كتابة المتطلبات: الوثيقة التي تمنع نصف الخلافات

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

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

واكتب المعايير بلغة النتيجة لا بلغة التنفيذ: لا تقل استعمل جدولا كذا، بل قل يجب أن يرى المستخدم كذا.

ما يهمل عادة

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

المستثنيات

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

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

1. الأداء: كم مستخدما متزامنا، وما زمن الاستجابة المقبول.
2. الأمان: مستوى الحماية المطلوب، وسياسات كلمات المرور والصلاحيات.
3. التوافر: هل يحتمل النظام انقطاعا، وكم مدة الاستعادة المقبولة.
4. اللغة والاتجاه: هل يلزم دعم لغتين، وأي منهما الافتراضية.

الاعتماد والتغيير

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

أسئلة شائعة

كم يجب أن تكون الوثيقة مفصلة؟

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

من يكتب المتطلبات؟

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

هل تصلح الطريقة الرشيقة بلا وثائق؟

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