كيف تحوّل فكرة مشروع التخرج إلى متطلبات SRS قابلة للاختبار؟

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

ابدأ بالسياق وحدود النظام

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

عرّف مصطلح «فترة متاحة» قبل استخدامه: جهاز فعال، وخارج الصيانة، ولا يتعارض مع حجز مؤكد. وحدد المنطقة الزمنية ومعنى حدود الفترة؛ سنعتبرها نصف مفتوحة، فتسمح ببداية حجز عند نهاية حجز آخر. هذه الكلمات تبدو تفصيلية لكنها تغير الاختبار ونتيجة التنفيذ.

اكتب وظيفة واحدة لكل متطلب

هذه متطلبات تعليمية وليست مواصفات جامعة بعينها. استبدل «وفق السياسة المعتمدة» بمرجع سياسة محدد في وثيقتك؛ وإلا ستؤجل معنى المتطلب إلى المطور. يمكن أن تنص السياسة، مثلاً، على الإلغاء قبل بدء الفترة، لكن لا تضعها بوصفها حقيقة عن أي مختبر قبل اتفاق صاحب المتطلب.

اجعل المتطلبات غير الوظيفية قابلة للقياس

عبارة «النظام سريع وآمن وسهل» لا تكفي لتقرير نجاحه. اكتب ظرفاً ومقياساً وطريقة فحص. مثال R-05: تعرض صفحة قائمة الأجهزة المحتوى الأساسي عند تعطيل JavaScript. معيار القبول هو فتحها في هذه الحالة والوصول إلى الروابط والنصوص. هذا أكثر وضوحاً من المطالبة العامة بأن يكون الموقع متوافقاً.

مثال أداء افتراضي R-06: عند عدد متزامن متفق عليه وبيانات اختبار محددة، لا يتجاوز p95 لطلب عرض الأجهزة الحد الذي يقره الفريق والمشرف. يجب تثبيت العدد والحد وبيئة التشغيل قبل القياس، مع فصل زمن الخادم عن زمن تحميل الصفحة. لا نضع رقماً في وثيقتك لمجرد وجوده في مثال؛ قيمة الحد تأتي من الحاجة والقدرة والقيود.

اكتب سيناريو قبول يمكن تكراره

للمتطلب R-03، جهّز جهازاً واحداً وحجزاً من 09:00 إلى 10:00 وفق توقيت معروف. حين يطلب مستخدم فترة 09:30–10:30 للجهاز نفسه، يتوقع رفض التعارض وعدم إضافة حجز. وحين يطلب 10:00–11:00، يتوقع القبول إن لم توجد صيانة أو قيود أخرى. بذلك تختبر الحد الذي قد يختلف عليه قارئان.

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

اربط المتطلب بالتصميم والاختبار

لا تكتب «ناجح» في مصفوفة القبول قبل الاختبار. يمكن أن تبدأ الخانات باعتبارها روابط مخططة، ثم تضيف ملفات النتائج الفعلية وتاريخها. توضح مصفوفة التحقق في مرجع NASA أهمية تحديد وسيلة التحقق وربطها بمعرف المتطلب؛ تطبيقها هنا مقترح تعليمي يتكيف مع حجم المشروع.

كيف تراجع المتطلبات عند إضافة وظيفة؟

اقرأ كل جملة واسأل هل يستطيع شخصان تفسيرها بطريقة واحدة، وهل تتضمن أكثر من وظيفة، وهل تتعارض مع متطلب آخر؟ راجع قائمة NASA لكتابة المتطلبات كمصدر لمعايير الوضوح والتتبع والتحقق، مع بقاء صياغة النطاق مسؤولية أصحاب المشروع.

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