- What “problem identification” means in OCR H446 project analysis.
- How to describe features that make a problem solvable by computational methods.
- How to explain why a problem is amenable to a computational approach.
- How to avoid vague, generic justifications such as “computers are faster”.
This topic is the starting point of the Programming project analysis. Before you design screens, databases, algorithms, or tests, you must show that you have found a real problem and that it is suitable for a computer-based solution.
Problem identification is not just “I want to make an app”. It is about explaining:
- who has the problem
- what currently happens
- what is wrong or inefficient
- what data and rules are involved
- why computation is a sensible way to solve it
Problem identification
Problem identification is the process of selecting, describing, and justifying a real-world problem clearly enough that it can be analysed and potentially solved using a computer system.
A real-world situation is often messy. People may describe it using broad phrases like “the booking system is bad” or “revision is hard”. Your job is to turn that into a precise problem.
A computational problem usually involves the classic input-process-output model:
- Input: data entered into or collected by the system.
- Process: rules, calculations, decisions, or algorithms applied to the data.
- Output: useful results produced for the user.
Computational method
A computational method is a way of solving a problem using precise, repeatable steps carried out by a computer, usually involving data storage, algorithms, validation, searching, sorting, calculation, or decision-making.
The diagram shows how you can move from a real-world issue towards a justified project proposal.

The core test
A problem is suitable for computation when you can identify the data involved, the processing rules needed, the outputs expected, and the constraints that affect the solution.
A stakeholder is anyone affected by the problem or by the proposed solution. This might be a teacher, shop owner, club organiser, receptionist, student, customer, or administrator.
An end user is the person who will directly use the system. Sometimes the stakeholder and end user are the same person; sometimes they are different. For example, a school attendance system may be used by office staff, but its outputs may affect teachers, parents, and senior leaders.
To identify a strong problem, you should understand the current process. That means what people do now, before your system exists.
Useful evidence might include:
- interviews with stakeholders
- observation of the current process
- copies of paper forms or spreadsheets
- screenshots of an existing system
- descriptions of errors, delays, duplication, or missing information
Narrowing a vague project idea
Suppose your starting idea is: “I want to make a system for a school library.”
-
Identify the stakeholder and current process: the librarian currently records loans in a spreadsheet and manually checks whether books are overdue.
-
Turn the situation into data: the system would need data about books, borrowers, loan dates, return dates, and book availability.
-
Identify repeatable rules: a book cannot be loaned if it is already out, a due date can be calculated from the loan date, and overdue books can be found by comparing the due date with today’s date.
-
Define useful outputs: the librarian needs a list of current loans, overdue books, borrower histories, and book availability.
-
State the problem precisely: “The librarian needs a system to record book loans and returns, prevent unavailable books being issued, and automatically identify overdue loans.”
OCR expects you to describe and justify the features that make the problem solvable by computational methods. This means you should not simply list features; you should explain why each one matters.
The system must have data it can work with. This data should be obtainable, representable, and relevant.
For example:
- a booking system may use customer names, dates, times, and room numbers
- a stock system may use product IDs, quantities, reorder levels, and supplier details
- a revision quiz may use questions, answers, topics, marks, and user scores
If the data cannot be collected reliably, the problem may not be suitable.
The user should know what they want the system to produce. Outputs might include:
- reports
- alerts
- search results
- schedules
- invoices
- recommendations
- updated records
- graphs or summaries
A problem is easier to justify if the outputs are useful and testable.
An algorithm is a finite sequence of clear steps used to solve a problem. Computers are especially good at tasks where the same rules are applied many times.
Examples of repeatable rules include:
- calculating a total price
- checking whether a password meets requirements
- sorting appointments by date
- finding all overdue tasks
- preventing double bookings
- calculating a grade from marks
Confusing judgement with rules
Do not claim a problem is computational just because it involves a decision. If the decision depends entirely on human judgement, emotion, taste, or context, you need to explain how the system will represent that judgement using data and rules.
Many good project problems involve storing data and retrieving it later. This often leads naturally to files or a database.
For example, a gym membership system may need to store:
- member records
- membership types
- payments
- class bookings
- attendance history
This makes the problem computational because the system can search, update, validate, and summarise stored records more reliably than a manual process.
A constraint is a limitation or condition that affects the solution. Constraints do not necessarily make a project impossible, but they shape what is realistic.
Common constraints include:
- time available to develop the project
- hardware or software access
- user skill level
- data availability
- privacy and security requirements
- network access
- cost
- legal or ethical limits
If your project uses personal data, you should think carefully about privacy and data handling. For OCR, the relevant legislation name is The Data Protection Act 1998.
A success criterion is a testable statement that describes what the final solution must achieve.
Weak success criterion:
- “The system should be easy to use.”
Stronger success criterion:
- “A receptionist should be able to add a new appointment with patient name, date, time, and clinician in under one minute without creating a clash.”
The stronger version is better because it is measurable and linked to the real problem.
Improving success criteria
Suppose the problem is that a sports club struggles to manage court bookings.
-
Start with the vague aim: “The system should manage bookings well.”
-
Identify the user need: the club secretary needs to avoid two members booking the same court at the same time.
-
Convert the need into a rule: before accepting a booking, the system must check whether the selected court, date, and time slot are already taken.
-
Convert the rule into a measurable criterion: “The system must reject a booking if another booking already exists for the same court, date, and time slot.”
-
Link it back to the problem: this criterion directly addresses the current double-booking issue.
Amenable to a computational approach
A problem is amenable to a computational approach if it is well-suited to being solved or improved using a computer system, because it involves data, repeatable processing, clear rules, and useful outputs.
This is slightly different from saying the problem is merely possible to solve with a computer.
A problem is solvable if a computer can be used to produce a solution.
A problem is amenable if using a computer is a sensible and beneficial approach.
For example, you could technically use a computer to store a list of three names, but that may not justify a full project. A computer-based system becomes more appropriate when there is enough data, repetition, complexity, or need for accuracy to make automation worthwhile.
A problem is often amenable to computation when it involves one or more of these features.
| Feature | Why it supports a computational approach |
|---|
| Repetition | Computers can apply the same rule many times without getting bored or inconsistent. |
| Large amounts of data | Computers can search, sort, filter, and summarise data efficiently. |
| Need for accuracy | Validation and automatic calculations can reduce human error. |
| Time pressure | Automated processing can produce outputs faster than manual work. |
| Record keeping | Data can be stored, retrieved, backed up, and updated. |
| Clear rules | Algorithms can be designed when the decision process is precise. |
| Useful feedback | Reports, alerts, or recommendations can support user decisions. |
Justifying a computational approach for bookings
A local sports club currently uses a paper diary for court bookings. Members often phone the secretary, who manually checks available times. Double bookings happen during busy evenings.
-
Identify the input data: the system would use member details, court numbers, dates, times, booking durations, and booking statuses.
-
Identify the processing rules: the system can check whether a requested court and time slot already exists, reject clashes, and store valid bookings.
-
Identify the outputs: it can show an availability timetable, booking confirmations, cancellation records, and weekly usage reports.
-
Explain the benefit over the manual method: automatic clash checking reduces double bookings, searching by date is faster than scanning a paper diary, and reports can be generated without recounting entries manually.
-
Conclude why it is amenable: the problem involves structured data, repeatable validation rules, frequent updates, and clear outputs, so a computational approach is appropriate.
A strong answer usually follows this pattern:
- Context: describe the organisation, user, or situation.
- Current process: explain what happens now.
- Problem: identify what is inefficient, inaccurate, slow, risky, or difficult.
- Evidence: refer to stakeholder comments, documents, observations, or examples.
- Computational features: identify inputs, outputs, processing rules, stored data, and constraints.
- Justification: explain why these features make the problem suitable for computation.
- Scope: state what your project will and will not attempt to solve.
Weak:
“This problem is good for a computer because computers are fast and accurate.”
Strong:
“The current spreadsheet requires the user to manually check whether appointment times overlap. The proposed system can store appointment records, compare a new appointment against existing records for the same staff member and time period, and reject clashes automatically. This makes the problem suitable for a computational approach because it involves structured data and repeatable validation rules.”
The strong version is better because it links the computational approach to the actual problem.
Use because, not just can
When justifying suitability, use sentences with because. For example: “The problem is suitable for a computational approach because the booking rules are repeatable and can be applied automatically to stored booking records.”
Some problems are harder to justify as computational projects.
Examples include:
- problems with no clear user
- problems with no accessible data
- problems based mainly on personal taste
- problems where the rules cannot be described
- problems too large for the project timeframe
- problems already solved completely by an existing tool, with no meaningful improvement
- problems where legal or ethical issues make data collection inappropriate
Do not overclaim
A computer system may support a human decision without fully replacing it. For example, a system might rank applications using clear criteria, but a human may still need to make the final judgement.
You can use a structure like this when writing your own project analysis:
The problem affects [stakeholder], who currently [current process]. This causes [specific issue], such as [evidence/example]. The problem is suitable for computational methods because it involves [input data], [processing rules], and [required outputs]. A computer-based solution would be appropriate because [benefit linked to the problem]. The project will focus on [scope], while excluding [out of scope].
This keeps your writing focused on the problem rather than jumping straight to the final solution.
In the exam
-
Separate the problem from the solution: describe the user’s current difficulty before talking about software features.
-
Justify every claim: link inputs, processing rules, outputs, constraints, and success criteria to the actual scenario.
-
Avoid generic phrases like “computers are faster”; explain what the computer will do faster, more accurately, or more consistently.
-
Use the word amenable carefully: show that the problem is not only possible to solve by computer, but genuinely well-suited to computation.
Check yourself
- Can you identify the input data, processing rules, and outputs for your own project idea?
- What evidence could you collect to prove that the problem affects a real stakeholder?
- Why is a computational approach better than the current method, beyond simply saying “computers are fast”?