Problem solving process
Computer ScienceΒ· Unit 9: Algorithm design & problem solvingΒ· 10 min read
1. Step 1: Problem Definition & Requirements Analysisβ βββββ± 3 min
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.
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
- The program must record the customer name and desired collection date for each order
- 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.
2. Step 2: Decomposition & Abstractionβ β ββββ± 4 min
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.
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
- User authentication: Only allow verified teachers and admins to log into the system
- Attendance recording: Let teachers mark students as present/absent for each timetabled class
- Secure data storage: Save attendance records to a database that is backed up daily
- Report generation: Generate weekly absence summary reports for school management
3. Step 3: Solution Design & Implementationβ β ββββ± 3 min
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.
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:
- 3ext{Absence Percentage} = igg( rac{ ext{absent days}}{ ext{total days}}igg) imes 100
- 4
Step 3: Round the result to 1 decimal place and output the final percentage
4. Step 4: Testing & Evaluationβ β ββββ± 3 min
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.
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.
5. Common Pitfalls
Wrong move:
Jumping straight to writing code before clearly defining the problem.
Why:
This leads to building a solution that solves the wrong problem, wasting time and losing marks in exams.
Correct move:
Always outline all requirements and constraints first, before designing any algorithm or code.
Wrong move:
Confusing requirements and constraints in exam answers.
Why:
Examiners specifically test this distinction, so mixing them up leads to avoidable lost marks.
Correct move:
Remember: requirements are what the solution must do, constraints are limits on how you build the solution.
Wrong move:
Decomposing problems into overlapping sub-problems with shared functionality.
Why:
This leads to repeated code, makes debugging harder, and creates dependencies between sub-problems.
Correct move:
Ensure each sub-problem has one clear responsibility with no overlapping functionality with other sub-problems.
Wrong move:
Ending the process after testing for bugs, skipping evaluation.
Why:
A solution can be bug-free but still fail to meet the original problem's requirements and constraints.
Correct move:
Always compare the finished solution against every original requirement and constraint to evaluate its suitability.
6. Quick Reference Cheatsheet
Step | Key Activity | Check Question |
|---|---|---|
| Capture requirements + constraints | Do I understand the problem? |
| Split into sub-problems, remove extra details | Are sub-problems independent? |
| Write algorithms, integrate, code | Does each sub-problem work? |
| Test for bugs, check against requirements | Does it solve the original problem? |
When this came up on past exams
AI-estimated based on syllabus patterns β cross-check with official past papers for accuracy. Use only as revision-focus signals.
- 2022 Β· 12
Describe problem solving steps
- 2024 Β· 11
Identify problem constraints
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.