📋 Lecture 03 · 106 slides · أهم lecture في الترم

Requirements Engineering

"إذا ما تعرفش رايح فين، مفيش جهد ولا سرعة هتوصلك" — د. الرملي. هنا هنتعلم ازاي نجمع requirements من العملاء، نوثقها، ونتحقق منها. كل أسئلة User Stories و SRS و Use Cases في الامتحانات بتيجي من هنا.

← All Lectures 🎯 جرب أسئلة الامتحان

Chapters

RE Stages

Spec Methods

Exam Qs

Types of Software Products

قبل ما نجمع requirements، لازم نعرف الـ software اللي بنبنيه نوعه ايه. النوع بيحدد كل الخطوات بعد كده.

🎯 Custom Made

Software مخصص لـ عميل محدد — بيتبني حسب احتياجاته الفريدة.

مثال: نظام محاسبي لشركة معينة.

🏢 B-B (Business to Business)

Product narrow بيستهدف شركات معينة (clients محددين).

مثال: Salesforce, SAP.

👥 B-C (Business to Customer)

Product / Platform عام للجمهور العريض.

مثال: Word, Uber, Google Docs (cloud-based), WhatsApp.

💡 ليه ده مهم؟ الـ Custom-made بيحتاج interviews كتيرة مع العميل. الـ B-C بيحتاج market research وsegmentation. النوع بيغير كل الخطوات بعد كده.

Pre-Project Activities — قبل ما نبدأ المشروع أصلاً

4 أنشطة لازمة قبل ما نكتب أول سطر كود. كتير من المشاريع بتفشل لإنها بتتخطى الخطوات دي.

STEP 1

Market / Gap Analysis

STEP 2

Market Segmentation

STEP 3

Feasibility Study

STEP 4

High-Level Biz Plan

STEP 5

→ Project Start

📊 1. Market / Gap Analysis

Market Analysis: تشوف كيف الناس في دول تانية بتحل المشكلة دي.

Global Practices: مثال — تبني تطبيق دفع، بص على كينيا (M-Pesa) ومصر (Vodafone Cash).
Local Practices: الـ landscape المحلي — مثلاً في مصر: mobile wallets, government initiatives.

Gap Analysis: بيحدد الفجوات بين الـ current state والـ desired future state.

👥 2. Market Segmentation & Research

افهم مين هم العملاء الـ target:

Customer Segmentation: مين متأثر؟ (unbanked، أهالي، طلاب جامعة، SMEs، رِيف/مدينة).
Demographics: العمر، الدخل، التعليم، عادات استخدام الـ tech.

🔬 3. Feasibility Study — 4 جوانب

النوع	السؤال اللي بيجاوب عليه
Technical	هل ممكن نبنيه بالـ technology والـ tools والـ skills المتاحة؟
Economic	هل المشروع مربح؟ (Cost vs Revenue, ROI)
Legal & Regulatory	هل بيلتزم بالقوانين واللوائح؟
Schedule	هل ممكن نخلصه في الوقت المتاح؟

📝 4. High-Level Business Plan — 3 أجزاء

🎯 Project Goals (لازم تكون SMART)

Specific · Measurable · Achievable · Relevant · Time-bound

مثال: "Build a mobile budgeting app, achieve 100,000 active users in 1st year, integrate with major banks by Q3."

💎 Value Proposition

ايه اللي بيخليك different عن المنافسين؟

مثال: "AI-powered budgeting app that predicts monthly spending, auto-saves, and gives personalized financial advice — all in one place."

💰 Financial Outlook

Dev Costs: $150K
Ongoing: $50K/year (hosting, support, marketing)
Revenue: $5/month × 20K users = $1.2M/year

Domain Analysis — افهم المجال قبل ما تبني

قبل ما تجمع requirements، لازم تفهم الـ domain اللي شغّال فيه (طب، تعليم، بنوك، إلخ).

🌐 ايه الـ Domain Analysis؟

العملية اللي بيها الـ software engineer بيتعلم عن الـ domain علشان يفهم المشكلة:

الـ domain = المجال العام بتاع البيزنس أو الـ tech اللي العميل هيستخدم فيه الـ software.
الـ domain expert = شخص عنده فهم عميق للـ domain.

✨ فوائد Domain Analysis

⚡ Faster Dev

تطوير أسرع.

🎯 Better System

نظام أحسن.

🚫 No Misunderstanding

تجنب سوء الفهم.

🔮 Anticipate Extensions

توقع التوسعات المستقبلية.

📄 Domain Analysis Document — 8 أقسام

القسم	المحتوى
A. Introduction	خلفية عامة + الغرض من الـ doc
B. Glossary	تعريفات للمصطلحات الخاصة بالـ domain (Open event, Fixed event, Recurrent event...)
C. General knowledge	قوانين الـ domain العامة
D. Customers and users	مين هم الـ clients (organizations) و users (staff, admins...)
E. The environment	البيئة المحيطة (HW, SW, network, regulatory)
F. Tasks and procedures currently performed	كيف بيشتغلوا دلوقتي بدون الـ software الجديد
G. Competing software	المنتجات المنافسة الموجودة
H. Similarities to other domains	أي domains تانية شبه ده ممكن نستفيد من خبرتها

Requirements Engineering Process — 5 مراحل

RE = تعريف، توثيق، وصيانة الـ requirements. 5 مراحل بترتيب: Elicit → Analyze → Specify → Validate → Manage.

Elicitation

Analysis

Specification

Validation

Management

🎤 S1: Elicitation — جمع المعلومات

أول خطوة. الـ goal: نفهم الـ needs والـ desires والـ constraints من الـ stakeholders. الـ techniques:

Interviews — مقابلات فردية. اسأل عن الـ details، الـ vision، الـ alternatives، مصادر المعلومات. مش كافي لوحدها.
Surveys — استبيانات للوصول لعينة كبيرة.
Workshops / Brainstorming — جلسات جماعية. moderator + trigger question، وكل واحد يكتب إجابة ويمرر للجاي بعده.
Focus Groups — مجموعات صغيرة لمناقشة عميقة.
Observation of Users — تشوف الـ users بيشتغلوا في الحياة الحقيقية.
Prototyping — mockups أو pictures للنظام لتوضيح الفكرة. مش بيعمل computations حقيقية، بس بيوضح الـ UI.

📌 Winter 2025 Q1.23 السؤال: "Which are typically parts of requirements elicitation?" الإجابة: Stakeholder surveys + Role-playing scenarios + Prototyping. Creating UML diagrams ليس elicitation — ده specification.

🔍 S2: Analysis & Negotiation

بعد ما جمعنا الـ requirements، نحللها ونتفاوض عليها:

Identify conflicting requirements.
Categorize requirements (FR, NFR, etc.).
Prioritize based on importance (MoSCoW: Must, Should, Could, Won't).
Address ambiguity.

📝 S3: Specification / Documentation

التوثيق الرسمي. طرق ممكنة:

Textual (Natural language, User Stories, Use Cases, EARS).
Models (UML diagrams).
Formal languages or logic (Z notation, pseudocode).
Prototypes / mockups (للـ UI).

✓ S4: Validation

نتأكد إن الـ requirements بتطابق احتياجات الـ stakeholders الحقيقية:

Reviews and inspections — مراجعة من فريق خارجي ("4 eyes are better than 2").
Prototyping — لإظهار الفكرة قبل التنفيذ.
Simulations / walkthroughs مع الـ stakeholders.
User feedback.

📚 S5: Management — مستمرة طول حياة المشروع

Change Management: تتبع وموافقة على التغييرات.
Traceability: كل requirement بنرجعه لمصدره ولينكه بـ design elements و tests.

🚧 Challenges of RE

Ambiguity — متطلبات غامضة → سوء فهم.
Conflicting Requirements — stakeholders عندهم احتياجات متعارضة.
Incomplete Requirements — متطلبات ناقصة → gaps في الـ functionality.
Changing Requirements — المتطلبات بتتغير.
Communication Barriers — لغات/مصطلحات مختلفة بين stakeholders.

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

5 أنواع رئيسية. ركز على الفرق بين Functional و Non-functional، وأيضاً Business، Transition، Stakeholder.

⚙️ Functional Requirements (FR)

بتحدد الـ behavior والـ functions اللي النظام يعملها.

FR Examples

// R1.1
The system must allow users to create
a new account by entering email,
username, and password.

// R1.2
User must be able to log in with
registered credentials and reset
password via email link.

// R3.2
System should calculate and display
shipping costs and taxes before
completing the purchase.

🎚️ Non-Functional Requirements (NFR)

بتوصف كيف النظام بيؤدي وظايفه، مش ايه اللي بيعمله.

النوع	مثال
Performance	Speed, responsiveness
Security	Access control, encryption
Scalability	Handle 10K concurrent users
Usability	User-friendly, accessible
Accessibility	ALT text for blind users
Compliance	GDPR, HIPAA

📈 Business Requirements

أهداف عالية المستوى من الـ organization. بتعبر عن الـ vision.

مثال: "Develop mobile app to increase customer engagement by 20% in the first year."

عادةً بيكتبها product owners, sponsors, marketing.

🔄 Transition Requirements

متطلبات مؤقتة خاصة بالانتقال من الـ current state للـ future state.

بتشمل: training, data conversion, reformatting, parallel system runs.

بعد التنفيذ، ما تبقاش محتاجة.

📌 Winter 2025 Q1.24"All customer support staff must complete a 2-day training workshop on the new CRM system" = Transition Requirement.

👤 Stakeholder Requirements

احتياجات وتوقعات وقيود الأطراف المختلفة (users, customers, sponsors, regulators).

مثال: "Ambulance drivers should receive audio instructions about next case NOT on screen."

Characteristics of Good Requirements — 5 صفات لازمة

كل requirement لازم يحقق الـ 5 صفات دي. لو ناقص واحدة، بيبقى ضعيف.

📦 1. Complete

بيدي كل المعلومات اللازمة للتنفيذ والاختبار.

🎯 2. Unambiguous

تفسير واحد بس، مش مفتوح لتفسيرات متعددة.

🔗 3. Consistent

ما بيتعارضش مع متطلبات تانية.

✓ 4. Verifiable

ممكن نقيس / نختبر تحققه (fully or partially).

🔍 5. Traceable

بنرجعه لمصدره ولينكه بـ design و tests.

🔎 أمثلة Complete

The system should allow users to log in.

The system should require users to enter a valid username and password. If correct → dashboard. If incorrect → error message, allow up to 3 tries before temp lock.

🔎 أمثلة Unambiguous

The system shall show the name somewhere on the homepage.

The system will display user's name on the top right corner of the homepage after login.

🔎 أمثلة Verifiable

The system should be secure.

The system must encrypt all user passwords using AES-256 before storing in the database.

The system should be fast and efficient.

System should process 1,000 transactions per second under normal operating conditions.

⚠️ exam trap كلمات زي "fast", "easy", "popular platforms" = NOT verifiable. أرقام محددة وأسماء محددة = verifiable.

🔎 أمثلة Consistent

تعارض واضح:
R1: "System shall allow one-click shopping by clicking purchase button and using stored credit card."
R2: "System should NOT store credit card details after purchase."
الاتنين ما يقدرش يتحققوا في نفس الوقت.

🔎 أمثلة Traceable

The system shall encrypt user data.

The system shall ensure all user data is encrypted using AES-256 to comply with GDPR (Requirement ID: GDPR-001).

6 Methods for Specifying Requirements

كل طريقة ليها استخدام مختلف. اللي بيتسأل عليه في الامتحان: User Stories, Use Cases, EARS.

Method	الخصائص	الاستخدام
1. Natural Language	بسيط لكن غامض	للنقاشات الأولية والـ general audience
2. Formal Specs (Z, pseudocode)	دقيق، machine-readable	Critical systems / formal analysis
3. IEEE 830 SRS Template	مفصل ومنظم	المشاريع الكبيرة
4. User Stories	User-centric + acceptance criteria	Agile teams, backlog
5. Use Cases	تفاعل user-system بخطوات	OO design
6. EARS	Structured natural language	متطلبات دقيقة وtestable

📑 IEEE 830-1998 SRS Template

3 أقسام رئيسية:

Introduction: Purpose, Scope, Definitions, References, Overview
Overall Description: Product Perspective, Functions, User Characteristics, Constraints, Assumptions
Specific Requirements: External interfaces, FR, Performance, Design constraints, Quality, Other

📌 Updateتم تحديث الـ standard لـ IEEE 29148-2011 (ISO/IEC/IEEE 29148).

🎯 EARS Method — Easy Approach to Requirements Syntax

Structure ثابت بـ 5 كلمات: When · then · If · then · Else

EARS example

When a user enters their username and password,
then the system checks the credentials.
If the credentials are valid,
then the user is granted access to the dashboard.
Else the system displays an error message and allows retry.

الـ structure: When <trigger>, then <response>. If <cond>, then <response>. Else <opposite>.

User Stories & INVEST Criteria ⭐

أهم سؤال متكرر في الامتحان. لازم تعرف الـ format والـ INVEST كويس جداً.

📝 User Story Format

Standard format

As a [user role],
I want [some functionality]
so that [I achieve some benefit / value].

مثال:

Example user story

As a user,
I want to log into the application
so that I can access my dashboard securely.

Acceptance Criteria:
1. System should accept username & password.
2. System should authenticate credentials.
3. If valid → redirect to dashboard.
4. If invalid → display error message.

⭐ INVEST — 6 صفات اللي بتخلي user story كويس

Independent

مستقل عن stories تانية

Negotiable

قابل للنقاش والتعديل

Valuable

يضيف قيمة للـ user

Estimable

سهل تقدير الجهد المطلوب

Small

صغير، يخلص في sprint واحد

Testable

عنده acceptance criteria واضحة

⚠️ Exam trap الـ doctor بيدي 3 user stories و يسأل أيهم INVEST. الـ stories اللي بتيجي من perspective عالي جداً (مدير المدرسة) ومتعريفة بشكل مفتوح زي "monitor progress" — بتفشل في S (Small) و E (Estimable).

💎 Enriched User Stories

User Story + prototype + data dictionary + textual use case + acceptance criteria — كل ده في document واحد.

الميزة: Enhanced team communication — كل اللي محتاجه الـ dev team والـ stakeholders في مكان واحد.

بيشمل:

Description, Focal point, Other Actors
Location (path في الـ UI), Pre/Post-conditions
Main Path table (2-column: Actor Action / System Response)
Data dictionary (Field name, Type, Validation, Business Rules)
UI Mockup

Use Cases — تفصيلي

أهم Diagram في الامتحان (Question 2 في كل امتحان فيه use case modeling). 3 خطوات: Actors → Use Cases → Diagram.

📖 What is a Use Case?

تسلسل الـ actions اللي الـ user بيعملها لإتمام مهمة معينة.
بيغطي الـ full sequence من البداية للنهاية.
بيوصف user-system interaction، مش الحسابات الداخلية.
مكتوب بشكل independent من UI design.
بس user-computer actions، مش manual أو internal.

📋 Step 1: Identify Actors

الـ Actor = كيان (شخص أو نظام) بيتفاعل مع الـ system. اسأل:

Who uses / starts / maintains / shuts down the system?
What other systems use this system?
Who gets information from / provides information to the system?

📋 Step 2: Identify Use Cases

بعد ما عرفت الـ actors، اسأل لكل واحد:

What functions will the actor want?
Does the system store information? Who CRUDs it?
Does the actor need to be informed of state changes?
External events?

📊 Step 3: Build the Diagram

عناصر الـ Use Case Diagram:

🧍

Actor

System Boundary

Use Case 1

Use Case 2

العنصر	المعنى
Actor (stick figure)	كيان خارجي بيتفاعل مع الـ system
Use Case (oval)	وظيفة بيقدر الـ user يعملها
System Boundary (rectangle)	حدود الـ system
Generalization (solid arrow with open triangle)	Actor/Use case بيرث من أب
<<Include>> (dashed arrow)	Use case دايماً بتستخدم use case تانية (مثل Login مع كل use case)
<<Extend>> (dashed arrow)	Use case ممكن أحياناً تستخدم use case تانية (شرط معين)

📌 Winter 2023 Q1.04"Customers with bad credit history should pay an extra down payment" → الإجابة هي <<extend>> من Bad Credit Customer لـ Pay Extra Down Payment. الـ extend بيستخدم لما الحالة conditional.

📝 Use Case Description — 8 عناصر

#	العنصر	المحتوى
A ⭐	Name	اسم قصير ووصفي
B	Actors	مين بيعمل الـ use case
C	Goals	ايه اللي الـ actor بيحاول يحققه
D	Preconditions	حالة النظام قبل الـ use case
E	Summary	وصف غير رسمي قصير
F	Related use cases	include / extend
G ⭐	Steps	2-column: Actor Actions / System Responses
H	Postconditions	حالة النظام بعد الانتهاء

💡A والـ G هما الأهم — في exam questions كتيرة، بيطلبوا منك Use Case Description كاملة، الـ Name والـ Steps هما المعيار الرئيسي للتقدير.

📚 Example: Library "Check Out Item"

Actor: Clerk
Goal: Lend a book to a borrower
Preconditions: User is allowed to borrow
Postconditions: Item is checked out & recorded on user's borrowing records

Actor	System
1- Enter user's ID (or scan)	2- Open user page
3- Choose "borrow an item"
4- Enter book's barcode & click borrow	5- Add book to user's records, due date displayed

Exceptional Flow — User suspended:

Actor	System
1- Enter/Scan user ID	2- Open user page (Suspended / Max num reached)
3- Borrow option disabled
4- Cancel

🎯

Exam Question Bank — Lecture 3

10 أسئلة حقيقية من امتحانات 2021 → 2025 · User Stories, INVEST, SRS, Use Cases, Verifiability

Question 1 Fall 2021–22 · Q1.01 (also Winter 2021)

A good user story should be INVEST. Which of the following is a good user story?

(a) View Grades: "As a student, I can see grades online as soon as they are posted, so I don't have to wait until I go to school."
(b) Upgrade Grades: "As a teacher, I want to enter grades online so I no longer need to fill students' reports by hand."
(c) Monitoring Students' Progress: "As a school manager, I want to monitor the progress of students so I know if the school is doing well or not."

A Only (a)

B Only (b)

C Only (c)

D Both (a) and (b)

E All three

F None

✅ الإجابة الصح: D — Both (a) and (b) الـ (a) و (b) كلاهما specific, small, testable — بيوصفوا feature واضحة في sprint واحد.

(c) "monitor progress" واسع جداً — مش Small ولا Estimable. ده business goal مش user story. مدير المدرسة لما يطلب "monitor progress"، ده ممكن يتقسم لـ 10 user stories أصغر.

Question 2 Fall 2021–22 · Q1.02

Which requirements are verifiable (V) and which are non-verifiable (NV)?

1. Scrum development process must be followed.
2. The system should support the popular mobile platforms now.
3. The game server should be able to handle up to 1000 players simultaneously.
4. The web server should be fast and respond quickly to requests.

A Verifiable: 1, 3 / Non-verifiable: 2, 4

B Verifiable: 2 / Non-verifiable: 1, 3, 4

C Verifiable: 1, 2, 3 / Non-verifiable: 4

D Verifiable: 3, 4 / Non-verifiable: 1, 2

✅ الإجابة الصح: A — Verifiable: 1, 3 / Non-verifiable: 2, 4

1 (V) — ممكن نتأكد بمراجعة عملية التطوير.
2 (NV) — "popular mobile platforms now" غامض. "popular" ايه معايير؟ "now" يعني امتى؟
3 (V) — رقم محدد: 1000 players. اختبار load testing.
4 (NV) — "fast and respond quickly" مفيش معيار. كان لازم يكون "response time < 200ms".

Question 3 Winter 2021 · Q1.02

Same question but item 2 is now:

1. Scrum development process must be followed.
2. The system should support two mobile platforms: iOS and Android.
3. The game server should handle up to 1000 players.
4. The web server should be fast.

A V: 1, 3 / NV: 2, 4

B V: 2 / NV: 1, 3, 4

C V: 1, 2, 3 / NV: 4

D V: 3, 4 / NV: 1, 2

✅ الإجابة الصح: C — V: 1, 2, 3 / NV: 4 الفرق عن السؤال السابق: item 2 بقى specific ("iOS and Android"). الآن قابل للتحقق بـ tests على المنصتين.

Item 4 لسه non-verifiable — "fast" بدون رقم محدد. ده الـ trap الأساسي.

Question 4 Winter 2023 · Q1.01

Which of these are unambiguous (clear) requirements that developers can understand easily?

I. The user should be able to update his profile picture with a new one.
II. The system should support 1000 simultaneous users.
III. The system should work in the same way on the most popular web browsers.
IV. The UI should be easy to understand and quick to learn.

A I and IV

B I and II

C I and III

D II and III

E III and IV

✅ الإجابة الصح: B — I and II

I ✅ واضح — تغيير صورة البروفايل.
II ✅ واضح — 1000 simultaneous users. رقم محدد.
III ❌ غامض — "most popular browsers"؟ ايه هم؟ Chrome? Safari? IE6؟
IV ❌ غامض — "easy to understand" و "quick to learn" مفيش معيار.

Question 5 Winter 2025 · Q1.23

Which of the following are typically parts of requirements elicitation?

1. Stakeholder surveys and user observation
2. Role-playing user scenarios
3. Creating UML diagrams for design
4. Prototyping to clarify concepts

A Only 1 and 2

B Only 3 and 4

C Only 1, 2 and 4

D All four

✅ الإجابة الصح: C — Only 1, 2 and 4 Elicitation = جمع المعلومات من stakeholders. Surveys, role-playing, observation, prototyping كلهم techniques لجمع المعلومات.

3 (UML diagrams) ده design أو specification، مش elicitation. الـ UML بيتعمل بعد ما الـ requirements اتجمعت أصلاً.

Question 6 Winter 2025 · Q1.24

Classify the following requirement: "All customer support staff must complete a 2-day training workshop on the new CRM system's features before the system goes live."

A Business Requirement

B Functional

C Stakeholder

D Transition

✅ الإجابة الصح: D — Transition Requirement Training قبل go-live = activity مؤقتة خاصة بالانتقال من الـ current state للـ new system. بعد الـ go-live، ما تبقاش محتاجة.

A (Business) — لا، ده مش goal على مستوى الـ org. · B (Functional) — لا، ده مش function للـ system. · C (Stakeholder) — قريبة لكن Transition أكتر specific.

Question 7 Winter 2025 · Q1.25

Which AI assistant tools can be most helpful in requirements engineering?

A UI/UX Design tools like Uizard and Galileo AI

B AI Code Assistants like Windsurf, Codex, Cursor

C AI Code Review tools like Codacy and CodeRabbit

D AI Document Generation tools like Tabnine Docs and DocuWriter.ai

✅ الإجابة الصح: A — UI/UX Design tools Uizard و Galileo AI بيعملوا mockups و prototypes من نصوص — وده جزء أساسي من requirements elicitation (Prototyping).

B, C, D — كل دول tools للـ coding/review/docs بعد ما الـ requirements اتحددت. مش بتفيد في مرحلة جمع الـ requirements.

Question 8 Winter 2023 · Q1.04

Customers of a car sales shop can buy cars. Customers with a bad credit history should pay an extra down payment. Which use case relation is correct?

A <> from Bad Credit Customer's "Buy a car" to "Pay extra down payment"

B <> on the Customer side

C <> on the Customer side

D <> from "Pay extra down payment" to "Buy a car" on the Bad Credit Customer side

✅ الإجابة الصح: D <> بيستخدم لما الـ use case الإضافية conditional — يعني بتحصل في حالات معينة (هنا: لما العميل عنده bad credit). الـ relation بيتعمل من Bad Credit Customer لأنه هو اللي بيدفع الـ extra.

A, B — include بيستخدم لما الـ use case الإضافية إلزامية دايماً. هنا مش الحالة. · C — extend صح بس على الـ Customer العادي غلط — الـ extra بيدفعه bad credit بس.

📋

Cheat Sheet — مذاكرة سريعة

كل المصطلحات والمعايير والصيغ اللي محتاجها لاتقان الـ requirements engineering.

🎯 INVEST Criteria

Independent — لا يعتمد على stories تانية

Negotiable — قابل للنقاش

Valuable — يضيف قيمة

Estimable — قابل لتقدير الجهد

Small — يخلص في sprint

Testable — عنده acceptance criteria

✅ Good Requirement = 5 صفات

1. Complete

معلومات كاملة للتنفيذ والاختبار

2. Unambiguous

تفسير واحد، أرقام/أسماء محددة

3. Consistent

ما يتعارضش مع requirements تانية

4. Verifiable

ممكن قياسه/اختباره

5. Traceable

له ID وبنرجعه لمصدره

🔄 RE Process — 5 Stages

S1: Elicitation

Interviews, Surveys, Brainstorming, Focus groups, Observation, Prototyping

S2: Analysis

Conflicts, Categorize, Prioritize, Ambiguity

S3: Specification

SRS, User Stories, Use Cases, EARS, Z

S4: Validation

Reviews, Prototyping, Walkthroughs, User feedback

S5: Management

Change mgmt, Traceability (continuous)

📚 Types of Requirements

Functional (FR)

ايه اللي النظام يعمله (login, search...)

Non-Functional (NFR)

كيف يعمله (performance, security, scalability, usability)

Business

أهداف الـ org (vision, ROI)

Transition

مؤقتة — training, data migration, parallel runs

Stakeholder

احتياجات أطراف محددة

🎬 Use Case Quick Ref

Actor

Stick figure · external entity

Use Case

Oval · user goal

System Boundary

Rectangle around use cases

Always uses another UC (Login)

Sometimes (conditional) — bad credit case

Generalization

Inheritance between actors/UCs

📝 EARS Method

Keyword 1

When <trigger>

Keyword 2

then <system response>

Keyword 3

If <condition>

Keyword 4

then <another response>

Keyword 5

Else <negative response>

⚡

Rapid Revision

Flashcards · Common Mistakes · What the doctor loves to ask.

🎴 Flashcards

ايه الـ 5 stages بتاعة RE Process؟

tap to flip

Elicitation → Analysis → Specification → Validation → Management

ايه INVEST؟

tap to flip

Independent · Negotiable · Valuable · Estimable · Small · Testable

User Story Format؟

tap to flip

As a [role], I want [goal], so that [benefit]

5 صفات الـ Good Requirement؟

tap to flip

Complete · Unambiguous · Consistent · Verifiable · Traceable

Include vs Extend؟

tap to flip

Include = ALWAYS uses · Extend = SOMETIMES (conditional)

Training before go-live = نوع ايه؟

tap to flip

Transition Requirement

FR vs NFR؟

tap to flip

FR = ايه يعمل · NFR = كيف يعمل (perf, security, usability)

EARS keywords؟

tap to flip

When · then · If · then · Else

6 Techniques للـ Elicitation؟

tap to flip

Interviews · Surveys · Brainstorming · Focus Groups · Observation · Prototyping

🚨 Common Mistakes

1. خلط Include و ExtendInclude = mandatory dependency. Extend = optional/conditional. لو فيه شرط زي "if customer has bad credit", استخدم extend.

2. اعتبار "easy", "fast", "popular" verifiableدي كلمات غامضة. للـ verifiability محتاج أرقام أو أسماء محددة (1000 users, AES-256, Chrome & Safari).

3. التفريق بين Transition وStakeholderTransition = activities مؤقتة للـ go-live (training, migration). Stakeholder = احتياجات specific لـ user types (ambulance drivers want audio).

4. اعتبار UML diagrams part of ElicitationUML بيتعمل بعد ما الـ requirements اتجمعت — ده Specification/Design. الـ Elicitation = جمع المعلومات بـ interviews/surveys/observation.

5. اعتبار "monitor school progress" user storyده business goal مش user story. الـ INVEST بيفشل في Small و Estimable.

⭐ What Dr. El-Ramly Loves to Ask

🔥 الأسئلة المتكررة على Lec 3

INVEST evaluation — بيدي 3 user stories و يسأل أيهم كويس. السر: الـ vague/high-level بيفشل.
Verifiable vs Non-verifiable — بيدي 4 requirements و يسأل أيهم verifiable. كلمات زي "fast" دايماً NV.
نوع الـ requirement — Functional? Transition? Stakeholder? اقرا الكلمات الـ trigger.
Use Case relations — Include vs Extend. لو في "should pay if/when..." → extend.
Question 2 (UML Modeling) — كل امتحان فيه سؤال 20 مارك على بناء use case diagram + class diagram لـ system معين (car rental, email server, etc.). ركز على ده!