وصف المتطلبات بطريقة سيئة هي أحد أهم أسباب فشل معظم المشاريع البرمجية، كما أن معدل الفشل مرتفع جدًا في صناعة تكنولوجيا المعلومات، لذلك فكرت في إبراز الجوانب الرئيسية لمتطلبات البرمجية، والتي تجعل من المتطلبات جيدة وجديرة.
خصائص المتطلبات الفعالة:
1- خالية من الغموض:
يجب أن يكون هناك طريقة واحدة فقط لتفسير المتطلب. في بعض الأحيان يتم تقديم الغموض من خلال الاختصارات غير المحددة، مثلاً:
- يجب تنفيذ النظام باستخدام (ASP).
هل تعني كلمة (ASP) صفحات الخادم النشطة أو موفر خدمة التطبيق؟ لإصلاح ذلك، يمكننا ذكر الاسم كاملا وتقديم الاختصار بين قوسين:
- يجب تنفيذ النظام باستخدام صفحات الخادم النشطة (ASP).
إليك مثال آخر:
- يجب ألا يقبل النظام كلمات المرور التي تزيد عن (15) حرفًا.
ليس من الواضح ما يفترض أن يفعله النظام: هل يجب ألا يسمح النظام للمستخدم بإدخال أكثر من (15) حرفًا؟ هل يقوم النظام باقتطاع سلسلة الاحرف اوتوماتيكيا التي تم إدخالها بعد (15) حرفًا؟ أو هل يجب أن يعرض النظام رسالة خطأ إذا قام المستخدم بإدخال أكثر من (15) حرفًا؟
تصحيح المتطلب يكون بتوضيحه:
- يجب ألا يقبل النظام كلمات المرور التي تزيد عن (15) حرفًا. إذا أدخل المستخدم أكثر من (15) حرفًا أثناء اختيار كلمة المرور، فستظهر رسالة خطأ تطلب من المستخدم تصحيحها.
كما يمكن إدخال بعض الغموض من خلال وضع كلمة معينة، فعلى سبيل المثال:
- في شاشة “الرحلة المخزنة”، يمكن للمستخدم عرض سجل واحد فقط.
هل هذا يعني أنه يمكن للمستخدم “العرض فقط” ، وليس الحذف أو التحديث، أم يعني أنه يمكن للمستخدم عرض سجل واحد فقط وليس اثنين أو ثلاثة؟ تتمثل إحدى طرق حل المشكلة في إعادة كتابة المتطلب من وجهة نظر النظام:
- في شاشة “الرحلة المخزنة”، يعرض النظام رحلة واحدة فقط.
2- قابل للاختبار (يمكن التحقق منه):
يجب أن يكون المختبرين قادرين على التحقق مما إذا تم تنفيذ المتطلب بشكل صحيح، ويجب أن ينجح الاختبار أو يفشل. ولتكون قابلة للاختبار، يجب أن تكون المتطلبات واضحة ودقيقة ولا لبس فيها. يمكن لبعض الصفات أن تجعل أحد المتطلبات غير قابل للاختبار، مثل: قوية، آمنة، دقيقة، فعالة، قابلة للتوسيع، مرنة، قابلة للصيانة، موثوقة، سهلة الاستخدام، كافية، بسرعة وأمان وفي الوقت المناسب. وكلمات أو اختصارات غير محددة أيضا، مثل: إلخ، و، أو، ويتم تحديدها لاحقًا. كما في هذا المتطلب:
- يجب أن تسمح أداة البحث للمستخدم بالعثور على الحجز بناءً على اسم العائلة والتاريخ وما إلى ذلك.
في هذا المتطلب، يجب إدراج جميع معايير البحث بشكل صريح. لا يستطيع المصمم والمطور تخمين ما يعنيه المستخدم بعبارة “إلخ”.
مشاكل أخرى قد تجعل من المتطلب غير قابل للاختبار من خلال الكلمات أو الصياغة الغامضة، العبارات: عند الاقتضاء، حسب الاقتضاء، إذا لزم الأمر، يجب النظر فيها. وصيغة المبني للمجهول: يكون موضوع الجملة الفعل فقط، بدلاً من، مَن هو الذي يقوم بتنفيذه. كما أن الضمائر: أي شخص، أي شيء، البعض، شخص ما. المتطلبات التالية توضح متطلبات غير قابلة للاختبار وتصحيحها:
- يجب إدخال رمز المطار. والمتطلب الصحيح يكون: يجب على المستخدم إدخال رمز المطار.
- يجب أن يتحمّل النظام الاستخدام المتزامن للعديد من المستخدمين. والمتطلب الصحيح يكون: يجب أن يتحمّل النظام الاستخدام المتزامن لـ (1000) من المستخدمين.
يُظهر المثال الأول أعلاه، مثالًا كلاسيكيًا على المبني للمجهول. فمن الذي يجب أن يدخل هذا الرمز هل هو النظام أم المستخدم؟، أما في المثال الثاني ما الرقم الذي يجب اعتباره “بالعديد” هل هو “10، أم 100، أم 1000″؟
3- واضح (موجز، بسيط، دقيق):
يجب ألا تحتوي المتطلبات على كلام أو معلومات غير ضرورية، إذ يجب ذكرها بوضوح وبساطة، ففي المثال التالي:
- في بعض الأحيان يقوم المستخدم بإدخال رمز المطار، والذي سيفهمه النظام، ولكن في بعض الأحيان قد تحل أقرب مدينة محلها، لذلك لا يحتاج المستخدم إلى معرفة رمز المطار، وسيظل مفهومه من قبل النظام.
يمكن استبدال هذه الجملة بعبارة أبسط:
- يجب أن يحدد النظام المطار بناءً على رمز المطار أو اسم المدينة.
4- صحيح:
إذا كان أحد المتطلبات يحتوي على حقائق، فيجب أن تكون هذه الحقائق صحيحة، فعلى سبيل المثال:
- يجب أن تُظهر أسعار تأجير السيارات جميع الضرائب المطبّقة (بما في ذلك ضريبة الولاية بنسبة “6٪”).
تعتمد الضريبة على الولاية، لذا فإن رقم “6٪” المقدم غير صحيح، ويتم تصحيح المتطلب بحذف الرقم.
5- مفهوم:
يجب أن تكون المتطلبات صحيحة نحويًا ومكتوبة بأسلوب متسق، ويجب استخدام الاصطلاحات القياسية. فمثلا يجب استخدام كلمة “shall” بدلاً من “will” أو “must” أو “may”.
6- ممكن تطبيقه (واقعي):
يجب أن يكون المتطلب قابلاً للتنفيذ في ظل القيود الحالية مثل الوقت والمال والموارد المتاحة، مثلا:
- يجب أن يحتوي النظام على واجهة لغة طبيعية ستفهم الأوامر المقدمة باللغة الإنجليزية.
في المثال أعلاه، قد لا يكون هذا المطلب ممكنًا في غضون فترة قصيرة من وقت التطوير، فيتم إما حذفه أو التعديل عليه بما يتناسب مع الفترة الزمنية.
7- مستقل:
لفهم المتطلبات، لا ينبغي أن تكون هناك حاجة لمعرفة أي متطلبات أخرى، على سبيل المثال:
- يجب أن تتضمن قائمة الرحلات المتاحة أرقام الرحلات ووقت المغادرة ووقت الوصول لكل جزء من الرحلة.
- يجب فرزها حسب السعر.
يشير الضمير في كلمة “فرزها ” في الجملة الثانية إلى متطلب سابق، مع ذلك، إذا تغير ترتيب المتطلبات، فلن يكون هذا المطلب مفهومًا.
8- الذَرّي:
يجب أن يحتوي المتطلب على عنصر واحد يمكن تتبعه، أي يجب أن يوضح المتطلب حاجة أو سمة جودة واحدة لصاحب المصلحة، واذا كان يحتوي المتطلب على اكثر من حاجة أو سمة يتم تقسيمهم، فمثلا:
- يجب أن يوفر النظام الفرصة لحجز الرحلة وشراء تذكرة وحجز غرفة في فندق وحجز سيارة وتقديم معلومات حول أماكن الجذب.
يجمع هذا المطلب بين خمسة متطلبات ذرية، مما يجعل التتبع صعبًا للغاية، يجب مراجعة الجمل التي تتضمن الكلمات “و” أو “لكن” لمعرفة ما إذا كان يمكن تقسيمها إلى متطلبات ذرية أخرى.
9- ضروري:
الشرط غير ضروري إذا كان لا يحتاج أي من أصحاب المصلحة المتطلب أو إذا كان لن تؤثر إزالة المتطلب على النظام. مثال على متطلب لا يحتاجه أصحاب المصلحة هو مطلب تمت إضافته بواسطة المطورين والمصممين؛ لأنهم يفترضون أن المستخدمين أو العملاء يريدون ذلك. على سبيل المثال، حقيقة أن المطور يعتقد أن المستخدمين يرغبون في ميزة عرض خريطة للمطار ويعرف كيفية تنفيذها ليس سببًا صالحًا لإضافة هذا المطلب.
10- ملخص:
يجب ألا تحتوي المتطلبات على معلومات التصميم والتنفيذ الغير ضرورية:
- يجب تخزين معلومات المحتوى في “text file“.
تكون كيفية تخزين المعلومات واضحة للمستخدم ويجب أن يكون قرار مصمم البرمجيات.
11- متناسق:
يجب ألا يكون هناك أي تعارض بين المتطلبات، قد يكون التعارض مباشرة أو غير مباشرة. تحدث التعارضات المباشرة عندما يُتوقع في نفس الموقف سلوك مختلف:
- يجب عرض التواريخ بتنسيق (الشهر/ اليوم/ السنة).
- يجب عرض التواريخ بتنسيق (اليوم/ الشهر/ السنة).
في بعض الأحيان يكون من الممكن حل التناقض من خلال تحليل الظروف التي يتم فيها المتطلب، فعلى سبيل المثال، إذا تم تقديم المتطلب الأول من قبل مستخدم أمريكي (في المثال أعلاه)، وتم تقديم المتطلب الثاني بواسطة مستخدم فرنسي، فيمكن إعادة كتابة المتطلبات السابقة على النحو التالي:
- بالنسبة للمستخدمين في الولايات المتحدة، يجب عرض التواريخ بتنسيق (الشهر/ اليوم/ السنة).
- بالنسبة للمستخدمين في فرنسا، يجب عرض التواريخ بتنسيق (اليوم/ الشهر/ السنة).
يمكن أن يؤدي هذا في النهاية إلى المتطلب التالي:
- يجب عرض التواريخ بناءً على تنسيق التاريخ المحدد في متصفح الويب الخاص بالمستخدم.
