Analysis Techniques, Models & Tools in Systems Development

Core Concepts of Systems Analysis

1. What is Systems Analysis?

Systems analysis is the problem-solving process that bridges the gap between user needs and technical solutions. It involves:

• Understanding the current system (as-is) and its problems.
• Defining what the new system (to-be) should achieve.
• Documenting requirements clearly for designers and developers.

Why is it crucial? Without proper analysis, systems fail because they either:

• Do not meet user needs (e.g., a banking app that crashes during peak hours).
• Are too complex or costly to implement (e.g., a government portal with redundant features).

2. Key Activities in Analysis

The analysis phase includes:

1. Requirement Elicitation: Gathering needs from stakeholders (users, managers, experts).
2. Requirement Analysis: Organizing and prioritizing requirements.
3. Requirement Specification: Documenting requirements in a structured format.
4. Feasibility Study: Assessing technical, economic, and operational viability.

Techniques for Gathering Requirements

1. Interviews

How it works:

• One-on-one or group discussions with stakeholders to understand their needs.
• Uses open-ended and closed-ended questions.

Example Questions:

• Open-ended: "What challenges do you face with the current order system?"
• Closed-ended: "Do you want the new system to support mobile access? (Yes/No)"

Advantages:

• Flexible, allows follow-up questions.
• Builds rapport with stakeholders.

Disadvantages:

• Time-consuming.
• Biased if interviewer influences responses.

2. Surveys/Questionnaires

How it works:

• Distributed to a large group (e.g., customers, employees).
• Uses Likert scales, multiple-choice, or open-ended questions.

Example for a Daraz Seller App:

Advantages:

• Collects data from many people quickly.
• Anonymous responses reduce bias.

Disadvantages:

• Low response rate.
• Limited depth in answers.

3. Observation

How it works:

• Analyst observes users performing tasks (e.g., a bank teller processing loans).
• Can be structured (following a checklist) or unstructured.

Example:

• Observing Nepal Rastra Bank employees manually calculating interest to identify inefficiencies.

Advantages:

• Reveals real-world workflows (not just what users say).
• Useful for identifying hidden problems.

Disadvantages:

• Users may alter behavior if aware of being watched (Hawthorne Effect).
• Time-consuming.

4. Document Analysis

How it works:

• Reviewing existing documents (reports, manuals, emails) to extract requirements.
• Example: Analyzing NTC’s billing system reports to find discrepancies.

Advantages:

• Provides historical data on past issues.
• Low-cost and non-intrusive.

Disadvantages:

• Documents may be outdated or incomplete.
• Requires interpretation skills.

5. Prototyping

How it works:

• Creating a mock-up (low-fidelity or high-fidelity) of the system for user feedback.
• Example: A Khalti payment app prototype showing how users would transfer money.

Types of Prototypes:

Advantages:

• Early feedback reduces redesign costs.
• Users can visualize the system.

Disadvantages:

• May give false confidence in incomplete features.
• Requires iterative refinement.

Modeling Techniques for Analysis

1. Data Flow Diagrams (DFDs)

What it is: A graphical representation of how data moves through a system (processes, data stores, data flows, external entities).

Example: Ncell Billing System DFD

graph TD
    A["Customer"] -->|"Submits Usage Data"| B["Billing Process"]
    B -->|"Generates Bill"| C["Bill Database"]
    C -->|"Sends Bill"| A
    D["Ncell Admin"] -->|"Updates Tariffs"| B

Levels of DFDs:

Advantages:

• Shows data flow clearly.
• Helps identify bottlenecks (e.g., slow bill generation in NTC).

Disadvantages:

• Does not show control logic.
• Can become complex at lower levels.

2. Use Case Diagrams (UML)

What it is: A UML diagram showing actors (users) and their interactions with the system.

Example: eSewa Payment System

classDiagram
    class User {
        +Make Payment
        +Check Balance
    }
    class eSewa {
        +Process Payment
        +Update Transaction Log
    }
    class Bank {
        +Verify Funds
    }
    User --> eSewa : "Uses"
    eSewa --> Bank : "Requests Funds"

Key Elements:

• Actors: External entities (e.g., Customer, Admin).
• Use Cases: Actions (e.g., "Transfer Money").
• Relationships: <uses>, <includes>, <extends>.

Advantages:

• Focuses on user goals.
• Easy to understand for non-technical stakeholders.

Disadvantages:

• Does not show data flow.
• May miss non-functional requirements.

3. Entity-Relationship (ER) Diagrams

What it is: Models data structures (entities, attributes, relationships) for databases.

Example: Daraz Order Management System

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ PRODUCT : contains
    ORDER ||--|| PAYMENT : has
    CUSTOMER {
        int customer_id PK
        string name
        string email
    }
    ORDER {
        int order_id PK
        date order_date
        string status
    }

Key Symbols:

Advantages:

• Foundation for database design.
• Clearly shows relationships (e.g., one customer can place many orders).

Disadvantages:

• Does not show process flow.
• Requires normalization knowledge.

In the Real World

1. Khalti & eSewa (Digital Payments)

   • Use Case Diagrams model how users transfer money between banks.
   • DFDs show how transaction data flows from the user’s phone to the bank’s server.
   • Example: When you pay a bill via Khalti, the system validates your PIN (use case), checks your balance (DFD data flow), and updates the merchant’s account (ER relationship).

2. Daraz & Amazon (Order Processing)

   • DFDs map how an order moves from customer → warehouse → delivery agent.
   • ER Diagrams define tables like Orders, Customers, and Payments to store data.
   • Example: If Daraz’s system crashes during peak sales (like Dashain), a poorly designed DFD (missing backup processes) could cause losses.

3. NTC & Ncell (Billing Systems)

   • Prototyping is used to test new billing features before full implementation.
   • Observation helps identify why some customers face billing errors (e.g., manual data entry mistakes).
   • Example: NTC’s "Smart Meter" project used DFDs to show how real-time data would flow from meters to the billing system.

4. Nepal Rastra Bank (Loan Processing)

   • Interviews with loan officers reveal inefficiencies (e.g., paper-based approvals).
   • Use Case Diagrams model how a customer applies for a loan online.
   • Example: The bank’s new digital loan system reduced processing time from weeks to hours by automating checks (modeled in DFDs).

Worked Example: Analyzing a Traffic Management System for Kathmandu

Problem Statement

Kathmandu’s traffic congestion causes delays of 2+ hours daily. The municipality wants a smart traffic light system to optimize flow.

Step 1: Gather Requirements

Step 2: Model the System

DFD Level 0: Smart Traffic System

graph TD
    A["Traffic Sensors"] -->|"Detects Vehicles"| B["Traffic Controller"]
    B -->|"Adjusts Timings"| C["Traffic Lights"]
    D["Emergency Vehicles"] -->|"Priority Signal"| B
    B -->|"Logs Data"| E["Central Database"]

Use Case Diagram

classDiagram
    class Driver {
        +Follow Traffic Lights
        +Report Congestion
    }
    class TrafficSystem {
        +Adjust Light Timings
        +Detect Emergencies
    }
    class Municipality {
        +Monitor System
        +Update Rules
    }
    Driver --> TrafficSystem : "Interacts With"
    Municipality --> TrafficSystem : "Manages"

ER Diagram (Partial)

erDiagram
    TRAFFIC_LIGHT ||--o{ VEHICLE : controls
    VEHICLE ||--|| EMERGENCY : is
    TRAFFIC_LIGHT {
        int light_id PK
        string location
        int current_timer
    }

Step 3: Identify Feasibility Issues

Common Pitfalls in Analysis

Exam Tip

How This Unit is Tested

1. Short Questions (2–5 marks):

   • Define DFD, use case, or ER diagram.
   • Example: "What is the difference between a Level 0 and Level 1 DFD?" Answer: Level 0 shows the entire system in one diagram, while Level 1 breaks down a single process from Level 0 into sub-processes.

2. Diagram-Based Questions (5–10 marks):

   • Draw a DFD for a bank ATM system or a use case diagram for WhatsApp.
   • Tip: Always label external entities, processes, and data flows.

3. Scenario-Based Questions (10–15 marks):

   • "Analyze the requirements for a hospital management system using interviews and DFDs."
   • Structure your answer:
     1. List 3 interview questions.
     2. Draw a Level 0 DFD for patient registration.
     3. Identify one feasibility issue (e.g., doctor resistance to digital records).

4. Case Studies (15–20 marks):

   • "A company wants to automate its inventory. Use ER diagrams and use cases to model the system."
   • Key points to cover:
     • Entities: Products, Suppliers, Orders.
     • Relationships: "Supplier supplies Product."
     • Use Cases: "Place Order," "Update Stock."

Marks Distribution Trick

• Diagrams (30–40%): Always draw neatly. Use Mermaid syntax in exams if allowed.
• Explanations (30–40%): Link your answer to real-world examples (e.g., "Like Daraz’s order system...").
• Feasibility/Analysis (20–30%): Discuss technical, economic, and operational factors.

Final Checklist Before Exam

✅ Can you draw a DFD, use case diagram, and ER diagram from memory? ✅ Do you know 3 techniques to gather requirements (interviews, surveys, observation)? ✅ Can you analyze a real-world system (e.g., Khalti, NTC billing) using these tools? ✅ Have you practiced scenario-based questions with time constraints?