كتابة متطلبات برمجية يمكن اختبارها فعلًا

ابدأ بسلوك يمكن الاتفاق على نتيجته

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

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

مثال افتراضي لطلب شراء

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

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

عرّف معنى الاكتمال: هوية المورد والعملة والبنود والمبرر مثلًا. واحصل على حدود الاعتماد الفعلية من مالك العملية. وضح هل يؤثر تغيير هذه الحدود في الطلبات المفتوحة أم يبدأ تطبيقه على الطلبات الجديدة فقط.

أجزاء تساعد الفريق على الاختبار

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

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

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

حوّل صفات الجودة إلى ظروف قياس

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

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

عالج الغموض قبل التقدير

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

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

جرّب القبول قبل بدء البرمجة

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

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