The big idea: A problem specification writes down exactly what the program must do, before anyone writes any of it.
It is what you check the finished program against — and without it, "finished" is a matter of opinion.
Why it comes first: "Make a system for the library" cannot be built or tested, because nobody can say when it is done.
The specification turns a wish into something with a definite answer.
Free preview
This is the free notes preview
You're reading the free notes. Aimnova Pro unlocks the full study experience — and you can try it with your first topic free to keep:
- FlashcardsLock in vocabulary and key terms with spaced repetition.
- Practice questionsAnswer exam-style questions and get instant AI marking.
- Mock exams & past-paper vaultSit full mocks and see exactly how examiners award marks.
- Personalised study planA daily plan built around your exam date and weak areas.
Problem statement
One or two sentences saying what problem is being solved and for whom.
"Library staff cannot tell which loans are overdue without checking every record by hand." Describe the problem, not the solution you have in mind.
Objectives and goals
What the finished system must achieve, written so each one can be checked off.
"List all overdue loans within five seconds" is an objective. "Be easy to use" is not — nobody can tell whether it was met.
Input specification
What goes in: each item, its type, its valid range, and where it comes from.
"Member ID: a whole number between 1 and 99999, entered by staff." This is also where validation rules come from.
Output specification
What comes out: the format, the destination, and what happens when there is nothing to show.
"A list on screen, sorted by days overdue, showing member name, title and days late; a message if there are none."
Constraints and limitations
What you are not free to choose: the language, the hardware, a deadline, a budget, data protection rules.
Also what the system will deliberately not do — which prevents arguments later.
Evaluation criteria
How anyone will judge whether it worked, decided now rather than afterwards.
"Staff can find every overdue loan in under a minute, tested on a full term's data." Written before you build, so you cannot move the target.
Learn what examiners really want
See exactly what to write to score full marks. Our AI shows you model answers and the key phrases examiners look for.
Testable
- "Return results within five seconds on 10,000 records"
- "Reject any member ID outside 1 to 99999"
- "Show a message when no loans are overdue"
- Each one can be tried, and the answer is yes or no
Not testable
- "Be fast"
- "Handle errors properly"
- "Be user-friendly"
- Each one is a matter of opinion, so it can never be settled
The test for an objective: Ask: how would I prove this was met?
If you can describe the test in one sentence, the objective is good. If not, rewrite it until you can.
Where the marks usually are: Exam answers lose marks by writing vague objectives and by skipping the input and output specifications.
Naming types and ranges for inputs takes one line each and is the easiest part to get right.
How this is tested — you must write objectives and input-output specifications that could actually be tested. It comes up two ways:
Paper 2 — working with code
- Construct a specification from a scenario, 4-6 marks
- Write objectives, inputs and outputs
- Identify constraints the scenario implies
Paper 2 — the algorithmic-thinking question
- Specify a problem described in words, with no code involved
- Say how the finished solution would be judged
The classic trap: Writing objectives that cannot be checked. "Be efficient" earns nothing; "process 10,000 records in under five seconds" earns the mark, because it can be tried.
A school canteen wants a program that lets students pre-order lunch and tells staff how many of each meal to prepare. Construct a problem specification.
Model answer plan
See the answer broken into clear points, with guidance on how each point earns marks.