Bad Practices - Part IV - Speculative & Vague Terms

On speculation
Avoid using generalizations and speculative words such as often, normally and typically. A requirement must not include any speculation at all.

On dictionary.com, a requirement is defined as, "Something that is required; a necessity." On Wikipedia, the definition is, "a singular documented need of what a particular product should be or do." The common theme is that requirements define needs. When defining a solution to a problem, speculation has no place. It is either do or do not, there is no maybe (or try, as Yoda in The Empire Strikes Back would say.)

On being vague
One common mistake that people make when taking down requirements is to use informal and unverifiable terms. What do the terms: user-friendly, flexible, easy-to-use, fast, and intuitive mean to you? Do you think these terms mean the same thing to someone else? Generally, no! So when different people see these types of terms, people will generate their own interpretations on what they mean. The net result is that the requirement is not clearly understood.

Look at the picture below. What do you see? Do you think other people may see something different than you? If two people can see the exact same picture but come up with different interpretations of it, what would make anyone think that people can read the same requirement and (because of subtle vageries) come up with the same understanding?

No jargon please

Another suggestion I have is to avoid using the jargon of the company one is working with. While understanding the jargon and nuances of a specific company shows some level of understanding, one must realize that jargon does not mean anything to people who are not familar with the company. If a company employs a lot of contractors to help with projects, using excessive jargon increases the learning curve.