الوحدة 4: جمع المتطلبات وتحليلها

أهداف التعلم

"من احتياجات المستخدم إلى مواصفات النظام"

بنهاية هذه الوحدة سيكون الطالب قادرًا على:

• فهم أهمية مرحلة **جمع المتطلبات** كأحد أهم عوامل نجاح النظام.
• التعرف على **تقنيات جمع البيانات**: المقابلات، الاستبيانات، الملاحظة، ورش العمل.
• التمييز بين **المتطلبات الوظيفية** و**غير الوظيفية**.
• تطبيق أساليب التوثيق مثل **Use Case Diagrams** و **User Stories**.
• إدراك دور **أصحاب المصلحة** (Stakeholders) في تحديد المتطلبات.

1. مقدمة في جمع المتطلبات

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

تعريف المتطلبات

المتطلبات هي ببساطة **ما يجب أن يفعله النظام**، وما هي **القيود المفروضة عليه**. هي الاحتياجات التي يجب أن يلبيها النظام لكي يكون ناجحًا ويحقق أهدافه المحددة. يمكن أن تكون هذه الاحتياجات من المستخدمين النهائيين، أو الإدارة، أو اللوائح القانونية، أو حتى من الأنظمة الأخرى التي سيتكامل معها النظام الجديد.

الفرق بين المتطلبات (Requirements) والمواصفات (Specifications)

• **المتطلبات (Requirements):** تصف "ماذا" يجب أن يفعله النظام من وجهة نظر المستخدم أو أصحاب المصلحة. هي عادة ما تكون على مستوى عالٍ وغير تقنية بالضرورة. (مثال: "يجب أن يتمكن العميل من تتبع طلباته.")
• **المواصفات (Specifications):** تصف "كيف" سيتم تحقيق هذه المتطلبات على المستوى التقني والتفصيلي. هي موجهة للمطورين وتتضمن تفاصيل تقنية دقيقة. (مثال: "يجب أن يتم تحديث حالة الطلب في قاعدة البيانات SQL كل 5 ثوانٍ، وأن تُعرض على واجهة المستخدم باستخدام تقنية AJAX.")

العلاقة بين المتطلبات ونجاح المشروع

تُظهر الإحصائيات والدراسات أن الفشل في تحديد المتطلبات بشكل صحيح هو أحد الأسباب الرئيسية لفشل مشاريع تطوير الأنظمة. فوفقًا لتقارير معهد إدارة المشاريع (PMI)، تفشل نسبة كبيرة من المشاريع (قد تصل إلى 70% أو أكثر في بعض الدراسات) بسبب ضعف في مرحلة تحليل المتطلبات أو عدم فهمها بشكل كامل.

• **المتطلبات غير الواضحة:** تؤدي إلى بناء نظام لا يلبي احتياجات المستخدمين.
• **تغيير المتطلبات المتكرر:** يؤدي إلى زيادة التكاليف وتأخير الجدول الزمني.
• **ضعف التواصل:** بين أصحاب المصلحة وفريق التطوير يؤدي إلى سوء فهم كبير.

لذا، فإن استثمار الوقت والجهد الكافي في هذه المرحلة يضمن بناء نظام يلبي التوقعات ويحقق القيمة المرجوة.

2. تقنيات جمع المتطلبات

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

أ) المقابلات (Interviews)

تُعد المقابلات من أكثر التقنيات فعالية لجمع المتطلبات التفصيلية والشخصية. تسمح بالتفاعل المباشر والحصول على رؤى عميقة.

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

ب) الاستبيانات (Questionnaires)

تُستخدم لجمع البيانات من عدد كبير من الأشخاص بسرعة وفعالية. مناسبة لجمع البيانات الكمية أو الآراء العامة.

• **الأسلوب:** توزيع مجموعة من الأسئلة المكتوبة على جمهور واسع (عبر البريد الإلكتروني، نماذج الويب).
• **أنواع الأسئلة:**
  • **أسئلة متعددة الخيارات، صح/خطأ، أسئلة مفتوحة.**
  • **مقياس ليكرت (Likert Scale):** لتقييم مدى الاتفاق أو الرضا (مثال: "أوافق بشدة، أوافق، محايد، لا أوافق، لا أوافق بشدة").
• **المميزات:** فعالة من حيث التكلفة والوقت لجمع البيانات من عدد كبير، سهلة التحليل (خاصة الأسئلة المغلقة).
• **العيوب:** تفتقر إلى المرونة، لا تسمح بالتعمق، قد لا تكون معدلات الاستجابة مرتفعة، وقد لا تكون الأسئلة مفهومة للجميع.

ج) الملاحظة (Observation)

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

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

د) ورش العمل (Workshops)

جلسات مكثفة وتفاعلية تجمع أصحاب المصلحة الرئيسيين وفريق التطوير لتبادل الأفكار، تحديد المتطلبات، وحل التعارضات بشكل جماعي.

• **الأسلوب:** تُجرى في بيئة منظمة، وعادة ما يقودها مُيسر (Facilitator) محايد. يمكن استخدام تقنيات مثل العصف الذهني (Brainstorming).
• **المميزات:** جمع كمية كبيرة من المتطلبات بسرعة، بناء توافق في الآراء بين أصحاب المصلحة، حل التعارضات بشكل فوري، وتقليل سوء الفهم.
• **العيوب:** تتطلب تخطيطًا جيدًا ومُيسرًا خبيرًا، وقد تكون مكلفة لإعدادها، وقد يهيمن عليها أصحاب النفوذ.

3. تصنيف المتطلبات

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

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

تصف **الوظائف أو السلوكيات** التي يجب أن يؤديها النظام. هي المتطلبات المباشرة التي تُخبرنا بما يجب على النظام "فعله".

• ما هي المهام التي سينجزها النظام؟
• ما هي أنواع البيانات التي سيعالجها؟
• ما هي التفاعلات التي ستحدث بين المستخدم والنظام؟

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

تصف **كيف** يجب أن يؤدي النظام وظائفه، أي أنها تتعلق **بجودة وأداء النظام**. لا تصف ما يفعله النظام بشكل مباشر، بل تصف خصائص مثل السرعة، الأمان، الموثوقية، سهولة الاستخدام، والقابلية للتوسع.

• **الأداء (Performance):** السرعة، زمن الاستجابة، عدد المعاملات في الثانية. (مثال: "يجب أن تستجيب الصفحة الرئيسية خلال 2 ثانية كحد أقصى.")
• **الأمان (Security):** حماية البيانات، التحكم في الوصول، التشفير. (مثال: "يجب أن يتم تشفير جميع كلمات المرور باستخدام AES-256.")
• **الموثوقية (Reliability):** القدرة على العمل دون فشل لفترة معينة، مقاومة الأخطاء. (مثال: "يجب أن يكون وقت التوقف للنظام أقل من 0.1% شهريًا.")
• **سهولة الاستخدام (Usability):** مدى سهولة تعلم واستخدام النظام. (مثال: "يجب أن يتمكن المستخدم الجديد من إتمام عملية الشراء في 5 خطوات كحد أقصى.")
• **قابلية التوسع (Scalability):** قدرة النظام على التعامل مع زيادة في حجم العمل أو عدد المستخدمين. (مثال: "يجب أن يدعم النظام 1000 مستخدم متزامن دون تدهور في الأداء.")
• **قابلية الصيانة (Maintainability):** سهولة تعديل وإصلاح وتحديث النظام. (مثال: "يجب أن يكون الكود مكتوبًا بمعايير جافا المؤسسية.")

4. توثيق المتطلبات

توثيق المتطلبات هو عملية تسجيل المتطلبات المجمعة وتحليلها بطريقة منظمة ومفهومة لجميع أصحاب المصلحة. التوثيق الجيد يضمن أن الجميع لديهم فهم مشترك لما سيفعله النظام وكيف سيعمل.

أ) مخططات حالة الاستخدام (Use Case Diagrams)

تُعد جزءًا من لغة النمذجة الموحدة (UML)، وتُستخدم لتمثيل **وظائف النظام من وجهة نظر المستخدمين (Actors)**. تظهر هذه المخططات العلاقة بين المستخدمين وما هي المهام (حالات الاستخدام) التي يمكنهم إنجازها باستخدام النظام.

• **الممثل (Actor):** هو كيان يتفاعل مع النظام (قد يكون شخصًا، نظامًا آخر، أو جهازًا).
• **حالة الاستخدام (Use Case):** وظيفة محددة يقدمها النظام استجابة لتفاعل مع ممثل (مثال: "تسجيل دخول"، "إدارة المخزون").
• **العلاقات:** تصف كيفية تفاعل الممثلين مع حالات الاستخدام (خطوط بسيطة) أو العلاقات بين حالات الاستخدام نفسها (include, extend).

ب) قصص المستخدم (User Stories)

صياغة بسيطة وموجزة للمتطلبات الوظيفية من وجهة نظر المستخدم النهائي. تُستخدم بشكل شائع في منهجيات التطوير الرشيقة (Agile).

الصيغة العامة:

كمستخدم/نوع مستخدم (As a ),
أريد أن (I want to ),
لكي (so that ).

ج) قاموس البيانات (Data Dictionary)

هو مجموعة موثقة ومنظمة لجميع البيانات المستخدمة في النظام. يوفر تعريفات موحدة للمصطلحات، الحقول، الجداول، والعلاقات، مما يضمن اتساق البيانات ويزيل الغموض.

• **يتضمن:** اسم العنصر، وصفه، نوع البيانات، حجمه، القيم المسموح بها، والعلاقات مع عناصر بيانات أخرى.
• **الفائدة:** يوحّد المصطلحات، يمنع التكرار، ويسهل على المطورين فهم هيكل البيانات.

د) وثيقة مواصفات المتطلبات البرمجية (Software Requirements Specification - SRS)

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

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

الأنشطة التعليمية

لترسيخ فهمك لمفاهيم جمع المتطلبات وتحليلها، إليك بعض الأنشطة المقترحة:

• **ورشة عمل: محاكاة مقابلات جمع المتطلبات**
  • قسّموا أنفسكم إلى أزواج أو مجموعات صغيرة.
  • اختاروا نظامًا بسيطًا (مثال: نظام تسجيل الطلاب في الكلية).
  • يقوم أحد الأفراد (أو مجموعة) بدور محلل النظم، والآخر بدور أصحاب المصلحة (مثال: طالب، مسجل، مدرس).
  • قوموا بمحاكاة مقابلة لجمع المتطلبات، مع طرح أسئلة مفتوحة ومغلقة، ومحاولة فهم احتياجات الطرف الآخر.
• **تمرين عملي: إعداد استبيان**
  • صمموا استبيانًا من 10 أسئلة على الأقل لقياس رضا المستخدمين عن خدمة إلكترونية شائعة (مثال: تطبيق توصيل الطعام، منصة تعليمية، أو خدمة بنكية عبر الإنترنت).
  • تأكدوا من تضمين أنواع مختلفة من الأسئلة، بما في ذلك أسئلة مقياس ليكرت.
• **دراسة حالة: فشل مشروع NHS IT Project**
  • ابحثوا عن معلومات حول مشروع "NHS National Programme for IT" في المملكة المتحدة وأسباب فشله.
  • حللوا كيف ساهمت التحديات في جمع المتطلبات (مثل المتطلبات المتغيرة، سوء التواصل، تعقيد المنظمة) في هذا الفشل الضخم.
  • اكتبوا تقريرًا تحليليًا (200-300 كلمة) يبرز الدروس المستفادة من هذه الحالة.

أدوات التقييم

لتقييم مدى استيعابك للمفاهيم في هذه الوحدة:

• **اختبار قصير (10 درجات):**
  • يغطي مفاهيم جمع المتطلبات، تقنياتها، والتمييز بين الأنواع المختلفة من المتطلبات (وظيفية وغير وظيفية).
• **مهمة فردية: إعداد وثيقة متطلبات مبدئية (SRS) (30%)**
  • يُطلب من كل طالب إعداد وثيقة SRS مبسطة (3-4 صفحات) لنظام افتراضي صغير (يمكن أن يكون نظامًا بسيطًا لمطعم، أو نظام إدارة مخزون لمحل صغير). يجب أن تتضمن الوثيقة قائمة بالمتطلبات الوظيفية وغير الوظيفية، بالإضافة إلى Use Case Diagram واحد على الأقل.
• **عرض جماعي: تقديم نتائج تحليل المتطلبات (20%)**
  • تقوم المجموعات بتقديم عرض تقديمي (10-15 دقيقة) لنتائج تحليل متطلبات مشروع صغير (يمكن أن يكون المشروع الذي عملوا عليه في ورشة العمل). يجب أن يوضح العرض التقنيات التي استخدموها، وكيف صنفوا المتطلبات، وأمثلة على Use Cases أو User Stories.

المراجع البصرية المقترحة

لتعزيز فهمك البصري للمفاهيم، يمكنك البحث عن المخططات التالية:

• **مخطط يوضح الفرق بين المتطلبات الوظيفية وغير الوظيفية:** يفضل أن يكون رسماً بيانياً يوضح كيف أن الوظيفية هي "ماذا" وغير الوظيفية هي "كيف".
• **نموذج Use Case مبسط مع شرح عناصره:** يوضح الممثلين، حالات الاستخدام، والعلاقات.
• **مثال لاستبيان حقيقي لجمع متطلبات نظام:** يوضح أنواع الأسئلة المستخدمة.

المراجع

• "Systems Analysis and Design" – Kenneth Kendall & Julie Kendall.
• "Software Requirements" – Karl Wiegers.
• تقارير Project Management Institute (PMI) حول أسباب فشل المشاريع.

ملخص الوحدة

لقد أكملتَ هذه الوحدة الحيوية في مقرر "تحليل وتصميم النظم"، حيث تعلمتَ أن جمع المتطلبات بدقة هو البوابة الأولى لنجاح أي نظام.

• أدركتَ أهمية المتطلبات في تحديد نجاح أو فشل المشروع، وفهمتَ الفرق بين المتطلبات والمواصفات.
• تعرفتَ على مجموعة متنوعة من **تقنيات جمع البيانات**، مثل المقابلات والاستبيانات والملاحظة وورش العمل، وكيفية استخدام كل منها بفعالية.
• ميزتَ بوضوح بين **المتطلبات الوظيفية** (ما يفعله النظام) و**المتطلبات غير الوظيفية** (كيف يؤديه النظام بجودة).
• تعلمتَ أساليب **توثيق المتطلبات** الأساسية، بما في ذلك مخططات Use Case Diagrams، وقصص المستخدم (User Stories)، ووثيقة SRS، وأهمية قاموس البيانات.
• فهمتَ الدور المحوري لأصحاب المصلحة في عملية تحديد المتطلبات، وأن التواصل الفعال معهم هو أساس التحليل الفعّال.

بامتلاكك لهذه المهارات، أصبحتَ جاهزًا للانتقال إلى مرحلة تطبيق أدوات التحليل، حيث ستتعلم في الوحدة القادمة كيفية استخدام **مخططات تدفق البيانات (Data Flow Diagrams - DFD)** لنمذجة وتصوير تدفق المعلومات داخل النظام.