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  identifies four major principles to apply when designing and evaluating software methodologies.
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
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.  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.
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.