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

Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) is a graphical, structured-analysis tool that depicts how data moves through a system, the processes that transform the data, the external entities that supply or receive data, and the data stores that hold it. It models the logical flow of information without specifying physical implementation details (hardware, files, programs).

DFD Notation (Yourdon/De Marco)

(a) Context Diagram (Level 0 / Top level)

The context diagram shows the whole system as a single process (process 0) and its interactions with external entities.

        clothing-order / payment
  CUSTOMER ───────────────────────►┌──────────────────┐
          ◄──── bill / receipt ─────┤  0               │
                                     │  Retail Clothing │── purchase order ──► SUPPLIER
  MANAGEMENT ── reports request ───►│  Sales System    │◄── stock supply ───
            ◄──── sales report ──────└──────────────────┘

External entities: Customer, Supplier, Management. The single process exchanges data flows such as order, payment, receipt, sales report, purchase order, stock supply.

(b) Level-1 (commonly called Level-0 expansion) DFD

Process 0 is decomposed into the main sub-processes of the store:

CUSTOMER ──order──►( 1.0 )──valid order──►( 2.0 )──invoice──► CUSTOMER
                  Process            Process Sale
                  Order
                    │ check stock        │ update
                    ▼                    ▼
               D1 | Inventory       D2 | Sales
                    ▲                    
             ( 3.0 )──reorder──► SUPPLIER
             Manage Stock
                    ▲
               D1 | Inventory

MANAGEMENT ◄── sales/stock report ──( 4.0 ) Generate Reports ◄── D2|Sales, D1|Inventory

• 1.0 Process Order – receives customer order, validates it against the Inventory store (D1).
• 2.0 Process Sale – produces invoice/receipt, records the transaction in Sales store (D2), decrements inventory.
• 3.0 Manage Stock – monitors inventory level and raises purchase orders to the Supplier when stock is low.
• 4.0 Generate Reports – reads Sales and Inventory stores to produce management reports.

This layered set of DFDs (context → level-1) maintains balancing: every data flow entering/leaving the context process also appears in the level-1 diagram.

Entity-Relationship Diagram (ERD)

An Entity-Relationship Diagram (ERD) is a conceptual data-modelling tool that represents the data requirements of a system in terms of entities, their attributes, and the relationships among them. It is used during system analysis to design the logical structure of a database.

(a) Attributes

Properties that describe an entity. Types:

• Simple / atomic – cannot be divided (e.g. Age).
• Composite – made of sub-parts (e.g. Name = First + Last).
• Key (identifier) – uniquely identifies an entity instance (e.g. Member_ID); shown underlined.
• Derived – computed from others (e.g. Age from DOB); shown dashed.
• Multivalued – can hold several values (e.g. Phone); shown double-ellipse.

(b) Relationships

An association between two or more entities, drawn as a diamond. A relationship may have a degree (unary, binary, ternary) and may itself carry descriptive attributes (e.g. Issue_Date on the BORROWS relationship).

(c) Cardinality

The number of instances of one entity that can be associated with instances of another:

• One-to-One (1:1) – e.g. an employee manages one branch.
• One-to-Many (1:N) – e.g. one publisher prints many books.
• Many-to-Many (M:N) – e.g. many members borrow many books.

Participation may be total (every instance must participate) or partial (optional).

ER Model for a Library Management System

Entities & key attributes

• MEMBER(<u>Member_ID</u>, Name, Address, Phone)
• BOOK(<u>Book_ID</u>, Title, Author, Edition)
• PUBLISHER(<u>Pub_ID</u>, Name, Address)
• STAFF(<u>Staff_ID</u>, Name, Designation)

Relationships (with cardinality)

MEMBER ──< BORROWS >── BOOK        (M:N, attrs: Issue_Date, Due_Date)
PUBLISHER ──< PUBLISHES >── BOOK   (1:N)
STAFF ──< ISSUES >── BOOK          (1:N, who handed out the copy)

Diagram description: rectangles for the four entities, ellipses for attributes (key attributes underlined), and diamonds BORROWS, PUBLISHES, ISSUES connecting them with cardinality ratios M:N and 1:N labelled on the connecting lines. The M:N BORROWS relationship is later resolved into a junction (associative) entity LOAN when mapping to tables.

CASE Tools

CASE (Computer-Aided Software Engineering) tools are software applications that automate and support the activities of the Software Development Life Cycle (SDLC) — analysis, design, coding, testing, documentation and maintenance. They improve productivity, enforce standards, maintain consistency and reduce errors by storing all project information in a central repository.

Components of CASE Tools

1. Central Repository (Information Repository) – a shared database storing all diagrams, data dictionary entries, design specifications and reports; ensures consistency and reusability across the project.

2. Diagramming / Drawing tools – produce DFDs, ER diagrams, structure charts, UML diagrams, flowcharts; help visualise and document the system.

3. Data Dictionary tools – record and manage definitions of every data element, data flow and data store used in the models.

4. Form/Report (Screen & prototype) generators – design input screens, forms and output reports; support prototyping.

5. Analysis tools – check models for completeness, consistency and correctness (e.g. detect unbalanced DFDs, missing entities).

6. Code generators – automatically generate source code/skeletons from design models, reducing manual coding.

7. Documentation generators – produce technical and user documentation automatically from the repository.

8. Project / configuration management tools – schedule tasks, track versions and manage changes.

Categories

• Upper CASE – supports early SDLC phases (planning, analysis, design).
• Lower CASE – supports later phases (coding, testing, maintenance).
• Integrated (I-CASE) – covers the entire life cycle through a shared repository.

Role in System Development

CASE tools speed up development, enforce methodology and documentation standards, improve communication among the team, reduce manual/repetitive work and errors, ease maintenance through up-to-date documentation, and support reusability — overall raising software quality and productivity.

Technical vs Operational vs Economic Feasibility

Feasibility study assesses whether a proposed system is worth developing. Three key dimensions:

Summary: Technical = can we build it, Operational = should/will it work in practice, Economic = is it financially justified.

Roles and Responsibilities of a System Analyst

A system analyst is the key person who studies an organisation's problems and information needs and designs an appropriate computer-based solution, acting as a bridge between users and the technical development team.

Key Roles

• Investigator / Fact-finder – gathers requirements through interviews, questionnaires, observation and document study.
• Problem solver – analyses the existing system, identifies problems and proposes feasible solutions.
• System designer – designs inputs, outputs, processes, files/database and interfaces (using DFDs, ERDs, etc.).
• Liaison / Communicator – mediates between non-technical users and technical programmers, translating business needs into specifications.
• Change agent – introduces and helps the organisation adopt the new system.

Responsibilities

1. Conduct feasibility study (technical, operational, economic).
2. Collect and analyse requirements and document them clearly.
3. Design the logical and physical system (data, process, interface design).
4. Prepare specifications for programmers and oversee development.
5. Plan and supervise testing, implementation and conversion.
6. Prepare documentation and train users.
7. Support maintenance and post-implementation review.

Thus the analyst combines technical knowledge, analytical ability and good communication/interpersonal skills.

Normalization

Normalization is the process of organising the attributes and tables of a relational database to reduce data redundancy and eliminate insertion, update and deletion anomalies. It decomposes large tables into smaller, well-structured tables linked by keys, based on functional dependencies.

First Normal Form (1NF)

A relation is in 1NF if every attribute holds only atomic (single) values — no repeating groups or multivalued attributes.

Example (not 1NF):

Converted to 1NF (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: In (StudID, Course → Grade, StudName), StudName depends only on StudID (partial). Split into:

• STUDENT(StudID, StudName)
• ENROLL(StudID, Course, 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: In STUDENT(StudID, Dept, DeptHead), DeptHead depends on Dept (transitive). Split into:

• STUDENT(StudID, Dept)
• DEPARTMENT(Dept, DeptHead)

Each higher form removes a specific anomaly, yielding cleaner, redundancy-free relations.

System Testing and Its Importance in SDLC

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

Types of System Testing

1. Unit testing – tests individual modules/components in isolation.
2. Integration testing – tests combined modules to verify their interfaces work correctly (top-down/bottom-up).
3. System testing – tests the complete, integrated system against requirements as a whole.
4. Functional testing – verifies each function produces the expected output (black-box).
5. Performance / Stress / Load testing – checks speed, response time and behaviour under heavy load.
6. Security testing – verifies access control and data protection.
7. Recovery testing – checks the system can recover from failures.
8. Acceptance testing – done by the user/client (alpha and beta) to confirm the system is acceptable for delivery.
9. Regression testing – re-tests after changes to ensure no new defects are introduced.

Importance of Testing in the SDLC

• Detects and removes defects early, reducing later correction cost.
• Ensures the system meets user requirements and quality standards.
• Improves reliability, performance and security.
• Builds user confidence and reduces risk of failure after deployment.
• Validates that all modules integrate correctly before go-live.

Testing is a continuous quality-assurance activity that ultimately determines whether the system is fit for implementation.

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:

1. Direct (Plunge / Big-Bang) Conversion

The old system is stopped completely and the new system starts on a chosen date.

• Advantage: cheapest, no duplication of effort.
• Disadvantage: very risky — if the new system fails there is no fallback.
• Use when: the system is small/non-critical or the old system is unusable.

2. Parallel Conversion

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

• Advantage: safest; old system is a backup; results can be validated.
• Disadvantage: expensive — double work and resources.
• Use when: the system is critical and failure is costly.

3. Phased (Phased-in) Conversion

The new system is introduced gradually, module by module or function by function.

• Advantage: risk is spread; users adapt gradually.
• Disadvantage: takes longer; old and new must interface during transition.
• Use when: the system is large and can be split into stages.

4. Pilot Conversion

The new system is first deployed in one location/department (pilot site); after success it is rolled out everywhere.

• Advantage: limits risk to one site; lessons learned before full rollout.
• Disadvantage: full benefits delayed; not all sites are identical.
• Use when: the organisation has many similar branches/locations.

System Maintenance

System maintenance is the process of modifying a system 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.

Types of Maintenance

1. Corrective Maintenance – fixing errors/bugs discovered after the system is in use (e.g. correcting a faulty calculation). It deals with residual defects.

2. Adaptive Maintenance – modifying the system to keep it working in a changed environment (new hardware, OS, government rules, or business policy changes).

3. Perfective Maintenance – enhancing the system to improve performance, usability or add new features requested by users, even though it works correctly. This is usually the largest portion.

4. Preventive Maintenance – making changes to prevent future problems and to make the system more maintainable (e.g. restructuring code, updating documentation, optimising for reliability).

Importance

Maintenance keeps the system operational, accurate, secure and relevant throughout its life, protecting the organisation's investment.

RAD vs Agile Development

Summary: RAD focuses on speed through prototyping and component reuse, whereas Agile focuses on flexibility and continuous customer collaboration through repeated iterations. Agile is a broad philosophy, while RAD is a specific rapid-prototyping model.

Relationship Between DFD and ERD

Both DFD and ERD are structured-analysis modelling tools, but they describe different views of the same system and are complementary.

How they relate

• The data stores in a DFD correspond to the entities (and their relationships) in the ERD. A DFD says which processes read/write a store; the ERD describes the structure and relationships of the data inside that store.
• The data flows in a DFD are made up of data elements that are defined as attributes of entities in the ERD.
• Both share a common data dictionary, which keeps the two models consistent.

Importance together

Used together they give a complete model: the DFD captures the functional/behavioural requirements while the ERD captures the data/storage requirements. Cross-checking them (a data store in the DFD must map to entities in the ERD) ensures the analysis is consistent and complete.

System: Definition, Characteristics and Types

Definition

A system is a set of interrelated and interdependent components (elements) that work together in an organised way to achieve a common goal or objective, by taking inputs, processing them, and producing outputs.

Characteristics of a System

1. Components / Elements – interrelated parts that make up the system.
2. Boundary – defines what is inside and outside the system.
3. Environment – everything outside the boundary that affects the system.
4. Interface – the point of interaction between subsystems or with the environment.
5. Input – Process – Output – inputs are transformed into useful outputs.
6. Feedback & Control – output is monitored and used to regulate the system.
7. Objective / Purpose – the goal all components work toward.
8. Organisation & Interdependence – arranged hierarchically; parts depend on one another.

Types of Systems (with examples)

• Open vs Closed – an open system interacts with its environment (e.g. a business/ banking system); a closed system does not (e.g. a sealed chemical reaction).
• Physical vs Abstract – physical systems are tangible (computer hardware); abstract (conceptual) systems are ideas/models (a mathematical model).
• Deterministic vs Probabilistic – deterministic behaves in a predictable way (a computer program); probabilistic involves uncertainty (a weather-forecasting system).
• Manual vs Automated – manual done by people (a paper filing system); automated done by computers (an online billing system).
• Natural vs Man-made – natural (the solar system); man-made (an information system).

Thus a system is purposeful, organised, bounded and interactive, and can be classified along these dimensions depending on its nature.