Chapter - 12 - Fit, Criteria and Rationale

Fit, Criteria and Rationale

Formality Guide

A pleasing aspect (amongst many) of Kent Beck’s extreme Programming technique is its insistence on writing test cases before writing the code. The test case defines the yardstick that the implemented code must match. The fit criterion is the same thing: It is a yardstick for the requirement. By adding a fit criterion to the requirement, you are writing its test case.

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 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 outsource. 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.

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.

Scale of Measurement

Any requirement can be measured: All you must do is find a suitable scale with which to measure it. The scale of measurement is the unit you use to test the conformance of the product to its requirement. For example, if the requirement is for a certain speed of operation, then obviously the scale is time—microseconds, minutes, months—to complete a given action or set of tasks. For a usability requirement, you can measure the time needed to learn a product, or the time taken before achieving a level of competence, or perhaps even the error rate of the work done using the product. Scales of measurement exist for all sorts of qualities. Color can be measured by specifying its component colors as a percentage of cyan, magenta, yellow, and black. Loudness and softness of sound are measured in terms of decibels. An amount of light is measured in units of lumens. Typefaces can be measured by face names and point sizes. In fact, there is a scale of measurement for almost everything.

Product Failure

The fit criterion might be determined by asking your stakeholder, “What would you consider a failure to meet this requirement?” Suppose you have this requirement: Description: The product must produce the road de-icing schedule within an acceptable time. Clearly, the scale of measurement here is time. Your client can tell you how much time he thinks would constitute a failure. For example, the client would consider the product unacceptable if the engineer must wait for more than 15 seconds for the schedule to become available. This means you have the following fit criterion, with suitable business tolerances applied: Fit Criterion: The road de-icing schedule shall be available to the engineer within 15 seconds from when he makes his request for 90 percent of the times that it is produced. It shall never take longer than 20 seconds.

Standards

Sometimes numbers are not appropriate, or you can create a better fit criterion by citing a standard. For example, the requirement mentioned earlier that the product is “not offensive to any group” could be handled by citing your organization’s standards of conduct. Alternatively, your communications department might have standards for what is and what is not allowed to be said or displayed for public consumption. By citing that the product must comply with that standard, you are in effect setting the benchmark for lack of offensiveness.

Defining the Data

For example, within the Ice Breaker project requirements often refer to Road Section. If you look in the data dictionary, you will find this definition: Road Section = Road Section Identifier + Road Section Coordinates You can then expect to find a definition of each of the attributes—for example: Road Section Identifier = *Unique identifier for 500 meters of road. The maximum number of road sections per road is 10,000.* Another strategy for defining the data is to define each term as part of the fit criterion of each individual requirement. However, as you will usually reference the same term in more than one requirement, it makes sense to maintain a central dictionary that can act as a cross-reference between requirements. Your growing understanding of the data means that you can progressively build a business data/information model that specifies the essential stored data for the requirements you are specifying.

Graphic Fit Criteria

When writing fit criteria, the aim is to be as implementation neutral as possible, thereby giving the designers and developers the maximum amount of freedom in choosing how to meet each requirement. The problem is that natural language is inherently procedural (you are forced to write words in a serial order) and sometimes that order is interpreted incorrectly as part of the requirement. You might consider the following approaches.

Decision Tables

Suppose that your fit criterion defines the rate of discount that a customer should have depending on how long he has been a customer, what his cumulative spending is, and whether he is a member of the customer loyalty program.

Maintainability Requirements

Maintainability requirements specify expectations about the maintenance of the product. Usually the fit criteria for these requirements quantify the amount of time allowed to make certain changes. This is not to say that all maintenance changes can be anticipated, but where changes are expected, then it is possible to quantify the time allowed to adopt those changes. Fit Criterion: All functionality must be migrated to the new website with no more than 10 minutes of unavailability of the site.

Security Requirements

Security is too important to be left to the whims or the goodwill of the developers. Your organization probably has some security standards in place, either specific to the industry or specific to your type of product. It is important to know which standard applies and to include it in your fit criterion. Taking this step has an added benefit: CYA. If a breach occurs in the future, at least you can say your product complied with the standard.

Cultural Requirements

Cultural requirements, by their nature, are subjective and slightly more difficult to quantify. The fit criterion is usually based on who will certify the product’s acceptability. For example: Fit Criterion: The Shatnez Laboratory of Brooklyn shall certify that the product complies with the shatnez rules. Fit Criterion: The communications department shall give the opinion that the product displays no words or symbols that could be construed as religious or political.