Plan a Computer Science project around a solvable problem

Confirm the course before planning the evidence

Computer Science has a curriculum transition: the newer course is first assessed in May 2027, and its internal assessment is a computational solution with emphasis on the computational thinking process. Confirm the guide for your examination session with your teacher. Requirements and evidence from an older project template may not match your cohort.

Start with a real problem you can describe and investigate. Identify who experiences it, what currently happens and which part could be addressed through a computational solution. Keep the purpose more precise than 'make an app.'

Define a manageable problem boundary

For an illustrative school-club equipment tracker, the problem might be conflicting records of loans and returns. Identify the information needed, common actions and constraints. Decide what the project will handle within the available time, such as recording items, checking availability and logging a return.

Discuss access to people and records with your teacher and follow school privacy requirements. Use appropriate sample data during development. The illustrative tracker is a planning example; your actual project needs its own justified problem and evidence.

Write observable success conditions

Translate the problem into conditions you can test. 'Easy to use' is too vague by itself. A condition such as preventing a second active loan for the same uniquely identified item makes the intended behavior observable. Include relevant input, output and error conditions.

Agree the conditions through the support arrangements permitted for your task. Avoid treating every suggestion as a new feature. Check whether each proposed requirement serves the defined problem and is feasible with your skills and school timeline.

Plan the computational approach

Break the solution into data, operations and rules. For the tracker, distinguish an item from a loan record and define how identifiers connect them. Sketch the flow for a loan, return and invalid request. Explain the algorithmic decisions rather than choosing a framework solely because it looks advanced.

Build a small prototype of the hardest part. Testing the rule that prevents duplicate active loans can reveal a data-model weakness early. Keep notes on what you tried, what failed and how the design changed.

Develop tests alongside the solution

For each success condition, plan normal, boundary and invalid cases where appropriate. Give the expected result and preserve evidence of the actual result. A demonstration using only a successful path may miss an important problem. Recheck related behavior after a change affects shared data or logic.

• Keep dated versions and development notes.
• Acknowledge external code and resources appropriately.
• Explain code and design choices in your own reasoning.
• Map the evidence you collect to your cohort's actual task guidance.

Evaluate against the original problem

Inspect whether the solution meets the stated conditions and what remains limited. In the tracker example, preventing duplicate loans may work while the interface still makes returns confusing; those are distinct findings. Use relevant evidence to explain improvements, then prioritize changes that matter most to the problem. Leave time to prepare and inspect the required submission materials under your teacher's current guidance and school deadline.