What you'll learn
The Systems Life Cycle forms a critical component of the CIE IGCSE Information and Communication Technology syllabus, typically accounting for 6-10 marks across Paper 1 and Paper 2. This topic examines the structured approach organisations use to develop, implement and maintain new computer systems, from initial problem identification through to final evaluation and maintenance.
Key terms and definitions
Systems Life Cycle — a structured methodology that breaks down the development of a new computer system into five distinct stages: Analysis, Design, Development and Testing, Implementation, and Maintenance/Review
Analysis — the first stage where the current system is investigated, problems are identified, user requirements are gathered and a feasibility study determines whether the project should proceed
Feasibility study — an assessment that examines whether a proposed system is technically possible, economically viable, legally compliant and operationally practical
Design — the stage where system specifications are created, including data structures, input/output designs, validation rules and processing requirements
Implementation — the stage where the new system is installed and made operational, involving data migration, user training and system changeover
Changeover methods — the different approaches used to transition from an old system to a new one: direct, parallel, phased and pilot
Alpha testing — internal testing conducted by the development team within the organisation before the software is released to external users
Beta testing — external testing conducted by end-users in real-world conditions to identify remaining errors and gather feedback
Core concepts
Stage 1: Analysis
The analysis stage investigates the current system to understand its problems and define requirements for the new system. This stage is crucial because errors made here propagate through all subsequent stages, making them expensive to fix later.
Methods of fact-finding during analysis:
- Observation — watching employees perform their current tasks to understand workflows and identify inefficiencies
- Interviews — one-to-one discussions with stakeholders to gather detailed requirements and opinions
- Questionnaires — distributed to large numbers of users to collect quantitative data about system performance
- Examination of existing documents — reviewing current forms, reports and paperwork to understand data flows
- Examination of existing files — analysing current data structures and storage methods
Outputs from the analysis stage:
- A clear statement of the problem with the current system
- A detailed list of user requirements (what the new system must do)
- A feasibility report covering technical, economic, legal and operational factors
- Data flow diagrams showing how information moves through the current system
- A decision on whether to proceed with system development
The feasibility study examines four key areas. Technical feasibility determines whether the required technology exists and whether staff have the expertise to implement it. Economic feasibility calculates whether benefits justify costs through cost-benefit analysis. Legal feasibility ensures compliance with data protection laws, copyright and accessibility regulations. Operational feasibility assesses whether the system will work within the organisation's culture and whether users will accept it.
Stage 2: Design
Design creates the blueprint for the new system. Detailed specifications are produced that programmers and developers will use to build the system.
Key design documents include:
- Data capture forms — designed input documents (paper or screen-based) showing field names, data types and validation rules
- Screen layouts — mockups of user interfaces showing menus, buttons, text boxes and navigation paths
- Report layouts — designs for printed or on-screen outputs including headers, footers and data fields
- Data structures — database table designs showing field names, data types, field lengths and validation rules
- File organisation — decisions about file storage formats and access methods
- Validation rules — specifications for range checks, format checks, length checks, presence checks, check digits and lookup lists
- System flowcharts — diagrams showing program logic and processing sequences
- Test plans — tables documenting test data (normal, abnormal and extreme), expected outcomes and reasons for each test
Key validation types specified in design:
- Range check — ensures data falls between specified upper and lower limits (e.g. exam marks 0-100)
- Format check — ensures data matches a required pattern (e.g. email contains @ symbol)
- Length check — ensures correct number of characters (e.g. 11-digit phone number)
- Presence check — ensures essential fields are not left blank
- Check digit — calculates additional digit to verify accuracy of long numbers like barcodes
- Lookup list — restricts input to values from a predefined list (e.g. gender: M/F/Other)
Stage 3: Development and Testing
Development involves creating the actual system based on design specifications. Programmers write code, databases are constructed, interfaces are built and all components are integrated.
Alpha testing occurs first. The development team tests the system in-house using the test plan created during design. Testers systematically work through each function, entering normal, abnormal and extreme test data to identify bugs, logic errors and system crashes. Testing occurs in a controlled environment that simulates real-world conditions but does not risk live data.
Beta testing follows alpha testing. A selected group of end-users tests the system in their actual working environment. Beta testers use real data and genuine workflows, identifying problems that developers might not anticipate. Their feedback reveals usability issues, performance bottlenecks and incompatibilities with existing hardware or software.
Types of test data:
- Normal (typical) data — values the system should accept and process correctly (e.g. age = 25)
- Abnormal (erroneous) data — invalid values the system should reject with error messages (e.g. age = -5 or age = cat)
- Extreme (boundary) data — values at the limits of acceptable ranges that test boundaries (e.g. if valid age is 18-65, test with 18, 65, 17 and 66)
Stage 4: Implementation
Implementation transitions the organisation from the old system to the new one. This stage involves data migration (converting and transferring existing data to the new system), user training (teaching staff how to operate the new system) and system changeover (switching operations from old to new).
The four changeover methods:
Direct changeover — the old system is stopped completely and the new system starts immediately on a specific date. This is the fastest and cheapest method but carries the highest risk. If the new system fails, the organisation has no backup system, potentially causing catastrophic data loss or business interruption. Suitable only when the old system is completely unusable or when a new business starts with no existing system.
Parallel running — both old and new systems operate simultaneously for a period (typically weeks or months). Staff enter data into both systems and compare outputs to verify the new system works correctly. This is the safest method because if the new system fails, the old system continues operating without disruption. However, it is the most expensive method, requiring double the work, hardware and staff time. Used for critical systems like banking or hospital records where failure is unacceptable.
Phased implementation — the new system is introduced gradually, one module or department at a time. For example, a school might implement a new management system in the library first, then the office, then classrooms. This spreads cost and training over time, allowing problems to be identified and fixed before the next phase. Less risky than direct changeover but takes longer to complete full implementation.
Pilot implementation — the new system is introduced to one location or branch first as a trial. For example, a retail chain might introduce new point-of-sale software in one shop before rolling it out nationally. If successful, the system is then implemented across all locations. This tests the system in real conditions with limited risk exposure.
User documentation (manuals, help files, video tutorials) and training (hands-on sessions, online courses, help desk support) ensure staff can use the new system effectively.
Stage 5: Maintenance and Review
Once operational, systems require ongoing maintenance to remain effective. Three types of maintenance occur:
Corrective maintenance — fixing bugs and errors that were not identified during testing but emerge during live use
Adaptive maintenance — updating the system to work with new hardware, operating systems or legal requirements (e.g. changes to tax rates or data protection laws)
Perfective maintenance — enhancing the system by adding new features or improving performance based on user feedback
Review and evaluation involves comparing the system against the original requirements specified during analysis. Key questions include: Does the system solve the original problem? Have all user requirements been met? Does the system operate within budget? Is the system reliable and efficient? Are users satisfied?
Eventually, maintenance becomes too costly or the system can no longer meet organisational needs. At this point, the cycle begins again with a new analysis stage.
Worked examples
Example 1: Analysis methods [6 marks]
A library wants to replace its manual book-lending system with a computerised database system. Describe three suitable methods the systems analyst could use to gather information during the analysis stage.
Mark scheme answer:
Observation [1 mark] — The analyst watches library staff processing book loans and returns [1 mark]. This identifies current procedures, workflow bottlenecks and time taken for each task [1 mark].
Interviews [1 mark] — The analyst conducts face-to-face discussions with librarians and library users [1 mark]. This gathers detailed opinions about problems with the current system and requirements for the new system [1 mark].
Questionnaires [1 mark] — The analyst distributes surveys to all library members [1 mark]. This collects quantitative data from a large sample about usage patterns, preferred features and satisfaction levels [1 mark].
[Award 2 marks per method: 1 for naming, 1 for appropriate description in context]
Example 2: Changeover methods [8 marks]
A hospital is implementing a new patient records system to replace the current paper-based system. Discuss the suitability of direct changeover and parallel running for this implementation.
Mark scheme answer:
Direct changeover means the hospital would stop using paper records completely and switch to the computer system on a specific date [1 mark].
Advantages: Implementation would be fast [1 mark] and costs would be lower as only one system operates [1 mark].
Disadvantages: If the new system crashes or contains errors, patient records would be unavailable [1 mark], potentially endangering patient safety [1 mark]. There is no backup system if problems occur [1 mark].
Parallel running means the hospital would maintain paper records while also entering data into the new computer system [1 mark].
Advantages: If the computer system fails, paper records remain available [1 mark], ensuring continuity of patient care [1 mark]. Outputs can be compared to verify accuracy [1 mark].
Disadvantages: Staff workload doubles as they complete both systems [1 mark], requiring additional time and resources [1 mark].
Conclusion: Parallel running is more suitable despite higher costs [1 mark] because patient safety is critical and the hospital cannot risk losing access to medical records [1 mark].
[Award marks for: definition of each method, advantages, disadvantages, justification in context. Maximum 8 marks]
Example 3: Test data [6 marks]
A website requires users to create a password between 8 and 15 characters long. Complete the test plan table below, providing one example of each type of test data and stating the expected outcome.
| Test data type | Example | Expected outcome |
|---|---|---|
| Normal | ||
| Extreme | ||
| Abnormal |
Mark scheme answer:
| Test data type | Example | Expected outcome |
|---|---|---|
| Normal [1 mark] | 10 characters e.g. "MyPass1234" [1 mark] | Accepted / Password created successfully [1 mark] |
| Extreme [1 mark] | 8 or 15 characters e.g. "Pass1234" or "MyPassword12345" [1 mark] | Accepted / At boundary limits [1 mark] |
| Abnormal [1 mark] | 7 or 16 characters e.g. "Pass123" or "MyPassword123456" [1 mark] | Rejected / Error message displayed [1 mark] |
[Award 1 mark for identifying type correctly, 1 mark for valid example, 1 mark for correct expected outcome]
Common mistakes and how to avoid them
Mistake: Confusing alpha and beta testing or stating they are the same thing. Correction: Alpha testing is internal testing by developers in controlled conditions; beta testing is external testing by end-users in real environments with live data.
Mistake: Describing implementation methods (direct, parallel, phased, pilot) without relating them to the specific context given in the question. Correction: Always justify which method is most suitable based on the scenario details — consider factors like system criticality, organisation size, available budget and acceptable risk level.
Mistake: Listing validation checks during the design stage without explaining what each check actually does. Correction: Define each validation type precisely — for example, "range check ensures the value entered falls between specified upper and lower limits" rather than just writing "range check".
Mistake: Providing only two types of test data when three are required (normal, abnormal, extreme). Correction: The question typically requires all three types. Extreme data tests boundaries of acceptable ranges; ensure you give values at the limits, not just within the valid range.
Mistake: Describing maintenance as "fixing problems" without distinguishing between corrective, adaptive and perfective maintenance. Correction: Learn the three distinct types. Corrective fixes bugs, adaptive updates for external changes (new laws, new hardware), perfective adds enhancements based on user requests.
Mistake: Writing that parallel running eliminates all risk. Correction: Parallel running reduces risk but creates disadvantages including doubled workload, increased costs, requirement for duplicate hardware and potential staff resistance due to additional work.
Exam technique for The Systems Life Cycle
Command word awareness: "Describe" questions (typically 4-6 marks) require detailed explanation of processes — name the method/stage AND explain what happens. "Discuss" questions (typically 8-10 marks) require balanced evaluation — present advantages AND disadvantages, then reach a justified conclusion relevant to the context.
Context is critical: Generic answers score poorly. When asked about changeover methods for a bank versus a small shop, tailor your answer to the specific scenario. Reference the organisation type, criticality of data and consequences of system failure mentioned in the question.
Structured answers for high-mark questions: Use the format — define the term, explain the process, give advantages, give disadvantages, provide a justified conclusion linked to the context. This structure ensures coverage of all mark scheme points.
Test data tables: When completing test data tables, ensure your examples clearly demonstrate the test type. For extreme data testing a range of 0-100, give exactly 0 and 100 (not 5 and 95). For abnormal data, choose values that clearly violate the rule (e.g. -10 and 150, or text when numbers are required).
Quick revision summary
The Systems Life Cycle consists of five stages: Analysis (investigating current systems using observation, interviews and questionnaires), Design (creating specifications including validation rules and test plans), Development and Testing (building the system then conducting alpha and beta testing), Implementation (transitioning via direct, parallel, phased or pilot changeover with user training), and Maintenance (corrective, adaptive and perfective updates). Each stage produces specific outputs documented by the systems analyst. Understanding which changeover method suits different scenarios and distinguishing between validation types are high-scoring exam topics.