Relevant to Purpose?

When trawling for requirements, you are certain to come across some absolutely charming, well-stated, complete requirements that are perfect in all respects, except they are irrelevant to the purpose of your product. This happens on most projects. Users become enthusiastic and start adding every thing they can think of; developers add requirements because they want to make the product all-encompassing or just plain cooler. Unfortunately, this kind of irrelevancy quickly leads to requirements creep, with the probable result that the project runs significantly over time and over budget, and even then doesn't deliver the product it set out to build in the first place.

In Chapter 3, which covered the project blastoff, we discussed how to identify the purpose of the project and to write it down as quantified project goals. These goals serve as the arbiter of relevancy throughout the project.

Chapter 3, Project Blastoff, discusses how to define the purpose of the product.

To test a requirement for relevancy, compare its intention with the project goals. The test is fairly simple: Does this requirement contribute to the purpose of the project? Does this requirement help make the product, directly or indirectly, meet the project's purpose?

Does this requirement contribute to the purpose of the project?

As an example, imagine that you are working on the IceBreaker project and you come across this requirement:

The product shall maintain a lookup table of the times of sunrise and sunset throughout the year.

At first this requirement appears to be relevant. The product has to predict the formation of ice on roads, and ice usually forms at night. Thus this requirement appears to contribute to the project goal:

Project Goal: To accurately predict when ice will form on road surfaces and to efficiently schedule the appropriate de-icing treatment.

However, if we dig a little deeper, we discover that the temperature of the road surface actually determines whether ice will form, and road temperature is monitored and transmitted by weather stations. In other words, whether it is night or day does not override the actual temperature. Ice is perfectly capable of forming during the daylight hours. There is no reason for the product to have any knowledge of day or night.

Requirements can contribute indirectly to the product. Sometimes the requirement may call for the product to do something that has no immediate connection to the purpose; however, without this requirement, the product could not achieve its purpose. As an example, consider this requirement:

See section 8 of the Volere Requirements Specification Template in appendix B for a sample context model. Also refer to Chapter 3, Project Blastoff, for information on how to set the context.

Description: The product shall record the durations of truck activity.

At first glance, this requirement appears to have nothing to do with the goal of the product, which is to efficiently schedule trucks to treat roads with de-icing material. But look at the rationale for this requirement:

Rationale: De-icing trucks may not be scheduled for more than 20 hours out of each 24-hour period.

Now the reason for the requirement is apparent. The Quality Gatekeeper can allow this requirement to pass, because it makes a contribution toward meeting the goals of the project.

Also consider that many of the nonfunctional requirements contribute indirectly to the project's goals.

Irrelevant requirements should be returned to their source with a short explanation. Be prepared to invest a little time in this communication, as an "irrelevant" requirement may indicate that a stakeholder has misunderstood the purpose or signal that a new business area is opening. In other words, you have to make a judgment as to whether the requirement is truly irrelevant or the original scope has become incorrect because of business changes.

The scope of the product also determines relevancy of the requirements. The scope results from making decisions about the product use cases. This effort should lead to section 8 of the requirements specification, which contains a product context diagram showing the flows of information between the product and the actors/adjacent systems. You can use these flows as a test for relevancy.

For example, suppose that you are given the following potential requirement. Does it fit within the scope we have defined for IceBreaker?

The product shall record the overtime worked by the truck drivers.

Look at the product boundaries. A product context model shows the boundaries of the product by the flows of information that enter or leave the product. Compare the preceding requirement with the boundary flows. Do any of the flows have anything to do with recording truck drivers' working overtime? Are there flows that indicate the product is dealing with working hours? Is there anything on the context model that indicates overtime hours should be stored within the product?

Is every requirement relevant within the stated boundaries of this product?

In the IceBreaker example, nothing makes the overtime requirement relevant. There is no information flow that could possibly have any data content related to working hours. If you included this requirement, it would not connect to anything else in the product, and so would be redundant functionality.

When considering relevancy, pay particular attention to the following sections of your requirements specification:

• Users (Section 3): Who are you building the product for, and is it a product suitable for these users?

• Requirements Constraints (Section 4): Is the product relevant within the constraints? Have all the constraints been observed by the requirements?

• Relevant Facts (section 6): Have the requirements failed to account for any external factors?

• Assumptions (section 6): Are the requirements consistent with any assumptionsyou aremaking about the project?