Just Enough Requirements Management: Requirements Triage

This chapter is from the book

Just Enough Requirements Management: Where Software Development Meets Marketing

Learn More Buy

This chapter is from the book

This chapter is from the book 

Just Enough Requirements Management: Where Software Development Meets Marketing

Learn More Buy

Basic Triage Techniques

This section of the book differentiates between basic and advanced triage. 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. Basic triage can be thought of as performing a balancing act upon a three-person seesaw, as shown in Figure 3-2. If the requirements are too “heavy” for the seesaw, then the schedule and cost arms rise, indicating excessive risk of failing to meet schedule and cost. If the desired schedule or cost is too “light” for the seesaw, then the requirements arm falls, indicating excessive risk of failing to meet all the requirements.

Figure 3-2: Basic Triage Represented as a Three-Person Seesaw.

Performance of basic triage necessitates that you know something about the requirements being considered for inclusion. At a minimum, this knowledge should include the relative importance of the requirements (from the customer perspective) and the cost of satisfying each requirement. There are many other attributes, but these are the two that you cannot afford to omit.

Prioritizing Candidate Requirements by Importance and Cost

Numerous techniques exist to determine the relative importance of requirements. Ironically, one technique that does not work is to simply ask individual customers to prioritize the requirements. If you do this, most customers will tell you that all the requirements are of equal importance and they are all critical. Instead, gather stakeholders together in a room, show them the list of candidate requirements, and ask them to apply the hundred-dollar test, the yes-no vote, or the five-way priority scheme.

To apply the hundred-dollar test [LEF00], explain to the stakeholders that they each have one hundred (imaginary) dollars that they must distribute among the candidate requirements—in this case, let’s say we have 100—in such a way that if requirement i is x times more important than requirement j, then they should give it x times more money. Also, explain to them that it would be pointless to give $1.00 to each requirement because when we sum all the votes, their vote would have no effect on the outcome, so this is equivalent to not voting at all. If the group is small enough, simply point to each candidate requirement, conduct a short discussion to make sure that everybody understands the requirement sufficiently, and then go around the room asking each stakeholder for his or her points. Add as you go, and write the sum of the votes next to the requirement. Repeat this for every candidate requirement. Sort the requirements from most to least points, and—voila!—you have your prioritization.

If the group is too large to count the votes in real time, you may do the counting one of two ways. First, if the candidate requirements are already in an electronic medium, have all the stakeholders record their votes using a computer. If the candidate requirements are written down (on cards, as a result of brainstorming, for example), simply give the stakeholders a marker and ask them to record their votes on the cards. The biggest advantage of the hundred-dollar test is that stakeholders can vote how they really believe, so if they believe one requirement is ten times more important than another, they can give it ten times more votes.

The biggest disadvantage is that the hundred-dollar test can easily be “gamed.” Let me tell you about a situation that occurred a few years ago, an excellent example of gaming: We had gathered seven or eight stakeholders together in a room to discuss the next release’s features. We started with a two-hour discussion of all the requirements. During this time, one stakeholder expressed his view that only four of the requirements were of high importance to him. It also became evident that everybody else in the room shared his assessment of three of the four, but only he cared about the fourth one. When it came to a vote, he realized he would be wasting his vote on the first three, since the other stakeholders would vote for them. So, he put all one hundred dollars on the fourth requirement. After tallying the votes, we discovered that the fourth requirement received the highest number of total votes, even though only one stakeholder cared about it.

Collusion is another game that stakeholders sometimes play. This also happened to me a few years ago: I had gathered together six stakeholders for a hundred-dollar test. I had warned them up-front of the futility of giving every requirement the same number of points. I pointed to the first requirement and added up the votes: $6.00. I pointed to the second requirement and added up the points: $6.00 again. After this happened eight more times, I realized that they must have colluded before entering the room. I could imagine them saying, “Davis is going to try to get us to agree that some of the requirements are less important than others! We all know that they are all of equal importance, so let’s not let him get away with it.” When this became evident to me, I suggested a short recess. During the recess, I cornered one of the developers and asked him to join us for the rest of the voting. Upon reconvening, I announced, “I have asked Quinn to join us for the remainder of the voting. As you all know, I strongly believe that developers’ opinions on the importance of requirements are not as important as customers’ opinions. For that reason, I am giving Quinn just $1.00 to distribute in one-cent increments among the one hundred candidate requirements. Nobody should feel intimidated by Quinn’s presence. After all, no matter how he chooses to vote, any one of you can easily out-vote him with just one of your hundred dollars.” And so we continued the voting process. The first requirement Quinn voted on earned $6.10, the next earned $6.01, and so on. Within a few minutes, it became clear to the stakeholders that if they continued with their collusion game, Quinn would be making all the prioritization decisions. Finally, one of the original stakeholders asked if we could start over again. During this second run, the stakeholders voted more accurately. Some would say I tricked the stakeholders into voting in a differentiated manner, but Quinn’s presence would not have had any effect on their votes if their votes actually reflected how they felt about the relative priorities of the requirements.

To address the inherent weaknesses of the hundred-dollar test, some organizations use a much simpler voting system: the yes-no vote. In this system, simply point to each requirement and ask stakeholders to indicate their interest-level in the requirement by raising their hands. There is no reason to establish limits on the hand-raises. If stakeholders choose to raise their hands to all or none of the requirements, they should feel free to do so. No matter how many people are in the room, it is pretty easy to tally the number of raised hands. Record these numbers next to the requirements and sort them from highest to lowest to find the relative prioritization of your candidate requirements. The yes-no vote is very easy to administer, but has two major problems:

• What does it mean for a stakeholder to not raise a hand for a requirement? Does it mean that he or she does not care if the requirement is satisfied in this release? Or does it mean that he or she believes that including the requirement in the current release would actually detract from its usefulness?
• How should a stakeholder vote if he or she really believes that one requirement is twice as important as another requirement, but that both should be included in the next release?

To overcome the weaknesses of the yes-no vote while maintaining simplicity, try using the five-way priority scheme, which is the system I use most. Conduct the voting the same way that the yes-no vote demands, but give the stakeholders five options. They can vote +1 if they are for the requirement’s inclusion in the next release, 0 if they don’t care, and -1 if they are against its inclusion. They can also vote +2 if they feel the requirement is extraordinarily important, and -2 if they feel its inclusion is extraordinarily destructive to the release. To make the tallying process easy, ask the stakeholders to vote with their fingers, as shown in Figure 3-3. When I am facilitating a triage session with ten or fewer stakeholders, I usually record all their votes rather than just the sum, as shown in Figure 3-4. My reason for doing this is simple: Let us say that two requirements each score 0 points, but one is the result of every stakeholder voting 0 and the other is the result of five stakeholders voting +2 and five stakeholders voting -2. In the former case, the requirement should be excluded from the baseline. But the votes for the latter requirement indicate that we may need to consider two versions of the product.

Figure 3-3: Five-Way Priority Scheme.

The above prioritization schemes work as stated when the stakeholders are all equally important. If some stakeholders are more important than others, you may want to modify the data collection method somewhat. First of all, if the politics of the situation are such that all parties understand which stakeholders are most important, then simply weight those individuals’ votes accordingly. For example, if everybody knows that stakeholder x is twice as important as anybody else, just count his or her votes twice. If the politics dictate that the relative importance of stakeholders remain clandestine, then it is best to collect all the votes electronically (or secretly) and do the tallying remotely.

Figure 3-4: A List of Prioritized Candidate Requirements.⁷

During the triage discussion, one stakeholder decided that he needed a more complex system: one that controlled four roads (as opposed to two) converging on the one-lane bridge. I have therefore added new requirements 3 and 4. Note that the votes indicate quite a bit of controversy surrounding these new requirements.

Another stakeholder, during the triage session, realized that we had inadvertently omitted an important requirement—interfacing to sensors that detect arriving traffic. This is why requirement 5 was added. Look at the votes for this one. Here, one stakeholder voted “-1” because she felt it was “obvious.”

If you are looking for a technique that incorporates multiple stakeholders, each with differing levels of importance, and a way of propagating such data to the decision process, take a look at quality function deployment (QFD) [MIZ94]. In QFD, a table is created with each stakeholder name and its relative importance atop each column, and each individual requirement labeling the rows. In each column, record that stakeholder’s votes for the requirements. After completing the data entry, do a weighted sum of the rows,⁸ and record that sum in a new column to the right. This becomes your relative priority of requirements.

Estimating Effort for Candidate Requirements

There are many books that can assist organizations in determining the quantity of resources required to build software to solve a problem (for example, see [BOE00, JON98]). When distilled, though, all of them will tell you basically the same thing:

• Estimate the size of the problem that needs to be solved or the solution that needs to be built.⁹
• Tweak the size based on some attributes of the problem to be solved, the people working on the project, or the type of solution.
• Use historic data to see how many resources were required in the past to tackle such an endeavor.

The effort estimation should be done on a per-requirement basis. In other words, you should estimate the effort required to satisfy each requirement. The units of effort can be anything you like: feature points, function points, lines of code, person-years, person-months, person-weeks, person-hours, dollars, and so on. Figure 3-5 shows the example of Figure 3-4 with the individual stakeholder priorities summed and with the estimate efforts, in person-hours.

Figure 3-5: A List of Candidate Requirements with Effort Estimates.¹⁰

Disagreements Concerning Relative Priority of Requirements

Let’s say that two members of the marketing team have seriously differing opinions about the relative priority of the following requirement:

• A. The system shall provide service x to the customers.

There could be a variety of reasons for this disagreement. One possibility is that the two marketing people represent two disparate groups of customers with different needs, based on the jobs that they do. In that case, the best route is to record multiple attributes for each requirement, one for each of the priorities, for each of the groups, as shown in Figure 3-4. Averaging or combining the priorities is unlikely to be of much value. For example, if a requirement is essential to meet the needs of one class of customer but unimportant to another, nothing worthwhile results from recording an average priority of “important.” The fact is that if the requirement is met, the first group of customers will have its needs met. And if the requirement is not met, that group’s needs will not be met. The satisfaction of the second group of customers is completely unrelated to this requirement.

Another possible basis of the disagreement is that the two marketing people have different interpretations of the candidate requirement. In this case, the correct route is to refine the requirement. By refining it, you will improve your understanding of the requirement and discover the basis of the disagreement. So, in the above example, we could refine the requirement into, say, three sub-requirements:

• Al. The system shall provide service xl to the customers.
• A2. The system shall provide service x2 to the customers.
• A3. The system shall provide service x3 to the customers.

This is what was done to create some of the hierarchies of requirements shown in Figure 3-4.

Once this is done, it often becomes clear that the person who rated requirement A highly did so because service x3 is of critical importance (and perhaps xl and x2 were actually of little value). And the person who gave a low rating to requirement A did so because he or she thought that x referred only to x2, rather than xl, x2, and x3. With the refined requirements, however, the parties realize that they actually agreed with the priorities—requirement Al is low-priority, requirement A2 is low-priority, and requirement A3 is high-priority. But, equally important is the side effect this refinement has of reducing the ambiguity of requirement A.

Disagreements Concerning Effort to Satisfy a Requirement

Let’s say that two members of the development organization have seriously differing opinions about the effort required to address the aforementioned requirement A.

There could be a variety of reasons for the disagreement. One possibility is that the two developers have different assumptions concerning the development resources that are to be applied. For example, Sally may be assuming that she will be assigned to the development effort, and she knows she is highly skilled in this type of work. Knowing this, she has provided a relatively low estimate of effort. Meanwhile, John may be assuming that he will be assigned the development effort, but really does not like doing this type of work. Feeling this way, he has provided a relatively high estimate of effort. These are but two of the many games developers play when making estimates.¹¹ If such is the case, the best route is to find out from Sally and John “where their heads are at.” That is, try to ascertain what games they are playing, so you can make the right decisions. Then select either Sally’s or John’s estimate, and be sure to record the assumptions that you are making. Whatever you do, do not average the two estimates.

An equally likely reason for the disagreement is that the two developers have different interpretations of the candidate requirement. In this case, you should take the same action as in the case of a disagreement among marketing personnel—refine the requirement:

• Al. The system shall provide service xl to the customers.
• A2. The system shall provide service x2 to the customers.
• A3. The system shall provide service x3 to the customers.

Once this is done (as we did above, to clarify relative priority), it often becomes clear that the person who estimated that it would require a lot of effort to satisfy requirement A did so because service x3 is very difficult to provide (and perhaps xl and x2 are easy to provide). And the person who estimated that it would require little effort to satisfy requirement A did so because he or she thought that x meant x2 only, rather than xl, x2, and x3. After refinement, however, the parties realize that they actually agree with the estimates. Equally important is that the ambiguity of requirement A has been reduced.

Establishing Requirements Relationships

The preceding subsections assumed that requirements are independent. In reality, this is rarely the case. The following sections describe just some of the relationships that may exist between requirements.

Necessity Dependency

In this relationship, it makes sense to satisfy requirement A only if we are also satisfying requirement B. For example, consider this dependency:

• Requirement A: The stop button shall be red.
• Requirement B: The system shall provide a stop button.

Sometimes, such a dependency is bidirectional, as in this case:

• Requirement A: The system shall provide the Fiends and Famine capability for our customers.
• Requirement B: The system shall bill customers $3 per minute when they use the Fiends and Famine feature.

If such dependencies exist between requirements, you should record the relationships, as shown in Figure 3-6 and Figure 3-7. The record of this relationship will be used during requirements triage. As we try to select an optimal subset of the requirements to implement, we will want to avoid subsets that include a requirement without including all requirements on which it depends. Par Carlshamre et al. [CAR01] differentiate between two types of necessity dependence: AND (which indicates bidirectional necessity dependence between two requirements) and REQUIRES (which indicates a unidirectional necessity relationship between one requirement and another).

Figure 3-6: Unidirectional Necessity Dependency.

Figure 3-7: Bidirectional Necessity Dependency.

Effort Dependency

In this relationship, requirement A will be easier to satisfy if we are also satisfying requirement B. For example, such a dependency may exist between the following:

• Requirement A: The system shall provide reports of accounts receivable older than 60 days.
• Requirement B: The system shall provide a general-purpose report-generation utility.

If such a dependency exists between requirements, you should record that relationship, as shown in Figure 3-8. Unlike necessity dependency, effort dependency is not used to select compatible requirements. Instead, it is used to determine the actual implementation cost for selected subsets. So, in the case of Figure 3-8, the cost of satisfying requirement A is four person-months and the cost of satisfying requirement B is five person-months, but the cost of satisfying both requirements A and B is seven person-months, because satisfying requirement B reduces the effort required to satisfy requirement A by two person-months.

Figure 3-8: Effort Dependency.

Pär Carlshamre et al. [CAR01] separate this relationship into two subtly different characteristics: TEMPORAL dependencies, to capture the fact that one requirement should be implemented before another, and ICOST dependencies, to capture the incremental cost reduction gained by implementing one requirement before another.

Subset Dependency

If requirement A is satisfied, then requirement B will be satisfied. That is, requirement B is part of requirement A.

If such a dependency exists between requirements, you should record that relationship. Notice from the list of requirements shown in Figure 3-9 that we have refined the parent requirement into three child requirements. In this case, the three children do not represent the entirety of the parent’s functionality. The intent is for them to exemplify or capture the spirit of the parent. Notice in this case that developers must satisfy the full essence of the parent requirement—in doing so, they’ll satisfy the three children requirements, but that is not sufficient. Note also that during the actual triage process, when selecting an optimal subset of the requirements to satisfy, you may select all, some, or none of the children. And if you select all the children, then you may also select the parent if you wish. However, if you select the parent, you must select all its children. You will notice that there is no need to define effort dependencies between parent and children requirements. If we select A for satisfaction, we will automatically select B, C, and D, and the total effort will be 27 person-months. If we select only a subset of B, C, and D, then the effort will be only the sum of the efforts of the selected requirements.

Figure 3-9: Subset Dependency.

An alternate way to represent subset dependency is by numbering the requirements accordingly, so that if a parent is numbered 3, then its children are numbered 3.1, 3.2, 3.3, and so on. This is precisely what is being represented in Figure 3-4. That figure has also indented the requirements texts for children so they can be even more easily identified. In such cases, there is no need to use a separate column to show the dependency. Juha Kuusela and Juha Savolainen [KUU00] call this an AND dependency because child requirements 3.1 and 3.2 and 3.3 represent the parent requirement 3.

Cover Dependency

This is a special case of subset dependency in which the union of the children’s functionality is the parent’s functionality. If requirements B, C, and D are satisfied, then requirement A will be satisfied; and if requirement A is satisfied, then requirements B, C, and D will be satisfied. That is, requirements B, C, and D represent a refinement of requirement A.

If such a dependency exists between requirements, you should record that relationship. You will notice from the list of requirements shown in Figure 3-10 that we have refined the parent requirement A into three child requirements—B, C, and D—and we do wish to imply that the sum of the three children completely captures the parent. Note that during the actual triage process, when selecting an optimal subset of the requirements to satisfy, you may select all, some, or none of the children. And if you select all the children, then you have indeed selected the parent by inference. If you select the parent, you have selected all children requirements by inference. Notice that once again there is no need to include effort dependency.

Figure 3-10: Cover Dependency.

Value Dependency

If satisfying one requirement lowers (or raises) the need for another requirement, then a value dependency exists between them [CAR01].

If such a dependency exists between requirements, you should record that relationship as you would other types of dependencies. When a value dependency exists, triage will become a bit more complex: The relative priority of requirement B will change as a result of including requirement A in the next release. If the dependency has not been recorded, the triage participants are likely to include requirement B even though it is no longer that important.

Pär Carlshamre et al. [CAR01] also describe a requirements relationship they call an OR dependency. When two requirements possess an OR relationship, then one of the requirements should be satisfied, but not both. I believe that this is just a special case of a bidirectional value dependency. In particular, if requirement A is selected for inclusion, the priority of requirement B becomes negative, and if requirement B is selected for inclusion, then the priority of requirement A becomes negative.

Documenting the Dependencies

In all of the above cases, I have shown the relationships as arrows in the figures. There are a variety of ways of maintaining these relationships on an actual project:

• Manual: If you want requirement 1 to refer to requirement 2, simply type “requirement 2” in the appropriate attribute field of requirement 1. This requires almost no effort at all to do initially, but maintenance is extremely painful [ANT01, DOM98, RAM98]. Every time a requirement changes, you must manually check to see if other requirements are impacted.
• Hyperlink: Much better than manual maintenance, this requires you to enter a hyperlink [HAY96] called “requirement 2” in the appropriate attribute field of requirement 1. The biggest advantage of this is you can quickly move from one requirement to all the related requirements. This makes maintenance somewhat easier.
• Requirements Tools: Ideally, when you change requirement 1, you want to immediately see a list of all requirements related to it on a first- and second-order basis (what relates to requirement 1 and what relates to what relates to requirement 1, respectively), and so on. The easiest way to do this is to use a requirements management tool,¹² which makes maintenance a lot easier. But with the benefit comes the extra overhead of having to learn how to use (and having to pay for) the tool.

Performing Triage on Multiple Releases

The essence of the triage decision is to decide whether or not each candidate requirement will be included in the next release, given the available time and resources. As described earlier, this is always the result of a cooperative process among multiple stakeholders. I highly recommend that you always plan at least two releases at a time. If you plan just one release—say, Release 3.0—every requirement necessitates a binary (yes or no) decision. There is no compromise position. If you plan two releases at a time, a compromise position is available. So, let’s say one stakeholder insists a requirement be included in Release 3.0 and another stake-holder insists that it be excluded from Release 3.0. It might be possible to formulate a middle-of-the-road position by agreeing that it will be satisfied in the following release, Release 4.0. To make this even more palatable, you might consider numbering the following Release 3.1, or even 3.01 (rather than 4.0), to make it sound even more imminent and thus even more of an acceptable compromise (see Figure 3-11).

Figure 3-11: A Compromise Release.