The problem with detailing requirements
“The importance of complete, consistent and well documented software requirements is difficult to overstate.” – Marvin Early, Relating Software Requirements to Software Design
The quote above is from our VFQ Requirements book which goes through the whole history of requirements in software projects and comes to the conclusion that the normal requirement in a project today is really just a piece of information that unfortunately mixes need, scope, design, expectation and acceptance in a way that will leave a reader confused as to what is required and what is truly valuable. In a sense, they’re often used to try and define a ‘scope of work’. In most cases, it’s done incredibly poorly.
That’s because of these 3 problems:
- Not all information is equal
- Information has a lifecycle
- Information can overwhelm action
This means the traditional requirements document that you tried to get ‘signed off’ at the beginning of a project is essentially useless as things change, understanding is developed and importance shifts. Even when requirements are ‘accurate’ they don’t happen to paint the same picture in the heads of the person who captured them and the one using them to build something new. The whole goal of trying to get to a set of ‘cast iron’ 10s (if not 100s or 1000s) of requirements is one that doesn’t lead to a better outcome.
You only know if a requirement was right when you built the thing and a user and customer says it’s correct. So, instead of focusing on getting to sign-off, spend your time creating an approach that defines the important feedback loops so that you can govern risk, investment and acceptance on a regular cadence. The goal is to manage market, technical and delivery risks – not pin down a set of requirements.
Are you able to discover quality with fast feedback? Be explicit about what feedback you might need, what defines quality and what the frequency is. It will lead to better results than focusing on exhaustively detailing requirements.