Rationale

The rationale is the reason, or justification, for a requirement. We have found that attaching a rationale to the requirement makes it far easier to understand the real need. Quite often, stakeholders tell you a solution rather than their real requirement. Or they tell you a requirement that is so vague as to be (for the moment) unusable. In the example given previously, the client asked for a "nice" product. The justification, or rationale given, was the users would readily adopt the product.

Suppose the rationale had been different. Say, instead of ready adoption, the client gave you a rationale that indicated a "nice" product is so easy to use that its users make fewer errors than they do with the current product. The corresponding requirement has a different meaning, and the resulting fit criterion is completely different.

The rationale is not only a guide to help you find the fit criterion, but also a means to help you know when you have several different requirements masquerading as one. One stakeholder says "nice" means the product is pleasant to use, another says "nice" means the product is exciting, and yet another says a "nice" product encourages users to make return visits to it. In this case you have three different requirements, each with its own fit criterion that measures the desired property.

When asking stakeholders for their rationale for a requirement, you might appear to be like the child constantly asking a parent, "Why?" So be it. That is the role of the requirements analyst: to ask why and keep on asking why until you understand the meaning of the requirement. But you haven't finished yet, because you still have to pass along a way to measure the requirement's real meaning. That is why you derive the fit criterion.

You have to pass along a way to measure the requirement's real meaning.

To find an appropriate fit criterion, start by analyzing the description and rationale you have established for the requirement.

Description: The product shall make it easy for a buyer to find his chosen music.

This requirement is fairly subjective and slightly ambiguous. The rationale provides more information on what is needed:

Rationale: Music buyers are used to convenience and will not tolerate slow or awkward searches for their chosen tracks.

Now you know the requirement is about speedwhich is fairly easy to quantifyand awkwardnesswhich is about complexity and perceived ease. For the speed component, a time limit for a search is an appropriate measurement. Suppose your market research people tell you ten seconds is the limit of the target audience's tolerance. To be better than the competition, you are shooting for six seconds.

For the awkwardness component of the fit criterion, your ergonomics people and your market research personnel both say that buyers must be able to find a piece of music in no more than three actions (an action here means a click, a gesture, a menu selection, or any other conscious action on the user's part).

Your measurement for these things would be this fit criterion:

Fit Criterion: The average music buyer shall be able to locate any piece of music within six seconds, using no more than three actions.

Some fit criteria may, at first, be unattainable because of business or real-life constraints. Or your client may not be willing to spend the amount required for the implementation to meet the criterion. Thus sometimes you might negotiate an adjustment to the fit criterion to allow for the product's operating environment, intended usage, and client's budget. Think of these adjustments as business tolerances. As we are certain that some of the intended users of the product will be below-average performers, we would adjust the fit criterion to read as follows:

Fit Criterion: Ninety percent of music buyers shall be able to locate any piece of music within six seconds, using no more than three actions.