01 | FOLLOW ONE SMALL TASK

You type two numbers into a calculator, press the add button and see a result. Something entered the system, something happened to it, and something came out. That simple journey gives us three useful ideas: input, process and output.

Now imagine a school-club booking program. It must remember accepted bookings tomorrow as well as display a message today. This introduces a fourth idea: storage.

These ideas help us analyse a system without first knowing how to code it. Instead of saying “the program handles bookings”, we can explain what data it receives, what it does with that data, what results it produces and what must be kept.

We will build each idea from familiar examples, then combine them in the booking system. The important skill is identifying the role of information in a particular task.

02 | INPUT: WHAT DOES THE SYSTEM RECEIVE?

Input is data supplied to a system for use. In the calculator example, the numbers you enter are inputs. In a booking system, a requested student identifier is input.

Data can arrive in different ways. A person can type it, a barcode scanner can read it, a sensor can measure it, or another system can send it electronically. Input is not limited to a keyboard.

Distinguish the data from the device. “Student identifier S104” describes the input data. “Keyboard” describes a device that can enter it. If a question asks what the booking program needs to receive, naming a keyboard alone does not tell us what information the program requires.

A user’s action can also supply a choice, such as selecting “return book” rather than “borrow book”. The program needs both the relevant data and enough information to know which task has been requested.

03 | BE SPECIFIC ABOUT THE INPUTS

Suppose a canteen system calculates an order total. “Customer details” is too broad to explain that calculation. The system needs the selected items, how many of each item are ordered and their prices.

The customer may enter item choices and quantities, while prices are retrieved from stored records. Prices still supply data for the calculation, but they are not necessarily new values typed by the customer.

For the club checker, the new request supplies a student identifier. Existing booked identifiers and capacity may already be stored in the system. Staff might enter capacity when setting up a session rather than entering it for every booking.

Always read the scenario carefully. Identify what is entered now, what is already available and where each value comes from. This avoids assuming that every piece of data must be typed during every task.

04 | PROCESS: WHAT HAPPENS TO THE DATA?

A process is an operation performed on data. It can calculate, compare, search, check, sort or update information.

In a calculator, adding two numbers is processing. In a club system, comparing a requested identifier with existing bookings is processing. Calculating how many places remain is also processing.

Processing does not always change the input. Searching for S104 can produce a found/not-found result without altering any identifiers. A comparison can lead to a decision about which action to take.

Be precise. “Process the booking” hides the important work. “Check whether the identifier is already booked and whether the booking count is below capacity” explains the operations that determine acceptance.

A program implements these operations using instructions. At the analysis stage, you can describe the operations clearly in ordinary language before deciding exactly how the instructions will be written.

05 | WORK THROUGH A CALCULATION

A canteen order contains two sandwiches priced at 4 units each and one drink priced at 2 units. The quantities are 2 and 1. The prices are 4 and 2.

The system calculates each item cost by multiplying its price by its quantity: 4 × 2 = 8 for the sandwiches and 2 × 1 = 2 for the drink. It then adds those costs to obtain the total: 8 + 2 = 10.

The input values and total are related, but they have different roles. The prices and quantities are data used by processing. Multiplying and adding are the processes. Showing “Total: 10” on the screen is output.

If the system saves the completed order for later reporting, that introduces storage as well. Calculating a total does not automatically mean that the order has been saved.

06 | OUTPUT: WHAT DOES THE SYSTEM PRODUCE?

Output is information or a result produced by a system. It could be a displayed total, a printed receipt, a sound, a message sent to another system or a control signal sent to an actuator.

In the club example, output can include “Booking accepted”, “Already booked” or “Club full”. Showing the number of remaining places is another output.

Again, distinguish the result from the device. “Screen” names an output device. “A rejection message explaining that the session is full” describes the information output by the program.

Output helps a user understand what happened. If the program rejects a request but produces no message, staff may think nothing happened and try again. A clear output connects the internal decision to the person using the system.

However, a displayed success message is not proof that the underlying record was updated correctly. Testing needs to check the data changes as well as the message.

07 | STORAGE: WHAT NEEDS TO BE KEPT?

Storage retains data for later use. A booking system must keep accepted identifiers so that future requests can be checked against them. A library needs loan records to know which books have been borrowed.

During execution, a program can hold a working collection in memory. Ordinary working data in RAM is volatile, so it is not enough by itself to retain bookings after the program closes or loses power.

If the requirements say bookings must be available tomorrow, the program must save them using suitable persistent storage, such as a file or database on non-volatile storage. It must also retrieve them when needed.

“The program remembers it” is therefore incomplete. Explain which data is retained and for how long. You do not need to design a complete database in this lesson; you need to identify that persistent records are required.

Not every value needs permanent storage. A temporary remaining-place calculation can be recomputed from capacity and accepted bookings unless the requirements call for a historical snapshot.

08 | THE INFORMATION JOURNEY IS NOT ALWAYS A STRAIGHT LINE

A simple input → process → output model is a useful starting point, but many systems also read and update stored data during processing.

For a new booking, the program receives an identifier, retrieves existing bookings, checks the rules, updates the booking record if accepted and produces a message. A rejected request should not be added to the accepted-booking collection.

Reading storage supplies previously retained information to processing. Writing storage retains an update for future use. Both need to happen at the appropriate point in the task.

The diagram shows roles, not a rule that every system must save data after every output. A calculator can produce a result without keeping it permanently. A booking system needs retained records because its requirements include future use.

09 | A COMPLETE BOOKING EXAMPLE

The club has capacity 3. Its stored accepted identifiers are S104 and S205. A staff member enters S306.

Input: the new identifier S306. The program also uses capacity and the existing bookings retrieved from stored records.

Processes: check whether S306 is already present; count the current bookings; compare the count with capacity. S306 is new and only two places are taken, so acceptance is permitted. Add S306 and calculate 3 − 3 = 0 remaining places.

Output: show that the booking was accepted and that no places remain. Storage: retain the updated accepted identifiers S104, S205 and S306 for later requests.

Now a request from S407 arrives. The capacity check rejects it. The output says the club is full, and the accepted-booking storage remains unchanged. Different inputs and starting records can lead to different decisions.

10 | THE SAME DATA CAN HAVE DIFFERENT ROLES

Consider the identifier S306. It is input when staff enter it. It is used in processing during the duplicate check. It becomes stored data when an accepted booking is saved. It may appear in output when a booking list is displayed.

This is not a contradiction. Input, process, output and storage describe roles in a task, not permanent labels attached to every value.

Similarly, a file can be read to supply data to a calculation, and a new file can be written to retain the results. A value retrieved from storage can be input to a particular sub-system, even if nobody has just typed it.

Be clear about the boundary you are describing. For the complete booking system, distinguish the new request from existing stored records. For the capacity-check component, capacity and booking count are the data it receives.

If the scenario is unclear, explain your interpretation rather than forcing each item into one category without context.

11 | APPLY THE MODEL TO A LIBRARY LOAN

A librarian scans a book identifier and enters a member identifier. The system retrieves the book and member records.

It checks whether the book is available and whether the member is permitted to borrow it under the agreed rules. If the loan is accepted, it records which member has the book and marks the book as on loan.

A receipt is output because it communicates the loan details. The saved loan record is storage because it allows the system to check availability and process the return later.

Do not invent extra rules without identifying them as assumptions. For example, an overdue-loan check belongs in processing only if the scenario’s borrowing rules require it.

12 | BUILD YOUR OWN INPUT–PROCESS–OUTPUT–STORAGE TABLE

Start with the system’s purpose. Then follow one real task from beginning to end, asking what information arrives, what operations are required, what results are communicated and what data must be available later.

Write concrete descriptions. For a temperature-controlled greenhouse, input might be the measured temperature, processing a comparison with the target, and output a signal to switch a heater. Stored settings might include the target temperature. Keeping a long-term measurement history is a separate requirement, not something every controller necessarily does.

For the booking system, “data, calculations, screen, disk” would be too vague. “Student identifier, duplicate and capacity checks, acceptance message, saved booking records” describes the actual task.

You can break a large system into smaller sub-systems and produce a table for each. This links decomposition to analysis of information flow and prepares you to design algorithms that use the right data.

13 | COMMON CONFUSIONS AND CLEAR EXPLANATIONS

Calculating versus displaying: calculating remaining places is a process; showing the number is output. Say which action you mean.

Data versus device: a barcode is data received as input; a scanner is a device that reads it. A displayed loan confirmation is output; a monitor displays it.

Working memory versus persistent records: retaining a value during execution does not by itself guarantee that it will be available after restarting.

For an explain question, connect the role to its purpose: “Accepted bookings must be stored because future requests need to be checked against existing identifiers, therefore the system must retrieve the retained records when checking for duplicates.”

You should now be able to trace information through a familiar scenario, describe operations precisely and justify what needs to be retained.