How to write a technology requirements specification that works

The requirements specification is the document that most technology projects either skip entirely or produce in a form that is too vague to be useful. It is also the document that, when it is done well, prevents more problems than any other single artefact in the project. This is a practical account of how to write one that reflects what your organisation actually needs.

The three-tier structure ¶

A useful requirements specification distinguishes between must-have requirements, should-have requirements, and nice-to-have requirements. The must-haves are the things the system cannot go live without. The should-haves are important but could be delivered in a later phase. The nice-to-haves are features that would be useful but are not worth paying a premium for.

This distinction matters most during vendor evaluation, when vendors will present every feature as essential and every limitation as minor. Having agreed priorities in writing before the process starts gives you a basis for scoring responses that is not vulnerable to a persuasive sales presentation.

• Must-have: the system cannot go live without this
• Should-have: important, but could be phased
• Nice-to-have: useful but not worth a premium
• Out of scope: explicitly excluded to prevent scope creep

Who should be involved in writing it ¶

The requirements specification should be written by the people who will use the system, reviewed by the people who will maintain it, and signed off by the person who will be accountable for the outcome. In practice, the document is often written by the IT team alone, which produces a specification that is technically coherent but misses the operational requirements that matter most to end users.

A useful technique is to map the key processes the system needs to support before writing any requirements. What does a member of staff actually do, step by step, when they are using this system? What information do they need at each step? What happens when something goes wrong? The answers to those questions produce requirements that are grounded in real use rather than assumed functionality.

Common mistakes to avoid ¶

The most common mistake is writing requirements that describe a solution rather than a need. 'The system must use a cloud-based architecture' is a solution. 'The system must be accessible from any location without a VPN' is a need. The distinction matters because a requirements specification that describes solutions constrains the vendor's response in ways that may not be in your interest.

The second common mistake is failing to include non-functional requirements: performance, security, availability, and integration. A system that does everything on the functional list but takes forty-five seconds to load a page, or that cannot connect to your existing finance system, is not fit for purpose. Non-functional requirements are as important as functional ones and are more frequently omitted.

Writing a good requirements specification takes time and discipline, and it is the stage most organisations are tempted to rush. The projects where we have seen the most significant problems are almost always the ones where the brief was vague at the start.