Managing Software Requirements: A Use Case Approach (Addison-Wesley Object Technology Series) by Dean Leffingwell, Don Widrig, Don Widrig, Don Widrig, Don Widrig

From the Publisher

"Many projects fail because developers fail to build the right thing. Developers of any kind of application should read this book." —Grady Booch

"A comprehensive solution to the requirements challenges faced by every development team. Full of insight and ideas all developers can learn from." —Ivar Jacobson

Despite the wealth of development knowledge, experience, and tools available today, a substantial percentage of software projects fail, often because requirements are not correctly determined and defined at the outset, or are not managed correctly as the project unfolds. This second edition of the popular text Managing Software Requirements focuses on this critical cause of failure and offers a practical, proven approach to building systems that meet customers' needs on time and within budget.

Using an accessible style, their own war stories, and a comprehensive case study, the authors show how analysts and developers can effectively identify requirements by applying a variety of techniques, centered on the power of use cases. The book illustrates proven techniques for determining, implementing, and validating requirements. It describes six vital Team Skills for managing requirements throughout the lifecycle of a project: Analyzing the Problem, Understanding User Needs, Defining the System, Managing Scope, Refining the System Definition, and Building the Right System. Managing Software Requirements, Second Edition, specifically addresses the ongoing challenge of managing change and describes a process for assuring that project scope is successfully defined and agreed upon by all stakeholders.

Product Details

• Table of Contents
• Forewords & Introductions

Table of Contents

Forewords & Introductions

Throughout, however, innovation in software technology continues unabated and the industry as a whole is still growing rapidly. The global reach of the Internet continues to change our lives, driving new forms of communication as witnessed by themes as varied as new global electronic marketplaces facilitating the exchange of goods and services, to the new, after-school instant messaging chat-fests which seem to absorb our children's homework time and so much of that expensive Internet bandwidth we rolled out in the last decade.

We are connected to our business associates, friends, and family 7x24. Internet cafes in Darwin, Australia, Edinburgh, Scotland and Alaska-bound cruise ships are open 24 hours. We receive emails on our PDAs at the grocery store. We can't make breakfast, drive to work, ride an elevator, or enter an office building without interacting with software. Software has become the embodiment of much of the world's intellectual knowledge and the business of developing and deploying software has emerged as one of the world's most important industries.

Software development practices continue to march forward as well. The UML, adopted as late as 1997, is now the de-facto means to communicate architecture, patterns, and design mechanisms. The Rational Unified Processand similar processes based on the UML are being adopted by many in the industry as the standard way to approach the challenge of software development.

Our personal lives have changed also. After four years at Rational Software, I have moved on to helping a number of independent software companies achieve their goals. Some teams hope to change the world, some hope to have a significant impact on an individuals life's by improving healthcare, still others hope to improve their customer's manufacturing efficiencies, or help businesses grow by translating product data to a prospect's native language. However, these teams all have one thing in common: they are challenged by the complexity and difficulty of defining software solutions in a way that can be understood—by themselves, by their customers, by their marketing teams, by their internal development and testing teams—indeed, by all those that must understand the proposed solution at the right level of detail so that the proper results can be achieved. Fail to do that and they fail to achieve their mission. Because of the importance of their mission on their personal lives as well as those whose products they are intended to help, failure is not an option.

So, while much has changed in the software industry in just a few short years, some things, including the challenge of Managing Software Requirements, remain largely the same and so our work continues in this, the second edition.

About the Second Edition

The motivation for the content changes in the second edition is based on different, yet convergent factors.

The first is based on the success of the book in the marketplace, which has generated many positive comments and much encouragement, as well as constructive criticisms. While comments range widely, a few consistent themes emerged.

The More Use Cases Theme. The first edition, A Unified Approach, reconciled and combined two major viewpoints on requirements techniques. The first, perhaps a more traditional approach, described the way in which requirements specifications are created and detailed to prescribe system behavior using declarative techniques (the system shall....). The second, the use case approach, described the way in which use cases could be used to define the majority of the functional behavior of the system. We combined these techniques in the first edition in order to create a common, and hopefully more holistic, approach. Based on feedback, we did achieve some success. However, one criticism of the work is that, while we recommended and described the use case method, we did not go far enough in helping the reader develop or apply this technique. Moreover, in presenting both techniques, we confused some readers who wanted to better understand which technique to apply, and when.

The "it's a big book with many techniques-can't you be more prescriptive" Theme. The first work was intended to be a comprehensive work, a one-stop shopping reference for any technique one might need to define requirements for a system of any type. We hope this provided value to our readers because we truly believe that there is no "one size fits all" solution to each specific software engineering challenge. And yet, the reviewer's theme remains: Does it have to be this hard? Can't you be more prescriptive?

A second set of factors driving this same theme is based on my own experiences in using the book as I work with companies to help them achieve their software development objectives. Some have software applications that require multiple techniques; some can make time for a fairly rigorous introduction to a full requirements management discipline. However, others need to document a specific set of requirements for a specific software application and they need to do so immediately. Starting tomorrow. There is no time or interest in a debate as to which technique might be more effective, or as to the nuances of anything. "Just give me one technique, make it simple, and get me started right now," they say.

Fortunately, these two factors are mostly convergent and the answer to both is fairly clear. For most teams, in most circumstances, a combination of 1) a well-considered Vision document, 2) an identification and elaboration of the key use cases to be implemented, and 3) a supplementary spec for specifying nonfunctional requirements is adequate and appropriate for managing software requirements. In addition, if this is the chosen method, the elaborated use cases can directly become the foundation for system testing.

To this end, this Second Edition of Managing Software Requirements has new content, a new theme, and a new subtitle: A Use Case Approach. In this edition, the use case technique is the cornerstone technique and a more prescriptive approach has been chosen and represented. For example, Chapter 14, A Use Case Primer, has been added to provide a more fundamental basis for understanding and applying use cases. It should serve as a tutorial adequate for an otherwise uninitiated individual to be able to learn and begin to apply the technique. The example and case study have also been updated to reflect a more use-case-centered approach. In addition, a new chapter, Chapter 26: From Use Case to Test Case has been added. This chapter illustrates how the use cases can directly drive a comprehensive test strategy as well as serve as direct input to the test cases themselves.

In addition, we've made one substantial enhancement motivated solely by our own purposes. Chapter 17, The Product Champion, has been renamed to become Product Management and enhanced with new material designed to help teams understand how to turn a software application into what we call the whole product solution. Since getting the requirements "right" cannot by itself insure commercial success, this chapter provides insight and guidelines for those activities, such as pricing and licensing, positioning and messaging, and other commercial factors that transform a working software application into a software product people want to buy.

Since modern software development processes are becoming more iterative, we decided to re-purpose the first edition's chapter on Quality so that this edition's chapter would be more in line with modern processes. It turned out that the new chapter may now be found as Chapter 29 and speaks directly to a much-improved fit between iterative techniques for gathering and improving requirements and the possibility of iterative quality improvements.

Finally, we also took the opportunity to address a new undercurrent in the industry, a movement on the part of many to what are perceived as lighter, less formal methods or more agile methods. In the extreme, extreme programming, or XP, as espoused by Beck and others, could be interpreted to eliminate process entirely. Perhaps more correctly, it incorporates certain keystone processes, such as direct customer requirements input, directly into programming practices, but it's also fair to note that the concepts of "software process" and the "M" word (methodology) are studiously avoided. Perhaps less extreme and considered by some to be more practical, the introduction of agile methods, as espoused by Cockburn and others, have also taken root in some circles. Though controversial in some circles, these lighter approaches should not be ignored and we've addressed these in the requirements context in another new chapter, Chapter 30, Agile Requirements Methods.

Of course, no book can be all things to all people and in order to make this edition as readable as possible, we eliminated a number of topics and chapters from the prior version, and shortened others.

In so doing, we sincerely hope that you will find this text more approachable, easier to use and apply, and that it will better help you and your teams to Manage Your Software Requirements.

—Dean Leffingwell