System life cycle
Learn the core concepts and decision-making in Cambridge 9626 Topic 16, then practise recall, application and transfer with fictional scenarios.
Section Paper 3 · Advanced Theory · 1 hour 45 minutes · 70 marks · 25% A Level
Exam scope and assessment notes
This is original StudyForA teaching and fictional practice based on Cambridge syllabus outcomes, not copied syllabus text, an official question, a required software brand or a Cambridge mark scheme. Practical software tasks here are planning and reasoning exercises; StudyForA does not inspect files created in spreadsheet, database, graphics, audio/video or animation software, simulate the practical exam environment, award official marks or predict a grade. Follow the software and file-format requirements issued by your centre for your exam year.
Before you begin
- Check whether your route is AS Level (Topics 1–11) or full A Level (Topics 1–21).
Work on paper. Try each question before revealing help, and explain why your method works.
Quick readiness check
Before Topic 16: system life cycle
What you will learn
- Explain system stages and feedback between them
- Research needs with questionnaires, interviews, observation and documents; write user, system and design specifications
- Model data/processes with context/level 1/level 2 DFDs, system flowcharts, forms and reports
- Plan development/testing, test data, alpha/beta, white/black-box, usability, implementation, documentation, evaluation, development methods, prototyping and maintenance
Analysis and design convert a need into a buildable plan
A system combines components, such as hardware and software, to achieve a purpose. Analysis researches the current situation through questionnaires, interviews, observation and document analysis. A user requirements specification describes what users need; a system specification sets system behaviour and constraints; a design specification explains how it will be built. Data-flow diagrams show movement and processing of data; system flowcharts show control and processing steps.
Test, implement, evaluate and maintain iteratively
A test plan records feature, test data, expected result and actual result. Normal, boundary and invalid data reveal different faults; alpha testing is internal, beta testing uses selected external users; white-box tests inspect structure and black-box tests check inputs/outputs. Implementation may be direct, parallel, pilot or phased. Compare agile, iterative, incremental, RAD and waterfall to the project's change and risk. Prototypes can be evolutionary, incremental, throwaway or rapid; maintenance can be perfective, adaptive, preventive or corrective.
Sources for this lesson
Pause and explain
Which approach best demonstrates secure, reliable IT practice in system life cycle?
Worked example
A library replaces a paper-booking process. Outline a suitable analysis and testing approach.
Show the worked solution
- Interview users and observe the current process; inspect booking records.
- Define user, system and design specifications with flow diagrams/forms.
- Use test plans with normal, boundary and invalid records; pilot before full rollout.
Answer Interview staff and learners, observe booking and cancellation, and inspect existing forms. Document user needs and system constraints, then design data flows, validation and reports. Test with normal bookings, dates at the allowed limits, duplicate entries and invalid IDs. A pilot can expose real-use problems before broader implementation.
Try a topic test
Choose Easy, Normal or Difficult. Save your answers and open worked review after finishing.
Test this topic →From guided practice to a new situation
Write your answer and reasoning first. Use a hint only if you are stuck. The model solution is for self-checking; your written work is not automatically marked.
A student records their date of birth using an online form. Give one normal, one boundary and one erroneous test value.
Give me a hint
The tests should exercise expected input, a permitted edge and a value that should be rejected.
Compare my reasoning
- Choose a plausible date within the accepted range.
- Choose the minimum or maximum permitted date.
- Choose an impossible or disallowed date and state expected behaviour.
For example, normal: 15/06/2008; boundary: the earliest permitted date for the learner group; erroneous: 31/02/2008. The test plan should state expected acceptance/rejection and actual result. The precise boundary must come from the system requirement, not be invented by the tester.
Look for these in your work
- Distinguishes test categories
- Uses a requirement-defined boundary
- States expected results
A team is building a changing system with frequent user feedback. Compare iterative development with waterfall.
Give me a hint
Focus on feedback timing and the cost of changing earlier decisions.
Compare my reasoning
- Explain how iterative work delivers reviewed cycles.
- Explain waterfall's more sequential phases.
- Match the method to uncertainty, governance and user availability.
Iterative development builds and reviews successive versions, so feedback can refine requirements and reduce the risk of discovering a mismatch only at the end. Waterfall completes defined stages in sequence and can suit stable requirements or strict sign-offs, but late changes may be costly. A team should choose according to requirement uncertainty, assurance needs and stakeholder availability.
Look for these in your work
- Accurately contrasts cycles
- Connects to feedback
- Qualifies the recommendation
A new system passes functional tests but users cannot complete the main task without help. Which evaluation evidence is needed?
Give me a hint
Correct outputs do not prove that a system meets usability needs.
Compare my reasoning
- Observe representative users attempting the task.
- Record completion, time, errors and assistance required.
- Compare results with user requirements and revise/test again.
Run usability tests with representative users and realistic tasks. Record completion rate, time, errors and assistance, then compare with the user requirements. Ask for feedback, fix the main barriers and repeat the test. Functional correctness is necessary, but it does not establish that the system is usable.
Look for these in your work
- Uses representative users
- Measures observable outcomes
- Connects evaluation to requirements
Common mistakes
- Confusing user requirements with design specification
- Testing only expected inputs
- Choosing a development method without considering change and feedback
What can you explain now?
A student records their date of birth using an online form. Give one normal, one boundary and one erroneous test value.
Compare with the explanation
For example, normal: 15/06/2008; boundary: the earliest permitted date for the learner group; erroneous: 31/02/2008. The test plan should state expected acceptance/rejection and actual result. The precise boundary must come from the system requirement, not be invented by the tester.
The tests should exercise expected input, a permitted edge and a value that should be rejected.
After trying it yourself, choose your next review. This is your self-assessment.
Your review choice appears on Today. Sign in to sync it across devices.
Make it stick
How do normal, boundary and erroneous test data differ?
If you needed the solution, close it and solve the problem again from a blank page. A correct answer is stronger when you can explain the reason for each step.