Summary

In this chapter, we've described the concept of a product or system feature, which is a simple but critical construct in requirements management. Features are easy to elicit, easy to document, and easy to maintain. They are user friendly, and they can be devoid of technical jargon that could lead to misunderstandings. Moreover, if we force ourselves to write them in such a way that a maximum of 25 “50 features can fully encompass a system or incremental release, then we have a simple and elegant way to begin to describe what a system needs to do, as well as how much time and effort may be required to do it.

So, let's move on to developing some team skills that will help us find the necessary features of our proposed system. We'll start with interviewing (Chapter 10).

Table 9-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	Assists in managing scope and determining priority. 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. Example: Critical, Important, Useful rankings.
Effort	Helps establish realistic schedules, goals, and costs. Estimating the number of team- or person-weeks, lines of code or function points, or just the general level of effort helps set expectations of what can and cannot be accomplished in a given time frame. Example: Team months, or Low, Medium, High levels of effort.
Risk	Indicates a measure of the probability that the feature will cause undesirable events, such as cost overruns, schedule delays, or even cancellation. Example: High, Medium, Low risk level.
Stability	Reflects a measure of the probability that the feature will change or that the team's understanding of the feature will change. This attribute helps establish development priorities and determine those items for which additional elicitation is the appropriate next action. Example: High, Medium, Low stability.
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. Example: Version 2.3.
Assigned to	Indicates who will be responsible for implementing the feature. In many projects, features will be assigned to "feature teams " responsible for further elicitation, writing the software requirements, and perhaps even implementation.
Reason	Helps 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.