ما هي المتطلبات؟

ما هي المتطلبات؟

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

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

المستويات الثلاثة للمتطلبات

تخيّل عيادة طبية متنامية قررت استبدال دفتر المواعيد الورقي بنظام حجز رقمي. ستدور ثلاثة محادثات مختلفة تماماً:

• متطلبات الأعمال — يقول مدير العيادة: "نحتاج إلى تقليل حالات الغياب عن المواعيد بنسبة 30٪ وإتاحة الحجز للمرضى خارج أوقات العمل." هذا متطلب أعمال. يعبّر عن هدف أو مشكلة أو فرصة على المستوى المؤسسي. لا يخبر فريق التطوير بما يجب بناؤه، بل يخبرهم لماذا يبنونه. تخص متطلبات الأعمال الرعاة التنفيذيين وكبار أصحاب المصلحة.
• متطلبات المستخدمين — تقول موظفة الاستقبال: "أحتاج إلى عرض جميع مواعيد اليوم على شاشة واحدة، وإلغاء الحجز بنقرة واحدة، وإرسال رسالة تذكير للمريض عبر الرسائل القصيرة." هذا متطلب مستخدم (يُسمى أحياناً متطلب صاحب المصلحة). يصف ما يحتاج شخص بعينه أن يفعله مع النظام. تُكتب متطلبات المستخدمين بلغة بسيطة، وكثيراً ما تُصاغ كحالات استخدام أو قصص مستخدم.
• متطلبات النظام — يقول المطوّر: "يجب على النظام إرسال إشعار عبر الرسائل القصيرة قبل الموعد بـ24 ساعة على الأقل. يجب أن تستجيب واجهة برمجة تطبيقات الحجز في أقل من 200 مللي ثانية تحت حمل متزامن من 500 مستخدم. يجب تشفير سجلات المرضى في حالة السكون باستخدام AES-256." هذه متطلبات نظام. تحدد بدقة ما يجب أن يفعله البرنامج (المتطلبات الوظيفية) وكيف يجب أن يفعله (المتطلبات غير الوظيفية). متطلبات النظام هي المدخل المباشر لمرحلتي التصميم والبناء.

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

داخل مستوى متطلبات النظام، يُحدث المحللون تمييزاً بالغ الأهمية:

• المتطلبات الوظيفية تصف ما يفعله النظام — السلوكيات والقواعد والتحولات التي يجب أن يؤديها. مثال: "يجب أن يتيح النظام للمريض المسجَّل إلغاء حجزه حتى ساعتين قبل الموعد المحدد."
• المتطلبات غير الوظيفية تصف مدى جودة أدائه — سمات الجودة كالأداء والأمان وقابلية التوسع والتوافر وسهولة الاستخدام والامتثال. مثال: "يجب تسليم بريد تأكيد الإلغاء الإلكتروني في غضون 30 ثانية من إجراء المستخدم في 99٪ من الحالات."

من الأخطاء الشائعة الاكتفاء بالمتطلبات الوظيفية ومعالجة المتطلبات غير الوظيفية كأمر ثانوي. في الواقع العملي، كثيراً ما تُحرّك المتطلبات غير الوظيفية القرارات المعمارية أكثر مما تفعله أي ميزة وظيفية. فمتجر إلكتروني يستقبل 10,000 عملية دفع متزامنة خلال تخفيضات مفاجئة يحتاج معمارية مختلفة تماماً عن متجر لا يتجاوز 50 عملية يومياً — حتى لو كانت المتطلبات الوظيفية متطابقة.

لماذا يصعب استخلاص المتطلبات؟

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

1. فجوة المعرفة. أصحاب المصلحة خبراء في مجالهم لكنهم ليسوا مفكرين في منظومات. يعرفون ما يفعلونه يومياً، لكنهم يعجزون عن صياغته بشكل يمكن للمحلل أو المطوّر التصرف بناءً عليه. قد لا يدرك موزّع الشحنات في شركة لوجستية أنه يطبّق عشرات من القواعد الذهنية عند توزيع المسارات — حتى تراقبه وهو يعمل.
2. فجوة التواصل. يستخدم المحللون والمطوّرون مصطلحات تقنية؛ ويستخدم المستخدمون من قطاع الأعمال مصطلحات متخصصة بمجالهم. قد تعني الكلمة ذاتها شيئاً مختلفاً تماماً. في إحدى شركات اللوجستيك، كان "تاريخ التسليم" يعني لفريق العمليات اليوم الذي غادرت فيه البضاعة المستودع، بينما يعنيه لفريق الحسابات اليوم الذي وقّع فيه الزبون على الإيصال — وهو فارق أفضى إلى أشهر من أخطاء التسوية.
3. مشكلة المعرفة الضمنية. كثير مما يعرفه الخبراء يكمن في اللاوعي. لا يستطيعون إخبارك بما يعرفونه لأنهم غير مدركين لمعرفتهم أصلاً. كثيراً ما تكون المراقبة والنمذجة الأولية السبيل الوحيد لاستخراج هذه المعرفة الخفية.
4. تغيّر سياق الأعمال. تتحول أهداف العمل خلال المشروع. فخط أساس المتطلبات المتفق عليه في يناير قد يكون جزء منه متجاوَزاً بحلول يونيو. إدارة التغيير دون السماح بتمدد النطاق تحدٍّ دائم.
5. أصحاب مصلحة متعددون ومتعارضون. مدير العيادة يريد مواعيد أقصر لتعظيم الطاقة الإنتاجية. الطبيب يريد مواعيد أطول للحالات المعقدة. المريض يريد أوقاتاً مناسبة. مدير تقنية المعلومات يريد تطويراً مخصصاً أقل ما يمكن. الموازنة بين هذه المصالح المتنافسة تتطلب التفاوض لا مجرد التوثيق.

المتطلبات في السياق: مثال واقعي

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

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

ملخص

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