🎯 What is Requirements Elicitation?
Definition
Elicitation is the process of identifying the needs and constraints of the various stakeholders for a software system.
Etymology: "Elicit" means to draw out, extract, or bring forth (استنبط، استخرج، انتزع)
Key Characteristics
- A collaborative and analytical process that includes activities to collect, discover, extract, and define requirements
- Not just "gathering requirements" or transcribing what users say
- Discovers business, user, functional, and non-functional requirements
- Perhaps the most challenging, critical, error-prone, and communication-intensive aspect of software development
💡 Memory Trick
ELICIT = Extract, Listen, Investigate, Collaborate, Interpret, Transform
Remember: You're not just collecting; you're actively extracting and transforming stakeholder needs into requirements!
🎯 Elicitation Goals
- Determine sources of information and select appropriate techniques
- Elicit information on domain, problem, needs, and constraints
- Produce a first document:
- Mainly user requirements and elicitation notes
- Potentially incomplete, disorganized, and inconsistent
- But you must start somewhere!
Important: Requirements development is an iterative process. Do some elicitation → study what you learn → write some requirements → realize you have gaps/conflicts → return to elicitation → repeat!
📚 Sources of Requirements
1. Stakeholders (Various Types)
| Stakeholder Type | Role/Description | Key Contribution |
|---|---|---|
| Client/Customer | Pays for software development | Business objectives, budget, final decisions |
| User | Current or future system users | User requirements, usability needs, workflow |
| Domain Expert | Familiar with problem and environment | Domain knowledge, business rules, constraints |
| Developer | Technical staff | Technical feasibility, design constraints |
| Others | Project manager, tester, etc. | Testing requirements, project constraints |
2. Other Sources
- Existing systems (not necessarily software)
- Existing documentation (user manuals, guides, memos)
- Competing systems
- Documentation about interfacing systems
- Standards, policies, collective agreements, and legislation
📌 PAST EXAM - Midterm (Riyadh Seasons)
Q: List all possible stakeholders
Answer:
- Organizers (clients)
- Secure Payment Inc. (external service provider)
- Customers (end users)
🔄 Requirements Elicitation Process
1. Plan
Define objectives and strategy
2. Prepare
Get ready for sessions
3. Perform
Execute elicitation
4. Follow Up
Organize and document
Step 1: Planning for Elicitation
Key Planning Elements
- Objectives: Why this elicitation? (Overall and individual activity goals)
- Strategy & Techniques: Which stakeholders? Which techniques?
- Schedule & Resources: Coordination with clients/customers and development team
- Independent Elicitation: Start with documents & systems before talking to people
- Expected Products: Use cases, SRS, quality attributes specification, etc.
- Risks: Identify potential factors and ways to overcome them
Step 2: Prepare for Elicitation
- Decide on scope: Topics, questions, process flows, or use cases
- Create agenda: Topics to be covered, assigned time, objectives
- Prepare resources: Physical space, participants, documentation, systems
- Identify stakeholders: Learn about cultural, regional, language preferences
- Prepare questions: Imagine learning the user's job
- What else could...?
- What happens when...?
- Would you ever need to...?
- Where do you get...?
- Why do you (or don't you)...?
- Does anyone ever...?
- Draft analysis models: Use cases, process flows (straw man models)
Step 3: Performing Elicitation Activities
✅ Best Practice: Take Good Notes
Document:
- Attendees
- Decisions made
- Actions to be taken and who is responsible
- Outstanding issues
- Key points
Step 4: Following Up After Elicitation
Organize and Share Notes
- Review and update right after session
- Consolidate input from multiple sources
- Edit notes with care
- Keep originals
- Review with stakeholders
Document Open Issues
- Items that need to be further explored
- Gaps that need to be closed
🔍 Classifying Customer Input
Not everything stakeholders say is a requirement. Learn to distinguish:
| Type | Example |
|---|---|
| Business Requirement | "Save SAR X/year on electricity" |
| User Requirement | "I need to print a mailing label" |
| Business Rule | "Time-off approvals must comply with HR vacation policy" |
| Functional Requirement | "The user must be able to sort the project list alphabetically" |
| Quality Attribute | "The mobile software must respond quickly to touch commands" |
| External Interface | "Files submitted electronically cannot exceed 10 MB" |
| Solution Idea | "Select state from drop-down list" |
| Data Definition | "ZIP code has 5 digits + optional 4 digits" |
🏁 When Are We Done with Elicitation?
Signs you're reaching completion:
- ✓ Users can't think of any more use cases or user stories
- ✓ Users propose new scenarios that don't lead to new functional requirements
- ✓ Users repeat issues previously covered
- ✓ Suggested new features/requirements are all out of scope
- ✓ Proposed new requirements are all low priority
- ✓ Developers and testers reviewing requirements have few questions
💡 Remember
You'll never be completely done, but these signs suggest you're reaching a good stopping point for the current iteration.
⚠️ Elicitation Challenges
Sources of Challenge & Mitigations
| Source | Challenges | Mitigations |
|---|---|---|
| Scope | • Inadequately defined • Incorrectly defined • Hard to maintain focus |
• Re-check scope before delving in • Use "in-scope" and "out-of-scope" labels |
| Requirements | • Assumed requirements • Implied requirements • Missing requirements |
• Ask "What are we assuming here?" • Analyze requirements systematically |
| Business Analyst | • Lack of expertise • Lack of domain knowledge |
• Research domain • Consult others |
| Stakeholders | • Uncertainty • Limited technical knowledge • Availability issues • Cooperation problems • Conflicts |
• BA's interpersonal skills • Communication skills • Interviewing techniques |
📌 PAST EXAM - Major 1
Q: Collecting quality requirements is considered problematic, discuss what problems we may face as RE when collecting and specifying such requirements
Sample Answer:
- We lack the right expertise for many professions
- Not many experienced software engineers or domain experts are always available
- Extracting requirements from stakeholders can be problematic as stakeholders are not always available
- Many stakeholders may view our presence as a threat to their job and thus will not cooperate
- Many important areas in requirements can be difficult to specify clearly
🛠️ Requirements Elicitation Techniques
Two Categories
- Facilitated (Interactive): Work with stakeholders directly
- Primarily focus on discovering user and business requirements
- Independent: Work on your own
- Focus on discovering needed functionality users might not be aware of
Facilitated Techniques
1. Interviews
One-on-one or small group sessions with stakeholders.
Strengths:
- Effective for getting to know application domain quickly
- Interviewees more comfortable sharing thoughts than in workshops
- Easier to establish user involvement
- Suitable for busy executives
✅ Interview Tips
- Acquire background knowledge: Domain, interviewee's work
- Prepare questions: Have structured questions ready
- Establish rapport: Introduce yourself, review agenda
- Stay in scope: Keep focused on objectives
- Suggest ideas: Don't just listen—actively contribute
- Listen actively: Paraphrase to confirm understanding
💡 Interview Example
User: "My elevators are too slow!"
Bad Response: "I don't think so. I think you have an elevator throughput problem, not a speed problem."
Good Response: "I see. Tell me why you feel they are too slow."
Lesson: Never contradict directly—explore the user's perspective!
2. Workshops
Facilitated, structured meetings with multiple stakeholders concurrently.
"Facilitation is the art of leading people through processes toward agreed-upon objectives in a manner that encourages participation, ownership, and productivity from all involved" - Sibbet, 1994
Strengths:
- Effective in solving disagreements
- Suitable for tight schedules
- Multiple viewpoints gathered at once
✅ Workshop Tips
- Establish ground rules and enforce them
- Fill all team roles: Facilitator, scribe, etc.
- Plan an agenda: Structured approach
- Stay in scope: Don't let discussions wander
- Use parking lots: Capture items for later consideration
- Timebox discussions: Keep momentum
- Keep team small: But include right stakeholders
- Keep everyone engaged: Watch for dominators!
3. Focus Groups
Representative group of users who generate input on functional and quality requirements.
Strengths:
- Valuable for developing commercial products
- Explores users' attitudes, impressions, preferences, needs
Key Points:
- Keep them on topic without influencing opinions
- Include users from different user classes or same class (multiple sessions)
- Participants normally don't have decision-making authority
- Generates subjective feedback for further evaluation
4. Observations
Shadow important users as they do their work—"in the wild."
Strengths:
- Useful for important or high-risk tasks
- Facilitates requirements validation
- Identifies new topics for interviews
Methods:
- Silent observation
- Interactive (ask questions)
- May be supplemented with questionnaires/interviews
- Time-consuming but valuable
5. Questionnaires
Survey large groups to understand their needs.
Strengths:
- Inexpensive
- Suitable for large user populations
- Easily administered across geographical boundaries
✅ Questionnaire Tips
- Cover full set of possible responses
- Make answer choices mutually exclusive and exhaustive
- Avoid suggestive questions
- Use scales consistently
- Use closed questions with choices for statistical analysis
- Consult an expert on questionnaire design
- Test the questionnaire before distribution
- Avoid asking too many questions (fatigue)
Independent Techniques
6. System Interface Analysis
Examine systems to which your system connects.
- Reveals functional requirements for data/service exchange
- Consult context diagrams and ecosystem maps
- Identify functionality in other systems that may lead to requirements
7. User Interface Analysis
Study existing systems to discover user and functional requirements.
Strengths:
- Suitable for building new version of existing system
- Facilitates identification of improvement areas
- Relates user input to reality
Important:
Don't assume you need to stick to all features of the existing UI for next implementation!
8. Document Analysis
Examine any existing documentation for potential requirements.
- Good way to get up to speed on existing system or new domain
- Documents might not be up to date
- User manuals, guides, memos, change histories, etc.
📌 PAST EXAM - Major 1 (Riyadh Seasons)
Q: How can you gather further requirements? Mention three different elicitation methods. For each, explain: (i) Why suitable? (ii) What stakeholders? (iii) How to implement?
Sample Answer 1: Analyze Existing Systems
- Why: Many cities have developed similar event systems. We can learn from others without reinventing the wheel.
- Stakeholders: Most appropriate for organizers
- Implementation: Task teams to examine current systems and extract requirements, then sit with organizers to see if extracted requirements fit their needs and wants.
Sample Answer 2: Interviews
- Why: Very important to gather ideas and opinions of all stakeholders to understand what they have in mind. Can't develop without their input.
- Stakeholders: Appropriate for all stakeholders
- Implementation: Conduct interviews with organizers, Secure Payment Inc., and customers to understand what they want and need in the system.
Sample Answer 3: Prototyping
- Why: Prototypes help discover new requirements that stakeholders didn't know existed. Not all can state requirements off the top of their head.
- Stakeholders: Most appropriate for organizers and customers
- Implementation: Create prototypes, have stakeholders use them, examine reactions and facial gestures, then get verbal feedback to extract requirements.
📝 Use Cases
Definition
A use case is a sequence of interactions between a system and an external actor that results in the actor being able to achieve some outcome of value.
- User-centric and usage-centric technique
- Shifts from product-centric perspective ("what do you want the system to do?") to user-centric perspective ("what do you need to accomplish?")
Usage Scenario vs. Use Case
- Scenario: Description of a single instance of usage
- Specific actor, at specific time, with specific data
- Use Case: Collection of related usage scenarios
- A scenario is a specific instance of a use case
Example:
Use Case: "Request a Chemical"
- Scenario 1: Request chemical from stockroom
- Scenario 2: Request chemical from vendor
Representation of Use Cases
Textual Representation
Narrative Form: Paragraph focusing on primary scenario and some secondary ones
Example: "A User inserts a card in the card reader slot. The system asks for a personal identification number (PIN). The user enters a PIN. After checking that the user identification is valid, the system asks the user to choose an operation..."
Useful when stakeholders first meet
Visual Representation
Use Case Diagram: UML diagram showing actors, use cases, and relationships
Use Case Diagram Elements
- Actor: External entity that interacts with system (stick figure)
- Use Case: System functionality (oval)
- Relationships:
- <<include>>: Base use case requires included use case
- <<extend>>: Base use case optionally extended
- Association: Actor to use case (line)
Use Case Best Practices
- Use case names written as verb + object (e.g., "Buy Ticket", "Register Customer")
- Actor names reflect roles rather than actual people
- Use right level of abstraction
Use Cases - Strengths & Risks
Strengths:
- Users have clearer expectations of what system will do
- BAs and developers better understand user's business
- Prevents implementation of unneeded functionality
- May be turned into object models for OO design
Risks:
- Too many use cases (overwhelming)
- Highly complex use cases (hard to understand)
📌 PAST EXAM - Midterm
Q: Draw a use case diagram for a ticket distributor for a train system. The system includes two actors: traveler and central computer system. Use cases: BuyOneWayTicket, BuyWeeklyCard, BuyMonthlyCard, UpdateTariff. Exceptions: Time-Out, TransactionAborted, DistributorOutOfChange, DistributorOutOfPaper.
Students should draw a proper use case diagram with travelers connected to ticket purchase use cases, computer system connected to UpdateTariff, and exception use cases extending from base use cases.
⚠️ Misuse Cases
Definition
Negative scenario: A scenario whose goal is:
- Undesirable from business organization's viewpoint
- Desirable from hostile agent's viewpoint (not necessarily human)
Misuse case: Captures use cases that a system must be protected against
- Proposed by Sindre & Opdahl (2000)
- Obvious applications for security and risk analysis
Finding Misuse Cases - 3 Steps
- Identify potential misactors for a given use case diagram
- Misactor = agent with intentions to harm the system
- Identify misuse cases – what would actors do to harm system?
- Express goals of misactors
- Add relationships (<<threaten>>)
- Mitigate misuse cases
- What would neutralize the threats?
- New use cases or secondary scenarios (<<mitigate>>)
Example:
Normal Use Cases: Browse Catalog, Register Customer
Misactors: Competitor, Crook
Misuse Cases: Flood System, Steal Password
Mitigations: Block Repeated Registrations, Encrypt Message
Misuse Cases - Benefits & Risks
Benefits:
- Elicitation of security and safety requirements
- Early identification of threats, mitigations, and exceptions
- Early identification of test cases
- Documentation of rationales
Risks:
- May lead to premature design solutions during mitigation
- Goal should be to find requirements (safety, security), not design
- Potential for missing misactors/threats in partial view
📝 Practice Question
Q: For an online banking system, identify potential misuse cases and their mitigations.
Suggested Answer:
- Misactor: Hacker
- Misuse Case: Intercept Transaction Data
- Mitigation: Implement End-to-End Encryption
- Misactor: Identity Thief
- Misuse Case: Bypass Authentication
- Mitigation: Two-Factor Authentication
🎨 Prototyping
Definition
A software prototype is a partial, possible, or preliminary implementation of a proposed new product.
- Can be: static designs or working models
- Can be: quick sketches or highly detailed screens
- Can be: visual displays or full slices of functionality
- Takes a tentative step into the solution space
Purpose of Prototyping
Prototypes serve three major purposes (must be clear from beginning!):
- Clarify, complete, and validate requirements – requirements tool
- Explore design alternatives – design tool
- Create a subset that will grow into ultimate product – construction tool
Prototype Attributes
| Attribute | Options |
|---|---|
| Scope | • Mock-up (interface only) • Proof-of-concept (key functionality) |
| Future Use | • Throwaway (discard after use) • Evolutionary (grows into product) |
| Form | • Paper (low-fidelity) • Electronic (high-fidelity) |
Fidelity Levels
| Fidelity | Description | Pros | Cons |
|---|---|---|---|
| Low | Static or non-functional | • Easy, quick, cheap • Excellent for interfaces |
• Not interactive • May deter some stakeholders |
| High | Fully functional | • Deeper understanding • More precise decisions |
• Time consuming & costly • May be difficult to change |
💡 Memory Trick: Fidelity
Fidelity = How REAL and REACTIVE the prototype is
Low fidelity = Paper sketches (static)
High fidelity = Working software (reactive)
Prototyping - Strengths & Risks
Strengths:
- Enhances user involvement
- Closes expectation gaps
- Resolves uncertainties early in development
Risks:
- Pressure to release the prototype
- Distraction by detail
- Unrealistic performance expectations
- Investing excessive effort in prototypes
✅ Prototyping Success Factors
- Include prototyping in project plans
- State the purpose before building
- Plan to develop multiple prototypes
- Create throwaways as quickly and cheaply as possible
- Don't prototype requirements you already understand (unless exploring design)
- Don't expect prototype to replace written requirements
📊 Comparison of Elicitation Techniques
| Technique | Good For | Plus | Minus |
|---|---|---|---|
| Questionnaires | Specific questions | Reach many people with low resources | Design crucial; low response rate; may not get desired responses |
| Interviews | Exploring issues | Guide interviewee; encourages contact | Time consuming; artificial environment |
| Focus Groups | Multiple viewpoints | Highlights consensus/conflict; encourages contact | Time consuming |
| Observation | Understanding context | Insight that other techniques can't give | Very time consuming; huge amounts of data |
| Document Analysis | Learning procedures/standards | No time commitment from users | Day-to-day work differs from documented procedures |
🎯 Factors for Choosing Elicitation Techniques
When choosing appropriate elicitation techniques, consider:
- Nature of information being elicited
- Conscious, unconscious, or subconscious requirements?
- Time and budget constraints
- Availability of stakeholders
- Experience of BA with particular techniques
💡 Memory Trick: N-T-A-E
Nature of information
Time & budget
Availability of stakeholders
Experience of BA
✨ Requirements Elicitation Best Practices
- ✓ Define product vision and project scope
- ✓ Identify user classes and their characteristics
- ✓ Select a product champion for each user class
- ✓ Conduct focus groups with typical users
- ✓ Work with user representatives to identify user requirements
- ✓ Identify system events and responses
- ✓ Hold elicitation interviews
- ✓ Hold facilitated elicitation workshops
- ✓ Observe users performing their jobs
- ✓ Distribute questionnaires
- ✓ Perform document analysis
- ✓ Examine problems of current system
- ✓ Reuse existing requirements
🎓 Final Remarks
Remember:
- Requirements elicitation is perhaps the most challenging, critical, error-prone, and communication-intensive aspect of software development
- Try to extract the essence of stakeholders' requirements
- Invent new ways for users to better perform their tasks
- Elicitation is incremental and iterative
- No single technique is best—use a combination based on context
📝 Practice Questions
Question 1
List the four steps of the requirements elicitation process and briefly describe each.
Answer:
- Plan: Define objectives, select strategies/techniques, schedule resources, identify risks, and expected products
- Prepare: Decide on scope and agenda, prepare resources, identify stakeholders, prepare questions, draft models
- Perform: Execute elicitation activities and take good notes (attendees, decisions, actions, issues, key points)
- Follow Up: Organize and share notes, document open issues, review with stakeholders
Question 2
What are the main differences between interviews and workshops as elicitation techniques?
Answer:
- Interviews: One-on-one or small group; interviewees more comfortable sharing; easier to establish rapport; suitable for busy executives; good for getting to know domain quickly
- Workshops: Multiple stakeholders concurrently; facilitated and structured; effective in solving disagreements; suitable for tight schedules; requires careful facilitation to prevent domination
Question 3
Explain the difference between a use case and a usage scenario with an example.
Answer:
- Use Case: Collection of related usage scenarios describing interactions to achieve an outcome of value (e.g., "Withdraw Cash from ATM")
- Usage Scenario: Single instance of a use case with specific actor, time, and data (e.g., "Customer John withdraws SAR 500 from ATM on Jan 7, 2026 at 3:00 PM using his debit card")
Question 4
What factors should be considered when choosing elicitation techniques?
Answer (N-T-A-E):
- Nature of information: Conscious, unconscious, or subconscious requirements
- Time and budget constraints
- Availability of stakeholders
- Experience of BA with particular techniques
Question 5
Describe the three-step process for finding misuse cases.
Answer:
- Step 1: Start from normal use case diagram and identify potential misactors (hostile roles)
- Step 2: Ask what would misactor do to harm system, express goals, add <<threaten>> relationships
- Step 3: Mitigate misuse cases by asking what would neutralize threats, add new use cases or scenarios with <<mitigate>> relationships
📚 Chapter Summary
Key Takeaways
- Elicitation is about extracting and discovering requirements, not just collecting them
- The elicitation process has 4 steps: Plan → Prepare → Perform → Follow Up
- Requirements come from multiple sources: stakeholders, existing systems, documents, standards
- Two categories of techniques: Facilitated (interactive) and Independent
- Facilitated techniques: Interviews, Workshops, Focus Groups, Observations, Questionnaires
- Independent techniques: System Interface Analysis, User Interface Analysis, Document Analysis
- Use cases are user-centric descriptions of interactions to achieve outcomes of value
- Misuse cases help identify security and safety requirements
- Prototyping helps clarify requirements but has risks (don't release, don't over-invest)
- Choose techniques based on N-T-A-E: Nature, Time, Availability, Experience
- Elicitation is iterative—you'll never be completely done!
🎯 وش يعني استنباط المتطلبات؟
التعريف
استنباط المتطلبات هو عملية استخراج احتياجات وقيود أصحاب المصلحة للنظام قبل لا نبني النظام.
معلومة: كلمة Elicit يعني “نستخرج / نطلع / نجيب من الشخص” (استنبط، استخرج، انتزع)
أهم الملامح
- عملية تعاونية وتحليلية فيها جمع/اكتشاف/استخراج/تعريف المتطلبات
- مو بس “نجمع كلام المستخدم” ونكتبه زي ما هو
- نطلع متطلبات أعمال، مستخدم، وظيفية، وغير وظيفية
- غالباً هي أصعب وأخطر وأكثر جزء فيه أخطاء وتواصل بتطوير البرمجيات
💡 خدعة للتذكّر
ELICIT = Extract, Listen, Investigate, Collaborate, Interpret, Transform
الفكرة: مو قاعدين نجمع بس… قاعدين نستخرج ونحوّل احتياجهم لمتطلبات واضحة.
🎯 أهداف الاستنباط
- تحديد مصادر المعلومات واختيار الطرق المناسبة
- استخراج معلومات عن المجال، المشكلة، الاحتياج، والقيود
- إخراج أول وثيقة:
- غالباً متطلبات مستخدم + ملاحظات جلسات
- ممكن تكون ناقصة/ملخبطة/فيها تعارضات
- بس لازم نبدأ من مكان
مهم: تطوير المتطلبات تكراري. نسوي استنباط → نحلل → نكتب متطلبات → نكتشف نقص/تعارض → نرجع للاستنباط… وهكذا.
📚 مصادر المتطلبات
1) أصحاب المصلحة (أنواع مختلفة)
| نوع صاحب المصلحة | دوره/وصفه | وش يقدّم |
|---|---|---|
| العميل/الزبون | اللي يدفع تكلفة التطوير | أهداف الأعمال، الميزانية، القرار النهائي |
| المستخدم | مستخدمين حاليين أو مستقبليين | احتياجات الاستخدام، سهولة الاستخدام، سير العمل |
| خبير مجال | فاهم بيئة المشكلة | قواعد العمل، المعرفة بالمجال، القيود |
| المطوّر | الطاقم التقني | الجدوى التقنية، قيود التصميم |
| غيرهم | مدير مشروع، مختبر… | متطلبات اختبار، قيود المشروع |
2) مصادر ثانية
- أنظمة موجودة (مو شرط تكون برمجية)
- توثيق موجود (كتيبات/أدلة/مذكرات)
- أنظمة منافسة
- توثيق أنظمة متكاملة (interfacing systems)
- معايير وسياسات وأنظمة ولوائح
📌 اختبار سابق - (موسم الرياض)
س: اذكري أصحاب المصلحة المحتملين
إجابة:
- المنظّمين (العميل)
- Secure Payment Inc. (مزود خدمة خارجي)
- العملاء/الحضور (مستخدمين)
🔄 عملية استنباط المتطلبات
1. Plan
نحدد الأهداف والاستراتيجية
2. Prepare
نجهّز للجلسات
3. Perform
ننّفذ الاستنباط
4. Follow Up
نرتّب ونوثّق
الخطوة 1: التخطيط
أشياء أساسية بالتخطيط
- الأهداف: ليه نسوي استنباط؟
- الاستراتيجية والطرق: مين أصحاب المصلحة؟ وش التقنية المناسبة؟
- الجدولة والموارد: تنسيق مع العميل والفريق
- استنباط مستقل: ابدأي بوثائق/أنظمة قبل مقابلة الناس
- المخرجات المتوقعة: Use cases, SRS…
- المخاطر: وش ممكن يعطّلنا وكيف نتعامل
الخطوة 2: التحضير
- تحديد النطاق: المواضيع والأسئلة والـ flows
- الأجندة: مواضيع + وقت لكل جزء + هدف
- التجهيزات: مكان/حضور/وثائق/أنظمة
- معرفة أصحاب المصلحة: لغة/ثقافة/تفضيلات
- تحضير أسئلة: زي: وش يصير إذا…؟ ليه تسوون…؟ هل قد احتجت…؟
- نماذج أولية للتحليل: use cases / process flows كـ straw man
الخطوة 3: التنفيذ
✅ أهم شيء: خذي ملاحظات مضبوط
- الحضور
- القرارات
- الإجراءات ومن مسؤول عنها
- نقاط معلّقة
- أهم النقاط
الخطوة 4: المتابعة
ترتيب ومشاركة الملاحظات
- راجعيها بعد الجلسة مباشرة
- ادمجي المدخلات من مصادر مختلفة
- عدّلي الملاحظات بحذر وخلي الأصل
- راجعيها مع أصحاب المصلحة
توثيق النقاط المفتوحة
- أشياء تحتاج استكشاف زيادة
- نواقص لازم تتقفل
🔍 تصنيف كلام العميل
مو كل شيء ينقال يعتبر requirement. لازم تفرّقين:
| النوع | مثال |
|---|---|
| متطلب أعمال | "نوفر X ريال بالسنة" |
| متطلب مستخدم | "أحتاج أطبع ملصق شحن" |
| قاعدة عمل | "الموافقات لازم تمشي حسب سياسة HR" |
| متطلب وظيفي | "المستخدم يقدر يرتّب القائمة أبجديًا" |
| صفة جودة | "التطبيق يستجيب بسرعة للمس" |
| واجهة خارجية | "الملفات المرسلة ما تتجاوز 10MB" |
| فكرة حل | "خلّ الاختيار من قائمة منسدلة" |
| تعريف بيانات | "الرمز البريدي 5 أرقام + 4 اختياري" |
🏁 متى نعتبر إننا خلصنا الاستنباط؟
علامات إنكم قربتم تخلصون (لهالـ iteration):
- ✓ المستخدمين ما عاد عندهم use cases جديدة
- ✓ السيناريوهات الجديدة ما تطلع وظائف جديدة
- ✓ تكرار نفس المشاكل اللي انقالت قبل
- ✓ أي شي جديد كله خارج النطاق
- ✓ أي متطلبات جديدة كلها أولويتها منخفضة
- ✓ المطورين/التسترز أسئلتهم قليلة على المتطلبات
💡 تذكير
صدق ما راح “تخلصين 100%”، بس هذي إشارات إنكم وصلتم نقطة توقف جيدة.
⚠️ تحديات الاستنباط
المصادر + الحلول
| المصدر | التحديات | الحلول |
|---|---|---|
| النطاق | • مو واضح • معرف غلط • صعب نخلي التركيز |
• نراجع النطاق قبل ما نتعمّق • نستخدم In-scope / Out-of-scope |
| المتطلبات | • افتراضات • تلميحات • نواقص |
• نسأل: وش قاعدين نفترض؟ • تحليل منهجي |
| محلل الأعمال | • خبرة أقل • نقص معرفة بالمجال |
• بحث عن المجال • استشارة خبراء |
| أصحاب المصلحة | • عدم وضوح • معرفة تقنية قليلة • توفرهم صعب • تعاون ضعيف • تعارضات |
• مهارات تواصل • مهارات مقابلة • إدارة علاقات |
🛠️ طرق الاستنباط
قسمين
- Facilitated (تفاعلي): نتعامل مباشرة مع أصحاب المصلحة (مقابلات/ورش...)
- Independent (مستقل): نشتغل لحالنا على وثائق/أنظمة... ونطلع أشياء ما ينتبهون لها المستخدمين
Facilitated
1) مقابلات
✅ نصايح سريعة
- اجمعي خلفية عن المجال
- حضّري أسئلة
- ابدئي بتعريف وراجعي الأجندة
- خليك داخل النطاق
- اسمعي وكرري الفكرة للتأكيد
2) ورش عمل
- تفيد إذا فيه اختلافات وتحتاجون تتفقون بسرعة
- تجمع أكثر من وجهة نظر بنفس الوقت
3) Focus Groups
- مفيدة للمنتجات التجارية عشان تلتقط تفضيلات وانطباعات المستخدمين
- الناس عادة ما عندهم قرار نهائي—يعطون feedback
4) Observation
- تشوفين الشغل الحقيقي “على الطبيعة”
- تفيد بالمهام الحرجة/عالية المخاطر
5) Questionnaires
- رخيصة وتوصل لكثير ناس
- بس تصميمها مهم جدًا
Independent
6) System Interface Analysis
- تفيد لمعرفة متطلبات تبادل بيانات/خدمات مع أنظمة ثانية
7) User Interface Analysis
- تفيد إذا بتسوون نسخة جديدة لنظام قديم
- بس لا تفترضين إن لازم تنقلون كل شي زي ما هو
8) Document Analysis
- يساعدك تفهمين المجال بسرعة
- ممكن الوثائق تكون قديمة—انتبهي
📝 Use Cases
وش هي؟
Use case هي سلسلة تفاعلات بين النظام وـ actor خارجي عشان يحقق نتيجة لها قيمة.
- تركز على المستخدم واستخدامه
- تحول السؤال من “وش تبين النظام يسوي؟” إلى “وش تبين تنجزين؟”
Scenario vs Use Case
- Scenario: حالة واحدة محددة
- Use Case: مجموعة سيناريوهات مرتبطة
⚠️ Misuse Cases
سيناريو سلبي هدفه يضر النظام (مفيد لاستخراج متطلبات أمن/سلامة).
- تحديد misactors
- تحديد misuse cases (وش بيسوون عشان يضرون)
- تحديد mitigations (كيف نمنع/نخفف)
🎨 Prototyping
نموذج أولي يعطي تصور/تجربة، يساعد يوضح المتطلبات، بس انتبهي من مخاطره (لا ينضغط عليكم إنه يصير المنتج النهائي).
📚 ملخص الفصل
- الاستنباط = استخراج واكتشاف، مو نسخ كلام
- العملية: Plan → Prepare → Perform → Follow Up
- المصادر متعددة: ناس + أنظمة + وثائق + معايير
- الطرق: تفاعلية + مستقلة
- الاستنباط تكراري (Iterative)