Defining Measurable Requirements 

It is important to specify requirements as precise as possible. In addition, requirements should be measurable. For example, the phrase "XPDL (XML Process Definition Language) supported" does not represent a well-specified requirement. You may feel tempted to ask questions, such as: "Which XPDL version?" or "for what purpose?"

While software vendors do have feature-rich products, this does not mean that all features are equally well implemented. You may hear vendor representatives saying: "For us, abc is the main technology, everything else is just available as basic implementation, so that we can tick xyz on the marketing slides." 

To avoid falling into the trap of rudimentarily implemented functionality, defining measurable requirements is the path to follow. 

The Evaluation Specification Authoring Sub-Process 

Authoring an Evaluation Specification involves several process tasks, embedded in an iterative process. The first iteration receives the stakeholder-defined goal as input, and the last iteration produces a version of the Evaluation Specification that is ready for approval.

Here, we presume that you have obtained license keys which allow you to import and customize Evaluation Specifications and import Requirements from the Requirements Repository. Now, it will be a fairly straightforward task to come up with a first draft of an Evaluation Specification.

Once the first draft is available, it is good practice to distribute it among participants of the review team. Reviewers may provide comments via e-mail, for example, which the Evaluation Specification author will consider for the next draft version.

When the reviewers do not see the need for additional requirements and do not have any change requests, the Evaluation Specification may be considered stable and is thus ready for approval. Reviewers may be formally requested to vote in favor or against each Evaluation Specification draft version.