System Requirements Analysis: Techniques, DFDs, JAD, Feasibility

TAKEAWAYS:

• Requirements analysis bridges user needs and system design, using techniques like interviews, JAD, and DFDs to model processes.
• Data Flow Diagrams (DFDs) visually represent system flows (data, processes, stores, external entities) with strict rules for decomposition.
• Feasibility studies evaluate technical, economic, and operational viability using metrics like payback period, NPV, and ROI.
• JAD (Joint Application Development) accelerates requirement gathering by involving stakeholders in collaborative workshops.
• Real-world ties: eSewa’s payment flows (DFD), Daraz’s order queues (process modeling), and Ncell’s billing systems (feasibility analysis).
• Exam focus: Draw DFDs, calculate payback periods/NPV, differentiate JAD techniques, and explain feasibility trade-offs.

1. What is System Requirements Analysis?

System requirements analysis is the core phase of system development where analysts:

• Gather user needs (functional/non-functional).
• Analyze conflicts, gaps, and priorities.
• Document requirements clearly for designers/developers.

Why It Matters

• Avoids costly rework: 70% of software failures stem from unclear requirements (Standish Group).
• Aligns stakeholders: Ensures developers build what users actually need.
• Legal/compliance: Critical for GDPR, banking regulations (e.g., NEPSE’s trading system rules).

2. Key Techniques for Requirement Elicitation

Requirements are elicited (collected) using multiple methods. Below are the most common, with real-world Nepali examples:

A. Interviews

• How it works: One-on-one or group discussions with stakeholders (users, managers, experts).
• Example: Interviewing a Daraz seller to understand inventory management needs (e.g., stock alerts, bulk uploads).

B. Questionnaires/Surveys

• How it works: Structured questions distributed to a large group (e.g., Ncell customers for USSD feedback).
• Pros: Scalable, anonymous responses.
• Cons: Low response rates, lack of depth.

C. Observation

• How it works: Watching users perform tasks (e.g., observing NTC call center agents handling complaints).
• Example: Noticing bottlenecks in eSewa’s payment flow (e.g., slow OTP verification).

D. Document Analysis

• How it works: Reviewing existing manuals, reports, or system logs (e.g., NEPSE’s trading rules for a new stock system).
• Tools: SQL queries on databases, log files.

E. Prototyping

• How it works: Building a mockup (wireframe or interactive model) to validate requirements.
• Example: A Pathao driver app prototype tested for route optimization features.

F. Joint Application Development (JAD)

• Definition: A collaborative workshop where stakeholders, analysts, and developers work together to define requirements.
• Phases:
  1. Planning: Define goals, participants, agenda.
  2. Workshop: Facilitated sessions with brainstorming, prototyping.
  3. Follow-up: Document outcomes and resolve conflicts.

Mermaid Diagram: JAD Process

stateDiagram-v2
    [*] --> Planning: "Define scope, participants"
    Planning --> Workshop: "Facilitated sessions"
    Workshop --> Brainstorming: "Ideas, prototypes"
    Brainstorming --> ConflictResolution: "Resolve disagreements"
    ConflictResolution --> Documentation: "Finalize requirements"
    Documentation --> [*]

Advantages of JAD:

• Faster than sequential methods.
• Improves stakeholder buy-in.
• Reduces miscommunication.

Disadvantages:

• Requires skilled facilitators.
• Expensive for large teams.

3. Data Flow Diagrams (DFDs): Modeling System Processes

DFDs are visual tools to represent how data moves through a system. They answer:

• What data flows where?
• What processes transform data?
• Where is data stored?

Key Symbols

Rules for Drawing DFDs

1. Level 0 (Context Diagram): Single process, all external entities.
2. Level 1: Decompose the main process into sub-processes.
3. Balancing: Inputs/outputs must match parent diagram.
4. No arrows between stores: Data flows via processes.
5. Name processes with strong verbs: "Calculate Tax" (not "Tax Calculation").

Worked Example: eSewa Payment System (Level 0 & 1)

Scenario: Model how a user pays a bill via eSewa.

Level 0 DFD (Context Diagram)

graph LR
    A["User"] -->|"Bill Payment Request"| B["eSewa System"]
    B -->|"Payment Confirmation"| A
    C["Bank"] -->|"Fund Transfer"| B
    D["NTC/Electricity Board"] -->|"Update Bill"| B

Level 1 DFD (Decomposed)

graph TD
    A["User"] -->|"Enter Amount"| B["Authenticate User"]
    B -->|"Valid?"| C{"Yes/No"}
    C -->|"Yes"| D["Deduct Balance"]
    C -->|"No"| E["Show Error"]
    D -->|"Success"| F["Update Bank"]
    F -->|"Confirm"| G["Notify NTC"]
    G -->|"Ack"| A

Trace Example:

1. User requests Rs. 500 payment to NTC.
2. System checks balance (Process B).
3. If valid, deducts amount (Process D) and updates bank (Process F).
4. NTC’s system is notified (Process G).

Common Mistakes in DFDs

• Unbalanced flows: Inputs ≠ Outputs.
• Overlapping processes: Combine similar steps (e.g., "Login" + "Verify" → "Authenticate").
• Ignoring data stores: Always show where data is stored (e.g., user profiles in a database).

4. Feasibility Analysis: Is the System Worth Building?

Feasibility studies assess whether a project is viable in:

1. Technical Feasibility: Can the system be built with existing tech?
2. Economic Feasibility: Is it cost-effective? (Use payback period, NPV, ROI).
3. Operational Feasibility: Will users accept it?
4. Legal Feasibility: Does it comply with laws? (e.g., PCI-DSS for eSewa payments).

A. Economic Feasibility Metrics

Worked Example: Ncell Billing System Upgrade

• Initial Cost: Rs. 5,00,000
• Annual Savings: Rs. 1,50,000 (reduced call center costs)
• Payback Period: 5,00,000 / 1,50,000 = 3.33 years

NPV Calculation (6% discount rate, 5 years):

Year 1: 1,50,000 / 1.06 = 1,41,509
Year 2: 1,50,000 / 1.1236 ≈ 1,33,526
...
Total NPV = Rs. 6,02,000 - Rs. 5,00,000 = **Rs. 1,02,000 (Positive → Viable)**

B. Technical Feasibility Checklist

• Does the organization have the skills (e.g., Python for Daraz’s recommendation engine)?
• Are hardware/software available? (e.g., cloud servers for NEPSE’s trading platform).
• Can the system integrate with existing systems? (e.g., eSewa + bank APIs).

C. Operational Feasibility

• User Training: Will staff adopt the new system? (e.g., NTC employees resisting digital billing).
• Workflow Changes: Does it disrupt daily operations? (e.g., Pathao drivers needing new route algorithms).

5. Types of Requirements

Requirements are classified into functional (what the system does) and non-functional (how it does it).

6. Contemporary Requirement Techniques

In the Real World

1. eSewa’s Payment Flow (DFD)

   • How it uses DFDs: Models data flows from user → bank → merchant (e.g., NTC).
   • Key Processes:
     • Authenticate user (OTP).
     • Deduct balance.
     • Notify merchant.
   • Real Picture:

     graph LR
         A["User"] -->|"Login"| B["eSewa App"]
         B -->|"OTP"| C["Bank API"]
         C -->|"Debit"| D["User Account"]
         D -->|"Credit"| E["Merchant (NTC)"]

2. Daraz’s Order Queue (Process Modeling)

   • How it uses DFDs: Tracks orders from placement → fulfillment → delivery.
   • Bottleneck Example: Slow warehouse processing → Daraz optimized with automated sorting (seen in Level 1 DFDs).

3. Ncell’s Billing System (Feasibility)

   • Payback Period: Upgrading from manual to digital billing saved Rs. 1.2 crore/year.
   • NPV: Rs. 4.5 crore over 5 years (6% discount rate) → Positive ROI.

4. Khalti’s Security Requirements (Non-Functional)

   • PCI-DSS Compliance: Encrypted transactions, tokenization.
   • DFD Example: Separate flows for fraud detection (e.g., duplicate payments).

Exam Tip

1. DFDs:

   • Always draw Level 0 first, then decompose.
   • Label arrows clearly (e.g., "Order Details" not just "Data").
   • Common exam question: "Draw a DFD for a library system up to Level 1."

2. Feasibility Calculations:

   • Payback Period: Direct division (Initial Cost / Annual Cash Flow).
   • NPV: Use the formula $\text{NPV}=\sum \frac{{\text{Cash Flow}}_t}{(1+r{)}^t}-\text{Initial Cost}$.
   • Example: For a system costing Rs. 3,00,000 with Rs. 80,000/year savings at 8%:

     Year 1: 80,000 / 1.08 ≈ 74,074
     Year 2: 80,000 / 1.1664 ≈ 68,589
     ...
     Total NPV ≈ Rs. 2,90,000 (Positive → Viable)
     

3. JAD vs. Traditional Methods:

   • JAD: Faster, collaborative (good for eSewa’s payment system).
   • Interviews/Surveys: Slower but better for NTC’s widespread users.

4. Requirement Types:

   • Functional: "System must generate receipts" (eSewa).
   • Non-Functional: "Receipts must be emailable" (Khalti).

5. Avoid in Exams:

   • Overcomplicating DFDs: Stick to 3–4 processes in Level 1.
   • Ignoring data stores: Always include databases/files.
   • Forgetting to balance flows: Inputs must equal outputs.

Final Visual Summary

mindmap
  root((System Requirements Analysis))
    Techniques
      Interviews
      JAD
      Prototyping
    DFDs
      Level 0
      Level 1
      Symbols
    Feasibility
      Economic (NPV, Payback)
      Technical
      Operational
    Real-World
      eSewa (DFD)
      Daraz (Processes)
      Ncell (Feasibility)