To clarify what accurate wording means, let us start with a few examples of inaccurate wording, which were just found on the Internet:

1. "Granular Privileges"
2. "Ease of implementation"
3. "Flexible credit terms and debt chasing methods"
4. "Is a general purpose Graphical or Statistical modeling tool included in the proposed software?"

As you can easily see, all of the above example statements leave much room for interpretation. You may just as well come to the conclusion that these statements are not requirements at all.

I will not go into detail here about how to write high-quality requirements. There are excellent textbooks (e.g. "Software Requirements, Second Edition" by Karl E. Wiegers) or specification templates (e.g. "Volere Requirements Specification Template" by James and Suzanne Robertson) that provide valuable guidance. We followed most of those recommendations when we designed the knowledge data model, which forms the basis for the Evaluation Specification and Requirements Repository.

Who suffers from bad requirements? 

1. The specification author: She/he has to respond to questions and clarify what was meant.
2. The vendor representative: She/he may need to get back to the specification author and ask questions for clarification. However, she/he may not ask and just interpret things in the vendor's favor.
3. The members of the evaluation committee: They may be confused when they attempt to relate vendor statements to requirements and need to assign scores.

It is probably safe to say that just about everyone involved in the evaluation and selection process suffers from poorly specified requirements. What a waste of time and money!

It is also safe to say that it takes more time and effort to remedy the effects of poorly written requirements than it takes when things are done right in the first place.