Specifying Requirements

Now that project Condor has begun, one of the first workstreams - and arguably the most important - is specifying the Business requirements. Normally, IT projects are only started once we receive a Requirements Specification from the business area, and we start the analysis process. Requirements are often incomplete, ambiguous, stated without context, duplicated or reflect a suggested solution rather than a business need.

It is an oft-quoted statistic that the later in the life-cycle of a project - any project - that errors are spotted and eliminated, the more costly it is to do so. To quote an extreme example, one error in a requirements specification spotted during User Acceptance Testing can require weeks and cost tens of thousands of pounds to rectify, but only a few minutes if spotted before the specification is baselined.

In order to have any chance of meeting the tight deadlines imposed on this project, I have arranged for an analyst to be assigned to the business team drawing up the requirements. The project team assigned other people as well, and set up dedicated office space where everyone could work together, and arranged a series of workshops to draw out requirements on specific topics before they were documented.

Specifying business requirements - or user requirements - is not a difficult thing to do, but it's also very easy to do it badly, and make the developer's job a nightmare. We are not always understood when we explain something verbally, but it's even more difficult to get the message across accurately when we have to write it down.

Here are 8 simple rules about good requirements. Whether you are someone who specifies requirements, or someone who receives them, make sure the Requirements Specification you end up with follows these principles, and your project will be off to a good start.

1. Source - Identify who originated the requirement, so that any queries can be addressed to the right person.
2. User - Identify who will benefit from each requirement.
3. Clear and concise - Eradicate any possible ambiguity.
4. Unique - Eliminate duplication.
5. Identifiable - Each requirement must have a reference to ensure traceability (see below).
6. Prioritised - Each requirement must be assigned a priority to distinguish between the ones that are essential for the business case, and which are 'nice-to-have'. The MoSCoW method is widely used for this purpose and is easy to understand.
7. Verifiable - It must be possible to verify, by inspection or testing, that a requirement has been met. If you cannot verify it, you should not be specifying it.
8. Genuine - Specify the requirement, not a suggested solution.

Traceability must also be maintained from each requirement, through design, to individual test cases. The ability to track a test case back to a requirement ensures that all requirements are delivered and verified. But more on this another time.