ما المتطلبات؟
المتطلب (Requirement) عبارة تصف شيئاً يجب أن يفعله المنتج، أو جودةً أو قيداً يجب أن يلتزم به، لأن أحد أصحاب المصلحة في المنتج يحتاج إليه. فعبارة «يرسل النظام رسالة تذكير نصية (SMS) قبل 24 ساعة من كل موعد محجوز» متطلب، وعبارة «يجب أن يستطيع المريض إلغاء موعده دون الاتصال بالعيادة» متطلب أيضاً، وكذلك هدف العيادة الذي يقف وراءهما: تقليل المواعيد الفائتة.
تقع هذه العبارات الثلاث في مستويات مختلفة، هي العمل وأصحاب المصلحة والنظام، وتأتي من أشخاص مختلفين، وتُكتب بأشكال مختلفة: وثيقة استراتيجية، أو قصة مستخدم، أو مواصفة، أو تصميم، أو عقد. وكما رأيت في درس تحليل الاختبار، يبدأ الاختبار من أساس الاختبار (Test Basis)، والمتطلبات هي الجزء الأكبر منه في معظم المنتجات. ويعلّمك هذا الدرس كيف تتعرّف على المتطلبات بكل أشكالها وكيف تقرؤها بعين المختبِر.
لماذا يهم
قد يولد العيب في المتطلب قبل كتابة أي شيفرة. فإذا كان المتطلب مفقوداً أو غامضاً أو خاطئاً، نقل التصميم والشيفرة والاختبارات الخطأ نفسه، وقد ينجح النظام عندها في كل اختبار ثم يخذل الناس الذين بُني من أجلهم. والعيب الذي يُكتشف في المتطلب أثناء كتابته يكلّف حواراً، أما إذا اكتُشف بعد الإصدار فيكلّف إصلاحاً وإعادة اختبار، وأحياناً تنظيفاً للبيانات، وثقةَ المستخدمين.
بالنسبة للمنتج، تُحسم في المتطلبات حدود النطاق والتكلفة والمخاطر. وبالنسبة للمختبِر، فقراءتها جيداً أولى مهارات الدور: فهي تحدد ما تختبره، وما تختبره أولاً، ومدى الدقة التي تشرح بها الإخفاق. فعبارة «ينص المتطلب على 24 ساعة قبل الموعد، لكن التذكير وصل قبله بساعتين» تقرير خطأ يستطيع المطور العمل عليه فوراً.
ثلاثة مستويات: متطلبات العمل وأصحاب المصلحة والنظام
تُوصف المتطلبات عادةً على ثلاثة مستويات، يجيب كل منها عن سؤال مختلف، ويملكه أشخاص مختلفون، ويفصّل المستوى الذي فوقه: فهدف العمل يتحقق عبر أشياء يحتاج المستخدمون إلى فعلها، وهذه الاحتياجات تتحقق عبر أشياء يجب أن يفعلها النظام.
تختلف الأسماء: فمعيار هندسة المتطلبات ISO/IEC/IEEE 29148 يصف مواصفات منفصلة لمتطلبات العمل وأصحاب المصلحة والنظام والبرمجيات، وكثير من الفرق يسمّي المستوى الأوسط «متطلبات المستخدم»، ويقول «متطلبات البرمجيات» حين يكون النظام برمجياً بالكامل. وفي الفرق الرشيقة (Agile) تظهر هذه المستويات، على وجه التقريب، في صورة هدف المنتج، وقصص المستخدم التي تخدمه، ومعايير القبول والملاحظات التقنية تحت كل قصة.
- متطلبات العمل (Business Requirements): لماذا تريد المؤسسة المنتج، أي هدف تسعى إليه أو مشكلة تحلّها. يصوغها الراعي أو الإدارة أو مالك العمل. مثال: «تقليل المواعيد الفائتة في عياداتنا بمقدار الخُمس خلال ستة أشهر».
- متطلبات أصحاب المصلحة أو المستخدم (Stakeholder/User Requirements): ما يحتاج المستخدمون وأصحاب المصلحة الآخرون إلى فعله أو تحقيقه، بكلماتهم هم. يجمعها مالك المنتج (Product Owner) أو محلل الأعمال (Business Analyst). مثال: «بصفتي مريضاً، أريد تذكيراً قبل موعدي كي أحضر في الوقت أو ألغي مبكراً».
- متطلبات النظام أو البرمجيات (System/Software Requirements): ما يجب أن يفعله النظام ومدى جودة أدائه، بدقة تكفي للبناء والاختبار. يُتفق عليها مع المطورين والمعماريين. مثال: «يرسل النظام رسالة تذكير نصية قبل 24 ساعة من كل موعد محجوز». ويضم هذا المستوى المتطلبات الوظيفية وغير الوظيفية والقيود، ويفصل الدرس التالي بينها.
كل مستوى يفصّل المستوى الذي فوقه، ويجب أن يُتتبَّع إليه
عند طبقة «متطلبات العمل»: هدف عامعند طبقة «متطلبات النظام (البرمجيات)»: دقيق بما يكفي للبناء والاختبار
- 1متطلبات العملهدف المؤسسة، يصوغه الراعي أو مالك العمل: تقليل المواعيد الفائتة بمقدار الخُمس
يحدد المختبِر الأولويات ويتأكد أن الهدف قابل للقياس
- 2متطلبات أصحاب المصلحة (المستخدم)احتياجات بكلمات المستخدمين، يجمعها مالك المنتج أو المحلل: تذكير كي أحضر في الوقت أو ألغي
يسأل المختبِر هل يلبّي المنتج الاحتياج الحقيقي (التحقق من الصلاحية)
- 3متطلبات النظام (البرمجيات)سلوك محدد بدقة، يُتفق عليه مع المطورين: رسالة تذكير نصية قبل 24 ساعة من كل موعد محجوز
يستخرج المختبِر شروط الاختبار والنتائج المتوقعة
تختلف الأسماء: فالمعيار ISO/IEC/IEEE 29148 يفصل أيضاً متطلبات النظام عن متطلبات البرمجيات، والفرق الرشيقة كثيراً ما تُظهر المستويات في صورة هدف المنتج وقصص المستخدم ومعايير القبول.
من أين تأتي المتطلبات وما الأشكال التي تُكتب بها
لكل متطلب مصدر، أي الشخص أو الوثيقة أو القاعدة التي جاء منها، وشكل، أي الطريقة التي دُوِّن بها. ومن المصادر المعتادة: العملاء والمستخدمون النهائيون، ومالك المنتج أو محلل الأعمال، وتذاكر الدعم وبيانات الاستخدام، والقوانين واللوائح، والمعايير مثل WCAG 2.2 لإمكانية الوصول، والعقود، وسلوك نظام قائم يحلّ النظام الجديد محله. ومعرفة المصدر تخبرك بمن تسأل حين يكون النص غير واضح.
تحتفظ معظم الفرق بالمتطلبات في عدة أشكال في الوقت نفسه. ويذكر منهج ISTQB للمستوى التأسيسي مواصفات المتطلبات وعناصر قائمة مهام المنتج والعقود والنماذج ضمن مُخرَجات العمل التي يمكن فحصها بالاختبار الساكن، لذا يمكن مراجعة معظم هذه الأشكال قبل وجود أي شيفرة. فاقرأها مجموعةً واحدة: القصة تقول ما يحتاجه المستخدم، والتصميم يُظهر الشاشة، وعقد الواجهة البرمجية (API) يثبّت الحقول، وقرار في محادثة جانبية قد يغيّر الثلاثة معاً.
- الوثائق: وثائق متطلبات العمل، ومواصفات متطلبات البرمجيات، وعبارات مرقّمة بصيغة «يجب أن» (shall). دقيقة ولها إصدارات، لكنها بطيئة التغيير.
- عناصر قائمة مهام المنتج (Product Backlog): الملاحم (Epics) وقصص المستخدم ومعايير قبولها في أداة تتبّع. قصيرة عن قصد، والتفاصيل يُتفق عليها في الحوار، فتأكد من تدوين القرارات في العنصر نفسه.
- النماذج: مخططات سير العمليات، ومخططات الحالات، ونماذج البيانات، وعقود الواجهات البرمجية مثل ملف OpenAPI. وهي تكشف ما يخفيه النص: كل حالة، وكل حقل، وكل استجابة خطأ.
- النماذج الأولية والتصاميم: المخططات الهيكلية (Wireframes) والتصاميم التفصيلية (Mock-ups) والنماذج الأولية القابلة للنقر. تُظهر التخطيط وتسلسل الشاشات، فاسأل أي أجزائها مُلزِم وأيها مجرد محتوى للعرض.
- الأمثلة والتوقعات غير المكتوبة: الأمثلة المحلولة، وسيناريوهات Given/When/Then، والأشياء التي لا يكتبها أحد لأنها تبدو بديهية: البيانات المحفوظة لا تضيع، والمنتج يلتزم بالقانون، ويتصرف كالمنتجات المشابهة. وهذه المتطلبات الضمنية تبقى متطلبات.
مثال تطبيقي: تذكير المواعيد على ثلاثة مستويات
تضيف سلسلة عيادات تذكيرات إلى تطبيق الحجز الخاص بها. وفيما يلي مجموعة المتطلبات بعد أول اجتماع تنقيح (Refinement)، مرتبةً حسب المستوى. ولكل عبارة معرّف، كي تشير إليها الأسئلة وحالات الاختبار وتقارير الأخطاء.
اقرأها مرتين قبل القسم التالي. من الأعلى إلى الأسفل: هل لكل احتياج شيء تحته يحققه؟ ومن الأسفل إلى الأعلى: هل يخدم كل متطلب نظام احتياجاً فوقه؟ أحد الفحصين لا ينجح.
الميزة: تذكير المواعيد (تطبيق حجز العيادات)
متطلبات العمل
BR-1 تقليل المواعيد الفائتة في عياداتنا بمقدار الخُمس خلال ستة أشهر
من الإطلاق.
متطلبات أصحاب المصلحة (المستخدم)
UR-1 بصفتي مريضاً، أريد تذكيراً قبل موعدي كي أحضر في الوقت أو ألغي مبكراً.
UR-2 بصفتي موظف استقبال، أريد أن أرى من أكّد موعده من المرضى كي أتصل
بالباقين.
متطلبات النظام
SR-1 يرسل النظام رسالة تذكير نصية قبل 24 ساعة من كل موعد محجوز،
باللغة التي اختارها المريض (العربية أو الإنجليزية).
SR-2 تحتوي الرسالة على رابط لتأكيد الموعد أو إلغائه.
SR-3 عند إلغاء المريض عبر الرابط، يصبح الموعد متاحاً للحجز مجدداً
خلال دقيقة واحدة.جرّبها: المتطلبات ← حالات اختبار جرّبها: المتطلبات ← سيناريوهات اختبار
لماذا يقرأ المختبِر المتطلبات، على المثال نفسه
في درس تحليل الاختبار قيّمت أساس الاختبار واستخرجت منه شروط الاختبار (Test Conditions). والمتطلبات عادةً هي الجزء الأكبر من هذا الأساس، وقراءتها مبكراً تمنح المختبِر كل ما يلي، وكل نقطة منه ظاهرة في مثال التذكير.
- النواقص قبل وجود الشيفرة: الفحص من الأسفل إلى الأعلى ينجح، إذ يحقق SR-1 وSR-2 المتطلبَ UR-1، ويجعل SR-3 الإلغاءَ المبكر مفيداً لأنه يحرّر الموعد لمريض آخر. أما الفحص من الأعلى إلى الأسفل فلا ينجح: لا يوجد متطلب نظام يحقق UR-2، فلا شيء يحدد أين تظهر التأكيدات ولا من يراها. إن أُثير الآن فهو تعليق مراجعة، وإن اكتُشف في اختبار النظام فهو ميزة مفقودة. ومراجعة المتطلبات بهذه الطريقة اختبار ساكن (Static Testing)، وينطبق عليها مباشرةً مبدأ ISTQB «الاختبار المبكر يوفّر الوقت والمال».
- النتائج المتوقعة: المتطلب هو مرجع الاختبار (Test Oracle) المعتاد، أي مصدر النتيجة المتوقعة. وSR-3 يعطيك نتيجة مباشرة: ألغِ عبر الرابط، ويجب أن يصبح الموعد متاحاً للحجز مجدداً خلال دقيقة واحدة.
- أسئلة لا يجيب عنها الاختبار وحده: لا يقول SR-1 ماذا يحدث لموعد حُجز قبل أقل من 24 ساعة، ولا في أي منطقة زمنية تُحسب «24 ساعة قبل الموعد»، ولا أي لغة تُستخدم إن لم يختر المريض لغة. وكل إجابة تصبح نتيجة متوقعة.
- الأولويات: يخبرك BR-1 لماذا وُجدت الميزة؛ فالتذكير الذي لا يصل يُفشل الهدف، أما خطأ إملائي في الرسالة فلا يُفشله. ويكشف أيضاً احتياجاً خفياً: لا يمكن قياس الهدف إلا إذا سجّل النظام المواعيد الفائتة.
- التحقق من الصلاحية إلى جانب التحقق: مطابقة البناء مع SR-1 تحقق (Verification)، أما السؤال عمّا إذا كانت رسالة قبل 24 ساعة هي فعلاً ما يحتاجه المرضى فهو تحقق من الصلاحية (Validation)، كما في درس التحقق والتحقق من الصلاحية.
- عمل قابل للتتبع: تحتفظ شروط الاختبار بمصدرها، مثل «إرسال التذكير قبل 24 ساعة (SR-1)» و«موعد محجوز قبل ثلاث ساعات (SR-1)» و«رابط الإلغاء يحرّر الموعد (SR-3)»، فيمكن الإبلاغ عن التغطية والإخفاقات لكل متطلب على حدة.
أخطاء شائعة
- عدّ المواصفة الرسمية وحدها «المتطلبات» وتجاهل قصص المستخدم والتصاميم وعقود الواجهات البرمجية والقرارات المتخذة في المحادثات، أو العكس: اختبار قصة دون فتح التصميم والعقد اللذين يضيفان تفاصيلها.
- قراءة تفاصيل مستوى النظام فقط وتخطّي هدف العمل، فلا تعرف أي الإخفاقات أخطر، ولا إن كانت الميزة تحل المشكلة أصلاً.
- انتظار البناء قبل قراءة المتطلبات، وهذا يفوّت أرخص لحظة لاكتشاف متطلب مفقود أو متناقض.
- سدّ الفجوات بافتراضاتك بصمت؛ فيفحص الاختبار عندها تخمينك لا السلوك المتفق عليه. اسأل، واكتب الإجابة في المتطلب أو القصة.
- الاختبار مقابل إصدار قديم: المتطلبات تتغيّر، فتحقّق من إصدار القصة أو المواصفة أو التصميم الذي تستخرج منه اختباراتك أو من تاريخه.
- الاعتقاد بأن ما لم يُكتب غير مطلوب. فالتوقعات غير المكتوبة، مثل عدم ضياع البيانات والالتزام بالقانون والاتساق مع المنصة، متطلبات ضمنية، ويمكن الإبلاغ عن المنتج إذا خالفها.
من منظور ضمان الجودة
في فريق العمل الحقيقي ينضم المختبِر إلى حوار المتطلبات مبكراً: في جلسات التنقيح، وفي جلسات «الأصدقاء الثلاثة» (Three Amigos) مع مالك المنتج ومطور، أو في مراجعة المواصفة. اسأل مالك المنتج أو محلل الأعمال عن مستويي العمل والمستخدم («من يحتاج هذا، وكيف سنعرف أنه نجح؟»)، واسأل المطورين أو المعماريين عن مستوى النظام («ما الحدود، وماذا يحدث عند الإخفاق؟»). وكثيراً ما يكون فريق الدعم والأشخاص الذين سيستخدمون المنتج أفضل مصدر للاحتياجات الحقيقية.
دوّن أولاً بأول: سجّل معرّف كل متطلب تختبر مقابله وإصداره، وضع كل سؤال وإجابته في القصة أو التذكرة لا في ذاكرتك أو في محادثة خاصة، واربط حالات الاختبار وتقارير الأخطاء بمعرّفات المتطلبات. وحين تكون المتطلبات شحيحة، اكتب فهمك في قائمة قصيرة من السلوكيات المتوقعة واطلب من مالك المنتج تأكيدها؛ فالاختبار مقابل افتراضات غير مؤكدة خطر تذكره في تقرير الاختبار.
تمرين عملي
صنّف مجموعة متطلبات حسب المستوى والمصدر والشكل
تضيف سلسلة صيدليات خدمة تجديد الوصفات الطبية عبر تطبيقها. اقرأ العبارات الست أدناه، وحدّد لكل منها مستواها (عمل أو أصحاب مصلحة أو نظام)، واذكر مصدرها وشكلها المرجّحين، واكتب سؤالاً واحداً يطرحه المختبِر قبل تصميم الاختبارات.
ثم افحص المجموعة من الأعلى إلى الأسفل ومن الأسفل إلى الأعلى، وسمِّ أي احتياج لا يوجد تحته شيء.
الميزة: تجديد الوصفات عبر الإنترنت (تطبيق الصيدلية)
R1 خفض المكالمات الهاتفية إلى فروعنا بشأن تجديد الوصفات إلى النصف خلال سنة.
R2 بصفتي مريضاً، أريد طلب تجديد وصفتي من هاتفي كي لا أضطر إلى الاتصال
بالفرع.
R3 بصفتي صيدلياً، أريد قائمة واحدة بطلبات التجديد في فرعي، مرتبة حسب وقت
الاستلام، كي أجهّزها بالترتيب.
R4 يجب أن يعرض التطبيق فقط الوصفات التي بقي لها تجديد ولم تنتهِ صلاحيتها.
R5 يجب أن يرسل التطبيق إشعاراً فورياً عندما تتغير حالة طلب التجديد إلى
«جاهز للاستلام».
R6 يجب أن تُخزَّن بيانات الوصفات وتُعالَج وفق اللائحة الوطنية لحماية
البيانات الصحية.- صنّف كل عبارة حسب مستواها: عمل، أو أصحاب مصلحة (مستخدم)، أو نظام.
- دوّن المصدر المرجّح (من أو ما الذي جاءت منه) والشكل الذي كُتبت به.
- اربط كل متطلب نظام بالاحتياج الذي يخدمه، وكل احتياج بهدف العمل.
- علّم أي احتياج لا يوجد تحته شيء، واكتب سؤالاً واحداً لكل عبارة.
إظهار الإجابة النموذجية
المستويات: R1 متطلب عمل (هدف للسلسلة من الإدارة، يُكتب عادةً في دراسة جدوى أو في هدف المشروع). وR2 وR3 متطلبات أصحاب مصلحة (مستخدم)، من المرضى والصيادلة عبر مالك المنتج، مكتوبة في صورة قصص مستخدم. وR4 وR5 متطلبات نظام، من مالك المنتج والمطورين، في مواصفة أو ضمن معايير قبول R2. أما R6 فقيد على مستوى النظام مصدره لائحة تنظيمية، وشكله هنا عبارة «يجب أن» تحيل إلى نص قانوني.
الروابط: R4 وR5 يخدمان R2، وR2 يخدم R1. أما R3 فيخدم R1 بصورة غير مباشرة فقط: حين تكون الطلبات جاهزة في وقت الاستلام، يقلّ ما يدفع المرضى إلى الاتصال. ولا يخدم R6 أي احتياج للمستخدم، وهذا ليس فجوة: فالقيد يُتتبَّع إلى مصدره، وهو هنا اللائحة، لا إلى قصة. الفجوة: لا شيء على مستوى النظام يحقق R3، فلا يوجد متطلب يصف قائمة الصيدلي ولا ترتيبها ولا مرشّحاتها. أثِرها في تعليق مراجعة.
الأسئلة: R1: كيف تُحصى المكالمات اليوم، وما عددها الحالي؟ R2: على أي منصات يعمل التطبيق، وهل يلزم تسجيل الدخول؟ R3: بأي ترتيب تظهر الطلبات التي لا وقت استلام لها، وهل يرى الصيدلي فروعاً أخرى؟ R4: هل تُعرض وصفة تنتهي صلاحيتها اليوم؟ R5: ماذا يحدث إذا أوقف المريض الإشعارات؟ R6: أي لائحة وأي مواد تنطبق، وما مدة الاحتفاظ ببيانات التجديد؟
يمكن تحويل R4 وR5 إلى شروط اختبار الآن، أما R3 فلا يمكن اختباره قبل وجود متطلب النظام الخاص به، وR1 يُقاس بعد الإصدار لا بحالة اختبار.
أسئلة شائعة
هل قصة المستخدم متطلب؟
نعم. قصة المستخدم شكل شائع لمتطلبات أصحاب المصلحة (المستخدم)، لكنها وحدها قليلة التفاصيل؛ فالتفاصيل تأتي من معايير القبول والأمثلة والحوار الدائر حولها. ولقصص المستخدم درس خاص لاحقاً في هذه الوحدة.
مقابل ماذا أختبر إذا لم توجد متطلبات مكتوبة؟
مقابل ما اتفق عليه الفريق: الحوارات، والتصاميم، والنظام القائم، والمنتجات المشابهة، واللوائح، والتوقعات المعقولة للمستخدمين. اكتب فهمك في قائمة قصيرة من السلوكيات المتوقعة، واطلب من مالك المنتج تأكيدها، وأبلغ عن أي سلوك اختبرته مقابل افتراض غير مؤكد.
هل تُختبر متطلبات العمل؟
ليس عادةً بحالة اختبار قبل الإصدار، بل تُفحص بقياس النتائج بعد الإصدار، وهذا من صور التحقق من الصلاحية. وقبل الإصدار يستخدمها المختبِر لتحديد الأولويات، وللتأكد من أن النظام يسجّل البيانات اللازمة لقياسها.
هل المتطلب هو نفسه المواصفة؟
ليس تماماً. المتطلب احتياج أو شرط واحد، أما المواصفة فوثيقة تجمع المتطلبات، ومعها غالباً معلومات أخرى مثل السياق والتعريفات والتصاميم. والمواصفة الواحدة تضم عادةً متطلبات كثيرة، وقد يتوزع المتطلب الواحد على قصة وتصميم وعقد.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- The 2020 Scrum Guideتعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
تدرّب بأدوات متقن
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
اشتق سيناريوهات اختبار من المتطلبات الوظيفية مع خريطة للتغطية.
اشتق سيناريوهات اختبار شاملة (end-to-end) من قصة مستخدم، بما فيها التدفقات البديلة والاستثنائية.
عرض مواصفة OpenAPI 3.x / Swagger 2.0 (بصيغة JSON أو YAML) كتوثيق قابل للتصفح لنقاط النهاية.
اعثر على المتطلبات المفقودة — معالجة الأخطاء والصلاحيات والظروف الحدّية والاحتياجات غير الوظيفية — باستخدام الذكاء الاصطناعي من متقن.
للتعمّق أكثر
- كيف تراجع المتطلباتكيف تراجع المتطلبات وقصص المستخدم: قائمة تحقق من 8 معايير، والكلمات المنذرة، ومثال عملي بتعليقات مراجعة واقعية، ودور أدوات الذكاء الاصطناعي.
- الاختبار الساكنما الذي يمكن اختباره ساكناً، وما الذي يكتشفه عادةً
- دورة حياة اختبار البرمجيات (STLC)المرحلة 1 — تحليل المتطلبات (تحليل الاختبار)
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.