Requirements worst enemy is vague language. Notice that requirements can be written at different detail level (See post about levels). However, writing requirements on a high-level does not excuse the use of vague language.
When the requirements are written in vague language it opens op for interpretation and that is a source for arguing and discussions. Especially discussions concerning: “did the supplier deliver what we asked for”.
As a rule of thumb, you should write your requirements at a detail that enables you to verify that you get what you asked for.
How can you make sure that your requirements are not vague? I have three techniques:
1) Reach the right detail level. This is related to the rule of thumb. Always, always write at a detail that enables you to verify that you get what you ask for. Even in agile projects? – yep! Even in agile projects. However, this is only true for relevant requirements, which leads to the next technique
2) Remove irrelevant requirements. Is it for example relevant to specify that all text buttons should be yellow? If not remove the requirement, or forget about anything agile. If yes, keep the requirement.
3) Play the devil’s advocate. Either alone or helped by a colleague – read your requirements and try to find words or phrases that could be misunderstood or misinterpreted. In other words: avoid the forbidden vague words – a list of forbidden words is listed at the end of this post.
A few examples of vague requirements:
“The system user interface should be state-of-the-art”
What is state-of-the-art? Does state-of-the-art mean the same to you as it does to me? What does ‘should’ mean? Does it mean what it should be state-of-the-art IF it is possible?
The trick is to make the requirement more objective. If state-of-the-art to you mean that the user interface should follow a specific GUI standard or if it should be developed using Microsoft SilverLight elements or something similar, then that is what you need to require.
“Then showing user information all relevant information about the user must be shown”
What is relevant information? Details please! Please list the attributes.
Examples could go on and on. Below is a list of potential “forbidden words” which are examples of words that are not precise in their description, you could add more works to that list yourself.
About
Applicable
Approximate
Bad
Best
Best Practice
Between
Clearly
Could
E.G.
Easily
Easy
Effective
Efficient
Enable
Etc.
Excellent
Fast
Finest
Good
High
His / Her
Ideal
Include But Shall Not Be Limited To
Least
Like
Low
Maximize
May
Minimum
Mostly
Relevant
Same
Should
Similar
So As
State Of The Art
Sufficient
Support
Support
Target
User Friendly
Worse
Would
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.
/Anders
Posted by: Andersdinsen | 18/09/2011 at 07:55 PM
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.
Posted by: John Hansen | 23/09/2011 at 11:12 AM