3.2 Principles for Requirements Success

We propose an approach to gathering and documenting requirements that differs substantially from what we have called the traditional approach. Our approach is use-case-driven and employs a number of tools that are either borrowed from the traditional approach, perhaps with slight changes, or are completely new. Chapters 1 and 2 discuss the current state of requirements gathering and the simple elegance of use cases. Now let's look at a solution to the requirements problem. Table 3.1 outlines several guiding principles and ways to succeed in fulfilling those principles.

Table 3.1. Guiding Principles

Guiding Principle	Comments
Reduce risk.	The obvious result of a high-risk project is a high failure rate caused by unhappy users and management. Culprits in increasing risk are big-bang requirements and micromanagement. Possible ways to reduce risk are an iterative or incremental approach, increased user involvement (users writing use cases), and requirements reviews.
Focus on business interactions.	Very often, technologists focus on technology and not on the business interactions required for a system. To focus the effort on the business, you must separate analysis and design activities and keep use cases devoid of technical language and considerations.
Reduce volume.	By turning requirements specification into requirements engineering (a term we've avoided), teams often produce huge amounts of requirements documentation. When they are asked to review it, users rebel, either by rubber-stamping everything (and complaining later) or by refusing to deal with it, causing schedule delays. Strategies for reducing volume are to leave the rote requirements (table maintenance and the like) until the end and to abstract use cases and business rules as much as possible.
Reduce duplicates and inconsistencies.	When a requirements specification exceeds 30 to 40 pages of text, confusion and sloppiness begin to creep in. The requirements become a poor basis from which the designers must work, and they give users a poor view of the system-to-be. The strategies for reducing duplicates and inconsistencies are the same as those used to reduce volume.
Create requirements that users can understand easily.	The main culprits of user-inappropriate requirements are premature design, overspecification, and insufficient user involvement or authoring. The main strategy for avoiding this issue is to employ use cases as specified in this book, avoiding implementation-specific language.
Create requirements that are useful to designers, developers, and project managers.	When requirements are useless, the main culprit is the requirements list: Failure to group , classify, cross-reference, or automate listed requirements hurts their usefulness . Also, if the requirements are not easily traceable to design artifacts, code, and test cases, they get no attention from designers, developers, and testers. By using use cases and a use-case-driven lifecycle, you can minimize or avoid these issues.
Leave a requirements trail.	Even with use cases and business rules, it is important to cross-reference the artifacts properly so that later traceability is possible. By taking a use-case-driven approach and creating real use cases from abstract use cases, the team can help leave a requirements trail that ensures a system built as it was specified (and promised !).
Leave design until later.	If requirements analysts are really designers-in-disguise, then design considerations can easily creep into requirements specifications.
Keep the plan in mind.	It is easy to get caught up in today's set of requirements tasks and forget what is to be done with these documents. It is the responsibility of the project manager to help the team keep a far-sighted perspective. Thinking about the use-case paths as increments of development helps the team in making decisions on the granularity of use cases.