Just Enough Requirements Management: Requirements Triage
- Sep 27, 2013
As you discovered in the previous chapter, poorly executed requirements elicitation can hamper development. In this chapter, you will learn more about the second major area of requirements management: requirements triage.
Definitions and Terminology
After eliciting and creating a list of requirements, you will likely want to establish (or learn about) the desired schedule and the available budget. No matter how ample either of these appears to be, one of them, if not both, will be insufficient to address all the requirements. To solve this problem, you will need to find some way to balance the desired requirements, your available budget, and the desired schedule. Requirements triage is the art of selecting the right requirements to include in the next release of your product [DAV03]. Although many people with many diverse titles are assigned the task of performing elicitation, very few ever acknowledge this responsibility.
In most organizations, triage is not performed explicitly. Instead, it is performed by some combination of intimidation, inertia, osmosis, and incompetence. Here are some typical scenarios:
- The “You’re Not a Team Player” Approach: Development and marketing cannot agree on a set of requirements and a schedule. Specifically, marketing “demands” that all the requirements must be included by a particular date “or the product might as well not be built.” Development knows that the date is totally unreasonable, given the set of requirements, and fights back. Notice that both parties are trying to represent the best interests of the company. Frustrated, marketing approaches executive management, explains how important it is to have all the requirements satisfied by the date, and then informs the boss of development’s “obstructionist attitude.” Development is then seen as “not a team player,” and executive management demands that it conform. The manager of development agrees to the date even though he knows it is impossible to meet. The project is not delivered on schedule. Notice that the development organization is able to be late and still say, “I told you so.”
- The “You Don’t Understand Technology” Approach: Development and marketing cannot agree on a set of requirements and a schedule. Specifically, marketing “demands” that all the requirements must be included by a particular date “or the product might as well not be built.” Development knows that the date is totally unreasonable, given the set of requirements, and fights back. Frustrated, development approaches executive management, explains how important it is for the company to be successful, and then informs the boss of marketing’s “death wish.” Marketing is seen as trying to set up the company to fail by insisting that it try to accomplish the impossible. The manager of marketing agrees to either reduce requirements or delay the product release, even though she knows that the product will no longer be competitive. When marketing fails to meet revenue goals, it has the perfect scapegoat: development.
- The “Over-Estimate” Approach: Development knows from past experience that it is going to be forced to accept a ridiculously tight schedule. Therefore, developers over-estimate the effort needed to address each requirement. They hope that by doing so, they will have enough slack built into the schedule for them to actually succeed. This scenario may result in a successful product delivery. Unfortunately, the games being played make it impossible to ever repeat the process in a predictable manner. None of the players learn anything about why it worked or how to improve it. Executive management may walk away from the project feeling that it was successful, but for all the wrong reasons.
- The “Over-Demand” Approach: Marketing knows from past experience that development is going to deliver late regardless of what is needed. Therefore, it gives development an earlier deadline for product delivery, hoping that when the product is delivered, although late relative to the deadline, it will still be early enough to meet the real market window. This scenario may result in a successful product delivery. Unfortunately, the deceit involved makes it impossible to ever repeat the process in a predictable manner. No one involved learns anything about why it worked or how to improve it. But the worst part of this scenario is that development gets an undeserved “bad rap.”
Synonyms for requirements triage include release planning [CAR02], requirements prioritization [WIE03], optimal attainment of requirements [FEA02], requirements negotiation [IN01], requirements selection [KAR96, RUH03], and requirements allocation.1 I prefer the term “triage” because the analogy to triage in medicine is so fitting. As I described in [DAV03], after a medical disaster, medical personnel “systematically categorize victims into three groups: those who will die whether treated or not, those who will resume normal lives whether treated or not, and those for whom medical treatment may make a significant difference. Each group requires a different strategy. The first group receives palliative care, the second group waits for treatment, and the third requires some ranking in light of available resources. As new victims appear, personnel must repeat the categorization.”* Notice how similar this is to the software world. Some requirements are no-brainers—we absolutely must address them or the product won’t do its job. Other requirements are a different kind of no-brainer—just dreams that should remain unfulfilled until the appropriate resources are available. The third set requires ranking in light of available resources. As new requirements emerge or resources change, new rankings must be performed.
Triage is the most interdisciplinary of the three areas of requirements management. Successful triage requires close interplay between those responsible for understanding customer needs and the timing of those needs,2 those responsible for expending resources to satisfy requirements,3 those responsible for the allocation of money to the project,4 and those responsible for overall project success.5 Successful triage requires knowledge of the following:
- The needs of the customers: What problems does the customer have, and what is the relationship of various product requirements to the solution of those problems?
- The relative importance of requirements to the customers: Which requirements have the most (and least) value to the customer? If you simply ask this question directly, in most cases the answer will be, “They are all critical.” Later in this chapter, I discuss better ways to determine relative importance.
- Timing: What is the market window? By when does the customer need each requirement addressed? If you simply ask this question directly, in most cases the answer will be, “I need them all today.”6 Later in this chapter, I discuss better ways to determine relative timing.
- Relationships among requirements: Which requirements make sense only when other requirements are already present? For example, it makes little sense to include a requirement to bill for a particular service if the service itself is not being provided by another requirement. Are some requirements easier to implement after other requirements have already been implemented? Which ones? Which requirements are no longer needed when other requirements are met? Which requirements are incompatible with which other requirements?
- Sensible subsetting [PAR76]: Which sets of requirements make business sense only when all members are present?
- Cost to satisfy each requirement: How many resources (measured in terms of currency, effort, or elapsed time) will need to be expended in order to satisfy each requirement?
Triage should be performed for every planned release of a product, as indicated by the left-most oval in Figure 3-1. It is during this time that most requirements are assigned critical attributes and major decisions are made concerning which requirements will be addressed in the next release. As shown by the center and right-most ovals in Figure 3-1, triage activities are repeated each time new requirements arise or new resources become available.
Figure 3-1: Triage in the Requirements Process.