# Problem solving process

> Computer Science · CIE A-Level 9618
> Source: https://www.owlsprep.com/study/cie-9618-u9-problem-solving-process/

This module covers the structured, industry-standard problem solving process used in computer science, from initial problem definition to final solution evaluation. You will learn to break down complex problems and validate solutions against requirements.

**Prerequisites:** [Basic understanding of what an algorithm is](https://www.owlsprep.com/study/cie-9618-u9-what-is-an-algorithm/)

## Learning objectives

- Describe the structured steps of the standard computer science problem solving process
- Distinguish between requirements and constraints for a given problem
- Apply decomposition and abstraction to break down complex problems
- Evaluate finished solutions against original problem criteria

## Step 1: Problem Definition & Requirements Analysis

The first step of any problem solving process is to clearly define what the problem actually is, rather than jumping straight to coding. Many costly mistakes happen when developers solve the wrong problem because they skipped this critical step.

**Requirements Analysis** — The process of extracting all functional and non-functional requirements that the solution must meet to solve the problem

*Example:* A requirement for a shopping app could be *"users must be able to save payment methods for future checkout"*

Requirements are split into two categories: functional (what the solution *does*) and non-functional (how well it does it, e.g. page load time < 2 seconds). Constraints are also captured here: these are limitations placed on the solution, such as available memory, budget, or development deadline.

**Worked example:** A local bakery wants a program to track daily custom cake orders. List 2 functional requirements and 1 valid constraint for this problem.

1. First, identify core functional requirements, which describe features the program must provide:
2. 1. The program must record the customer name and desired collection date for each order
2. The program must calculate the total order price based on cake size and decorations
3. Next, identify a relevant constraint that limits the solution:
4. A valid constraint: *The program must run on the bakery's existing 8GB tablet, so it cannot use more than 1GB of RAM*

> **Exam tip:** Always explicitly distinguish between requirements (what the solution must do) and constraints (limits on the solution) — CIE examiners regularly test this distinction.

## Step 2: Decomposition & Abstraction

Once the problem is clearly defined, the next step is to reduce complexity by breaking it into smaller, manageable parts. This process is called decomposition, and it is almost always paired with abstraction to remove unnecessary details.

**Decomposition** — Splitting a large, complex problem into smaller independent sub-problems that can be solved separately, often by different team members

*Example:* Decomposing a school management system into: attendance tracking, grade recording, timetable generation

Abstraction simplifies the problem by hiding irrelevant details that do not affect the final solution. For example, when designing a bus route tracking system, you do not need to know the color or interior design of each bus — only its route number and current location.

**Worked example:** Decompose the problem of building a student attendance app into 4 appropriate, independent sub-problems.

1. Split the problem into logically separate sub-problems, each with a single clear responsibility:
2. 1. User authentication: Only allow verified teachers and admins to log into the system
2. Attendance recording: Let teachers mark students as present/absent for each timetabled class
3. Secure data storage: Save attendance records to a database that is backed up daily
4. Report generation: Generate weekly absence summary reports for school management

> **tip**
>
> When decomposing, aim for sub-problems that are loosely coupled: changing one should not require rewriting another.

## Step 3: Solution Design & Implementation

Once decomposed, each sub-problem is solved individually by first designing an algorithm. Algorithms can be represented as pseudocode, flowcharts, or structured English before any code is written.

After all individual algorithms are tested and refined, they are integrated (combined) to create the full working solution, then implemented in the target programming language.

**Worked example:** One sub-problem of the attendance app is to calculate the percentage of days a student has been absent. Write a simple algorithm for this sub-problem.

1. Step 1: Define the inputs to the algorithm: total number of school days, number of days the student was absent
2. Step 2: Calculate the absence percentage using the formula:
3. $$\text{Absence Percentage} = \bigg(\frac{\text{absent days}}{\text{total days}}\bigg) \times 100$$
4. Step 3: Round the result to 1 decimal place and output the final percentage

## Step 4: Testing & Evaluation

The final step of the problem solving process is testing the full solution for bugs, then evaluating whether it actually solves the original problem. Testing finds errors in the code, while evaluation checks that the solution meets all requirements and constraints.

Evaluation also considers opportunities for future improvement, and whether the solution can be adapted for similar problems later.

**Worked example:** After building the bakery order tracking program, the bakery reports the program is too slow to load on their existing tablet. Does this fail a requirement or a constraint? Explain your answer.

1. Step 1: Recall the definitions: requirements are what the solution must do, constraints are limitations on the solution.
2. Step 2: The original problem stated the program must run on the bakery's existing tablet, which is a constraint, not a functional requirement.
3. Conclusion: This fails the constraint of running on the bakery's existing hardware. The solution must be adjusted to reduce memory usage and improve load time.

> **Exam tip:** When asked to evaluate a solution in an exam, always refer back to the original requirements and constraints stated in the question to get full marks.

## Common pitfalls

- **Wrong:** Jumping straight to writing code before clearly defining the problem.
  - Why it fails: This leads to building a solution that solves the wrong problem, wasting time and losing marks in exams.
  - Correct: Always outline all requirements and constraints first, before designing any algorithm or code.
- **Wrong:** Confusing requirements and constraints in exam answers.
  - Why it fails: Examiners specifically test this distinction, so mixing them up leads to avoidable lost marks.
  - Correct: Remember: requirements are what the solution must do, constraints are limits on how you build the solution.
- **Wrong:** Decomposing problems into overlapping sub-problems with shared functionality.
  - Why it fails: This leads to repeated code, makes debugging harder, and creates dependencies between sub-problems.
  - Correct: Ensure each sub-problem has one clear responsibility with no overlapping functionality with other sub-problems.
- **Wrong:** Ending the process after testing for bugs, skipping evaluation.
  - Why it fails: A solution can be bug-free but still fail to meet the original problem's requirements and constraints.
  - Correct: Always compare the finished solution against every original requirement and constraint to evaluate its suitability.

## Cheatsheet

| Step | Key Activity | Check Question |
| --- | --- | --- |
| 1. Problem Definition | Capture requirements + constraints | Do I understand the problem? |
| 2. Decomposition & Abstraction | Split into sub-problems, remove extra details | Are sub-problems independent? |
| 3. Design & Implementation | Write algorithms, integrate, code | Does each sub-problem work? |
| 4. Testing & Evaluation | Test for bugs, check against requirements | Does it solve the original problem? |

## What's next

The structured problem solving process is the foundation for all algorithm design and software development in CIE A-Level Computer Science. Every topic from sorting algorithms to full software development projects relies on following these steps to avoid mistakes and deliver solutions that meet requirements. Mastering this process will help you approach even the longest 15-mark exam design questions by breaking them into clear, mark-winning steps. Next, you will build on this foundation to learn core problem solving techniques and algorithm representation methods.

- [Algorithm classification](https://www.owlsprep.com/study/cie-9618-u9-algorithm-classification/)
- [Standard searching algorithms](https://www.owlsprep.com/study/cie-9618-u9-standard-searching-algorithms/)
- [Standard sorting algorithms](https://www.owlsprep.com/study/cie-9618-u9-standard-sorting-algorithms/)

---

From [OwlsPrep](https://www.owlsprep.com) — free study guides for A-Level, IB, AP and IGCSE, written against the official syllabus. Canonical page: https://www.owlsprep.com/study/cie-9618-u9-problem-solving-process/