جمع المتطلبات: كيف تتجنب بناء النظام الخطأ

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

جمع المتطلبات (Requirements Gathering) هو الخطوة التي تحوّل احتياج أعمال غامضاً إلى مواصفات واضحة يمكن تصميمها وبرمجتها. جودة هذه الخطوة تحدد مباشرة ما إذا كان النظام النهائي سيُستخدم فعلياً، أو سينتهي به الحال مهجوراً رغم أنه "يعمل" تقنياً.

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

المتطلبات الوظيفية (Functional Requirements) تصف ماذا يفعل النظام: "يجب أن يتمكن المستخدم من تصدير تقرير بصيغة PDF". المتطلبات غير الوظيفية (Non-Functional Requirements) تصف كيف يعمل النظام: السرعة، الأمان، عدد المستخدمين المتزامنين الذي يجب أن يتحمّله، ووقت التعطل المسموح به. إهمال النوع الثاني ينتج أنظمة تعمل وظيفياً لكنها تنهار تحت الاستخدام الفعلي.

من تسأل، ومتى

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

تقنيات عملية لجمع متطلبات دقيقة

• المقابلات المنظّمة: أسئلة محددة مسبقاً تغطي كل جانب من العملية، لا نقاشاً حراً قد يفوّت تفاصيل مهمة.
• الملاحظة الميدانية: مشاهدة الموظف وهو ينفذ المهمة فعلياً غالباً تكشف خطوات لا يذكرها أحد لأنها "بديهية" بالنسبة له.
• ورش العمل الجماعية: تجمع أصحاب مصلحة من أقسام مختلفة في جلسة واحدة، فتكشف تعارضات في الفهم لم تكن ظاهرة في مقابلات منفصلة.
• نماذج أولية سريعة (Prototypes): عرض شاشة تقريبية للنظام يجعل أصحاب المصلحة يتذكرون تفاصيل لم يذكروها حين كان السؤال مجرداً.

الأخطاء الشائعة

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

الخلاصة

• اجمع المتطلبات الوظيفية وغير الوظيفية معاً، فكلاهما يحدد نجاح النظام.
• وثّق كل متطلب بصياغة قابلة للاختبار: "يجب أن يُنجز الطلب خلال 3 ثوانٍ" وليس "سريع".
• تحقق من فهمك للمتطلبات مع أصحاب المصلحة قبل تسليمها لفريق التصميم.