Chapter 12 Fit Criteria and Rationale

Fit Criteria and Rationale, we show how measuring requirements makes them unambiguous, understandable, communicable, and testable.

Fit means a solution completely satisfies or matches the requirement. That is, the solution does exactly what the requirement says it must do or has the property the requirement says it must have—no more and no less. To test whether the solution fits the requirement, however, the
the requirement itself must be measurable.

Formality Guide

Rabbit projects
Rabbits use a blog or wiki to discover the non-functional requirements. For each of the non-functional requirements yielded by the blog, we now suggest deriving the appropriate fit criterion,
confirming it with the stakeholder, and writing the test case using that fit criterion.

Horse projects need to have a precise and easily shareable understanding

of the meaning of requirements. It has been our experience that when the

project has multiple stakeholders—which is the norm for horse projects—

different stakeholders assign different meanings to requirements. Adding a

rationale and a fit criterion to each requirement means it is virtually impossible

for misunderstandings to occur. We recommend that horse projects

include both of these in their requirements.

Elephant projects must use rationales and fit criteria. These projects are

forced to produce a written specification to be handed on to some other

party, either another part of the organization or an outsourcer. Having a

specification containing only unambiguous, testable requirements is crucial

to elephant projects,

if the other party is to understand and then deliver the

correct product.

Why does fit need a criterion?

When you have a requirement for the product to perform some function or

to have some property, the testing activity must demonstrate that the product

does, indeed, perform that function or possess the desired property. To

carry out such tests, the requirement must have a benchmark such that the

testers can compare the delivered product with the original requirement.

The benchmark is the fit criterion—a quantification of the requirement that

demonstrates the standard the product must reach.

Possibly the most challenging part of testing a requirement against an

agreed-upon measurement is defining the appropriate measurement for the

requirement. It is tricky, but certainly not impossible.

Let’s suppose that your stakeholder is inexperienced and asks for a product

that is “user-friendly.” What that phrase means to you is likely not the

same thing as what it means to the stakeholder. However, once you can

measure “user-friendliness”—that is, put numbers against it—then you and

the stakeholder can arrive at an identical understanding.

The Rationale for the 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 may tell you their perceived

solution to the problem, rather than their real need. Alternatively, they may

state a requirement that is so vague as to be (for the moment) unusable. In

the example given previously, the client asked for a “user-friendly” product,

but you could make sense of it when you learned that the rationale was that

the project needed the users to readily adopt the product.