Software Requirements Engineering: Elicitation, Analysis, SRS & Tools

TAKEAWAYS:

• Requirements engineering bridges user needs and technical solutions through structured elicitation, analysis, and documentation.
• A well-written Software Requirements Specification (SRS) document is the contract between developers and stakeholders, defining scope, constraints, and acceptance criteria.
• Techniques like use cases, scenarios, and prototyping reduce ambiguity and improve stakeholder buy-in.
• Traceability ensures requirements are testable, verifiable, and aligned with business goals.
• Challenges like changing requirements, conflicting stakeholder priorities, and incomplete domain knowledge require iterative refinement.
• Tools like CASE tools (e.g., Rational RequisitePro, IBM DOORS) automate requirements management and validation.

Core Concepts: What Are Software Requirements?

Software requirements are formal descriptions of what a software system must do (functional requirements) and how it must perform (non-functional requirements). They serve as the foundation for design, development, and testing.

Types of Requirements

mindmap
  root((Software Requirements))
    Functional
      User Requirements
      System Requirements
    Non-Functional
      Performance
      Security
      Usability
      Reliability
    Domain-Specific
      Legal/Compliance
      Business Rules

Example: For an eSewa payment app, functional requirements might include:

• "User must log in with a mobile number and OTP."
• "System must deduct payment from user’s bank account and credit the merchant."

Non-functional requirements could be:

• "Response time for payment confirmation must be ≤ 2 seconds."
• "Data encryption must comply with PCI-DSS standards."

Requirements Elicitation: Gathering Needs from Stakeholders

Elicitation is the process of collecting raw requirements from users, clients, and domain experts. Common techniques include:

1. Interviews

• Structured vs. Unstructured: Structured interviews use predefined questions; unstructured allow open-ended discussions.
• Example: Interviewing a NTC engineer to define requirements for a new fault detection system in power grids.
  • "What are the most common faults in the current system?"
  • "How quickly must technicians be alerted?"

2. Surveys and Questionnaires

• Used for large-scale feedback (e.g., gathering user pain points for Pathao’s ride-hailing app).
• Pros: Scalable, anonymous responses.
• Cons: Low response rates, lack of depth.

3. Observations

• Watching users interact with existing systems (e.g., observing Khalti users making payments to identify usability issues).
• Example: A bank might observe tellers processing loans to define requirements for a new automated loan approval system.

4. Prototyping

• Low-fidelity (paper sketches) vs. High-fidelity (interactive mockups).
• Example: Before building Daraz’s new checkout flow, a team might create a clickable prototype to test user frustration points.

5. Use Cases and Scenarios

• Use Case: A structured description of how a user interacts with the system (e.g., "Place Order" in an e-commerce system).
• Scenario: A specific instance of a use case (e.g., "User adds 5 items to cart, applies coupon, and checks out").
• Visual Example:

  sequenceDiagram
    participant User
    participant DarazSystem
    participant PaymentGateway
    User->>DarazSystem: Selects items, adds to cart
    User->>DarazSystem: Applies coupon code
    DarazSystem->>PaymentGateway: Requests payment
    PaymentGateway-->>DarazSystem: Returns success/failure
    DarazSystem-->>User: Confirms order

Requirements Analysis: Refining Raw Inputs

Analysis involves organizing, prioritizing, and validating elicited requirements. Key activities:

1. Categorization: Classify requirements as functional/non-functional.
2. Prioritization: Use MoSCoW method (Must-have, Should-have, Could-have, Won’t-have).
3. Conflict Resolution: Resolve contradictions (e.g., "Users want fast checkout but also detailed product reviews").
4. Feasibility Study: Assess technical, economic, and operational viability.

Example: Kathmandu Traffic Management System

• Raw Requirement: "Reduce traffic congestion in Thapathali."
• Analyzed Requirements:
  • Must-have: Real-time traffic light synchronization.
  • Should-have: Mobile app for route optimization.
  • Conflict: "Pedestrians want longer crossing times, but drivers want faster green lights."

Software Requirements Specification (SRS) Document

The SRS is a formal contract between developers and stakeholders. It must include:

Example SRS Excerpt for a Bank Loan System:

Functional Requirement FR-001: The system shall allow customers to apply for a loan online using their net banking credentials. Non-Functional Requirement NFR-001: The loan approval process must complete within 48 hours for 80% of standard loan applications.

Challenges in Requirements Engineering

Real-World Example:

• Nepal Stock Exchange (NEPSE) Trading System:
  • Challenge: Traders demanded real-time stock updates, but IT teams argued it required expensive infrastructure.
  • Solution: A prioritization workshop led to a phased rollout, starting with delayed (5-minute) updates before moving to real-time.

Requirements Validation and Verification

• Validation: "Are we building the right product?" (Check if requirements meet user needs.)
  • Techniques: Reviews, prototyping, walkthroughs.
• Verification: "Are we building the product right?" (Check if requirements are correctly implemented.)
  • Techniques: Inspections, testing, traceability matrices.

Example: WhatsApp End-to-End Encryption

• Validation: Did WhatsApp correctly interpret users’ need for privacy?
• Verification: Does the implemented encryption (Signal Protocol) meet the specified security standards?

Tools for Requirements Engineering

In the Real World

1. eSewa Payment System:

   • Use Case: "User transfers money to a merchant."
   • Requirements Engineering Role:
     • Elicited from Nepal Rastra Bank (NRB) for compliance.
     • Validated via prototypes with low-income users to ensure usability.
     • SRS included NFR-003: "Transaction logs must be retained for 7 years for audits."

2. Pathao Ride-Hailing App:

   • Challenge: Drivers complained about low earnings during peak hours.
   • Solution: Requirements analysis revealed the need for dynamic surge pricing, which was prototyped and tested with a small group before full rollout.

3. NTC Smart Grid Project:

   • Use Case: "Automatically reroute power during outages."
   • Tools Used:
     • IBM DOORS to manage 500+ requirements.
     • Simulink to model power flow scenarios.
   • Real Picture:

Worked Example: Daraz Order Fulfillment System

Scenario: Daraz wants to reduce order delivery time from 7 to 3 days. Requirements Elicitation:

• Interviewed warehouse managers → "Current sorting is manual; errors cause delays."
• Surveyed customers → "70% want same-day delivery for orders under Rs. 2000."

Analyzed Requirements:

SRS Excerpt:

Use Case: "Process Order" Actor: Warehouse System Precondition: Order received in system. Main Flow:

1. System scans barcode.
2. AI sorts items into bins by delivery route.
3. System generates shipping label. Exception: If item is out of stock, notify customer within 1 hour.

Validation:

• Prototype: Built a low-fidelity mockup of the sorting system and tested it with 10 warehouse staff.
• Feedback: Staff suggested adding a "quality check" step before binning.

Exam Tip

1. For SRS Questions:

   • Always structure your answer using the SRS template (Introduction → Functional/Non-Functional → Models → Appendices).
   • Example Answer Starter:

     "The SRS for a bank loan system must include an Introduction defining scope (e.g., ‘Online loan applications for salaried employees’), Functional Requirements like ‘FR-001: System shall verify credit score via CIBIL,’ and Non-Functional Requirements such as ‘NFR-002: Response time ≤ 5 seconds for 90% of queries.’"

2. For Elicitation Techniques:

   • Compare interviews vs. surveys in a table (as above) and link to real-world examples (e.g., "Khalti used surveys to gather feedback on failed transactions").

3. For Challenges:

   • Use the challenge-mitigation table and tie to past exam questions.
   • Example:

     "Ambiguity in requirements (e.g., ‘users want a fast app’) can be mitigated via prototyping, as seen in Pathao’s dynamic pricing feature, which was tested with a small user group before full launch."

4. Diagrams Are Your Friends:

   • Always draw a sequence diagram for use cases (e.g., "Show the interaction between a user, eSewa, and the bank for a payment").
   • Use a mindmap for types of requirements (functional/non-functional).

5. Traceability Matters:

   • If asked about validation vs. verification, explain:
     • Validation = "Does the loan system meet the stakeholder’s need for ‘fast approvals’?" (Check with users.)
     • Verification = "Does the implemented algorithm for credit scoring match the SRS specification?" (Check code against requirements.)

Final Visual Summary:

flowchart TD
    A["Stakeholder Needs"] --> B["Elicitation: Interviews/Surveys"]
    B --> C["Analysis: Prioritize/Resolve Conflicts"]
    C --> D["Document: SRS"]
    D --> E["Validation: Prototypes/Reviews"]
    E --> F["Verification: Testing/Inspections"]
    F --> G["Implementation"]
    G -->|"Feedback Loop"| A