Cambridge IGCSE ICTThe Systems Life Cycle
The systems life cycle is the process followed when an existing computer system is replaced or improved. It begins by analysing the current system and continues through design, development/testing, implementation, documentation and evaluation.
AnalysisDesignDevelopment & testingImplementationDocumentationEvaluation
A system may need replacing because existing equipment has become obsolete, new hardware can improve efficiency and reliability, the organisation has expanded, or changes in laws or taxes require changes to software. A systems analyst studies the existing system and recommends improvements.
Analysis → Design → Development & Testing → Implementation → Documentation → Evaluation
Development and testing may reveal problems that require parts of the system to be redesigned, so the process does not always move in only one direction.
Jump to a subtopic
Use these links to move directly to each stage of the systems life cycle.
7.1 AnalysisResearch methods, requirements, inputs/outputs and system specification.
7.2 DesignFiles, fields, data types, validation, verification, forms and outputs.
7.3 Development and testingModules, test plans, normal/extreme/abnormal data and live data.
7.4 ImplementationDirect, parallel, pilot and phased changeover.
7.5 DocumentationTechnical documentation and user documentation.
7.6 EvaluationChecking whether the new system meets the original requirements.
7.1 Analysis
The analysis stage investigates the existing system and determines what the new system needs to do.
What the analyst needs to find out
how the present system works
inputs and outputs
processing carried out
problems with the current system
user requirements
information requirements
hardware and software required for the new system
Researching the current system
Four methods are used:
Observation
The analyst watches employees using the existing system.
Advantage
allows the analyst to see how the system actually operates
Disadvantage
workers may behave differently because they know they are being watched
This change in behaviour is known as the Hawthorne effect.
Interviews
The analyst asks users questions face-to-face.
Advantages
follow-up questions can be asked
questions can be changed depending on the person's answers
detailed information can be obtained
Disadvantages
time-consuming
interviewees may not always give completely honest answers
Questionnaires
Questions are given to users of the existing system.
Advantages
many people can take part
relatively inexpensive
users can remain anonymous
answers can be analysed quickly
Disadvantages
some people may not return them
follow-up questions cannot easily be asked
Examining existing documents
The analyst examines items such as existing files, operating instructions, training manuals and accounts. This can help identify storage needs, input/output requirements and how the current system operates.
Advantage
information may be discovered that other methods do not reveal
Disadvantage
examining many documents can take a long time
Inputs, outputs and processing
Inputs
Data entering the system.
Processing
What the computer does with the data.
Outputs
Information produced by the system.
Storage
Where the data needs to be stored.
The analyst also looks for problems such as bottlenecks and areas where errors may occur.
User and information requirements
User requirements
User requirements describe what users expect the new system to do.
are written for the customer/business managers
use natural language
contain little technical jargon
help confirm that the proposed system meets the customer's needs
Information requirements
These identify the information needed by the organisation. They mainly consider:
what? – what data is needed
when? – when the data/information is needed
The analyst then develops a functional requirements specification explaining how the system will be developed and implemented.
System specification
The analyst decides what hardware and software the new system requires.
Hardware considerations
barcode readers
scanners
touch screens
monitors
printers
speakers
storage devices
The hardware chosen should match the organisation's needs.
Software considerations
Off-the-shelf software
already available
saves development time and cost
commonly used, so less training may be required
Bespoke software
specially created for the organisation
closely matches its requirements
takes more time and money to develop
Storage requirements such as capacity, speed and type of access also need to be considered.
7.2 Design
Once analysis is complete, the new system is designed.
The design stage includes
file and data structuresinput formatsdata capture formsoutput formatsscreen/report layoutsvalidation routines
File structures
A file contains records, and records contain fields.
Example record
| Product code | Year | Description | Price |
|---|
| T4131618 | 2022 | Digital camera | $405 |
This is one record, while product code, year, description and price are fields. One field should uniquely identify each record. This is called the primary key.
When designing a field, the analyst considers:
field name
field length
data type
whether coding is used
whether the field is a primary key
Data types
The main data types in the chapter are:
| Data type | Meaning | Example |
|---|
| Alphanumeric | Letters and/or numbers | A345FF |
| Character | One character | X |
| Text | String of characters | John Smith |
| Boolean | Two logical choices | Yes/No |
| Integer | Whole number | 234 |
| Decimal/real | Number containing decimals | 25.54 |
| Currency | Monetary value | $24.55 |
| Date/time | Dates or times | 14/05/2020 |
A telephone number should not normally be stored as numeric data simply because it contains numbers; it is not used for calculations.
Validation routines
Validation automatically checks whether data entered into a computer satisfies certain rules. It checks whether data is reasonable/acceptable, not whether it is actually correct.
Range check
Checks whether a value lies between specified limits.
Example: Temperature must be between 10°C and 50°C.
Type/character check
Checks that the correct type of data has been entered.
Example: A person's height should contain numbers rather than letters.
Length check
Checks that the correct number of characters has been entered.
Example: A password must contain exactly eight characters.
Format check
Checks that data follows the required pattern.
Example: dd/mm/yyyy
Presence check
Checks that a required field has not been left empty.
Check digit
An extra digit calculated from the other digits in a code. It can help detect errors such as:
digits entered incorrectly
digits transposed
missing or extra digits
Important exam point: Validation does NOT prove that data is correct. For example, an age of 35 may pass a range check even if the person's real age is 25.
Verification and double entry
Verification
Verification checks that data entered or copied into a computer matches the original source. It helps detect data-entry errors, but it does not prove that the original source data itself is correct.
Double entry
The same data is entered twice and the computer compares the two entries. If both entries match, the data is accepted. If they do not match, the user must re-enter or correct the data.
Example: entering an email address twice.
Validation vs verification
| Validation | Verification |
|---|
| Validation: checks whether data is reasonable/acceptable and follows the required rules. | Verification: checks whether data has been entered or copied accurately from the original source. |
Easy way to remember:
Validation = “Is the data acceptable?”
Verification = “Was the data copied correctly?”
Input formats – data capture forms
A data capture form is used to collect data before or while it is entered into a computer. Forms can be paper-based or computer-based/electronic.
Paper-based forms
A well-designed paper form should:
have a clear heading
clearly show where answers should be written
provide enough space
use clear fonts
use tick boxes where appropriate
use character boxes for certain data
Computer-based forms
These may use:
text boxes
drop-down lists
radio buttons
tick boxes
on-screen help
automatic validation
double-entry boxes for important data such as email addresses
control buttons such as Save, Next and Clear
Output formats
Outputs also need to be carefully designed.
Screen output should:
use suitable field sizes
give clear instructions
make good use of the screen
use readable fonts and colours
Printed reports should consider:
headers and footers
page layout
colours
information to be displayed
Database reports often display selected information in a clear table.
7.3 Development and testing
After the system has been designed, it is created and thoroughly tested.
Testing checks areas such as
file structuresdata structuresinput methodsoutput formatsvalidation rulesverification methodsuser interfaces
Module testing
Software is often divided into smaller parts called modules.
Developed → Tested → Errors corrected → Tested again
Once the individual modules work correctly, they are combined and the whole system is tested. Even if individual modules work correctly, problems may occur when they are combined.
Test plan
A test plan should include:
tests to be carried out
test data
type of test data
expected result
actual result
action needed if the result is wrong
Types of test data
Normal data
Valid data that should be accepted.
Example: if a month must be 1–12, 7 is normal data.
Extreme data
Valid data at the limits of the acceptable range.
For months: 1 and 12.
Abnormal data
Invalid data that should be rejected.
Examples: 0, 13, July, 3.5 if the system expects a whole-number month between 1 and 12.
Easy way to remember
| Test data | Meaning |
|---|
| Normal | Valid ordinary value |
| Extreme | Valid boundary value |
| Abnormal | Invalid value |
Live data
After testing is complete, live data is used. Live data has known outcomes. It is entered into the new system and its results are compared with results produced by the existing system.
If the results do not match, the system may need to be modified and tested again.
7.4 Implementation
Implementation is the stage where the tested system is introduced into the organisation.
Before changeover, existing data may need to be transferred by:
manually keying data
scanning documents
transferring electronic files
Staff also need to be trained. There are four changeover methods.
Direct changeover
The old system is stopped and the new system starts immediately.
Advantage
quick and relatively inexpensive
Disadvantage
if the new system fails, the old system is no longer available as backup
Parallel running
The old and new systems operate together for a period of time.
Advantage
old system remains available if the new system fails
Disadvantage
expensive and time-consuming because both systems have to be operated
Pilot implementation
The new system is first introduced in one branch or part of the organisation. If successful, it is introduced elsewhere.
Advantage
problems only affect the pilot location
Disadvantage
the entire organisation cannot immediately benefit from the new system
Phased implementation
The new system is introduced one part at a time. When one part works correctly, the next part is introduced.
Advantage
a failure only affects the latest part being introduced
Disadvantage
can take a long time
Quick comparison
| Method | How it works | Main benefit | Main risk/problem |
|---|
| Direct | Immediate replacement | Fast | High risk |
| Parallel | Both run together | Safest backup | Expensive |
| Pilot | One location first | Limits impact of failure | Slower full introduction |
| Phased | Introduced in stages | Problems affect one stage | Time-consuming |
7.5 Documentation
Documentation is produced for technical staff who may maintain or modify the system and for users who need to operate the system.
Technical documentation
Technical documentation is mainly for programmers and systems analysts. It may contain:
program code
programming language used
algorithms/flowcharts
file structures
hardware/software requirements
validation rules
known bugs
test results
User documentation
User documentation helps the end-user operate the system. It may explain:
how to install/load the software
how to save files
how to search or sort data
how to print
how to add or edit records
how to log in and out
troubleshooting and FAQs
meaning of error messages
Technical vs user documentation
| Technical documentation | User documentation |
|---|
| For programmers/analysts | For end-users |
| Program code | How to operate software |
| Algorithms | Tutorials |
| Validation rules | How to save/search/print |
| File structures | Troubleshooting |
7.6 Evaluation
After the new system has been implemented, it must be evaluated.
Evaluation checks whether the new system actually solves the original problem and meets the requirements identified during analysis.
The organisation may:
compare the new system with the original requirements
identify limitations
identify improvements
ask users for feedback
compare results from the old and new systems
compare how long tasks take
observe users
use interviews and questionnaires
The main questions are:
Is the new system more efficient?
Is it easy to use?
Is it suitable for the task?
Evaluation may show that hardware or software needs updating because of:
user feedbackorganisational changesnew technologychanges in legislation
Chapter 7 revision checklist
Students should be especially confident with:
the six stages of the systems life cycle
observation, interviews, questionnaires and examining documents
the Hawthorne effect
user and information requirements
records, fields and primary keys
common data types
validation and the different validation checks
verification, double entry and the difference between validation and verification
paper-based and electronic data capture forms
normal, abnormal and extreme test data
live data
the four implementation methods: direct, parallel, pilot and phased
differences between technical and user documentation
what happens during evaluation