Specialty Digest

Global English editionLearners’ Study Dashboard — in development
The Knowledge Library for All

Online Courses / University Track / Computing Foundations

Module 1 · Lesson 1 · Core

From problem to specification: inputs, outputs and constraints

Turn a vague request into an exact statement of what goes in and what must come out.

  • 55 minutes
  • Serves O1
  • No prior lesson needed

Phase 1: Prepare

Step 1 Warm-up recall

Think of a task you do with fixed steps, such as making tea. List the steps and say what must be ready before you start.

Private: nothing you type here is sent or stored.

Step 2 Learning goal

By the end of this lesson you can:

  • define a computational problem as inputs, a required output and constraints (Foundation);
  • spot what is missing from a vague request (Core);
  • write a precise specification for a simple task (Core).

Phase 2: Teach

Step 3 A familiar example

You ask a colleague to “tidy the list”. One person sorts it, another deletes duplicates, a third makes it shorter. The request did not say what a tidy list is, so nobody could be wrong or right.

Step 4 Clear explanation

A computational problem is a question with defined inputs and a required output. A specification states three things: what kind of input is allowed, what the output must be, and any constraints, such as “the list is never empty”. A machine cannot ask what you meant, so anything left open is either guessed or fails.

Inputa list of numbersAlgorithmthe methodOutputthe largest number
Every computational problem has the same shape: defined inputs, a method, and a required output.

Compare vague requests with precise specifications:

Vague requestPrecise specification
“Sort the students.”Input: a list of student names. Output: the same names in alphabetical order. Ties keep their original order.
“Find the best price.”Input: a list of prices in pounds. Output: the lowest price in the list. The list has at least one price.
“Check the password.”Input: a text string. Output: yes if it has at least 12 characters, otherwise no.

A good specification says what the answer is, not how to find it. “Return the lowest price” is a specification. “Check each price and keep the smallest” is a method, which is the subject of Lesson 2. Keeping the two apart lets you ask whether a method is correct: does it always produce the output the specification requires?

Step 5 Worked example (4 marks)

Write a specification for “find the oldest person in a team”.

  1. Input: a list of people, each with a date of birth. (1 mark)
  2. Output: the person with the earliest date of birth. (1 mark)
  3. Constraint: the list has at least one person. (1 mark)
  4. Open question stated: if two people share the earliest date, return the first in the list. (1 mark)

Phase 3: Practise

Step 6 Learner practice (instant-marked)

1. What are the three parts of a specification?

2. Which statement is a specification rather than a method?

3. Why is “sort the students” a poor specification?

4. What does a constraint such as “the list is never empty” do?

Phase 4: Close

Step 7 Recap

  • A computational problem has defined inputs and a required output.
  • A specification states the input, the output and the constraints.
  • Say what the answer is before saying how to find it.

Step 8 Exit ticket (ungraded)

Write a one-sentence specification for “find the longest word in a sentence”, including what happens in a tie.

Private: nothing you type here is sent or stored.

Step 9 Go further (Extension)

Choose a spreadsheet function you use, such as a sum or a lookup, and write its specification: input, output and one constraint.

Common mistakes

MistakeWhy it fails
Describing steps instead of the answerThat is a method; the specification comes first.
Leaving ties undefinedA machine will do something, and you may not like it.
Forgetting the invalid inputState which inputs are allowed.

Limits. This lesson uses small everyday tasks. Real specifications for large systems are longer and are written with the people who will use the result.