- How to analyse a problem before you start coding.
- How to use decomposition to split a large problem into smaller parts.
- How to use abstraction to focus on the details that matter.
- How decomposition and abstraction work together when designing a solution.
A common beginner mistake is to open Python and start typing straight away. That can work for tiny tasks, but larger problems quickly become confusing.
Before developing code, you need to understand:
- what the program is meant to achieve
- what data it needs
- what rules it must follow
- how the solution can be split into manageable pieces
Computational problem
A computational problem is a task that can be solved using a computer. It usually has inputs that go into the program, processing that happens to the data, and outputs that come out of the program.
An input is data supplied to the program, such as a name, score, password, or menu choice.
An output is data produced by the program, such as a result, message, total, or report.
A constraint is a rule or limit the solution must obey, such as “the username must be at least 6 characters” or “there are only 30 seats available”.
To analyse a problem means to examine it carefully so you know what needs to be solved. In Computer Science, analysis often means identifying the inputs, outputs, rules, and constraints.
A requirement is something the program must do, or a condition it must meet.
For example, “the program must calculate the total cost” is a requirement. “The user must not be able to book more tickets than are available” is also a requirement.
Analysing a ticket calculator
A sports club wants a program to calculate the cost of tickets. Adult tickets cost £8, child tickets cost £5, and the user cannot buy more than 10 tickets in one order.
-
Decide what the program must output: it needs to output the total ticket cost, so the final answer depends on the number and type of tickets.
-
Identify the inputs needed to calculate that output: the program needs the number of adult tickets and the number of child tickets.
-
Identify the rules that affect processing: adult tickets are multiplied by 8, child tickets are multiplied by 5, and the two subtotals are added.
-
Identify the constraint that affects whether the input is allowed: the total number of tickets must not be more than 10, so the program must check the combined number of adult and child tickets before accepting the order.
Analyse before solving
A good solution starts with a clear understanding of the problem. If you do not know the inputs, outputs, and rules, your code is likely to be incomplete or incorrect.
Decomposition
Decomposition is the process of breaking a large or complex problem into smaller, more manageable sub-problems.
A sub-problem is one smaller part of the original problem. Each sub-problem should be easier to understand, solve, test, and debug than the whole task at once.
In programming, decomposed sub-problems often become separate sections of an algorithm or separate Python functions. A function is a named block of code that performs a specific task and can be reused.
The diagram below shows how one large problem can be split into smaller tasks, while abstraction filters out details that are not useful.

Decomposition makes a problem easier because you can:
- focus on one part at a time
- divide work between different programmers
- test each part separately
- reuse parts of the solution in other programs
- reduce the chance of forgetting a requirement
For example, a “quiz program” sounds like one task, but it might contain several smaller tasks:
- load questions
- display a question
- get the user’s answer
- check if the answer is correct
- update the score
- show the final result
A decomposition tree shows a problem at the top, then breaks it down into smaller and smaller parts underneath. It is not code yet — it is a planning tool.
Decomposing a library search program
A school library wants a program that lets a user search for a book by title or author and then shows whether matching books are available.
-
Start with the main goal: the program must let a user search the library records and display useful matching results.
-
Split the goal by what needs to happen to the data: get the search term, search the book records, check availability, and display the results.
-
Break the searching part down further: compare the search term with each book title, compare it with each author name, and collect any records that match.
-
Give each sub-problem a clear purpose: for example, “check availability” should take a book record and decide whether it is available to borrow.
Clear sub-problems
A useful sub-problem usually has a clear job. If you cannot say what data it needs and what result it produces, it probably needs more thought.
Splitting without connections
Do not just list random features. A decomposition should show how the parts help solve the whole problem, and what data needs to move between them.
Abstraction
Abstraction is the process of reducing complexity by focusing on the important details of a problem and ignoring unnecessary details.
Real-world problems contain lots of information. Some of it affects the solution, and some of it does not.
For example, if you are writing a program to calculate a bus fare, the passenger’s age may matter if children get a discount. The colour of the bus probably does not matter.
Abstraction helps you create a simpler model of the problem. A model is a simplified representation of something real.
A detail is relevant if it affects the solution.
A detail is irrelevant if it does not affect the solution for this particular problem.
This depends on the problem. In one program, a person’s age might matter. In another program, it might not.
Abstracting a bus fare problem
A bus company wants a program to calculate ticket prices. The real-world description mentions the route name, bus colour, passenger age, number of zones travelled, whether the ticket is single or return, and the driver’s name.
-
Decide what decision the program must make: it must calculate the ticket price, so only details that affect the price are useful.
-
Keep details that change the price: passenger age may affect discounts, number of zones may affect distance cost, and single or return ticket type may affect the total.
-
Discard details that do not affect the price: bus colour, driver’s name, and route name can be ignored unless the pricing rules specifically use them.
-
Create a simplified model: the program needs inputs such as passenger_age, zones_travelled, and ticket_type, then outputs a ticket price.
Generalisation is closely linked to abstraction. It means spotting a pattern and creating a general rule instead of treating every single case separately.
For example, instead of writing separate logic for “Alice gets a child fare”, “Ben gets a child fare”, and “Caitlin gets a child fare”, the program can use a general rule: if the passenger is under the child-fare age limit, apply the child fare.
This makes the solution shorter, clearer, and easier to maintain.
Removing important rules
Abstraction does not mean ignoring details at random. If a detail affects the output or whether the input is valid, it must be kept.
These two techniques are different, but they work well together.
| Technique | Main question | What it does |
|---|
| Decomposition | “What smaller parts can this problem be split into?” | Breaks the problem into manageable sub-problems |
| Abstraction | “Which details actually matter?” | Removes unnecessary detail and keeps the important information |
Decomposition is about structure.
Abstraction is about detail.
Use both together
Decomposition helps you decide the parts of the solution. Abstraction helps you decide what information each part really needs.
When you are given a programming problem, use this approach:
- Identify the goal of the program.
- Identify the inputs, outputs, rules, and constraints.
- Use abstraction to remove irrelevant real-world detail.
- Use decomposition to split the solution into sub-problems.
- Decide how the sub-problems connect.
- Turn the plan into an algorithm or Python code.
- Test each part and then test the whole solution.
Once the problem is decomposed, each sub-problem can often become a function.
For a quiz program, you might have functions with meaningful names such as:
load_questions()
ask_question()
check_answer()
update_score()
display_result()
The names should describe what each part does. This makes the program easier to understand and debug.
Planning a revision quiz program
A teacher wants a quiz program that asks questions, checks answers, keeps score, and shows the final result. The description also mentions background colours, sound effects, and the classroom display board.
-
Abstract the problem by keeping details that affect the required behaviour: question text, correct answers, user answers, and score are needed.
-
Remove details that do not affect the core solution: background colours, sound effects, and the classroom display board can be ignored unless they are stated requirements.
-
Decompose the program into sub-problems: load the questions, ask each question, compare the user’s answer with the correct answer, update the score, and display the final result.
-
Decide the data flow between sub-problems: the question data is passed into the asking part, the user answer is passed into the checking part, and the result of checking is used to update the score.
-
Combine the parts into an overall algorithm: set the score to 0, repeat the question-check-score process for each question, then output the final score.
Decomposition and abstraction are not just for writing code. They also help you read and understand exam questions.
If a question describes a messy situation, abstraction helps you filter the text. You can ask: “Which details affect the answer?”
If a question asks for a solution, decomposition helps you structure your response. You can show the smaller tasks needed rather than trying to describe the whole system in one sentence.
A quick check
If your plan is still confusing, decompose further. If your plan is full of unnecessary real-world detail, abstract more.
In the exam
-
If asked about decomposition, name the smaller sub-problems and explain how they contribute to the full solution.
-
If asked about abstraction, state which details are kept, which are ignored, and why those choices help simplify the problem.
-
For longer problem-solving questions, organise your answer around inputs, outputs, rules, constraints, and sub-problems.
Check yourself
- Can you explain the difference between decomposition and abstraction in your own words?
- Given a food-ordering app, what details would be relevant for calculating the total cost?
- How could decomposing a program make it easier to test and debug?