Requirements Engineering: Elicitation, Analysis & Specification

TAKEAWAYS:

• Requirements engineering bridges user needs and technical solutions, ensuring software meets business goals.
• Techniques like interviews, surveys, and prototyping elicit raw requirements, while analysis refines them into clear, testable specifications.
• A Software Requirements Specification (SRS) document is the contract between developers and stakeholders, defining scope, features, and constraints.
• Misaligned requirements (e.g., omitting security in eSewa) lead to costly rework; validation (reviews, prototyping) prevents this.
• Non-functional requirements (performance, usability) often fail in apps like Daraz if ignored during design.
• Agile vs. traditional approaches differ in how requirements are documented (user stories vs. formal SRS).

1. What Are Software Requirements?

Software requirements are descriptions of what a system must do and how it must perform to satisfy stakeholders. They answer:

• Functional requirements: What the system should do (e.g., "Khalti app must allow P2P transfers").
• Non-functional requirements: How well it should do it (e.g., "Ncell’s IVR must respond in <2 seconds").

Why Are Requirements Critical?

• Cost of fixing errors: A study by IBM found that fixing a defect in the requirements phase costs $100, but in testing it costs $1,000 and in production $10,000.
• User satisfaction: Poor requirements lead to systems users reject (e.g., NTC’s outdated ticketing portal).
• Legal/compliance: Banks (e.g., NMB) must meet KYC requirements; violating them risks fines.

2. Requirements Elicitation: Gathering Needs

Elicitation is the process of collecting raw requirements from stakeholders (users, clients, domain experts). Common techniques:

Challenges in Elicitation

• Stakeholder conflicts: Users want low cost; management wants fast delivery.
• Vague requirements: "The system should be user-friendly" → Needs metrics (e.g., <3 clicks to complete a task).
• Hidden requirements: Assumptions not stated (e.g., "The app must work offline" for rural areas).

3. Requirements Analysis: Refining the Raw Data

Raw requirements are often incomplete, ambiguous, or conflicting. Analysis involves:

• Prioritization: Using techniques like MoSCoW (Must-have, Should-have, Could-have, Won’t-have).
• Conflict resolution: Mediating between competing needs (e.g., security vs. convenience in eSewa).
• Feasibility study: Checking if requirements are technically/financially possible (e.g., "Real-time traffic updates" for Kathmandu traffic app).

Example: Analyzing a Loan System for a Nepali Bank

Raw Requirement: "Customers should get loans quickly." Analyzed Requirements:

1. Must-have: Loan approval in <24 hours for existing customers.
2. Should-have: Biometric verification for fraud prevention.
3. Could-have: AI-driven credit scoring.
4. Won’t-have: Manual paperwork (replaced by digital forms).

4. Requirements Specification: The SRS Document

The Software Requirements Specification (SRS) is a formal document that describes:

• Functional requirements (e.g., "System shall allow users to reset passwords via OTP").
• Non-functional requirements (e.g., "System shall handle 10,000 concurrent users").
• System models (use cases, diagrams).
• Constraints (e.g., "Must comply with Nepal Rastra Bank’s data security laws").

Structure of an SRS

mindmap
  root((SRS Document))
    Introduction
      Purpose
      Scope
      Definitions
    Overall Description
      Product Perspective
      User Characteristics
      Assumptions & Dependencies
    Specific Requirements
      Functional Requirements
      Non-Functional Requirements
        Performance
        Security
        Usability
    Appendices
      Glossary
      Use Case Diagrams

Example: SRS for a Traffic Management System (Kathmandu)

Functional Requirement (FR1): The system shall detect traffic congestion using GPS data from Pathao/Nepal Police vehicles and reroute users via the mobile app.

Non-Functional Requirement (NFR1): The system shall update routes every 5 minutes with 99.9% accuracy.

5. Requirements Validation: Ensuring Correctness

Validation checks if the requirements are correct, complete, and feasible. Techniques:

• Reviews: Experts inspect the SRS for gaps.
• Prototyping: Build a demo (e.g., Khalti’s payment flow prototype).
• Use case testing: Simulate user scenarios (e.g., "What if a Daraz order fails during checkout?").
• Automated tools: Tools like IBM DOORS or JIRA track requirements.

Common Validation Errors

In the Real World

1. eSewa’s Payment System

   • Idea Used: Non-functional requirements (security, reliability).
   • How: eSewa’s SRS explicitly defines:
     • FR: "Users must authenticate via fingerprint or OTP."
     • NFR: "Transaction data must be encrypted with AES-256."
     • Validation: Stress-tested during Dashain to handle 100,000+ transactions/hour.

2. Daraz’s Order Queue Management

   • Idea Used: Prioritization (MoSCoW) and conflict resolution.
   • How: Daraz’s SRS prioritized:
     • Must-have: Same-day delivery for Prime members.
     • Conflict: Sellers wanted lower fees; Daraz kept fees high for profit.
     • Resolution: Introduced "Express Delivery" as a premium option.

3. NTC’s Ticketing Portal Redesign

   • Idea Used: Elicitation (observation + surveys).
   • How: NTC observed users struggling with:
     • Pain Point: Manual ticket purchases took 30+ minutes.
     • Solution: New SRS included:
       • FR: "Buy tickets via mobile app in <5 minutes."
       • NFR: "App must support Nepali language and offline mode."

6. Types of Requirements (Comparison Table)

7. Requirements in Agile vs. Traditional (Waterfall) Models

8. Common Pitfalls and How to Avoid Them

1. Golden Hammer Syndrome

   • Problem: Over-engineering (e.g., building a blockchain for a simple eSewa feature).
   • Fix: Prioritize MVP (Minimum Viable Product)—start small.

2. Changing Requirements

   • Problem: Stakeholders add new features mid-project (e.g., Daraz adding "subscription boxes").
   • Fix: Use change control processes (document impacts before approving changes).

3. Ignoring Non-Functional Requirements

   • Problem: Fast development leads to slow apps (e.g., NEPSE’s laggy trading platform).
   • Fix: Allocate 20% of time to performance/security testing.

Exam Tip

1. For short-answer questions:

   • Define requirements as: "Descriptions of system behavior and constraints, derived from stakeholder needs."
   • Differentiate functional vs. non-functional with examples (e.g., "Login system" vs. "99.9% uptime").

2. For case studies (e.g., "Design a system for X"):

   • Follow this structure:
     1. Elicitation: List 2–3 techniques (e.g., interviews + surveys).
     2. Analysis: Show a MoSCoW table.
     3. Specification: Draft 1 functional and 1 non-functional requirement.
     4. Validation: Mention reviews + prototyping.

3. Diagrams:

   • Use case diagrams are worth marks—always include actors (e.g., "Customer," "Admin") and use cases (e.g., "Place Order," "Cancel Order").
   • SRS structure mindmap (as above) is a safe bet for 5+ marks.

4. Real-world tie-ins:

   • Examiners love links to Nepali apps. Example: "Like Khalti’s SRS, which prioritizes security over speed, a banking app’s SRS must define encryption standards (e.g., PCI-DSS compliance) as a non-functional requirement."

5. Avoid:

   • Vague answers like "requirements are important."
   • Forgetting validation—always mention at least one technique (reviews/prototyping).

Worked Example: Designing a Requirements Document for a Nepali Food Delivery App (Like Fyyur)

Scenario: Your team is building a food delivery app for Pokhara. Draft key requirements.

Step 1: Elicitation

• Interview: Talk to restaurant owners (they want bulk orders) and customers (they want discounts).
• Survey: 80% of users want cash-on-delivery; 20% prefer digital payments.

Step 2: Analysis (MoSCoW Table)

Step 3: SRS Excerpt

Functional Requirement (FR2): The system shall allow customers to add items to a cart and proceed to checkout without creating an account.

Non-Functional Requirement (NFR3): The app shall load restaurant menus in <3 seconds on 3G networks.

Validation:

• Prototype: Build a clickable wireframe to test checkout flow.
• Review: Invite 5 restaurant owners to validate order management features.

Visual: Use Case Diagram for a Bank Loan System

Visual: SRS Document Structure (Simplified)

mindmap
  root((SRS for Pokhara Food App))
    Introduction
      Purpose: "Deliver food in <30 mins"
      Scope: "Pokhara city only (Phase 1)"
    Functional Requirements
      FR1: "User can browse menus"
      FR2: "Guest checkout"
    Non-Functional Requirements
      NFR1: "<3s load time on 3G"
      NFR2: "95% order accuracy"
    Validation
      Prototyping
      User Acceptance Testing (UAT)

A textbook-style use case diagram with actors and use cases labeled. (Image: Richard Bruce, Public domain, via Wikimedia Commons)