مشروع: كتابة وثيقة SRS مصغّرة

مشروع: كتابة وثيقة SRS مصغّرة

كل ما درستَه في هذا البرنامج التعليمي — المتطلبات الوظيفية وغير الوظيفية، وصياغة المتطلبات بدقة، وهيكل وثيقة SRS، وقصص المستخدم مع معايير القبول، وترتيب الأولويات بأسلوب MoSCoW، والتحقق من المتطلبات وإدارة تغيُّرها والتتبع — يتجمّع في مُخرَج واحد: وثيقة مواصفات متطلبات البرنامج (SRS). تأخذك هذه الدرس الختامي خطوةً بخطوة لإنتاج وثيقة SRS مصغّرة متكاملة واحترافية لسيناريو عمل واقعي، مع توضيح القرارات المُتّخذة في كل مرحلة.

السيناريو: CareSlot — نظام حجز عيادة

تُدير عيادة Greenfield Health الخاصة متعددة التخصصات خمسةَ أطباء في ثلاثة تخصصات. يتصل المرضى حاليًا بالاستقبال هاتفيًا لحجز المواعيد أو إلغائها أو إعادة جدولتها، مما يُفضي إلى ضياع نحو 30 موعدًا أسبوعيًا بسبب المكالمات الفائتة وأخطاء الإدخال المزدوج. تريد الإدارة بوابة حجز ذاتي عبر الإنترنت. لقد عُيِّنتَ محللًا للأعمال، وبعد إجراء مقابلتَين مع أصحاب المصلحة وجلسة ملاحظة ميدانية، عليك تسليم وثيقة SRS مصغّرة.

القسم 1 — المقدمة

يُجيب قسم المقدمة في أي وثيقة SRS على أربعة أسئلة: ما هو المنتج؟ مَن هم أصحاب المصلحة؟ ما الذي يقع ضمن النطاق؟ ما الافتراضات التي تُقيّد العمل؟

• اسم المنتج والغرض منه: CareSlot v1.0 — بوابة حجز مواعيد تعمل عبر المتصفح لعيادة Greenfield Health، تُتيح للمرضى الحجز الذاتي والإلغاء وإعادة الجدولة مع أي طبيب.
• الجمهور المستهدف من الوثيقة: المرضى (المستخدمون الأساسيون)، موظفو الاستقبال (المستخدمون المتقدمون)، مدير العيادة (التقارير)، قسم تقنية المعلومات (النشر).
• النطاق: حجز المرضى ذاتيًا، لوحة الاستقبال الخلفية، تأكيدات البريد الإلكتروني والرسائل القصيرة تلقائيًا، وتقرير المواعيد اليومي. خارج النطاق: الفواتير، التكامل مع السجل الصحي الإلكتروني، التطبيق المحلي للهاتف، التوسع متعدد العيادات.
• الافتراضات: يحتفظ كل طبيب بتقويم التوفر الخاص به. تتمتع العيادة باتصال إنترنت مستقر. يمتلك المرضى بريدًا إلكترونيًا. يتولّى مزوّد خارجي معاقَد بالفعل تسليم الرسائل القصيرة.
• التبعيات: واجهة برمجة بوابة الرسائل القصيرة الخارجية، خلاصة التقويم لكل طبيب.

القسم 2 — ملفات أصحاب المصلحة

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

القسم 3 — المتطلبات الوظيفية

استخدم فعل SHALL على نمط IEEE 830 للمتطلبات الإلزامية. خصّص معرّفًا فريدًا لكل متطلب لأغراض التتبع.

• FR-01 (يجب): يجب أن يتيح النظام للمريض البحث عن المواعيد المتاحة حسب الطبيب والتخصص والنطاق الزمني.
• FR-02 (يجب): يجب أن يتيح النظام للمريض حجز موعد متاح بعد تقديم اسمه وتاريخ ميلاده ورقم هاتفه وبريده الإلكتروني.
• FR-03 (يجب): يجب أن يمنع النظام حجز موعدَين متداخلَين لنفس الطبيب.
• FR-04 (يجب): يجب أن يُرسل النظام بريدًا إلكترونيًا ورسالة قصيرة للمريض خلال دقيقتَين من تأكيد الحجز.
• FR-05 (يجب): يجب أن يتيح النظام للمريض إلغاء موعده أو إعادة جدولته قبل 4 ساعات على الأقل من الموعد المقرر.
• FR-06 (ينبغي): ينبغي أن يُرسل النظام تذكيرًا عبر البريد الإلكتروني والرسالة القصيرة قبل 24 ساعة من الموعد.
• FR-07 (ينبغي): ينبغي أن يتمكن موظف الاستقبال من رؤية جميع مواعيد اليوم الحالي على شاشة لوحة تحكم واحدة.
• FR-08 (يمكن): يمكن أن يتيح النظام لمدير العيادة تصدير تقرير أسبوعي للمواعيد بصيغة CSV.
• FR-09 (لن يُنفَّذ): لن يتضمن النظام معالجة الفواتير أو المدفوعات في الإصدار 1.0.

القسم 4 — المتطلبات غير الوظيفية

• NFR-01 الأداء: يجب أن تُحمَّل صفحة نتائج البحث عن المواعيد في أقل من ثانيتَين تحت حمل 50 مستخدمًا متزامنًا.
• NFR-02 التوفر: يجب أن يحافظ النظام على نسبة تشغيل 99.5% خلال ساعات عمل العيادة (07:00–20:00 بالتوقيت المحلي، الاثنين–السبت).
• NFR-03 الأمان: تُنقَل جميع بيانات المرضى الشخصية عبر HTTPS (TLS 1.2 أو أعلى)، وتُخزَّن كلمات المرور بتشفير bcrypt بمعامل تكلفة 12 أو أعلى.
• NFR-04 سهولة الاستخدام: يجب أن يتمكن مريض يستخدم البوابة لأول مرة دون تدريب من إتمام الحجز في أقل من 3 دقائق، بما يثبته اختبار قابلية استخدام مع خمسة مشاركين.
• NFR-05 قابلية الصيانة: يجب أن يتمكن موظف تقنية معلومات واحد من نشر النظام اتباعًا لدليل التشغيل المكتوب في أقل من 30 دقيقة.

القسم 5 — قصص المستخدم مع معايير القبول

استكمل عبارات SHALL الرسمية بقصص المستخدم حتى يفهم فريق التطوير السياق الإنساني. استخدم نمط Given-When-Then لمعايير القبول.

US-01 — حجز موعد (يجب)

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

• AC-01a: بمجرد أن أكون على صفحة الحجز وأختار تخصصًا وتاريخًا، أرى فقط المواعيد المتاحة (لا المحجوزة أو المحظورة).
• AC-01b: بعد اختيار موعد وإرسال النموذج ببيانات صحيحة وتأكيد الحجز، أستقبل بريدًا إلكترونيًا خلال دقيقتَين يتضمن اسم الطبيب والتاريخ والوقت ورقم مرجع فريد.
• AC-01c: إذا حاول مريضان حجز الموعد ذاته في وقت واحد، رفض النظام حجز الثاني برسالة واضحة واقترح أقرب موعد متاح.

US-02 — إلغاء موعد (يجب)

بوصفي مريضًا، أريد إلغاء موعدي عبر الإنترنت لإتاحة الوقت للعيادة وتجنُّب رسوم الغياب.

• AC-02a: عند إدخال رقم الحجز والبريد الإلكتروني وطلب الإلغاء قبل 4 ساعات من الموعد، يُحرَّر الوقت وأستقبل بريد تأكيد الإلغاء.
• AC-02b: عند محاولة الإلغاء في أقل من 4 ساعات من الموعد، يعرض النظام رسالة خطأ تشرح سياسة وقت القطع.

US-03 — عرض جدول اليوم (ينبغي)

بوصفي موظفة استقبال، أريد رؤية جميع مواعيد اليوم على شاشة واحدة لاستقبال المرضى بأسمائهم ورصد الغائبين بسرعة.

• AC-03a: بعد تسجيل الدخول، تعرض لوحة التحكم جميع مواعيد اليوم الحالي مرتَّبةً حسب وقت البدء مع اسم المريض والطبيب والتخصص والحالة.
• AC-03b: عند تغيُّر حالة أي موعد (إلغاء أو تأكيد متأخر)، يظهر التحديث على اللوحة خلال 30 ثانية دون إعادة تحميل الصفحة كاملةً.

القسم 6 — القيود والافتراضات

القيود حقائق لا يستطيع الفريق تغييرها؛ أما الافتراضات فهي حقائق يعتقد الفريق صحتها لكنه يُسجّلها صراحةً حتى يتمكن المراجعون من تحديّها.

• قيد تقني: يجب تشغيل البوابة على الاستضافة المشتركة الحالية للعيادة (لا Docker ولا Kubernetes).
• قيد تنظيمي: يجب أن تمتثل بيانات المرضى للقانون الوطني لحماية البيانات الشخصية؛ لا يجوز تخزين أي بيانات خارج البلاد.
• قيد تجاري: يجب إطلاق الخدمة قبل موسم تجديد العضويات السنوي للعيادة (8 أسابيع من انطلاق المشروع).
• الافتراض A1: سيعيّن كل طبيب مساعدًا إداريًا مسؤولًا عن حظر أوقات عدم التوفر في نظام التقويم.
• الافتراض A2: ستحافظ بوابة الرسائل القصيرة الخارجية على معدل تسليم يتجاوز 95% خلال ساعات العمل.

القسم 7 — مصفوفة التتبع (مقتطف)

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

القسم 8 — المسرد وسجل المراجعات

حتى وثيقة SRS المصغّرة تستفيد من مسرد مختصر (يُعرّف "الموعد المتاح" و"رقم مرجع الحجز" و"دور موظف الاستقبال") ومن سجل مراجعات (الإصدار 0.1 — مسودة أولى؛ الإصدار 0.2 — إضافة المتطلبات غير الوظيفية بعد مراجعة أصحاب المصلحة). هذا هو القسم الذي يتخطاه أغلب المحللين المبتدئين ويبحث عنه أول شيء كلُّ مراجع متمرس.

الصورة الكاملة

كتابة وثيقة SRS مصغّرة — ولو من عشر صفحات فحسب — تُلزمك بحل الغموض قبل كتابة سطر واحد من الكود. في نظام CareSlot كشف هذا التمرين عن ثلاث مسائل كانت ستتحول إلى أخطاء مكلفة: كان حدّ الإلغاء قبل 4 ساعات سياسةً داخلية للعيادة غير موثّقة؛ وكانت منطقة منع الحجز المزدوج تستلزم ضمنيًا قفل تفاؤليًا في قاعدة البيانات؛ وكانت تبعية بوابة الرسائل القصيرة نقطة فشل واحدة يجب أن تُعترف بها NFR-02. لم تظهر أيٌّ من هذه المسائل في جلسات العصف الذهني — بل ظهرت بفضل انضباط التوثيق الدقيق.

حين تنتقل إلى مشاريعك الخاصة، استخدم هذه الوثيقة المصغّرة قالبًا قابلًا للتوسع. اجعل كل متطلب قابلًا للاختبار، وكل افتراض صريحًا، وكل أولوية مبرَّرة. هذا الانضباط هو ما يُميّز وثيقة متطلبات توجّه بناءً ناجحًا عن وثيقة تنام في مجلد مشترك لا يفتحها أحد.