Grouping Requirements

We suggested earlier that you group the functional requirements by use case. The advantage achieved by doing so is that it becomes easy to discover related groups of requirements and to test the completeness of the functionality. Nevertheless, sometimes other groupings may prove more useful.

The word "feature" springs to mind here. The meaning and scope of a feature varies depending on the situation. It could be as small as turning on an indicator light or as large as allowing the user to navigate across a continent. Indeed, the feature itself is often important from a marketing point of view. But different features have different degrees of value to the organization. For this reason, you might find it necessary to discard or radically curtail features. Grouping the requirements by feature makes it easier to manipulate them and to adjust your specification when the market (or the marketing department's request) changes. Bear in mind that a feature will usually contain requirements from a number of different product use cases. Thus, if you are grouping requirements by feature so that you will be able to trace changes from and to the business, it makes sense to be able to group them by product use case as well (as illustrated in Figure 7.4).

Figure 7.4.

A hierarchy of requirements. The work context is the highestlevel statement of requirements; it is decomposed into the next level, the business events. The level below the business events comprises the product use cases, each of which is decomposed into a number of product use case steps. The lowest level includes the atomic requirements, each of which you can trace back to the higher-level use case step(s). Another possible hierarchy groups atomic requirements into features; such a grouping is often used by stakeholders from marketing or product version planning.

It helps to think of the atomic requirements as the lowest level of requirement specification. You group these into a requirements hierarchy for three reasons:

• To be able to involve stakeholders with different depths, breadths, and focuses of interest

• To help you discover the atomic requirements in the first place

• To be able to deal with volume and complexity

A leveled requirements specification meets these expectations as long as you have a nonsubjective traceable path from one level to another. We have see people run into trouble when they create "high-level requirements" and "low-level requirements" that do not have a formal, nonsubjective link. The practice of attempting to define high- and low-level requirements creates problems and arguments because "high-level" and "low-level" are so subjective. To avoid such conflicts, we recommend that you work with a nonsubjective hierarchy: work context, business event, product use case, product use case step, atomic requirement.