Qwizin — خط الأساس الموحّد للمتطلبات
الحالة: مسودة v0.1 · التاريخ: 2026-07-20 · القائد التقني: أمير هارون الغرض: المصدر المُقطَّر الوحيد للحقيقة المعمارية، مستخلَص من الوثائق المصدرية الاثنتي عشرة. كل وثيقة معمارية لاحقة تعود بالتتبّع إلى معرّف مُعرَّف هنا.
1. جرد الوثائق المصدرية#
| ID | الوثيقة | الحُجّية | الدور في خط الأساس هذا |
|---|---|---|---|
SRC-BRD |
Qwizin BRD V1.pdf (+ النسخة العربية V1) | مُلزِمة | النطاق الأساسي، الجهات الفاعلة، مصفوفة الأدوار، القيود |
SRC-MOM |
Minutes of meeting V01.0.pdf | مُلزِمة | تحليل محلل الأعمال (BA)، MoSCoW، المتطلبات غير الوظيفية (NFRs)، مصفوفة تتبّع المتطلبات (RTM) (REQ-01…06)، المخاطر |
SRC-UFC |
Qwizin User Flow Chart.pdf | مُلزِمة | رحلة الجهة الفاعلة من طرف إلى طرف |
SRC-DECK |
HPHQWIZIN APP-1.pdf | توجيهية | نموذج العمل، خارطة طريق المرحلة الثانية، التزامات أمام المستثمرين |
SRC-TRN |
Qwizin Training Portal.pdf | توجيهية | تصنيف التدريب وتوقعات لوحة المعلومات |
SRC-CNT |
نموذج SOP، سلامة الغذاء، HACCP Simplified، ثلاثة ملفات تدقيق .xlsx، نموذج الإجراء التصحيحي |
مرجعية | عيّنات محتوى — حمولة مكتبة القوالب، وليست مواصفات نظام |
ملاحظة معمارية على
SRC-CNT: كثيرًا ما يُظَن أن هذه الملفات الستة متطلبات. وهي ليست كذلك. إنها أصول تمثيلية لوحدة (module) القوالب. بنيتها مهمة لسبب واحد فقط: أن مصنّفات التدقيق عبارة عن قوائم تحقق منظّمة، بصف لكل ضابط، مع أعمدة لحالة الامتثال والشخص المسؤول. هذا الشكل إشارة قوية إلى أن "القالب القابل للتنزيل" هو صورة انتقالية لمرحلة الـ MVP لما سيصبح لاحقًا أداة تدقيق رقمية تفاعلية. انظرSEAM-03.
2. الجهات الفاعلة#
ستة أنواع من الجهات الفاعلة. لاحظ أن SRC-BRD §7.1 و§11 تعدّان ستة، بينما يقول SRC-MOM §6 "3 أنواع رئيسية من الحسابات (الأفراد، الشركات، مزوّدو الخدمة)". يُعتمد نموذج الجهات الفاعلة الست الوارد في BRD باعتباره المُلزِم؛ أما الثلاثة في MoM فهي تبسيط يُغفل الموظف (وهو نوع فرعي من الشركة)، والمستشار، ومسؤول المنصة.
| ID | الجهة الفاعلة | تسجيل ذاتي؟ | مشروط بالاعتماد؟ | ملاحظات |
|---|---|---|---|---|
ACT-IND |
فرد | نعم | لا | وصول فوري عند التحقق |
ACT-CO |
شركة (المستخدم المسؤول) | نعم | نعم | مستندات قانونية ← مراجعة مسؤول المنصة |
ACT-EMP |
موظف | لا — يُنشَأ بواسطة ACT-CO |
يرث حالة الشركة | لا يستطيع الشراء، ولا يرى ماليات الشركة |
ACT-CON |
مستشار | نعم | نعم | يحدّد التسعير + التوافر |
ACT-SP |
مزوّد خدمة | نعم | نعم | ظهوره في الدليل مشروط بالاشتراك |
ACT-ADM |
مسؤول المنصة | لا | لا ينطبق | مسؤول متعدد الأدوار (SRC-BRD §7.1) |
تبعية دورة حياة ACT-EMP: لا يمكن أن يوجد حساب موظف خارج شركة معتمَدة (SRC-BRD §12 القيد 10). وهذا يجعل تعليق الشركة أو رفضها تغيير حالة متسلسلًا (cascading) يمتد إلى جميع موظفيها، وتقييماتهم الجارية، وشهاداتهم الصادرة. هذه آلة حالات (state machine) غير بسيطة، وهي ناقصة التحديد في جميع الوثائق المصدرية ← OQ-07.
3. خريطة القدرات الوظيفية#
مجمَّعة في وحدات (modules) مرشَّحة. تصبح معرّفات MOD- هي تفكيك الكتل البنائية في عرض الكتل البنائية وفق arc42.
| الوحدة | القدرات | المصدر |
|---|---|---|
MOD-IAM |
التسجيل (بريد إلكتروني / هاتف / Google)، تسجيل الدخول، الملف الشخصي، نموذج الأدوار والصلاحيات، دورة حياة الجلسة/الرمز (token) | BRD §7.1، MOM FR-5 |
MOD-ONB |
رفع المستندات القانونية، طابور المراجعة لدى مسؤول المنصة، سير عمل الاعتماد / الرفض / إعادة التقديم، تفعيل الحساب | BRD §7.1، MOM FR-6 / REQ-02، UFC |
MOD-CONS |
دليل المستشارين وملفاتهم، التخصصات، إعداد التسعير، التوافر، الحجز، آلة حالات الموعد | BRD §7.1/§10.4، MOM FR-1/FR-2 |
MOD-VID |
دورة حياة جلسة الفيديو داخل التطبيق، رموز الانضمام، أحداث الجلسة، التسجيل (اختياري) | MOM FR-1 / REQ-03 |
MOD-TPL |
فهرس القوالب، التصنيفات، التنزيل المجاني، استقبال طلب القالب المخصّص وتنفيذه | BRD §7.1، MOM FR-3 / REQ-04 |
MOD-LRN |
المحتوى التعليمي، إسناد الشركة ← الموظف، تتبّع التقدّم | BRD §7.1، TRN |
MOD-ASMT |
تقديم التقييمات متعددة الخيارات (MCQ)، التصحيح الآلي، درجة نجاح قابلة للضبط، سجل المحاولات | BRD §7.1، MOM FR-4 / REQ-05 |
MOD-CERT |
التوليد الآلي للشهادات، التنزيل، السجل، التحقق | BRD §7.1، MOM REQ-05 |
MOD-MKT |
دليل المورّدين ومزوّدي الخدمة، البحث/التصفية، ترتيب الإدراج المميّز (featured) | BRD §7.1، MOM REQ-06 |
MOD-PAY |
دفع الاستشارات، دفع الطلبات المخصّصة، اشتراكات المزوّدين، شراء الإدراج المميّز، التحويلات للمزوّدين (payouts) | BRD §7.1/§9.3 |
MOD-ADM |
الاعتمادات، إدارة المحتوى، إدارة المزوّدين/المستشارين، مراقبة المدفوعات، التقارير، لوحة المعلومات | BRD §7.1، UFC |
MOD-NOTIF |
إشعارات البريد الإلكتروني والرسائل النصية (SMS) والدفع (push)؛ تذكيرات المواعيد | BRD §13 التبعيات 8/12/13، MOM "Could Have" |
4. خارج النطاق صراحةً (MVP)#
من SRC-BRD §7.2 وSRC-MOM §6/§14. مُوثَّق لأن المعمارية يجب ألا تسدّ الطريق أمامها، ولأن §5 أدناه تُبيّن أن اثنين منها متناقضان مع مواضع أخرى.
- نظام إدارة تعلّم (LMS) كامل: مسارات التعلّم، الفصول الافتراضية، الواجبات، تحليلات التعلّم
- التعلّم الإلكتروني القائم على الفيديو (مؤجَّل صراحةً لأسباب تتعلق بالتكلفة؛ قيد MoM §11)
- إدارة المخزون، المشتريات، أوامر الشراء، عقود المورّدين
- التكامل مع ERP / المحاسبة / CRM
- الأقسام داخل الشركات (BRD §10.2 — "تحسين مستقبلي")
5. ⚠ التناقضات والعيوب في الوثائق المصدرية#
هذه تتطلب حُكمًا من المعماري أو الجهة الراعية. كل بند منها عائق حاسم أو خطر حقيقي، وليس ملاحظة تحريرية شكلية.
CONF-01 — نطاق التدريب: BRD مقابل عرض بوابة التدريب#
يستثني SRC-BRD §7.2 وSRC-MOM §14 ("Won't Have") التعلّم الإلكتروني القائم على الفيديو، ومسارات التعلّم، وتحليلات التعلّم. بينما يحدّد SRC-TRN الفيديو كأسلوب تعلّم (ص. 12)، والتقييمات العملية (ص. 4)، ولوحة مقارنة بين الفروع، وتتبّع الدورات المتأخرة (ص. 13).
الأثر: مرتفع. محتوى التعلّم بالفيديو يغيّر جوهريًا معمارية التخزين وشبكة توزيع المحتوى (CDN) والترميز (transcoding). والتقييم العملي يستلزم سير عمل تصحيح بشري لا يغطيه التصحيح الآلي للأسئلة متعددة الخيارات. و"مقارنة الفروع" تستلزم تسلسلًا هرميًا من الشركة ← الفرع لا يملكه نموذج البيانات حاليًا (وقد أجّل BRD الأقسام).
الحكم المطلوب: هل SRC-TRN ضمن نطاق MVP، أم رؤية للمرحلة الثانية، أم تخطيط طموح من فريق المحتوى؟
CONF-02 — الدفع يسبق قبول المستشار#
سير عمل المواعيد في SRC-BRD §10.4: (1) العميل يحجز ← (2) العميل يدفع ← (3) المستشار يستلم الطلب ← (4) المستشار يوافق ← (5) النظام يؤكّد.
الأثر: مرتفع. تُحصَّل الأموال قبل الاتفاق على الخدمة. وهذا يفرض: الحجز على المبلغ ثم التحصيل (hold-then-capture) أو حجزًا كاملًا لدى طرف ثالث (escrow)، واسترداد تلقائي عند رفض المستشار، ومؤقّت انتهاء صلاحية للحجز في حال عدم استجابة المستشار، ومسارًا للنزاعات. ولا يرد أيٌّ من ذلك في أي وثيقة مصدرية.
الحكم المطلوب: تأكيد نمط hold-then-capture، وتحديد اتفاقية مستوى الخدمة (SLA) لاستجابة المستشار، وتحديد سياسة الاسترداد. يتقاطع مع OQ-01 (يجب أن تدعم بوابة الدفع الحجوزات والاستردادات).
CONF-03 — مصفوفة الأدوار والصلاحيات متناقضة داخليًا#
يمنح SRC-BRD §11 الجهة ACT-ADM صلاحيتَي "حجز استشارة" و"إدارة التوافر"، ويمنح ACT-SP صلاحيات "الوصول إلى التعلّم" و"أداء التقييمات" و"تنزيل الشهادات". كما يُظهر ACT-CON مع "رفع المستندات القانونية" بينما عمود الموظف فارغ فيما يخص إدارة الملف الشخصي ("محدودة").
التقييم: يبدو هذا أثرًا ناتجًا عن اختلال محاذاة الأعمدة في جدول ملف الـ PDF لا نيّةً مقصودة — إذ يبدو أن عمودَي "مزوّد الخدمة" و"مسؤول المنصة" اندمجا أثناء الاستخراج.
الأثر: حَرِج — فهذا الجدول هو المُدخَل المعتمَد لنموذج التخويل. والبناء على مصفوفة مختلّة المحاذاة يُنتج ثغرات صلاحيات حقيقية.
الحكم المطلوب: إعادة إصدار §11 كمصفوفة صلاحيات قابلة للفحص آليًا. ستُعرّف المعمارية التخويل انطلاقًا من مصفوفة مُصحَّحة؛ لا تُنفَّذ من ملف الـ PDF كما هو.
CONF-04 — التزامات المرحلة الثانية تتجاوز MVP بكثير#
تضع مصفوفة المنافسين في SRC-DECK ص. 12 علامة "YES" لـ Qwizin على: الحجوزات وإدارة الطاولات، وCRM وقاعدة بيانات الضيوف، والولاء والقسائم، وجدولة العمالة والرواتب، والمخزون والمشتريات، والتكامل مع POS/PMS، وتحليلات المشاعر، والتواصل B2B مع المورّدين، والطلب متعدد القنوات، والقائمة الرقمية، والتكامل الحكومي.
الأثر: هذه التزامات أمام المستثمرين. ليست ضمن MVP، لكنها تحدّد أين يجب أن تترك المعمارية نقاط فصل مستقبلية (seams). وتصميم الـ MVP كأن هذه الالتزامات غير موجودة هو السبب الأرجح لإعادة كتابة النظام في المرحلة الثانية.
الحكم المطلوب: لا شيء على الفور — لكن هذا هو سبب رسم حدود الـ modular monolith في MOD-* حيث رُسِمت.
CONF-05 — تعارضات في التواريخ#
SRC-BRD مؤرَّخ في 18/7/2026 وSRC-MOM في 14/07/2026 (وكلاهما متسق مع تاريخ اليوم، 2026-07-20). أما SRC-DECK فمؤرَّخ يوليو 2025 ويعرض خطة عمل: "البناء والاختبار سبتمبر 2025 ← الإطلاق أبريل 2026 ← الجهات الحكومية يناير 2027 ← المرحلة الثانية 2028".
الأثر: منخفض معماريًا، مرتفع من ناحية التخطيط. الجدول الزمني في العرض التقديمي قد انقضى فعليًا؛ و BRD/MoM يمثّلان البرنامج الحالي. تعامَل مع SRC-DECK باعتباره نيّة عمل، لا جدولًا زمنيًا.
6. الأسئلة المفتوحة#
طُرحت OQ-01–OQ-03 في SRC-MOM §15 ولا تزال دون إجابة. أما OQ-04 وما بعده فقد أثارها هذا التحليل.
| ID | السؤال | المصدر | معيق؟ |
|---|---|---|---|
OQ-01 |
أي بوابة دفع؟ يجب أن تدعم mada، والحجوزات/التحصيل، والاستردادات، وتحويلات السوق الإلكتروني (payouts) | MOM §15 | نعم — يعيق MOD-PAY |
OQ-02 |
القائمة الدقيقة للمستندات القانونية للتحقق من الشركة/المزوّد — السجل التجاري فقط، أم أيضًا الرخصة البلدية + شهادة سلامة الغذاء؟ | MOM §15 | نعم — يعيق نموذج بيانات MOD-ONB |
OQ-03 |
هل يدير المستشارون توافرهم ذاتيًا وديناميكيًا داخل التطبيق؟ | MOM §15 | نعم — يعيق تصميم الجدولة في MOD-CONS |
OQ-04 |
الحكم في CONF-01 (نطاق التدريب) |
هذا التحليل | نعم |
OQ-05 |
الحكم في CONF-02 (ترتيب الدفع/الاعتماد + سياسة الاسترداد) |
هذا التحليل | نعم |
OQ-06 |
مصفوفة الأدوار والصلاحيات المُصحَّحة (CONF-03) |
هذا التحليل | نعم |
OQ-07 |
تسلسل تعليق/رفض الشركة: ماذا يحدث لتقييمات الموظفين الجارية وللشهادات الصادرة بالفعل؟ | هذا التحليل | نعم |
OQ-08 |
هل تُسجَّل الاستشارات؟ يؤثر على التخزين والتكلفة والموافقة والتزامات نظام حماية البيانات الشخصية (PDPL) | هذا التحليل | نعم — يعيق تحديد أحجام MOD-VID |
OQ-09 |
هل تتطلب الشهادات قابلية تحقق من طرف ثالث (QR ← نقطة تحقق عامة)؟ فهي تُثبت كفاءة في سلامة الغذاء، ولها وزن فعلي في الواقع | هذا التحليل | نعم — يعيق MOD-CERT |
OQ-10 |
هل تحتفظ Qwizin بالأموال وتصرفها للمستشارين/المزوّدين؟ إن كان كذلك، فقد يستوجب ذلك ترخيص مؤسسة دفع من ساما (SAMA) | هذا التحليل | نعم — عائق قانوني محتمل |
OQ-11 |
هل التكامل مع الفوترة الإلكترونية لهيئة الزكاة والضريبة والجمارك (ZATCA) مطلوب للفواتير الصادرة من المنصة؟ | هذا التحليل | نعم |
OQ-12 |
نطاق ثنائية اللغة: هل المحتوى كله مزدوج عربي/إنجليزي، أم عربي أساسًا مع الإنجليزية كبديل احتياطي؟ | هذا التحليل | نعم — يؤثر على نموذج البيانات + البحث |
OQ-13 |
هل يلزم تسلسل هرمي شركة ← فرع (يُفهَم ضمنًا من مقارنة الفروع في SRC-TRN)؟ |
هذا التحليل | متوسط |
7. نقاط الفصل المعمارية (نقاط الاستخراج للمرحلة الثانية)#
مُستمدة من CONF-04. هذه هي الحدود التي يجب أن يحترمها الـ MVP كي تكون المرحلة الثانية إضافةً لا إعادة كتابة.
| ID | نقطة الفصل | المبرر |
|---|---|---|
SEAM-01 |
عزل MOD-PAY خلف منفذ (port) للدفع |
بوابة الدفع لم تُحسَم بعد (OQ-01)؛ وقد تستلزم الـ payouts ترخيصًا (OQ-10)؛ وتعقيد الفوترة يتنامى مع الاشتراكات + marketplace |
SEAM-02 |
عزل MOD-VID خلف منفذ للمزوّد |
قرار المورّد مؤجَّل بتصميم متعمَّد؛ والوسائط هي المكوّن الأرجح للاستبدال |
SEAM-03 |
نمذجة مستندات MOD-TPL ككيانات منظّمة، لا كملفات مبهمة |
مصنّفات التدقيق (SRC-CNT) بيانات بصف لكل ضابط؛ ومنتج التدقيق التفاعلي هو التطور البديهي للمرحلة الثانية |
SEAM-04 |
الفصل بين MOD-LRN وMOD-ASMT |
الـ LMS هو أعلى القدرات المؤجَّلة صوتًا؛ وإذا نما فسينمو بسرعة |
SEAM-05 |
فصل الفهرس/البحث في MOD-MKT عن عمليات CRUD الخاصة بالدليل |
تضيف المرحلة الثانية التواصل B2B مع المورّدين، والمشتريات، والقائمة الرقمية — وكلها مجاورة للفهرس |
SEAM-06 |
نمذجة التسلسل الهرمي شركة/فرع/موظف بمستوى من الوساطة (indirection) | الأقسام مؤجَّلة (BRD §10.2)، والفروع مفهومة ضمنًا (SRC-TRN)؛ وإقحام تسلسل هرمي لاحقًا في نموذج مسطّح مكلف |
SEAM-07 |
طبقة محوّلات (adapters) للتكامل الخارجي | تَعِد المرحلة الثانية بـ POS/PMS، والجهات الحكومية (SFDA/البلدية)، وERP/CRM — وكلها تكاملات مع أنظمة خارجية |
8. القيود (مُلزِمة)#
| ID | القيد | المصدر |
|---|---|---|
CON-01 |
تنفيذ منخفض التكلفة؛ حسّاس للميزانية | BRD §12.1 |
CON-02 |
تفضيل التقنيات مفتوحة المصدر | BRD §12.2، MOM NFR-3 |
CON-03 |
لا LMS كامل في الـ MVP | BRD §12.3 |
CON-04 |
الاعتماد مطلوب قبل تفعيل الشركة / المستشار / المزوّد | BRD §12.5 |
CON-05 |
الميزات المدفوعة تعتمد على نجاح معالجة الدفع | BRD §12.6 |
CON-06 |
النشر الأولي يستهدف المملكة العربية السعودية فقط | BRD §12.7 |
CON-07 |
باقات الاشتراك قابلة للضبط عبر لوحة تحكم مسؤول المنصة | BRD §12.8 |
CON-08 |
درجة النجاح في التقييم قابلة للضبط من قِبل مسؤول المنصة | BRD §12.9 |
CON-09 |
حسابات الموظفين تحت شركة معتمَدة فقط | BRD §12.10 |
CON-10 |
يجب تأمين المستندات القانونية المرفوعة | MOM NFR-1 |
CON-11 |
أقل عدد ممكن من خطوات الواجهة لطلبات القوالب المخصّصة (تجنّبًا لارتفاع معدّل الارتداد) | MOM NFR-2 |
CON-12 |
يجب أن تدعم المعمارية التوسّع إلى دول الخليج دون إعادة تصميم جوهرية | BRD §3.7، §5.5 |
قيود يفرضها المعماري (في هذا التكليف)#
| ID | القيد | المبرر |
|---|---|---|
CON-13 |
إقامة البيانات (data residency) داخل المملكة | وضع الامتثال لـ PDPL + طموح التعاقد الحكومي (SRC-DECK) |
CON-14 |
نمط أحادي معياري (modular monolith) بـ Laravel + خدمات مرافقة (sidecars) مستخرَجة | حجم الفريق والميزانية مقابل CON-01؛ انظر ADR-0002 |
CON-15 |
Kubernetes كهدف للتنسيق (orchestration) | قرار المعماري؛ انظر ADR-0003 |
CON-16 |
خلفية API-first، وعميل mobile-first | المنتج مقاده التطبيق (SRC-DECK) |
9. التتبّع إلى مصفوفة تتبّع المتطلبات لدى محلل الأعمال#
يعرّف SRC-MOM ستة معرّفات متطلبات. وربطها بخط الأساس هذا:
| MoM REQ | الوصف | الأولوية | يُربط بـ |
|---|---|---|---|
| REQ-01 | 3 أنواع حسابات بحقول خاصة بكل نوع عند التسجيل | Must | MOD-IAM، ACT-* |
| REQ-02 | رفع مستندات التحقق للمزوّد؛ لا ظهور في الدليل حتى اعتماد السجل التجاري + البطاقة الضريبية | Must | MOD-ONB، CON-04 |
| REQ-03 | مكالمات فيديو داخل التطبيق، مستقرة من البداية إلى النهاية | Must | MOD-VID، SEAM-02 |
| REQ-04 | تنزيل مجاني للقوالب + طلب تخصيص بسيط | Must | MOD-TPL، CON-11 |
| REQ-05 | تصحيح آلي للأسئلة متعددة الخيارات + شهادة PDF تلقائية قابلة للتنزيل | Must | MOD-ASMT، MOD-CERT |
| REQ-06 | دليل مورّدين بفلاتر متقدمة؛ المشتركون في الإدراج المميّز يتصدّرون الترتيب | Should | MOD-MKT |
10. مؤشرات النجاح (من SRC-MOM §13)#
مُوثَّقة لأنها تستتبع متطلبات بيانات للتقارير والتحليلات على المعمارية:
- عدد الاستشارات المحجوزة والمكتملة شهريًا
- عدد القوالب المجانية المُنزَّلة والمُخصَّصة
- نسبة الموظفين الناجحين في التقييمات والحاصلين على شهادات
- الإيراد الشهري المتكرر (MRR) من اشتراكات المزوّدين وباقات الإدراج المميّز
هذه المؤشرات الأربعة هي الحد الأدنى القابل للتطبيق من سطح التحليلات. وهي تتطلب التقاط الأحداث في
MOD-CONSوMOD-TPLوMOD-ASMT/MOD-CERTوMOD-PAYعلى التوالي. وتصميمها من البداية أرخص بكثير من إعادة بنائها لاحقًا من جداول المعاملات.
الوثائق التالية#
01-quality-attribute-scenarios.md— تحوّل المتطلبات غير الوظيفية أعلاه إلى سيناريوهات قابلة للقياس وموجِّهة للمعماريةarc42/— وصف المعمارية ذاتهadr/— سجلات القرارات لكل خيار اتُّخذ هنا وفيما بعده