Systems Analysis and Design — CXC CSEC Information Technology Revision Notes

What you'll learn

This revision guide covers the complete Systems Analysis and Design topic from the CXC CSEC Information Technology syllabus. You will learn how organizations identify problems, analyze existing systems, design solutions, and implement new information systems. This topic is essential for understanding how technology projects are planned and executed in Caribbean businesses, schools, and government agencies.

Key terms and definitions

System — a set of interrelated components working together to achieve a common goal or objective

Systems analyst — an IT professional who investigates problems, analyzes existing systems, and designs solutions to meet organizational needs

Feasibility study — an investigation carried out to determine whether a proposed system is practical, considering technical, economic, legal, operational, and schedule factors

Data flow diagram (DFD) — a graphical representation showing how data moves through a system, using symbols to represent processes, data stores, external entities, and data flows

Implementation — the phase where a new system is built, tested, and put into operation, replacing or supplementing the existing system

System Development Life Cycle (SDLC) — a structured process consisting of distinct phases used to develop information systems from initial concept to retirement

User requirements — specific needs and expectations that end users have for a new system, gathered during the analysis phase

Maintenance — ongoing activities to keep a system running efficiently, including correcting errors, updating features, and adapting to changing needs

Core concepts

The System Development Life Cycle (SDLC)

The SDLC provides a systematic approach to developing information systems. Each phase must be completed before moving to the next, ensuring thorough planning and quality control.

Phase 1: Preliminary Investigation/Problem Definition

This initial phase identifies whether a problem exists and determines if it warrants further investigation.

Activities include:

Recognizing the problem (e.g., long queues at a Caribbean commercial bank)
Conducting preliminary interviews with management and staff
Reviewing the current situation briefly
Determining if a full feasibility study is justified
Defining project scope and objectives

Phase 2: Feasibility Study

The systems analyst conducts a detailed investigation to determine if the proposed system is viable. Five types of feasibility are examined:

Technical feasibility: Can the solution be implemented with available technology? Does the organization have the required hardware, software, and technical expertise?
Economic feasibility: Do the benefits outweigh the costs? This includes cost-benefit analysis comparing development costs against long-term savings and revenue generation.
Legal feasibility: Does the solution comply with Caribbean data protection laws, copyright legislation, and industry regulations?
Operational feasibility: Will users accept and effectively use the new system? Does it fit with organizational culture and work practices?
Schedule feasibility: Can the system be developed and implemented within an acceptable timeframe?

Example: A Jamaican secondary school considering a computerized student information system must assess whether they have reliable electricity and internet (technical), sufficient budget (economic), compliance with student data protection (legal), teacher willingness to use technology (operational), and ability to implement before the new academic year (schedule).

Phase 3: Analysis

The analyst gathers detailed information about the current system to understand what the new system must accomplish.

Data collection methods:

Interviews: One-on-one or group discussions with stakeholders to gather in-depth information
Questionnaires: Written surveys distributed to collect data from many users efficiently
Observation: Watching users perform tasks to understand actual workflows
Document review: Examining existing forms, reports, procedures, and records

The analyst identifies:

User requirements (what users need the system to do)
System requirements (technical specifications)
Input, processing, and output requirements
Problems with the current system
Constraints and limitations

Phase 4: Design

The systems analyst creates detailed specifications for the new system.

Design activities include:

Input design: forms, screens, data capture methods
Output design: reports, displays, documents
File and database design: data structures, relationships, field specifications
Process design: algorithms, logic, calculations
Interface design: user interaction, navigation, menus
Security design: access controls, backup procedures
Hardware and software specifications

Documentation tools used in design:

Data flow diagrams (DFDs)
System flowcharts
Structure charts
Entity-relationship diagrams
Screen layouts and report formats

Phase 5: Implementation

The new system is built, tested, and put into operation.

Implementation activities:

Programming or software configuration
Hardware acquisition and installation
Testing (unit testing, system testing, user acceptance testing)
Data conversion from old to new system
User training and documentation preparation
System changeover using one of four methods

Changeover methods:

Direct changeover: The old system stops and the new system starts immediately on a specific date. Risky but fast and inexpensive.
Parallel changeover: Both old and new systems run simultaneously for a period. Safest but most expensive approach as duplicate work is required.
Phased changeover: The new system is introduced in stages, module by module or department by department.
Pilot changeover: The new system is introduced to one location or department first, tested, then rolled out to other areas.

Example: A Trinidad and Tobago supermarket chain implementing a new point-of-sale system might use pilot changeover, installing it first at one branch in Port of Spain, resolving issues, then expanding to other locations.

Phase 6: Maintenance

After implementation, ongoing work keeps the system functioning effectively.

Types of maintenance:

Corrective: Fixing errors and bugs discovered during operation
Adaptive: Modifying the system to accommodate changes in the environment (new regulations, hardware upgrades)
Perfective: Enhancing features based on user feedback and new requirements
Preventive: Making changes to prevent future problems

Phase 7: Evaluation

The system is assessed to determine if it meets objectives and user needs.

Evaluation criteria:

Does it solve the original problem?
Are users satisfied?
Is performance acceptable (speed, reliability, accuracy)?
Were budget and timeline targets met?
What lessons were learned for future projects?

Data Flow Diagrams (DFDs)

DFDs are essential tools for representing system processes and data movement. They use four standard symbols:

External entity (rectangle): People or organizations outside the system that provide or receive data (e.g., customers, suppliers)
Process (rounded rectangle/circle): Activities that transform or manipulate data
Data store (open rectangle/parallel lines): Where data is stored temporarily or permanently (files, databases)
Data flow (arrow): Shows data moving between entities, processes, and stores; labeled with data description

DFD levels:

Context diagram (Level 0): Shows the entire system as a single process with external entities
Level 1 DFD: Breaks the system into major processes
Level 2+ DFDs: Further decomposition of complex processes

DFD rules:

Processes must have both input and output flows
Data stores must have at least one input and one output (though not necessarily from the same process)
All flows must be labeled
External entities cannot communicate directly with data stores

System Development Approaches

Waterfall model: Sequential approach where each SDLC phase is completed before the next begins. Suitable for well-defined projects with stable requirements, such as implementing a payroll system for a Barbados government ministry.

Prototyping: Building a working model of the system early in development to clarify requirements and get user feedback. Useful when users are uncertain about exact requirements, like designing a new mobile app for a Caribbean tourism company.

Agile development: Iterative approach with short development cycles (sprints), continuous user involvement, and flexibility to accommodate changing requirements. Ideal for dynamic environments like developing an e-commerce platform for a regional retailer.

Documentation

System documentation includes:

System design specifications
Data dictionaries
Program code and comments
Test plans and results
Network diagrams
Security protocols

User documentation includes:

User manuals
Quick reference guides
Training materials
Online help systems
FAQ documents
Tutorial videos

Good documentation is essential for system maintenance, user support, and staff training.

Worked examples

Example 1 (8 marks)

A Grenadian hospital wants to replace its manual patient records system with a computerized system.

(a) State TWO problems the hospital might experience with the manual system. (2 marks)

(b) Identify TWO data collection methods the systems analyst could use during the analysis phase. (2 marks)

Mark scheme answers:

(a) Two of:

Difficulty locating patient files quickly/time consuming to search
Risk of losing or misplacing patient records
Limited space for storing paper files
Difficulty sharing records between departments
Handwriting may be illegible
Cannot generate statistical reports easily

(b) Two of:

Interviews (with doctors, nurses, administrators)
Questionnaires (distributed to staff)
Observation (watching patient registration and record-keeping processes)
Document review (examining existing forms, files)

This is suitable because:

Patient records contain critical medical information where errors could endanger lives, so having a backup system is essential
Staff can check that data is accurately transferred and the new system works correctly before abandoning the manual system
If the computerized system fails, patient care can continue using manual records without disruption
Provides time for staff to become familiar with the new system while maintaining the safety net of the familiar manual system

(Award 1 mark for defining parallel changeover, 3 marks for three developed points explaining suitability in context)

Example 2 (6 marks)

Draw a Level 0 Data Flow Diagram (context diagram) for a library book loan system. The system should show a Member borrowing and returning books. (6 marks)

Mark scheme answer:

The diagram must include:

One process labeled "Library Loan System" (1 mark)
External entity "Member" shown as rectangle (1 mark)
Data flow arrow from Member to System labeled "Book loan request" or similar (1 mark)
Data flow arrow from System to Member labeled "Borrowed book" or similar (1 mark)
Data flow arrow from Member to System labeled "Returned book" (1 mark)
Correct use of symbols and proper labeling (1 mark)

Example 3 (4 marks)

A systems analyst is conducting a feasibility study for a new online banking system for a St. Lucian credit union.

State what the analyst would investigate for EACH of the following types of feasibility: (a) Technical feasibility (1 mark) (b) Economic feasibility (1 mark) (c) Legal feasibility (1 mark) (d) Operational feasibility (1 mark)

Mark scheme answers:

(a) Whether the credit union has the necessary technology infrastructure (servers, internet bandwidth, security systems) and technical expertise to develop and maintain the online banking system

(b) Whether the costs of developing and maintaining the system (hardware, software, training, security) are justified by the benefits (reduced branch operating costs, increased member satisfaction, competitive advantage)

(c) Whether the system complies with Caribbean data protection legislation, banking regulations, electronic transactions laws, and cybersecurity requirements for financial institutions

(d) Whether members and staff will accept and use the system, and if it fits with the credit union's operational procedures and member demographics (considering internet access and digital literacy)

Common mistakes and how to avoid them

Confusing phases of SDLC: Students often mix up the order or activities of different phases. Remember the logical sequence: you must understand the problem (investigation) before studying it in detail (analysis), design before building (implementation), and maintain after deployment. Create a mnemonic or timeline chart for revision.
Drawing incomplete DFDs: Missing labels on data flows or drawing arrows in wrong directions loses marks. Always label every arrow with the data being transferred, ensure processes have both inputs and outputs, and remember data flows show data movement, not material goods.
Not relating feasibility to context: When asked about feasibility, students give generic answers. Always apply your answer to the specific scenario given—mention the organization type, location, or particular requirements stated in the question.
Describing changeover methods without justification: Simply defining parallel or direct changeover earns minimal marks. Explain WHY a method is suitable or unsuitable for the specific situation, considering factors like data criticality, user training needs, budget constraints, and organizational risk tolerance.
Mixing up system and user documentation: System documentation is technical and for IT professionals; user documentation is for end users. Don't confuse program code (system) with user manuals (user).
Incomplete data collection method descriptions: Stating "interviews" alone is insufficient. Specify who would be interviewed (users, managers, customers) and what information would be gathered. Similarly, for questionnaires, mention distribution to whom and what topics would be covered.

Exam technique for Systems Analysis and Design

Command words matter: "State" requires brief factual answers (1-2 words); "Describe" needs more detail showing characteristics; "Explain" requires reasons and consequences showing understanding. For "Explain why parallel changeover is suitable" you must give both the definition AND reasons related to the context.
Context is crucial: CXC examiners expect answers applied to the scenario. If the question mentions a "Barbadian pharmacy," relate your answer to medical data sensitivity, inventory management, or prescription regulations—not generic business examples.
Marks indicate detail required: A 1-mark question needs one point; 4 marks typically require four distinct points or two well-developed points. If you're asked to explain something for 4 marks, provide specific details, examples, or consequences, not just a definition.
DFD questions have precise marking criteria: Each symbol, label, and arrow direction matters. Use a ruler for neat diagrams, ensure all flows are labeled, and check that external entities don't connect directly to data stores.

Quick revision summary

The SDLC consists of seven phases: preliminary investigation, feasibility study, analysis, design, implementation, maintenance, and evaluation. Systems analysts use interviews, questionnaires, observation, and document review to gather requirements. Feasibility examines technical, economic, legal, operational, and schedule factors. DFDs use four symbols to show data movement. Four changeover methods exist: direct, parallel, phased, and pilot—each suited to different risk levels and budgets. Implementation includes testing, training, and documentation. Maintenance keeps systems running efficiently. Always apply concepts to the Caribbean organizational context provided in exam questions.