Write a problem specification by stating exactly what must be solved, who the solution serves, and its required inputs, outputs, constraints, assumptions, and success criteria. It defines what a computational solution must achieve, not how it will be programmed.
Building the specification
A problem specification establishes requirements and boundaries before solution design. In B1.1 Approaches to computational thinking, decomposition divides the problem into manageable parts, while abstraction removes irrelevant details and retains essential information.
Investigate the context and identify stakeholders, the people or organizations affected. Then specify each component precisely.
| Component | What to specify | Library fine calculator example |
|---|---|---|
| Problem and purpose | Current issue and intended outcome | Staff need consistent overdue-fine calculations |
| Inputs | Supplied data, types, and valid ranges | Overdue days: non-negative integer; category: student or teacher |
| Processing | Required calculations or decisions | Multiply overdue days by the category rate |
| Outputs | Information produced | Total fine and explanatory message |
| Constraints | Limits on the solution | Fine cannot exceed the maximum charge |
| Assumptions | Conditions accepted as true | Due and return dates are accurate |
| Success criteria | Specific, testable measures | Correct fines for boundary and typical valid inputs |
Requirements should be unambiguous, feasible, and testable. “The program must be user-friendly” is vague; “a librarian can calculate a fine in no more than three input steps” is measurable.
A common misconception is that a specification should include code, algorithms, or interface layouts. These belong to solution design; the specification comes first and provides criteria for evaluating the eventual solution.
Exam technique
If asked to formulate or outline a problem specification, connect every requirement to the scenario instead of giving a generic list. Examiners expect clear inputs, outputs, constraints, assumptions, and measurable success criteria. Show how decomposition separates subproblems and how abstraction keeps only relevant details. Include boundary and typical cases so each criterion can later be tested.
