SDLC - Requirements Analysis

✅ 2. Requirements Analysis – تحليل المتطلبات

🎯 الهدف من المرحلة دي:

نفهم بالظبط العميل أو المستخدم محتاج إيه من النظام.

مش بس "إيه عايز يعمله" لكن كمان "عايزه يشتغل إزاي؟"

---

📌 إيه اللي بيحصل في المرحلة دي؟

1. جمع المتطلبات (Requirements Gathering):
   بنقعد مع العميل أو أصحاب المشروع ونسألهم:

   • إيه اللي محتاجينه بالظبط؟

   • النظام ده هيشتغل فين؟ لمين؟

   • إيه المشاكل اللي النظام هيحلها؟

2. تصنيف المتطلبات:
   بنقسم المتطلبات إلى نوعين:

   • ✅ وظيفية (Functional Requirements):
     دي الحاجات اللي المفروض النظام يعملها، زي:

     المستخدم يسجل دخول – يضيف منتج – يشتري – يدفع

   • ⚙️ غير وظيفية (Non-Functional Requirements):
     دي حاجات مش واضحة في السلوك، بس مهمة زي:

     السرعة – الأمان – الأداء – عدد المستخدمين المتوقع

3. توثيق المتطلبات (Documentation):
   كل المتطلبات بنكتبها في مستند رسمي، غالبًا اسمه:

   SRS - Software Requirements Specification

4. موافقة العميل:
   لازم العميل يراجع المستند ده ويوافق عليه، عشان نكمل شغلنا بناءً عليه، ومايحصلش مشاكل بعدين.

---

🧠 المفروض تفهم إيه من المرحلة دي؟

• إزاي تسأل العميل الأسئلة الصح.

• تكتب متطلبات واضحة وسهلة الفهم.

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

• تفهم أهمية التوثيق والموافقة.

---

🔄 مثال عملي:

لو بنكمل على تطبيق البيع أونلاين:

• وظيفي:

  • المستخدم يسجل حساب

  • يضيف منتج للسلة

  • يطلب أوردر

  • يدفع بالكريدت كارد

• غير وظيفي:

  • لازم الصفحة تحمل في أقل من ثانيتين

  • لازم النظام يتحمل 10,000 مستخدم في نفس الوقت

  • لازم البيانات تكون مشفرة لحماية الخصوصية