Requirements Engineering: Elicitation, Analysis & Specification

TAKEAWAYS:

• Requirements engineering bridges the gap between user needs and technical solutions by eliciting, analyzing, and specifying what a system must do.
• Stakeholder analysis identifies who influences requirements (e.g., clients, end-users, developers) and their priorities.
• Use cases and user stories model interactions between actors and systems in a structured, visual way.
• Functional vs. non-functional requirements distinguish features (e.g., "login system") from qualities (e.g., "99.9% uptime").
• Requirements validation (e.g., prototyping, walkthroughs) ensures correctness before development begins.
• Agile vs. traditional approaches differ in documentation rigor, iteration frequency, and stakeholder involvement.

1. Introduction to Requirements Engineering

Requirements engineering (RE) is the foundational phase of software development. It ensures that the final product meets stakeholder expectations by defining what the system should do, not how it will do it. Poor RE leads to costly rework, missed deadlines, or failed projects.

Why is RE Critical?

• Cost of fixing errors: A study by IBM found that fixing a defect in the requirements phase costs $100, while fixing it post-deployment costs $10,000.
• User satisfaction: Misaligned requirements lead to unusable software (e.g., a banking app with unclear transaction limits).
• Legal/compliance risks: Non-functional requirements (e.g., GDPR data privacy) can result in fines or lawsuits.

2. Stakeholder Analysis

Stakeholders are anyone affected by or involved in the system. Identifying them early helps prioritize conflicting needs.

Types of Stakeholders

How to Identify Stakeholders?

1. Brainstorming: List all possible groups (e.g., for an eSewa-like app: users, merchants, bank partners, cybersecurity teams).
2. Interviews: Ask open-ended questions (e.g., "What pain points do you face with current payment systems?").
3. Document analysis: Review existing reports (e.g., Daraz’s customer feedback on checkout delays).
4. Observation: Watch users interact with similar systems (e.g., Pathao drivers using fare-calculation tools).

WORKED EXAMPLE: Khalti App Scenario: Khalti wants to add a "Split Bill" feature for group payments. Stakeholders and Needs:

• Users: Need a simple way to divide bills among friends (e.g., restaurant splits).
• Merchants: Want to avoid manual reconciliation (e.g., splitting a $50 bill among 3 people).
• Banks: Require fraud detection for split transactions.
• Developers: Need APIs to integrate with bank systems.

Conflict: Users want instant splits, but banks require 24-hour fraud checks. Solution: Prioritize non-functional requirements (e.g., "90% of splits processed in <1 minute") and document trade-offs.

3. Requirements Elicitation Techniques

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

sequenceDiagram
    participant User as End-User
    participant Facilitator as Workshop Facilitator
    participant Dev as Developer
    participant Bank as Bank Representative

    User->>Facilitator: "How can we split bills among friends?"
    Facilitator->>Dev: "Technical feasibility?"
    Dev-->>Facilitator: "API latency <1s"
    Facilitator->>Bank: "Fraud checks needed?"
    Bank-->>Facilitator: "24-hour hold for >Rs. 500 splits"
    Facilitator->>User: "Compromise: 90% splits in <1 min"
    User-->>Facilitator: "Agreed"

A. Interviews

• Pros: Deep insights, clarifies ambiguous needs.
• Cons: Time-consuming, biased by interviewer skills.
• Example: A bank interviewing loan officers to define requirements for a digital loan approval system.

B. Surveys/Questionnaires

• Pros: Scalable, quantifiable data.
• Cons: Limited depth, low response rates.
• Example: NTC surveying customers to prioritize mobile data speed improvements.

C. Observations

• Pros: Unbiased, reveals real-world usage patterns.
• Cons: Doesn’t capture "unspoken" needs.
• Example: Watching Kathmandu traffic police use a manual ticketing system to identify pain points for a digital solution.

D. Workshops (JAD - Joint Application Development)

• Pros: Collaborative, fast for small teams.
• Cons: Requires skilled facilitators.
• Example: A PU exam portal team workshopping with students to define online proctoring requirements.

E. Document Analysis

• Pros: Low-cost, leverages existing data.
• Cons: May miss current needs.
• Example: Analyzing NEPSE’s old trading system logs to identify gaps for a new platform.

MERMAID DIAGRAM: Elicitation Techniques Comparison

mindmap
  root((Requirements Elicitation))
    Interviews["1-on-1 or group\n*Pros*: Deep insights\n*Cons*: Time-consuming"]
    Surveys["Questionnaires\n*Pros*: Scalable\n*Cons*: Low response rate"]
    Observations["Watch users\n*Pros*: Unbiased\n*Cons*: Misses unspoken needs"]
    Workshops["JAD Sessions\n*Pros*: Collaborative\n*Cons*: Needs facilitator"]
    Documents["Existing reports\n*Pros*: Low-cost\n*Cons*: Outdated"]

4. Requirements Analysis

Raw requirements are often incomplete, conflicting, or ambiguous. Analysis refines them into a consistent, prioritized set.

Key Activities

1. Categorization: Classify requirements as:

   • Functional: What the system does (e.g., "User can reset password").
   • Non-functional: Qualities like performance, security, or usability.
   • Business rules: Policies (e.g., "Loans > Rs. 500K require collateral").

2. Prioritization: Use MoSCoW or Kano Model to rank requirements.

   • MoSCoW: Must-have, Should-have, Could-have, Won’t-have.
   • Kano Model: Basic (must-have), Performance (more = better), Excitement (unexpected delights).

3. Conflict Resolution: Example:

   • Requirement A: "System must process 10,000 transactions/sec" (Performance).
   • Requirement B: "Use only open-source tools" (Budget).
   • Solution: Negotiate to "Process 5,000 transactions/sec with a mix of open-source and licensed tools."

4. Feasibility Check: Assess if requirements are technically, economically, and legally viable.

   • Example: A Daraz seller asks for "real-time inventory sync across 10,000 warehouses". Is this feasible with current cloud costs?

TABLE: Functional vs. Non-Functional Requirements

5. Requirements Specification

The goal is to produce a clear, unambiguous document (e.g., Software Requirements Specification - SRS) that serves as a contract between stakeholders and developers.

Structure of an SRS

1. Introduction: Purpose, scope, definitions.
2. Overall Description:
   • Product perspective (e.g., "Replaces NTC’s legacy billing system").
   • User characteristics (e.g., "Mostly rural users with basic phones").
3. Functional Requirements: Use use cases or user stories.
4. Non-Functional Requirements: Performance, security, compliance.
5. Appendices: Glossary, diagrams, sample inputs/outputs.

MERMAID DIAGRAM: Use Case for "Pathao Ride Booking"

stateDiagram-v2
  [*] --> User:RequestsRide
  User:RequestsRide --> System:ValidateLocation
  System:ValidateLocation --> System:CheckDriverAvailability
  System:CheckDriverAvailability --> System:MatchBestDriver
  System:MatchBestDriver --> Driver:AcceptsRide
  Driver:AcceptsRide --> System:ConfirmBooking
  System:ConfirmBooking --> User:PayFare
  User:PayFare --> System:EndRide
  System:EndRide --> [*]

Key Elements in a Use Case:

• Actor: User, Driver, Payment Gateway.
• Main Success Scenario: Happy path (e.g., ride booked successfully).
• Extensions: Alternative flows (e.g., "Driver cancels last minute").

6. Requirements Validation

Even the best specifications can have errors or omissions. Validation techniques:

WORKED EXAMPLE: Daraz Order Queue System Requirement: "The system must prioritize orders based on delivery distance." Validation Steps:

1. Prototype: Build a dashboard showing order queues sorted by distance.
2. Walkthrough: Show Daraz logistics team how orders are routed to the nearest warehouse.
3. Test Case:
   • Input: 3 orders (Distance: 5km, 20km, 1km).
   • Expected Output: Orders processed in order of 1km → 5km → 20km.
   • Actual Output: Confirmed via load testing.

7. Agile vs. Traditional Requirements Engineering

When to Use Which?

• Traditional: Highly regulated systems (e.g., NTC’s core network software).
• Agile: Fast-changing markets (e.g., Pathao’s ride-hailing features).

In the Real World

1. eSewa’s "Split Bill" Feature

   • Idea Used: Stakeholder analysis and use case modeling.
   • How: eSewa identified stakeholders (users, merchants, banks) and modeled the split-payment workflow as a use case. The SRS included non-functional requirements like "transaction success rate > 99.5%".

2. Khalti’s Fraud Detection

   • Idea Used: Non-functional requirements (security) and conflict resolution.
   • How: Khalti prioritized "real-time fraud alerts" (non-functional) over "instant payouts" (functional) to comply with RBI regulations. This required trade-offs in system latency.

3. Daraz’s Warehouse Routing

   • Idea Used: Prioritization (MoSCoW) and prototyping.
   • How: Daraz’s logistics team used a simulation prototype to validate that "orders within 10km are prioritized" before rolling out the system. This reduced delivery times by 30%.

4. NEPSE’s Trading Platform

   • Idea Used: Requirements validation via testing.
   • How: NEPSE’s new platform underwent load testing with 10,000 simulated traders to ensure it could handle peak volumes (e.g., during IPO launches).

Exam Tip

1. Expect 20-30% of marks on definitions and comparisons:

   • Be ready to distinguish functional vs. non-functional requirements, elicitation techniques, and Agile vs. traditional RE.
   • Example question: "Differentiate between a use case and a user story with an example from a Nepalese context (e.g., Ncell recharge system)."

2. Case study questions are common:

   • You’ll be given a scenario (e.g., "Design requirements for a digital loan system for a rural bank") and asked to:
     • Identify stakeholders.
     • Draft 3 functional and 2 non-functional requirements.
     • Prioritize them using MoSCoW.
   • Tip: Use real-world examples (e.g., Siddhartha Bank’s loan app) to structure your answer.

3. Diagrams carry marks:

   • Practice drawing:
     • Use case diagrams (e.g., for a WhatsApp payment system).
     • State diagrams (e.g., order status in Daraz: "Pending → Shipped → Delivered").
     • Mindmaps for elicitation techniques.

4. Common pitfalls to avoid:

   • Vague requirements: ❌ "The system should be fast." ✅ "The system must process 90% of transactions in <2 seconds."
   • Ignoring non-functional requirements: Always include performance, security, and usability in your SRS.
   • Overlooking validation: Mention at least two validation techniques (e.g., prototyping + reviews) in your answer.

In the real world

• eSewa: Used stakeholder analysis to prioritize merchant needs (e.g., instant refunds) vs. bank compliance (fraud checks), leading to a phased rollout of dispute-resolution features.
• Pathao: Requirements elicitation via driver surveys revealed the need for real-time fare adjustments, which was later validated through prototyping (mock GPS-based dynamic pricing).
• NEPSE: Non-functional requirements (e.g., 99.99% uptime during trading hours) were specified after analyzing historical system crashes, resulting in a redundant server architecture.