عيوب المتطلبات

لماذا يهم

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

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

أربعة أنواع من عيوب المتطلبات

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

• الغامض (Ambiguous): يحتمل النص أكثر من قراءة معقولة، فيستطيع شخصان حريصان أن يبنيا سلوكين مختلفين أو يختبراهما وكلاهما ملتزم بالنص. ومن أسبابه الكلمات المبهمة، والمصطلحات غير المعرَّفة، والوحدة غير المذكورة، والشرط الذي قد ينطبق على عنصر واحد في قائمة أو على عناصرها كلها.
• الناقص (Incomplete): المتطلب موجود ومساره الرئيسي واضح، لكن جزءاً من سلوكه غير مذكور، مثل مسار خطأ أو حدّ أو دور أو ما يحدث عند الرفض أو انتهاء المهلة. تستطيع اختبار المسار السعيد (Happy Path)، لا ما سواه.
• المتناقض (Contradictory): عبارتان لا يمكن أن تصدقا معاً في الموقف نفسه، فكل نتيجة ممكنة تخالف إحداهما. وقد يقع التعارض داخل متطلب، أو بين متطلبين، أو مع قاعدة عمل أو تصميم أو عقد واجهة برمجية (API Contract)، أي الوصف المتفق عليه لطلبات الواجهة واستجاباتها.
• المفقود (Missing): سلوك أو قاعدة يحتاجها المنتج غير مكتوبة في أي مكان، فلا توجد جملة تضع عليها علامة. وبخلاف المتطلب الناقص، لا تقع الفجوة داخل متطلب موجود، بل حيث لا يوجد متطلب أصلاً.

أين يختبئ كل نوع وكيف تبحث عنه

لكل نوع طريقة بحث خاصة به:

• الغموض: حاول أن تكتب نتيجتين متوقعتين مختلفتين تلتزمان كلتاهما بالنص. فإن استطعت، فالعبارة غامضة. وافحص كل رقم: ما وحدته، ومن أين يبدأ العدّ، وهل الحدّ نفسه داخل في النطاق؟
• النقص: اسأل عن كل متطلب من يحق له تنفيذه ومن لا يحق له، وماذا يحدث حين تكون المدخلات غير صالحة، أو يُبلَغ حدّ، أو يُرفض الإجراء، أو يتعطل نظام يعتمد عليه.
• التناقض: قارن المتطلبات التي تمسّ الفاعل نفسه أو البيانات نفسها أو القاعدة نفسها، وقارنها بقواعد العمل والتصاميم وعقد الواجهة البرمجية. وجدول القرار (Decision Table)، كما في درس قواعد العمل، يُظهر التركيبات التي تفرض فيها قاعدتان إجراءين مختلفين.
• المتطلبات المفقودة: تتبّع عملية العمل من بدايتها إلى نهايتها، ودورة حياة كل عنصر، مثل الطلب، من إنشائه مروراً بتعديله وإلغائه وانتهاء صلاحيته؛ فكتابة حالاته وأحداثه تكشف أحداثاً لم يحدّدها أحد. ثم راجع كل دور، وخصائص الجودة في ISO/IEC 25010 مثل الأمان والاعتمادية.

جرّبها: مولّد جداول القرار جرّبها: مولّد انتقالات الحالات

مثال تطبيقي: مواصفة طلبات الإجازة

مسودة مواصفة طلبات الإجازة في بوابة للموارد البشرية مقررة لجلسة تحسين قائمة العمل (Backlog Refinement)، والمختبِر يراجعها قبلها. حاول أن تجد عيباً من كل نوع قبل قراءة الملاحظات.

طلبات الإجازة: بوابة الموارد البشرية، الإصدار 3 (مسودة)

LV-1  يطلب الموظف إجازة باختيار نوع الإجازة وتاريخ البداية وتاريخ النهاية.
LV-2  يجب تقديم طلب الإجازة قبل بدء الإجازة بـ 5 أيام على الأقل.
LV-3  يحصل قادة الفرق والموظفون الذين تزيد خدمتهم على سنتين على 30 يوماً من
      الإجازة السنوية في العام. ويحصل باقي الموظفين على 21 يوماً.
LV-4  يوافق مدير الموظف على الطلب أو يرفضه. والطلبات التي تزيد مدتها على 10 أيام
      تحتاج أيضاً إلى موافقة الموارد البشرية.
LV-5  يمكن طلب الإجازة المرضية في يوم بدئها.
LV-6  تُخصم أيام الإجازة الموافق عليها من رصيد الموظف.

جرّبها: المتطلبات ← حالات اختبار

الملاحظات والسؤال الذي يُطرح لكل منها

تذكر كل ملاحظة النوع، والحالة التي تكشفه، وسؤالاً لمالك المتطلب، وهو هنا مالك المنتج في الموارد البشرية. والسؤال الجيد يعرض الإجابات الممكنة بدلاً من أن يسأل «ماذا يعني هذا؟»، فتمكن الإجابة عنه في سطر واحد.

• غامض، LV-3: عبارة «الذين تزيد خدمتهم على سنتين» قد تنطبق على الفئتين أو على الموظفين وحدهم، فقائد الفريق الذي خدم سنة واحدة يحصل على ⁦21⁩ يوماً في قراءة وعلى ⁦30⁩ في الأخرى. اسأل: «هل يحصل قائد فريق خدم سنة واحدة على ⁦21⁩ يوماً أم ⁦30⁩؟»
• ناقص، LV-4: يذكر من يوافق، لكن في الطلب الذي تزيد مدته على ⁦10⁩ أيام لا تتضح إلا النتيجة حين يوافق الطرفان معاً. اسأل: «في طلب مدته ⁦12⁩ يوماً، من يقرر أولاً؟ وإذا وافق المدير ورفضت الموارد البشرية، فما الحالة النهائية، وماذا يحدث إذا لم يردّ أحد؟»
• متناقض، LV-2 وLV-5: الإجازة المرضية في يوم بدئها يرفضها LV-2 ويسمح بها LV-5. اسأل: «هل الإجازة المرضية مستثناة من مهلة الأيام الخمسة في LV-2؟» وفي العادة تُضيَّق إحدى العبارتين، ومالك المتطلب يقرر أيهما.
• مفقود: لا شيء يذكر هل يستطيع الموظف إلغاء طلبه؛ يخصم LV-6 الأيام، لكن لا شيء يعيدها. اسأل: «هل يستطيع الموظف إلغاء طلب معلّق أو موافق عليه، وحتى متى، وهل تُعاد الأيام؟ وإن كان ذلك خارج نطاق الإصدار ⁦3⁩، فهل نوثّقه؟»
• ومما يستحق الطرح أيضاً: هل الأيام الخمسة في LV-2 أيام تقويمية أم أيام عمل؟

جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.