Blog 5. Anxious requirement capturing

There are some areas within product development which are experienced as frightening. Capturing requirements is one. Requirements feel to be too powerful and risky to be stated by a single developer. In Sweden, as in many other countries, such powerful things must be handled by a group in consensus. Of course, a careful review by competent developers is beneficial and primarily essential. Still, even getting started to capture and document requirements brings too much anxiety.

As it always is in product development, the beginning of any action is wobbly. A developer has not everything clear from the beginning and must often start with blank paper. This is feeling pain because the team now will realize the shortcomings of its beginning. In addition to exposing oneself in a domain where you should be the expert, requirements are a bit challenging to describe understandably.

Back to home page

Questions that come up may be:

• Should I write them down by text, how to group them, etc. ?
• How to relate the overall requirement to detailed ones ?
• How to know when the coverage is enough, when can we finish capturing requirements ?
• Shall we separate functions from non-functional requirements ?
• Shall we capture use cases, and how to describe these ?

The above list can easily be longer !

You can see the result from anxiety, by taking a quick look at some produced descriptions. They can be called ambitions, proposals, ideas, offerings, services – anything but requirements. I agree, requirements are a bit difficult, and there are many crazy approaches in the literature. Contrary, Cpdm defines a few needed requirements, but not anything unnecessary. How all types relate is clearly explained, and how detailing is performed, and so forth.