شرح تفصيلي بالمصري

وثيقة متطلبات الأعمال — نظام التصاريح الموحد

دي قراءة كاملة لوثيقة الـ BRD رقم 001، مكتوبة بالعامية المصرية، سطر سطر، مع مثال عملي لكل حتة. الفكرة إنك تخرج من الصفحة دي فاهم النظام كأنك اللي كتبته — مش بس قريت العناوين.

الجهة: قيادة القوات الجوية الملكية السعودية المنفّذ: شركة مدينة الأعمال المحدودة الإصدار: 1.0 تاريخ الإصدار: 17 مايو 2026 الحجم: 41 صفحة · 25 قسم

§الخلاصة في 60 ثانية

لو مش هتقرا غير فقرة واحدة، اقرا دي.

القواعد الجوية دلوقتي بتدير التصاريح (اللي هي الكارنيهات اللي بتخلي الواحد يدخل ويخرج من القاعدة) بطريقة يدوية ومتفرقة — كل وحدة شغالة لوحدها، ورق، وإكسل، وتليفونات. الوثيقة دي بتطلب نظام مركزي واحد يجمع كل ده.

النظام ده بيعمل ٦ حاجات:

يستقبل الطلبات — طلب تصريح لمنتسب جديد، تجديد بعد ترقية، بدل فاقد، تصريح زائر، تصريح مؤقت لمتعاقد… إلخ.
يمشّيها في دورة موافقات (Workflow) — مدير الإدارة، وبعدين الاستخبارات لو الطلب حسّاس، وبعدين مدير قسم التصاريح.
يصدر التصريح ويطبعه ويولّد له باركود فريد.
ينزّل الباركود ده على أجهزة البوابات (أجهزة Honeywell) — عشان الجندي على البوابة يقرا الكارنيه ويعرف في ثانية: مصرّح ولا لأ.
يتكامل مع Oracle ERP عشان يجيب بيانات المنتسبين أوتوماتيك بدل ما حد يكتبها بإيده.
يشغّل طبقة ذكاء اصطناعي فوق كل الداتا دي عشان يطلّع تنبيهات: حد بيدخل منطقة مش بتاعته، بوابة فيها زحمة، وحدة بتستهلك حبر أكتر من الطبيعي.

مثال يخلّيك تحس بالفرق

النهارده: الرقيب أحمد اترقّى لرقيب أول. لازم كارنيه جديد. بيروح للإدارة، بيملا ورقة، الورقة تروح لمدير الإدارة يمضيها، حد يوديها بإيده لقسم التصاريح، القسم يدوّر على بياناته في ملف، يطبع الكارنيه، أحمد يجي يستلمه. المدة: من يومين لأسبوع. ومفيش حد يعرف الطلب واقف فين.

بعد النظام: ضابط الإدارة يفتح الشاشة، يكتب الرقم العسكري بتاع أحمد → النظام يجيب اسمه ورتبته من الـ ERP لوحده → يرفع خطاب الترقية → يبعت. مدير الإدارة يلاقي إشعار، يضغط "موافق". مدير قسم التصاريح يلاقي إشعار، يعتمد، يطبع. الباركود ينزل على أجهزة البوابات أوتوماتيك. أحمد ياخد إشعار "تصريحك جاهز للاستلام". المدة: ساعات. والطلب ليه رقم تتبّع تعرف بيه هو واقف عند مين بالظبط.

النقطة اللي لازم تفهمها كويس

الوثيقة دي مش تصميم فني نهائي — دي وثيقة متطلبات أعمال (BRD). يعني بتقول "النظام لازم يعمل إيه"، مش "النظام هيتعمل إزاي بالكود". فيها تفاصيل تقنية (سيرفرات، بورتات، قاعدة بيانات) بس دي على مستوى عالي — لسه ناقص وثيقة تصميم تفصيلي (SDD) وشاشات (Mockups) ومواصفات الـ API. وده طبيعي ومتوقّع في المرحلة دي.

1المقدمة — الغرض والنطاق والأهداف

1.1 الغرض

الوثيقة بتقول حرفيًا: الهدف هو "تحديد متطلبات وتفاصيل تصميم نظام مركزي متكامل لإدارة التصاريح داخل القواعد الجوية، بحيث يتم أتمتة الإجراءات وتحقيق أعلى مستويات الأمن والتحكم."

فكّها كده: تلات كلمات مفتاحية.

مركزي

مكانش فيه نظام واحد. كل قاعدة/وحدة كانت شغالة بطريقتها. دلوقتي في قاعدة بيانات واحدة والكل شغال عليها.

أتمتة

الورق والتوقيعات اليدوية تتحوّل لـ Workflow إلكتروني بإشعارات.

أمن وتحكّم

مين شاف إيه، مين وافق على إيه، ومين دخل امتى — كله متسجّل (Audit Log).

1.2 نطاق النظام (Scope)

ده أهم قسم في أي BRD، لأنه بيرسم الخط: إيه اللي جوّه المشروع وإيه اللي برّه. الوثيقة حددت 6 حاجات جوّه النطاق:

إصدار وإدارة تصاريح المنسوبين (العسكريين والمدنيين التابعين للقاعدة).
إدارة تصاريح الزوار.
إصدار التصاريح المؤقتة.
إدارة دورة حياة التصريح (من الطلب لحد الإلغاء).
التكامل مع نظام Oracle ERP.
الربط مع أجهزة قارئ الرموز الشريطية (الباركود).

لاحظ حاجة مهمة في النطاق

الوثيقة مقالتش إن النظام هيعمل تحكّم في فتح البوابة نفسها (Turnstile / Barrier). الأجهزة بتقرا الباركود وبتقول "مصرّح / غير مصرّح" — والجندي هو اللي بيفتح. ده فرق كبير في التكلفة والتعقيد، ومهم توضّحه مع العميل من دلوقتي.

كمان مفيش ذكر لـ تطبيق موبايل، ولا بوابة خدمة ذاتية للمنتسب (يقدم طلبه بنفسه). كل الطلبات بتتقدّم عن طريق الإدارات.

1.3 الأهداف

الهدف زي ما مكتوب	معناه عمليًا	إزاي تقيسه (KPI)
توحيد إجراءات التصاريح على مستوى القاعدة	نفس الخطوات ونفس النماذج في كل الوحدات	عدد الإجراءات المختلفة = 1
رفع مستوى الأمان	مفيش تصريح شغّال من غير موافقة، وكل حاجة متسجّلة	0 تصاريح صادرة بدون Audit trail كامل
تسريع المعالجة	الطلب يخلص في ساعات مش أيام	متوسط زمن الطلب من التقديم للإصدار
تقليل الإدخال اليدوي	البيانات تيجي من الـ ERP مش من كيبورد الموظف	نسبة الطلبات اللي اتملت أوتوماتيك
تمكين التتبّع اللحظي	تعرف الطلب واقف عند مين دلوقتي	كل طلب ليه رقم تتبّع وحالة حيّة
دعم اتخاذ القرار عبر التحليل الذكي AI	النظام يقولك "في مشكلة هنا" قبل ما تسأل	عدد التنبيهات الصحيحة / الكاذبة

ملاحظة صريحة

الأهداف دي مكتوبة كـ نوايا مش كـ أهداف قابلة للقياس. "تسريع المعالجة" مش هدف — "تقليل متوسط زمن إصدار تصريح منتسب من 5 أيام إلى أقل من 8 ساعات عمل" ده هدف. لما تيجي تسلّم المشروع وتقول "خلاص حققنا الأهداف"، هتحتاج الأرقام دي متفق عليها من دلوقتي. اسأل العميل عن الوضع الحالي (Baseline).

2أصحاب المصلحة — مين بيعمل إيه

ستة أطراف، وكل واحد ليه دور مختلف تمامًا. ده أهم جدول في الوثيقة لأنه بيحدّد صلاحيات النظام (Roles).

الجهة	الدور في الوثيقة	يعني إيه في النظام
القيادة العليا	التوجيه الاستراتيجي	مش بتشتغل على النظام يوميًا. بتشوف تقارير ولوحات مؤشرات بس. وبتستقبل تنبيهات معيّنة (زي "جهة معدل رفضها عالي").
إدارة قسم التصاريح	اعتماد ومراقبة التصاريح	ده مدير قسم التصاريح — أعلى سلطة تشغيلية. من غير موافقته مفيش تصريح بيتفعّل. وهو اللي بيستقبل معظم التنبيهات الذكية.
الاستخبارات	التذكية الأمنية (التحقق الأمني)	محطة موافقة إجبارية للطلبات الحسّاسة بس: المتعاقدين، المؤقتة، وغير السعوديين.
ضابط قسم التصاريح	إصدار ومعالجة الطلبات الواردة	الموظف اللي بيشتغل على الطلبات فعليًا — يراجع، يطبع، يسلّم.
إدارة الاتصالات	التشغيل والدعم الفني	الـ IT. مسؤولين عن السيرفرات، الشبكة، والأجهزة. مش مستخدمين للنظام في حد ذاته.
الإدارات المختلفة	تقديم الطلبات	مصدر كل الطلبات. كل إدارة فيها ضابط بيقدّم ومدير بيوافق.

مثال: مسار طلب بين الأطراف الستة

شركة صيانة تكييف عندها فني اسمه محمد (مصري الجنسية) هيشتغل جوّه القاعدة 3 شهور.

الإدارات المختلفة (إدارة الصيانة) → الضابط بيقدّم طلب "تصريح مؤقت" لمحمد.
مدير إدارة الصيانة → يراجع ويوافق.
النظام يشوف: تصريح مؤقت + متعاقد + غير سعودي → لازم استخبارات.
الاستخبارات → تعمل التذكية الأمنية. توافق.
مدير قسم التصاريح → الاعتماد النهائي.
ضابط قسم التصاريح → يطبع الكارنيه بالباركود.
إدارة الاتصالات → مالهاش دور في الطلب ده، بس هي اللي مخلّية الأجهزة والسيرفرات شغالة.
القيادة العليا → آخر الشهر بتشوف تقرير: "23 تصريح مؤقت، متوسط زمن التذكية الأمنية 3 أيام".

ثغرة في الجدول ده

مفيش دور اسمه مدير النظام (System Administrator) — اللي بيضيف مستخدمين، يعرّف المناطق (Zones)، يعرّف البوابات، يظبط قواعد الـ SLA. الوثيقة ذكرت "إدارة المستخدمين" كمتطلّب وظيفي (قسم 10) بس ماحددتش مين بيعملها. لازم تتحدد.

3نظرة عامة على النظام والمكوّنات

3.1 الوصف العام

"نظام إلكتروني مركزي لإدارة دورة حياة التصاريح من الطلب حتى التحقق عند البوابات عبر قارئ الرموز الشريطية، مع تكامل كامل مع الأنظمة الأخرى."

الجملة دي فيها البداية والنهاية: البداية = الطلب، النهاية = لحظة ما الجندي يقرا الباركود على البوابة. أي حاجة بره الخط ده مش من شغل النظام.

3.2 المكوّنات

المكوّنات الأساسية (7)

المكوّن	الشرح
إدارة الطلبات	الشاشات والفورمات اللي بتتقدّم منها كل أنواع الطلبات، وصندوق الوارد لكل مستخدم.
محرك الـ Workflow	العقل اللي بيقرر الطلب يروح لمين بعد كده. لو مؤقت → استخبارات. لو عادي → مدير التصاريح على طول.
إدارة التصاريح	الكيان بتاع التصريح نفسه: رقمه، بياناته، مناطقه، حالته، تاريخ انتهائه.
التكامل مع إدارة الاستخبارات	مسار الموافقة الأمنية — واجهة خاصة بيهم بيشوفوا فيها الطلبات الحسّاسة بس.
التكامل مع Oracle ERP	مصدر بيانات المنسوبين. النظام بيسأل الـ ERP بدل ما الموظف يكتب.
التكامل مع أجهزة Honeywell	ينزّل التصاريح على الأجهزة، ويطلّع منها حركات الدخول والخروج.
يدعم تقنية الذكاء الاصطناعي	طبقة تحليل فوق الداتا كلها. تطلّع 15 نوع تنبيه (شرحناهم في قسم 14).

المكوّنات الداعمة — إدارة المخزون (4)

ده الجزء اللي بيفاجئ الناس. النظام مش بس بيدير تصاريح — كمان بيدير مخزون الحبر والكروت البلاستيك اللي بتتطبع عليها التصاريح.

إدارة مخزون الكروت والأحبار.
متابعة الكميات لكل وحدة (Zone).
تسجيل عمليات الصرف والتوريد.
دعم طلبات الوحدات من المقر الرئيسي.

ليه ده موجود أصلًا؟

لأن المقر الرئيسي بيشتري الحبر والكروت مركزيًا وبيوزّعهم على الوحدات. لو مفيش تتبّع، وحدة تقعد تطلب كروت كل شهر ومحدش يعرف بتروح فين. النظام هنا بيربط عدد الكروت المصروفة بـ عدد التصاريح المطبوعة فعليًا — والفرق بينهم = هدر، والـ AI بيطلّع عليه تنبيه (شوف تنبيه 14.14).

الوصف الحرفي في الوثيقة: "مديول لإدارة مخزون المواد المستخدمة في طباعة التصاريح (الأحبار والكروت) بشكل مركزي، حيث يقوم المقر الرئيسي بإدارة الكميات وتوزيعها على الوحدات المختلفة."

4أنواع الطلبات — أهم قسم في الوثيقة

القسم ده هو اللي هيتحوّل لشاشات فعلية. فيه 13 نوع طلب مقسّمين على 6 مجموعات. هنمشي عليهم واحد واحد بالتفصيل الممل، لأن ده بالظبط اللي المبرمج محتاجه.

المجموعة	الأنواع	مين يقدر يقدّم؟	محتاج استخبارات؟
4.1 تصاريح المنتسبين	إصدار جديد · إعادة إصدار (ترقية) · إعادة إصدار (تلف) · بدل مفقود	الإدارات	لأ
4.2 التحديثات	إضافة منطقة · انتداب/تكليف/دورة	إدارة التصاريح بس	لأ
4.3 إدارة التصاريح	إلغاء · تجميد	إدارة التصاريح	لأ
4.4 الزوار	زيارة عمل · زيارة سكن · زيارة مناسبة · تمديد زيارة	الإدارات	لأ
4.5 التصاريح المؤقتة	إصدار تصريح مؤقت (≤ 3 شهور)	الإدارات	أيوه — إجباري
4.6 المخزون	طلب أحبار / كروت	مدير الإدارة	لأ — بس فيه تحليل AI

4.1 تصاريح المنتسبين — أربع حالات

أ) إصدار تصريح جديد

متى: منتسب داخل الوحدة (القاعدة) وبياخد تصريح لأول مرة.

الخطوات زي ما هي في الوثيقة:

الاستعلام عن بيانات المنتسب من النظام — بإدخال رقم الهوية أو الرقم العسكري.
أو إدخال البيانات يدويًا في حالة عدم توفّره.
إدخال بيانات التصريح: نوع التصريح + تحديد المناطق المسموح بها.
إرفاق المرفقات الداعمة:
- صورة الهوية
- صورة شخصية مقاس 60×60
- مستندات إضافية
إرسال الطلب لمدير الإدارة.

مثال كامل خطوة بخطوة

الجندي سعد بن ناصر القحطاني، رقم عسكري 4471902، اتنقل جديد لسرب الصيانة في القاعدة.

الخطوة 1

ضابط إدارة الصيانة يفتح "طلب جديد ← تصريح منتسب ← إصدار جديد".

الخطوة 2

يكتب 4471902 في خانة الرقم العسكري ويضغط "استعلام".

ما يحصل

النظام يكلّم Oracle ERP ويرجّع: الاسم الرباعي، رقم الهوية، الرتبة (جندي أول)، الإدارة (الصيانة)، الوحدة.

الخطوة 3

الضابط يختار نوع التصريح: "دائم — منتسب"، ويحدد المناطق: المنطقة الإدارية ورش الصيانة السكن. ما يختارش "المدرج" لأن ده مش شغله.

الخطوة 4

يرفع: صورة الهوية (PDF)، صورة شخصية 60×60 (JPG)، وخطاب النقل.

الخطوة 5

يضغط "إرسال". النظام يولّد رقم تتبّع، يقول مثلًا REQ-2026-001847، والحالة تبقى Pending.

بعد كده

مدير إدارة الصيانة ياخد إشعار فيه: رقم الطلب، نوعه، اسم مقدّم الطلب، تاريخ التقديم.

نقطة تصميمية مهمة: "أو إدخال البيانات يدويًا في حال عدم توفّره"

السطر ده صغير بس خطير. معناه إن النظام مش معتمد 100% على الـ ERP، وممكن حد يدخّل بيانات بإيده. وده بيفتح باب:

تكرار — نفس الشخص يتسجّل مرتين بشوية اختلاف في الاسم.
أخطاء إملائية في الأسماء العربية.
تلاعب محتمل — حد يدخّل شخص مش موجود أصلًا في الـ ERP.

اللي لازم يتحدد: مين له صلاحية الإدخال اليدوي؟ وهل بيتعلّم عليه علامة "بيانات غير موثّقة"؟ وهل بيتراجع بعدين لما الـ ERP يتحدّث؟

ب) إعادة إصدار — لغرض الترقية

متى: "تحديث التصريح نتيجة تغيير الرتبة داخل الوحدة."

الاستعلام عن بيانات المنتسب من النظام.
عرض بيانات التصريح الحالي.
تعديل الرتبة أو المسمى الوظيفي.
تحديث بيانات التصريح بناءً على الترقية.
إرفاق: خطاب الترقية.
إرسال الطلب لمدير الإدارة.

مثال

سعد بقى عريف. الضابط يفتح الطلب، النظام يعرض التصريح القديم PRM-88214 برتبة "جندي أول"، يغيّرها لـ "عريف"، يرفع خطاب الترقية، يبعت. النتيجة: كارنيه جديد بنفس المناطق بس برتبة جديدة. التصريح القديم لازم يتلغي ويتربط بالجديد.

الوثيقة ما قالتش

مقالتش صراحةً إن التصريح القديم بيتلغي. في حالة "التلف" و"بدل مفقود" قالت كده بوضوح، بس في الترقية سكتت. لازم يتحدد: هل الكارنيه القديم بيتشال من أجهزة البوابات، ولا هيفضل شغّال؟ لو فضل شغّال، ده ثغرة أمنية — الراجل هيبقى معاه كارنيهين.

ج) إعادة إصدار — لغرض التلف

متى: "استبدال تصريح تالف."

الاستعلام عن بيانات المنتسب.
إدخال رقم التصريح التالف.
تحديد سبب الإعادة (تالف).
إرفاق صورة التصريح التالف اختياري.
إصدار تصريح جديد بنفس البيانات.
ربطه بالتصريح السابق.
إرسال الطلب لمدير الإدارة.

مثال

كارنيه سعد اتكسر في الغسّالة والباركود مبقاش يتقرا. الضابط يعمل طلب "تلف"، يكتب PRM-88214، يصوّر الكارنيه المكسور، يبعت. النظام يطلّع PRM-91033 بنفس البيانات بالظبط، ويحطّ في التاريخ: "بديل لـ PRM-88214 — سبب: تلف".

د) بدل مفقود

متى: "إلغاء التصريح القديم وإصدار تصريح جديد." — لاحظ الفرق: هنا الإلغاء صريح ومذكور.

الاستعلام عن بيانات المنتسب.
إدخال رقم التصريح المفقود.
تسجيل بلاغ فقدان.
إلغاء التصريح السابق من النظام.
إصدار تصريح جديد.
تسجيل ملاحظة (بدل مفقود).
إرفاق: خطاب بدل الفقدان.
إرسال الطلب لمدير الإدارة.

دي أخطر حالة أمنيًا

كارنيه ضايع = كارنيه ممكن يكون في إيد حد تاني. عشان كده الوثيقة أصرّت على "إلغاء التصريح السابق من النظام". لكن الإلغاء في قاعدة البيانات مش كفاية — لازم الإلغاء ده ينزل على أجهزة البوابات فورًا. والوثيقة (في قسم 12) بتقول إن الأجهزة شغالة Offline وبتتزامن كل فترة. يعني في فجوة زمنية بين إلغاء الكارنيه ونزول الإلغاء على الأجهزة.

السؤال اللي لازم يتسأل: المزامنة بتحصل كل قد إيه؟ وهل في مسار "مزامنة عاجلة" لحالات الفقدان؟

لحسن الحظ في تنبيه ذكي بيغطّي الحالة دي جزئيًا: 14.3 تنبيه تجاوز الصلاحيات — "محاولة استخدام تصريح ملغى أو مجمّد". بس ده بيكتشف بعد ما الحركة حصلت.

4.2 التحديثات

قيد صلاحيات مهم جدًا

عنوان القسم في الوثيقة حرفيًا: "تحديثات (تتم عن طريق إدارة التصاريح فقط بحيث لا تظهر في الطلبات للإدارات)".

يعني النوعين دول مش هيظهروا في قائمة الطلبات بتاعة الإدارات العادية خالص. مدير قسم التصاريح بس هو اللي يشوفهم. ده متطلّب صلاحيات (Permission) لازم يتنفّذ في الـ UI وفي الـ API الاتنين.

أ) إضافة منطقة داخل وحدة

متى: "تعديل التصريح لإضافة مواقع جديدة داخل الوحدة."

الاستعلام عن بيانات المنتسب.
عرض التصريح الحالي.
اختيار المناطق الجديدة.
إرفاق: خطاب يؤكد أن المنتسب سوف يعمل بالمنطقة X.
حفظ التعديل وتحديث التصريح.
إرسال الطلب لمدير الإدارة.

مثال

سعد اتنقل من ورش الصيانة لصيانة الطائرات — بقى محتاج يدخل المدرج. إدارة التصاريح تفتح تصريحه، تضيف منطقة "المدرج"، ترفع الخطاب اللي بيقول إنه هيشتغل هناك، وتحفظ.

سؤال مفتوح: هل ده بيطلّع كارنيه جديد ولا نفس الكارنيه بس المناطق اتحدّثت في الداتا بيز؟ منطقيًا لو المناطق مطبوعة على الكارنيه لازم يتطبع جديد. الوثيقة سكتت. اسأل.

ب) انتداب / تكليف / دورة

متى: "تصريح مؤقت لمهمة خارج الوحدة (القاعدة)."

إدخال بيانات المنتسب.
تحديد نوع المهمة: انتداب تكليف دورة.
تحديد الوحدة (الوحدة اللي رايحلها).
تحديد تاريخ البداية والنهاية.
تحديث المناطق بناءً على الوحدة — أهم سطر هنا.
إرفاق: خطاب التكليف.
إرسال الطلب لمدير الإدارة.

مثال + النقطة التقنية اللي وراه

سعد مكلّف بدورة 6 أسابيع في قاعدة تانية. لازم يدخل هناك — بس مناطقه في قاعدته الأصلية مش هتنفع هناك. عشان كده الوثيقة بتقول "تحديث المناطق بناءً على الوحدة": يعني النظام لازم يعرف كل وحدة فيها أنهي مناطق، ولمّا تختار الوحدة يعرض عليك مناطقها هي بس.

ده معناه إن في جدول في الداتا بيز: Units ← Zones ← Gates. تسلسل هرمي. مهم جدًا في التصميم.

وطبعًا للتصريح ده تاريخ انتهاء — يوم ما تخلص الدورة يبطل شغّال أوتوماتيك.

4.3 إدارة التصاريح — الإلغاء والتجميد

إلغاء تصريح — نهائي

متى: عند التقاعد أو إنهاء الخدمة. مفيش رجوع.

الخطوات: البحث عن المنتسب ← عرض بيانات التصريح ← تحديد سبب الإلغاء (تقاعد / إنهاء خدمة) ← إلغاء التصريح ← تحديث الحالة من نشط إلى ملغي ← إرسال الطلب لمدير الإدارة.

تجميد تصريح — مؤقت

متى: "إيقاف مؤقت مع إمكانية إعادة التفعيل."

الخطوات: البحث عن المنتسب ← عرض بيانات التصريح ← إدخال سبب التجميد ← تغيير الحالة من نشط إلى مجمّد ← إرسال الطلب لمدير الإدارة.

الفرق بينهم بمثال

إلغاء: الرائد خالد وصل سن التقاعد. تصريحه يتلغي نهائيًا. لو حاول يدخل، الجهاز يقول "غير مصرّح".

تجميد: الرقيب فهد في إجازة طويلة 4 شهور، أو تحت التحقيق، أو مبتعث. تصريحه يتجمّد. لما يرجع، إدارة التصاريح تفكّ التجميد ويرجع شغّال بنفس البيانات ونفس الكارنيه.

حاجتين ناقصين هنا

الوثيقة ذكرت التجميد ما ذكرتش شاشة فكّ التجميد — رغم إنها ذكرت إشعار "عند إعادة تفعيل التصريح" (قسم 13.6). يعني العملية موجودة ضمنيًا بس مش موصوفة. لازم تتضاف كنوع طلب.
مفيش مدة تجميد افتراضية ولا تنبيه لو التجميد طوّل. الإشعار في 13.5 بيذكر "مدة التجميد" كمحتوى، يعني الحقل موجود — بس مين بيراجع لو المدة عدّت؟

4.4 الزوار — تلات أنواع في جدول واحد

الوثيقة حطّت التلات أنواع في جدول متوازي. في حقول مشتركة بتتاخد من أي زائر مهما كان نوع الزيارة، وحقول خاصة بكل نوع.

الحقول المشتركة (بتتاخد من كل زائر)

الحقل	إلزامي؟	ملاحظات
الاسم رباعي	إلزامي	رباعي بالتحديد — مش تلاتي
نوع الإثبات: رقم الهوية / رقم الجواز / رقم الحدود	إلزامي	تلات أنواع إثبات مختلفة — كل واحد ليه فورمات مختلف
رقم الجوال	إلزامي
الجنسية	إلزامي	مهم — لأن غير السعودي محتاج استخبارات
الديانة	اختياري	مش عليه نجمة في الوثيقة
مكان الميلاد	إلزامي

الحقول الخاصة بكل نوع زيارة

	زيارة عمل	زيارة سكن	زيارة مناسبة
الحقل 1	تحديد الإدارة المستهدفة	تحديد منطقة السكن	نوع المناسبة (تخرج / عيد / فعالية)
الحقل 2	تحديد الشخص المستهدف	تحديد بيانات الساكن	الشخص المستضيف
الحقل 3	تحديد المندوب	إدخال رقم الساكن	رقم جوال المستضيف
الفترة	تحديد وقت الدخول والخروج	تحديد فترة الزيارة	فترة الزيارة (وقت الدخول المتوقع — وقت الخروج المتوقع)
المرفقات	صورة الهوية + نموذج الزيارة	صورة الهوية	صورة الهوية + دعوة المناسبة
الموافقة	إرسال الطلب لمدير الإدارة	الموافقة من قبل المناوب	الموافقة من قبل منظّم المناسبة

لاحظ: تلات مسارات موافقة مختلفة

ده مش مجرد اختلاف في الحقول — ده اختلاف في الـ Workflow نفسه:

زيارة عمل → مدير الإدارة
زيارة سكن → المناوب (دور جديد ما ظهرش في جدول أصحاب المصلحة!)
زيارة مناسبة → منظّم المناسبة (دور جديد كمان!)

يعني في دورين إضافيين لازم يتعرّفوا في النظام مكانوش في قسم 2.

بيانات المركبة (اختياري — تشيك بوكس)

لو الزائر جاي بعربية، بيتفتح قسم فيه: الدولة، رقم اللوحة، العلامة التجارية، سنة التصنيع، اللون، نوع الطراز.

مثال كامل — زيارة مناسبة

حفل تخرّج في القاعدة. والد أحد الخريجين، عبدالله محمد سعيد الغامدي، سعودي، هوية 1012345678، جوال 0555••••••، جاي بعربيته.

نوع الزيارة

مناسبة

نوع المناسبة

تخرّج

الشخص المستضيف

الملازم أول أحمد الغامدي (ابنه)

الفترة

15 يونيو 2026، دخول 4:00م — خروج 9:00م

بمركبة

✅ — تويوتا كامري، أبيض، 2023، لوحة ABC 1234، السعودية

المرفقات

صورة الهوية + دعوة الحفل

الموافقة

منظّم المناسبة (ضابط شؤون الحفل)

بعد الموافقة → إشعار يروح للجهة المستضيفة فيه: اسم الزائر، رقم الهوية، وقت الدخول والخروج، المناطق المسموح بها (قسم 13.7). ويوم الحفل، عبدالله بياخد كارت مؤقت من البوابة عليه باركود، بيستخدمه للدخول والخروج، وبيسلّمه لما يمشي عشان يترجّع للمخزون ويتعاد استخدامه.

تمديد زيارة

البحث عن الزائر.
عرض بيانات الزيارة الحالية.
إدخال المدة الجديدة.
تحديد سبب التمديد.
إرسال الطلب لمدير الإدارة.
تحديث تاريخ الانتهاء.

وطبعًا في إشعار مرتبط: التمديد بيروح لمدير قسم التصاريح، وكمان للمناوب لو الزيارة زيارة سكن (قسم 13.11).

4.5 التصاريح المؤقتة

الوصف: "إصدار تصريح مؤقت (محددة المدة الزمنية)."

إدخال بيانات الشخص.
تحديد تاريخ البداية والنهاية — "أقصى فترة ممكن يختارها في التقويم هي 3 أشهر".
تحديد المناطق المسموح بها.
إرفاق: صورة الهوية + صورة شخصية + النموذج.
إرسال الطلب لمدير الإدارة.
بعد موافقة مدير الإدارة → الطلب يروح للاستخبارات.
إصدار التصريح بعد الموافقة.

دي أوضح قاعدة عمل في الوثيقة كلها

"أقصى فترة 3 أشهر" — دي قاعدة قابلة للبرمجة مباشرة. الـ Date Picker في الشاشة لازم يمنع اختيار تاريخ نهاية أبعد من 3 شهور من تاريخ البداية. مش تحذير — منع.

ولاحظ إنها مكتوبة "ممكن يختاره في التقويم" — يعني القيد على مستوى الـ UI. بس لازم يتحطّ كمان على مستوى الـ API والداتا بيز، عشان محدش يعدّي منه.

مثال

شركة "الخليج للمقاولات" هتعمل صيانة لمبنى الإدارة، ومحتاجة 12 فني يدخلوا لمدة شهرين ونص. كل فني بيتعمله طلب تصريح مؤقت لوحده: بياناته، من 1 يوليو لـ 15 سبتمبر، المناطق = "مبنى الإدارة" و"البوابة الشمالية" بس. بعد موافقة مدير الإدارة، الـ 12 طلب كلهم يروحوا للاستخبارات للتذكية الأمنية. الاستخبارات توافق على 11 وترفض واحد بسبب. الـ 11 يروحوا لمدير قسم التصاريح للاعتماد النهائي والطباعة.

4.6 طلب أحبار / كروت — وده أكتر مسار فيه ذكاء

المسار ده مختلف عن باقي المسارات لأن فيه خطوة تحليل ذكي قبل القرار البشري.

مدير الإدارة ينشئ طلب مواد← إدخال البيانات← إرسال لمدير قسم التصاريح← تحليل ذكي AI← قرار مدير قسم التصاريح

بيانات الطلب

نوع المادة: أحبار / كروت
الكمية المطلوبة
مبرر الطلب

التحليل الذكي — بيقارن الطلب بتلات حاجات

عدد التصاريح المطبوعة (كام تصريح الوحدة دي طبعت فعلًا؟)
معدّل الاستهلاك (بتستهلك قد إيه في المتوسط؟)
المخزون الفعلي (عندها كام دلوقتي؟)

والنتيجة بتتعرض لمدير قسم التصاريح كـ "دعم اتخاذ القرار" — مش قرار أوتوماتيكي. الراجل هو اللي بيقرر في الآخر.

لو وافق

يتم صرف المواد
تحديث مخزون الوحدة
تسجيل العملية في النظام
تحديث بيانات التحليل الذكي AI ← يعني النموذج بيتعلّم ويتحسّن
إرسال إشعار للإدارة بالموافقة

لو رفض

تسجيل سبب الرفض
إرسال إشعار بالرفض لمدير الإدارة

مثال يوضّح قيمة الـ AI هنا

وحدة "القاعدة الشرقية" بتطلب 500 كارت.

النظام بيطلّع لمدير قسم التصاريح الكارت ده:

الكمية المطلوبة

500 كارت

المخزون الحالي عندهم

310 كارت

تصاريح مطبوعة آخر 3 شهور

142 تصريح

معدل الاستهلاك الشهري

≈ 47 كارت

الاستهلاك المتوقع لـ 3 شهور جاية

≈ 141 كارت

التوصية

المخزون الحالي يكفي 6 شهور — راجع مبرر الطلب

من غير الشاشة دي، المدير كان هيوافق على الـ 500 من غير ما يفكّر. بالشاشة دي، هيسأل: "إنتوا عندكوا 310 وبتستهلكوا 47 في الشهر، ليه طالبين 500؟"

مخطط طلبات الأحبار والكروت من المقر الرئيسي — المخطط الأصلي من الوثيقة (قسم 9، صفحة 14) — دورة طلب المواد كاملة من إنشاء الطلب لحد تحديث بيانات الـ AI.

4.7 الاستخبارات (الموافقات)

الوصف: "مراجعة واعتماد الطلبات الحسّاسة."

إيه اللي بيوصلهم؟ تلات أنواع بس

تصاريح المتعاقدين

أي حد شغّال بعقد مش منتسب أصلي.

التصاريح المؤقتة

أي تصريح محدد بمدة (≤ 3 شهور).

تصاريح الأجانب غير السعوديين

معيار الجنسية.

بيعملوا إيه؟

عرض الطلبات (الأنواع التلاتة بس).
مراجعة البيانات مع المرفقات الداعمة.
اتخاذ القرار: موافقة أو رفض مع توضيح السبب.
تسجيل الملاحظات.
تحديث حالة الطلب.

سؤال تقني مهم

التلات معايير دول ممكن يتقاطعوا. متعاقد + غير سعودي + تصريح مؤقت = نفس الشخص. هل بيروح للاستخبارات مرة واحدة ولا تلاتة؟ منطقيًا مرة واحدة، بس لازم القاعدة تتكتب صراحةً:

needsIntelligence = isContractor OR isTemporary OR (nationality != 'SA')

وكمان: مين بيحدد إن الشخص "متعاقد"؟ ده حقل في الـ ERP ولا حقل بيتملا يدوي؟ لو يدوي، ممكن حد ينسى يعلّم عليه والطلب يعدّي من غير تذكية أمنية. دي ثغرة أمنية حقيقية لازم تتقفل.

5سير العمل (Workflow) وحالات الطلب

الوثيقة بتعرّف مسارين بس، ودي أهم فكرة في النظام كله.

5.1 المسار العادي

الإدارة← قسم التصاريح← مراجعة← إصدار

ده لأي طلب عادي: تصريح منتسب جديد، ترقية، تلف، بدل مفقود، زيارة عادية. أربع محطات وخلاص.

5.2 المسار الأمني

الإدارة← الاستخبارات← التذكية← التصاريح← إصدار

ده للطلبات الحسّاسة. خمس محطات — زوّدنا محطة الاستخبارات والتذكية الأمنية.

المسار الأمني كما في الوثيقة (صفحة 11) — بمحطة الاستخبارات والتذكية.

المخططات دي مبسّطة أوي

لاحظ إن المخططات خط مستقيم — مفيش فيها الرفض ولا الإرجاع للتعديل. لكن جدول الحالات (تحت) فيه Rejected و Returned. يعني المسارات الحقيقية أعقد من الرسمة. المخطط الشامل في قسم 8 بيوضّح ده بشكل أفضل.

5.3 حالات الطلب

الحالة	الوصف في الوثيقة	معناها عمليًا
Pending	قيد المراجعة	الطلب موجود عند حد ومستنّي قرار. ده اللي بيتحسب عليه الـ SLA.
Approved	تم الاعتماد	عدّى المحطة الحالية. لو دي آخر محطة → التصريح يتصدر.
Rejected	مرفوض	نهاية المسار. لازم يتكتب سبب.
Returned	معاد للتعديل	مش رفض — الطلب راجع لمقدّمه يصلّح حاجة ويبعت تاني.

أربع حالات مش كفاية

الحالات دي ناقصة كتير. مثلًا:

Draft — الضابط بدأ يملا الطلب وما خلّصش. هيروح فين؟
Approved عامة أوي — الطلب معتمد من مين؟ من مدير الإدارة؟ من الاستخبارات؟ محتاج حالات زي PendingIntelligence و PendingPermitManager. والدليل إن الوثيقة نفسها في قسم 13.2 ذكرت حالة اسمها "قيد التذكية الأمنية (الاستخبارات)" — وهي مش في الجدول ده!
Printed / Ready for Collection / Delivered — الوثيقة فيها إشعار "التصريح جاهز للاستلام" (13.4)، يعني في حالة كده موجودة ومش مكتوبة.
Cancelled — مقدّم الطلب سحبه.

ده أوضح نقص في الوثيقة، ولازم يتعالج في وثيقة التصميم التفصيلي.

6القواعد التشغيلية — خمس قواعد ذهبية

#	القاعدة	ليه مهمة
1	جميع الطلبات لها رقم تتبّع فريد	من غيره مش هتقدر تتبّع ولا تدوّر ولا تتكلم مع العميل عن طلب بعينه. لازم يتولّد أوتوماتيك ويكون مقروء للبني آدم (مثلًا `REQ-2026-001847`).
2	المرفقات إلزامية حسب نوع الطلب	مش كل الطلبات بتطلب نفس المرفقات. طلب ترقية لازمه خطاب ترقية، طلب بدل فاقد لازمه خطاب فقدان. يعني الـ Validation ديناميكي حسب النوع.
3	التصاريح المؤقتة وتصاريح المتعاقدين تتطلب موافقة استخباراتية	دي القاعدة اللي بتحكم اختيار المسار (عادي ولا أمني).
4	تسجيل كامل العمليات (Audit Log)	مين عمل إيه وامتى. في منشأة عسكرية ده مش رفاهية — ده مطلب أساسي. لازم يشمل حتى عمليات القراءة مش بس التعديل.
5	لا يتم تفعيل أي تصريح بدون موافقة نهائية من مدير قسم التصاريح	نقطة تحكّم واحدة نهائية. حتى لو الاستخبارات وافقت والإدارة وافقت — من غير المدير مفيش تصريح.

لاحظ تناقض بسيط

القاعدة 3 بتقول "التصاريح المؤقتة وتصاريح المتعاقدين" — بس قسم 4.7 (الاستخبارات) بيقول "المتعاقدين + المؤقتة + الأجانب غير السعوديين". يعني الجنسية اتنسيت من القواعد التشغيلية. حاجة صغيرة بس في وثيقة متطلبات لازم تكون متسقة.

7دورة حياة التصريح

طلب← مراجعة← اعتماد← إصدار← تفعيل← استخدام← إلغاء / تجميد

خلّي بالك من الفرق بين الإصدار والتفعيل — دول مرحلتين مختلفتين:

إصدار (Issue)

الكارنيه اتعمل في النظام واتطبع فعليًا. لسه مش شغّال على البوابة.

تفعيل (Activate)

بيانات الكارنيه اتبعتت لأجهزة البوابات، ودلوقتي الجهاز يقدر يقراه ويقول "مصرّح".

الفرق ده مهم عمليًا: ممكن كارنيه يكون مطبوع ومستنّي الاستلام، بس لسه مش مفعّل. ولازم شاشة تفرّق بين الحالتين.

حاجة ناقصة في الدورة

المخطط بينتهي بـ "إلغاء / تجميد" — بس مفيش انتهاء صلاحية (Expiry) رغم إن التصاريح المؤقتة والزيارات كلها ليها تاريخ انتهاء! لازم في حالة Expired بتحصل أوتوماتيك، والوثيقة نفسها في قسم 13.10 بتقول "تحديث الحالة إلى منتهية" للزيارات. فحالة Expired موجودة ضمنيًا ومش مرسومة.

وكمان مفيش إعادة تفعيل (Reactivate) في الرسمة رغم إنها موجودة في الإشعارات (13.6).

8المخطط الشامل لآلية تقديم الطلبات

ده أهم مخطط في الوثيقة كلها. بيجمع كل حاجة قلناها فوق في صورة واحدة.

مخطط آلية تقديم الطلبات — المخطط الكامل لآلية تقديم الطلبات (الوثيقة، صفحة 13).

قراءة المخطط سطر سطر

فوق خالص: أربع دواير = الأدوار الأربعة (الإدارات داخل الوحدة · مدير الإدارة · مدير قسم التصاريح · إدارة الاستخبارات).
"تقديم طلب تصريح" → بيتفرّع لخمس مجموعات: التصاريح الدائمة تحديثات إدارة التصاريح تصاريح الزوار التصاريح المؤقتة.
كل مجموعة بتتفرّع لأنواعها (إصدار جديد، إعادة إصدار ترقية، بدل تالف، بدل مفقود… إلخ) — إجمالي 13 نوع.
كل الفروع بترجع تتجمّع في نقطة واحدة: معيّن "قرار مدير الإدارة" (المعيّن = شكل الماسة، يعني قرار).
لو مرفوض → "رفض الطلب" → خلاص.
لو موافق → "التحقق من صحة الطلب" → معيّن تاني: "هل يتطلب موافقة الاستخبارات؟"
نعم → "الاستخبارات: موافقة / رفض مع السبب".
لا → "مدير التصاريح: موافقة / رفض مع السبب".
الاتنين بيرجعوا لـ "اتخاذ القرار".
لو مرفوض → "رفض مع توضيح السبب".
لو موافق → "إصدار التصريح" وبيتفرّع لفرعين متوازيين:
- "طباعة التصريح" → "إرسال إشعار بجاهزية التصريح للاستلام"
- "إرسال بيانات التصريح للأجهزة" → "أجهزة قارئ الرموز الشريطية" → "التحقق من حالة التصريح عند البوابات"

الحاجة الحلوة في المخطط ده

إنه بيوضّح إن الطباعة والتفعيل على الأجهزة بيحصلوا بالتوازي — مش واحد ورا التاني. يعني الباركود بينزل على الأجهزة في نفس اللحظة اللي الكارنيه بيتطبع فيها، حتى لو صاحبه ما جاش يستلمه لسه.

وحاجة وحشة في المخطط ده

حالة Returned (معاد للتعديل) مش موجودة في المخطط خالص. المخطط عنده قرارين بس: موافق أو مرفوض. مفيش سهم راجع لمقدّم الطلب. لكن الحالة موجودة في جدول 5.3. ده تناقض واضح لازم يتحل.

10المتطلبات الوظيفية

الوثيقة سردتهم كسبع نقط مختصرة. هفكّهم لك:

المتطلب	يعني إيه بالتفصيل
إدارة الطلبات	إنشاء، تعديل، حذف، بحث، فلترة، صندوق وارد لكل مستخدم حسب دوره، عرض تفاصيل الطلب مع مرفقاته وتاريخه الكامل.
Workflow متعدد	مش Workflow واحد — أكتر من مسار حسب نوع الطلب ونوع الشخص. المحرك لازم يكون قابل للتعريف مش مبرمج بالحديد في الكود، عشان لو القواعد اتغيّرت ما تحتاجش نسخة جديدة من البرنامج.
إصدار باركود فريد لكل تصريح	الباركود هو مفتاح الربط بين النظام والأجهزة. لازم يكون فريد عالميًا (مش على مستوى الوحدة بس)، وما يتعادش استخدامه أبدًا حتى بعد الإلغاء.
إشعارات	15 نوع إشعار عادي + 15 نوع ذكي. تفاصيلهم في قسمي 13 و14.
تقارير	تلات فئات (قسم 16): الطلبات، الدخول والخروج، تقارير أمنية.
إدارة المستخدمين	إضافة/تعديل/تعطيل مستخدمين، وربطهم بالأدوار (RBAC — مذكور في قسم الأمن).
مزامنة الأجهزة	نزول التصاريح للأجهزة، وطلوع حركات الدخول والخروج للنظام.

القسم ده أضعف قسم في الوثيقة

سبع كلمات مش هتبني منها نظام. مفيش ولا User Story واحدة، ولا معايير قبول (Acceptance Criteria)، ولا مواصفة شاشة. المتطلبات الحقيقية مبعثرة في قسم 4 (أنواع الطلبات) وقسم 13 و14 (الإشعارات) — والقسم اللي المفروض يجمّعهم فاضي تقريبًا.

التوصية: اعمل جدول متطلبات وظيفية مرقّم (FR-001 … FR-nnn) كل واحد بمعيار قبول واضح. ده اللي هتتحاسب عليه وقت التسليم.

11المتطلبات غير الوظيفية

الفئة	المتطلب	قراءتي
الأداء	زمن الاستجابة < 2 ثانية	مقبول لنظام إداري. بس ناقص: تحت أي حِمل؟ 50 مستخدم ولا 500؟ وهل الـ 2 ثانية دي للشاشة كلها ولا للـ API؟ وإيه اللي بيتقاس — المتوسط ولا الـ p95؟
التوفّر	99.9%	يعني ≈ 8 ساعات و45 دقيقة انقطاع مسموح بيها في السنة. رقم معقول ومتسق مع البنية اللي في قسم 19 (سيرفرين + Load Balancer + SQL Always-On).
الأمان	عالي الأمان — Encryption	كلمة فضفاضة. القسم 20 بيفصّلها أحسن (MFA، RBAC، TLS، Data at Rest).
قابلية التوسّع	دعم آلاف المستخدمين	"آلاف" مش رقم. 3 آلاف ولا 30 ألف؟ الفرق في التصميم هائل. اسأل عن العدد الفعلي.
الاعتمادية	High Availability	مغطّاة في قسم 19.5 بتفصيل أحسن.

فئات غير وظيفية غايبة تمامًا

الاسترجاع/الأرشفة — التصاريح الملغية تفضل في النظام قد إيه؟ سنة؟ عشرة؟ للأبد؟ في منشأة عسكرية ده مهم قانونيًا.
سهولة الاستخدام (Usability) — النظام هيستخدمه ضباط مش بالضرورة تقنيين. مفيش أي متطلب عن ده.
اللغة — عربي؟ إنجليزي؟ الاتنين؟ الوثيقة عربية بس ماحددتش.
المتصفحات المدعومة — Edge بس؟ Chrome؟ إيه المتاح على شبكة القاعدة؟
الطابعات — نوع طابعة الكروت البلاستيك (Zebra? Evolis? Fargo?) والتوصيل بيها. الوثيقة بتقول "طابعات مخصصة" وخلاص.

12التكاملات — أهم قسم تقني

12.1 التكامل مع Oracle ERP

الغرض: جلب بيانات المنسوبين + تحديث تلقائي للبيانات.

والوثيقة حددت الحقول بالظبط:

Field Name	Data Type	الوصف	ملاحظتي
PersonnelID	Int (PK)	معرّف فريد للمنتسب	المفتاح الأساسي للربط
FullName	String(200)	الاسم الكامل	حقل واحد — يعني مفيش تقسيم أول/أب/جد/عائلة. بس فورمة الزوار طلبت "اسم رباعي"!
NationalID	String(20)	رقم الهوية الوطنية	String مش Int — صح، عشان الأصفار البادئة
MilitaryNumber	String(20)	الرقم العسكري	مفتاح بحث تاني
Rank	String(50)	الرتبة العسكرية أو الوظيفية	نص حر — الأفضل يكون كود مربوط بجدول رتب
Department	String(100)	اسم الإدارة	نص كمان — المفروض `DepartmentID`
Unit	String(100)	الوحدة المعيّن بها	نص كمان
IssueDate	DateTime	تاريخ إصدار التصريح	غريب — ده حقل بتاع التصريح مش بتاع الـ ERP
ExpiryDate	DateTime	تاريخ انتهاء التصريح	غريب — نفس الملاحظة
Status	String	Active / Frozen / Cancelled	غريب — دي حالة التصريح مش حالة الموظف
Notes	String(500)	ملاحظات إضافية

مشكلة حقيقية في الجدول ده

الجدول ده مخلوط. آخر أربع حقول (IssueDate, ExpiryDate, Status, Notes) مش بيانات موظف من الـ ERP — دي بيانات تصريح بيولّدها نظام التصاريح نفسه. الـ ERP ماعندوش أصلًا فكرة "حالة التصريح".

يعني الجدول ده مش عقد الـ API مع الـ ERP، ده أقرب لـ شكل جدول في قاعدة بيانات نظام التصاريح. لازم يتفصلوا:

ERP.Personnel → PersonnelID, FullName, NationalID, MilitaryNumber, Rank, Department, Unit
Permits.Permit → PermitID, PersonnelID (FK), Barcode, IssueDate, ExpiryDate, Status, Zones[], Notes

وكمان: ناقص حقول أساسية — الجنسية (وهي معيار التذكية الأمنية!)، نوع التعاقد (منتسب/متعاقد — وده كمان معيار!)، حالة الخدمة (على رأس العمل / متقاعد / منتهي خدمته).

أسئلة تكامل مش مجاوب عليها

التكامل Pull (نظام التصاريح بيسأل) ولا Push (الـ ERP بيبعت لما حاجة تتغيّر)؟ الوثيقة بتقول "تحديث تلقائي" بس ما شرحتش الآلية.
لو الـ ERP وقع، النظام يقف؟ ولا في Cache محلي؟ (المخاطر في قسم 23 بتقول العلاج هو "Retry + Monitoring" — يعني مفيش Cache).
لو موظف اتقاعد في الـ ERP، هل تصريحه بيتلغي أوتوماتيك؟ ده هيكون أقوى فيتشر أمني في النظام كله، والوثيقة ما ذكرتوش.
شكل الـ API إيه؟ REST؟ SOAP؟ Oracle Integration Cloud؟ الأمان إزاي — Token؟ mTLS؟

12.2 التكامل مع أجهزة Honeywell — وده الجزء الأذكى في الوثيقة

الوظائف الأربعة المذكورة:

إرسال بيانات التصاريح بكل الأنواع
مزامنة الأجهزة
التحقق عند البوابات
إرسال حركات الدخول والخروج

الفكرة العبقرية: الكروت المعرّفة مسبقًا للزوار

دي محتاجة شرح بالراحة لأنها حل ذكي لمشكلة حقيقية.

المشكلة والحل

المشكلة: الزائر بييجي فجأة. لو هنطبعله كارنيه ونستنى النظام يزامن الأجهزة، ده ممكن ياخد وقت — والزائر واقف على البوابة.

الحل زي ما في الوثيقة: "يعتمد النظام على استخدام بطاقات مؤقتة معرّفة مسبقًا (Pre-Registered Cards) ومخزّنة داخل أجهزة قارئ الرموز الشريطية، بحيث تحتوي كل بطاقة على رمز شريطي فريد. وعند وصول الزائر، يتم إدخال بياناته في النظام المركزي وإسناد إحدى هذه البطاقات له، ليتم استخدامها مباشرة عند البوابة دون الحاجة إلى مزامنة فورية."

يعني إيه: عندك مثلًا 200 كارت مطبوعين مسبقًا بأرقام باركود من VIS-0001 لـ VIS-0200، وكل الأجهزة عارفاهم كلهم من الأول. لما زائر ييجي، الموظف يديله الكارت رقم VIS-0047 ويربطه بيه في النظام. الجهاز على البوابة أصلًا عارف VIS-0047 ← يقرا ويقول "مصرّح". لما الزائر يمشي، يرجّع الكارت، الربط يتفكّ، والكارت يرجع للمخزون لزائر تاني.

وضع عدم الاتصال (Offline Mode)

الوثيقة: "تعمل الأجهزة في وضع عدم الاتصال، حيث يتم التحقق من صلاحية البطاقة بناءً على البيانات المخزّنة محليًا، دون عرض أي بيانات شخصية للزائر، وتقتصر نتيجة التحقق على (مصرّح / غير مصرّح). عند إجراء المزامنة، يتم إرسال جميع حركات الدخول والخروج إلى النظام المركزي."

ليه Offline؟

عشان لو الشبكة وقعت أو الجهاز مش واصل، البوابة تفضل شغالة. في منشأة عسكرية ده مش اختياري.

ليه مفيش بيانات شخصية؟

لأن الجهاز محمول وممكن يضيع أو يتسرق. لو فيه أسماء وأرقام هويات، ده تسريب. فالجهاز بيشوف الباركود بس ويقول مصرّح/لأ.

إيه اللي بيطلع من الأجهزة وقت المزامنة؟

الوثيقة عدّدت 8 حقول لكل حركة:

#	الحقل	مثال
1	رقم البطاقة	VIS-0047
2	اسم الزائر	عبدالله محمد سعيد الغامدي
3	الجهة المستضيفة	سرب الصيانة
4	المناطق المصرّح بها	مبنى الإدارة، الساحة
5	البوابة	Gate-1
6	جهاز القراءة	ZONE1-GATE1-DEV2
7	التاريخ والوقت	2026-06-15 16:12:44
8	نوع الحركة	دخول / خروج

تناقض صغير بس مهم

الحقول 2، 3، 4 (اسم الزائر، الجهة المستضيفة، المناطق) — دول مش موجودين على الجهاز لأن الوثيقة قالت "دون عرض أي بيانات شخصية". فهما بيتضافوا في النظام المركزي بعد المزامنة، عن طريق الربط برقم البطاقة. والوثيقة فعلًا بتقول كده: "تتم معالجة البيانات وربط كل بطاقة بالزائر المرتبط بها". يعني الجهاز بيبعت (رقم بطاقة + بوابة + جهاز + وقت + نوع حركة)، والنظام بيكمّل الباقي. كويس — بس لازم تتوصّف كده صراحةً عشان محدش يفهمها غلط.

السؤال الأخطر في الوثيقة كلها: المزامنة بتحصل امتى؟

الوثيقة قالت "عند إجراء المزامنة" و"مزامنة الأجهزة" — ومحددتش أبدًا التوقيت ولا الآلية. وفي قسم 21 (الشبكة) كاتبة "Devices → System: Real-time Data Sync" وفي قسم 19.5 كاتبة "Devices Communication: Real-time synchronized". ده يتعارض مع Offline Mode!

ومخطط الـ HLD (قسم 15) بيوضّح إن الأجهزة موصولة بالكمبيوتر عن طريق USB، والكمبيوتر هو اللي موصول بالشبكة. يعني المزامنة يدوية — حد لازم يوصّل الجهاز بالكمبيوتر.

الثلاثة مش متسقين. ولازم يتحدد بالظبط: Real-time؟ كل ساعة؟ يدوي بالـ USB في بداية ونهاية الوردية؟ الإجابة دي بتغيّر التصميم كله، وبتغيّر الفجوة الأمنية في حالة "بدل مفقود".

13الإشعارات العادية — 12 إشعار

الوثيقة فصّلت لكل إشعار: مين بياخده وإيه محتواه. ده كويس جدًا لأنه بيوفّر شغل تصميم كتير.

#	الحدث	بيروح لمين	المحتوى
13.1	عند تقديم الطلب	مدير الإدارة	رقم الطلب · نوع الطلب · اسم مقدّم الطلب · تاريخ التقديم
13.2	عند الموافقة	مدير قسم التصاريح (+ الاستخبارات لو مطلوب)	رقم الطلب · نوع الطلب · الحالة: قيد التذكية الأمنية · الجهة الحالية: إدارة الاستخبارات
13.3	عند رفض الطلب	مقدّم الطلب (الإدارة)	حالة الطلب (مرفوض) · سبب الرفض بشكل واضح
13.4	عند جاهزية التصريح	الإدارة المعنية	التصريح جاهز للاستلام
13.5أ	عند إلغاء التصريح	مدير قسم التصاريح	سبب الإلغاء · تاريخ الإلغاء
13.5ب	عند تجميد التصريح	مدير قسم التصاريح	سبب التجميد · مدة التجميد · تاريخ التجميد
13.6	عند إعادة تفعيل التصريح	الإدارة المعنية	تم إعادة التفعيل · تاريخ التفعيل
13.7	عند الموافقة على طلب زيارة	الجهة المستضيفة	اسم الزائر · رقم الهوية · وقت الدخول والخروج · المناطق المسموح بها
13.8	عند رفض طلب زيارة	مقدّم الطلب	حالة الطلب (مرفوض) · سبب الرفض
13.9	عند قرب انتهاء الزيارة	الجهة المستضيفة	تنبيه قبل الانتهاء بمدة محددة
13.10	عند انتهاء الزيارة	—	انتهاء الصلاحية · تحديث الحالة إلى (منتهية)
13.11	عند تمديد الزيارة	مدير قسم التصاريح + المناوب (لو زيارة سكن)، وبعد الموافقة → الجهة المستضيفة	تاريخ الانتهاء الجديد · مدة التمديد
13.12	عند رفض التمديد	مقدّم الطلب	سبب الرفض

القنوات

الوثيقة حددت قناتين:

داخل النظام (In-App) — أساسية.
الإيميل (Email) — "كمقترح" — يعني لسه مش متأكدين.

ملاحظات على الإشعارات

مفيش SMS — رغم إن رقم الجوال بيتاخد إلزامي من كل زائر! الزائر مش هيدخل على النظام يشوف إشعاراته. لو عايز تقوله "زيارتك اتوافق عليها" هتبعتله إزاي؟
13.10 ما حددتش المستلم — "يتم إرسال إشعار" لمين؟
مفيش تنبيه للمنتسب إن تصريحه قرّب ينتهي — بس فيه واحد ذكي (14.4) بيروح للإدارة ومدير التصاريح.
الترقيم في الوثيقة فيه غلط — في 5.13 مرتين (إلغاء وتجميد)، وقسم 14 فيه 15.14 بين 14.14 و 15.14. حاجة شكلية بس بتقلّل احترافية الوثيقة.

14الإشعارات الذكية (AI) — 15 نوع

ده القسم اللي بيميّز النظام ده عن أي نظام تصاريح عادي. وهو كمان القسم اللي فيه أكبر مخاطرة تنفيذية، لأن كل تنبيه فيهم محتاج داتا تاريخية وموديل ومعايرة.

#	التنبيه	الحالة اللي بتشغّله	لمين	مثال عملي
14.1	سلوك غير طبيعي Anomaly Detection	دخول شخص منطقة غير مصرّح بها · دخول نفس الشخص بشكل متكرر خلال فترة قصيرة	مدير قسم التصاريح	الرقيب فهد دخل وخرج من البوابة الغربية 9 مرات في ساعتين. غير طبيعي — يستحق نظرة.
14.2	ازدحام البوابات Crowd Detection	ارتفاع عدد الدخول والخروج في بوابة معيّنة	مدير قسم التصاريح	البوابة الشمالية 7:15ص: 340 حركة في 15 دقيقة. مستوى الازدحام: عالي. افتح بوابة تانية.
14.3	تجاوز الصلاحيات Access Violation	محاولة استخدام تصريح ملغى أو مجمّد	مدير قسم التصاريح	حد حاول يستخدم `PRM-88214` — الكارنيه اللي أبلغ عن فقدانه من 3 أيام. تنبيه أمني فوري.
14.4	انتهاء تصاريح حرجة Risk Alert	تصاريح حسّاسة (بناءً على الرتبة) توشك على الانتهاء · تصاريح مؤقتة لمتعاقدين في مواقع حسّاسة	الإدارة المعنية + مدير قسم التصاريح	7 تصاريح متعاقدين في منطقة المدرج بتنتهي خلال 5 أيام. مستوى الخطورة: عالي.
14.5	أنماط الزيارات Visitor Behavior Pattern	زائر يتكرر دخوله بشكل غير طبيعي · زيارات لنفس الشخص بشكل متقارب	مدير قسم التصاريح	نفس الزائر زار 11 مرة في شهر، دايمًا لنفس الشخص. ممكن يكون طبيعي (مورّد)، وممكن يستحق سؤال.
14.6	التوقعات المستقبلية Predictive Alerts	توقّع ازدحام في يوم/وقت محدد · توقّع زيادة الطلبات	مدير قسم التصاريح	"متوقّع ازدحام الخميس 7:00–8:00ص بنسبة 82% — استعد."
14.7	التأخير في المعالجة SLA Breach	طلب متأخر عند: الاستخبارات · مدير الإدارة · أي مرحلة	مدير قسم التصاريح	الطلب `REQ-2026-001847` قاعد عند مدير إدارة الصيانة 6 أيام. الـ SLA المتوقع: يومين.
14.8	كثرة الرفض Rejection Pattern	جهة معينة لديها معدل رفض عالي · نوع طلب يتم رفضه بشكل متكرر	الإدارة العليا	إدارة اللوجستيات: 34% من طلباتها مرفوضة (المتوسط 6%). يا إما بيملوا غلط، يا إما في مشكلة تانية.
14.10	تصاريح غير نشطة Inactive Permit	تصريح لم يتم استخدامه لفترة طويلة	مدير قسم التصاريح	41 تصريح ما اتستخدمش من 6 شهور. تصاريح شغّالة بلا صاحب = خطر أمني. راجعها.
14.11	مقارنة أداء الوحدات Zone Performance	وحدة لديها: تأخير عالي · طلبات أعلى من المعدل · نسبة رفض غير طبيعية	مدير قسم التصاريح + الإدارة العليا	القاعدة الشرقية: متوسط معالجة 5.2 يوم مقابل 1.8 يوم في باقي الوحدات.
14.12	توقّع الضغط على الوحدات Zone Prediction	توقّع ازدحام في وحدة معيّنة خلال وقت محدد	مدير قسم التصاريح	ومعاه توصية: "زيادة أفراد / فتح بوابات". لاحظ إن ده التنبيه الوحيد اللي بيدّي توصية.
14.13	استهلاك غير طبيعي للأحبار Ink Consumption Anomaly	استهلاك أعلى من المتوقع مقارنة بعدد التصاريح المطبوعة · اختلاف كبير بين الوحدات	مدير قسم التصاريح	الوحدة الجنوبية طبعت 80 تصريح واستهلكت حبر يكفي 200. نسبة الانحراف +150%.
14.14	فقد/هدر في الكروت Card Waste	طلب كروت أكثر من المستخدم فعليًا · فرق بين الكروت المصروفة والمطبوعة	مدير قسم التصاريح	مصروف 500 كارت، مطبوع 310 تصريح. نسبة الهدر 38%. فين الـ 190؟
14.15	كفاءة الطباعة Printing Efficiency	وحدة تطبع نفس عدد التصاريح لكن تستهلك حبر أكتر من الطبيعي أو من باقي الوحدات	مدير قسم التصاريح	مقارنة معيارية بين الوحدات. ممكن السبب إعدادات طباعة غلط أو طابعة عايزة صيانة.

ملاحظة على الترقيم

الوثيقة فيها 14.1 → 14.8 بعدين قفزت لـ 14.10. مفيش 14.9. يا إما اتشالت يا إما اتنسيت. ولاحظ كمان إن اللي بعد 14.14 مكتوب "15.14" بدل "14.15". أخطاء ترقيم بس بتخلي المراجعة صعبة.

أكبر مخاطرة في المشروع كله موجودة هنا

الـ 15 تنبيه دول مش نوع واحد. لو بصيت كويس هتلاقيهم تلات فئات مختلفة تمامًا في الصعوبة:

1. قواعد بسيطة (سهلة)

14.3 (تصريح ملغي)، 14.4 (قرب الانتهاء)، 14.7 (SLA)، 14.10 (غير نشط). دول مش AI أصلًا — دول استعلامات SQL وIF. ممكن تتعمل في أسبوع.

2. إحصاء ومقارنة (متوسطة)

14.2، 14.8، 14.11، 14.13، 14.14، 14.15. دول محتاجين متوسطات وانحرافات معيارية. برضه مش AI — دي تحليلات. محتاجة داتا تاريخية عشان تعرف "الطبيعي" إيه.

3. تعلّم آلة حقيقي (صعبة)

14.1 (كشف الشذوذ)، 14.5 (أنماط الزوار)، 14.6 و 14.12 (التنبؤ). دول محتاجين موديلات، وداتا تدريب، ومعايرة، ومتابعة مستمرة.

المشكلة

عند الإطلاق (Day 1) مفيش داتا تاريخية خالص. الفئة 2 و3 مش هيشتغلوا. النظام محتاج 3–6 شهور تشغيل فعلي قبل ما التنبيهات دي يكون ليها معنى.

التوصية: اتفق مع العميل من دلوقتي على تسليم الـ AI على مراحل: المرحلة 1 = القواعد البسيطة مع الإطلاق. المرحلة 2 = التحليلات بعد 3 شهور. المرحلة 3 = التنبؤ بعد 6 شهور. لو اتوعدت بالـ 15 كلهم يوم الإطلاق، هتقع.

وحاجة تانية: إجهاد التنبيهات (Alert Fatigue)

مدير قسم التصاريح بياخد 12 نوع من الـ 15. لو كل واحد بيطلّع كذا تنبيه في اليوم، الراجل هيبطّل يبصّ عليهم خالص بعد أسبوعين. لازم يكون في:

عتبات (Thresholds) قابلة للتعديل لكل تنبيه.
تجميع (Grouping) — مش 41 إشعار لـ 41 تصريح غير نشط، لأ: إشعار واحد "41 تصريح غير نشط".
تصنيف بالخطورة — الحرج بس هو اللي يقاطع الراجل.
لوحة تحكّم (Dashboard) بدل الإشعارات للحاجات الدورية.

15التصميم عالي المستوى (High Level Design)

مخطط التصميم عالي المستوى — مخطط الـ HLD كما في الوثيقة (صفحة 30).

قراءة المخطط

على الشمال: Permit System User و Permit Printer — الاتنين بيوصلوا على HTTPS.
في النص: Load Balancer بيوزّع على سيرفرين: PERMITSRVAPP01 و PERMITSRVAPP02.
فوق يمين: Centralized Database (SQL) وجنبه Database.back — النسخة الاحتياطية. الاتصال على TCP 1433.
فوق شمال: ERP API على HTTPS 443.
تحت: ZONE-1 و ZONE-2، كل واحدة فيها Gate-1 و Gate-2، وكل بوابة فيها كمبيوتر، وتحت الكمبيوتر أجهزة Honeywell موصولة بـ USB.

تلات ملاحظات مهمة على المخطط

الأجهزة موصولة USB — مش شبكة. ده أهم اكتشاف في المخطط. يعني المزامنة يدوية: حد لازم يحطّ الجهاز في الكرادل الموصول بالكمبيوتر. ده يتعارض مع "Real-time Data Sync" اللي في قسم 21. لازم يتحسم.
غلط إملائي في المخطط: مكتوب Batabase.back بدل Database.back. وكمان مكتوب HTTPS 433 في تلات أماكن بدل 443. أخطاء شكلية بس في وثيقة معتمدة عسكريًا لازم تتصلّح.
مفيش Firewall ولا DMZ في المخطط رغم إن ده نظام عسكري وفيه تكامل مع نظام خارجي (ERP). ولا فيه سيرفر الـ AI/Intelligence المذكور في قسم 19.2. المخطط ناقص طبقات.

16-17التقارير والذكاء الاصطناعي

قسمين قصيرين جدًا في الوثيقة.

16 · التقارير

تلات فئات بس: الطلبات · الدخول والخروج · تقارير أمنية. مفيش تفصيل لأي تقرير.

17 · الذكاء الاصطناعي

تلات نقط: تحليل الأداء · كشف الأنماط · KPI. برضه بلا تفصيل — التفصيل الحقيقي في قسم 14.

القسمين دول محتاجين شغل

"تقارير أمنية" مش متطلّب. لازم تتحدد: كل تقرير اسمه إيه، فيه أعمدة إيه، فلاتره إيه، مين له صلاحية يشوفه، وهل بيتصدّر PDF/Excel. من غير كده، وقت التسليم كل واحد هيكون فاهم حاجة.

18معمارية النظام — خمس طبقات

الطبقة	مسؤولة عن إيه	في المشروع ده
Presentation Layer	الشاشات اللي المستخدم بيشوفها	واجهة ويب على HTTPS + طابعات مخصصة للكروت
Application Layer	منطق الشغل والـ Workflow	السيرفرين `PERMITSRVAPP01/02` على IIS 10
Integration Layer	الكلام مع الأنظمة الخارجية	ERP API + Intelligence API — كلهم HTTPS
Data Layer	تخزين الداتا	SQL Server مركزي + Backup + Audit Logs
Security Layer	الحماية عبر كل الطبقات	MFA + RBAC + تشفير + تسجيل عمليات

18.1 وصف المعمارية (نص الوثيقة)

"يوضح هذا المخطط البنية التحتية لنظام التصاريح الموحد، والذي تم تصميمه وفق نموذج معماري متعدد الطبقات يحقق الاعتمادية العالية، والأداء، والأمان. يتم تقديم الخدمات عبر بيئة مركزية تدعم توزيع الأحمال، والتكامل مع الأنظمة الخارجية، وربط الأجهزة الميدانية داخل القواعد الجوية."

المكوّنات بالتفصيل

واجهة المستخدم

وصول عبر ويب آمن بـ HTTPS، مع طابعات مخصصة لطباعة التصاريح بعد إصدارها.

موزّع الأحمال (Load Balancer)

يضمن: استمرارية الخدمة (HA) · تحسين الأداء · منع تحميل سيرفر واحد.

خوادم التطبيق

سيرفرين. بيعملوا: معالجة طلبات التصاريح · تنفيذ الـ Workflow · إدارة العمليات · الربط مع الأنظمة الأخرى.

قاعدة البيانات المركزية

SQL Server. بتخزّن: كل بيانات التصاريح · بيانات المستخدمين · الـ Audit Logs. مع نظام نسخ احتياطي.

التكامل مع ERP

عبر واجهات API آمنة بـ HTTPS: جلب بيانات المنسوبين + تحديث تلقائي.

أجهزة البوابات

إرسال بيانات التصاريح للأجهزة · التحقق عند نقاط الدخول/الخروج · تسجيل الحركة · إرسالها للنظام. الاتصال HTTPS.

آلية عمل النظام (High-Level Flow) — 6 خطوات

يقوم المستخدم بتقديم طلب تصريح عبر النظام.
يتم معالجة الطلب عبر خوادم التطبيق.
يتم تخزين البيانات في قاعدة البيانات المركزية.
يتم التحقق من البيانات.
بعد إصدار التصريح: يتم طباعته · يتم توليد باركود فريد · يتم إرسال بياناته إلى أجهزة البوابات.
عند البوابة، يتم التحقق من التصريح باستخدام أجهزة القراءة.

خصائص المعمارية

التوفّر العالي (High Availability) عبر Load Balancer
الأمان باستخدام بروتوكولات اتصال مشفّرة (HTTPS)
قابلية التوسّع (Scalability)
دعم الأجهزة الميدانية والتحقق اللحظي

تناقض في ترقيم الوثيقة

الوثيقة عندها قسم رقم 18 اسمه "معمارية النظام"، وجواه أقسام فرعية مرقّمة 16.2، 16.2.1، 16.2.2… — يعني الترقيم الداخلي بيقول 16 والعنوان بيقول 18. وكمان في قسمين رقمهم 17 (الذكاء الاصطناعي، وآلية عمل النظام) وقسمين رقمهم 18. الوثيقة محتاجة مراجعة ترقيم كاملة.

19البنية التحتية (Infrastructure)

19.1 بيئة الإنتاج

Server	Role	CPU	RAM	Storage
Permit-App01	App	16 vCPU	32 GB	500 GB
Permit-App02	App	16 vCPU	32 GB	500 GB
Permit-DB	DB	16-32 vCPU	32 GB	1 TB

تلات مشاكل هنا

سيرفر قاعدة بيانات واحد بس — رغم إن قسم 19.5 بيقول "SQL Cluster / Always-On"، والـ Always-On محتاج على الأقل سيرفرين. فالجدول ده متعارض مع نفسه.
32 GB RAM لسيرفر SQL شايل تصاريح + Audit Logs + كل حركات الدخول والخروج + بيانات تحليل AI… ده قليل. الحركات دي بتكبر بسرعة رهيبة (تخيّل 5000 شخص × دخول وخروج يوميًا = 3.6 مليون سجل في السنة).
مفيش سيرفر منفصل للـ AI رغم إن قسم 19.2 بيذكر "Integration Server: Analytics Engine + Machine Learning Processing". يعني السيرفر ده مذكور في جدول ومش موجود في جدول تاني.

وكمان مفيش بيئة اختبار (Test/Staging) ولا تطوير خالص. ده مش اختياري لنظام بالحجم ده — هتختبر التحديثات فين؟ على الإنتاج؟

19.2 متطلبات السيرفرات

المكوّن	التفاصيل
Web Servers	IIS 10 + Load Balanced
Application Servers	2 Servers (PERMITSRVAPP01 / PERMITSRVAPP02) — Workflow Processing + API Services
Database Server	SQL Server 2019+ — Centralized Database + Always-On
Integration Server	ERP API + Intelligence API (HTTPS) — Analytics Engine + ML Processing

19.3 نظام التشغيل

OS	Windows Server 2022
Compatibility	يدعم IIS / SQL Server / API Services
Security	Hardened OS Configuration

19.4 التخزين

Storage Type	SAN (Enterprise Storage)
Disk Type	SSD
RAID Level	RAID 10
Database Storage	High IOPS Storage
Backup Storage	Separate Storage Volume

RAID 10 اختيار صح لقاعدة بيانات — بيجمع بين السرعة والحماية (Mirroring + Striping). وفصل تخزين الـ Backup عن تخزين الداتا صح كمان.

19.5 التوفّر العالي

الطبقة	الآلية
Web Layer	Load Balancer (Active-Active)
Application Layer	Active-Active (2 Servers)
Database Layer	SQL Cluster / Always-On
Network	Redundant Paths
Devices Communication	Real-time synchronized

19.6 استراتيجية النسخ الاحتياطي

النوع	التفاصيل	قراءتي
Full Backup	Weekly	أسبوعي مقبول مع وجود Incremental
Incremental / Logs	Every 15 Minutes	ممتاز — ده معناه إن أقصى فقدان داتا = 15 دقيقة
Storage	Offsite + Onsite	صح — نسخة برّه الموقع تحمي من الكوارث المادية
Recovery Test	Scheduled DR Testing	أهم بند — Backup ما اتجربش = مفيش Backup

تناقض صارخ: الـ Backup vs الـ RPO

النسخ الاحتياطي التزايدي كل 15 دقيقة. طيب قسم 22 (التعافي من الكوارث) بيقول RPO = 24 ساعة.

الرقمين دول مالهمش أي علاقة ببعض. لو بتاخد Log Backup كل ربع ساعة، الـ RPO المفروض يكون 15 دقيقة مش 24 ساعة. يا إما الـ RPO مكتوب غلط، يا إما الـ DR Site بيتزامن مرة في اليوم بس. لازم يتحدد بالظبط — لأن الفرق بين "خسرنا ربع ساعة شغل" و"خسرنا يوم كامل" فرق هائل في منشأة عسكرية.

20الأمن (Security)

المجال	التفاصيل	يعني إيه
Authentication	Multi-Factor Authentication (MFA)	مش كلمة سر بس — لازم عامل تاني (OTP، توكن، بصمة). صح تمامًا لنظام عسكري.
Authentication	Role-Based Access Control (RBAC)	غلط في التصنيف — RBAC ده Authorization مش Authentication. الفرق: Authentication = "إنت مين؟"، Authorization = "إنت مسموحلك تعمل إيه؟". خطأ شكلي بس بيوضّح إن القسم مكتوب على السريع.
Encryption	Data in Transit (HTTPS) + Data at Rest	تشفير أثناء النقل وأثناء التخزين. الـ at Rest يتعمل بـ SQL Server TDE.
Monitoring	Audit Logs	مذكور برضه في القواعد التشغيلية. لازم يشمل قراءة + كتابة + محاولات الدخول الفاشلة.
API Security	Secure Tokens / Certificates	لتأمين الكلام مع الـ ERP والأجهزة.
Devices Security	Encrypted Communication (Honeywell)	الكلام مع الأجهزة مشفّر.

حاجات أمنية ناقصة في نظام عسكري

مفيش سياسة كلمات سر (طول، تعقيد، انتهاء).
مفيش قفل حساب بعد محاولات فاشلة.
مفيش إدارة الجلسات (Session timeout).
مفيش فصل شبكي — النظام على شبكة القاعدة المغلقة ولا على الإنترنت؟ ده يغيّر كل حاجة.
مفيش اختبار اختراق (Penetration Testing) كمتطلّب تسليم.
مفيش تصنيف بيانات — أنهي بيانات "سري" وأنهي "مقيّد"؟ في السياق العسكري ده أساسي.
مفيش ذكر لـ SIEM أو ربط الـ Audit Logs بنظام مراقبة أمني مركزي.
مفيش إدارة الحسابات المميزة (Privileged Access) — مين عنده SA على الداتابيز؟

21الشبكة (Network Connectivity)

المسار	المنفذ	ملاحظة
User → Load Balancer	HTTPS 443	صح
Load Balancer → App Servers	HTTPS 443	تشفير حتى جوّه الشبكة — كويس
App → Database	TCP 1433	البورت الافتراضي لـ SQL Server. توصية أمنية: غيّره لبورت غير قياسي.
App → ERP	HTTPS 443	صح
App → Intelligence	HTTPS 443	"Intelligence" هنا = سيرفر التحليلات، مش إدارة الاستخبارات
Core → Devices (Zones)	HTTPS 443	ده اللي بينزّل التصاريح على الأجهزة
Devices → System	Real-time Data Sync	مش بورت — ده وصف مش مواصفة. وبيتعارض مع الـ USB في الـ HLD وبيتعارض مع Offline Mode.

22التعافي من الكوارث (Disaster Recovery)

العنصر	القيمة	يعني إيه
Availability	99.9%	≈ 8 ساعات و45 دقيقة انقطاع مسموح سنويًا
RTO	6 ساعات	Recovery Time Objective = أقصى وقت مسموح النظام يفضل واقع فيه قبل ما يرجع
RPO	24 ساعة	Recovery Point Objective = أقصى كمية داتا مسموح تضيع (بالوقت)
DR Site	Secondary Data Center	مركز بيانات تاني
Replication	Database Replication	نسخ مستمر للداتابيز

RTO 6 ساعات لا يستقيم مع 99.9%

لو الـ SLA بتاعك 99.9%، يعني عندك 8.7 ساعة انقطاع مسموح في السنة كلها. طيب لو حصلت كارثة واحدة والـ RTO 6 ساعات، تكون خلاص أكلت 69% من ميزانية الانقطاع السنوية في حادثة واحدة.

ده مش تناقض مستحيل، بس معناه إن مفيش هامش. لو حصلت كارثتين في السنة، خرجت عن الـ SLA. يا إما تنزّل الـ RTO لساعة أو اتنين، يا إما تعترف إن الـ 99.9% دي طموح مش التزام.

وقلنا فوق: RPO = 24 ساعة يتعارض مع Log Backup كل 15 دقيقة. الجدولين محتاجين توحيد.

23المخاطر (Risks)

الخطر	التأثير	المعالجة	قراءتي
فشل التكامل مع ERP	تعطيل البيانات	Retry + Monitoring	ناقص: Fallback. لو الـ ERP وقع يومين، النظام يقف؟ لازم Cache محلي للبيانات الأساسية.
فقدان البيانات	عالي	Backup + DR	مغطّى — بس شوف تناقض الـ RPO فوق.
هجمات أمنية	عالي جدًا	MFA + Encryption + Logs	دي إجراءات وقاية بس. ناقص خطة استجابة للحوادث (Incident Response) — لو الاختراق حصل فعلًا نعمل إيه؟
ازدحام النظام	متوسط	Load Balancer + Scaling	معقول. بس "Scaling" على Windows Server تقليدي مش سهل — محتاج توضيح.
عدم مزامنة أجهزة Honeywell	متوسط	Failover + Alerts	التقييم غلط. التأثير مش متوسط — جهاز مش متزامن معناه إن كارنيه ملغي لسه شغّال على البوابة. ده خطر أمني عالي.
جودة البيانات	متوسط	Validation + AI Monitoring	مرتبط بالإدخال اليدوي اللي اتكلمنا عنه في 4.1.

مخاطر مش موجودة في القائمة

مقاومة التغيير — ضباط اتعوّدوا على الورق 20 سنة. ده أكبر سبب لفشل مشاريع الأتمتة، ومش مذكور.
عدم توفر بيانات كافية للـ AI — أكبر مخاطرة في المشروع (شرحناها في قسم 14) ومش في الجدول.
الاعتماد على مورّد واحد — Honeywell. لو غيّروا الـ API أو وقّفوا الموديل؟
تأخر الاستخبارات — دي جهة خارج سيطرة المشروع. لو قعدوا أسبوع على كل طلب، الأهداف كلها تقع.
عدم جاهزية الشبكة في القواعد — الأجهزة في البوابات محتاجة بنية شبكية.

24-25الخاتمة والاعتمادات

الخاتمة بتلخّص إن النظام "لا يقتصر فقط على كونه أداة لإدارة التصاريح، بل يمثل منصة تشغيل ذكية متكاملة تدعم القيادة في: تعزيز الأمن · تحسين الكفاءة · تمكين التحليل الذكي · دعم اتخاذ القرار."

وقسم الاعتمادات فيه خانتين توقيع:

شركة مدينة الأعمال المحدودة

ممثل الشركة — صفته: مدير المشروع
التوقيع: ______ · التاريخ: ______

قيادة القوات الجوية الملكية السعودية

الاسم — صفته: مدير المشروع بقسم التصاريح
التوقيع: ______ · التاريخ: ______

"بموجب التوقيع أدناه، يقر الأطراف المعنيون بمراجعة محتوى الوثيقة والموافقة عليها، والالتزام بما ورد فيها كأساس للتنفيذ."

دي النقطة القانونية المهمة

لحظة ما التوقيعين دول ينزلوا، الوثيقة دي بتبقى الأساس التعاقدي للتنفيذ. يعني كل ثغرة وكل تناقض ذكرناهم فوق هيبقى تكلفتهم "طلب تغيير" (Change Request) — بمفاوضة وسعر ووقت إضافي. عشان كده الوقت الوحيد المناسب لتصليحهم هو قبل التوقيع.

★قراءتي: أهم الثغرات والأسئلة الواجب سؤالها

لو هتقعد اجتماع مراجعة على الوثيقة دي، دي الأسئلة اللي أنا كنت هسألها بالترتيب.

الفئة الأولى — تناقضات لازم تتحل قبل التوقيع

#	التناقض	السؤال
1	الأجهزة Offline (قسم 12) مقابل Real-time Sync (قسم 19.5 و 21) مقابل USB (مخطط الـ HLD)	المزامنة بتحصل امتى وإزاي بالظبط؟ وإيه أقصى فجوة زمنية بين إلغاء تصريح ونزول الإلغاء على الأجهزة؟
2	RPO = 24 ساعة مقابل Log Backup كل 15 دقيقة	أنهي رقم هو الالتزام الفعلي؟
3	RTO = 6 ساعات مقابل 99.9% توفّر	إحنا ملتزمين بأنهي واحد فيهم لما يتعارضوا؟
4	سيرفر DB واحد مقابل SQL Always-On	عدد سيرفرات الداتابيز كام فعليًا؟
5	حالة Returned موجودة في الجدول ومش موجودة في أي مخطط	الإرجاع للتعديل شغّال من أنهي محطات؟ وبيرجع لمين؟
6	القاعدة 3 (القواعد التشغيلية) ما فيهاش الجنسية، وقسم 4.7 فيها	معيار التذكية الأمنية النهائي إيه بالظبط؟

الفئة الثانية — متطلبات ناقصة

مين هو "مدير النظام"؟ مين بيضيف مستخدمين، يعرّف المناطق والبوابات، يظبط عتبات التنبيهات والـ SLA؟
دورين مش معرّفين: "المناوب" و"منظّم المناسبة" ظهروا في جدول الزوار ومش في جدول أصحاب المصلحة.
فكّ التجميد مالوش شاشة موصوفة رغم إن ليه إشعار.
حالة Expired مش في دورة الحياة رغم إن كل التصاريح المؤقتة والزيارات ليها تاريخ انتهاء.
مواصفة التقارير — تلات كلمات مش كفاية.
مواصفة الشاشات (Mockups) — مفيش ولا شاشة واحدة في 41 صفحة.
سياسة الاحتفاظ بالبيانات — التصاريح الملغية والحركات القديمة تفضل قد إيه.
اللغة والمتصفحات المدعومة.
مواصفة الباركود — نوعه (Code128? QR? Data Matrix?)، طوله، هل فيه Checksum، وهل بيتشفّر.
مواصفة الكارنيه المطبوع — شكله، إيه المطبوع عليه، عناصر الأمان (هولوجرام؟)، نوع الطابعة.
بيئات التطوير والاختبار.
خطة الترحيل (Migration) — التصاريح الشغّالة حاليًا هتدخل النظام إزاي؟ ده مشروع لوحده.
التدريب والدعم بعد الإطلاق.

الفئة الثالثة — مخاطر تجارية على المنفّذ

اللي هيوجعك في التنفيذ

الـ 15 تنبيه ذكي. الوثيقة بتوصفهم كأنهم فيتشرات عادية. نصّهم مستحيل يشتغل صح من غير 3–6 شهور داتا. اتفق على تسليم مرحلي مكتوب.
تكامل Honeywell. ما فيش أي مواصفة فنية للأجهزة — الموديل إيه، الـ SDK إيه، بيدعم كام كارت، الذاكرة قد إيه. لو الأجهزة موجودة أصلًا في القاعدة، لازم تشوفها بنفسك قبل التسعير.
تكامل Oracle ERP. ما فيش عقد API. والتكامل مع أنظمة الـ ERP في الجهات الحكومية دايمًا بياخد وقت أطول من المتوقع بمرتين على الأقل، لأن الوصول للنظام نفسه بياخد موافقات.
الاستخبارات. جهة خارج سيطرتك بتقعد في نص الـ Workflow. لازم يكون فيه SLA متفق عليه معاهم، وإلا هيتحسب التأخير عليك.
"دعم آلاف المستخدمين" بلا رقم. ده بند مفتوح ممكن يتفسّر بعدين بأي شكل.

▣لو هتبنيه: خريطة الداتا المقترحة

ده مش في الوثيقة — ده استنتاجي من قراءتها. لو هتبدأ تصميم قاعدة البيانات، دي الكيانات اللي الوثيقة بتفرضها.

الكيان	الغرض	مصدره في الوثيقة
Personnel	بيانات المنتسبين (مرآة من الـ ERP)	قسم 12.1
Visitor	بيانات الزوار	قسم 4.4
Vehicle	بيانات المركبات المرتبطة بالزوار	قسم 4.4
Unit	الوحدات / القواعد	قسم 4.2 ("تحديث المناطق بناءً على الوحدة")
Zone	المناطق داخل كل وحدة	قسم 3.2 ("متابعة الكميات لكل وحدة (Zone)")
Gate	البوابات داخل كل منطقة	مخطط HLD (Gate-1, Gate-2)
Device	أجهزة القراءة المرتبطة بكل بوابة	مخطط HLD + قسم 12.2 (حقل "جهاز القراءة")
RequestType	أنواع الطلبات الـ 13 وقواعد كل نوع	قسم 4 كامل
Request	الطلب نفسه برقم تتبّع وحالة	قسم 5.3 + القواعد التشغيلية
RequestAttachment	المرفقات (إلزامية حسب النوع)	القاعدة التشغيلية 2
WorkflowStep	محطات الموافقة وقرار كل محطة	قسم 5.1 و 5.2
Permit	التصريح: باركود، تواريخ، حالة	قسم 7 + 12.1
PermitZone	المناطق المصرّح بها لكل تصريح (many-to-many)	قسم 4.1 و 4.2
VisitorCard	الكروت المعرّفة مسبقًا وحالة إسنادها	قسم 12.2
AccessLog	حركات الدخول والخروج (8 حقول)	قسم 12.2
InventoryItem	الأحبار والكروت	قسم 3.2 و 4.6
InventoryTransaction	الصرف والتوريد لكل وحدة	قسم 3.2
MaterialRequest	طلبات المواد من الوحدات	قسم 4.6
Notification	الإشعارات (12 عادي + 15 ذكي)	قسم 13 و 14
AlertRule	عتبات وقواعد التنبيهات الذكية	مستنتج من قسم 14
User / Role / Permission	المستخدمين والصلاحيات (RBAC)	قسم 10 و 20
AuditLog	سجل كل العمليات	القاعدة التشغيلية 4 + قسم 20

أهم علاقة في التصميم كله

Unit → Zone → Gate → Device

التسلسل ده هو اللي بيخلي جملة "تحديث المناطق بناءً على الوحدة" (قسم 4.2) تشتغل، وهو اللي بيخلي التنبيه "دخول شخص منطقة غير مصرّح بها" (14.1) ممكن أصلًا. لو التسلسل ده مش مظبوط من الأول، نص المتطلبات هتقع.

الشرح ده مبني بالكامل على وثيقة BRD #001 — نظام التصاريح الموحد، الإصدار 1.0، 17 مايو 2026 (41 صفحة). الاقتباسات المكتوبة بين علامتين تنصيص منقولة حرفيًا من الوثيقة. المخططات مأخوذة من صفحاتها الأصلية (11، 12، 13، 14، 30). الأقسام المعلّمة بـ «قراءتي» و«الثغرات» هي تحليل إضافي مش جزء من الوثيقة.