Since 1994, the Standish Group has published annual “Chaos” reports on project failure and success factors, analyzing tens of thousands of projects. In the failure column, over 30 percent of the pain factors were strongly related to requirements issues. And the 2000 National Software Quality Experiment (run by the U.S. Department of Defense) identified that the highest factor in defects, 41 percent, was related to lack of definition and traceability regarding requirements. In the “Chaos TEN” list of critical success factors identified by the Chaos studies, high user involvement and clear basic requirements are two of the key ingredients.
Clearly, doing a better job with requirements is needed. But—and this is a common trap—the classic “waterfall” or sequential life-cycle advice of attempting to specify fully and stabilize the requirements in the first phase of a project is not usually the answer. The evidence: Research into the high degree of requirements change on software projects (upwards of 50 percent change) and the high level of project challenge and failure associated with attempts to “nail the requirements” in step one. Research now shows that part of the answer is adopting an iterative life cycle, in which the requirements are incrementally and adaptively defined and refined, in parallel with short time-boxed implementation iterations. The iterations drive requirements clarification through quick feedback and adaptation cycles, based on building key parts of the system quickly, before all the requirements are “defined.”
Yet even more can be done to improve requirements definition and increase user involvement. Part of that is to use a language of requirements that appeals to the average participant, that emphasizes fulfilling the real goals of the user, and that pulls related requirements together, describing them in a cohesive context. This is the language of use cases, first described by Dr. Ivar Jacobson in 1986.
Although use cases are popular, they have also acquired the appellation “abuse cases” by some methodology wonks, because of the myriad examples of their poor creation and misuse. Therefore, I am delighted to see learning aids that help us write quality use cases, such as the influential Writing Effective Use Cases (Cockburn 2001) and now this excellent—and complementary to Cockburn—text on use case guidelines and patterns by Steve Adolph and Paul Bramble. The pattern form is an excellent mechanism to learn and share best practices, and we will all benefit from studying and applying their advice. In the early 1990s, I was sitting in my office at a college in Vancouver, British Columbia, when in walked Steve, to share the room. We immediately struck up a friendship. I was impressed by his passion for building—and the methods of building—excellent software. I first met Paul in the mid-1990s when I was serving at his company in Phoenix, Arizona, and shared his interest in patterns as a vehicle to capture and educate on best practices. Knowing their mutual interests, I suggested they connect at OOPSLA 98 in Vancouver, which they did. It's great to see skilled colleagues, who have practiced, thought, and taught long and hard on a subject, share their insights so that we can all benefit.
—Craig Larman
Dallas, Texas
May 2002