System Analysis & Design: Basics, Scope, and Process

Core Concepts and Definitions

What is a System?

A system is an interconnected set of components working together to achieve a common goal. In computing, it includes:

• Hardware (servers, routers, devices)
• Software (applications, databases, OS)
• Data (structured/unstructured)
• People (users, admins, developers)
• Processes (workflows, algorithms)

classDiagram
    class System {
        +Components: Hardware, Software, Data, People, Processes
        +Purpose: Achieve a defined goal
        +Types: Manual, Automated, Hybrid
    }
    class Hardware {
        +Examples: Servers, Routers, Mobile Devices
    }
    class Software {
        +Examples: ERP, CRM, Custom Apps
    }
    class Data {
        +Examples: Customer Records, Transaction Logs
    }
    class People {
        +Examples: End Users, IT Staff, Stakeholders
    }
    System --> Hardware
    System --> Software
    System --> Data
    System --> People
    System --> Processes

System Analysis vs. System Design

System Development Life Cycle (SDLC) Overview

SDLC is a structured process to develop, maintain, and replace information systems. The waterfall model (sequential phases) is the foundation, but modern approaches (agile, iterative) adapt it.

flowchart TD
    A["System Planning"] --> B["System Analysis"]
    B --> C["System Design"]
    C --> D["Implementation"]
    D --> E["Testing"]
    E --> F["Deployment"]
    F --> G["Maintenance"]
    G -->|"Feedback"| B

Phases Explained:

1. Planning: Define scope, feasibility, and high-level requirements.
2. Analysis: Gather detailed requirements (e.g., "Ncell’s billing system must support prepaid/postpaid customers").
3. Design: Create blueprints (e.g., database schema for Daraz’s order management).
4. Implementation: Code, configure, and integrate components.
5. Testing: Validate functionality (unit, integration, system tests).
6. Deployment: Roll out to users (e.g., NEPSE’s new trading platform).
7. Maintenance: Fix bugs, update features (e.g., eSewa adding QR payments).

Traditional SDLC phases with feedback loops (Image: Peter Kemp / Paul Smith, CC BY 3.0, via Wikimedia Commons)

Methodologies: Waterfall vs. Agile

Worked Example:

• Nepal Rastra Bank’s Core Banking System:
  • Waterfall: Used for initial design (stable regulatory requirements).
  • Agile: Later phases for adding features like mobile banking (eSewa integration).

Stakeholders and Their Roles

Stakeholders are individuals/groups affected by the system. Key roles in a hospital management system (e.g., for a private clinic in Kathmandu):

Requirements Gathering Techniques

Techniques to collect accurate requirements (critical for exams!):

1. Interviews: One-on-one with stakeholders (e.g., interviewing a Daraz store owner about inventory needs).
2. Surveys/Questionnaires: For large user bases (e.g., Ncell’s customer satisfaction surveys).
3. Observation: Watch users interact with existing systems (e.g., observing traffic at a Kathmandu bank’s ATM).
4. Document Analysis: Review existing manuals, reports (e.g., analyzing NTC’s old billing records).
5. Joint Application Design (JAD): Collaborative workshops (e.g., Khalti’s team brainstorming payment flows).
6. Prototyping: Create mockups for feedback (e.g., eSewa’s QR code payment demo).

Comparison Table:

In the Real World

1. eSewa’s Payment System:

   • Concept: Layered Architecture (presentation, application, data layers).
   • How: Users interact with the app (presentation layer), which communicates with payment gateways (application layer) and databases (data layer).
   • Visual:

2. Daraz’s Order Fulfillment:

   • Concept: Data Flow Diagrams (DFDs).
   • How: A Level-0 DFD shows customers → Daraz system → suppliers → delivery partners.
   • Worked Example:
     • Process: When you order a product, Daraz’s system:
       1. Validates inventory (data store).
       2. Generates an order (process).
       3. Notifies the supplier (data flow).
       4. Tracks delivery via a third party (e.g., Ncell’s logistics).

3. Ncell’s Billing System:

   • Concept: Use Case Diagrams.
   • How: Actors (customers, admins) interact with use cases like "Pay Bill," "Check Usage," "Update Profile."
   • Visual:

Exam Tip

1. Diagrams Are Worth 20% of Marks:

   • Always draw context diagrams, Level-0 DFDs, and use case diagrams for scenario-based questions.
   • Example: For a "hospital management system," show:
     • Context Diagram: "Hospital" as a single process with external entities (patients, doctors, labs).
     • Level-0 DFD: Break "Hospital" into sub-processes (appointment scheduling, billing, records).

2. Define Key Terms Precisely:

   • System Analysis: "The process of understanding and documenting what a system should do."
   • System Design: "The process of defining how the system will achieve its requirements."
   • Feasibility Study: "Assessing technical, economic, and operational viability."

3. Real-World Links:

   • Tie answers to Nepalese examples:
     • "Like eSewa’s layered architecture, the system we design must separate user interface from backend processing."
     • "Ncell’s billing system uses DFDs to model interactions between customers, the network, and payment gateways."

4. Common Pitfalls:

   • Avoid: Vague statements like "the system will be user-friendly." Instead, specify: "The UI will include a mobile-responsive design with Nepali language support."
   • Do: Use bullet points for structured answers (examiners love clarity).

5. Practice Questions:

   • For a retail store system (like a local Kathmandu mall shop):
     • Draw a context diagram with entities: Customers, Cashier, Inventory, Supplier.
     • Draw a Level-0 DFD with processes: Sales, Inventory Update, Payments.
   • For requirements gathering:
     • Compare interviews (deep but slow) vs. surveys (fast but shallow) for a Daraz seller’s needs.