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

System Development Life Cycle (SDLC)

Definition: The System Development Life Cycle (SDLC) is a structured, phased framework that describes the complete set of activities carried out to plan, analyze, design, build, test, deploy and maintain an information system. It provides a systematic methodology so that systems are developed on time, within budget and according to user requirements.

Diagram (described)

The phases form a sequence (often drawn as a cycle or waterfall):

Preliminary Investigation -> Requirement Analysis -> System Design
   -> Coding/Development -> Testing -> Implementation -> Maintenance

Phases of SDLC

1. Preliminary Investigation / Feasibility Study

   • Identify the problem or opportunity, define the project scope and objectives.
   • Conduct technical, economic and operational feasibility.
   • Output: feasibility report and go/no-go decision.

2. Requirement Analysis

   • Gather facts using interviews, questionnaires, observation and record review.
   • Determine what the system must do (functional and non-functional requirements).
   • Output: Software Requirement Specification (SRS), DFDs, data dictionary.

3. System Design

   • Convert requirements into a blueprint: input/output design, database (logical & physical) design, process design and interface design.
   • Two parts: logical design (what) and physical design (how).
   • Output: design specification document.

4. Coding / Development

   • Programmers write source code in a chosen language and build the database according to the design.
   • Output: working program modules.

5. Testing

   • Verify the system against requirements: unit, integration, system and acceptance testing.
   • Detect and remove errors. Output: tested, validated system.

6. Implementation / Deployment

   • Install the system, migrate data, train users and convert (direct, parallel, phased or pilot).
   • Output: operational system in the live environment.

7. Maintenance

   • Corrective, adaptive, perfective and preventive changes after deployment.
   • Keeps the system useful throughout its life.

Conclusion: SDLC ensures discipline, traceability and quality, reducing the risk of cost overruns and failed projects.

Waterfall Model and Prototyping Model

Waterfall Model

The Waterfall model is the classical, linear-sequential SDLC model in which each phase must be completed before the next begins, and output of one phase becomes the input of the next. The phases are: Requirement Analysis -> Design -> Implementation (Coding) -> Testing -> Deployment -> Maintenance. It is best suited for projects with well-understood, stable requirements.

Prototyping Model

The Prototyping model builds a working model (prototype) of the system quickly, shows it to users, gathers feedback, and refines it iteratively until the prototype is accepted. It is used when requirements are unclear or evolving.

Steps:

1. Gather initial (broad) requirements.
2. Build a quick prototype (input screens, outputs, partial functions).
3. User evaluates the prototype.
4. Refine the prototype based on feedback.
5. Repeat steps 3-4 until the user is satisfied.
6. Build the final system based on the accepted prototype.

Merits

• Users see results early and clarify requirements, reducing misunderstanding.
• Errors and missing requirements are detected early.
• Higher user involvement and satisfaction.
• Suitable when requirements are not fully known.

Demerits

• Frequent changes can lead to poor design and "never-ending" iterations (scope creep).
• Users may mistake the prototype for the final product.
• Documentation is often neglected.
• May increase cost/time if not controlled.

Feasibility Study

Definition: A feasibility study is an evaluation conducted during the preliminary phase of SDLC to determine whether a proposed system is practical, achievable and worthwhile in terms of technology, cost, operations, schedule and law before significant resources are committed.

Categories of Feasibility

1. Technical Feasibility – Can the system be built with available hardware, software and technical expertise?
2. Economic Feasibility – Do the benefits outweigh the costs (cost-benefit analysis)?
3. Operational Feasibility – Will the system be accepted and used effectively by users within the organization?
4. Schedule Feasibility – Can the system be completed within the required time frame?
5. Legal/Ethical Feasibility – Does the system comply with laws, regulations and contractual obligations?

Economic Feasibility via Cost-Benefit Analysis (CBA)

CBA compares the total expected costs of the system against its total expected benefits.

• Costs: development costs (hardware, software, salaries) + operating costs (maintenance, supplies).
• Benefits: tangible (reduced labor, increased revenue) and intangible (better decisions, customer satisfaction).

Common evaluation techniques:

• Payback Period: time to recover investment = $\dfrac{\text{Initial Investment}}{\text{Annual Net Cash Inflow}}$. Shorter is better.
• Net Present Value (NPV): discounts future cash flows to present value:

where $B_t,C_t$ are benefits/costs in year $t$ and $i$ is the discount rate. A project is feasible if $NPV > 0$.

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

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

System: Definition, Characteristics and Types

Definition: A system is a set of interrelated and interdependent components that work together to achieve a common goal by accepting inputs, processing them and producing outputs.

Characteristics

• Components/Subsystems: made of interacting parts.
• Interrelationship & Interdependence: components depend on one another.
• Boundary & Environment: a boundary separates the system from its surroundings.
• Inputs, Process & Outputs: transforms inputs into useful outputs.
• Purpose/Objective: every system has a defined goal.
• Feedback & Control: output is monitored to regulate behavior.

Types of Systems

• Physical vs. Abstract: tangible (computer) vs. conceptual (a model/plan).
• Open vs. Closed: interacts with environment (a business) vs. self-contained (a sealed reaction).
• Deterministic vs. Probabilistic: predictable output (a program) vs. uncertain output (weather forecasting).
• Manual vs. Automated: operated by people vs. by machines/computers.
• Natural vs. Man-made: solar system vs. payroll system.

Example: A library management system is a man-made, open, automated system that takes inputs (book/member data), processes transactions (issue/return) and produces outputs (reports, fines).

Fact-Gathering (Information-Gathering) Techniques

During requirement analysis the system analyst collects facts about the existing system and user needs using the following techniques:

1. Interviews – Face-to-face or virtual conversations (structured or unstructured) with users and managers to obtain detailed, in-depth information and clarify doubts.
2. Questionnaires – Predefined sets of questions distributed to many respondents; efficient for gathering data from a large, geographically dispersed group.
3. Observation – The analyst directly watches how work is actually performed, revealing facts users may omit or be unaware of.
4. Record / Document Review – Studying existing documents such as forms, reports, manuals, organization charts and procedures to understand current processes.
5. Questionnaire/Sampling – Examining a representative subset of records or transactions when reviewing all data is impractical.
6. Joint Application Development (JAD) – Structured workshops bringing users and analysts together to gather requirements quickly.
7. Prototyping – Building a quick model to elicit requirements through user feedback.

Good analysis usually combines several techniques to cross-check facts and improve accuracy.

Data Dictionary

Definition: A data dictionary is a centralized repository (catalogue) that stores metadata – i.e., organized definitions and descriptions of all data elements, data stores and data flows used in a system. It accompanies the Data Flow Diagrams in structured analysis.

Contents

For each item a data dictionary records:

• Data Elements (fields): name, alias, description, data type, length, format, range/valid values.
• Data Structures: composition of records (e.g., Customer = Cust_ID + Name + Address). Notation uses = (composed of), + (and), [ | ] (either/or), { } (repetition), ( ) (optional).
• Data Flows: source, destination and contents of each flow.
• Data Stores: description of files/databases and the elements they hold.
• Processes: brief description of what each process does.

Importance in Structured Analysis

• Provides a single, consistent definition of every data item, avoiding ambiguity and redundancy.
• Supports and validates DFDs by detailing the data behind every flow and store.
• Improves communication among analysts, designers, programmers and users.
• Aids database design, documentation and future maintenance.
• Helps detect inconsistencies, missing or duplicate data.

Decision Tables and Decision Trees

Both are tools to represent process logic that involves multiple conditions and corresponding actions.

Decision Table

A tabular representation with four quadrants: condition stub, condition entries, action stub, action entries. Each column is a rule combining condition values and the resulting actions.

Example – discount policy: Customer gets 10% discount if a regular customer AND purchase > Rs.5000; otherwise no discount.

Decision Tree

A graphical (tree) representation where each node is a condition and each branch is a possible outcome, leading to leaf nodes = actions. It is easier to read for sequential decisions.

                 Regular customer?
                /                \
             Yes                  No
              |                    |
        Purchase>5000?        No discount
         /          \
       Yes           No
        |             |
  10% discount    No discount

Comparison: Decision tables are compact and good for many conditions/rules; decision trees are more intuitive and show the order in which conditions are checked.

Structured English

Definition: Structured English is a precise, restricted subset of the English language used to describe process logic in structured analysis. It uses a limited vocabulary of imperative verbs and the three control structures of structured programming — sequence, selection (IF-THEN-ELSE / CASE) and iteration (DO-WHILE, REPEAT-UNTIL) — without programming syntax, so it is unambiguous yet readable by users.

Structured English for Computing Employee Payroll

FOR each employee in the employee file:
    READ basic_salary, hours_worked, allowance

    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 + allowance + overtime_pay

    IF gross_pay > tax_threshold THEN
        tax = (gross_pay - tax_threshold) * tax_rate
    ELSE
        tax = 0
    ENDIF

    deductions = tax + provident_fund + insurance
    net_pay = gross_pay - deductions

    PRINT employee_id, gross_pay, deductions, net_pay
ENDFOR

This clearly specifies the payroll computation logic using sequence, selection and iteration.

Data Flow Diagram (DFD): Symbols and Rules

A DFD graphically shows the flow of data through a system — its processes, data stores, external entities and data flows.

Symbols (Gane & Sarson / Yourdon)

Rules for Drawing a DFD

1. Every process must have at least one input and one output data flow (no "black hole" with only inputs and no "miracle" with only outputs).
2. A data flow cannot go directly between two external entities, between two data stores, or between an external entity and a data store — it must pass through a process.
3. Each process and data flow must have a unique, meaningful name (processes use verbs, flows use nouns).
4. Data cannot move by itself; a process is needed to move/transform it.
5. Number processes (0, 1, 2…) and ensure balancing — inputs/outputs of a parent process must match those of its decomposed lower-level DFD.
6. Start with a context diagram (Level 0) showing one process, then explode into Level 1, Level 2 as needed.

Technical vs. Operational vs. Economic Feasibility

In short, technical = can we build it, operational = will it be used, and economic = is it worth the money.

Roles and Responsibilities of a System Analyst

A system analyst is the key professional who studies a problem, analyzes requirements and designs an information-system solution, acting as a bridge between users and the technical development team.

Roles

• Investigator/Fact-finder: studies the existing system and gathers requirements.
• Problem solver: identifies problems and proposes feasible solutions.
• Communicator/Liaison: translates user needs into technical specifications and vice versa.
• Designer: prepares logical and physical designs (DFDs, data dictionary, I/O, database).
• Change agent / facilitator: helps the organization adopt the new system.
• Project coordinator: plans, schedules and monitors development activities.

Responsibilities

1. Conduct preliminary investigation and feasibility study.
2. Gather and analyze requirements using interviews, questionnaires, observation, etc.
3. Prepare the SRS and modeling tools (DFD, ER diagrams, data dictionary).
4. Design the system (inputs, outputs, files/database, processes, interfaces).
5. Coordinate development, testing and implementation; assist in user training.
6. Ensure the system meets requirements, is documented and maintained.

Thus the analyst must possess analytical, technical, communication and managerial skills.

Normalization

Definition: Normalization is the process of organizing the attributes and relations of a relational database to reduce data redundancy and eliminate undesirable insertion, update and deletion anomalies by decomposing tables into well-structured smaller tables.

First Normal Form (1NF)

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

Example: Unnormalized Student(Roll, Name, Subjects="Math,Science") -> split into 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: Marks(Roll, Subject, Name, Marks) with key (Roll, Subject) — Name depends only on Roll (partial). Decompose into Student(Roll, Name) and Marks(Roll, Subject, Marks).

Third Normal Form (3NF)

A relation is in 3NF if it is in 2NF and has no transitive dependency (a non-key attribute must not depend on another non-key attribute).

Example: Student(Roll, Dept_ID, Dept_Name) — Dept_Name depends on Dept_ID which depends on Roll (transitive). Decompose into Student(Roll, Dept_ID) and Department(Dept_ID, Dept_Name).

Summary: 1NF removes repeating groups, 2NF removes partial dependency, and 3NF removes transitive dependency.