كيف تكتب وثيقة متطلبات واضحة لمشروعك البرمجي: من الفكرة إلى معايير القبول

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

1. لماذا تتعثر المشاريع حين تغيب وثيقة المتطلبات

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

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

الوثيقة المكتوبة لا تمنع التغيير، لكنها تجعله ظاهرًا ومقصودًا بدل أن يحدث خفية.

2. المكونات الأساسية لوثيقة متطلبات جيدة

لا يُشترط أن تكون الوثيقة طويلة، بل أن تكون مرتبة وقابلة للرجوع إليها. وتشمل الوثيقة الجيدة عادة الأقسام الآتية:

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

3. كتابة المتطلبات الوظيفية بلغة قابلة للتحقق

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

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

4. المتطلبات غير الوظيفية: الجانب الذي يُنسى غالبًا

إذا كانت المتطلبات الوظيفية تصف ما يفعله النظام، فإن غير الوظيفية تصف كيف يفعله وتحت أي ظروف. وكثيرًا ما تُهمل في الوثائق لأنها لا تظهر في الشاشات، ثم تتحول إلى مشكلات مكلفة بعد الإطلاق. ومن أبرز ما ينبغي توثيقه:

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

والأفضل أن تُكتب هذه المتطلبات بقيم محددة يتفق عليها الطرفان، لا بأوصاف عامة.

5. قصص المستخدم: صياغة المتطلبات من منظور من يستخدم النظام

قصة المستخدم طريقة مختصرة لكتابة المتطلب تركز على الشخص والغاية لا على التقنية. وصيغتها الشائعة: «بصفتي [دور المستخدم]، أريد [القيام بإجراء]، لكي [أحقق فائدة]». وقيمة هذه الصيغة أنها تجبر كاتبها على ذكر السبب، فيستطيع الفريق اقتراح حل أبسط إذا وُجد، ويستطيع صاحب القرار ترتيب القصص حسب قيمتها الفعلية.

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

6. معايير القبول: كيف نعرف أن الميزة اكتملت

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

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

الخلاصة

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