Hidden requirements

Whatever the development approach requirements exist. They don’t all exist at the start some only emerge as things develop but once they emerge they are important. Implicit unstated known to a few they are problems waiting to happen. Captured and shared they are exceptionally valuable.

A chequered past

Requirements are out of favour. Historic attempts to fully predefine requirements in isolation have a poor record. The “waterfall” lifecycle has been replaced. However for a system of any size, or complexity that is not a “one-off” use system, but one that needs to be evolved, controlled requirements are a key element of the delivery process and to the support and maintenance process.

Timing is everything

The mistake made was to try and capture requirements too early. Before it was possible to know what was important and what was unimportant. Before it was possible to know what the right answer was. Before it was possible to know how to “write it down” in a useful way.

Effective requirements processes need to capture requirements at the optimum time. Though a requirement may only emerge with weeks to go, it may still may need to be known a year later when changes are made.

Which requirements?

Requirements need to be valuable and practical. Valuable requirements are ones that will make a real difference to the success of the solution. Non-compliance will have a concrete downside, compliance will bring great value. Practical means lots of things. It means achievable given the state of the art and the amount being invested. It means useable by all disciplines, specifiers can understand the implication of compliance and non-compliance, designers and developers can understand the implications on what they do and the assurance team can work how to measure the extent of compliance.