Register your product to gain access to bonus material or receive a coupon.
Managing Software Requirements: A Use Case Approach, 2nd Edition
- By Dean Leffingwell, Dean Leffingwell, Don Widrig
- Published May 5, 2003 by Addison-Wesley Professional. Part of the Addison-Wesley Object Technology Series series.
Book
- Sorry, this book is no longer in print.
About
Features
A pragmatic approach to the challenge of building more effective software requirements.
° New content, new theme, new subtitle! The use case approach is a cornerstone technique, and a more prescriptive approach is employed
° Proven "team skills" exercises help the reader roll the requirements process out to the reast of the team
° Foreword by Ed Yourdon
Description
- Copyright 2003
- Edition: 2nd
- Book
- ISBN-10: 0-321-12247-X
- ISBN-13: 978-0-321-12247-6
"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.
Topics covered include:- 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
032112247XB05082003
Sample Content
Downloadable Sample Chapter
Download Sample Chapter 30 related to this title.
Table of Contents
Foreword.
Preface to the Second Edition.
Preface to the First Edition.
Introduction.
1. The Requirements Problem.
The Goal of Software Development.
A Look at the Data.
The Root Causes of Project Success and Failure.
The Frequency of Requirements Errors.
The High Cost of Requirements Errors.
Summary.
2. Introduction to Requirements Management.
Definitions.
What Is a Software Requirement?
What Is Requirements Management?
Application of Requirements Management Techniques.
Types of Software Applications.
Systems Applications.
The Road Map.
The Problem Domain.
Stakeholder Needs.
Moving Toward the Solution Domain.
Features of the System.
Software Requirements.
Summary.
3. Requirements and the Software Lifecycle.
Traditional Software Process Models.
The Waterfall Model.
The Spiral Model.
The Iterative Approach.
Lifecycle Phases.
Iterations.
Disciplines.
Requirements in the Iterative Model.
Summary.
4. The Software Team.
Software Development as a Team Activity.
Requisite Team Skills for Effective Requirements Management.
Team Members Have Different Skills.
The Organization of Software Teams.
The Case Study.
Background for the Case Study.
The HOLIS Software Development Team.
Summary.
Team Skill 1 Analyzing the Problem.
5. The Five Steps in Problem Analysis.
Step 1: Gain Agreement on the Problem Definition.
The Problem Statement.
Step 2: Understand the Root Causes-The Problem Behind the Problem.
Addressing the Root Cause 48
Step 3: Identify the Stakeholders and the Users.
Step 4: Define the Solution System Boundary.
Step 5: Identify the Constraints to Be Imposed on the Solution.
Summary.
Looking Ahead.
6. Business Modeling.
The Purpose of Business Modeling.
Using Software Engineering Techniques for Business Modeling.
Choosing the Right Technique.
The Unified Modeling Language.
Business Modeling Using UML Concepts.
From the Business Model to the Systems Model.
When to Use Business Modeling.
Summary.
Looking Ahead.
7. Systems Engineering of Software-Intensive Systems.
What Is Systems Engineering?
Pragmatic Principles of Systems Engineering.
The Composition and Decomposition of Complex Systems.
Requirements Allocation in Systems Engineering.
On Derived Requirements.
A Quiet Revolution.
When Generations Collide: Graying Baby Boomer Meets Generation X-er.
Avoiding the Stovepipe System Problem.
When Subsystems Are Subcontracts.
Addressing the Conundrum.
The Case Study: Systems Engineering for HOLIS.
Preliminary User Needs.
Problem Analysis.
HOLIS: The System, Actors, and Stakeholders.
HOLIS Systems Engineering.
The Subsystems of HOLIS.
Summary.
Team Skill 1 Summary.
Team Skill 2 Understanding User and Stakeholder Needs.
8. The Challenge of Requirements Elicitation.
Barriers to Elicitation.
The "Yes, But" Syndrome.
The "Undiscovered Ruins" Syndrome.
The "User and the Developer" Syndrome.
Summary.
9. The Features of a Product or System.
Stakeholder and User Needs.
Features.
Managing Complexity by Picking the Level of Abstraction.
Attributes of Product Features.
Summary.
10. Interviewing.
Context-Free Questions.
Solutions-Context Questions.
The Moment of Truth: The Interview.
Compiling the Needs Data.
The Analyst's Summary: 10 + 10 + 10 pi 30.
The Case Study.
A Note on Questionnaires.
Summary.
11. Requirements Workshops.
Accelerating the Decision Process.
Preparing for the Workshop.
Selling the Concept.
Ensuring the Participation of the Right Stakeholders.
Attending to Logistics.
Providing Warm-Up Materials.
Choosing the Facilitator.
Setting the Agenda.
Running the Workshop.
Problems and Tricks of the Trade.
Brainstorming and Idea Reduction.
Production and Follow-Up.
Summary.
12. Brainstorming and Idea Reduction.
Live Brainstorming.
Idea Reduction.
Pruning Ideas.
Grouping Ideas.
Defining Features.
Prioritizing Ideas.
Web-Based Brainstorming.
The Case Study: The HOLIS Requirements Workshop.
The Attendees.
The Workshop.
The Session.
The Analysis of Results.
Summary.
13. Storyboarding.
Types of Storyboards.
What Storyboards Do.
Tools for Storyboarding.
Tips for Storyboarding.
Summary.
Team Skill 2 Summary.
Team Skill 3 Defining the System.
14. A Use Case Primer.
The Benefits of Use Cases.
Use Case Basics.
On Actors.
Use Case Anatomy.
A Step-by-Step Guide to Building the Use-Case Model.
Step 1: Identify and Describe the Actors.
Step 2: Identify the Use Cases and Write a Brief Description.
Step 3: Identify the Actor and Use-Case Relationships.
Step 4: Outline the Individual Use Cases.
Step 5: Refine the Use Cases.
On Use Cases, Storyboarding, and User Interface Design.
Use Cases and User Interfaces.
Use Cases and Storyboarding.
A Use Case Storyboard Example.
The Case Study: The HOLIS Use Cases.
Find the HOLIS Actors.
Find the HOLIS Use Cases.
Associate the Actors and Use Cases.
Outline the Use Cases.
Summary.
15. Organizing Requirements Information.
Organizing Requirements of Complex Hardware and Software Systems.
Organizing Requirements for Product Families.
On "Future" Requirements.
The Case Study: Organizing the HOLIS Requirements.
Summary.
Looking Ahead.
16. The Vision Document.
Components of the Vision Document.
The Delta Vision Document.
The Vision Document for Version 1.0.
The Vision Document for Version 2.0.
The Delta Vision Document in a Legacy System Environment.
Summary.
17. Product Management.
The Role of the Product Champion.
The Product Manager in a Software Product Company.
Primary Activities for a Product Manager.
Driving the Vision.
Maintaining the Product Road Map.
Defining the Whole Product Plan.
Sponsoring the Use-Case Model and Supplementary Requirements.
Testing the Product Concept.
Completing the User Experience.
Defining Commercial Terms.
Positioning and Messaging.
Supporting Activities.
Branding and Product Labeling.
End User Training Materials.
Product Demo.
Sales and Marketing Collateral.
The Product Champion in an IS/IT Shop.
Summary.
Team Skill 3 Summary.
Team Skill 4 Managing Scope.
18. Establishing Project Scope.
The Problem of Project Scope.
The Hard Question.
The Requirements Baseline.
Setting Priorities.
Assessing Effort.
Adding the Risk Element.
Reducing Scope.
A Reasonable First Estimate.
The Case Study: Scope Management for HOLIS.
Summary.
19. Managing Your Customer.
Engaging Customers to Manage Their Project Scope.
Communicating the Result.
Negotiating with the Customer.
Managing the Baseline.
Official Changes.
Unofficial Changes.
Summary.
Team Skill 4 Summary.
Team Skill 5 Refining the System Definition.
20. Software Requirements-A More Rigorous Look.
Looking Deeper into Software Requirements.
The Relationship between Software Requirements and Use Cases.
The Relationship between Features and Software Requirements.
The Requirements Dilemma: What versus How.
Excluding Project Information.
Excluding Design Information.
More on Requirements versus Design.
Iterating Requirements and Design.
A Further Characterization of Requirements.
Functional Software Requirements.
Nonfunctional Software Requirements.
Design Constraints.
Summary.
Looking Ahead.
21. Refining the Use Cases.
How Use Cases Evolve.
The Scope of a Use Case.
The Case Study: Anatomy of a Simple Use Case.
Reviewing the Actors.
Reviewing the Name.
Refining the Description.
Defining and Refining the Flow of Events.
Identifying the Pre- and Post-conditions.
Identifying Special Requirements.
Summary of Our Refined Use Case.
Extending Use Cases.
Including Use Cases in Other Use Cases.
Summary.
Looking Ahead.
22. Developing the Supplementary Specification.
The Role of the Supplementary Specification.
Expressing Functional Requirements in the Supplementary Specification.
Exploring Nonfunctional Requirements.
Usability.
Reliability.
Performance.
Supportability.
Understanding Design Constraints.
Sources of Design Constraints.
Handling Design Constraints.
Are Design Constraints True Requirements?
Identifying Other Requirements.
Linking the Supplementary Specification to the Use Cases.
Template for the Supplementary Specification.
Summary.
Looking Ahead.
23. On Ambiguity and Specificity.
Finding the "Sweet Spot".
Mary Had a Little Lamb.
Techniques for Disambiguation.
Summary.
24. Technical Methods for Specifying Requirements.
Pseudocode.
Finite State Machines.
Decision Tables and Decision Trees.
Activity Diagrams.
Entity-Relationship Models.
Summary.
Team Skill 5 Summary.
Team Skill 6 Building the Right System.
25. From Use Cases to Implementation.
Mapping Requirements Directly to Design and Code.
The Orthogonality Problem.
Object Orientation.
The Use Case as a Requirement.
Managing the Transition.
Modeling Software Systems.
The Architecture of Software Systems.
The Role of the Use-Case Model in Architecture.
Realizing Use Cases in the Design Model.
Structural and Behavioral Aspects of Collaborations.
Using Collaborations to Realize Sets of Individual Requirements.
From Design to Implementation.
Summary.
Looking Ahead.
26. From Use Cases to Test Cases.
A Tester's Perspective: Musings on the Big Black Box.
Is a Use Case a Test Case?
Common Testing Terms.
Relationships of Test Artifacts.
The Role of the Test Cases.
Use-Case Scenarios.
Deriving Test Cases from Use Cases: A Four-Step Process.
Step 1: Identify the Use-Case Scenarios.
Step 2: Identify the Test Cases.
Step 3: Identify the Test Conditions.
Step 4: Add Data Values to Complete the Test Case.
Managing Test Coverage.
Black-Box versus White-Box Testing with Use Cases.
Summary.
27. Tracing Requirements.
The Role of Traceability in Systems Development.
The Traceability Relationship.
A Generalized Traceability Model.
Tracing Requirements in the System Definition Domain.
Tracing Requirements to Implementation.
Tracing from Requirements to Testing.
Using Traceability Tools.
Proceeding without Traceability Tools.
Summary.
28. Managing Change.
Why Do Requirements Change?
External Factors.
Internal Factors.
°We Have Met the Enemy, and They Is Us°.
A Process for Managing Change.
Step 1: Recognize That Change Is Inevitable, and Plan for It.
Step 2: Baseline the Requirements.
Step 3: Establish a Single Channel to Control Change.
Step 4: Use a Change Control System to Capture Changes.
Step 5: Manage Change Hierarchically.
Requirements Configuration Management.
Tool-Based Support for Change Management.
Elements Impacted by Change.
Audit Trail of Change History.
Configuration Management and Change Management.
Summary.
Looking Ahead.
29. Assessing Requirements Quality in Iterative Development.
Software Project Quality.
Assessing Quality in Iterative Development.
Requirements Artifacts Sets.
Performing the Assessment.
Quality Assessment Checklists for Requirements.
Summary.
Team Skill 6 Summary.
Looking Ahead.
Getting Started.
Dedication.
What You've Learned So Far.
Introduction.
Team Skill 1: Analyzing the Problem.
Team Skill 2: Understanding User and Stakeholder Needs.
Team Skill 3: Defining the System.
Team Skill 4: Managing Scope.
Team Skill 5: Refining the System Definition.
Team Skill 6: Building the Right System.
30. Agile Requirements Methods.
Mitigating Requirements Risk with Effective Requirements Practices.
Methodology Design Goals.
Documentation Is a Means to an End.
An Extreme Requirements Method.
An Agile Requirements Method.
A Robust Requirements Method.
Summary.
31. Your Prescription for Requirements Management.
Selecting Your Requirements Approach.
The Simplifying Assumptions.
The Prescription.
On to the Next Release!
Appendixes.
Appendix A. HOLIS Artifacts.
Appendix B. Vision Document Template.
Appendix C. Use-Case Specification Template.
Appendix D. Supplementary Specification Template.
Appendix E. Requirements Management in the Rational Unified Process.
Appendix F. Requirements Management in the SEI-CMM and within ISO 9000:2000.
Bibliography.
Index. 032112247XT05082003
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
032112247XP01272003
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.
Index
Download the Index
file related to this title.