Requirements: A Picture’s Worth a Thousand Words
Many requirements are well "written". But does the "consumer" of the requirements - the developer - want them "well-written", or simply clear, understandable, and thorough?
Requirements are Challenging
Requirements are often an area of significant stress and challenge on projects. Owners want it to be good and want it now - but what is "it"?!
Language does have its limitations. Often we cannot quite find the words that are sufficient.
This is most clearly highlighted in the communication of people of different languages. It often happens with pictures! "Here, let me draw it for you." Or, "let me show you."
Why not use pictures? Or videos? Or something else visual and less formal...
These things work exceedingly well in regular, less formal communications. The well known "back of the envelope" sketch at the diner is one I am all too familiar with.
So why not employ that approach in requirements?
Let's contrast the waterfall and agile project approach for requirements.
Waterfall Approach to Requirements
In the waterfall approach, where the requirements are almost entirely completed before any development begins, the requirements are considered to be "formal". The are created painstakingly - with every "i" dotted and "t" crossed with great care. They are usually reviewed multiple times, thoroughly, by many people, until they are considered to be "perfect".
Here are some potential problems with that approach:
- Those providing the input and feedback don't necessarily know clearly what is needed.
- The true value of each requirement is not necessarily known or considered.
- High value requirements that are well-understood need to wait until ALL of the requirements, including those of lower or even no value, are captured and documented to the satisfaction of the reviewers.
- Time passes through this typically long process, and the opportunity to get it done and realize the value may pass, as needs can transition fast.
- The input of developers, who often are more familiar with what is possible, is typically not part of the process, and even if it were sought, the timing would be off, as not everything can be foreseen.
Agile Approach to Requirements
An agile approach to requirements can be the antidote to to most of these problems, but not necessarily. After all, the waterfall approach is built on a foundation of planning ahead, which has a lot of merit!
Here are the challenges with the agile approach antidote.
- Stakeholders further from the action can limit their input to what they know well - the high level requirements and general direction they want to go.
- The true value of each requirement will be much clearer closer to the time of development, when it is prioritized.
- High value requirements can be implemented rapidly, depending upon practical considerations at the implementation level.
- Value can be delivered more rapidly, feedback obtained sooner, and course corrections made as necessary - something that cannot happen if all is planned up front.
- A more balanced participation among stakeholders is achieved, with developers empowered to make appropriate decisions at their level.
What is likely to happen
When you open the requirements process to all involved - at all levels - and de-emphasize formality, you will likely experience more clarity and productivity toward project goals. In the process, other methods of communicating requirements are likely to emerge - such as pictures or videos - even models. The agile practice of providing short-term demos is a perfect illustration. The point is to think through what needs to be done, consider when and how it can be achieved, to control risk, and to achieve value as soon as possible.
Whether you use a more waterfall or agile oriented approach to requirements, strive to maintain a balance between up front planning and rapid delivery, and keep in mind that a picture is worth a thousand words!