B1.1.1 · Approaches to computational thinking
Problem specification
By the end you can
Write a problem specification: the problem statement, constraints, objectives and goals, input and output specifications and evaluation criteria.
Before anyone writes a line of code, someone has to say what the code is for. Programmers who skip this step build something that works perfectly and solves the wrong problem. The written answer is the : a short, clear account of the problem that everyone involved can read and agree on. It is also the starting point for your internal assessment, where the problem specification is the basis for planning, building and evaluating your product.
A problem specification can contain six parts:
- the problem statement,
- the constraints and limitations,
- the objectives and goals,
- the input specification,
- the output specification, and
- the evaluation criteria.
Work through them with one example in mind: a school that lets students book three music practice rooms by sending a message to a teacher, and keeps double-booking them.
The problem statement#
The says what is wrong, who it affects and why it matters. It is about the what and the why, never the how: if it already says “build an app”, you have started designing the answer before you understand the question. Good statements are short, specific and free of words that mean different things to different readers.
Weak: “Room booking is a mess.” A mess in what way? For whom? Would you know when it was fixed?
Strong: “Students book the three music practice rooms by messaging a teacher. Last term about one booking in five was double-booked, so students arrived to find the room in use and lost their rehearsal time.” It names the people, gives a figure and shows the consequence.
The people the problem touches are its : here the students, the teachers who take the messages and the music department. Talk to them. They are the best source of the figures, and the best way to find the constraints you would otherwise miss.
Constraints and limitations#
A is a boundary the solution has to stay inside. The usual families are:
- Time: a deadline.
- Money: a budget.
- Technical: the hardware, software or existing systems the solution must work with.
- People: how many staff can build, run and support it, and what skills they have.
- Legal and ethical: laws, regulations and the duty to protect people's data.
Like the problem statement, a constraint has to be specific. “We don't have many resources” tells a developer nothing. “The budget is $10,000 and cannot be exceeded” names the resource, gives the amount and says it is firm.
Objectives and goals#
These two are easy to mix up, so keep them apart. A is the broad direction: “make room booking fair and easy.” It is the reason for the project, but you could never prove you had fully achieved it. A is a milestone on the way to it, and it is measurable and has a time limit: “reduce double-bookings from 20% of bookings to under 2% within one term.” Every goal should be linked to an objective, and one objective usually has several goals.
Input and output specifications#
The describes the data that goes into the solution: what it is, its type and format, how it will be collected, and what you can reasonably expect of it. For room booking that is a student ID, a room, a date and a start time, chosen from a menu rather than typed so that nobody invents a room that does not exist. Input can arrive by manual entry (a keyboard or touch screen: cheap, but people make mistakes), by direct entry (a barcode or card reader) or automatically from sensors (more accurate and faster, but it costs more). The choice affects everything that follows, because the format of the data decides how it must be validated, stored and processed.
The describes what the solution produces and how it is delivered: the content, the format and the presentation. Here it might be an on-screen confirmation, an email, and a printed timetable for the music office. Output can be temporary (shown on a screen), permanent (printed or saved) or physical (a signal that switches something on). Writing it down early shows what the solution needs to calculate, and what the people who use it actually need to see.
Evaluation criteria#
The last part looks forward. are the tests you will apply once the solution exists, and writing them first keeps you honest, because you cannot adjust the target after you have seen the result. Good criteria are measurable and cover several qualities:
- Effectiveness: did it solve the problem? (double-bookings under 2%)
- Efficiency: does it save time or effort? (a booking takes under a minute)
- Accuracy: are its results correct? (every confirmation shows the right room and time)
- Usability: can people use it without training? (90% of surveyed students call it easy)
- Maintainability: can it be changed later? (a new room can be added by staff without a programmer)
Students book the three practice rooms by messaging a teacher, and about one booking in five last term was double-booked.
The system must be built by two students by the end of March, using only the school’s existing computers and tablets.
Make room booking fair and easy for students.
Cut double-bookings from 20% of bookings to under 2% within one term.
A student ID, a room, a date and a 30-minute start time, picked from menus.
An on-screen confirmation, an email, and a printed weekly timetable for the music office.
At least 90% of surveyed students say booking is easy, and a booking takes under a minute.
Student names and IDs must be stored in line with the school’s data-protection policy.
0 of 8 matched
Check yourself
Problem specification
Quick questions, made fresh every time and marked here. Do a few until they feel easy.
Exam practice
Paper 1-style questions
6 questions · 18 marks
Write your answer as you would in the exam, then show the mark points and tick each one your answer made. These are our own questions in the style of the exam, not past-paper questions.
1.Define the term problem specification.
[2]Define: Give the precise meaning of the term.
2.A manager writes: “Our website is slow and customers are unhappy.” Explain why this is a weak problem statement.
[3]Explain: Give reasons: say what happens AND why, or how one thing causes another.
3.A school wants to build a system to book its music practice rooms. State three constraints the developers may face.
[3]State: Give a short answer, no explanation needed.
4.Distinguish between a high-level objective and a specific goal.
[2]Distinguish: Make the differences between two things clear.
5.A café wants customers to order from their table using a phone, so that fewer orders are written down wrongly. Construct (a) a problem statement, and (b) one high-level objective with one specific goal linked to it.
[4]Construct: Draw or write it out (a table, a diagram, a program).
6.A bank is building a chatbot that answers customers’ questions. Outline an input specification and an output specification for it.
[4]Outline: A brief account: the main points, without much detail.
In a nutshell
- A problem specification says exactly what the problem is before anyone designs a solution. It has six parts: problem statement, constraints, objectives and goals, input specification, output specification and evaluation criteria.
- A strong problem statement is specific, measurable and says why the problem matters. “Our service is inefficient” is weak; “callers wait 25 minutes and 15% hang up” is strong.
- Constraints are the limits on the solution (time, money, hardware, people, law). A useful constraint is specific enough to check.
- An objective is the broad aim; a goal is a measurable, time-limited target that serves it.
- The input specification describes the data going in (type, format, how it arrives, what to expect). The output specification describes what comes out and how it is shown.
- Evaluation criteria are measurable tests, set in advance, of whether the solution worked: effectiveness, efficiency, accuracy, usability and maintainability.