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

لماذا يهم

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

بالنسبة إلى المختبِر، لا يصلح المتطلب أساساً للاختبار (Test Basis) إلا إذا أمكن أن تُستخرج منه نتيجة متوقعة. وعبارة «يجب أن تكون الصفحة سريعة» لا تعطي أي نتيجة. والحصول على المتطلبات غير الوظيفية مكتوبة بأرقام قبل بدء التطوير هو ما يجعلها قابلة للاختبار.

المتطلبات الوظيفية: ماذا يفعل النظام

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

• التحقق من المدخلات: حقل الرمز البريدي لا يقبل إلا صيغ دول التوصيل.
• قواعد العمل: الطلبات بقيمة ⁦300⁩ ريال فأكثر توصيلها مجاني (ويتناول الدرس التالي قواعد العمل).
• سير العمل: ينتقل الطلب من «مدفوع» إلى «تم الشحن» عندما يمسح المستودع الطرد.
• المخرجات والتكامل: رسائل التأكيد، والفواتير، واستدعاء مزوّد الدفع.
• الصلاحيات والأخطاء: لا يرى سجل الطلبات إلا صاحب الحساب، والدفع المرفوض يُبقي السلة كما هي.

جرّبها: المتطلبات ← حالات اختبار جرّبها: المتطلبات ← سيناريوهات اختبار

المتطلبات غير الوظيفية: مدى جودة ما يفعله

المتطلب غير الوظيفي لا يضيف سلوكاً، بل يحدد مستوى الجودة الذي يجب أن يبلغه السلوك. وبمصطلحات ISO/IEC 25010:2023 التي مرّت في درس جودة البرمجيات، تنتمي المتطلبات الوظيفية إلى الملاءمة الوظيفية (Functional Suitability)، وغير الوظيفية إلى الخصائص الثماني الأخرى. وتُدرج بعض الفرق القيود (Constraints) منفصلة، مثل قاعدة بيانات مفروضة أو لائحة تنظيمية.

وكثير من المتطلبات غير الوظيفية يشمل ميزات عديدة: فهدف زمن الاستجابة أو المطابقة لمعيار WCAG ينطبق على كل صفحة، لذا مكانه قائمة مشتركة لمتطلبات الجودة أو «تعريف الإنجاز» (Definition of Done)، لا قصة واحدة. وهي تُفحص بقياس قيمة تحت ظروف محددة، وغالباً باختبارات وأدوات متخصصة؛ وبعضها، مثل التوافر الشهري، لا يُؤكَّد إلا بالمراقبة في بيئة الإنتاج. أمثلة من المتجر نفسه:

• كفاءة الأداء (Performance Efficiency): يجيب البحث خلال ⁦1.5⁩ ثانية عند المئين ⁦95⁩ (95th percentile) مع ⁦200⁩ مستخدم متزامن.
• الأمان (Security): تنتهي الجلسة بعد ⁦15⁩ دقيقة دون نشاط.
• الموثوقية (Reliability): يكون إتمام الشراء متاحاً ⁦99.9%⁩ من كل شهر، باستثناء الصيانة المُعلن عنها.
• قابلية التفاعل (Interaction Capability): تطابق صفحات إتمام الشراء معيار WCAG 2.2 بالمستوى AA.
• التوافق (Compatibility)، ويضعه ISO/IEC 25010 تحت المرونة (Flexibility): يعمل المتجر في آخر إصدارين رئيسيين من Chrome وSafari وFirefox وEdge.

كيف تجعل المتطلب غير الوظيفي قابلاً للقياس

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

الأرقام قرارات عمل: المختبِر يقترح ويسأل، ومالك المنتج يقرر، ويُسجَّل القرار مع المتطلب. وقبل أن يقترح المختبِر رقماً، يتأكد أيضاً من أن بلوغه ممكن أصلاً، كما يبيّن المثال التطبيقي أدناه.

جرّبها: محلّل زمن الاستجابة

مثال تطبيقي: مسودة بوابة الواجبات المدرسية

تطلب مدرسة بوابة لتسليم الواجبات، ويتسلّم المختبِر هذه المسودة قبل بدء التطوير. حدّد لكل سطر هل هو وظيفي أم غير وظيفي، وهل يمكنك اختباره بصيغته الحالية.

بوابة الواجبات: مسودة المتطلبات
H1  يستطيع الطالب رفع ملف واحد لكل واجب حتى الموعد النهائي.
H2  الصيغ المقبولة PDF وDOCX، بحجم أقصاه 20 MB.
H3  بعد الموعد النهائي يُعطَّل زر «رفع» وتظهر عبارة «انتهى التسليم».
H4  لا يفتح التسليم إلا الطالب ومعلّمو المقرر.
H5  يجب أن يكون الرفع سريعاً.
H6  يجب أن تكون البوابة متاحة في أسابيع الامتحانات.
H7  يجب أن تعمل البوابة على الهواتف.

تتمة المثال: الفرز وإعادة الصياغة

المتطلبات من H1 إلى H3 وظيفية: لكل منها إجراء ونتيجة قابلة للملاحظة. أما H4 فيقع على الحد بين النوعين: فهو يحمي الأمان (السرية)، لكنه مكتوب سلوكاً ويُختبر كالمتطلب الوظيفي: افتح تسليم طالب آخر وتوقّع الرفض. وتضعه الفرق تحت هذا التصنيف أو ذاك؛ والمهم أنه قابل للاختبار بصيغته الحالية. أما H5 إلى H7 فغير وظيفية ولا يمكن اختبارها بصيغتها الحالية. ويقترح المختبِر قيماً لتؤكدها المدرسة:

• H5، كفاءة الأداء: عندما يرفع ⁦300⁩ طالب في الوقت نفسه، يُؤكَّد استلام ملف حجمه ⁦20⁩ MB مُرسَل عبر اتصال سرعته ⁦10⁩ Mbit/s خلال ⁦30⁩ ثانية من الضغط على زر «رفع» في ⁦95%⁩ من عمليات الرفع. فالنقل وحده يستغرق ⁦16⁩ ثانية على الأقل، لذا لا يمكن أبداً بلوغ هدف أقل من ذلك.
• H6، الموثوقية: من الساعة ⁦06:00⁩ إلى ⁦24:00⁩ في أسابيع الامتحانات تكون البوابة متاحة ⁦99.5%⁩ من الوقت، ويُقاس ذلك بفحص خارجي كل دقيقة.
• H7، التوافق (المرونة في ISO/IEC 25010): يعمل الرفع والتنزيل في آخر إصدارين رئيسيين من Chrome على Android وSafari على iOS.
• الناقص: هدف لإمكانية الوصول، ومدة الاحتفاظ بالملفات.

جرّبها: مولّد سيناريوهات الاختبار جرّبها: محلّل فجوات المتطلبات بالذكاء الاصطناعي

أسئلة شائعة

المراجع

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