BSc CSIT (TU) Science System Analysis and Design (BSc CSIT, CSC315) Question Paper 2075 Nepal

Waterfall Model

The waterfall model is a classical, linear-sequential SDLC model in which each phase must be completed before the next one begins. Output of one phase serves as input to the next, and there is little or no overlap or backtracking. The phases flow downward like a waterfall:

1. Requirement Analysis – gather and document all requirements.
2. System Design – architecture, data, and interface design.
3. Implementation (Coding) – translate design into program code.
4. Testing – verify the system against requirements.
5. Deployment – install and put the system into operation.
6. Maintenance – correct errors and enhance the system.

It works best when requirements are well understood, stable, and unlikely to change.

Prototyping Model

The prototyping model builds a working, throwaway or evolutionary prototype (a quick, partial version of the system) so users can see and react to it before the full system is built. It is used when requirements are not clear at the start.

Steps:

1. Requirements gathering – collect known, basic requirements.
2. Quick design – design the visible parts (inputs, outputs, interfaces).
3. Build prototype – construct a working model.
4. User evaluation – users test the prototype and give feedback.
5. Refine prototype – repeat steps 2–4 until the user is satisfied.
6. Engineer the final product – build the complete, robust system.

Merits

• Requirements are clarified early through user feedback, reducing misunderstanding.
• Users are actively involved, increasing acceptance and satisfaction.
• Errors and missing requirements are detected early, lowering rework cost.
• Suitable when requirements are unclear or rapidly changing.

Demerits

• Frequent changes can lead to poor structure and unstable design.
• Users may mistake the prototype for the final system, raising unrealistic expectations.
• Can be time-consuming and costly if iterations are not controlled.
• Documentation is often neglected; difficult to estimate cost/effort accurately.

Feasibility Study

A feasibility study is a preliminary investigation carried out during the early stage of system development to determine whether a proposed system is worth developing — i.e., whether it is practical and beneficial in terms of technology, operations, economics, schedule, and law. Its output is a feasibility report recommending whether to proceed, modify, or abandon the project.

Categories of Feasibility (TELOS)

1. Technical feasibility – Can the system be built with the available/affordable hardware, software, and technical expertise?
2. Economic feasibility – Do the benefits of the system outweigh its costs? Measured by cost-benefit analysis.
3. Operational feasibility – Will the system be used and accepted by users, and does it fit the organization's procedures and culture?
4. Schedule (Time) feasibility – Can the system be developed and delivered within the required time frame?
5. Legal feasibility – Does the system conform to legal, regulatory, and contractual requirements?

Measuring Economic Feasibility – Cost-Benefit Analysis

Cost-benefit analysis (CBA) compares the total expected costs against the total expected benefits over the system's life.

• Costs: development costs (hardware, software, salaries) and operating costs (maintenance, supplies, training).
• Benefits: tangible (measurable savings, e.g., reduced staff cost, faster processing) and intangible (better decision-making, customer goodwill).

Common evaluation techniques:

• Payback period – time needed for cumulative benefits to recover the initial investment; shorter is better.
• Net Present Value (NPV) – discounts future cash flows to present value:

where $B_t$ and $C_t$ are benefits and costs in year $t$ and $i$ is the discount rate. NPV > 0 means the project is economically feasible.

• Return on Investment (ROI) = $\dfrac{\text{Net Benefit}}{\text{Total Cost}} \times 100\%$.

If benefits exceed costs (positive NPV, acceptable payback/ROI), the project is judged economically feasible.

Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a graphical tool used in structured analysis to show how data flows through a system — from external sources, through processes that transform it, into data stores, and out to destinations. It depicts what the system does (logical view), not how it is implemented. Symbols used (Yourdon/DeMarco): process (circle), external entity (rectangle), data store (open-ended rectangle), and data flow (arrow).

Context Diagram (Level 0 / Top level)

The context diagram shows the whole Retail Clothing Store Selling System as a single process (0) with its external entities and the data exchanged.

            order/payment                    sales report
  CUSTOMER  ───────────────►┌──────────────────┐◄─────────── MANAGER
            ◄───────────────│ 0                │
            bill/receipt    │ Clothing Store   │ purchase order
                            │ Selling System   │────────────► SUPPLIER
            stock supply    │                  │◄─────────────
  SUPPLIER  ───────────────►└──────────────────┘ delivery info

External entities: Customer, Supplier, Manager.

Level-0 (Level-1) DFD

The single process is decomposed into the major sub-processes with data stores.

 CUSTOMER ──order──► [1. Process Sale] ──update──► (D1: Inventory)
          ◄─bill──        │                              ▲
                          ▼                              │check stock
                    (D2: Sales)                          │
                          ▲                       [2. Manage Stock]
 MANAGER ◄─reports── [3. Generate Report] ◄── (D2)        ▲
                                                          │stock supply
                                          SUPPLIER ──delivery──┘

Processes: (1) Process Sale, (2) Manage Stock / Purchase, (3) Generate Reports. Data stores: D1 Inventory file, D2 Sales/Transaction file.

This shows customers placing orders and receiving bills, stock being updated and replenished from suppliers, and the manager receiving sales reports.

Data Dictionary

A data dictionary is a structured, centralized repository (a "data about data") that stores precise definitions of all the data elements, data flows, data stores, and processes used in a system. In structured analysis it complements the DFD by formally describing the meaning, composition, and properties of every item shown on the diagrams.

Typical Contents

• Data elements (items): name, alias, data type, length, range/valid values, and description.
• Data structures: how elements combine to form composite data (using notation such as =, +, [ | ], { }, ( )).
• Data flows: source, destination, and composition of each flow on the DFD.
• Data stores: contents, organization, and which processes access them.
• Processes: brief description of each process's logic.

Importance in Structured Analysis

• Provides a single, consistent definition of data, avoiding ambiguity and duplication.
• Acts as a communication bridge between analysts, designers, programmers, and users.
• Supports DFD validation by ensuring every flow and store is defined.
• Aids database/file design and future maintenance by documenting structure.
• Helps enforce data standards and integrity across the system.

Decision Tables and Decision Trees

Both are tools used in structured analysis to represent complex process (decision) logic that involves multiple conditions and corresponding actions.

Decision Table

A decision table is a tabular representation listing all conditions, their possible combinations (rules), and the actions to be taken for each combination. It has four quadrants: condition stub, condition entries, action stub, action entries.

Example – Discount policy: Give 10% discount if customer is a member AND purchase ≥ Rs 5000; otherwise no discount.

Decision Tree

A decision tree shows the same logic as a horizontal tree: the root branches on each condition, and the leaves give the resulting actions. It is easier to read for sequential decisions.

              ┌─ Purchase ≥ 5000 ─► 10% discount
Member? ─Yes──┤
              └─ Purchase < 5000 ─► No discount
        └No ───────────────────────► No discount

Comparison: Decision tables are best when there are many conditions/combinations and completeness must be checked; decision trees are more intuitive and better for showing the order in which decisions are made.

Structured English

Structured English is a narrow, restricted subset of the English language used to describe process logic in a clear, unambiguous way. It uses a limited vocabulary of strong action verbs, the system's data-dictionary terms, and the three standard programming constructs — sequence, decision (IF-THEN-ELSE / CASE), and iteration (REPEAT/WHILE) — but no special syntax, so non-programmers can read it. It avoids adjectives, adverbs, and ambiguous words.

Structured English for Computing Employee Payroll

FOR each employee in the payroll file:
    READ employee record (basic-salary, hours-worked, allowances)

    Compute gross-pay:
        IF hours-worked > 160 THEN
            overtime-hours = hours-worked - 160
            overtime-pay   = overtime-hours * overtime-rate
        ELSE
            overtime-pay   = 0
        ENDIF
        gross-pay = basic-salary + allowances + overtime-pay

    Compute deductions:
        tax = gross-pay * tax-rate
        deductions = tax + provident-fund + insurance

    Compute net-pay:
        net-pay = gross-pay - deductions

    WRITE pay-slip (employee-id, gross-pay, deductions, net-pay)
ENDFOR

This describes the payroll process using sequence (compute steps), decision (overtime IF), and iteration (FOR each employee).

Symbols Used in a DFD

Using the DeMarco/Yourdon notation, a DFD uses four basic symbols:

Rules for Drawing a DFD

1. Process rule: Every process must have at least one input and one output data flow (no "miracle" or "black hole" processes). Data cannot be created or destroyed without a source.
2. Naming: Processes are named with verb phrases; data flows, stores, and entities with noun phrases. Each process is numbered.
3. Data store rule: Data cannot flow directly from one data store to another, or from store to external entity, without passing through a process. A store must be linked to at least one process.
4. External entity rule: Data cannot flow directly between two external entities without going through a process.
5. Balancing: The data flows in and out of a process must be balanced (conserved) between a parent diagram and its child (lower-level) decomposition.
6. Levelling: Start with a context diagram (single process 0), then explode into level-0, level-1, etc. Avoid crossing data-flow lines for clarity.

Technical vs Operational vs Economic Feasibility

In short: technical = capability, operational = acceptability/usability, economic = profitability of the proposed system.

Roles and Responsibilities of a System Analyst

A system analyst is the professional who studies an organization's problems and information needs and designs information-system solutions, acting as a bridge between users/management and the technical development team.

Roles

• Investigator / fact-finder: studies the existing system, gathers requirements through interviews, questionnaires, and observation.
• Problem solver: analyses problems and proposes feasible solutions.
• Architect / designer: designs the logical and physical structure of the new system (DFDs, data dictionary, files, interfaces).
• Change agent: introduces and manages organizational change caused by the new system.
• Communicator / liaison: mediates between users, management, and programmers.

Responsibilities

1. Conduct preliminary investigation and feasibility study.
2. Perform requirement gathering and analysis, documenting needs.
3. Prepare system specifications and design (input, output, processing, database).
4. Help in selecting hardware/software and estimating cost and schedule.
5. Coordinate development, testing, and implementation with programmers and users.
6. Plan conversion, training, and documentation.
7. Support ongoing maintenance and evaluation of the system.

Normalization

Normalization is the process of organizing the attributes and relations of a database to reduce data redundancy and eliminate insertion, update, and deletion anomalies by decomposing tables into smaller, well-structured relations based on functional dependencies.

First Normal Form (1NF)

A relation is in 1NF if all attributes contain only atomic (single, indivisible) values — no repeating groups or multivalued attributes.

Example (not 1NF → 1NF): A Student(RollNo, Name, Subjects="Math,Physics") row with multiple subjects in one cell violates 1NF. Convert to atomic rows:

Second Normal Form (2NF)

A relation is in 2NF if it is in 1NF and every non-key attribute is fully functionally dependent on the whole primary key (no partial dependency on part of a composite key).

Example: (StudentID, CourseID → Grade, StudentName). StudentName depends only on StudentID (partial dependency). Split into Student(StudentID, StudentName) and Enrollment(StudentID, CourseID, Grade).

Third Normal Form (3NF)

A relation is in 3NF if it is in 2NF and has no transitive dependency — no non-key attribute depends on another non-key attribute.

Example: Student(StudentID, DeptID, DeptName) where DeptName depends on DeptID (transitive). Decompose into Student(StudentID, DeptID) and Department(DeptID, DeptName).

Each higher form removes a specific type of redundancy/anomaly, improving data integrity.

Types of System Testing

Testing verifies that the system meets requirements and is free of defects before deployment.

• Unit testing: each module/program is tested in isolation for correct logic.
• Integration testing: tested modules are combined and the interfaces between them are tested (top-down, bottom-up, or sandwich).
• System testing: the complete, integrated system is tested against the functional and non-functional requirements (performance, security, recovery, stress, load).
• Acceptance testing (UAT): end users test the system in a real environment to confirm it satisfies their needs before sign-off (alpha and beta testing).
• Regression testing: re-testing after changes to ensure no new defects are introduced.

Testing techniques include black-box (test from specifications, ignoring internal logic) and white-box (test based on internal code paths).

Importance of Testing in SDLC

• Detects and removes errors/defects early, when they are cheaper to fix.
• Ensures the system meets the specified requirements and is reliable.
• Improves quality, performance, and security, building user confidence.
• Reduces the risk of costly failures after deployment and lowers maintenance cost.
• Validates that the system is ready for implementation and acceptable to users.

System Conversion (Changeover) Strategies

Conversion is the process of changing over from the old system to the new system during implementation. Four common strategies are:

1. Direct (Plunge / Big-Bang) Conversion

The old system is stopped and the new system takes over immediately at a chosen cut-off date.

• Advantage: least costly, fastest, no need to run two systems.
• Disadvantage: highest risk — if the new system fails, there is no fallback.

2. Parallel Conversion

The old and new systems run simultaneously for a period; outputs are compared until the new system is proven reliable.

• Advantage: safest — old system is a backup; results can be verified.
• Disadvantage: most expensive and time-consuming (double work and resources).

3. Phased (Phase-in) Conversion

The new system is introduced gradually, module by module (or function by function), replacing parts of the old system over time.

• Advantage: lower risk; users adapt gradually; problems isolated to one phase.
• Disadvantage: takes longer; managing interfaces between old and new parts is complex.

4. Pilot Conversion

The new system is first installed for one group/location/branch (the pilot site). After it succeeds there, it is rolled out to the rest of the organization.

• Advantage: limits risk to a small area; lessons learned improve full rollout.
• Disadvantage: slower full deployment; pilot site may differ from others.