Requirements Engineering: Elicitation, Analysis, Specification & Validation

TAKEAWAYS:

• Requirements engineering bridges user needs and technical solutions, ensuring software meets stakeholder expectations.
• Techniques like interviews, surveys, and use cases elicit requirements, while MoSCoW prioritization helps manage scope.
• Functional vs. non-functional requirements define what and how well the system should work (e.g., Daraz’s order processing speed).
• SRS (Software Requirements Specification) documents requirements formally, acting as a contract between developers and clients.
• Validation techniques (prototyping, walkthroughs) catch ambiguities early, saving costly rework.
• Misaligned requirements are the #1 cause of project failures—Nepal’s NTC’s digital ticketing system faced delays due to unclear stakeholder needs.

1. Introduction to Requirements Engineering

Requirements engineering (RE) is the art and science of discovering, documenting, and managing software requirements. It ensures that the final product aligns with user needs, business goals, and technical constraints. Poor RE leads to:

• Scope creep (e.g., eSewa’s delayed features due to unmanaged stakeholder demands).
• Rework costs (up to 50% of total project costs, per Standish Group).
• User dissatisfaction (e.g., Pathao’s early version lacked real-time traffic updates).

Why is RE Critical?

• User-centric design: Ensures the system solves real problems (e.g., Khalti’s UPI integration required clear payment flow requirements).
• Risk mitigation: Identifies conflicts early (e.g., NEPSE’s trading platform needed strict security requirements).
• Legal/compliance: Meets regulatory needs (e.g., banks’ KYC requirements for digital loans).

2. Types of Requirements

Requirements are classified into functional and non-functional:

3. Requirements Elicitation Techniques

Elicitation is the process of collecting requirements from stakeholders. Common techniques:

A. Interviews

• How it works: One-on-one or group discussions with stakeholders (e.g., Daraz’s delivery partners, customers).
• Pros: Deep insights, clarifies ambiguities.
• Cons: Time-consuming, biased if interviewer is inexperienced.
• Example:
  • Stakeholder: Daraz’s logistics team.
  • Question: "What are the top 3 delays in order delivery?"
  • Requirement Elicited: "System must auto-notify customers if delivery is delayed by >2 hours."

B. Surveys/Questionnaires

• How it works: Structured questions sent to a large group (e.g., NTC’s app feedback form).
• Pros: Scalable, quantifiable data.
• Cons: Low response rates, lacks depth.
• Example Survey Question:

  "How often do you face issues with online ticket booking?" Options: [Never | Rarely | Often | Always]

C. Use Cases

• How it works: Describes interactions between users and the system in a structured format.
• Example: Use Case for eSewa Bill Payment

  stateDiagram-v2
      [*] --> User:Logs in
      User:Logs in --> System:Shows dashboard
      System:Shows dashboard --> User:Selects "Pay Bill"
      User:Selects "Pay Bill" --> System:Displays bill options
      System:Displays bill options --> User:Chooses utility (e.g., NTC)
      User:Chooses utility --> System:Requests OTP
      System:Requests OTP --> User:Enters OTP
      User:Enters OTP --> System:Processes payment
      System:Processes payment --> System:Shows receipt
      System:Shows receipt --> [*]

• Key Components:
  • Actor: User, admin, or external system (e.g., NTC’s API).
  • Main Success Scenario: Happy path (e.g., successful payment).
  • Extensions: Error handling (e.g., "If OTP fails 3 times, lock account").

D. Prototyping

• How it works: Create a low-fidelity (paper) or high-fidelity (digital) mockup to visualize requirements.
• Example:
  • Problem: NTC’s app had unclear ticket booking flow.
  • Solution: A wireframe prototype revealed users struggled with multi-step forms.
  • Requirement: "Simplify booking to 2 steps: Select route → Pay."

E. Document Analysis

• How it works: Review existing documents (e.g., bank’s loan policy for a digital lending app).
• Example:
  • Document: Nepal Rastra Bank’s (NRB) guidelines for fintech apps.
  • Requirement: "App must verify user identity via Aadhaar or passport."

F. Brainstorming

• How it works: Group session to generate ideas (e.g., Khalti’s team brainstorming new features).
• Rule: No criticism during idea generation.

4. Requirements Analysis

After elicitation, requirements must be analyzed for completeness, consistency, and feasibility.

A. Prioritization Techniques

B. Conflict Resolution

Conflicts arise when requirements contradict (e.g., "App must be fast" vs. "Must support 100+ features"). Solutions:

1. Negotiation: Balance trade-offs (e.g., prioritize speed over features).
2. Prioritization: Use MoSCoW to drop "Won’t-haves."
3. Abstraction: Combine requirements (e.g., "Fast + feature-rich" → "Optimized for mid-range phones").

C. Feasibility Study

• Technical Feasibility: Can the system be built with current tech? (e.g., "Can Pathao’s app support real-time traffic via satellite data?")
• Economic Feasibility: Is it cost-effective? (e.g., "Will NTC’s app reduce ticketing costs by 20%?")
• Operational Feasibility: Will users adopt it? (e.g., "Will elderly users accept a mobile app for NTC tickets?")

5. Requirements Specification

The Software Requirements Specification (SRS) document formalizes requirements. Key sections:

A. SRS Structure (IEEE Standard)

1. Introduction
   • Purpose, scope, definitions, acronyms.
2. Overall Description
   • Product perspective, user characteristics, assumptions.
3. Specific Requirements
   • Functional: Use cases, scenarios.
   • Non-functional: Performance, security, usability.
4. Appendices
   • Glossary, diagrams, prototypes.

B. Example SRS Snippet (eSewa Payment System)

**Functional Requirement FR-001**:
The system shall allow users to pay utility bills (e.g., NTC, NEA) via UPI.
- **Actor**: Registered eSewa user.
- **Precondition**: User has linked bank account.
- **Postcondition**: Payment is processed, and receipt is sent via SMS.
- **Extensions**:
  - If payment fails, system shall notify user and offer retry.
  - If user cancels, refund shall be processed within 24 hours.

C. Tools for SRS

• Natural Language: Simple but ambiguous (e.g., "System must be user-friendly").
• Structured Language: Tables, decision trees (reduces ambiguity).
• UML Use Case Diagrams: Visualizes interactions (see earlier example).
• Mathematical Notation: For precise requirements (e.g., "Response time ≤ 1s for 90% of requests").

6. Requirements Validation

Validation ensures requirements are correct, complete, and consistent. Techniques:

7. Common Pitfalls and Best Practices

Pitfalls

• Ambiguity: "System must be fast" → Define "fast" (e.g., "<200ms response time").
• Gold Plating: Adding unnecessary features (e.g., Daraz adding AR product views before core checkout).
• Ignoring Non-Functional Requirements: Focusing only on features, not performance/security.
• Changing Requirements Late: Scope creep (e.g., NTC’s app kept adding features after launch).

Best Practices

• Involve All Stakeholders: Include users, developers, and business teams.
• Iterative Approach: Refine requirements in cycles (agile).
• Traceability: Link requirements to design/test cases (e.g., "FR-001 → Test Case TC-005").
• Automate Validation: Use tools like JIRA or Confluence to track requirements.

In the Real World

1. eSewa’s Payment Flow

   • Idea Used: Use Case Modeling + Non-Functional Requirements
   • How: eSewa’s team used use cases to map user interactions (e.g., "Pay Bill" → "Verify OTP" → "Confirm Payment"). Non-functional requirements ensured 99.9% uptime during festivals and <1s response time for transactions.

2. Pathao’s Ride Matching Algorithm

   • Idea Used: Performance Requirements + Conflict Resolution
   • How: Pathao’s requirement "Match rider to driver in <3 seconds" conflicted with "Support 10,000+ concurrent users." The team resolved this by:
     • Using geohashing for location-based matching.
     • Prioritizing Must-have (fast matching) over Could-have (real-time traffic rerouting).

3. NTC’s Digital Ticketing System

   • Idea Used: Stakeholder Analysis + Prototyping
   • How: NTC’s initial requirements ignored elderly users and offline mode. A paper prototype revealed:
     • Users struggled with small touch targets → Requirement: Larger buttons.
     • No ticket printing option → Requirement: Offline QR code generation.

Worked Example: Daraz’s Order Queue System

Scenario: Daraz’s warehouse must process orders efficiently during sales like "Daraz Days."

Step 1: Elicit Requirements

• Interview with Warehouse Manager:
  • "What’s the biggest bottleneck?" → "Order sorting takes 2 hours."
  • Requirement: "System must auto-sort orders by priority (urgent, standard)."
• Survey with Customers:
  • "How often do you face delayed deliveries?" → 60% said "Often."
  • Requirement: "Reduce delivery time by 30%."

Step 2: Analyze and Prioritize

Step 3: Specify in SRS

**Functional Requirement FR-003**:
The warehouse management system shall auto-sort orders based on:
1. **Priority**: Urgent (paid for next-day delivery) > Standard.
2. **Location**: Group orders by delivery zone (e.g., Kathmandu, Pokhara).
- **Input**: Order ID, priority flag, delivery address.
- **Output**: Sorted order list for pickers.
- **Extensions**:
  - If system fails, manual override shall be available.
  - Log all sorting actions for audit.

Step 4: Validate with Prototyping

• Low-Fidelity Prototype:

  flowchart TD
      A["Order Received"] --> B["Check Priority"]
      B -->|"Urgent"| C["Route to Express Lane"]
      B -->|"Standard"| D["Route to Regular Lane"]
      C --> E["Picker Assigns"]
      D --> E

• Testing: Simulated 5,000 orders → Result: Sorting time reduced from 2 hours to 15 minutes.

Exam Tip

How This Unit is Examined (PU Pattern)

1. Short Questions (2-5 marks):

   • Define requirements elicitation, SRS, or MoSCoW prioritization.
   • Example Question:

     "Differentiate between functional and non-functional requirements with an example from a Nepalese app."

2. Long Questions (10-15 marks):

   • Scenario-Based: Given a case (e.g., "Design requirements for a digital loan app for a Nepalese bank").
     • Steps to Answer:
       1. Identify stakeholders (bank, customers, regulators).
       2. Elicit 3 functional and 2 non-functional requirements.
       3. Prioritize using MoSCoW.
       4. Draft a use case for "Apply for Loan."
   • Diagram-Based: Draw a use case diagram or state diagram for a given scenario.

3. Case Study (15-20 marks):

   • Example: "NTC wants to develop an app for ticket booking. As a requirements engineer, document the SRS for the 'Book Ticket' use case."
     • Marks Breakdown:
       • 5 marks: Identify stakeholders and their needs.
       • 5 marks: List 3 functional and 2 non-functional requirements.
       • 5 marks: Draw a use case diagram.
       • 5 marks: Write a use case scenario with extensions.

Key Formulas/Checklists for Exams

Common Mistakes to Avoid

• Ignoring Non-Functional Requirements: Always include performance, security, and usability.
• Vague Language: Avoid "user-friendly" → Specify "must pass Nielsen’s 10 usability heuristics."
• Missing Traceability: Link requirements to test cases (e.g., "FR-001 → Test Case TC-001").
• Overlooking Stakeholders: Include users, developers, business, and regulators (e.g., NRB for fintech apps).

Final Worked Example for Exam Practice

Question: "A Nepalese food delivery app like Foodmandu wants to add a 'Subscription Plan' feature. As a requirements engineer, document the requirements for this feature using:

1. One functional requirement with a use case.
2. Two non-functional requirements.
3. Prioritize them using MoSCoW."

Answer:

1. Functional Requirement: Subscribe to Plan

**FR-005: Subscription Plan**
- **Actor**: Registered user.
- **Trigger**: User clicks "Subscribe" on the dashboard.
- **Main Success Scenario**:
  1. System displays available plans (Monthly: Rs. 999, Quarterly: Rs. 2,500).
  2. User selects plan and enters card details.
  3. System processes payment via Khalti/eSewa.
  4. System grants subscription benefits (e.g., 20% off, free delivery).
- **Extensions**:
  - If payment fails, system shall notify user and offer retry.
  - If user cancels within 24 hours, refund shall be processed.

Use Case Diagram:

erDiagram
    USER ||--o{ SUBSCRIPTION_PLAN : "selects"
    SUBSCRIPTION_PLAN ||--|| PAYMENT_GATEWAY : "processes"
    SUBSCRIPTION_PLAN }|--|| BENEFITS : "grants"

2. Non-Functional Requirements

3. MoSCoW Prioritization