جمع المتطلبات ( Requirements Gathering )

تعرف على مفهوم جمع المتطلبات (Requirements Gathering) في هندسة البرمجيات، أنواعه، أهم الوثائق مثل SRS وURS، وأفضل الممارسات لتحليل احتياجات المستخدمين وضمان نجاح المشاريع البرمجية.

مقدمة

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

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

ما هو جمع المتطلبات؟ (What is Requirements Gathering?)

جمع المتطلبات (Requirements Gathering) هو عملية تحديد، وتحليل، وتوثيق ما يجب أن يفعله النظام البرمجي لتحقيق أهداف المستخدمين والجهات المعنية (Stakeholders).

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

يمكن القول إن جمع المتطلبات هو “المرحلة الاستراتيجية” في دورة حياة تطوير البرمجيات (SDLC).

أهمية جمع المتطلبات في هندسة البرمجيات

تُظهر الدراسات أن أكثر من 60٪ من فشل المشاريع البرمجية يعود إلى ضعف في تحليل أو توثيق المتطلبات.
ولهذا السبب تعتبر هذه المرحلة من أهم مراحل SDLC لأنها:

• تمنع حدوث سوء الفهم بين العميل والفريق التقني.
• تقلل التكلفة الزمنية والمادية الناتجة عن إعادة العمل.
• تضمن أن المنتج النهائي يلبي احتياجات المستخدم الحقيقية.
• تسهل التخطيط للاختبار (Testing Planning) لاحقًا.
• تشكل أساسًا لتقدير التكلفة والجدول الزمني بدقة.

أنواع المتطلبات (Types of Requirements)

تنقسم المتطلبات في هندسة البرمجيات إلى نوعين رئيسيين:

1. المتطلبات الوظيفية (Functional Requirements)

هي المتطلبات التي تحدد ما الذي يجب أن يفعله النظام.
مثال: “يجب أن يتمكن المستخدم من تسجيل الدخول باستخدام البريد الإلكتروني وكلمة المرور.”

تشمل أمثلة أخرى:

• معالجة الطلبات (Order Processing)
• تسجيل المستخدمين (User Registration)
• إدارة الحسابات (Account Management)

2. المتطلبات غير الوظيفية (Non-Functional Requirements)

هي المتطلبات التي تحدد كيف يجب أن يعمل النظام وليس ما الذي يفعله.
تركز على الأداء (Performance)، الأمان (Security)، وسهولة الاستخدام (Usability).

أمثلة:

• يجب ألا يتجاوز زمن تحميل الصفحة 2 ثانية.
• يجب أن يدعم النظام 10,000 مستخدم في نفس الوقت.
• يجب أن تكون واجهة المستخدم سهلة التصفح.

وثائق المتطلبات (Requirements Documents)

عند الانتهاء من جمع وتحليل المتطلبات، يتم توثيقها في وثائق رسمية تُعتبر مرجعًا رئيسيًا للمطورين والمصممين والمختبرين.
أهم هذه الوثائق هي:

وثيقة SRS هي الأهم في هذه المرحلة، لأنها الأساس الذي يُبنى عليه التصميم والتطوير والاختبار لاحقًا.

خطوات جمع المتطلبات (Steps of Requirements Gathering)

1. تحديد أصحاب المصلحة (Identify Stakeholders)

هُم جميع الأشخاص أو الجهات التي لها مصلحة في المشروع، مثل:

• العميل (Client)
• المستخدم النهائي (End User)
• مدراء المشاريع (Project Managers)
• مهندسو النظم (System Engineers)

2. تحديد الأهداف والغايات (Define Goals and Objectives)

يجب تحديد ما الذي يسعى المشروع لتحقيقه على المستويين:

• الهدف (Goal): النتيجة الكبرى مثل “تحسين تجربة العملاء.”
• الغاية (Objective): خطوات قابلة للقياس مثل “تقليل وقت تسجيل الدخول إلى 3 ثوانٍ.”

3. الاستقصاء (Elicitation)

وهي عملية جمع المعلومات من أصحاب المصلحة باستخدام أدوات مثل:

• المقابلات (Interviews)
• الاستبيانات (Questionnaires)
• تحليل الوثائق الحالية (Document Analysis)
• الملاحظة المباشرة (Observation)
• ورش العمل (Workshops)

تسمى هذه المرحلة أحيانًا “استخراج المتطلبات” لأنها تركز على طرح الأسئلة الصحيحة وليس الافتراضات.

4. التوثيق (Documentation)

بعد جمع البيانات، يتم توثيق المتطلبات في وثائق رسمية (مثل SRS) بصيغة منظمة وواضحة.
يُفضل استخدام أدوات مثل Confluence أو Notion لتوثيق المتطلبات ومشاركتها بسهولة مع الفريق.

5. التحليل والتأكيد (Analysis & Validation)

يتم تحليل المتطلبات لاكتشاف أي غموض أو تعارض، ثم تأكيدها مع العميل قبل الانتقال إلى مرحلة التصميم.
التحليل الجيد يتأكد من أن كل متطلب:

• مفهوم (Understandable)
• قابل للتحقق (Verifiable)
• قابل للتنفيذ (Feasible)
• متناسق مع بقية المتطلبات (Consistent)

6. تحديد الأولويات (Prioritization)

ليس كل المتطلبات بنفس الأهمية، لذلك يتم ترتيبها حسب الأولوية باستخدام تقنيات مثل:

• MoSCoW Method:
  • Must have (يجب أن يتوفر)
  • Should have (يفضل أن يتوفر)
  • Could have (يمكن أن يتوفر)
  • Won’t have (لن يُنفذ الآن)

هذا يساعد الفريق في تحديد الحد الأدنى القابل للإطلاق (MVP – Minimum Viable Product).

أدوات جمع وتحليل المتطلبات (Tools for Requirements Gathering)

توجد العديد من الأدوات التي تُستخدم لتسهيل عملية جمع وتحليل المتطلبات، منها:

• Jira: لإدارة المهام والمتطلبات في المشاريع الكبيرة.
• Miro: لتصميم خرائط ذهنية (Mind Maps).
• Lucidchart: لرسم المخططات وعلاقات النظام.
• Notion / Confluence: لتوثيق المتطلبات ومشاركتها مع الفريق.
• Trello: لتتبع مراحل تنفيذ المتطلبات.

أخطاء شائعة في جمع المتطلبات (Common Mistakes)

حتى مع وجود خطة محكمة، يمكن أن تقع بعض الأخطاء مثل:

• تجاهل المستخدم النهائي والتركيز على آراء الإدارة فقط.
• صياغة متطلبات غامضة مثل “النظام يجب أن يكون سريعًا.”
• عدم مراجعة المتطلبات بانتظام.
• جمع متطلبات كثيرة دون ترتيب أولوياتها.

هذه الأخطاء تؤدي إلى فجوة بين ما يتوقعه العميل وما يتم تنفيذه فعلاً.

أفضل الممارسات (Best Practices)

لضمان نجاح مرحلة جمع المتطلبات:

• استمع أكثر مما تتحدث.
• استخدم لغة واضحة ومفهومة لجميع الأطراف.
• تأكد من أن كل متطلب يمكن قياسه.
• راجع المتطلبات دوريًا مع أصحاب المصلحة.
• استخدم الرسوم التوضيحية والمخططات متى أمكن.

العلاقة بين جمع المتطلبات ودورة حياة تطوير البرمجيات (SDLC)

تعتبر مرحلة جمع المتطلبات الركيزة الأولى في SDLC، إذ تعتمد عليها جميع المراحل التالية:

• التصميم (Design) يبنى على نتائج التحليل.
• التطوير (Development) يستند إلى وثائق المتطلبات.
• الاختبار (Testing) يقيس مدى التزام النظام بالمتطلبات المحددة.

بدون متطلبات دقيقة، لا يمكن بناء أو اختبار نظام ناجح.

الخلاصة

جمع المتطلبات (Requirements Gathering) ليس مجرد مقابلات أو أوراق، بل هو علم وفن يتطلب دقة وفهمًا عميقًا لطبيعة العمل والمستخدم.
نجاح أي مشروع برمجي يبدأ من هنا، من هذه المرحلة التي ترسم الطريق نحو منتجٍ يلبي احتياجات العميل بفعالية واستدامة.

📚 للمزيد

• المقال السابق: دورة حياة تطوير البرمجيات (SDLC)
• المقال التالي: جودة البرمجيات (Software Quality)