Features

Interestingly, when interviewed about their needs and requirements for a new system, stakeholders typically describe neither of these things, at least not in terms of the definitions we've provided thus far. That is, stakeholders often tell you neither their real need ("If I don't increase productivity in this department, I won't get my bonus this year" or "I want to be able to slow this vehicle down as quickly as possible without skidding") nor the actual requirement for the system ("I must reduce sales order entry transaction processing time by 50 percent" or "The vehicle shall have a computer control system for each wheel"). Instead, they describe what seems to be an abstraction somewhere between ("I need a new GUI-based order entry screen" and "I want a vehicle with ABS").

We call these high-level expressions of desired system behavior the features of a product or system. These features are often not well defined and may even be in conflict with one another ”"I want increased order processing rates" and "I want to provide a far more user -friendly interface to help our new employees learn the system" ”but they are a representation of real needs nevertheless.

What is happening in this discussion? In their minds, the stakeholders have already translated the real need (productivity or safety) into a system behavior that they have reason to believe will solve the real need (Figure 9-1). In so doing, the what ("I need") has subtly shifted to the how ("what I think the system should do to address this need"). This is not a bad thing since the user often has real expertise in the domain and real insight into the value of a prospective feature. Also, because it is easy to discuss these features in natural language, to document them, and to communicate them to others, they add tremendous richness to the requirements schema.

Figure 9-1. Needs and features are closely related

However, there is a caveat to this discussion: if the team leaves the discussion without an understanding of the need behind the feature, then there is a real risk. If the feature does not solve the real need for any reason, then the system may fail to meet the users' objectives even though the implementation delivered the feature they requested . You are right, but you still lose!

Features are a convenient way to describe functionality without getting bogged down in detail.

In any case, we find this high level of abstraction ”these features ” to be a useful and convenient way to describe the functionality of a new system without getting bogged down in too much detail. Indeed, we will drive most of our requirements activities from this "feature" construct.

We define a feature as

a service the system provides to fulfill one or more stakeholder needs.

With this definition, users' features can't be too far removed from their needs , and we have a handy way to start to define the system.

Our focus in understanding user needs is on eliciting and organizing the needs and features of the proposed system. Sometimes we'll get all needs and no features. Sometimes we'll get all features and no needs. Sometimes we won't be able to tell them apart. But so long as we are careful about the distinction in our own minds, we should, all the time, be learning valuable information about what the system must do .

Features are easily expressed in natural language and consist of a short phrase; Table 9-1 shows some examples. Rarely, if ever, are features elaborated in more detail. Features are also very helpful constructs for early product scope management and the related negotiation and trade-off processes. The statement of features does not entail a great deal of investment, and they are easy to describe and list.

Table 9-1. Examples of Features

Application Domain	Example of a Feature
Elevator control system	Manual control of doors during fire emergency
Inventory control system	Provide up-to-date status of all inventoried items
Defect tracking system	Provide trend data to assess product quality
Payroll system	Report deductions-to-date by category
Home lighting automation system (HOLIS)	Vacation settings for extended away periods
Weapon control system	Minimum of two independent confirmations of attack authorization required
Shrink-wrap application	Windows XP compatibility

Managing Complexity by Picking the Level of Abstraction

A system of arbitrary complexity can be defined in a list of 25 “99 features.

The number of features we permit ourselves to consider will effectively pick the level of abstraction of the definition. To manage the complexity of the systems we are envisioning, we recommend that, for any new system or for an increment to an existing system, capabilities be abstracted to a high enough level so that a maximum of only 25 “99 features result, with fewer than 50 preferred .

In this way, a relatively small and manageable amount of information provides a comprehensive and complete basis for product definition, communication with the stakeholders, scope management, and project management. With 25 “99 features suitably categorized and arranged, we should be able to describe and to communicate the gestalt of the system, be it a space shuttle ("reentry and reuse") or a software tool ("automatic defect trending"). In Team Skill 5, Refining the System Definition, these features will be elaborated into detailed requirements specific enough to allow for implementation. We will call those software requirements to differentiate them from the higher-level features. We'll deal with that need for additional specificity later. For now, however, we'll keep our thinking at the features level.

Once the set of possible features is enumerated, it's time to start making such decisions as " defer to a later release," "implement immediately," "reject entirely," or "investigate further." This scoping process is best done at the level of features rather than at the level of requirements, or you will be swamped in detail. We'll cover scoping in Team Skill 4, Managing Scope.

Attributes of Product Features

In order to help us better manage this information, we introduce the construct of feature attributes , or data elements that provide additional information about the feature. Attributes are used to relate the feature or requirements data to other types of project information. We can use attributes to track ( name or unique identifier, sponsor, history data, allocated from, traced to, and so on), to prioritize (priority field), and to manage (status) the features proposed for implementation. For example, the attribute priority could be used to capture the results of the cumulative voting in a brainstorming session; the attribute version number might be used to record the specific software release in which we intend to implement a specific feature.

By attaching various attributes to the features, you can better manage the complexity of the information. Although there is no limit to the types of attributes you might find useful, experience has demonstrated that some common attributes for features apply to most project circumstances (see Table 9-2 on the next page). In the remainder of this book, we'll use these attributes to help us manage the complexity of the feature and requirements data and to manage the relationships, such as dependencies, among the various types of system requirements.