Managing Software Requirements: A Unified Approach / Edition 1 by Dean Leffingwell, Don Widrig | | 9780201615937 | Hardcover | Barnes & Noble
Managing Software Requirements: A Unified Approach / Edition 1

Managing Software Requirements: A Unified Approach / Edition 1

by Dean Leffingwell, Don Widrig
     
 

ISBN-10: 0201615932

ISBN-13: 9780201615937

Pub. Date: 10/29/1999

Publisher: Pearson

Despite the wealth of development knowledge, experience, and tools generally available today, a substantial percentage of software projects continue to fail, often because requirements are not correctly determined and defined at the outset, or are not managed correctly as the project unfolds. Clients do not always know or express their needs precisely, and too often

Overview

Despite the wealth of development knowledge, experience, and tools generally available today, a substantial percentage of software projects continue to fail, often because requirements are not correctly determined and defined at the outset, or are not managed correctly as the project unfolds. Clients do not always know or express their needs precisely, and too often designers and developers do not ask the right questions at the right times. As a result, projects often spin out of control as "feature bloat" and shifting priorities cause budgets and schedules to exceed expectations. 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.

The authors are skilled practitioners who have spent their careers in the trenches building high-quality applications, including safety-critical, real-time systems. Using an informal, approachable style, their own war stories, and a comprehensive case study they show how designers and developers can effectively identify requirements by employing the power of use cases and more traditional forms of requirements expression. The book illustrates proven techniques for determining, implementing, verifying, 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 specifically addresses the ongoing challenge of managing change and describes a process for assuringthat 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 clients, users, developers, and other stakeholders
  • Applying and refining use cases
  • Prototyping
  • Organizing and managing requirements information
  • Establishing project scope and managing customers
  • Using both informal and technical methods for specifying requirements
  • How to measure and improve the quality of your product's requirements
  • Moving from requirements to implementation
  • Verifying and validating the system
  • Managing change

The book concludes with a step-by-step guide to incorporating these powerful techniques into future projects.

Product Details

ISBN-13:
9780201615937
Publisher:
Pearson
Publication date:
10/29/1999
Series:
Object Technology Series
Edition description:
Older Edition
Pages:
528
Product dimensions:
7.76(w) x 9.46(h) x 1.13(d)

Table of Contents

Foreword xv
Preface xxi
Introduction 1(1)
Team Skill 1 Introduction 1(30)
The Requirements Problem
5(10)
The Goal
5(1)
A Look at the Data
6(1)
Root Causes of Project Success and Failure
7(8)
The Frequency of Requirements Errors
9(1)
The High Cost of Requirements Errors
10(3)
Conclusion
13(2)
Introduction to Requirements Management
15(8)
Definitions
15(2)
What Is Requirements Management?
16(1)
Application of Requirements Management Techniques
17(1)
Systems Applications
18(1)
The Road Map
18(3)
The Problem Domain
19(1)
Stakeholder Needs
19(1)
Moving Toward the Solution Domain
20(1)
Features of the System
20(1)
Software Requirements
20(1)
An Introduction to Use Cases
21(1)
Summary
21(2)
The Software Team
23(8)
Software Development as a Team Activity
24(2)
Requisite Team Skills for Effective Requirements Management
25(1)
Team Members Have Different Skills
25(1)
The Organization of Software Teams
26(1)
The Case Study
26(2)
Background for the Case Study
27(1)
The HOLIS Software Development Team
27(1)
Summary
28(3)
Team Skill 2 Analyzing the Problem 31(48)
The Five Steps in Problem Analysis
33(16)
Gain Agreement on the Problem Definition
35(1)
The Problem Statement
35(1)
Understand the Root Causes---The Problem Behind the Problem
36(3)
Addressing the Root Cause
38(1)
Identify the Stakeholders and the Users
39(2)
Define the Solution System Boundary
41(3)
Identify the Constraints to Be Imposed on the Solution
44(2)
Summary
46(1)
Looking Ahead
46(3)
Business Modeling
49(8)
Purpose of Business Modeling
50(1)
Using Software Engineering Techniques for Business Modeling
50(4)
Choosing the Right Technique
51(1)
The Unified Modeling Language (UML)
51(1)
Business Modeling Using UML Concepts
52(2)
From the Business Models to the Systems Model
54(1)
When to Use Business Modeling
55(1)
Summary
55(1)
Looking Ahead
56(1)
Systems Engineering of Software-Intensive Systems
57(22)
What Is Systems Engineering?
58(3)
Pragmatic Principles of Systems Engineering
59(1)
The Composition and Decomposition of Complex Systems
59(2)
Requirements Allocation in Systems Engineering
61(7)
On Derived Requirements
61(1)
A Quiet Revolution
62(1)
When Generations Collide: Graybeard Meets Young Whippersnapper
63(2)
Avoiding the Stovepipe System Problem
65(1)
When Subsystems Are Subcontracts
65(1)
Making It Work Out Right
66(2)
The Case Study
68(11)
Preliminary User Needs
68(1)
Problem Analysis
68(2)
HOLIS: The System, Actors, and Stakeholders
70(2)
HOLIS Systems Engineering
72(1)
The Subsystems of HOLIS
73(6)
Team Skill 3 Understanding User Needs 79(76)
The Challenge of Requirements Elicitation
81(6)
Barriers to Elicitation
82(2)
The "Undiscovered Ruins" Syndrome
83(1)
The "User and the Developer" Syndrome
83(1)
Techniques for Requirements Elicitation
84(3)
The Features of a Product or System
87(6)
Stakeholder and User Needs
87(1)
Features
88(5)
Managing Complexity by Picking the Level of Abstraction
90(1)
Attributes of Product Features
91(2)
Interviewing
93(10)
The Interview Context
94(1)
Value-Added Context
94(1)
The Moment of Truth: The Interview
95(4)
Compiling the Need Data
99(2)
The Analyst's Summary: 10 + 10 + 10 ≠ 30
99(1)
The Case Study
100(1)
A Note on Questionnaires
101(2)
Requirements Workshops
103(10)
Preparing for the Workshop
104(2)
Selling the Concept
104(1)
Ensuring the Participation of the Right Stakeholders
105(1)
Logistics
105(1)
"Warm-Up Materials"
105(1)
Role of the Facilitator
106(2)
Setting the Agenda
108(1)
Running the Workshop
109(4)
Brainstorming and Idea Reduction
109(1)
Production and Follow-Up
109(4)
Brainstorming and Idea Reduction
113(12)
Live Brainstorming
114(2)
Idea Reduction
116(4)
Pruning
116(1)
Grouping Ideas
117(1)
Feature Definition
117(1)
Prioritization
118(2)
Web-Based Brainstorming
120(1)
The Case Study: The HOLIS 2000 Requirements Workshop
120(5)
Attendees
121(1)
The Workshop
122(1)
The Session
122(1)
Analysis of Results
122(3)
Storyboarding
125(10)
Types of Storyboards
126(1)
What Storyboards Do
127(1)
Tools and Techniques for Storyboarding
128(1)
Tips for Storyboarding
129(1)
Summary
130(5)
Applying Use Cases
135(6)
Building the Use-Case Model
136(2)
Applying Use Cases to Requirements Elicitation
138(1)
Case Study: The Use Cases for HOLIS
139(1)
Summary
140(1)
Role Playing
141(6)
How to Role Play
142(1)
Techniques Similar to Role Playing
143(2)
Scripted Walkthroughs
143(1)
CRC (Class-Responsibility-Collaboration) Cards
144(1)
Summary
145(2)
Prototyping
147(8)
Types of Prototypes
147(2)
Requirements Prototypes
149(1)
What to Prototype
150(1)
Building the Prototype
150(1)
Evaluating the Results
151(1)
Summary
151(4)
Team Skill 4 Defining the System 155(32)
Organizing Requirements Information
159(10)
Organizing Requirements of Complex Hardware and Software Systems
161(2)
Organizing Requirements for Product Families
163(2)
On "Future" Requirements
165(1)
Business and Marketing Requirements versus Product Requirements
165(1)
The Case Study
166(1)
Summary
167(2)
The Vision Document
169(10)
Components of the Vision Document
170(4)
The "Delta Vision" Document
174(5)
Vision Document for Release 1.0
174(1)
Vision Document for Version 2.0
175(2)
The Delta Vision Document in a Legacy System Environment
177(2)
The Champion
179(8)
The Role of the Product Champion
180(1)
The Product Champion in a Software Product Environment
180(3)
The Product Champion in an IS/IT Shop
183(4)
Team Skill 5 Managing Scope 187(38)
The Problem of Project Scope
191(4)
Components of Project Scope
191(3)
The Hard Question
194(1)
Establishing Project Scope
195(12)
Setting Priorities
197(1)
Assessing Effort
197(2)
Adding the Risk Element
199(1)
Reducing Scope
200(3)
A Reasonable First Estimate
200(3)
The Case Study
203(4)
Managing Your Customer
207(6)
Engaging Customers to Manage Their Project Scope
207(1)
Communicating the Result
208(1)
Negotiating with the Customer
208(1)
Managing the Baseline
209(4)
Official Change
210(1)
Unofficial Change
211(2)
Scope Management and Software Development Process Models
213(12)
The Waterfall Model
214(1)
The Spiral Model
215(3)
The Iterative Approach
218(4)
Lifecycle Phases
219(1)
Iterations
219(1)
Workflows
220(2)
What to Do, What to Do ...
222(3)
Team Skill 6 Refining the System Definition 225(86)
Software Requirements
227(22)
Definition of Software Requirements
228(2)
Relationship between Features and Software Requirements
230(1)
The Requirements Dilemma: What versus How
231(3)
Exclude Project Information
231(1)
Exclude Design Information
232(2)
More on Requirements versus Design
234(2)
Iterating Requirements and Design
236(1)
A Further Characterization of Requirements
236(10)
Functional Software Requirements
237(1)
Nonfunctional Software Requirements
237(5)
Design Constraints
242(3)
Are Design Constraints True Requirements?
245(1)
Using Parent-Child Requirements to Increase Specificity
246(2)
Organizing Parent-Child Requirements
247(1)
Looking Ahead
248(1)
Refining the Use Cases
249(12)
Questions to Ask
250(2)
When Are Use Cases Not the Best Choice?
250(1)
The Redundancy Problem
251(1)
Refining Use-Case Specifications
252(3)
How Use Cases Evolve
253(1)
The Scope of a Use Case
254(1)
The Case Study: Anatomy of a Simple Use Case
255(5)
Define the Actor(s)
255(1)
Define the Use Case by Naming It
255(1)
Write a Brief Description
256(1)
Define a Flow of Events
256(2)
Identify Pre- and Postconditions
258(2)
Looking Ahead
260(1)
A Modern Software Requirements Specification
261(10)
The Modern SRS Package
262(6)
Who Owns the SRS Package?
264(1)
Organizing the Modern SRS Package
264(4)
Documenting Functional Requirements
268(2)
Looking Ahead
270(1)
On Ambiguity and Specificity
271(8)
Mary Had a Little Lamb
274(2)
Techniques for Disambiguation
276(1)
What to Do?
277(2)
Quality Measures of Software Requirements
279(18)
Nine Quality Measures
280(9)
Correct Requirements
280(1)
Unambiguous Requirements
281(1)
Completeness of the Requirements Set
282(2)
Consistency in the Requirements Set
284(1)
Requirements Ranked for Importance and Stability
285(1)
Verifiable Requirement
286(1)
Modifiable Requirements Set
287(1)
Traceable Requirements
288(1)
Understandable Requirements
289(1)
Quality Measures for the Use-Case Model
289(3)
Use-Case Specifications
290(1)
Use-Case Actors
291(1)
Quality Measures of the Modern SRS Package
292(5)
A Good Table of Contents
292(1)
A Good Index
293(1)
A Revision History
294(1)
A Glossary
295(2)
Technical Methods for Specifying Requirements
297(14)
Pseudocode
298(1)
Finite State Machines
299(2)
Decision Trees and Decision Tables
301(1)
Graphical Decision Trees
301(1)
Activity Diagrams
302(1)
Entity-Relationship Models
303(1)
Object-Oriented Modeling
304(1)
Data Flow Diagrams
305(2)
Maintenance of Specifications
307(1)
Case Study
308(3)
Team Skill 7 Building the Right System 311(92)
Building the Right System Right: Overview
313(6)
Continually Confirm that the Development Is on Track
314(3)
Principles of Software Verification
314(1)
The Cost of Verification
315(1)
Verification at All Levels
316(1)
The Reason for Verification
316(1)
Confirm that the Development Results Are Correct
317(1)
Learn How to Cope with Change that Occurs during the Development Process
318(1)
Looking Ahead
318(1)
From Requirements to Implementation
319(14)
Mapping Requirements to Design and Code
320(7)
The Orthogonality Problem
320(1)
Object Orientation
321(1)
The Use Case as a Requirement
322(1)
Managing the Transition
323(1)
Modeling Software Systems
323(3)
Role of the Use-Case Model in Architecture
326(1)
Realizing Use Cases in the Design Model
327(3)
Structural and Behavioral Aspects of Collaborations
328(1)
Using Collaborations to Realize Sets of Individual Requirements
328(2)
From Design to Implementation
330(1)
Summary
330(1)
Looking Ahead
331(2)
Using Traceability to Support Verification
333(14)
The Role of Traceability in Requirements Verification
333(4)
Implicit versus Explicit Traceability
335(1)
Additional Traceability Options to Consider
336(1)
Using Traceability Tools
337(4)
Maintenance of Traceability Relationships
340(1)
Proceeding without Traceability Tools
341(4)
Omitted Verification Relationships
342(2)
Excess Verification Relationships
344(1)
Thinking about Verification and Traceability
345(1)
Looking Ahead
346(1)
Validating the System
347(12)
Validation
348(2)
Validation Testing
348(2)
Validation Traceability
350(1)
Requirements-Based Testing
350(1)
Case Study: Testing Use Cases
350(3)
Test Case 1 Description
351(1)
Tracing Test Cases
351(2)
Testing Discrete Requirements
353(3)
Omitted Validation Relationships
354(1)
Excess Validation Relationships
355(1)
Testing Design Constraints
356(1)
Looking Ahead
357(2)
Using ROI to Determine the V&V Effort
359(8)
Depth versus Coverage
360(1)
V&V Coverage
361(1)
What to Verify and Validate
361(4)
Verify and Validate Everything
362(1)
Use a Hazard Analysis to Determine V&V Necessities
363(1)
Hazard Analysis as Return on Investment (ROI)
364(1)
Looking Ahead
365(2)
Managing Change
367(22)
External Factors
367(2)
Internal Factors
369(1)
"We Have Met the Enemy, and They Is Us"
369(2)
A Process for Managing Change
371(8)
Recognize that Change Is Inevitable, and Plan for It
371(1)
Baseline the Requirements
372(1)
Establish a Single Channel to Control Change
373(1)
Use a Change Control System to Capture Changes
373(3)
Manage Change Hierarchically
376(3)
Requirements Configuration Management
379(5)
Tool-Based Support for Change Management
379(2)
Elements Impacted by Change
381(1)
Audit Trail of Change History
382(2)
Configuration Management and Change Management
384(1)
Summary
384(5)
Getting Started
389(14)
Dedication
389(1)
What We've Learned So Far
389(6)
Introduction
389(1)
Analyzing the Problem
390(1)
Understanding User Needs
391(1)
Defining the System
392(1)
Managing Scope
393(1)
Refining the System Definition
394(1)
Building the Right System
394(1)
Your Prescription for Requirements Management
395(4)
Simplifying Assumptions
396(1)
The Recipe
396(3)
Now, On to the Next Release!
399(4)
Appendix A HOLIS Artifacts 403(32)
Appendix B Vision Document Template 435(12)
Appendix C Modern SRS Package Template 447(10)
Appendix D Requirements Management in the SEI-CMM and within ISO 9000 457(8)
Appendix E Requirements Management in the Rational Unified Process 465(12)
Bibliography 477(4)
Index 481

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >