Davis defines requirements triage to be
the art of selecting the right requirements to include in the next release of your product
Making such a selection is almost always necessary, simply because the desired schedule/budget will not allow for the satisfaction of all the requirements identified during elicitation.
Although many people (with a diverse set of titles) engage in requirements triage, few ever acknowledge this responsibility. Indeed, in most organizations, requirements triage is performed implicitly and not very effectively. (Davis claims that it is done "by some combination of intimidation, inertia, osmosis and incompetence", whatever that means.)
Here are some typical scenarios:
Other names for requirements triage are release planning, requirements prioritization, optimal attainment of requirements, requirements negotiation, and requirements selection. But Davis likes the word "triage" because of the analogy to what EMT's do at the site of a disaster involving physical injuries to a number of people.
Davis puts requirements into three broad categories:
Requirements triage is the most interdisciplinary of the three areas of requirements (recall that the other two are elicitation and specification), requiring interplay among those people responsible for
Successful requirements triage requires knowledge of
Requirements triage should be performed for every planned release of a product, so as to decide which requirements to try to satisfy in that release. (See Figure 3-1, page 67.) Also, requirements triage activities should be repeated each time new requirements arise or new resources become available.
Most organizations don't, so why should yours?
Davis claims (page 68) that
Performing triage is the most effective way to achieve just enough requirements management. ... If you don't do it explicitly, it will occur implicitly [in which case] you are leaving the success of your project to pure chance.
According to Davis:
Basic triage is the art of achieving a balance between requirements, development cost, development schedule, and risk. It is the minimal amount of triage that should be performed when trying to accomplish software development in a just enough manner.
He likens it to performing a balancing act on a three-person seesaw, with Requirements, Schedule, and Cost sitting on the three boards. (See Figure 3-2, page 68.)
To perform requirements triage, at a minimum you must know, for each requirement, its relative importance (to the customer) and the cost of satisfying it. (Later in the chapter are described several other attributes that are also important, but less so.)
Numerous techniques exist. Interestingly, the most straightforward one —asking the customers to do it&mdash does NOT work, because most of them will tell you that all requirements are equally critical!
Three better approaches are the hundred-dollar test, the yes/no vote, and the five-way priority scheme. (These are all based upon collecting opinions from a collection of stakeholders, preferably one in which each stakeholder group is adequately represented.)
It would be silly to spend the same amount on each requirement, as then your "votes" would have no influence on the final result.
The total amount spent on each requirement determines that requirement's priority.
A weakness of this approach is that it can be "gamed" in a couple of different ways:
This trick would have a much smaller chance of working if the maximum value that could be spent on a single requirement were severely limited.
Obviously, under this approach the "Pet Requirement" game described above is not possible.
Because of its coarseness, there are at least two major problems with Yes-NO voting:
It can be quite useful to record all the votes of all the stakeholder representatives, rather than simply the sums for each requirement. That's because, for example, if a requirement earns a total near zero because most votes were 0 (with maybe a few +1's and -1's), that means something different than if there were lots of +2's and lots of -2's! In the former case, the requirement would (most likely) not be included in the baseline. In the latter case, perhaps what is needed are two different versions of the product!
What if some stakeholder (groups) are more important than others? In this case, you can weight the votes. That is, assign a "weight" (a positive real number) to each participating stakeholder representative according to the importance of the group that (s)he represents. Then multiply each of her/his votes by that weight.
Among the possible reasons for such disagreement are
In this case it is important to record, for each such requirement, its priority as judged by each stakeholder class (as opposed to recording only its "overall" priority as computed by averaging over all stakeholder classes).
In this case the requirement should be refined (possibly by devising a list of sub-requirements) so that it becomes more well understood and so that (possibly) the basis of disagreement is discovered.
Several books address this issue; in short, what they all say is
Among the possible reasons for such disagreement are
In this case the requirement should be refined (possibly by devising a list of sub-requirements) so that it becomes more well understood and so that (possibly) the basis of disagreement is discovered.
Requirements are not, in general, independent of one another. Rather, various releationships exist between them. Among these are the following.
Sometimes the dependency can be in both directions:
A: The system shall provide the Fiends and Famine capability.
B: The system shall bill customers $3 per minute for using
the Fiends and Famine capability.
In class, not only did no one know what "Fiends and Famine" refers to, but no one could offer an explanation as to how A depends upon B. Moreover, it was agreed that, in a certain way of looking at it, nor does B depend upon A, because it is conceivable that the system could be designed to charge $3 per minute for a certain capability, even if that capability is not offered by the system!
This type of relationship between requirements should be recorded (see Figures 3-6 and 3-7 on page 79) and then be considered during triage. Indeed, if A has a necessity dependence upon B, it would make no sense to decide to satisfy A but not B.
Taking account of this type of dependency is important in estimating the implementation cost for a set of selected requirements. In this example, Davis attaches a -2 value to this dependency, meaning that satisfaction of B reduces the cost of satisfying A by two units. (See Figure 3-8 on page 79.)
The example in Figure 3-9, page 80, has
A: The system shall enable the user to specify that the displayed list be ordered in any of a wide variety of ways.
with B, C, and D each being similar, but indicating one particular way of ordering (alphabetic, chronological, and employment seniority, respectively). (Note that Davis's wording of A has been improved to remove ambiguity; the original wording could be interpreted to mean that "a wide variety of ways" refers not to the ordering of the list but to the user having choices as to how to specify the ordering.
A special case (sort of) of subset dependency is cover dependency, in which A's children requirements completely describe A itself. (Mathematically speaking, for this to make sense we must consider the dependency to be between a requirement and a set of requirements, as opposed to being between two requirements.)
An example would be to rephrase requirement A above to say A: The system shall enable the user to specify that the displayed list be ordered either alphabetically, chronologically, or by employment seniority.
Now, of course, B, C, and D "add up" to A. (See Figure 3-10, page 81. But the Effort Estimates don't seem to make sense, as the parent requirement effort is less than two of its children!)
If, in the course of triage, we choose all the children of A (where A has cover dependency on its set of children), then we have also chosen A itself. If, on the other hand, we choose A, we have also chosen all of A's children.
In some cases, satisfaction of one requirement makes the other one's priority "negative" (meaning it should not be satisfied). (A special case would be two conflicting requirements.)
In other cases (such as when two requirements arise from the same feature (i.e., high-level requirement) and hence to satisfy one without the other would seem incongruent), inclusion of one requirement could increase the priority of another. Perhaps an example (for a document-preparation applicatoin) would be spell-checking and grammar-checking, because both contribute toward the "feature" of "error checking".
This kind of dependency makes triage tricky, because it means that the priority attached to a candidate requirement is not static, but rather depends upon the set of requirements currently in the "tentative baseline".
As an example of where choosing one requirement reduces the priority of another, how about
A: ??
B: ??
How to document dependencies?
However it is done, it is important that, for any given requirement,
we can easily find others on which it depends or which depend upon it.
This suggests the use of an automated tool.
Indeed, a number of requirements tools have been developed.
See the web site
www.incose.org for a list.
Davis highly recommends that triage be used for planning not just the
next release but at least one after that. If you plan for only one
release, decisions on what to include and what not to become strictly
binary, making it more difficult to compromise.
Having engaged the stakeholders (by the means discussed earlier) to
determine a relative ranking of requirements, how does one go about
deciding which requirements to include in the "baseline".
Of course, not all candidate requirements can be included, because
the desired schedule and budget will not be sufficient to allow it.
Nor is it simply a matter of including the requirements, one at a time,
from most to least important, until the schedule and budget are
consumed. Why not? In part, because of the interdependencies among the
requirements.
Stuff missing here.... See pages 84-97.
Omitted. The focus is mostly upon business/marketing concerns,
which is more than a software engineer or computer scientist should
have to deal with!
Triage is completed (but I thought that it was never finished!!)
once it has been decided which subset of candidate requirements
to try to satisfy in the next release of the product.
In addition, it should have resulted in estimates of
(see Figure 3-36, page 116)
(See the same figure (3-37) for a list of other facts/estimates relevant
to products for internal use.)
Typically, the chosen requirements are listed in a preliminary
version of the requirements document, which is expanded in the
subsequent specification phase.
The other pieces of information end up being documented in
a business case document, a preliminary project plan,
or a preliminary marketing plan.
Paying too little attention to triage is likely to result in trying to
build a system that is "too big" to fit into your budget and/or schedule.
Paying too much attention to triage could result in priorities changing
before you get to specification!
The secrets of doing just enough triage are these:
Performing Triage on Multiple Releases
Making the Triage Decision
Advanced Triage Techniques
The Result of Triage
If advanced triage was performed, and the product is intended
to be sold (as opposed to having been custom built for a particular
customer), several other facts/estimates should have been formulated
(see Figure 3-37, page 117):
The Secrets of Just Enough Triage
By adding this requirement, the probability of on-time delivery
decreases from 73% to 27%.
or
By eliminating this requirement, our expected revenues fall from
$20 million to $11 million.