What you'll learn
The systems life cycle is the series of stages followed when an organisation replaces an old system with a new ICT system: analysis, design, development and testing, implementation, documentation and evaluation. This guide concentrates on the first two stages, analysis and design, which carry the most marks. You will learn the fact-finding methods used to investigate a current system and their strengths and weaknesses, what goes into a requirements specification, how inputs, outputs and data structures are designed, and — very importantly — the difference between validation and verification, with every type of check you need to know.
Questions often give a scenario, such as a library, a hospital or a school replacing a paper system, and ask you to choose fact-finding methods, design validation for a field, or explain why a mistake was not caught. Precise use of terms is essential.
Key terms and definitions
Systems life cycle — The stages followed to develop and introduce a new system: analysis, design, development and testing, implementation, documentation and evaluation.
Analysis — Investigating the current system and identifying the requirements of the new one.
Fact-finding — Collecting information about the current system, using questionnaires, interviews, observation and examining documents.
Requirements specification — A list of what the new system must be able to do, agreed with the client.
Design — Planning inputs, outputs, processes, data structures, validation and testing for the new system.
Data flow diagram — A diagram showing how data moves between processes, data stores and people.
Validation — An automatic check that data entered is sensible and allowed.
Verification — Checking that data has been entered or copied accurately.
Test plan — A document setting out the tests to be carried out and the expected results.
Normal, boundary and erroneous data — Test data that is valid, at the edge of what is allowed, and invalid.
Core concepts
The stages of the life cycle
- Analysis — find out how the current system works, its problems, and what users need.
- Design — plan the new system in detail.
- Development and testing — build the system and test it against the test plan.
- Implementation — install the system and switch over from the old one (directly, in parallel, by pilot or in phases), and train staff.
- Documentation — produce user guides and technical documentation.
- Evaluation — compare the finished system with the requirements and gather user feedback.
The stages form a cycle because evaluation often identifies improvements, which start a new round of analysis.
Analysis: investigating the current system
The analyst must understand the current system — the data collected, the processes carried out, the outputs produced, and the problems — before designing anything new. They also identify hardware and software requirements so the new system can run and be budgeted for. Four fact-finding methods are used, usually in combination.
Questionnaires. The same written questions are given to many people.
- Advantages: many people can be reached quickly and cheaply; answers can be anonymous, so they may be more honest; results with closed questions are easy to analyse.
- Disadvantages: many may not be returned; questions may be misunderstood; there is no chance to ask follow-up questions; closed questions may miss important details.
Interviews. The analyst asks a user questions face to face.
- Advantages: the analyst can ask follow-up questions and explore answers in depth; body language and emphasis give extra information.
- Disadvantages: time-consuming and expensive, so only a few people can be interviewed; interviewees may say what they think the analyst wants to hear; answers are not anonymous.
Observation. The analyst watches users working with the current system.
- Advantages: shows what really happens, which may differ from what people say; first-hand, reliable information.
- Disadvantages: people may work differently when they know they are being watched; time-consuming; may miss tasks that happen only occasionally; privacy may be an issue, for example in a hospital.
Examining documents. The analyst studies existing forms, records and reports.
- Advantages: shows exactly what data is collected and what outputs are needed, which is essential for designing the new inputs and outputs.
- Disadvantages: documents may be out of date or incomplete and do not show how people actually use them.
For a large organisation, a sensible combination is questionnaires for everyone plus interviews with key users such as managers, supported by observation and document examination where helpful.
The requirements specification
The analysis produces a requirements specification: what the new system must do, its inputs and outputs, data to be stored, performance targets and any constraints such as budget. It is agreed with the client and later used in evaluation to judge whether the system succeeded. Poor analysis is a major reason systems fail: if requirements are wrong or missing, the error carries through design and development and is expensive to fix later.
Design
The design stage produces detailed plans for:
- Input forms and screens — clear labels, logical order, instructions, drop-down lists for fixed choices, and suitable field sizes. A well-designed form reduces data-entry errors.
- Outputs — screen layouts and printed reports designed around what users need to know, with suitable layout, level of detail and frequency.
- Data structures — file and database designs: field names, data types, field lengths and key fields.
- Processes — what the system will do with the data, often shown in flowcharts or data flow diagrams.
- Validation rules for each input.
- A test plan, including normal, boundary and erroneous test data with expected results.
Involving end-users in the design makes it more likely the system meets real needs and is accepted. A clear design specification gives developers a plan to follow and allows the finished system to be tested against it.
Validation checks
Validation is carried out automatically by the computer when data is entered. It rejects data that cannot be correct.
| Check | What it does | Example |
|---|---|---|
| Range check | Value is between a lower and upper limit | Percentage between 0 and 100 |
| Presence check | Field is not left blank | Surname must be entered |
| Type check | Data is the correct kind | Age must be a number |
| Length check | Data has an allowed number of characters | Password at least 8 characters |
| Format check | Data matches a pattern | Date in DD/MM/YYYY |
| Lookup check | Value is in a list of allowed values | Department code exists |
| Check digit | Extra digit calculated from the others detects errors | Barcodes, ISBNs |
| Consistency check | Related fields make sense together | End date after start date |
Validation cannot guarantee data is correct. It only checks that data is reasonable. If a clerk types an exam mark of 67 instead of 76, a range check of 0–100 will accept it, because 67 is allowed.
Verification
Verification checks that data has been copied or entered accurately from its source.
- Double entry: the data is typed twice and the computer compares the two versions; if they differ, the user re-enters it. Passwords are often verified this way.
- Visual check (proofreading): the user compares the data on screen with the original document.
Verification also has a limit: if the source document is wrong, copying it accurately still produces wrong data.
The two methods complement each other. Validation catches impossible data; verification catches copying errors.
Testing data
Test plans use three kinds of data. For a field accepting marks from 0 to 100:
- Normal data — for example 55 — should be accepted.
- Boundary data — 0 and 100 (and just outside, such as −1 and 101) — test the edges of the rule.
- Erroneous data — "abc" or 150 — should be rejected with a helpful error message.
Implementation methods
Although this topic focuses on analysis and design, you should know the four ways of changing over to a new system, because design decisions affect them:
- Direct changeover — the old system stops and the new one starts immediately. It is quick and cheap, but if the new system fails there is nothing to fall back on.
- Parallel running — old and new systems run side by side for a time and results are compared. It is the safest, but expensive and doubles staff workload.
- Pilot — the new system is introduced in one branch or department first. Problems affect only part of the organisation and staff there can train others, but it takes longer to roll out.
- Phased — the new system is introduced one part at a time. Each part can be tested before the next, but the whole changeover takes longer and old and new parts must work together.
For a hospital's patient records, parallel running or a pilot is usually chosen because failure would be serious; for a small shop's new till system, direct changeover may be acceptable.
Worked examples
Example 1: Choosing fact-finding methods
An analyst must investigate a system used by 2,000 staff across several sites. Recommend fact-finding methods. (3 marks)
Answer: Questionnaires for all staff, as they reach many people quickly and cheaply (1). Interviews with key users such as managers, to explore problems and requirements in depth (1). Examining existing documents, to see what data is collected and output (1).
Example 2: Designing validation
Suggest suitable validation for a date of birth field on a secondary school's admissions form.
Answer: A format check so the date is entered as DD/MM/YYYY; a range check so the date is not in the future and gives a plausible age for a pupil; and a presence check so the field cannot be left blank.
Example 3: Explaining an undetected error
A shop assistant enters a customer's age as 15 instead of 51. Explain why validation did not detect this.
Answer: 15 is a sensible, allowed age, so it passed the range and type checks. Validation only checks that data is reasonable, not that it is true. Double-entry verification or a visual check against the source could have caught the error.
Example 4: Test data
A field accepts quantities from 1 to 50. Give one normal, one boundary and one erroneous test value.
Answer: Normal: 25. Boundary: 50 (or 1). Erroneous: 75 or "ten".
Common mistakes and how to avoid them
- Mixing up validation and verification. Validation = sensible; verification = accurately copied.
- Saying validation "makes data correct". It only rejects impossible or unreasonable data.
- Listing fact-finding methods without justification. Link each to the scenario's size and needs.
- Describing a check vaguely. "Checks the data is right" earns nothing; "checks the value is between 0 and 100" earns the mark.
- Forgetting boundary data in test plans.
Exam technique for "The Systems Life Cycle: Analysis and Design"
- When asked to describe a check, give what it checks plus a specific example linked to the scenario's field.
- For method choices, give an advantage linked to the scenario: "interviews, because the three managers can explain the problems in depth".
- In "explain why" questions about errors, name the limitation precisely (validation only checks reasonableness; verification relies on the source).
- Learn the order of the stages so you can place activities correctly.
Quick revision summary
- Stages: analysis → design → development and testing → implementation → documentation → evaluation.
- Fact-finding: questionnaires (many people, no follow-up), interviews (depth, time), observation (real behaviour, people may change), documents (data and outputs).
- The requirements specification is agreed with the client and used to evaluate success.
- Design covers inputs, outputs, data structures, processes, validation and test plans.
- Validation checks: range, presence, type, length, format, lookup, check digit, consistency.
- Verification: double entry and visual checks.
- Neither guarantees correct data; use both, and test with normal, boundary and erroneous data.