Defining Scope with Feature Levels and Events (Scope Part 2)

In part 1 of this three-part series, adapted from my book More about Software Requirements, I described the importance of documenting the scope of each software development project or iteration. The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.

Customers, marketers, and developers often talk about product features, but the software industry doesn’t have a standard definition of this term. I define a feature as: “A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective.” Features are product capabilities that a user can recognize, as opposed to capabilities that the product needs to have “under the hood” but aren’t visible to end users. Marketing materials often state the features that the new (or improved) product will offer to the customer. Therefore, feature lists help customers make purchase decisions.

You can think of each product feature as having a series of levels that represent increasing degrees of capability or feature enrichment. Each iteration or product release implements a certain set of new features and perhaps enhances certain features that were partially implemented in earlier releases. One way to describe the scope of a particular product release, then, is to identify the specific levels for each feature that the team will implement in that release. A sequence of releases represents increasing levels of capability—and hence user value—delivered over a period of time. During requirements analysis, the analyst determines just which functional requirements must be implemented in a particular release to deliver the planned feature levels, beginning with the top-priority or foundational levels of the top-priority features.

To illustrate this approach to scope definition, consider the following set of features from our hypothetical cafeteria ordering system:

FE-1: Create and modify cafeteria menus
FE-2: Order meals from the cafeteria menu to be picked up or delivered
FE-3: Order meals from local restaurants to be delivered
FE-4: Register for meal payment options
FE-5: Request meal delivery
FE-6: Establish, modify, and cancel meal service subscriptions
FE-7: Produce recipes and ingredient lists for custom meals from the cafeteria

Table 1 illustrates a feature roadmap, which depicts the various levels for each of these features that are planned for implementation in forthcoming releases. FE-2 and FE-5 in Table 1 represent features that each have three enrichment levels, but there's nothing special about three levels. Some product features may have four or five levels of increasing functionality enrichment. Others might just have a single level that's implemented all at once, such as FE-1, Create and modify cafeteria menus, which the team will fully implement in the first release.

The full functionality for each of these features is delivered incrementally across the three planned releases. The analyst can also indicate dependencies between features or feature levels. As an illustration, the level of FE-2 scheduled for release 1 will let users pay for meals by payroll deduction. Therefore, the capability of FE-4 that lets users register for payroll deduction payments cannot be deferred to a later release, because the first level of FE-2 depends on the first feature level of FE-4. Understanding these dependencies is essential for effective release planning. Notice that this sample feature roadmap indicates that the team won’t work on feature FE-3 at all until the third planned release. Also, feature FE-6 is of lower priority than the others. We’d like to get it out in the first release if we can, but it’s okay to defer it to release 2 if necessary.

Table 1: A Sample Feature Roadmap

The feature level approach is the most descriptive of the four techniques I’m presenting for defining the project scope. The farther into the future you look, the less certain the scope plans become and the more you can expect to adjust the scope as project and business realities change. Nonetheless, defining the product vision and project scope lays a solid foundation for the rest of the project work. This helps keep the team on track toward maximizing stakeholder satisfaction.

The final scoping technique I’m going to describe focuses on external events the system must detect. Each event causes the system to produce a particular response. There are three types of system events to consider:

1. Business events, which are user actions that cause the system to respond in some way. The trigger that initiates the execution of a use case typically is a business event.

2. Temporal or time-based events, such as scheduled program executions. Examples are automatically producing a database extract at the same time every night or having an antivirus program check for virus signature updates once an hour.

3. Signal events, which could be input signals received from sensors or switches in a system that contains both software and hardware components.

Event analysis works well for real-time systems. Consider a complex highway intersection. It might include road sensors and cameras to detect vehicles (though sometimes they don’t seem to spot me when I’m on my motorcycle), traffic lights, buttons pedestrians can press to cross the street, pedestrian walk signals, and so forth. This system has to deal with a variety of events, including these:

• A sensor detects a car approaching in one of the through lanes.

• A camera detects a car approaching in a left-turn lane.

• A pedestrian presses a button to request to cross a street.

• One of several timers counts down to zero.

At the scope level, you can just list the external events to which the system must respond without worrying about additional details. For an iterative development approach, you can allocate the handling of specific events to different iterations or releases. This initial events list also leads nicely into more detailed functional requirements specifications, expressed in the form of an event–response table. Exactly what the system does in response to an external event depends on the state of the system at the time it detects the event. Table 2 presents a fragment of what an event–response table might look like for such a system. This sort of layout is an effective alternative to the traditional list of natural-language functional requirements, which can be tedious to read and review.

Table 2: Partial Event-Response Table for a Highway Intersection
 

Now that we’ve seen several methods for representing a project’s scope, in the final article in this series I’ll offer some suggestions about how to effectively manage the dreaded specter of scope creep.

Author: Karl Wiegers, Process Impact