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

Entity-Relationship Diagram (ERD)

An Entity-Relationship Diagram (ERD) is a graphical (conceptual) data model that describes the data stored in a system in terms of entities, the attributes that describe them, and the relationships among them. It was introduced by Peter Chen (1976) and forms the basis of relational database design.

Attributes

An attribute is a property or characteristic of an entity (shown as an ellipse). Types include:

• Simple / Atomic – cannot be divided (e.g. Age).
• Composite – made of sub-parts (e.g. Name = First + Last).
• Single-valued vs Multi-valued – e.g. DOB vs Phone numbers (multi-valued, double ellipse).
• Derived – computed from others (e.g. Age from DOB, dashed ellipse).
• Key attribute – uniquely identifies an entity instance (underlined, e.g. Member_ID).

Relationships

A relationship (diamond) is an association between two or more entities, e.g. a Member borrows a Book. Relationship degrees: unary (recursive), binary, ternary.

Cardinality

Cardinality specifies the number of instances of one entity that can be associated with instances of another:

• One-to-One (1:1)
• One-to-Many (1:N)
• Many-to-Many (M:N)

Participation may be total (mandatory, double line) or partial (optional).

ER Model for a Library Management System

Entities and key attributes

Relationships and cardinality

• BOOK has COPY → 1:N (one title, many physical copies; total participation of COPY).
• MEMBER borrows COPY → M:N, resolved into an associative entity ISSUE (Issue_Date, Due_Date, Return_Date).
• STAFF manages ISSUE → 1:N.
• MEMBER reserves BOOK → M:N.

Textual diagram description

  [MEMBER]──<borrows>──[COPY]──<is copy of>──[BOOK]
      |                                   
   <reserves> M:N ────────────────────────[BOOK]
      |
  [STAFF]──<manages>──(ISSUE associative entity)

The M:N borrows relationship becomes the ISSUE table holding Member_ID + Copy_ID + dates, giving a clean relational schema.

CASE Tools

CASE (Computer-Aided Software Engineering) tools are automated software packages that support and partly automate one or more phases of the System Development Life Cycle (SDLC) — analysis, design, coding, testing, documentation and maintenance. They improve productivity, consistency and quality of the delivered system.

Components of CASE Tools

1. Central Repository (Information Repository) – A shared database storing all project data: diagrams, data dictionary, requirements, design specifications and metadata. It ensures consistency and integration among all other components.

2. Upper CASE (Front-end) Tools – Support early phases: planning, requirement analysis and design. Examples: diagramming tools for DFDs, ERDs, structure charts, screen/report layout designers.

3. Lower CASE (Back-end) Tools – Support later phases: coding, testing, maintenance. Includes code generators, test-case generators and configuration management.

4. Integrated CASE (I-CASE) Tools – Combine upper and lower CASE through a common repository, providing seamless support from analysis to implementation.

5. Diagramming Tools – Draw and verify graphical models (DFD, ERD, UML, flowcharts).

6. Documentation Generators – Produce technical and user documentation automatically.

7. Code Generators & Reverse-Engineering Tools – Generate source code from design and reconstruct design from existing code.

8. Analysis / Validation Tools – Check models for completeness, consistency and errors.

Role in System Development

• Automates repetitive drawing and documentation tasks.
• Enforces standards and improves accuracy/consistency.
• Speeds up development and reduces cost.
• Maintains an up-to-date repository easing maintenance and team coordination.
• Improves communication between analysts, designers and developers.

Examples: Rational Rose, Oracle Designer, Visible Analyst, ER/Studio, Microsoft Visio.

Logical vs Physical System Design

Logical design defines the abstract model of inputs, processes, outputs and data; physical design translates that model into actual technical specifications that can be built.

Input Design

The process of designing how data enters the system. Goals: accuracy, ease of use, minimum errors and effort.

• Decide input data, source, medium (keyboard, scanner, web form), format and validation.
• Use codes, default values, drop-downs and validation checks to reduce errors.
• Apply the GIGO principle — good input prevents "garbage out".

Output Design

The process of designing the information the system delivers to users (reports, screens, documents).

• Determine output content, format, medium (screen, print, file), frequency and recipients.
• Outputs must be relevant, timely, accurate, well-formatted and readable.
• Types: external, internal, operational, turnaround and detail/summary/exception reports.

Principles of Good Form Design

1. Clarity & simplicity – logical, uncluttered layout.
2. Proper sequencing – fields follow the natural order of data entry.
3. Grouping of related fields with clear captions/labels.
4. Adequate space for entries and instructions.
5. Identification – title, form number, organisation name.
6. Consistency in style, fonts and alignment.
7. Ease of completion – minimise effort, use tick boxes/codes.
8. Routing & control information for processing.

Normalization

Normalization is a step-by-step database design technique that organises relations to reduce data redundancy and eliminate insertion, update and deletion anomalies by decomposing tables based on functional dependencies.

First Normal Form (1NF)

A relation is in 1NF if every attribute holds atomic (single, indivisible) values — no repeating groups or multi-valued attributes.

Example: Student(ID, Name, Subjects="Maths,Physics") violates 1NF. Fix by one row per subject:

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). Relevant only when there is a composite key.

Example: (StudentID, CourseID) → Grade, but StudentID → StudentName is a partial dependency. Decompose into Student(StudentID, StudentName) and Enrolment(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 StudentID → DeptID → DeptName. DeptName depends transitively on the key. Decompose into Student(StudentID, DeptID) and Department(DeptID, DeptName).

Each higher normal form removes a specific class of anomaly, yielding a cleaner, redundancy-free design.

Types of System Testing

1. Unit Testing – Tests individual modules/components in isolation to verify each works correctly.
2. Integration Testing – Tests combined modules to detect interface and interaction errors (top-down, bottom-up, sandwich).
3. System Testing – Tests the complete integrated system against the specified requirements as a whole.
4. Functional Testing – Verifies the system performs the required functions correctly (black-box).
5. Performance / Stress / Load Testing – Checks speed, response time and behaviour under heavy load.
6. Security Testing – Verifies protection against unauthorised access.
7. Acceptance Testing (UAT) – Conducted by the end-user/client to confirm the system meets business needs before go-live; includes Alpha (in-house) and Beta (real users) testing.
8. Regression Testing – Re-tests after changes to ensure existing functionality still works.

Importance of Testing in SDLC

• Detects defects early, when they are cheaper to fix.
• Ensures the system meets user requirements and quality standards.
• Improves reliability, security and performance.
• Builds user confidence and reduces post-deployment failures and maintenance cost.
• Validates that the system is fit for purpose before implementation.

System Conversion (Changeover) Strategies

Conversion is the process of changing 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 starts immediately.

• Pros: least cost, fastest.
• Cons: 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 trusted.

• Pros: safest, provides a backup and validation of results.
• Cons: most expensive (double operating cost and effort).

3. Phased (Staged) Conversion

The new system is introduced gradually, module by module over time.

• Pros: lower risk, allows learning and correction between phases.
• Cons: takes longer; interfacing old and new parts can be complex.

4. Pilot Conversion

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

• Pros: limits risk to a small group, real-environment trial.
• Cons: pilot results may not represent the whole organisation; slower full rollout.

Summary: Direct is cheapest but riskiest; parallel is safest but costliest; phased and pilot offer a balanced, controlled changeover.

System Maintenance

System maintenance is the process of modifying a system after it has been deployed to correct faults, improve performance, or adapt it to a changed environment. It is the longest and most costly phase of the SDLC.

Types of Maintenance

1. Corrective Maintenance – Fixing errors/bugs discovered during operation that were not detected during testing.

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

3. Perfective Maintenance – Enhancing functionality, performance or maintainability in response to user requests (new features, better UI, optimisation). Usually the largest share of effort.

4. Preventive Maintenance – Changing the system to prevent future problems, improve reliability and reduce the risk of failure (e.g. restructuring code, updating documentation).

Importance: keeps the system useful, reliable, secure and aligned with evolving user and organisational needs throughout its life.

RAD vs Agile Development

In short: RAD is a prototype-driven approach to build software fast, whereas Agile is a broader iterative philosophy that embraces change through continuous collaboration and incremental delivery.

Relationship between DFD and ERD

DFD (Data Flow Diagram) is a process model showing how data moves and is transformed — its processes, data flows, external entities and data stores.

ERD (Entity-Relationship Diagram) is a data model showing the structure of stored data — entities, attributes and relationships.

How they relate (complementary views of the same system)

• A DFD models the dynamic/process view (what the system does), while an ERD models the static/data view (what the system stores).
• The data stores in a DFD correspond to the entities (and their relationships) in the ERD. Each data store in a DFD is typically defined as one or more entities in the ERD.
• Both share a common data dictionary: the data flows and stores in the DFD are described by the same data elements that form the attributes of entities in the ERD.
• They are cross-checked for balance/consistency — every entity must be created, read, updated or deleted by some process in the DFD, and every data store must map to entities.

Example

In a library system, the DFD data store "Books File" maps to the BOOK entity in the ERD; the "Issue Records" store maps to the ISSUE relationship/entity.

Together DFD and ERD give a complete structured-analysis model — process logic plus data structure.

System

A system is an organised set of interrelated and interdependent components that work together toward a common goal/objective by accepting inputs, processing them and producing outputs.

Characteristics of a System

1. Components / Subsystems – made of interacting parts.
2. Interrelationship & Interdependence – parts depend on one another.
3. Boundary – defines what is inside and outside the system.
4. Environment – everything outside the boundary that affects it.
5. Inputs, Process, Output – the basic transformation cycle.
6. Goal / Objective – a common purpose.
7. Interface – connection between subsystems.
8. Feedback & Control – monitors output and adjusts the system.

Types of Systems (with examples)

• Physical vs Abstract – tangible (computer hardware) vs conceptual (a mathematical model).
• Open vs Closed – interacts with environment (a business/ERP system) vs isolated (a controlled lab reaction).
• Deterministic vs Probabilistic – predictable output (a computer program) vs uncertain (weather forecasting).
• Natural vs Man-made (Artificial) – solar system vs banking system.
• Manual vs Automated – paper-based ledger vs computerised accounting system.

Fact-Gathering (Fact-Finding) Techniques

Fact-finding is the process by which an analyst collects information about the existing system and user requirements. The main techniques are:

1. Interview – Direct, face-to-face questioning of users/management (structured or unstructured). Pros: detailed, allows clarification. Cons: time-consuming, depends on interviewer skill.

2. Questionnaire – A set of written questions distributed to many respondents. Pros: covers large, dispersed groups cheaply, anonymous. Cons: low response rate, no clarification.

3. Observation – Watching how work is actually performed in the real environment. Pros: reliable, first-hand data. Cons: people may behave differently when watched; time-consuming.

4. Record / Document Review – Studying existing documents, reports, manuals, forms and files. Pros: shows current procedures and data; Cons: may be outdated.

5. Sampling – Examining a representative subset of records/transactions when data volume is large.

6. Joint Application Development (JAD) / Workshops – Group sessions bringing users and analysts together to gather requirements quickly.

7. Research / Brainstorming / Prototyping – Studying similar systems or eliciting feedback through trial prototypes.

Analysts usually combine several techniques for accurate and complete requirements.

Data Dictionary

A data dictionary is a centralised repository of metadata — "data about data" — that stores standardised definitions of all data elements, data flows, data stores and processes used in a system. In structured analysis it complements the DFD by precisely describing every item that appears on the diagram.

Contents of a Data Dictionary

For each data element it records:

• Name / alias of the data item.
• Description / meaning.
• Data type and length / format.
• Range / allowed values and validation rules.
• Default value.
• Relationships / composition of data structures, expressed with notation such as:
  • = (is composed of), + (and / concatenation)
  • [ | ] (either/or), { } (repetition / iteration)
  • ( ) (optional)
• Source and destination (which processes use it), and data stores it belongs to.

Importance in Structured Analysis

• Ensures consistency and standard definitions across the whole design and team.
• Removes ambiguity about data meaning and avoids redundancy.
• Supports cross-checking and balancing of DFDs (every flow/store is defined).
• Acts as documentation aiding design, programming and maintenance.
• Forms the basis for designing the database/file structures and validation logic.