The systems life cycle
Move from investigation to evaluation in a system project, using evidence, clear requirements and tests at each stage.
Exam scope and assessment notes
Cambridge IGCSE Information and Communication Technology 0983, for exams in 2026, 2027 and 2028. Examples, datasets and practice are original StudyForA material; they are not Cambridge questions, source files, mark schemes or grades. Practical lessons teach transferable operations, but learners must perform them in locally available office and web-authoring software and inspect their own files. This site does not reproduce a Cambridge practical examination or award an official grade. The separate 2029 syllabus is not mapped here. Cambridge states that IGCSE 0983 has the same subject content as IGCSE 0417, with 9–1 grading. This StudyForA pathway maps the 2026–2028 syllabus only. This 9–1 graded qualification is available only in a limited number of administrative zones. Confirm that your centre can enter you for this code and exam series with Cambridge International. Cambridge has published a separate syllabus for 2029. StudyForA has not reconciled that version yet; this page supports exams in 2026, 2027 and 2028 only.
Before you begin
- No previous ICT course is assumed. Read each scenario carefully and justify a tool or method by connecting it to the task, user and constraints.
Work on paper. Try each question before revealing help, and explain why your method works.
Quick readiness check
Which research method lets an analyst see the current work as it happens?
What you will learn
- Use observation, interviews, questionnaires and document review to investigate a current system and establish user requirements.
- Specify hardware and software; design data structures, inputs, outputs and validation routines.
- Plan tests using normal, abnormal, extreme and appropriate live data, record outcomes and take remedial action.
- Compare direct, parallel, pilot and phased implementation; distinguish user from technical documentation and evaluate against requirements.
Find the real problem and design a testable solution
Analysis records the current inputs, processing, outputs and problems. Observation shows what users actually do; interviews allow probing; questionnaires reach more people but depend on question quality; existing documents reveal rules and records. Turn evidence into user and information requirements, then justify suitable hardware and software.
Design defines file/data structures (field names, data types, lengths and codes), input and output formats and validation. A presence check ensures a value is entered; a range check limits values; type, length, character, format and check-digit checks test different properties. Validation checks whether data follows rules; it does not prove the data is true.
Test, implement, document and evaluate
Test modules, functions and the complete system before implementation. Normal data should be accepted, abnormal data rejected or handled, and extreme data should test boundaries. Record the test data, expected result, actual result and remedial action. Live data may expose real conditions but must be handled securely and with permission.
Direct changeover is quick but risky; parallel running compares old and new systems but costs more; a pilot tests at a limited site; phased implementation introduces parts over time. Technical documentation supports maintenance; user documentation explains how to operate the solution. Evaluate efficiency, ease of use and suitability against original requirements and user feedback, then identify specific improvements.
Sources for this lesson
Pause and explain
A school cannot risk the new attendance system failing on its first morning. Which implementation method gives a small-scale trial first?
Worked example
A paper-based library loan system often loses due dates. Outline the analysis and one boundary test for a replacement system.
Show the worked solution
- Observe loans and interview library staff; inspect existing forms and identify users and current outputs.
- Specify the required inputs, loan rules, reports and equipment.
- Test an allowed maximum loan period and a value just outside that boundary, recording expected and actual results.
Answer First document the current loan steps and interview staff and borrowers to define required functions. For a rule allowing 1–28 days, test 14 days as normal, 29 days as abnormal and 28 days as an extreme boundary value; record whether each is accepted and correct the system if the result differs from the expected outcome.
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 clinic replaces a paper appointment book. Choose two analysis methods and state what each could reveal.
Give me a hint
Use methods that reveal both real behaviour and user explanations.
Compare my reasoning
- Observe staff making bookings to identify actual steps and delays.
- Interview staff or patients to explore needs and exceptions.
- Review appointment forms to identify existing data fields and rules.
Observe bookings to see the real sequence and common delays; interview staff or patients to discover pain points and requirements. Reviewing current forms can identify fields and rules. Combining evidence is stronger than assuming a written procedure matches everyday practice.
Look for these in your work
- Names methods and the evidence they provide
- Links findings to requirements
Design normal, abnormal and extreme test data for a booking form that accepts dates from 1 to 31 March.
Give me a hint
Choose one ordinary valid date, one invalid value and one valid boundary.
Compare my reasoning
- Use a mid-range date as a normal test.
- Use 32 March or an incorrectly formatted date as abnormal data.
- Use 1 March and 31 March to test both valid boundaries.
Normal: 15 March in the required date format. Abnormal: 32 March or 15/13 if the form requires day/month. Extreme: 1 March and 31 March, the lower and upper valid boundary. Record expected and actual results; invalid dates should be rejected or corrected clearly.
Look for these in your work
- Tests valid, invalid and boundary cases
- Explains expected handling
A new payroll system must be introduced without risking missed payments. Compare parallel and phased implementation, then recommend a method.
Give me a hint
Consider checking, cost, scope and when the old process remains available.
Compare my reasoning
- Parallel running compares old and new outputs for a period.
- Phased implementation moves selected functions or groups over in stages.
- Choose based on the need to detect errors, time, cost and how easily payroll can be divided.
Parallel running offers direct comparison and a fallback but duplicates work and costs staff time. Phased implementation limits the number of changes at once but may create temporary integration problems. For payroll, parallel checks for at least one verified cycle may be justified if privacy and workload are managed; the exact choice depends on system size and risk.
Look for these in your work
- Explains both methods
- Makes a justified recommendation with a trade-off
Common mistakes
- Calling validation a guarantee that input is accurate
- Testing only normal cases and not recording actual results
- Choosing a changeover method without weighing disruption and risk
What can you explain now?
What is the difference between a range check and verification?
Compare with the explanation
A range check tests whether a value falls within allowed limits; verification compares input with its source.
Validation rules test acceptable format or limits, while verification checks that data matches the original source.
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
Reconstruct the project stages from analysis through evaluation and give one concrete output or check for each stage.
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.