Requirements Engineering: Elicitation, Analysis, SRS & Real-World Needs

TAKEAWAYS:

• Requirements engineering is the foundation of software development, ensuring the final product meets stakeholder needs and business goals.
• Functional requirements define what the system should do (e.g., "process loan applications"), while non-functional requirements specify how well it should perform (e.g., "99.9% uptime").
• Elicitation techniques (interviews, surveys, observation) uncover hidden needs, but biases and ambiguity must be mitigated through validation.
• A good SRS document is unambiguous, verifiable, modifiable, and traceable—critical for avoiding costly rework in later phases.
• Domain requirements (industry-specific rules) often dictate compliance (e.g., banking regulations for eSewa transactions).
• Real-world examples show how requirements drive design: Pathao’s ride-hailing app requires both functional (matching drivers) and non-functional (low latency) requirements.

1. What Are Requirements?

Requirements are formal statements of needs that a software system must satisfy. They act as a contract between stakeholders (clients, users, developers) and the development team. Without clear requirements, projects risk:

• Scope creep (uncontrolled changes),
• Misaligned deliverables (wrong features built),
• Wasted resources (rework due to misunderstandings).

Types of Requirements

Requirements are classified into three broad categories, each serving a distinct purpose:

2. Functional Requirements: "What the System Should Do"

Functional requirements define specific behaviors or functions the system must perform. They are verifiable (can be tested) and often expressed as:

• Use cases (e.g., "A user can reset their password"),
• User stories (e.g., "As a customer, I want to track my Daraz order so I can plan delivery"),
• Process specifications (e.g., "The system shall validate loan eligibility within 5 minutes").

Worked Example: Library Management System

Why it matters in real life:

• eSewa’s functional requirements include:
  • "A user can pay utility bills online" (process specification).
  • "The system must support mobile payments via Khalti" (integration requirement).
• Nepal Rastra Bank’s rules for digital transactions are domain requirements that override functional design choices.

3. Non-Functional Requirements: "How Well the System Should Do It"

Non-functional requirements (NFRs) define quality attributes like performance, security, and usability. They are often constraints or goals rather than specific features.

Common NFR Categories

Worked Example: Kathmandu Traffic Management System

Assume a smart traffic system for Kathmandu:

• Functional: "Detect congestion at 10 key intersections."
• Non-Functional:
  • Performance: "Process sensor data in <100ms."
  • Reliability: "99.9% accuracy in detecting jams."
  • Security: "Prevent hacking of traffic light signals."
  • Usability: "Traffic police can override signals via mobile app."

Real-world tie-in:

• Google Maps’ NFRs:
  • Performance: Real-time route updates using satellite + crowd-sourced data.
  • Usability: Voice navigation works in Nepali (for Nepali users).
  • Scalability: Handles 1B+ monthly users globally.

4. Domain Requirements: Industry-Specific Rules

Domain requirements are regulatory or business rules unique to an industry. Ignoring them can lead to legal penalties or system failure.

Examples by Domain

5. The Requirements Engineering Process

Requirements engineering is iterative and involves four key activities:

Step 1: Elicitation (Discovering Requirements)

Goal: Gather raw requirements from stakeholders. Techniques:

Challenges:

• Stakeholder conflicts (e.g., bank wants security; users want speed).
• Ambiguity (e.g., "fast response time" → define: 1s or 5s?).
• Politics (senior managers may override user needs).

Step 2: Analysis (Refining Requirements)

• Prioritize requirements (e.g., using MoSCoW: Must-have, Should-have, Could-have, Won’t-have).
• Resolve conflicts (e.g., "Security vs. Usability" trade-offs).
• Identify gaps (e.g., missing compliance rules).

Example: For a hospital management system:

• Must-have: Patient records must be HIPAA-compliant.
• Should-have: Doctors can access records via mobile.
• Could-have: AI suggests treatments based on past cases.

Step 3: Specification (Documenting Requirements)

The Software Requirements Specification (SRS) document is the single source of truth. It must be:

• Complete: No missing requirements.
• Unambiguous: No vague language (e.g., "user-friendly" → define metrics).
• Consistent: No contradictions.
• Verifiable: Requirements must be testable.
• Modifiable: Easy to update.
• Traceable: Link requirements to design/test cases.

SRS Structure (Simplified):

mindmap
  root((SRS Document))
    Introduction
    Overall Description
      Product Perspective
      User Characteristics
      Assumptions & Dependencies
    Functional Requirements
    Non-Functional Requirements
    Domain Requirements
    Use Cases
    Glossary
    Appendices

Worked Example: SRS for a Bank Loan System

**Requirement ID**: FR-001
**Title**: Loan Eligibility Check
**Description**: The system shall validate a user’s loan eligibility based on credit score, income, and existing loans.
**Priority**: Must-have
**Acceptance Criteria**:
- Credit score ≥ 650.
- Income ≥ Rs. 50,000/month.
- No outstanding loans > Rs. 200,000.
**Test Case**:
- Input: Credit score=700, Income=Rs. 60,000, Loans=Rs. 150,000.
- Output: Approve loan of Rs. 500,000.

Step 4: Validation (Ensuring Correctness)

• Reviews: Experts check the SRS for completeness.
• Prototyping: Build a demo to validate critical requirements.
• Walkthroughs: Stakeholders test scenarios.
• Inspections: Formal meetings to find defects.

Example: For Pathao’s ride-hailing app, validation might include:

• Testing the driver-matching algorithm with 1000 simulated users.
• Ensuring the app works on low-end phones (e.g., Samsung J2).

6. Common Pitfalls and How to Avoid Them

In the Real World

Requirements engineering is everywhere in software—especially in Nepal’s digital economy. Here’s how companies apply it:

1. eSewa/Khalti (Digital Payments)

   • Functional Requirement: "Users can pay utility bills via QR code."
   • Non-Functional Requirement: "Transaction processing time <3s (95% of cases)."
   • Domain Requirement: "Must comply with Nepal Rastra Bank’s digital payment guidelines."
   • Real Example: During the 2023 fuel shortage, eSewa’s system had to handle 10x normal traffic—requiring scalability testing upfront.

2. Pathao (Ride-Hailing)

   • Functional Requirement: "Match drivers to riders within 10 seconds."
   • Non-Functional Requirement: "System must work offline for 30 minutes (for remote areas)."
   • Domain Requirement: "Integrate with Nepal Police’s vehicle verification API."
   • Real Example: During COVID-19, Pathao added a contactless payment feature—driven by a new NFR: "Reduce physical cash handling by 90%."

3. NTC (Electricity Bill Payments)

   • Functional Requirement: "Customers can pay bills via mobile, internet banking, or counter."
   • Non-Functional Requirement: "99.99% uptime during peak hours (6–9 PM)."
   • Domain Requirement: "Must sync with government’s Citizens Service Portal for authentication."
   • Real Example: During load-shedding, NTC’s app saw 300% traffic spikes—requiring stress-testing for reliability.

4. Daraz (E-Commerce)

   • Functional Requirement: "Order tracking with real-time updates."
   • Non-Functional Requirement: "Inventory system must update in <500ms."
   • Domain Requirement: "Return policies must follow Nepal’s Consumer Rights Act."
   • Real Example: During the 2022 Dashain sales, Daraz’s system processed 50,000 orders/hour—achieved by prioritizing scalability in requirements.

5. Nepal Stock Exchange (NEPSE)

   • Functional Requirement: "Traders can place buy/sell orders in real-time."
   • Non-Functional Requirement: "Order execution latency <50ms."
   • Domain Requirement: "Must comply with SEBON (Securities Board of Nepal) regulations."
   • Real Example: During IPOs (e.g., NMB Bank’s 2023 listing), NEPSE’s system handled 1M+ orders/day—validated through load testing.

Exam Tip

Based on past TU/PU/NEB questions, here’s how to maximize marks:

Do This:

✅ Define terms precisely:

• "Functional requirements specify behaviors the system must exhibit, while non-functional requirements define quality attributes."
• Example: For a library system, "borrow a book" is functional; "response time <2s" is non-functional.

✅ Use real-world examples:

• "In eSewa, the requirement ‘process payments securely’ is non-functional (security), while ‘allow Khalti wallet payments’ is functional (feature)."

✅ Structure answers for SRS questions:

1. Introduction: Purpose of the SRS.
2. Requirements Breakdown: Functional/non-functional/domain.
3. Desirable Characteristics: Complete, unambiguous, verifiable, etc.
4. Example: Show 1–2 sample requirements with IDs, descriptions, and test cases.

✅ Compare techniques:

• "Interviews are best for exploring unknown needs, while surveys work for quantitative data from many users."

Avoid This:

❌ Vague answers:

• ❌ "Requirements are important." → ✅ "Requirements engineering prevents scope creep by documenting stakeholder needs upfront, as seen in Pathao’s driver-matching algorithm which required precise latency NFRs."

❌ Ignoring Nepal context:

• Always tie examples to local companies (eSewa, Daraz, NTC) or regulations (Nepal Rastra Bank, SEBON).

❌ Overlooking NFRs:

• Many students focus only on functional requirements. NFRs often carry more marks—prioritize them in answers.

Sample High-Mark Answer (NEB-style)

Question: "Differentiate between functional and non-functional requirements. Describe any three functional and non-functional requirements for a library management system."

Answer: Functional requirements define specific actions the system must perform, while non-functional requirements specify quality attributes like performance, security, or usability.

Real-world tie-in: In eSewa’s library of digital services, the requirement "process utility bill payments in <5s" is non-functional (performance), while "support Khalti wallet payments" is functional (feature). Neglecting NFRs led to outages during peak hours in early versions of the app, highlighting their criticality.