Requirements Management

Why requirements fail

Defective requirements are consistently among the largest causes of project failure, and the defects are predictable: incomplete, contradictory, ambiguous, gathered from the wrong people, describing a solution rather than a need, or simply never written down.

The consequence is discovered late, when the deliverable is tested or used, which is the most expensive point at which to discover it.

Types

• Business requirements — the outcome the organisation needs.
• Stakeholder requirements — what particular groups need.
• Functional requirements — what the result must do.
• Non-functional requirements — how well it must do it: performance, capacity, availability, security, usability, maintainability, compliance. These are routinely under-specified and are the most expensive to retrofit.
• Transition requirements — what is needed to move from the current state: migration, training, parallel running.

Elicitation

Requirements are elicited rather than collected, because stakeholders frequently cannot state what they need in usable terms. Techniques include interviews, workshops, observation of current work, document analysis, prototypes, process modelling and reviewing the problems the current arrangement produces.

Observation is consistently the most revealing and least used. What people say they do and what they actually do differ substantially, and the workarounds visible in practice usually reveal the real requirements.

Writing a usable requirement

A requirement should be:

• Necessary — traceable to a business need.
• Unambiguous — one interpretation only. Words such as "user-friendly", "fast", "flexible" and "as required" are the usual offenders.
• Testable — you can demonstrate whether it has been met. This is the single most useful test of a requirement's quality.
• Solution-free where possible — stating the need rather than the implementation, which preserves options.
• Consistent with the others.
• Prioritised, because not everything can be delivered.

Traceability

Each requirement should be traceable forward to the design, the build and the test that verifies it, and backward to the business need that justifies it.

The forward direction proves nothing has been missed. The backward direction is more interesting: a requirement that cannot be traced to a business need is a candidate for removal, and applying this test to a requirements set routinely removes a significant proportion of it.

Conflicts and unstated requirements

Stakeholders want incompatible things, and reconciling that is a project task rather than something to be discovered at acceptance. Equally, some requirements are never stated because they are assumed — regulatory obligations, organisational standards, and the things everybody knows. Prompting explicitly for these is quick and prevents a familiar category of late surprise.