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

Logical vs. Physical System Design

Logical design is the abstract blueprint of the system showing inputs, outputs, processes and data without regard to the implementing technology. Physical design maps that blueprint onto actual technology — specifying the database structure, file organisation, hardware platform, programming language, input screens and output reports.

Input Design

Input design is the process of converting user-oriented inputs into a computer-based format. Its goals are to reduce input volume, minimise errors, avoid delays and keep the process simple. It covers deciding the data to capture, the input medium (keyboard, OCR, barcode, web form), the input format/layout, validation checks (range, type, check digit) and feedback/error messages.

Output Design

Output design determines how information is presented to users. The output is the most visible part of a system, so it must be accurate, timely, relevant and in the right format (screen display, printed report, document, graph). Steps include identifying the output's purpose and audience, selecting the medium, and designing the layout (headings, columns, totals).

Principles of Good Form Design

• Ease of use / simplicity — logical top-to-bottom, left-to-right flow.
• Meaningful title and clear instructions at the top.
• Logical grouping of related fields into sections.
• Adequate space for handwritten/typed entries.
• Captions and labels clearly identify each field.
• Consistent terminology and layout across forms.
• Pre-printed/default values and check boxes to reduce effort.
• Routing information (where the form goes next) and proper margins.

A good form minimises data-entry errors and gathers exactly the data the system needs.

System Development Life Cycle (SDLC)

The SDLC is a structured, phase-by-phase framework that describes the activities performed to plan, analyse, design, build, test, deploy and maintain an information system. It provides a disciplined approach that ensures the delivered system meets user requirements within budget and time.

Phases of SDLC

1. Preliminary Investigation / Feasibility Study The problem or opportunity is identified and a feasibility study (technical, economic, operational, schedule, legal) determines whether the project is worth pursuing. Output: feasibility report.

2. System Analysis (Requirement Analysis) The analyst studies the existing system using fact-gathering techniques (interviews, questionnaires, observation, record review) and models requirements with DFDs, ER diagrams and a data dictionary. Output: Software Requirement Specification (SRS).

3. System Design The SRS is converted into a blueprint. Includes logical design (overall architecture, modules) and physical design (database, input/output, interfaces, processing logic). Output: design specification.

4. Coding / Implementation (Development) Programmers write and unit-test the actual program code according to the design specifications.

5. Testing The system is verified through unit, integration, system and acceptance testing to ensure it is error-free and meets requirements.

6. Deployment / Conversion The new system is installed and users are switched over using a conversion strategy (direct, parallel, pilot or phased). User training and data migration occur here.

7. Maintenance After going live the system is monitored and modified — corrective, adaptive, perfective and preventive maintenance — to keep it useful over its life.

Diagram (described)

The classic SDLC is drawn as a downward sequence of boxes — Investigation → Analysis → Design → Coding → Testing → Implementation → Maintenance — often shown as a circular/cyclic loop because maintenance feedback can trigger a new investigation, making the life cycle continuous.

Feasibility -> Analysis -> Design -> Coding -> Testing -> Implementation -> Maintenance
      ^________________________ feedback ________________________________|

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 flows down as input to the next (like water cascading down steps). Typical phases: Requirement Analysis → System Design → Implementation → Testing → Deployment → Maintenance. It is simple and easy to manage but inflexible — requirements must be known fully and early, and going back to a previous phase is costly. It suits small, well-understood projects with stable requirements.

Prototyping Model

In the prototyping model, a working prototype (a quick, partial, throwaway or evolutionary version) of the system is built early and shown to users. Based on user feedback the prototype is refined repeatedly until it satisfies requirements, after which the final system is built (throwaway) or the prototype is grown into the final system (evolutionary).

Steps:

1. Identify basic/known requirements.
2. Develop an initial prototype quickly.
3. User evaluates the prototype.
4. Refine the prototype using feedback.
5. Repeat steps 3–4 until accepted, then build/finalise the system.

Merits

• Users see and interact with the system early, so requirements are clarified and misunderstandings reduced.
• High user involvement and satisfaction.
• Errors and missing functions detected early.
• Useful when requirements are unclear or evolving.

Demerits

• Can lead to poor documentation and unclear scope.
• Risk of scope creep from continuous changes.
• Users may mistake the rough prototype for the finished product.
• Repeated prototyping can be time-consuming and costly; quick prototypes may produce a poorly structured final system.

RAD vs. Agile

Summary: RAD emphasises fast delivery through prototyping and tooling, while Agile is a broader philosophy of iterative, collaborative and adaptive development. RAD can be seen as an early predecessor that influenced Agile.

Relationship between DFD and ERD

A DFD (Data Flow Diagram) models the process/functional view — how data moves through the system, the processes that transform it, the external entities, and the data stores where data rests. An ERD (Entity-Relationship Diagram) models the data/structural view — the entities (things about which data is stored), their attributes, and the relationships among them.

They are complementary, not competing models of the same system:

• The data stores in a DFD correspond to the entities (and relationships) in the ERD. Each persistent data store usually maps to one or more entities in the ERD.
• The DFD shows how and when data in those stores is created, read, updated and deleted (process logic), while the ERD shows what data is stored and how it is structured/related.
• Together they ensure consistency: every entity in the ERD should be created/used by some process in the DFD, and every data store in the DFD should be defined by entities in the ERD.
• Both share definitions in the common data dictionary, which links the data elements appearing in flows/stores to the attributes of entities.

Example: In a library system, the DFD process Issue Book writes to the data store Loans; in the ERD this corresponds to a relationship Borrows between the entities Member and Book.

Definition of a System

A system is an organised set of interrelated and interdependent components (subsystems) that work together toward a common goal or objective, taking inputs, transforming them through a process, and producing outputs, with feedback and control.

Characteristics of a System

• Organisation / Structure — components arranged in an ordered way.
• Interaction & Interdependence — components depend on and affect one another.
• Integration — components form a unified whole (the whole is greater than the sum of parts).
• Central Objective / Goal — every system exists for a purpose.
• Input, Process, Output — the basic transformation cycle.
• Boundary and Environment — what is inside the system vs. outside.
• Feedback and Control — output is monitored to regulate the system.

Types of Systems (with examples)

• Physical vs. Abstract — physical are tangible (a computer); abstract are conceptual (a mathematical model).
• Open vs. Closed — open systems exchange with their environment (an organisation); closed systems are isolated (a sealed chemical reaction).
• Deterministic vs. Probabilistic — deterministic behave predictably (a computer program); probabilistic involve uncertainty (weather/inventory systems).
• Natural vs. Man-made (Artificial) — natural occur in nature (the solar system); man-made are designed by people (a payroll system).
• Adaptive vs. Non-adaptive — adaptive change with environment (a living organism, a learning system); non-adaptive do not.

Fact-Gathering (Requirement-Elicitation) Techniques

During system analysis the analyst collects facts about the current system and user requirements using these techniques:

1. Interviews — direct, face-to-face questioning of users/managers. May be structured (fixed questions) or unstructured (open). Gives rich, detailed information and allows clarification, but is time-consuming.
2. Questionnaires — a set of printed questions distributed to many respondents. Economical for reaching a large, geographically spread audience; less flexible and may have low response rates.
3. Observation — the analyst watches how work is actually performed in the workplace. Gives first-hand, reliable facts about real procedures; but people may behave differently when observed (Hawthorne effect).
4. Record / Document Review — studying existing documents, reports, manuals, forms and procedures. Reveals how the current system is supposed to work; documents may be outdated.
5. Sampling — examining a representative subset of records/transactions when the volume is too large to study fully.
6. Prototyping / JAD sessions — building a quick prototype or holding joint workshops with users to elicit and confirm requirements.

A good analyst usually combines several techniques to cross-check facts and obtain complete, accurate requirements.

Data Dictionary

A data dictionary is a centralised repository (the data about data or metadata) that stores precise definitions of all the data elements, data flows, data stores and processes used in a system. In structured analysis it supplements the DFD by defining everything that appears on it.

Contents

• Data Elements (items) — name, alias, description, data type, length, allowed values/range, default.
• Data Structures / Records — how elements are grouped, defined using notation such as = (composed of), + (and), [ ] (either/or), { } (repetition), ( ) (optional).
• Data Flows — source, destination, and composition of each flow in the DFD.
• Data Stores — files/tables, the data they hold and the flows in/out.
• Processes — description of the transformation each process performs.

Example notation: Customer-Address = Street + City + District + Postal-Code

Importance in Structured Analysis

• Provides a single, consistent definition of every data item, avoiding ambiguity and duplication.
• Documents and standardises the system, easing communication among analysts, designers and programmers.
• Helps validate DFDs (ensures balancing and completeness).
• Aids database/file design and later maintenance by recording structure and meaning.
• Serves as a cross-reference linking DFD, ERD and design.

Decision Tables and Decision Trees

Both are tools to represent complex process logic that depends on multiple conditions, used when structured English becomes hard to follow.

Decision Table

A tabular tool with four quadrants: condition stubs (list of conditions), condition entries (Y/N for each rule), action stubs (possible actions), and action entries (X marking which actions fire for each rule). For n conditions there are 2ⁿ rules.

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

Decision Tree

A graphical, tree-like tool. The root is the starting point, branches represent the outcomes of each condition (decision points/nodes), and the leaves show the actions. It reads left to right and is more intuitive than a table when the order of conditions matters.

Example (described): From the root, branch on Member? → if Yes, branch on Order ≥ 5000? → Yes leads to Give 10% discount, No leads to No discount; if Member? No, leaf is No discount.

Member? --Yes--> Order>=5000? --Yes--> 10% discount
   |                          --No---> No discount
   --No-----------------------------> No discount

Comparison: Decision tables are compact and good for checking completeness/all combinations; decision trees are easier to read and show the sequence of decisions clearly.

Structured English

Structured English is a restricted, precise subset of the English language used to describe process logic in a clear, unambiguous way. It uses a limited vocabulary (imperative verbs + data names from the data dictionary) and three standard control constructs — sequence, decision (IF-THEN-ELSE / CASE) and iteration (REPEAT/WHILE/FOR) — written with indentation. It avoids adjectives, adverbs and ambiguous words, making logic easy to understand and convert to code.

Structured English for Computing Employee Payroll

GET employee record
READ hours_worked, hourly_rate

IF hours_worked <= 40 THEN
    gross_pay = hours_worked * hourly_rate
ELSE
    regular_pay = 40 * hourly_rate
    overtime_hours = hours_worked - 40
    overtime_pay = overtime_hours * hourly_rate * 1.5
    gross_pay = regular_pay + overtime_pay
ENDIF

COMPUTE tax = gross_pay * tax_rate
COMPUTE total_deductions = tax + provident_fund + other_deductions
COMPUTE net_pay = gross_pay - total_deductions

PRINT employee_name, gross_pay, total_deductions, net_pay

This shows a sequence of computations with an IF-THEN-ELSE decision for overtime, producing the employee's net pay.

Data Flow Diagram (DFD): Symbols and Rules

A DFD graphically shows how data flows through a system — from external sources, through processes that transform it, into data stores, and out to external destinations.

Symbols

(Two common notations exist: Yourdon/DeMarco uses circles for processes; Gane & Sarson uses rounded rectangles.)

Rules for Drawing a DFD

1. Each process must have at least one input and one output data flow.
2. No process can create data out of nothing — a process with only outputs (a miracle) or only inputs (a black hole) is invalid.
3. Data flows only to/from a process — data cannot flow directly between two external entities, between two data stores, or from a store to an external entity without passing through a process.
4. A data store must connect to at least one process (data must be put in or taken out).
5. Name every process, flow, store and entity clearly and uniquely.
6. Maintain balancing (levelling): the inputs/outputs of a parent process must match those of its child diagram when the DFD is exploded into Level 0, Level 1, etc. The top-level context diagram has a single process for the whole system.
7. Avoid crossing data-flow lines where possible; duplicate stores/entities can be marked.

Technical vs. Operational vs. Economic Feasibility

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

Summary:

• Technical — Is the technology available and adequate?
• Operational — Will the new system be used and supported by people in the organisation?
• Economic — Do the benefits justify the costs? (the most commonly used, via cost-benefit analysis).