John asks two people a question: "What's the weather like?" Both respond with 'Fine'. To John who lives in California, 'fine' means that it is warm and the sun shines. To Sally, who lives in Scotland, 'fine' means it doesn't rain. To Ali, who lives in a desert, 'fine' means that it does rain. As this simple example indicates, a sketchy question like this provokes misunderstandings. 

In the context of a software evaluation, Evaluation Specification author and (pre-)sales consultants with software vendors must have a mutual understanding of the meaning of requirements and interpret them in the same way. To make sure that this can actually happen, care must be taken to ensure that requirements meet certain quality criteria.

To better understand what these quality criteria are, let us first examine a few examples. Sometimes, you can see phrases, which are labeled as requirements, such as:

• "Granular privileges"
  
• "Flexible credit terms and debt chasing methods"
• "Can the proposed system export to XML?"

The first example looks much too broad in scope. Would you really expect any potential offeror to respond with a "no"? The (pre-)sales consultant would not know what exactly your requirements are, but she/he would feel on the safe side to respond with "yes".

As it turns out, you may just as well have omitted the requirement. Clarification is needed later in the evaluation process whether your actual detail requirements are met. You will find yourself asking questions that refer to detail requirements which are in your mind, but are not included in the Evaluation Specification. In addition, when it comes to actual software comparison, you do not have a clear measure that tells you whether this requirement is met or not. This is because the requirement is not measurable.

In terms of effort, you generate more work compared to writing high-quality requirements from the beginning. Although you may get the Evaluation Specification finished within a relatively short period of time, you actually put work off until later when you start with product evaluation and comparison. Further time-consuming inquiries targeted at one or more vendors will be necessary until you can establish that the products do meet or do not meet the finer-grained requirements.

The second example broadly falls into the same category as the first one. It is simply not clear enough what "flexible credit terms" and "debt chasing methods" are. Although you have a clear picture of what it means for your organization, (pre-)sales consultants may have different ideas. You may even be "talking about different things" using the same terms.

The third example is phrased as a question. A vendor's (pre-)sales consultant would not know what should be exported to XML, and what XML version the requirement refers to.

Frankly, if you were a (pre-)sales consultant that receives an RFP which contains a lot of requirements similar to the above examples, what would you do? You work under typical time constraints, and it is no wonder that you interpret requirements as liberally as possible. Your company wants the business. Given your liberal interpretation, if you can put in a "yes", you do it.

The solution, which saves the requirements author and (pre-)sales consultants from extra work, is to write high-quality requirements. The number of requirements in your specification will invariably increase, but so will the overall quality of an Evaluation Specification, and thus of a Request for Proposal (RFP).

Three prominent characteristics of high-quality requirements are:

Logically atomic: The requirement refers to a single entity, a single piece of functionality, or to a single quality characteristic (i.e. aggregation of multiple requirements into a single requirement must be avoided).

Unambiguous: The requirement allows a reader to draw only one interpretation of it.

Measurable: The requirement allows to test whether a given solution satisfies the requirement.