Given some of the problems we've described in the earlier chapters, it seems clear that the development team is rarely, if ever, handed a perfect, or perhaps even reasonable, specification to use as the basis for system development. In Chapter 7, we learned about the reasons for this. One conclusion we can draw is that if we are not going to be given better definitions, we are going to have to go out and get them. In other words, in order to achieve success, the development team is going to have to play a much more active role in eliciting the requirements. As we'll discover, although we can delegate the majority of this responsibility to a senior lead, analyst, or product manager, in the end, the entire team will be involved at one or more points in the process.
It seems obvious that the development team will build a better system only if it understands the true needs of the stakeholder. That information will give the team the information it needs to make better decisions in the definition and implementation of the system. This set of inputs, which we call stakeholder or user needs, or just user needs, provides a crucial piece of the puzzle.
Often, these user needs will be vague and ambiguous. "I need easier ways to understand the status of my inventory" or "I'd like to see a big increase in the productivity of sales order entry," your stakeholder might say. Yet, these statements set a most important context for all of the activities that follow. Since they are so important, we'll spend some significant time and energy trying to understand them. We'll define a stakeholder need as
a reflection of the business, personal, or operational problem (or opportunity) that must be addressed in order to justify consideration, purchase, or use of a new system.
Interestingly, when interviewed about their needs or 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? The stakeholder has already translated the real need (productivity or safety) into a system behavior that they have reason to believe will solve the real need (see Figure 8-1). In so doing, the what ("I need") has subtly shifted the to the how ("what I think the system should do to address this need"). This is not a bad thing, as the user oftentimes has real expertise in the domain and real insight into the value of the feature. Also, because it is easy to discuss these features in natural language and to document them and to communicate them to others, they add tremendous richness to the requirements schema.
However, there is a caveat to this discussion, which is: 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 user's objectives even though the implementation delivered the feature that was asked for.
In any case, we find this high level of abstraction—these features—to be very useful and a 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.
Earlier, we defined 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.
Table 4-1. Features examples
| 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 2000 compatibility. |
Features are easily expressed in natural language and consist of a short phrase; some examples are shown in Table 8-1. 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.
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, 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 will be 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.
In order to help us better manage this information, we introduce the notion of feature attributes, or data elements that provide additional information about the item. 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, state, 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 (Table 8-2). 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.
So, let's move on to some team skills that will help us get the information we need. We'll start with interviewing (Chapter 9).
Table 4-2. Attributes of features
| Attribute | Description |
|---|---|
| Status | Tracks progress during definition of the project baseline and subsequent development. Example: Proposed, Approved, Incorporated status states. |
| Priority/Benefit | All features are not created equal. Ranking by relative priority or benefit to the end user opens a dialogue between stakeholders and members of the development team. Used in managing scope and determining priority. Example: Critical, Important, Useful rankings. |
| Effort | Estimating the number of team- or person-weeks, lines of code or function points, or just general level of effort helps set expectations of what can and cannot be accomplished in a given time frame. Example: Low, Medium, High levels of effort. |
| Risk | A measure of the probability that the feature will cause undesirable events, such as cost over-runs, schedule delays, or even cancellation. Example: High, Medium, Low risk level. |
| Stability | A measure of the probability that the feature will change or that the team's understanding of the feature will change. Used to help establish development priorities and to determine those items for which additional elicitation is the appropriate next action. |
| Target release | Records the intended product version in which the feature will first appear. When combined with the Status field, your team can propose, record, and discuss various features without committing them to development. |
| Assigned to | In many projects, features will be assigned to "feature teams" responsible for further elicita-tion, writing the software requirements, and perhaps even implementation. |
| Reason | Used to track the source of the requested feature. For example, the reference might be to a page and line number of a product specification or to a minute marker on a video of an important customer interview. |