I have always been a believer in pushing the development team to the very edge of their capabilities, resulting in products they did not even believe they could create. However, there is a fine line between pushing the team to the limits of their abilities and asking for the impossible, or for something the organization is not able to support with the right resources. The result will be a frustrated development team and friction between the development team and the marketing/business team.

While this is obvious, it is also worth emphasizing that any requirements that are documented and given to the development team must do the following:

Requirements that are concise are easy to read and understand by all interested parties, including management and development teams. They also help minimize ambiguity in terms of what needs to be accomplished, and they identify the problem (or problems) that must be addressed. To be concise, it is also best to limit your requirements to be no more than 30-50 words.

If you are, or ever were, an engineer or are technically minded, you will find this to be particularly challenging. When faced with a problem, it is very easy for us to jump to an immediate solution or potential solutions without fully understanding the requirements. Even though you think you know what needs to be built to meet the perceived customer's issue, one needs to focus on why the customer needs it, and let the development team design the solution. In the next section, we will talk about how you must describe the "what's," and the development team will be tasked with how they will determine the "how's."

Your requirement statement must fully articulate what the customer or user will be able to do, accomplish, or experience with the product or service you will create as part of this development. If at all possible, it is also good practice to include forms of measurement whenever possible.

You need to write requirements using grammatically correct language that is logical and easily understood, with the intent that all members of the team will have a clear and consistent understanding of what is being asked for in the requirement statement. Strive to remove all vagueness and ambiguity from the requirements you write, so that there is only one interpretation from anyone on the development team who might review them.

Another characteristic that is worth checking is to ensure the requirements you write are also consistent with your business strategy. If your requirements run counter to the business strategy, your odds of getting approval for your project are diminished.

As we mentioned in the introduction to this section, the main reason we write requirements is to communicate to the development team and the rest of the organization what the customer requires, and what needs to be done to satisfy the market. If we cannot verify that what ultimately is delivered to the market meets the original needs expressed by the customer, we will have no way of knowing whether we have been successful or not.

Each requirement statement needs to be able to tie back to a customer input that you have collected during your research.

The requirements must be written so the final product can be tested, analyzed, inspected, or demonstrated so as to ensure that it meets the needs of the original customer input. As an example, "The cable modem will be able to download at a minimum of 100 Mbps." Only in this way is it possible to verify whether the product or system met the requirements or not.

Each requirement needs to be a single specific market need. If the requirement statement you write contains two or more requirements, it must be rewritten to convey only one thought, or the requirement statement must be separated into multiple requirements. If your requirements say, "The computer must support a USB and an HDMI output," these needs must be separated and written as two unique requirements. If not, you run the risk of satisfying only a part of the requirement when the project is complete, and you may end up only solving a portion of the market needs.

While many customers will consider all their requirements to be the top priority, that is far from possible. For a list of requirements to be actionable by the organization, there must be a priority assigned to each requirement, so that the development team can understand the relative importance of each individual requirement statement to the others.

The preceding two sections were necessary to provide you with an understanding of the types of requirements, as well as what characteristics make for a good requirement. If you have responsibilities for the product management function and are writing the MRD, this section should be a good reference for you.

We are now ready to take the output from our affinity exercise and turn it into something actionable by the organization. Actual requirements that engineers can use to develop your new product.