When to Detail Requirements

When to Detail Requirements "Analysis paralysis" is a common condemnation of stalled projects. This complaint reflects the experience that trying too hard to pin down project requirements early can prevent any forward movement. This can be a significant risk in envisioning. There are two factors to keep in mind to mediate this risk: the shelf life of requirements and the audience for them. Requirements Are Perishable One of the great insights of the valueup paradigm is that requirements have a limited shelf life, for four reasons: The business environment or problem space changes. Competitors, regulators, customers, users, technology, and management all have a way of altering the assumptions on which your requirements are based. If you let too much time lapse between the definition of requirements and their implementation, you risk discovering that you need to redefine the requirements to reflect a changed problem. The knowledge behind the requirements becomes stale. When an analyst or team is capturing requirements, knowledge of the requirements is at its peak. The process of communicating their meanings, exploring their implications, and understanding their gaps should happen then. Documentation might capture some of this information for intermediate purposes such as contractual signoff, but ultimately what matters is the implementation. The more closely you couple the implementation to the requirements definition, the less you allow that knowledge to decay. There is a psychological limit to the number of requirements that a team can meaningfully consider in detail at one time. The smaller you make the batch of requirements, the more attention you get to quality design and implementation. Conversely, the larger you allow the requirements scope of an iteration to grow, the more you risk confusion and carelessness. The implementation of one iteration's requirements influences the detailed design of the requirements of the next iteration. Design doesn't happen in a vacuum. What you learn from one iteration enables you to complete the design for the next. In the discussion about capturing requirements that follows, I risk encouraging you to do too much too early. I don't mean to. Think coarse and understandable initially, sufficient to prioritize requirements into iterations. The detailed requirements and design can follow. Who Cares About Requirements For most projects, the requirements that matter are the ones that the team members and stakeholders understand. On a successful project, they all understand the same requirements; on an unsuccessful one, they have divergent expectations (see Figure 3.2). Figure 3.2. The Xaxis shows the degree of ambiguity (opposite of specificity) in the requirements documents; the Yaxis shows the resulting understandability. Dean Leffingwell and Don Widrig, Managing Software Requirements (Boston, MA: Addison-Wesley, 2000), 273 This tension between specificity and understandability is an inherently hard issue. The most precise requirements are not necessarily the most intelligible, as illustrated in Figure 3.2. A mathematical formulation or an executable test might be much harder to understand than a more commonplace picture with a prose description. It is important to think of requirements at multiple levels of granularity. For broad communication, prioritization, and costing to a rough order of magnitude, you need a coarse understanding that is easy to grasp. On the other hand, for implementation of a requirement within the current iteration, you need a much more detailed specification. Indeed, if you practice testdriven development (see Chapter 6, "Development"), the ultimate detailed requirement definition is the executable test. Think about the audience for your requirements work. The audience will largely determine the breadth and precision you need to apply in specifying requirements. At one end of the scale, in eXtreme Programming, you may have a small, collocated team and an onsite customer. You note future requirements on a 3" x 5" card or as the title on a work item, and you move on until it is time to implement. When it is time to do a requirement, within the same session you discuss the requirement with the customer and write the test that validates it, just before implementation. [3] At the other extreme, your requirements specification may be subject to regulatory approval, audit, or competitive bidding. At this end, you may want every detail spelled out so that every subsequent change can be individually costed and submitted for approval.[4] MSF recommends that you plan and detail requirements for one iteration at a time. Effectively, the iteration becomes a batch of requirements that progress through realization. For most projects, this is a balanced medium that maximizes communication, keeps requirements fresh, avoids wasted work, and keeps the focus on the delivery of customer value.