System Documentation & Implementation: Types, Methods, Costs & DFDs

TAKEAWAYS:

• System documentation includes user documentation (manuals, tutorials) and system documentation (technical specs, DFDs, code comments), each serving distinct roles.
• Implementation methods (direct, parallel, phased) differ in risk, cost, and user impact—choose based on project size and budget.
• Economic feasibility uses payback period and NPV to justify system costs; worked examples show calculations for real scenarios (e.g., NTC’s fiber-optic upgrade).
• DFDs (Data Flow Diagrams) model processes visually; Level 0/1 diagrams for systems like eSewa’s payment flow clarify data movement.
• Forms and reports must follow design guidelines (consistency, minimal clutter) to ensure usability—compare Daraz’s order confirmation vs. a poorly designed bank statement.
• System testing includes unit, integration, system, and acceptance tests; trace a Pathao ride request through these stages.

1. System Documentation: Types, Purpose, and Guidelines

Documentation is the "blueprint" of a system—it ensures smooth operation, maintenance, and user adoption. Poor documentation leads to system failures (e.g., Ncell’s billing system outages due to undocumented code changes).

Types of Documentation

mindmap
  root((System Documentation))
    User Documentation
      "Manuals (eSewa app guide)"
      "Tutorials (WhatsApp video guides)"
      "FAQs (Daraz return policy)"
    System Documentation
      "Technical specs (NTC network protocols)"
      "DFDs (Khalti transaction flow)"
      "Code comments (bank loan system)"
      "Test cases (Pathao driver app)"

Key Differences:

Why Documentation Matters

• Reduces errors: A bank’s loan system with unclear documentation may miscalculate interest (costing thousands in penalties).
• Lowers maintenance costs: NEPSE’s trading system relies on documented APIs to avoid crashes during high-volume days.
• Ensures compliance: Hospitals use documented patient record systems to meet health regulations.

2. Designing Forms and Reports: Guidelines and Real-World Examples

Forms and reports are the "face" of a system—poor design frustrates users (e.g., Daraz’s checkout page with hidden fees).

Guidelines for Effective Forms

flowchart TD
  A["Start: Define Purpose"] --> B["Minimize Fields"]
  B --> C["Group Related Fields"]
  C --> D["Use Labels Clearly"]
  D --> E["Consistent Layout"]
  E --> F["Test with Users"]

Example: Daraz Order Confirmation vs. Poorly Designed Bank Statement

Worked Example: Designing a Khalti Payment Receipt

1. Purpose: Confirm transaction details (amount, recipient, time).
2. Fields:
   • Header: "Khalti Payment Receipt" (bold, large font).
   • Body:
     • Sender name/phone (auto-filled).
     • Recipient name/phone.
     • Amount (₹X.XX) with currency symbol.
     • Transaction ID (unique, copyable).
     • Status: "Completed" or "Pending".
   • Footer: "Powered by Khalti" + QR code for disputes.
3. Validation: Ensure the QR code links to the transaction page.

3. System Implementation Methods

Implementation is the "go-live" phase—choosing the wrong method can sink a project (e.g., NTC’s failed direct cutover of its billing system in 2018).

Types of Implementation

Worked Example: Library Management System (Level 1 DFD)

flowchart TD
  A["Librarian"] -->|"Issue Book"| B["Check Availability"]
  B -->|"Available"| C["Update Records"]
  C -->|"Generate Receipt"| A
  B -->|"Unavailable"| D["Notify User"]

• Process B: "Check Availability" splits into:
  • Sub-process: "Query Database."
  • Sub-process: "Check Due Dates."

6. System Testing: Ensuring Quality Before Launch

Testing catches bugs before users do (e.g., Pathao’s app crashes during peak hours if not tested).

Types of System Tests

mindmap
  root((System Testing))
    Unit Testing
      "Test individual modules (e.g., Khalti’s API)"
    Integration Testing
      "Test combined modules (e.g., Daraz cart + payment)"
    System Testing
      "Test entire system (e.g., Ncell’s network + app)"
    Acceptance Testing
      "User approval (e.g., bank’s loan system)"
    Regression Testing
      "Ensure old features still work after updates"

Worked Example: Pathao Ride Request Flow

1. Unit Test: Verify the "Calculate Fare" module.
2. Integration Test: Check if the fare module + GPS module work together.
3. System Test: Simulate 10,000 concurrent ride requests.
4. Acceptance Test: Pathao’s drivers/test users confirm the app works in low-network areas.

In the Real World

1. eSewa’s Payment Flow (DFDs + Implementation)

   • Idea Used: DFDs model how money moves from user → eSewa → merchant → bank.
   • How: Level 1 DFD breaks "Process Payment" into:
     • Authenticate user (via phone/OTP).
     • Deduct amount (via bank API).
     • Update merchant’s wallet.
   • Implementation: Phased rollout—first for mobile payments, then bills, then loans.

2. Ncell’s Network Upgrade (Economic Feasibility)

   • Idea Used: NPV and payback period justified a ₹1.2B 5G upgrade.
   • Calculation:
     • Annual benefit: ₹400M (more data usage → higher revenue).
     • PP = ₹1.2B / ₹400M = 3 years.
     • NPV (10% discount rate) ≈ ₹800M (positive → approved).

3. Daraz’s Order Queue (Process Modeling)

   • Idea Used: DFDs show how orders flow from customer → warehouse → delivery.
   • Problem Solved: Identified bottlenecks in the "Pack Order" process, reducing delays by 30%.

Exam Tip

1. Documentation Questions:

   • Always distinguish user vs. system documentation with examples (e.g., "eSewa’s app tutorial is user docs; its backend API specs are system docs").
   • For forms/reports, describe one guideline (e.g., "group related fields") and apply it to a real system (e.g., "Khalti’s receipt groups transaction details together").

2. Implementation Methods:

   • Direct: Use for low-risk systems (e.g., NEPSE’s annual updates).
   • Parallel: Use for critical systems (e.g., bank core banking).
   • Phased/Pilot: Use for large systems (e.g., NTC’s fiber rollout).
   • Exam Trap: Avoid saying "parallel is always safest"—mention its high cost.

3. Economic Feasibility:

   • Payback Period: Direct formula question (e.g., "Calculate PP for a ₹500K system with ₹100K/year profit").
   • NPV: Show all cash flows in a table (even if not asked, it’s worth marks).
   • Real-World Tie: Relate to Ncell’s 4G upgrade or eSewa’s expansion.

4. DFDs:

   • Level 0: Must have one process bubble and all external entities.
   • Level 1: Must decompose the main process (e.g., "Process Payment" → "Authenticate" + "Deduct").
   • Exam Tip: If asked to draw a DFD, label all arrows (e.g., "Payment Request" → "Process Payment").

5. Testing:

   • Types: List all four (unit, integration, system, acceptance).
   • Worked Example: Trace a Pathao ride request through these stages.

Final Checklist for Full Marks:

• Used real-world examples (eSewa, Ncell, Daraz) for every concept.
• Included at least 3 visuals (DFD, implementation table, NPV calculation).
• Showed worked examples with calculations (payback period, DFD decomposition).
• Compared implementation methods in a table.
• Ended with exam-specific tips (e.g., "always show NPV cash flows").