Managing Software Requirements (paperback): A Use Case Approach

Overview

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

See more details below
Paperback
$77.59
BN.com price
(Save 3%)$79.99 List Price
Other sellers (Paperback)
  • All (5) from $58.93   
  • New (4) from $58.93   
  • Used (1) from $77.58   
Sending request ...

Overview

"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

Read More Show Less

Product Details

  • ISBN-13: 9780321903723
  • Publisher: Addison-Wesley
  • Publication date: 12/21/2012
  • Edition number: 1
  • Pages: 502
  • Sales rank: 566,222
  • Product dimensions: 7.20 (w) x 9.00 (h) x 1.20 (d)

Meet the Author

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.

032112247XAB05082003

Read More Show Less

Read an Excerpt

PREFACE TO THE SECOND EDITIONBy Dean Leffingwell

Much has transpired since the first edition of this text was published in 1999. The "dot.com" bubble economy of the late 1990s (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.

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 and drive new, varied forms of communication, from the global electronic marketplaces that facilitate the exchange of goods and services to the after-school instant messaging chat-fests that 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 24/7. Internet cafes in Australia, in Scotland, and on Alaska-bound cruise ships are open 24 hours a day. We receive e-mails 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 Unified Modeling Language (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, recently acquired by IBM, I have moved on to helping independent software companies achieve their goals. Some teams hope to change the world; some hope to have a significant impact on individual lives by improving health care; still others hope to improve their customers' manufacturing efficiencies or to help businesses grow by translating product data into other languages. However, these teams all have one thing in common: they are challenged by the 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 who 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.

Therefore, 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 set of factors 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, two consistent themes emerged.


  • The "more use cases" theme. The first edition (subtitled 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—please be more prescriptive" theme. The first edition of this book was intended to be a comprehensive work, a one-stop-shopping reference for any technique readers 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 reviewers' 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 about which technique might be more effective or about the nuances of anything. "Just give me one technique, make it simple, and get me started right now," they say.

Fortunately, these two sets of inputs 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 specification of the 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 HOLIS case study has also been updated to reflect a more use-case-centered approach. Chapter 26, From Use Case to Test Case, has been added to illustrate 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 (which appeared in the first edition as Chapter 18, The Champion), has been renamed 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 ensure 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.

Also, since modern software development processes are becoming more iterative, we decided to repurpose the first edition's chapter on quality so that this edition's chapter would provide a more comprehensive look at quality within the context of a modern software process. Thus Chapter 29, Assessing Requirements Quality in Iterative Development, speaks directly to iterative techniques for gathering and improving requirements within an overall iterative development framework.

Finally, we also took the opportunity to address a new undercurrent in the industry, a movement toward what are perceived as lighter, less formal methods. In the extreme, Extreme Programming (XP), as espoused by Beck and others, could be interpreted to eliminate process entirely. Perhaps more correctly, XP 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 advocated by Cockburn and others, has also taken root. Though controversial in some circles, these lighter approaches cannot 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. 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.

We sincerely hope that you will find this revised text more approachable, as well as easier to use and apply, and that it will better help you and your teams to manage your software requirements.

Read More Show Less

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

Read More Show Less

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

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)