Requirements Gathering & Analysis: Methods, Prototyping, JAD, and Data Modeling

Key Concepts and Methods for Requirements Gathering

1. Definitions and Importance

Requirements Gathering is the process of identifying, documenting, and validating the needs of stakeholders for a new or modified system. It ensures that the final product aligns with user expectations and business goals.

Requirements Analysis involves examining gathered requirements to identify inconsistencies, conflicts, or missing details, then refining them into a clear specification.

Why it matters:

• Prevents costly rework by catching errors early.
• Ensures the system meets user needs (e.g., eSewa’s payment system must handle transactions securely and quickly).
• Forms the foundation for design and development.

2. Traditional Methods for Gathering Requirements

Three primary methods are used, each with strengths and weaknesses:

3. Radical and Modern Methods

A. Prototyping

Prototyping creates a working model of the system to gather feedback early. Two types:

1. Throwaway Prototyping:

   • Built quickly to explore ideas, then discarded.
   • Used when requirements are unclear (e.g., designing a new UI for Khalti).
   • Example: A mockup of a bank’s loan application form to test user confusion.

2. Evolutionary Prototyping:

   • Refined iteratively into the final product.
   • Used for complex systems (e.g., eSewa’s multi-service platform).
   • Example: Starting with a basic version of Daraz’s "Buy Now, Pay Later" feature and adding layers based on user feedback.

stateDiagram-v2
    [*] --> Throwaway: Built for feedback
    Throwaway --> Discard: Not used in final system
    [*] --> Evolutionary: Built incrementally
    Evolutionary --> Refine: Add features based on feedback
    Refine --> FinalSystem: Complete product

B. Joint Application Design (JAD)

• What it is: A structured workshop where stakeholders (users, developers, managers) collaborate intensively to define requirements.
• How it works:
  1. Pre-session: Define goals, invite participants, prepare materials.
  2. Session: Facilitated discussion (3–5 days) with tools like whiteboards or digital boards.
  3. Post-session: Document outcomes and validate with stakeholders.
• Why it’s better than traditional methods:
  • Faster than sequential interviews/observations.
  • Reduces miscommunication (e.g., all Ncell executives agree on a new billing feature in one session).
  • Encourages buy-in from all parties.

Example: A JAD session for designing a Khalti merchant dashboard would include:

• Bank representatives (for payment rules),
• Developers (for technical feasibility),
• Small shop owners (for usability).

4. Conceptual Data Modeling

A conceptual data model represents the "what" (data entities and their relationships) without worrying about "how" (database schema or technology). The most common tool is the Entity-Relationship (ER) Diagram.

Key Components:

1. Entities: Things of interest (e.g., Customer, Product, Order).
2. Attributes: Properties of entities (e.g., Customer has customerID, name, email).
3. Relationships: How entities interact (e.g., Customer places Order).
4. Cardinality: How many instances relate (1:1, 1:many, many:many).

Example: Retail Store in a Mall (ER Diagram)

erDiagram
    Customer ||--o{ Order : places
    Order ||--|{ Product : contains
    Product }|--|| Category : belongs_to
    Customer {
        int customerID PK
        string name
        string contact
    }
    Order {
        int orderID PK
        date orderDate
        decimal totalAmount
    }
    Product {
        int productID PK
        string name
        decimal price
    }
    Category {
        int categoryID PK
        string categoryName
    }

How to Gather Information for ER Diagrams:

1. Interview stakeholders: Ask, "What data do you need to track?" (e.g., a Daraz seller might say, "I need to track order status and delivery dates").
2. Analyze documents: Review invoices, receipts, or past system reports.
3. Observe processes: Watch how data flows (e.g., how a bank teller records loan applications).

5. Handling Disruptive Technologies

Disruptive technologies (e.g., AI, blockchain, IoT) can reshape requirements. For example:

• AI in eSewa: Requires new data points (e.g., user behavior patterns) for fraud detection.
• Blockchain in NEPSE: Needs immutable ledgers for transparent stock trades.
• IoT in NTC: Smart meters require real-time data collection and analysis.

How to incorporate them:

1. Identify where the technology adds value (e.g., "Can AI reduce call wait times at Ncell?").
2. Define new requirements (e.g., "The system must log customer call durations for AI training").
3. Assess feasibility (e.g., "Does NTC’s infrastructure support IoT sensors?").

6. Pitfalls and Best Practices

Common Pitfalls:

• Bias in Observation: Observing only "good" workers may miss pain points.
  • Fix: Observe diverse users (e.g., both experienced and new Daraz sellers).
• Scope Creep: Adding too many features based on feedback.
  • Fix: Prioritize requirements using MoSCoW (Must-have, Should-have, Could-have, Won’t-have).
• Ignoring Non-Functional Requirements: Performance, security, and scalability are often overlooked.
  • Fix: Explicitly ask, "How fast must the system respond?" (e.g., Pathao’s ride-matching must complete in <2 seconds).

Best Practices:

• Validate requirements: Use prototypes or JAD sessions to confirm understanding.
• Document everything: Keep a traceable record of decisions (e.g., "Why we chose SQL over NoSQL for Khalti’s database").
• Involve end-users early: Even if they’re not technical (e.g., a Kathmandu traffic police officer testing a new fine-collection app).

In the Real World

1. eSewa’s Payment Flow:

   • Method Used: Prototyping (evolutionary) and JAD.
   • How: eSewa started with a basic mobile payment prototype, then iterated based on user feedback (e.g., adding QR code payments after testing). A JAD session with banks and telecoms defined security requirements like OTP validation.

2. Daraz’s Inventory System:

   • Method Used: Observation and document analysis.
   • How: Daraz observed how sellers manually tracked stock (using Excel) and analyzed their order documents to design an automated inventory system with real-time updates. The ER diagram for this system includes entities like Warehouse, Supplier, and StockMovement.

3. Ncell’s Customer Support Chatbot:

   • Method Used: Disruptive technology (AI) + interviews.
   • How: Ncell interviewed customers to identify common complaints (e.g., "I can’t check my bill online"). They then designed an AI chatbot requirement: "The system must handle 10,000 concurrent queries with <3-second response time."

Worked Example: Feasibility Study for a Bank Loan System

Scenario: A bank wants to automate its loan approval process. Gather requirements using:

1. Interviews: Talk to loan officers, borrowers, and IT staff.
   • Loan Officer: "We need to check credit scores from multiple agencies."
   • Borrower: "I want to upload documents online, not visit the bank."
2. Observation: Watch how officers manually process applications (e.g., they spend 20 minutes per loan verifying documents).
3. Document Analysis: Review past loan approval/rejection reports to identify patterns (e.g., 60% of rejections are due to incomplete documents).
4. Prototyping: Build a mock loan application form and test it with 10 users to see where they struggle (e.g., confusing fields for "income proof").

ER Diagram for Loan System:

erDiagram
    Customer ||--o{ LoanApplication : submits
    LoanApplication ||--|{ LoanOfficer : reviewed_by
    LoanApplication ||--|{ Document : contains
    LoanApplication }|--|| LoanType : applies_for
    Customer {
        int customerID PK
        string name
        decimal creditScore
    }
    LoanApplication {
        int applicationID PK
        date submissionDate
        string status "Pending/Approved/Rejected"
    }
    Document {
        int documentID PK
        string type "Income Proof/Pan Card/etc."
        string status "Uploaded/Verified"
    }

Key Requirements Identified:

• The system must integrate with 3 credit agencies (e.g., TransUnion, Experian).
• Users must upload documents via a drag-and-drop interface.
• Loan officers need a dashboard to track application statuses.

Exam Tip

1. For short-answer questions (e.g., "Compare observation and document analysis"):

   • Use a 2-column table with "Observation" vs. "Document Analysis," listing 3–4 points each (e.g., "Observation captures real behavior; Document Analysis is faster").
   • Mention one pitfall for each (e.g., "Observation may miss 'why' users act a certain way").

2. For ER diagrams:

   • Always include 3 entities, 1 relationship, and cardinality (e.g., Customer 1:many Order).
   • Label attributes clearly (e.g., Order has orderID, date, totalAmount).
   • Real-world tie: If asked about a retail store, use Customer, Product, and Order as in the example above.

3. For prototyping/JAD:

   • Define throwaway vs. evolutionary in one sentence each.
   • For JAD, explain the 3-phase process (pre-session, session, post-session) and why it’s faster than interviews.

4. For disruptive technologies:

   • Name one technology (e.g., blockchain) and one Nepalese example (e.g., NEPSE’s transparent trading).
   • Describe one new requirement it introduces (e.g., "immutable audit logs").

5. For conceptual data modeling:

   • Start with: "A conceptual data model represents entities, attributes, and relationships without technical details."
   • Link to ER diagrams: "It is visualized using ER diagrams, which show how data interacts (e.g., a Customer places an Order)."