Better requirements: working with developers, standards and suppliers

1. Ask what the request is trying to achieve

Purpose: Separate the underlying need from a proposed solution.

“Add an export button” is a proposed solution. “Help coordinators transfer approved bookings without retyping them” describes a need that can be investigated.

Ask someone to show you a recent example. Follow the information from its source to the final task, noting repeated entry, corrections, waiting and work done outside the applications. Confirm what happens today before deciding which parts should change.

Record the evidence and the uncertainty separately. One person’s account can reveal an important problem, but the team still needs to understand how widely it occurs.

2. Bring implementers into discovery

Purpose: Identify constraints while options are still open.

Implementers include developers, testers, technical specialists, supplier engineers and people who maintain the service. They may know about access restrictions, old interfaces, data quality problems or support limitations that change the available choices.

• Which system holds the authoritative record for each field?
• How quickly must an update arrive for the task to work?
• Which permissions and data restrictions apply?
• What happens when information is missing, duplicated or out of order?
• Who can provide representative test data and a suitable test environment?

Translate technical findings into their effect on users and delivery. “Updates are processed overnight” matters because a coordinator may otherwise promise equipment using yesterday’s availability.

3. Describe behaviour people can verify

Purpose: Give development and testing a shared basis for checking the result.

Acceptance criteria state the conditions used to judge whether a particular piece of work meets the agreed need. Include the normal journey and realistic exceptions.

This example leaves decisions to resolve deliberately. The team must agree the actual processing window, permitted recovery actions and how conflicts are handled before implementation is treated as ready.

Add quality requirements where they affect the service: expected volumes, accessibility of the administrative interface, security, monitoring and support arrangements. Turn vague words such as “fast” or “reliable” into agreed conditions that can be assessed.

4. Make the standard practical to implement

Purpose: Help teams apply shared rules consistently and raise evidence of problems.

The UK Government’s Open Standards Principles describe open standards as a way to support compatibility and reduce reliance on custom integration. A particular standard still needs clear guidance about how it applies in the local context.

Provide worked examples, valid and invalid sample records, version information and a route for questions. Validation tools can check defined rules, but they do not establish that the whole user journey works.

When teams struggle, capture the rule or section, a reproducible example, the affected task, the impact and the clarification requested. Share that evidence with the standard’s owner and tell implementers what was decided.

A useful feedback loop also distinguishes an unclear rule from a local implementation defect. Escalate the question without assuming that either the standard or the developer is automatically at fault.

5. Agree ownership across supplier boundaries

Purpose: Prevent important responsibilities falling between organisations.

Confirm who owns interface documentation, test access, data correction, incident investigation and changes to the connection. Check those expectations against the supplier agreement and involve the relevant commercial colleagues where scope or cost needs a decision.

Agree how version changes will be communicated, how compatibility will be checked and what transition support is available. A change that looks small in one application can affect several connected services.

Keep a decision record with an owner and review date. Link requirements to their source need and test evidence so that a later change can be assessed with its context intact.

Try this with one real requirement

Purpose: Leave with clearer behaviour and named follow-up actions.

Invite someone who understands the user task, an implementer and someone who will support the result. Include the supplier when its service is part of the decision.

• Describe the task and the evidence behind the request.
• Walk through one successful example using representative information.
• Walk through a missing record, duplicate update and unavailable system.
• Identify the applicable standard and version.
• Record unresolved decisions, owners and the evidence needed to resolve them.

Finish by asking each person to explain what should happen. Differences in those explanations are useful findings to resolve before delivery.