Methodology Design Goals

As we have said, the purpose of requirements methodology is to address requirements- related project risks. The purpose of the overall development methodology is to address collective project risks. In his book on agile development, Cockburn [2002] identifies four major principles to apply when designing and evaluating software methodologies.

1. Interactive, face-to-face communication is the cheapest and fastest channel for exchanging information.

2. Excess methodology weight is costly.

3. Larger teams need heavier methodologies.

4. Greater ceremony is appropriate for projects with greater criticality.

Let's examine these principles briefly to see what insight we can gain into selecting the correct requirements management methodology for a particular project context.

Table 30-1. Requirements Techniques and the Specific Project Risks They Address

Technique	Risk Addressed
Interviewing	The development team might not understand who the real stakeholders are. The team might not understand the basic needs of one or more stakeholders.
Requirements workshops	The system might not appropriately address classes of specific user needs. Lack of consensus among key stakeholders might prevent convergence on a set of requirements.
Brainstorming and idea reduction	The team might not discover key needs or prospective innovative features. Priorities are not well established, and a plethora of features obscures the fundamental "must haves."
Storyboards	The prospective implementation misses the mark. The approach is too hard to use or understand, or the operation's business purpose is lost in the planned implementation.
Use cases	Users might not feel they have a stake in the implementation process. Implementation fails to fulfill basic users needs in some way because some features are missing or because of poor usability, poor error and exception handling, and so on.
Vision document	The development team members do not really understand what system they are trying to build, or what user needs or industry problem it addresses. Lack of longer- term vision causes poor planning and poor architecture and design decisions.
Whole product plan	The solution might lack the commercial elements necessary for successful adoption.
Scoping activities	The project scope exceeds the time and resources available.
Supplementary specification	The development team might not understand nonfunctional requirements: platforms, reliability, standards, and so on.
Tracing use cases to implementation	Use cases might be described but not fully implemented in the system.
Tracing use cases to test cases	Some use cases might not be tested , or alternative and exception conditions might not be understood , implemented, and tested.
Requirements traceability	Critical requirements might be overlooked in the implementation. The implementation might introduce requirements or features not called for in the original requirements. A change in requirements might impact other parts of the system in unforeseen ways.
Change management	New system requirements might be introduced in an uncontrolled fashion. The team might underestimate the negative impact of a change.

Principle 1: Interactive, Face-to-Face Communication Is the Cheapest and Fastest Channel for Exchanging Information

Whether eliciting requirements information from a customer or communicating that information to a team, face-to-face discussion is the best and most efficient way to communicate. If the customer is close to the team, if the customer is directly accessible, if requirements can be explained to the team directly, if the analyst can communicate directly with the customer and the team, then less documentation is needed. ^[1] However, due to the criticality of understanding requirements for the system, some requirements must be documented. Otherwise, the team bears the risk that implicit, tacit assumptions to the effect of "we all know what we are developing here" may again become a primary risk factor in the project. But certainly , fewer documents need be produced, and necessary documents ”Vision documents, use cases, supplementary specifications, and the like ”can be shorter and written with less specificity.

^[1] It is important to take this notion with a grain of salt. As Philippe Kruchten pointed out to us recently, "I write to better understand what we said."

Principle 2: Excess Methodology Weight Is Costly

This principle translates to "Do only what you have to do to be successful." Every unnecessary process or artifact slows the team down, adds weight to the project, and diverts time and energy from essential coding and testing activities. The team must balance the cost and weight of each requirements activity with the risks listed in Table 30-1. If a particular risk is not present or likely to occur, consider deleting the corresponding artifact or activity from your process. Alternatively, think of a way to "lighten" the artifact until it's a better fit for the risk in your particular project. Write abbreviated use cases, apply more implicit traceability, and hold fewer reviews of requirements artifacts.

Principle 3: Larger Teams Need Heavier Methodologies

Clearly, an appropriate requirements methodology for a team of three developers who are subject matter experts and who have ready access to a customer may be entirely different than the right methodology for a team of 800 people at five different locations who are developing an integrated product line. What works for one will not work for the other. The requirements method must be scaled to the size of the team and the size of the project. However, you must not overshoot the mark either; an over-weighted method will result in lower efficiency for a team of any size .

Principle 4: Greater Ceremony Is Appropriate for Projects with Greater Criticality

The criticality of the project may be the greatest factor in determining methodology weight. For example, it may be quite feasible to develop software for a human pacemaker's external programming device with a two- or three-person coding team. Moreover, the work would likely be done by a development team with subject matter expertise as well as ready access to clinical experts who can describe exactly what algorithms must be implemented and why and how. However, on such a project, the cost of even a small error might be quite unacceptable since it could endanger human life. Therefore, all the intermediate artifacts that specify the use cases, algorithms, and reliability requirements must be documented in exceptional detail, and they must be reviewed and rationalized as necessary to ensure that only the "right" understanding appears in the final implementation. In such cases, a small team may need a heavyweight method. The opposite case may also be true. A noncritical project of scope sufficient to require a large team may be able to apply a lighter-weight method.