Project analysis: from a problem to measurable requirements
Analysis explains what problem needs solving and why a proposed computational solution is suitable. Evidence connects stakeholder needs to requirements and success criteria.
Content owner: Michael Print · Written for A-Level learners · Checked against official specifications
The idea to start with
Start with the existing problem and its impact. Investigate users, existing approaches and constraints before choosing features. A requirement states what the solution needs; a success criterion specifies how achievement will be judged.
These are fictional teaching exercises. Your assessed project must be your own work. Follow your centre's supervision and authentication rules and OCR section 4e: permitted AI assistance must be acknowledged and its effect made clear; copied output cannot establish your own knowledge, understanding or ability.
OCR H446 · 3.1.1–3.1.4
Before you start
Useful foundations
Decomposition separates a problem into manageable parts.
A stakeholder can be a user, administrator or another person affected by the solution.
By the end, you should be able to
Identify a computationally suitable problem and its limits.
Evaluate stakeholder and research evidence.
Distinguish requirements from measurable success criteria.
Identify the problem before naming the app
A vague aim such as 'make a timetable app' says little about the difficulty. A clearer problem is that two coordinators allocate the same room to overlapping activities and find conflicts only after participants arrive. Inputs, rules and required outputs make the computational work visible.
Explain where computation can help: storing structured records, detecting conflicts and searching feasible allocations. Also identify what the system cannot decide, such as whether two groups should receive equal priority.
A manageable scope is one you can implement and evaluate with available time, tools and access.
Identify stakeholders and gather useful evidence
A coordinator needs reliable conflict checks; a participant needs a clear allocation; the person maintaining room data needs straightforward editing. Their interests may conflict. Justify whom you consult and what each can tell you rather than treating one convenient respondent as the whole user population.
Ask about actual workflows, failures and constraints. 'Show me what happens when a room is unavailable' is more useful than 'Would you like my app?' Record evidence with dates and an appropriate method, using only data you are allowed to collect.
Explain how a finding changes a requirement.
Research alternatives and their limitations
Investigate an existing spreadsheet, booking product or manual process. Compare relevant behaviour: conflict detection, search, accessibility and maintenance. A feature list alone does not explain whether an approach solves this problem.
State the limits of the research. A trial account may hide administrative functionality; one user interview may miss another group's needs. Distinguish an observed limitation from an assumption, then decide whether further evidence is needed.
Check the project language and graphical interface
OCR appendix 5e accepts Python, the C family, Java, Visual Basic, PHP and Delphi for component 03. Choose a language that fits the problem, available tools and your own development skills.
For a language outside that list, ask your centre to arrange OCR consideration of the task outline, language details and reasons for choosing it before committing to the project.
Appendix 5e requires a suitable graphical interface for a project in any language. A console-only final booking tool would therefore miss that requirement, even if its conflict algorithm worked.
Plan graphical controls for the coordinator's tasks, such as entering a booking, reading a conflict message and correcting the time. Justify the interface from stakeholder needs and test it with the intended environment.
Our short console algorithms are isolated teaching exercises. For the fictional Python project, investigate a permitted graphical toolkit and document its dependencies alongside the runtime; the standard-library Tkinter interface is one possible choice when the required Tk installation is available.
Check installation, accessibility and offline operation on the actual centre machine rather than assume that naming Python establishes them.
Justify the hardware and software configuration
This fictional offline trial has at most 2000 bookings. The available test export is under 2 MB; records must save and reload locally. These are scenario facts, not universal minimum specifications.
Document the actual runtime version and modules the proposed design uses. A configuration choice is adequate only when it can run within the centre’s permissions and the measured workload.
Justify the configuration from the requirements and access constraints. A small export does not prove low RAM consumption or adequate response time. Verify those claims with measured tests, check installation permissions and document dependencies.
If simultaneous coordinators or remote access become requirements, revisit the local-file design and hardware/software choice.
Match the trial configuration to its job
Centre laptop → available platform→
Supported 64-bit OS, 4 GB RAM and 200 MB free local storage. State the actual centre-approved OS/version in a real analysis.
Keyboard/display → coordinator input→
Enter and check bookings on the existing device instead of requiring a mobile device or network server.
Python 3.12 + dependencies → offline execution→
Use the permitted runtime and document the standard-library record/file modules and required graphical-toolkit installation.
Local storage → records and recovery→
Reserve space for saved records and backups, then test the largest planned dataset on this configuration.
Requirements and success criteria
Include relevant usability, performance and resource constraints with justified measures. 'Easy to use' and 'fast' cannot be judged without a task, user group, dataset or time threshold. Avoid arbitrary targets unsupported by the actual problem.
Evidence → requirement → measurable success
1
Evidence
The coordinator reports overlapping bookings for one room.
2
Requirement
Reject overlapping bookings for the same room.
3
Success criterion
For all eight planned overlap/boundary cases, reject genuine overlaps and accept adjacent bookings. This names an observable outcome and a method of checking it.
Fictional analysis traceability
Evidence
Requirement
Success check
Coordinator reports double bookings
Detect same-room time conflicts
All eight overlap/boundary cases behave correctly
Volunteer works without network access
Load/save local booking records
Reload a saved dataset after restarting offline
Participants cannot find their room
Search allocations by activity
Representative users find a named activity in the agreed trial task
Worked example
Research two approaches before choosing a direction
In this fictional investigation, a coordinator demonstrates a paper register and a trial online calendar using the same four example bookings. Record what is observed rather than infer features from a product name.
The paper register works offline and is familiar, but the coordinator must compare every relevant interval manually. The online calendar shows overlapping entries clearly, but in this configured trial it accepts both and requires a network connection.
Neither trial meets both conflict prevention and the offline constraint. A local checker is a justified prototype direction because it can apply the interval rule while storing local records. It still needs implementation and evaluation; research does not prove the proposed system will work.
Limit the conclusion: only two workflows and one coordinator were investigated. Check other users, permission to install the runtime and the largest dataset before treating the proposed direction as suitable.
Fictional observations and their effect on requirements
Approach
Observed strength
Observed limit
Design implication
Paper register
Works offline
Manual comparisons miss overlap
Automate the stated conflict rule
Configured online-calendar trial
Shows times visually
Accepts conflicting entries; needs network
Keep understandable times and enforce checks offline
Worked example
Improve an untestable aim
Original aim: 'The timetable should work well.' Identify whose task is difficult: a coordinator assigning a room to an activity.
State the required behaviour: prevent a same-room overlap while allowing adjacent bookings.
Define the interval rule: bookings overlap when startA < endB and startB < endA. End equals next start is allowed in this fictional policy.
Plan concrete checks: contained, identical, partial-overlap, different-room and adjacent intervals. Connect the later tests to the criterion.
Keep a scope limit: the prototype does not optimise all allocations automatically. It detects conflicts and lets the coordinator choose an alternative.
Original A-Level practice
7 original questions total 27 marks. Attempt each before opening the independently written indicative marking guidance.
Question 1
4 marks
A learner proposes a console-only booking project in a language outside OCR's listed choices. Explain two checks needed before proceeding with that assessed project.
Show solution and marking guidance+
Indicative answer
Arrange OCR consideration through the centre, supplying the task outline and language details (1), with reasons why that language is appropriate to the task (1).
Plan a suitable graphical interface because appendix 5e requires one in every language (1); connect its controls/feedback to the coordinator's tasks and check that it can run in the permitted environment (1).
Question 2
4 marks
Explain why 'create a club app' is an inadequate problem definition and propose two details that would improve it. [4]
Show solution and marking guidance+
Indicative answer
It names a product without explaining an existing difficulty or impact (1).
It does not establish why computation is suitable (1).
For example identify the affected user's workflow and a specific failure, such as overlapping bookings (1), and state relevant inputs/rules/outputs or constraints (1).
Question 3
4 marks
The fictional paper register works offline but requires manual overlap checks; the configured online-calendar trial shows overlaps but accepts them and needs a network. Justify a prototype direction and state one research limitation.
Show solution and marking guidance+
Indicative answer
Identify that neither observed approach meets both conflict prevention and offline use (1).
Propose a local computational checker that enforces the documented overlap rule (1).
Connect retained strengths, such as clear time presentation/offline storage, to the coordinator need (1).
State a relevant limitation, e.g. one user/two workflows or untested performance/installation, and avoid treating a proposed solution as proven (1).
Question 4
4 marks
A learner interviews one coordinator. Explain two limitations and how to address them. [4]
Show solution and marking guidance+
Indicative answer
One person's needs may not represent participants/maintainers; consult relevant additional stakeholders (1+1).
Self-reported problems may omit actual workflow details; observe or examine permitted records/examples (1+1). Credit other justified limitations.
Question 5
5 marks
The fictional coordinator has an offline centre laptop and a dataset of at most 2000 bookings. Explain two hardware/software configuration choices and how to establish that the configuration is adequate.
Show solution and marking guidance+
Indicative answer
Use the available keyboard/display and supported centre machine for entering/checking bookings, connecting the choice to the task (1).
Choose an approved runtime and document its version/dependencies so the solution can actually execute offline (1).
Use permitted local storage with justified space for records/backups rather than require an unavailable network service (1).
Test the largest planned dataset on the intended configuration (1).
These are independently written explanations and practice questions. CompSciTutoring.co.uk is not affiliated with or endorsed by an examination board. The marking guidance is indicative; always check the syllabus for your examination year.