From Projects to Products: The Path to Solving Transformation Fatigue – Download now

The problem with detailing requirements

The problem with detailing requirements - a folder full of requirements and specs
Written by
Emergn
Flow Quality

“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:

  1. Not all information is equal
  2. Information has a lifecycle
  3. 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.

Consider

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.

Additional Insights

View all

The art of feedback

Product Quality Ways of Working
Learning happens at the rate of feedback. But only if the feedback is relevant, actionable, and provided in time. The most frequent failures to learn include listening to the views of pretend-users and expecting experts to return with ‘likes’ within minutes.
View all