Archive for June, 2005

Requirements document vs. Story Cards

June 5, 2005, No Comments

This article was heavily inspired by Lukas Kraus talk about: “Requirements: Clear and testable”. He pointed out that it is very important to have a test-manager on the requirements gathering team. His job should be to make sure that requirements are detailed enough that they can be tested later.

I agree that being able to test requirements is important. I don’t agree that the way to achieve this is by writing more details into the requirements document.

Having everything written down in great detail is one extreme. Let’s have a look at the other extreme.

Some might have heard that extreme programming doesn’t use a requirements document. That’s true. Partially.

In extreme programming requirements aren’t written down in details. They are vague. Written on a card, that might even be thrown away later.

That has its reasons of course. One is that if the feature turns out not to be important, you didn’t waste time on defining it. Another one is to delay fixing the details until the last possible minute - increasing flexibility and helping to make good decisions with regard to the things that were already built. These two ideas were adopted from lean manufacturing.

The nature of the story card becomes clear once it is time to write the code for it. Before any code is written, a conversation takes place. The customer explains exactly what he wants (face to face).

Now you might wonder how the tester (or anybody) is supposed to know what was discussed and what the software is supposed to do. That is after all, the big advantage of a requirements document. The answer has two parts. First, the tester is part of the discussion. Second - and let me emphasize this - no user story is complete without automated test cases. The test cases if properly defined become the requirements document. Not just any kind of requirements document. It is an executable requirements document.

Yes, I mean that. You click a button and your requirements document tells you exactly which features are currently correctly implemented.

Can your requirements document do that for you?

see also: Testing unclear requirements for an example