This topic covers how a computer system is planned, built, introduced and judged. You meet it in case-study questions where a small organisation wants to replace a paper process, and you must show you can reason about that organisation, not just recite stages.
The lessons here take one stage at a time: finding out what is needed, collecting data, designing an input form, choosing how to switch over, and checking the finished system against the original need.
What do you need to know first?
You should be comfortable with the basic parts of a computer system: input, processing, output and storage. The module on hardware, software and systems covers these. A little database vocabulary (field, record, table) helps for the form lesson, and you can try queries in the read-only SQL practice lab.
One worked example to orient you
An invented bookshop, Kedai Buku Mawar, tracks school-book orders in a notebook. Parents phone, staff write the name and book, and orders get lost.
| Stage | What happens in this case |
|---|---|
| Requirements | Record each order, show which orders are uncollected, keep names safely |
| Data collection | Watch staff for one day, ask staff three questions, read the notebook pages |
| Design | An order form with name, phone, book code and a collected tick box |
| Implementation | Start with one shelf of books, then add the rest once staff are confident |
| Evaluation | Check each requirement: is every order now recorded and are uncollected orders listed? |
Notice that every row mentions something specific to the shop. That habit is what separates a strong case answer from a generic one.
In what order should you study the lessons?
- Extract user requirements from a case: everything later depends on knowing what the system must do.
- Choose a data-collection method: this is how you find out what is needed in the first place.
- Design an input form: the first concrete design product, with validation and layout choices.
- Compare direct and phased implementation: how the new system replaces the old one, and the risks of each way.
- Evaluate a system against its original requirements: the stage that closes the loop and reuses lesson one.
Finish with the mixed practice set, then use the ICT practical task and evidence checker to organise your own notes.
What are the common traps?
- Describing a stage in general terms instead of using the detail in the case.
- Mixing up the stages, for example putting “ask users what they need” under evaluation.
- Naming a product or brand instead of describing the feature needed.
- Writing “it is faster” without saying faster at what, for whom, and how you would know.
- Treating a form as decoration. Every field needs a type and a check.
How should you use the practice set?
Attempt each question on paper first, then open the answer. When you lose a mark, note the stage involved and return to the matching lesson. The mistake log is a simple way to keep these notes.
Case-study reasoning improves quickly with feedback on your own sentences. That is the situation where online one-to-one ICT tuition from our team of teachers can help, and the next related module is safety, security and effects.