7 requirements myths

James Robertsen gave a presentation on March 31, 2011 for the Dutch chapter of IIBA, the International Institute of Business Analysis. James is always good for a nice presentation, and this presentation was no exception. His subject was: “Requirements myths”.

Myth 1: Requirements are about requirements.
Truth: Requirements are about a business problem. Don’t look where the light shines (which is usually a software problem), look beyond the software for the business problem behind the software.

Myth 2: Listen to your customers.
Truth: Your customers don’t come up with innovations. Ford: “If I had asked what people wanted, they would probably have said: ’faster horses’”. The same applies to Steve Jobs: he never held a customer survey in which people came told him they wanted an iphone.

Myth 3: Testers test software.
Truth: Testers should do end to end testing. They should also test the project plan, the vision document, the requirements, and so on.

Myth 4: Always write a complete set of requirements.
Truth: The 80/20 rule also applies to requirements.

Myth 5: Allow time for debugging.
Truth: Debugging is at the end. Instead, spend more time to get your requirements right.

Myth 6: Start with use Cases.
Truth: Start with understanding the problem.

Myth 7: With agile you don’t need requirements
Truth: You need requirements engineers for your vision document, your initial requirements set, your conversations, and your testing.

On a personal note, I am not enthusiastic about all of them. Some of them can hardly be characterized as a myth. For example, take number 5, allow time for debugging. No doubt I have been on the wrong projects for the last 20 years, but I have never seen projects where software was perfect and faultless when delivered by the programmers.

Something similar applies to myth number 3: Testers test software. Imho testers do test software. It is good to have a fellow worker review your products, and this has become standard practice in most big organizations. Lost of defects can thus be prevented. But he does have point when he says that testers can also have a look at the early documents. Personally I prefer to send early documents also to testers - if they are already known.

Other things are what we in the Netherlands call "Open doors", things which are obvious. Myth number 7 is such an example.

But I think he does have a point with some of the others, such as the complete set of requirements (myth 4) and stressing the business problem (myths 1 and 6).