Requirements Engineering: Elicitation, Analysis, Validation & Documentation

TAKEAWAYS:

• Requirements engineering bridges the gap between user needs and technical solutions through structured elicitation, analysis, and validation techniques.
• Elicitation techniques (interviews, surveys, observations) uncover raw requirements, while analysis refines them into clear, testable specifications.
• A Software Requirements Specification (SRS) document is the contract between developers and stakeholders, defining functional/non-functional requirements.
• Prototyping and use cases help validate requirements before development begins, reducing costly rework.
• Common pitfalls include ambiguous requirements, scope creep, and ignoring non-functional constraints (performance, security).
• Agile vs. traditional approaches differ in how requirements are documented (user stories vs. formal SRS).

Core Concepts: What Are Requirements?

Requirements are descriptions of what a system should do (functional) or how it should perform (non-functional). They answer:

• Functional: "What should the system accomplish?" (e.g., "eSewa should allow users to pay utility bills online.")
• Non-functional: "How well should it do it?" (e.g., "The system must process 10,000 transactions per minute during peak hours.")

Why it matters: Poor requirements lead to failed projects (e.g., London’s £18B Heathrow Terminal 5 overrun due to unclear specs). Clear requirements save time, money, and frustration.

The Requirements Engineering Process

stateDiagram-v2
    [*] --> Discover: Elicitation (Interviews, Surveys, etc.)
    Discover --> Analyze: Refine & Prioritize
    Analyze --> Specify: Document (SRS, Use Cases)
    Specify --> Validate: Prototypes, Reviews
    Validate --> Manage: Change Control
    Manage --> [*]

1. Elicitation: Uncovering Raw Requirements

Goal: Extract needs from stakeholders (users, clients, domain experts). Techniques (with real-world Nepali examples):

Worked Example: eSewa’s Bill Payment System

• Problem: Users struggled to pay utility bills via mobile.
• Elicitation:
  • Interview: 50+ users asked, "What’s your biggest pain point?" → 60% said "manual entry errors."
  • Observation: Watching users fill paper forms revealed confusion over due dates.
  • Prototype: A clickable mockup showed users could select bills from a dropdown.
• Outcome: Reduced errors by 70% in the final app.

2. Analysis: Refining Requirements

Goal: Convert raw inputs into clear, consistent, and prioritized requirements. Steps:

1. Classify:
   • Functional (e.g., "System shall generate receipts").
   • Non-functional (e.g., "Response time < 2s for 95% of requests").
2. Prioritize (MoSCoW method):
   • Must have (e.g., login system for eSewa).
   • Should have (e.g., push notifications).
   • Could have (e.g., voice commands).
   • Won’t have (e.g., blockchain for now).
3. Resolve Conflicts:
   • Example: "Users want free delivery (non-functional), but Daraz needs to profit." → Compromise: "Free delivery for orders > Rs. 1,000."

Visual: MoSCoW Prioritization

pie
    title MoSCoW Prioritization for a Banking App
    "Must Have (Login, Transactions)" : 40
    "Should Have (Biometrics, Notifications)" : 35
    "Could Have (Chatbot)" : 15
    "Won’t Have (Cryptocurrency)" : 10

3. Specification: Documenting Requirements

Output: A Software Requirements Specification (SRS) document, the contract between developers and stakeholders. Key Sections of an SRS:

mindmap
  root((SRS Document))
    Introduction
    Overall Description
      Product Perspective
      Product Functions
      User Characteristics
    Specific Requirements
      Functional Requirements (Use Cases)
      Non-Functional Requirements (Performance, Security)
    Appendices (Glossary, Prototypes)

Worked Example: Ncell’s Mobile Recharge App Functional Requirement: "The system shall allow users to recharge any prepaid number using their saved card details with a success rate of 99.9%."

Non-Functional Requirements:

4. Validation: Ensuring Correctness

Goal: Confirm requirements meet stakeholder needs before coding. Techniques:

• Prototyping: Build a low-fidelity (paper) or high-fidelity (interactive) mockup.
  • Example: Kathmandu Traffic Police prototyped a real-time congestion map using Google Maps API before building the app.
• Use Cases: Narrative descriptions of system interactions.
  • Example Use Case: "User pays utility bill via eSewa."

    Actor: Registered User
    Precondition: User logged in, bill due.
    Main Steps:
      1. User selects "Pay Bill" from menu.
      2. System displays list of due bills.
      3. User selects bill and payment method.
      4. System processes payment and sends SMS confirmation.
    Postcondition: Bill status updated to "Paid."
    

• Reviews: Walkthroughs with stakeholders.
  • Example: NEPSE’s team reviewed trading app requirements with brokers to catch a missing "short-selling rule."

5. Management: Handling Changes

Problem: Requirements evolve (e.g., Daraz adding "same-day delivery" after seeing Amazon Prime’s success). Solutions:

• Change Request Form: Document, approve, and track changes.
• Version Control: Track SRS revisions (e.g., "SRS_v1.2: Added dark mode").
• Impact Analysis: Ask, "How will this change affect cost/time?"

In the Real World

1. eSewa’s Bill Payment System

   • Idea Used: Prototyping + Use Cases
   • How: Before coding, eSewa’s team created a clickable prototype showing users how to pay bills. They validated it with 100+ users, leading to changes like adding a "save payment method" feature. This reduced the final app’s error rate by 65%.

2. Pathao’s Driver App

   • Idea Used: Observations + Non-Functional Requirements
   • How: Pathao observed drivers struggling with GPS accuracy in Kathmandu’s narrow streets. They added a "manual pin drop" feature and specified "GPS error margin < 10 meters in urban areas" in the SRS.

3. NTC’s Smart Meter Rollout

   • Idea Used: Workshops + Stakeholder Analysis
   • How: NTC held workshops with villagers, engineers, and politicians to define requirements like:
     • "Meters must work offline for 24 hours" (rural areas).
     • "Data must sync automatically when online" (urban areas).
   • Outcome: Avoided a Rs. 5B overrun by identifying these needs early.

Common Pitfalls and How to Avoid Them

Exam Tip: How to Score Full Marks

1. Structure Your Answer:

   • Start with a definition (e.g., "Requirements engineering is the process of...").
   • Use bullet points for techniques (interviews, surveys, etc.).
   • Include a real-world example (e.g., eSewa, Daraz) to show understanding.

2. Diagrams = Easy Marks:

   • Draw a state diagram for the requirements process.
   • Show a MoSCoW prioritization pie chart or SRS mindmap.

3. Avoid Common Mistakes:

   • ❌ "Requirements are just user stories." → ✅ "Requirements include functional (use cases) and non-functional (performance) specs."
   • ❌ Skipping validation techniques (prototyping, reviews).
   • ❌ Ignoring non-functional requirements (they’re 30% of exam weight!).

4. Memorize These Key Terms:

   • SRS: Software Requirements Specification.
   • MoSCoW: Must-have, Should-have, Could-have, Won’t-have.
   • Use Case: Narrative of system interaction.
   • Prototyping: Building a mockup to clarify needs.

Final Checklist for TU/PU Exams:

• Defined requirements engineering clearly.
• Listed 3+ elicitation techniques with examples.
• Explained functional vs. non-functional requirements.
• Showed a diagram (process, prioritization, or SRS structure).
• Gave a real-world Nepali example (eSewa, Daraz, NTC).
• Discussed validation (prototypes, reviews, use cases).