Revision notes for OCR AS Level Computer Science Specify the proposed solution. Open the guide for explanations and worked examples. Written against the OCR AS Level Computer Science specification, so the content matches what's examinable rather than general Computer Science background.
Specify the proposed solution
What you'll learn
- How to turn problem analysis into a clear proposed solution.
- How to specify and justify functional, non-functional, data, hardware and software requirements.
- How to write measurable success criteria that can later be tested and evaluated.
- How to avoid vague statements that lose marks because they cannot be evidenced.
Where this fits in the project
At this point, you have analysed the problem: you should know who the users are, what the current problem is, and what constraints exist. Now you need to say what you are proposing to build.
This is still part of analysis, not detailed design. You are not yet drawing every screen or writing algorithms. Instead, you are defining the requirements the solution must meet.
Definition
Proposed solution
A proposed solution is a clear description of the system you intend to create to solve the identified problem, including what it must do, what constraints it must satisfy, and what resources it needs.
Key Idea
Requirements come from evidence
Good requirements are not guesses. They should be based on evidence from your analysis: user interviews, observation of the current system, existing documents, data samples, constraints, and stakeholder priorities.
Solution requirements
A requirement is a statement describing something the solution must provide or a condition it must satisfy.
Your requirements should be:
- Specific — clear enough that another person understands what is meant.
- Relevant — linked to the actual problem and users.
- Justified — supported by evidence or reasoning.
- Testable — capable of being checked later.
- Realistic — achievable within the project time and available technology.
Functional requirements
Definition
Functional requirement
A functional requirement states what the system must do. It describes features, processes, inputs, outputs, calculations, searches, reports, validation or user actions.
Examples include:
- The system must allow a receptionist to add, edit and cancel appointments.
- The system must calculate the total cost of an order from item prices and quantities.
- The system must allow an administrator to search customer records by surname or customer ID.
- The system must generate a weekly stock report.
Functional requirements usually involve a user action or system process.
Example
Turning stakeholder needs into functional requirements
A charity shop manager says: “We keep selling items that are no longer in stock because the paper stock sheets are out of date. Volunteers need something simple because staff change often.”
-
Identify the real operational problem: the stock record is not updated quickly enough, so the proposed system needs to keep stock quantities current after sales and deliveries.
-
Identify the user actions needed to solve it: volunteers must be able to add new stock, record sales, search for items, and view current quantities.
-
Convert those actions into functional requirements: “The system must decrease an item’s stock quantity when a sale is recorded” and “The system must prevent a sale being recorded when the item quantity is zero.”
-
Justify the requirements using the evidence: these features directly address the manager’s problem of selling unavailable items and reduce dependence on out-of-date paper records.
Non-functional requirements
Definition
Non-functional requirement
A non-functional requirement states how well the system must work or what constraints it must satisfy. It describes qualities such as performance, usability, reliability, security, compatibility or accessibility.
Examples include:
- The system must load the customer search screen within two seconds on the target computer.
- The system must be usable by volunteers with minimal training.
- The system must require an administrator login before stock values can be edited.
- The system must run on the client’s existing Windows laptop.
These are still requirements, but they are not individual “features” in the same way as adding a booking or printing a report.
Common Mistake
Writing vague non-functional requirements
Avoid statements such as “the system will be fast”, “the system will be user-friendly” or “the system will be secure”. They are too vague unless you define what fast, user-friendly or secure means in this specific context.
Data requirements
A data requirement describes what data the solution needs to store, process, validate or output.
This is important because many programming projects fail when the student describes features but not the data behind them.
You might specify:
- Customer details: customer ID, name, phone number, email address.
- Appointment details: date, time, service, staff member, status.
- Validation rules: phone number must not be blank; appointment date cannot be in the past.
- Storage needs: records must persist after the program closes.
- Data protection needs: personal data should only be visible to authorised users.
If your solution handles personal data, your analysis should consider privacy and lawful handling. In OCR H446, the relevant legislation is referred to as The Data Protection Act 1998.
Hardware and software configuration
The specification asks you to include hardware and software configuration if appropriate. This means you should describe the technical environment needed for the proposed solution to be developed, run and tested — but only where it matters.
Definition
Configuration
A configuration is the combination of hardware, software, operating environment, peripherals and settings needed for a system to work correctly.
Hardware configuration
Hardware might include:
- Desktop computer, laptop, tablet, server or mobile device.
- Processor, memory and storage requirements, if they affect performance.
- Network or internet access.
- Peripherals such as barcode scanners, printers, touchscreens, cameras or card readers.
- Backup storage, if local data must be protected.
Do not list impressive hardware for the sake of it. If a simple database application will run on the client’s existing laptop, say so and justify it.
Software configuration
Software might include:
- Operating system.
- Programming language or runtime environment.
- Database management system or file storage approach.
- Web browser, if it is a web-based system.
- Development tools, if relevant.
- Third-party libraries or APIs, if the solution depends on them.
The important word is justify. You need to explain why the chosen configuration suits the user’s situation and constraints.
Example
Choosing an appropriate configuration
A school music department wants a loan system for instruments. It will be used by one teacher on an existing school laptop. Internet access is unreliable in the practice rooms.
-
Use the environment constraint to rule out unsuitable approaches: a solution that depends on constant internet access would be risky because the user may need the system in rooms with unreliable connectivity.
-
Choose hardware that matches the real setting: the proposed solution can run on the existing school laptop because only one teacher needs access and the data volume is small.
-
Choose software that supports the constraint: a local application with persistent local storage would allow loans and returns to be recorded without internet access.
-
Justify the configuration: this avoids extra hardware cost, works in the rooms where the system is needed, and matches the single-user workflow described by the stakeholder.
Tip
Development versus deployment
You may develop the project on your own machine, but the deployment environment is where the user will actually run it. Your requirements should focus mainly on the user’s real environment.
Measurable success criteria
Once you have specified the solution requirements, you need to define how success will be judged.
Definition
Success criterion
A success criterion is a measurable statement used to decide whether the finished solution meets a requirement.
A success criterion should be clear enough that you can later test it and collect evidence. It may be numeric, such as a time limit, or observable, such as whether a validation rule correctly accepts and rejects specific inputs.
From requirements to success criteria
A requirement says what the solution must provide. A success criterion says how you will know it has been achieved.
| Requirement | Weak success criterion | Better success criterion |
|---|---|---|
| The system must be easy for volunteers to use. | Users like the system. | At least four out of five test users can record a sale and update stock without help after a five-minute introduction. |
| The system must search customer records. | Search works. | Searching by surname returns all matching customer records from a test dataset of at least 100 records within two seconds. |
| The system must validate appointment dates. | Dates are checked. | The system rejects blank dates, non-date values and dates before the current date, while accepting valid future dates. |
| The system must produce a stock report. | Report is good. | The system generates a report showing item ID, item name, current quantity and reorder status for every item in the inventory. |
Notice that the better versions are measurable. They define what will be tested and what counts as success.
Example
Writing measurable success criteria
Suppose your requirement is: “The system must allow the club secretary to produce a list of members who have not paid their annual fee.”
-
Identify the purpose of the requirement: the secretary needs to chase unpaid fees, so the output must distinguish paid and unpaid members accurately.
-
Choose measurable evidence: use a test dataset containing members with both paid and unpaid statuses, including edge cases such as recently updated payments.
-
Define the pass condition: “Given a test dataset of at least 30 members, the system lists every unpaid member and excludes every paid member.”
-
Add a relevant usability or performance measure if needed: “The secretary can generate the unpaid-members report in no more than three user actions from the main menu.”
Justifying success criteria
You should not only list success criteria. You should also justify them.
A good justification explains why that criterion proves the solution is useful for the real user.
For example:
- “This criterion is needed because the current paper system causes missed payments, so the secretary must be able to identify unpaid members accurately.”
- “The two-second search limit is appropriate because staff need to answer customer queries while speaking on the phone.”
- “The validation criterion is required because incorrect dates caused double bookings in the existing spreadsheet.”
Key Idea
Every criterion should trace back
Each success criterion should trace back to a requirement, and each important requirement should have at least one success criterion. This makes your final evaluation much stronger because you can prove whether the solution met the original analysis.
A practical structure for your write-up
A clear way to present this section is to use a table. For each requirement, include its type, the requirement itself, the justification, and the linked success criterion.
| Type | Requirement | Justification | Measurable success criterion |
|---|---|---|---|
| Functional | The system must allow the manager to add new stock items. | The current paper record is often incomplete when deliveries arrive. | A manager can add an item with ID, name, category, price and quantity, and the item appears in later searches and reports. |
| Non-functional | The system must be usable by temporary volunteers. | Volunteers change regularly and cannot receive lengthy training. | A new volunteer can record a sale after a five-minute introduction without needing written instructions. |
| Data | The system must store stock quantities persistently. | Quantities must not be lost when the program closes. | After closing and reopening the program, all stock quantities match the values saved before closing. |
| Configuration | The system must run on the existing shop laptop. | The charity has limited budget for new hardware. | The completed system runs successfully on the target laptop during user testing. |
You do not have to use exactly these column names, but your write-up should make the link between analysis evidence, requirements and success criteria obvious.
Common Mistake
Confusing design decisions with requirements
A requirement might be “the user must be able to search bookings by date”. A design decision might be “there will be a search box in the top-right corner”. At this stage, focus on what the solution must achieve, not every detail of how the interface will look.
Quality checklist
Before you move on, check that your proposed solution section answers these questions:
- What exactly are you proposing to build?
- What must the system do?
- What data must it store, process or output?
- What constraints affect performance, usability, security or compatibility?
- What hardware and software will be needed, if relevant?
- Why are these requirements appropriate for this user and problem?
- How will you measure whether the finished solution is successful?
Exam technique
In the exam
-
Link every requirement to the user’s problem or constraints; do not just list features you personally want to build.
-
Make success criteria measurable by including observable outputs, test datasets, time limits, accuracy expectations or clear pass/fail conditions.
-
Avoid vague words such as “fast”, “easy” and “secure” unless you define exactly how they will be measured.
Self review
Check yourself
- Can you explain the difference between a functional requirement and a non-functional requirement?
- Could someone test each of your success criteria and decide whether it has passed or failed?
- Have you justified your hardware and software choices using the user’s real situation rather than personal preference?
Keep learning
Make a free account to read the full revision notes and worked examples.