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

Feasibility Study

A feasibility study is a preliminary investigation carried out during the early phase of the SDLC to evaluate whether a proposed system is worth developing. It determines whether the project is practical, achievable and beneficial in terms of technology, operations, economics, schedule and legal constraints, and produces a recommendation on whether to proceed.

Categories of Feasibility

1. Technical Feasibility — Assesses whether the required technology (hardware, software, networks, technical skills) exists or can be acquired to build and run the system. It answers: Can it be built with current technology?
2. Economic Feasibility — Evaluates whether the benefits of the system outweigh its costs, usually through cost-benefit analysis. It answers: Is it worth the money?
3. Operational Feasibility — Examines how well the system will work within the organization, whether users will accept it, and whether it solves the actual problem. It answers: Will it be used effectively?
4. Schedule (Time) Feasibility — Determines whether the system can be developed and delivered within the required time frame.
5. Legal Feasibility — Checks conformity with laws, regulations, data-protection rules and contracts.

Measuring Economic Feasibility (Cost-Benefit Analysis)

Cost-benefit analysis compares the total costs of developing and operating the system against the benefits it produces.

Costs include:

• Development costs (one-time): hardware, software, analyst/programmer salaries, training.
• Operating costs (recurring): maintenance, supplies, electricity, support staff.

Benefits include:

• Tangible benefits: measurable gains such as reduced labour cost, lower error rates, increased sales.
• Intangible benefits: improved customer satisfaction, better decision making, goodwill.

Common evaluation techniques:

• Payback Period — time taken for cumulative benefits to recover the initial investment.

• Net Present Value (NPV) — discounts future cash flows to today's value; a positive NPV means the project is economically viable.

where $C_t$ is the net cash flow in year $t$ and $r$ is the discount rate.

• Return on Investment (ROI) —

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

Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a graphical tool used in structured analysis to represent the flow of data through a system. It shows how input data is transformed by processes into output, where data is stored, and the external entities that interact with the system. A DFD models what the system does rather than how it does it, and is decomposed into levels (context/level-0, level-1, etc.).

Symbols used:

• Process (circle/rounded rectangle) — transforms data.
• Data flow (arrow) — direction of data movement.
• External entity (rectangle) — source/sink of data outside the system.
• Data store (open rectangle / two parallel lines) — where data is held.

Context Diagram (Level-0 / Top Level)

The context diagram represents the entire selling system as a single process (process 0) interacting with external entities.

  +----------+      order/payment       +-------------------+      receipt/goods      +----------+
  | CUSTOMER | -----------------------> |                   | ----------------------> | CUSTOMER |
  +----------+                          |   0               |                         +----------+
                                        |  Clothing Store   |
  +----------+   stock/price update     |  Selling System   |   purchase order        +----------+
  | SUPPLIER | -----------------------> |                   | ----------------------> | SUPPLIER |
  +----------+                          +-------------------+                          +----------+
                                                 |  sales report
                                                 v
                                          +------------+
                                          | MANAGEMENT |
                                          +------------+

External entities: Customer, Supplier, Management.

Level-0 (Level-1) DFD

The single process is exploded into the main sub-processes of the store.

 CUSTOMER --order--> ( 1. Process Sale ) --update--> [D1 Inventory]
        <--receipt-- (              )                      ^
                            | sale record                 | stock check
                            v                             |
                       [D2 Sales]            ( 2. Manage Inventory ) --reorder--> SUPPLIER
 CUSTOMER --payment--> ( 3. Process Payment ) --txn--> [D3 Payments]
                            |
                            v
                  ( 4. Generate Reports ) --sales report--> MANAGEMENT
                            ^
                            | reads
                       [D2 Sales]

Processes: 1. Process Sale, 2. Manage Inventory, 3. Process Payment, 4. Generate Reports. Data stores: D1 Inventory, D2 Sales, D3 Payments. Data flows connect customers placing orders/payments, inventory updates, supplier reordering, and management reports.

Entity-Relationship Diagram (ERD)

An Entity-Relationship Diagram (ERD) is a graphical model that represents the logical structure of a database by depicting entities, their attributes, and the relationships among them. It is used during data modelling to design the conceptual schema of a system.

Key Concepts

Entity — A real-world object or concept about which data is stored (e.g. Book, Member). Shown as a rectangle.

Attributes — Properties that describe an entity, shown as ovals. Types:

• Key attribute — uniquely identifies an entity (e.g. BookID); underlined.
• Composite attribute — divisible into parts (e.g. Name → first, last).
• Multivalued attribute — can hold many values (e.g. PhoneNo); double oval.
• Derived attribute — computed from others (e.g. Age from DOB); dashed oval.

Relationship — An association between entities (e.g. Member borrows Book). Shown as a diamond.

Cardinality (mapping) — Specifies how many instances of one entity relate to another:

• One-to-One (1:1) — e.g. each Member has one Library Card.
• One-to-Many (1:N) — e.g. one Author writes many Books.
• Many-to-Many (M:N) — e.g. Members borrow many Books, and a Book can be borrowed by many Members over time.

ER Model for a Library Management System

Entities and key attributes:

• Member (MemberID, Name, Address, Phone)
• Book (BookID, Title, ISBN, Edition)
• Author (AuthorID, Name)
• Librarian/Staff (StaffID, Name)

Relationships with cardinality:

  Author  ──< writes >── Book          (1:N : one author writes many books)
  Member  ──< borrows >── Book         (M:N : resolved by a BORROW/Issue entity)
  Staff   ──< issues  >── Borrow       (1:N : a librarian issues many loans)

The M:N borrows relationship is implemented through an associative entity Issue/Borrow (IssueID, IssueDate, DueDate, ReturnDate) linking MemberID and BookID.

[Member]---(borrows)---[Issue]---(of)---[Book]---(written by)---[Author]
   |MemberID                 |IssueID         |BookID                |AuthorID

This ERD captures members borrowing books, books written by authors, and loans handled by staff, with appropriate cardinalities.

Structured English

Structured English is a process-description tool used in structured analysis to specify the logic of a process in a narrow, restricted subset of the English language. It uses simple, unambiguous statements combined with the three basic constructs of structured programming — sequence, selection (IF-THEN-ELSE, CASE) and iteration (REPEAT/WHILE) — together with indentation, so that the process logic is clear to both users and programmers without using actual programming syntax.

Structured English for Computing Employee Payroll

FOR each employee in the payroll file DO
    READ employee record (hours worked, hourly rate, status)

    IF hours worked > 40 THEN
        overtime hours = hours worked - 40
        regular pay = 40 * hourly rate
        overtime pay = overtime hours * hourly rate * 1.5
    ELSE
        regular pay = hours worked * hourly rate
        overtime pay = 0
    ENDIF

    gross pay = regular pay + overtime pay

    CASE of employee tax bracket
        WHEN gross pay <= 25000: tax = 0
        WHEN gross pay <= 50000: tax = gross pay * 0.10
        OTHERWISE:               tax = gross pay * 0.20
    ENDCASE

    deductions = tax + provident fund + insurance
    net pay = gross pay - deductions

    PRINT pay slip (gross pay, deductions, net pay)
ENDFOR

This specification uses sequence (calculations), selection (IF/CASE for overtime and tax) and iteration (FOR loop over employees), which are the defining features of structured English.

Rules and Symbols for Drawing a DFD

Symbols

Rules

1. Every process must have at least one input data flow and one output data flow (no "black hole" with only inputs, no "miracle" with only outputs).
2. Processes must be named with a verb phrase and numbered hierarchically (0, 1, 1.1, …).
3. Data flows must be labelled with the name of the data and generally move in one direction.
4. No data flow directly between two external entities — they must be connected through a process.
5. No data flow directly between two data stores and no direct flow from an external entity to a data store — a process must lie in between.
6. Data stores cannot create data — data flows in or out of a store only via a process.
7. Conservation / balancing rule — the inputs and outputs of a parent process must match the inputs and outputs of its decomposed (child) diagram (level balancing).
8. The context diagram has exactly one process representing the whole system.

Technical vs Operational vs Economic Feasibility

Summary: Technical feasibility checks capability, operational feasibility checks acceptability and usability, and economic feasibility checks affordability and profitability.

Roles and Responsibilities of a System Analyst

A system analyst is the key person who studies an organization's problems and information needs and designs solutions, acting as a bridge between users/management and the technical development team. Major roles and responsibilities include:

1. Investigation / Fact Finding — Study the existing system and gather requirements through interviews, questionnaires, observation and document review.
2. Problem Analysis — Identify problems, define the scope, and determine what the new system must achieve.
3. Feasibility Study — Assess technical, economic, operational and schedule feasibility of the proposed solution.
4. System Design — Design inputs, outputs, processes, files/databases and interfaces; prepare DFDs, ERDs and specifications.
5. Liaison / Communicator — Act as an intermediary between end users, management and programmers, translating user needs into technical specifications and vice versa.
6. Coordination and Planning — Plan project schedules, allocate resources and coordinate the development team.
7. Testing and Implementation Support — Assist in testing, user training, system conversion and documentation.
8. Evaluation and Maintenance — Review system performance after installation and recommend improvements.

In short, the analyst plays the roles of investigator, problem solver, designer, coordinator and change agent.

Normalization

Normalization is the process of organizing the attributes and tables of a relational database to reduce data redundancy and eliminate insertion, update and deletion anomalies. It decomposes a table into smaller, well-structured tables based on functional dependencies, while preserving data through joins.

First Normal Form (1NF)

A relation is in 1NF if every attribute holds only atomic (single, indivisible) values and there are no repeating groups.

Example (not 1NF): Student(RollNo, Name, Subjects = {Math, Science}). 1NF: split repeating subjects into separate rows so each cell is atomic:

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: (RollNo, Subject) → Marks but RollNo → Name. Here Name depends only on part of the key (partial dependency). 2NF decomposition:

• Student(RollNo, Name)
• Result(RollNo, Subject, Marks)

Third Normal Form (3NF)

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

Example: Student(RollNo, Name, DeptID, DeptName) where RollNo → DeptID and DeptID → DeptName (transitive). 3NF decomposition:

• Student(RollNo, Name, DeptID)
• Department(DeptID, DeptName)

Each higher normal form removes a specific type of anomaly: 1NF removes non-atomic values, 2NF removes partial dependency, 3NF removes transitive dependency.

Types of System Testing and Importance of Testing in SDLC

Testing is the process of executing a system to find errors and to verify that it meets its specified requirements.

Types / Levels of Testing

1. Unit Testing — Tests individual modules/components in isolation to ensure each works correctly.
2. Integration Testing — Tests combined modules to verify that interfaces and data passing between them work (top-down, bottom-up, or sandwich approaches).
3. System Testing — Tests the complete, integrated system against the overall requirements (functional and non-functional such as performance, security, usability).
4. Acceptance Testing — Conducted by end users/customer to confirm the system meets business needs; includes Alpha testing (in-house) and Beta testing (real users at their site).
5. Regression Testing — Re-testing after changes to ensure existing functionality is not broken.

Testing techniques include black-box testing (based on inputs/outputs without internal knowledge) and white-box testing (based on internal logic and code paths).

Importance of Testing in SDLC

• Detects and removes errors/defects early, reducing the cost of fixing them later.
• Ensures the system meets user requirements and quality standards.
• Improves reliability, security and performance.
• Builds user confidence and reduces the risk of failure after deployment.
• Verifies and validates the product before implementation, lowering maintenance effort.

System Conversion (Changeover) Strategies

Conversion is the process of changing over from the old system to the new system during implementation. The four main strategies are:

1. Direct (Plunge / Big-Bang) Conversion — The old system is stopped completely and the new system is switched on at a chosen date.

   • Advantage: Cheapest and fastest; no duplicate operation.
   • Disadvantage: Very risky — if the new system fails there is no fallback.

2. Parallel Conversion — The old and new systems run simultaneously for a period; results are compared until the new system is proven reliable.

   • Advantage: Safest; old system acts as a backup.
   • Disadvantage: Expensive and effort-intensive (running two systems at once).

3. Phased (Gradual) Conversion — The new system is introduced in stages/modules over time, each part replacing the corresponding old part.

   • Advantage: Lower risk than direct; errors are isolated to one phase.
   • Disadvantage: Takes longer; needs interfaces between old and new parts.

4. Pilot Conversion — The new system is first installed in one location or department (the pilot site); after success it is rolled out to the rest of the organization.

   • Advantage: Limits risk to a small group and provides a real test environment.
   • Disadvantage: Roll-out to all sites takes additional time.

System Maintenance

System maintenance is the process of modifying a system or its components after it has been delivered and put into operation, in order to correct faults, improve performance, or adapt it to a changed environment. It is the final and longest phase of the SDLC and typically consumes the largest share of the total system cost.

Types of Maintenance

1. Corrective Maintenance — Fixing errors, bugs and defects discovered during actual use that were not detected during testing.
2. Adaptive Maintenance — Modifying the system to keep it usable in a changed environment (new hardware, OS, regulations, or business rules).
3. Perfective Maintenance — Enhancing the system by adding new features or improving performance, usability and maintainability in response to user requests.
4. Preventive Maintenance — Making changes to prevent future problems, such as restructuring/refactoring code, updating documentation and improving reliability before faults occur.

Corrective and adaptive maintenance keep the system working; perfective and preventive maintenance keep it useful and robust over its life.

RAD vs Agile Development

Summary: RAD focuses on speed through prototyping and reusable components, while Agile focuses on flexibility through continuous iterative delivery and collaboration.