01 | WHY NOT START BY WRITING CODE?

Imagine being asked to build a booking program for your school’s robotics club. You open your editor and begin making a colourful screen with a “Book now” button. It looks promising, but there is a problem: you do not yet know how many places the club has, who can book, or what should happen when the club is full.

You might produce a program that runs perfectly but solves the wrong problem. A computer follows the instructions it is given; it cannot fill in missing school rules for you.

This is why development begins with analysis. Analysis means investigating the problem and identifying what a solution needs to achieve. At this stage, your most useful tools are careful questions, observation and clear notes.

Our example starts with this situation: staff record club bookings on paper. Sometimes they accept too many students, and counting the remaining places takes time. We will turn that everyday difficulty into information a programmer can use.

02 | FIND THE PROBLEM BEHIND THE REQUEST

A teacher says, “We need an app for the club.” That sounds like a clear request, but it tells you very little about the underlying problem. An app is one possible way of helping; it does not explain what needs improving.

Ask the teacher to show you what happens now. They point to a list of names and explain that several staff members add bookings without always counting the existing entries. The important difficulty is now clearer: bookings can exceed the available places.

A problem statement is a short description of the difficulty or need. For our example, it could be:

Staff need to record club bookings, prevent overbooking and see how many places remain.

This gives development a purpose. A programme that only displays a club photograph would not address that problem, even if its screen looked impressive.

Pause and think: if somebody asks for “a better library system”, what would you need to ask before you could describe the actual problem?

03 | TALK TO THE PEOPLE WHO WILL USE IT

A user is someone who interacts with the system. In our example, staff enter bookings. Students are affected by the decisions, but they are not necessarily entering information themselves. That distinction changes what the program needs to provide.

You could interview staff, watch them make bookings and examine their current forms. Each method can reveal details that were missing from the original request.

Suppose you ask, “Can one student book more than once?” The teacher replies, “No, each student should only have one place.” This is an important rule. Without asking, you might accidentally allow duplicate bookings.

Next you ask, “Do you need the bookings tomorrow?” The answer is yes. The program must therefore keep the information after it closes, rather than losing the list at the end of the session.

Questions about who uses the system, what they enter, what decisions it makes and what must be retained turn a broad request into a specific task.

04 | WHAT IS A REQUIREMENT?

A requirement states something the solution must do or a condition it must satisfy. Think of it as an agreed expectation: when the program is finished, you should be able to check whether it has met that expectation.

“It should be good” is too vague. Two people could disagree about what “good” means. “Reject a new booking when the club is full” describes behaviour you can observe.

For our worked example, we agree that there is one club session, its capacity is a positive whole number, every student has a unique identifier, and each student can book only once. Capacity means the maximum number of students allowed. An identifier is a value that distinguishes one student from another, such as S104. Names alone can be ambiguous if two students share a name.

The capacity also acts as a constraint: it limits how many bookings the solution can accept. An assumption is something we take to be true while working. If we assume there is only one session, we must check that with staff; a system for several sessions would need more information.

05 | FOLLOW THE INFORMATION THROUGH THE SYSTEM

To understand what a system needs to do, follow one booking from beginning to end. A staff member enters S306. The program checks whether S306 is already booked and whether a place is available. It then displays an acceptance or rejection message. If accepted, the booking is saved.

These actions introduce four useful ideas. Input is data supplied to the system. Processing is work performed on that data, such as comparing, checking or calculating. Output is the information produced for a user or another system. Storage retains data for later use.

Do not confuse calculating a number with displaying it. Working out that one place remains is processing; showing “1 place remaining” on screen is output.

The same identifier can have different roles at different moments. S306 is input when typed, data used during processing when checked, and stored data when saved as an accepted booking. These labels describe how information is being used.

06 | WHY SIMPLIFY A REAL-WORLD PROBLEM?

A real club has many details: students, tables, tools, room decorations, meeting times, posters and booking forms. If we try to include every detail in a booking model, we make the problem harder to understand without necessarily improving the solution.

Abstraction means removing unnecessary detail so that we can focus on the important features of a problem. We keep what affects the task and leave out what does not.

You already use abstraction outside computing. A route map shows stations and connections so that you can plan a journey. It does not need to show every tree or shop along the railway. Those details exist, but they do not help answer that particular question.

Our booking model works in the same way. It represents the information needed to decide whether a booking can be accepted. A model is a simplified representation of something. It can be a diagram, a table or a description of the information and rules; it does not have to be a physical object.

07 | DECIDE WHAT TO KEEP AND WHAT TO LEAVE OUT

Ask a practical question about each detail: would removing this stop us meeting a requirement?

If we remove capacity, we cannot tell whether the club is full. If we remove student identifiers, we cannot reliably identify duplicate bookings. If we remove the existing booking records, we cannot count accepted places or check who has already booked. These details must stay.

The wall colour does not change whether another student can book. Neither does the font used on the old paper form. We can leave these out of the availability model.

Be careful with details that seem irrelevant at first. An email address is unnecessary for a basic availability decision, but it becomes relevant if the requirements include sending confirmation messages. Meeting times become relevant if students must avoid clashes between several clubs.

Abstraction is therefore tied to the purpose of the solution. You are not deciding that a detail is unimportant forever; you are deciding whether it is needed for the current task.

08 | BUILD A SMALL MODEL YOU CAN UNDERSTAND

Let us make the booking example small enough to follow by hand. The club has a capacity of 3. Two students, S104 and S205, already have bookings.

We represent the capacity as one value and the accepted identifiers as a collection. A collection simply means several items kept together. You do not need to know arrays or any programming language yet to understand this model.

The number of accepted bookings is found by counting the identifiers. Remaining places are calculated using capacity − accepted bookings, so there is currently 3 − 2 = 1 place left.

Notice what is missing: we do not represent the teacher’s handwriting, the poster’s colours or the shape of the booking sheet. None of these affects the decision. We have kept enough information to answer the question without copying every feature of the real club.

09 | WALK THROUGH THREE BOOKING REQUESTS

First request: S306 asks to book. The identifier is not already in the collection and one place remains. The system accepts it and adds S306. There are now three accepted bookings and zero places remaining.

Second request: S407 asks to book. This is a new identifier, but the club is full. The system rejects the request. S407 is not added, so the accepted booking count stays at three.

Third request: S104 asks to book again. That identifier is already in the collection. The system rejects the duplicate. S104 still has the original booking; the request does not create another one.

Each decision is supported by information retained in our model and by an agreed requirement. We have explained the required behaviour without deciding the exact code or screen layout.

10 | ABSTRACTION AND DECOMPOSITION WORK TOGETHER

Another term in this topic is decomposition. It means breaking a problem into smaller, manageable parts. If solving the whole booking system feels overwhelming, consider one task at a time: entering a request, checking it, recording an accepted booking and showing the remaining places.

Abstraction and decomposition help in different ways. Abstraction reduces unnecessary detail in what we represent. Decomposition divides the work into smaller tasks we can understand and develop.

For example, leaving wall colour out of the booking model is abstraction. Separating “check availability” from “save an accepted booking” is decomposition.

Neither removes the need to meet the requirements. A small task still needs to do its job correctly, and a simplified model still needs enough information for the decisions. Later lessons will show how these smaller tasks can be organised into diagrams and algorithms.

11 | USE REQUIREMENTS TO KNOW WHAT SUCCESS LOOKS LIKE

How will we know whether the finished program works? We need something more reliable than saying, “I clicked the button and nothing crashed.” A program can run without crashing and still accept an invalid booking.

A clear requirement gives us an expected result: the behaviour that should occur in a particular situation. Later, testing compares what actually happens with what should happen.

These are separate example starting situations, not one continuous sequence. Each tells a tester how to set up the system and what result to look for.

If the full-club test accepts another booking, the program has failed a requirement. If staff later explain that they need a waiting list, analysis must be revisited because the requirements have changed.

12 | CONNECT ANALYSIS TO THE DEVELOPMENT LIFE CYCLE

The syllabus identifies four stages: analysis, design, coding and testing. We have focused on analysis: understanding the problem, identifying requirements, removing unnecessary detail and beginning to break the task into parts.

In design, we plan how the solution will work. An algorithm is a precise sequence of steps for completing a task. It can be represented using a flowchart, which shows steps and decisions graphically, or pseudocode, a structured written description of the steps.

In coding, we turn the design into instructions in a programming language. In testing, we use suitable data to check the behaviour against the requirements. These stages can be revisited: finding a mistake may lead us back to the code, the design or even an unclear requirement.

You do not need to write the full booking program yet. The achievement of this lesson is being able to explain what it needs to do, what information it needs and why.

13 | EXPLAIN YOUR THINKING CLEARLY

If a question asks you to define abstraction, give its meaning: removing unnecessary detail to focus on the important features of a problem.

If it asks you to explain how abstraction is used, connect a specific example to its purpose: “The model omits wall colour because it does not affect booking availability. It retains capacity and existing bookings because these are needed to decide whether a place remains.”

A common mistake is to write only “make it simpler”. That does not show which details were removed or why the remaining information is sufficient. Another is to describe decomposition instead: splitting a system into tasks is useful, but it is a different idea.

Before moving on, try explaining the club model to somebody who has not read the lesson. Can you tell them the problem, one clear requirement, a relevant detail, an irrelevant detail and the reason for each choice?