Analysis: requirements and success criteria

Stakeholders, fact finding, functional and non-functional requirements, and measurable success criteria that the robot checks for itself.

A14.3Software development, law and ethicsA level40 min

Analysis turns a client's description of a problem into a precise statement of what the solution must do. It is the stage where the most expensive mistakes are made, because everything later is built on it. A program that perfectly does the wrong thing has failed.

Defining the problem

Before anything can be designed, the problem must be defined: what is wrong with the current situation, who it affects, and what the limits of the project are. For the delivery robot:

Parcels between the school office and classrooms are carried by staff, who lose about an hour a day doing it. The project is a robot that carries small parcels (under 1 kg) along the ground floor corridors. Stairs, outdoor routes and heavy items are out of scope.

The scope matters as much as the goal. Saying what the system will not do stops the project growing until it can never be finished.

Stakeholders

A stakeholder is anyone affected by the system. Requirements must come from interaction with the intended users, not from the developer's guesses.

Different stakeholders want different things, and sometimes they conflict: office staff want the robot fast; the site manager wants it slow in corridors. Analysis brings these out so the client can decide.

Requirements

A requirements specification lists everything the system must do, agreed with the client. Requirements are of two kinds:

• Functional requirements say what the system must do: "The robot must stop before it reaches an obstacle." "The robot must signal when it arrives."
• Non-functional requirements say how well it must do it, or under what constraints: performance, reliability, usability, security, cost. "The robot must complete a delivery within 5 minutes." "The robot must run for a full school day on one charge."

Hardware and software requirements (what it runs on) and the data the system needs are also recorded. AQA stresses creating a data model at this stage: the entities the system deals with and how they relate, such as rooms, parcels, deliveries and routes. A good data model makes the later design of data structures and databases straightforward.

Success criteria

A requirement is only useful if you can tell whether it has been met. Success criteria are requirements written so they can be measured, each with a clear test.

Measurable criteria are what make evaluation honest: at the end, each one is simply met or not met, with evidence. They also become the headings of the test plan, so the analysis already tells you how the system will be tested.

A program can check its own criteria. Here the limits are constants, written once, taken straight from the specification:

# the limits come straight from the success criteria
GAP_LOW, GAP_HIGH = 18, 22

def check_gap(gap):
    return "met" if GAP_LOW <= gap <= GAP_HIGH else "not met"

for measured in [17.5, 18.0, 20.3, 22.0, 24.1]:
    print(f"SC1 gap {measured} cm: {check_gap(measured)}")

Run this in the simulator

Abstraction and decomposition

Analysis also begins the thinking that design finishes. Abstraction removes detail that does not matter to the problem: the robot's route can be modelled as a graph of corridor junctions (lesson A4.1), ignoring the colour of the walls. Decomposition breaks the problem into smaller problems: plan a route, drive a leg, avoid people, report arrival.

Prototyping and agile analysis

Users often cannot say what they want until they see something. A prototype, a quick, incomplete version, lets them react: "the beep is too quiet", "I need to know which room it is going to". In an agile approach, analysis is not finished once at the start: each iteration refines the requirements with the client. The success criteria still need to be measurable; they are simply written a few at a time.

Analysis in the NEA

Every board's project starts with analysis, and it is marked on the same ideas: a clearly defined problem, research into the needs of real end users (interviews, questionnaires, existing solutions), a justified choice of what to include, and a numbered list of measurable success criteria. Lesson A14.9 works through one.

Task: meet the success criteria

The robot starts 71 cm from the charging wall, facing it. Write a program that meets these success criteria, then checks each one and prints the result:

• SC1: the robot stops with a gap of 18 to 22 cm (inclusive) between it and the wall, measured with distance().
• SC2: it has stopped within 20 seconds of the program starting, measured with clock().
• SC3: when parked, the LED turns green and an 880 Hz note plays.

After parking and signalling, print exactly three lines:

• SC1 gap <cm> cm: <result>, where <cm> is the gap read after stopping;
• SC2 time <seconds> s: <result>, where <seconds> is clock() read after stopping;
• SC3 signal: met.

Each <result> is met or not met, decided by an if that compares the measurement with the limits in GAP_LOW, GAP_HIGH and TIME_LIMIT. Do not touch the wall.

# the two lines every program starts with: the commands, then the robot
from bugbot import *
connect()

GAP_LOW, GAP_HIGH = 18, 22     # SC1, in cm
TIME_LIMIT = 20                # SC2, in seconds

Challenges

1. Rewrite each vague requirement as a measurable success criterion: "The robot should be safe near students." "The app should look nice." "The battery should last."
2. Office staff want deliveries in under 2 minutes; the site manager wants the robot below walking pace. How would an analyst resolve this?
3. List three entities in a data model for the delivery system and one relationship between two of them.