« Top Ten Business Process Optimisation Failures | Main | Use Case Specification Example »



Feed You can follow this conversation by subscribing to the comment feed for this post.


Thanks for the reminder! It can't be repeated too often.

I have to admit though, that as a tester, I like vague requirements. At first, they tend to frustrate me because I don't know what to do about them, but then I realise that here's a good indication that there's a problem around somewhere.

I usually need to dig up a little information: What did the customer mean when he wrote this vague requirement? I can find that by asking him, or if he is not directly available, by interpreting the document, trying to put myself in his place.

Bugs and other quality issues are often a direct result of vague requirements.


John Hansen

Hi Anders

Thank you very much for your comment. I totally agree. Vague requirements are often the problem. I can see your point that the testers can elaborate the vague requirements and dig up the "true" requirements. However, in fixed price/ fixed scope projects it might be too late in order to avoid fights with a supplier - which also means that the testers should be part of the requirements review sessions, which they often are not - which is a shame because it will definitely enrich the requirements.

The comments to this entry are closed.

Welcome to All About Requirements. I hope you are visiting because you, just like me, are absolutely passionate about business process analysis, use cases, and requirements in general. Thank you for visiting.
- John