For example, consider the following requirement: "Executable business process definitions shall be instantiated by the IBM Websphere Application Server version 6.0 or higher".

What is wrong with the above requirement?

In terms of wording, there is nothing wrong. The requirement is concise and precise. There is no space left for inadvertent misinterpretation. 

However, the requirement is tied to a specific implementation, namely IBM's Websphere Application Server. 

There is room for improvement. It is generally a good idea to focus on concepts rather than implementation. Following that path, the requirement might read: "Executable business process definitions shall be instantiated by a business process engine". 

To be fair, an additional requirement is needed that establishes the link to the execution environment. For example, you may think of the following requirement: "The business process engine shall execute in IBM Websphere Application Server version 6.0 or higher". However, if you do not mandate a specific execution environment, you might alternatively specify: "The business process engine shall execute in an application server, which has achieved J2EE 1.4 compatibility certification".

It is generally advisable to specify requirements focused on concepts. Concentrate on the "what" rather than the "how". When necessary, you can associate "what" and "how" with just one requirement. This is particularly useful when there is more than one possible execution environment. For example, a message engine may execute in an application server, or it may run in a purpose-specific message server.

The following table provides just a few example associations between concept and implementation.