Managing Software Requirements: A Use Case Approach, 2nd Edition

Product Author Bios

Dean Leffingwell, software business development consultant and former Rational Software executive, is a recognized authority on software requirements. He was cofounder and chief executive officer of Requisite, Inc., where he developed RequisitePro, the highly successful requirements management software tool, and Requirements College, the basis of Rational's popular requirements management professional development course series.

Don Widrig is an independent technical writer and consultant. He developed and delivered Rational Software's RequisitePro Tool Training Course until his "retirement" to the mountains of Colorado in 1997. When he is not busy watching the elk in his yard, Don writes a regular column for his local newspaper and does pro bono work helping the townspeople deal with their computers. He was formerly the vice president of research and development at RELA, Inc., a producer of safety-critical, real-time systems.

"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.

• The five steps in problem analysis
• Business modeling and system engineering
• Techniques for eliciting requirements from customers and stakeholders
• Establishing and managing project scope
• Applying and refining use cases
• Product management
• Transitioning from requirements to design and implementation
• Transitioning from use cases to test cases
• Agile requirements methods

Index

Download the Index file related to this title.

Preface

Much has transpired since the first edition of this text was published in 1999. The "dot.com" bubble economy of the late '90s, driven in part by the Internet, software, and related technology, has burst, causing significant disruption, economic uncertainty, and chaos in the lives of many. And yet, perhaps order and sanity have been restored to a free market that appeared to have "lost its wits" for a time.

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 Process and 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

Foreword

FOREWORD
By Ed Yourdon

THE ROCK PROBLEM
One of my students summarized the issues discussed in this book as the "rock" problem. She works as a software engineer in a research laboratory, and her customers often give her project assignments that she describes as "Bring me a rock." But when you deliver the rock, the customer looks at it for
a moment and says, "Yes, but, actually, what I really wanted was a small blue rock." The delivery of a small blue rock elicits the further request for a spherical small blue rock.

Ultimately, it may turn out that the customer was thinking all along of a small blue marble. Or maybe he wasn't sure what he wanted, but a small blue marble would have sufficed.

At each subsequent meeting with the customer, the developer may exclaim, "You want it to do what?" The developer is frustrated because she had something entirely different in mind when she worked long and hard to produce a rock with the characteristics she thought the customer said he needed; the customer is equally frustrated because he's convinced that he has expressed it clearly. These developers just don't get it!

To complicate matters, in most real projects, more than two individuals are involved. In addition to the customer and the developer-who may, of course, have very different names and titles-there are likely to be marketing people, testing and quality assurance people, product managers, general managers, and a variety of "stakeholders" whose day-to-day operations will be affected by the development of the new system.

All of these people can become frustrated by the problems of specifying an acceptable "rock," particularly because there often isn't enough time in today's competitive, fast-moving business world to scrap an expensive, two-year "rock project" and do it all over again. We've got to get it right the first time yet also provide for the iterative process in which the customer ultimately discovers what kind of rock he wants.

It's difficult enough to do this when we're dealing with tangible, physical artifacts like rocks. Most business organizations and government agencies today are "information intensive," so even if they're nominally in the business of building and selling rocks, there's a good chance that the rock contains an embedded computer system. Even if it doesn't, there's a good chance that the business needs elaborate systems to keep track of its e-commerce rock sales, its rock customers, its rock competitors and suppliers, and all of the other information that it needs to remain competitive in the rock business. Moreover, for thousands of companies today, those companies whose business is dedicated exclusively to the development and sales of software products, their entire business focuses on making their products-intangible and abstract as they are-into tangible rocks that their customers can purchase, evaluate, and apply.

Software systems, by their nature, are intangible, abstract, complex, and-in theory, at least-"soft" and infinitely changeable. So, if the customer begins articulating vague requirements for a "rock system," he often does this on the assumption that he can clarify, change, and fill in the details as time goes on. It would be wonderful if the developers-and everyone else involved in the creation, testing, deployment, and maintenance of the rock system-could accomplish this in zero time, and at zero cost, but it doesn't work that way.

In fact, it often doesn't work at all: More than half of the software systems projects taking place today are substantially over budget and behind schedule, and as much as 25 percent to 33 percent of the projects are canceled before completion, often at a staggering cost.

Preventing these failures and providing a rational approach for building the system the customer does want is the objective of this book. However, this is not a book about programming, and it's not written just for the software developer. This is a book about managing requirements for complex software applications. As such, this book is written for every member of the software team (analysts, developers, tester and QA personnel, project management, product management, documentation folks, and the like) as well as members of the external "customer" team (users and other stakeholders, marketing, and management)-everyone, really, who has a stake in the definition and delivery of the software system.

You'll discover that it is crucial that the members of both teams, including the non-technical members of the external team, master the skills required to successfully define and manage the requirements process for your new system-for the simple reason that they are the ones who create the requirements in the first place and who ultimately determine the success or failure of the system. The stand-alone, hero programmer is an anachronism of the past: May he rest in peace.

A Simple Metaphor: Building a House
If you were a building contractor, you wouldn't need to be convinced that a series of critical conversations with the homeowner are necessary; otherwise, you might end up building a two-bedroom house when your customer wanted a three-bedroom house. But it's equally important that these "requirements" be discussed and negotiated with the government authorities concerned with building codes and zoning regulations, and you may need to check with the next-door neighbors before you decide to cut down any trees on the property where the house will be built.

The building inspector and the next-door neighbors are among the other stakeholders who, along with the person who intends to pay for and inhabit the house, will determine whether the finished house meets their needs. It's also clear that these important stakeholders of your system, such as neighbors and zoning officials, are not users (homeowners), and it seems equally obvious that their perspectives on what makes a quality home may differ from the homeowner's opinion.

Again, we're discussing software applications in this book, not houses or rocks. The requirements of a house might be described, at least in part, with a set of blueprints and a list of specifications; similarly, a software system can be described with models and diagrams. But just as the blueprints for a house are intended as a communication and negotiation mechanism between laypeople and engineers-and lawyers and inspectors and nosy neighbors-so the technical diagrams associated with a software system can also be created in such a way that "ordinary" people can understand them.

Many of the crucially important requirements don't need any diagrams at all. The prospective house buyer, for example, can write a requirement in ordinary English that says, "My house must have three bedrooms, and it must have a garage large enough to hold two cars and six bicycles." As you'll see in this book, the majority of the crucial requirements for a software system can be written in plain English. In other cases, it would be more helpful to have a picture of what kind of fireplace the homeowner had in mind.

Many of the team skills you will need to master in order to address this challenge can also be described in terms of practical, commonsense advice. "Make sure you talk to the building inspector," we might advise our novice house builder, "before you dig the foundation for the house, not after you've poured the cement and begun building the walls and the roof." For a software project, we would offer similar advice: "Make sure you ask the right questions of the right people, make sure that you understand how the system is going to be used, and don't assume that 100 percent of the requirements are critical, because you're not likely to have time to finish them all before the deadline."

ABOUT THIS BOOK
In this book, Leffingwell and Widrig have taken a pragmatic approach to describing the solution to the rock problem. They have organized the book into eight parts. The Introduction provides some of the context, definitions, and background that you'll need to understand what follows. Chapter 1 reviews the systems development "challenge." The data shows that some software project failures are indeed caused by sloppy programming, but a number of studies demonstrate that poor requirements management may be the single largest cause of project failure. And though I've described the basic concept of requirements management in a loose, informal fashion in this foreword, the authors will define it more carefully in Chapter 2, in order to lay the groundwork for the chapters that follow. Chapter 3 provides an overview of some of the software development models in use today and concludes with a recommendation for an iterative process, one that facilitates additional requirements discovery along the way. Chapter 4 provides a brief introduction to some of the characteristics of modern software teams so they can relate the team skills that will be developed to the team context, wherein the skills must be applied.

Each of the next six major parts is intended to help you and your team understand and master one of the six requisite team skills for effective requirements management.

NOTE: The book is structured on the six requisite team skills for effective requirements management.

· To begin, of course, you will need a proper understanding of the problem that's intended to be solved with a new software system. That is addressed in Team Skill 1, Analyzing the Problem.
· Team Skill 2, Understanding User and Stakeholder Needs, is also crucial.
· Team Skill 3, Defining the System, describes the initial process of defining a system to address those requirements.
· Team Skill 4, Managing Scope, covers that absolutely crucial and often ignored process of managing the customer's expectations and the scope of the project.
· Team Skill 5, Refining the System Definition, illustrates key techniques that you will use in order to elaborate on the system to a level of detail sufficient to drive design and implementation, so the entire extended team knows exactly what kind of system you are building.
· Team Skill 6, Building the Right System, discusses the processes associated with building a system that fulfills the requirements. Team Skill 6 also discusses techniques you can use to validate that the system meets the requirements and, further, to help ensure that the system doesn't do anything malevolent to its users or otherwise exhibit unpleasant behaviors that are not defined by the requirements. And, since requirements for any nontrivial application cannot be frozen in time, the authors describe ways in which the team can actively manage change without destroying the system under construction. Team Skill 6 concludes with a chapter that suggests ways in which the requirements gathering process can improve the quality of the overall project. Special emphasis is given to the iterative nature of modern program development processes and how this yields substantial opportunities for an ongoing quality assessment.

After these descriptions of specific requirements management techniques, the authors briefly review the evolving methods of Extreme Programming and Agile Methods and demonstrate ways of integrating effective requirements management practices into the framework of these software development methods. Finally, in Chapter 31 the authors provide a prescription that you and your team can use to manage requirements in your next project.
I hope that, armed with these newly acquired team skills, you too will be able to build the perfect rock or marble. However, it will never be easy; even with the best techniques and processes, and even with automated tool support for all of this, you'll still find that it's hard work. Moreover, it's still risky; even with these team skills, some projects will fail because we're "pushing the envelope" in many organizations, attempting to build ever more complex systems in ever less time. Nevertheless, the skills defined in this book will go a long way toward reducing the risk and thereby helping you achieve the success you deserve.

Table of Contents

Foreword.


Preface to the Second Edition.


Preface to the First Edition.


Introduction.


1. The Requirements Problem.

Downloadable Sample Chapter

Download Sample Chapter 30 related to this title.