كتابة متطلبات جيدة

كتابة متطلبات جيدة

جمع المتطلبات ليس سوى نصف المهمة. النصف الآخر — وهو في الغالب الأصعب — يكمن في تحويل المدخلات الخام للمعنيين إلى عبارات دقيقة وقابلة للاختبار يستطيع المطوّر تنفيذها والمختبر التحقق منها. المتطلب الذي يقول "يجب أن يكون النظام سريعاً" أو "يحتاج المستخدمون إلى واجهة سهلة" ليس متطلباً حقيقياً، بل هو أمنية. يعلّمك هذا الدرس كيف تكتب متطلبات تصمد أمام الفحص الدقيق وتُوجِّه قرارات التصميم الفعلية.

ما الذي يجعل المتطلب "جيداً"؟

تشترك المتطلبات المكتوبة بشكل جيد في ست صفات، تُلخَّص أحياناً باختصار SMART-U:

• محدد (Specific) — يصف سلوكاً أو قيداً واحداً بعينه، لا فئة مبهمة.
• قابل للقياس (Measurable) — ثمة وسيلة موضوعية للتحقق من تحققه.
• قابل للتحقيق (Achievable) — مجدي تقنياً واقتصادياً ضمن نطاق المشروع.
• ذو صلة (Relevant) — يرتبط بحاجة حقيقية للمعنيين أو بهدف تجاري.
• قابل للاختبار (Testable) — يمكن كتابة حالة اختبار له بنتيجة نجاح/فشل واضحة.
• لا لبس فيه (Unambiguous) — يفهمه كل قارئ بالطريقة ذاتها.

لغة shall و should

تستخدم وثائق المتطلبات المهنية الأفعال الشرطية بشكل متعمد. يميّز معيار IEEE 830 ومعظم أدلة الأسلوب المؤسسي ثلاثة مستويات:

• shall (يجب) — متطلب إلزامي. عدم الامتثال له يُعدّ خللاً.
• should (ينبغي) — سلوك موصى به لكنه اختياري عند التطبيق.
• may (قد/يجوز) — خيار مسموح به للنظام.

يتيح استخدام هذه الكلمات بثبات لكل قارئ — مطوراً أو مختبِراً أو مدققاً — أن يفهم مستوى الالتزام فوراً. تجنّب will في عبارات المتطلبات (تُقرأ كتنبؤ لا كالتزام)، ولا تستخدم must مرادفاً لـshall في الوثائق الرسمية (يُنشئ التباساً قانونياً في العقود).

تشريح عبارة المتطلب الجيد

تتبع عبارة المتطلب الواحد عادةً هذا النمط:

لنأخذ نظام حجز العيادة مثالاً. قارن بين نسختين لنفس الحاجة:

• مبهم: "يجب على النظام تأكيد المواعيد بسرعة."
• جيد: "يجب على النظام إرسال إشعار تأكيد الموعد للمريض خلال 30 ثانية من حفظ الحجز."

تُسمّي الصياغة الجيدة الفاعل (النظام)، والإجراء (إرسال إشعار التأكيد)، والمفعول به (للمريض)، والمُحدِّد القابل للقياس (خلال 30 ثانية من حفظ الحجز). يستطيع مهندس ضمان الجودة الآن كتابة اختبار آلي له.

أنماط شائعة للمتطلبات المكتوبة بشكل سيئ

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

• الصفات المبهمة: "يجب أن تكون صفحة الدفع سهلة الاستخدام." — سهلة بحسب من؟ استبدلها بمعيار قابل للقياس: "يجب أن يتمكن المستخدم الجديد من إتمام عملية الدفع في أقل من 4 خطوات دون الرجوع إلى التوثيق."
• المتطلبات المركّبة (فخ AND): "يجب على النظام التحقق من عنوان الشحن وحساب تقدير التوصيل وعرض التكلفة الإجمالية." — هذه ثلاثة متطلبات منفصلة في صياغة واحدة. افصلها.
• المبني للمجهول الذي يخفي الفاعل: "يجب أن تُنشأ الفواتير تلقائياً." — من قِبَل ماذا؟ بعد أي حدث؟ اكتب بدلاً من ذلك: "يجب على النظام إنشاء فاتورة PDF تلقائياً خلال 5 ثوانٍ من تغيير حالة الطلب إلى مؤكَّد."
• أداء غير قابل للقياس: "يجب على النظام استيعاب حركة المرور العالية." — قِسه: "يجب على النظام دعم 500 مستخدم متزامن على الأقل دون تجاوز وقت استجابة 2 ثانية على أي صفحة."
• الافتراضات الضمنية: "يجب على النظام عرض تواريخ التوصيل." — في أي منطقة زمنية؟ لأي ناقل شحن؟ بأي تنسيق؟

تطبيق القواعد: سيناريو شركة لوجستية

تبني شركة لوجستية بوابة تتبع للشحنات. الملاحظة الخام للمعني تقول:

تحليل هذه الملاحظة إلى متطلبات جيدة الصياغة:

1. "يجب على تطبيق الجوال السماح للسائق المُوثَّق بتحديث حالة تسليم الشحنة المُسنَدة إليه خلال 3 نقرات من الشاشة الرئيسية." (قابلية الاستخدام + التفاعل)
2. "يجب على تطبيق الجوال تخزين تحديثات الحالة المعلّقة محلياً ومزامنتها تلقائياً مع الخادم خلال 60 ثانية من استعادة الاتصال بالشبكة." (السلوك دون اتصال + المزامنة)
3. "يجب على النظام الاحتفاظ بطابع زمني ومعرّف السائق لكل تحديث حالة." (سلامة البيانات + قابلية التدقيق)

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

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

تقع المتطلبات غير الوظيفية في الغالب ضحيةً للصياغة المبهمة، لأن موضوعها — الأداء والأمان والتوافر — يبدو مجرداً بطبيعته. والعلاج دائماً هو نفسه: سمِّ المقياس وحدِّد عتبته.

• الأداء: "يجب على صفحة البحث عن المنتج إعادة النتائج في أقل من 1.5 ثانية عند الشريحة المئوية الخامسة والتسعين تحت حمولة 300 مستخدم متزامن."
• التوافر: "يجب على خدمة الحجز الحفاظ على وقت تشغيل 99.5%، مقاساً شهرياً، باستثناء نوافذ الصيانة المجدولة التي يُعلَن عنها قبل 24 ساعة على الأقل."
• الأمان: "يجب تشفير جميع بيانات المرضى المنقولة بين العميل والخادم باستخدام TLS 1.2 أو أعلى."
• قابلية الاستخدام: "يجب أن يتمكن موظف الاستقبال الجديد دون أي تدريب مسبق من حجز موعد خلال 5 دقائق، مقاساً أثناء اختبار التأهيل."

قائمة التحقق قبل اعتماد المتطلب

قبل إدراج متطلب في نسختك المرجعية، مرِّره عبر قائمة التحقق هذه:

1. هل يحتوي على عبارة shall (أو should) واحدة بالضبط؟
2. هل الفاعل أو مكوّن النظام لا لبس فيه؟
3. هل ثمة معيار موضوعي قابل للقياس للرضا عنه؟
4. هل يمكن لقارئين مختلفين تفسيره بشكل مختلف؟ إذا نعم، أعِد الصياغة.
5. هل يمكن كتابة حالة اختبار له الآن؟
6. هل يصف ماذا يفعل النظام لا كيف يفعله؟ (التنفيذ ينتمي إلى التصميم، لا إلى المتطلبات.)
7. هل هو خالٍ من العبارات المركّبة؟ (لا تقسيمات مخفية بـ AND أو OR.)

لا تُكتب المتطلبات الجيدة في مراجعة واحدة. حتى المحللون ذوو الخبرة يراجعون كل عبارة مرتين أو ثلاث مرات قبل أن تجتاز كل بند في هذه القائمة. الاستثمار يعود بأضعافه حين لا يحتاج فريق التطوير أبداً إلى السؤال "ماذا كنت تقصد بهذا؟" ويستطيع فريق الاختبار أتمتة التحقق منذ اليوم الأول.