Effective Requirements Practices

Description

• Copyright 2001
• Dimensions: 7-1/4" x 9-1/4"
• Pages: 400
• Edition: 1st

• Book
• ISBN-10: 0-201-70912-0
• ISBN-13: 978-0-201-70912-4

More than 25% of all software projects still fail outright -- costing organizations billions of dollars. One key reason: a failure to effectively define project requirements. In this book, leading enterprise software project manager Ralph Young brings together today's best techniques for gathering requirements, presenting solutions for every project role and stakeholder -- technical and business. Young demonstrates how to identify initial requirements, prioritize and specify requirements, iterate specifications to achieve greater clarity; identify the best ways each requirement can be met; and verify and validate requirements prior to coding. He offers proven techniques for establishing positive partnerships and effective communication with business managers, technical professionals, and software users; handling changes that occur during the course of a project; maintaining a project's momentum in the face of corporate politics and other obstacles; and much more. The book includes comprehensive templates that can be used to improve existing software requirements processes -- or to establish entirely new processes. For all project stakeholders: IT executives, project managers, software engineers, application developers, testers, quality specialists, integrators, even software consumers.



Downloads

CD Contents

Download the CD Contents related to this title.



Extras

Related Articles

Guidelines for Effective Emailing

Requirements Planning: A Little-Used But Valuable Technique

Save Money by Improving Requirements Practices

Interview(s)

Click below for Interview related to this title:
Interview



Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
youngch4.pdf

Table of Contents

List of Figures.


Foreword.


Preface.


Acknowledgments.

I. Background.

1 Introduction.

The State of the Industry Today.

The Need to Use Effective Requirements Practices.

The Requirements Process.

What is a Process?

What Is the Requirements Process?

Benefits of a Process Approach.

Pitfalls of Using a Process Approach.

About This Book.

Roles.

Key Terms.

A Requirements Taxonomy.

Systems and Software Engineers.

Intended Audience.

Recommended Mind-set for Readers of This Book.

The "Team," the "Project," and the "Project Manager".

Footnotes in This Book.

Key References and Suggested Readings.

Upcoming Topics.

Summary.

Key References and Suggested Readings.

II Recommended Requirements Practices.

2 Commit to the Approach.

What Do We Mean by Commitment?

How Can Commitment Be Attained and Maintained?

Recommendations to Assist in Evolving the Partnering Approach.

Involve Managers with Authority in the Partnering Workshop.

Develop a Requirements Plan.

Utilize a Set of Mechanisms, Methods, Techniques, and Tools.

Work Toward a Quality Culture.

Summary.

Key References and Suggested Readings.

3 Establish and Utilize a Joint Team Responsible for the Requirements.

What Is a "Joint Team"?

What Does the Joint Team Do?

How Is the Joint Team Created?

Who Should Be on the Joint Team?

How Often Should the Joint Team Meet?

What Metrics Need to Be Created and Tracked?

Calculating Return on Investment (ROI) from Using Effective Requirements Practices.

Customer and Supplier Roles.

Summary.

Key References and Suggested Readings.

4 Define the Real Customer Needs.

Recommendations to Facilitate Getting to the Real Requirements.

Invest More in the Requirements Process.

Train PMs to Pay More Attention to the Requirements Process.

Identify a Project Champion.

Define the Project Vision and Scope.

Identify a Requirements Engineer and Utilize Domain Experts to Perform Requirements Engineering Tasks.

Train Developers Not to Make Requirements Decisions and Not to Gold Plate.

Utilize a Variety of Techniques to Elicit Customer and User Requirements and Expectations.

Use Cases.

Train Requirements Engineers to Write Good Requirements.

The Impact of Requirements Errors.

The Importance of Requirements to Program Costs.

What Is a Good Requirement?

Document the Rationale for Each Requirement.

Utilize Methods and Automated Tools to Analyze, Prioritize, and Track Requirements.

Approaches, Tools, and Methods for Prioritizing Requirements.

Collect Requirements from Multiple Viewpoints.

Consider the Use of Formal Methods When Appropriate.

Pitfalls.

Summary.

Key References and Suggested Readings.

5 Use and Continually Improve a Requirements Process.

What Is a Process?

How Is a Process Designed?

Why Is a Requirements Process Needed?

Goals of Requirements Engineers.

A Sample Requirements Process.

How Can Organizations Create or Tailor a Requirements Process?

Tailoring of Processes.

Web Support: An Organizational Process Asset Library.

Summary.

Key References and Suggested Readings.

6 Iterate the System Requirements and Architecture Repeatedly.

The System Engineering Process.

Recommendations.

Consider the "Designability" of the System When Addressing the Requirements.

Allocate Requirements to Functional Partitions, Objects, People, or Support Elements to Support Synthesis of Solutions.

Utilize a System Architecture Process.

Consider Open Systems Standards.

Guidelines for "Architecting".

Another View.

Summary.

Key References and Suggested Readings.

7 Use a Mechanism to Maintain Project Communication.

Setting the Stage.

Natural Human Tendency.

A Proactive Approach to Achieve Effective Communication.

An Example Mechanism.

When Negativism Shows Up.

Another Valuable Mechanism<171>Brown Bags.

Guidelines for Effective Meetings.

Guidelines for Effective E-mail Communication.

The Value of a Common Vocabulary.

The Use of Vertical Experts.

Avoid Multiple Locations.

A Final Recommendation.

Summary.

Key References and Suggested Readings.

8 Select Familiar Methods and Maintain a Set of Work Products.

The Foundation for System Development.

What Are the Candidate Methods and Techniques?

Which Methods and Techniques Are Best?

Use of Function Points for Software Estimation.

Quality Function Deployment.

What Comprises the Requirements Specification?

The Rationale for Prioritizing Requirements.

Summary.

Key References and Suggested Readings.

9 Perform Requirements Verification and Validation.

V&V Terminology.

The Importance of V&V.

V&V Planning.

Verification Methods.

V&V Techniques.

Using Traceability to Support Verification.

A Structured Approach to Testing.

Recommendations.

Pitfalls.

Summary.

Key References and Suggested Readings.

10 Provide an Effective Mechanism to Accommodate Requirements Changes.

Why Such Emphasis?

Planning for Changes in Requirements.

The Recommended Mechanism.

Requirements Leakage.

Focus on What Counts!

How Much Can Requirements Change?

A Way to Deal with Requirements Creep Contractually.

Other Recommendations.

Summary.

Key References and Suggested Readings.

11 Perform the Development Effort Using Known, familiar Proven Industry, Organizational, and Project Best Practices.

What's All the Fuss?

What Can We Do About It?

Recommendations.

Provide to the Development Team an Understanding of the Relevant Policies, Processes, and Procedures to Be Used.

Utilize a Practical, Effective Project Management Approach.

Ensure That Selected Members of the Development Team Have Domain Knowledge.

Perform the Development Effort Using Known (Trained), Proven Processes, Mechanisms, Methods, Techniques, and Tools.

Provide and Utilize Mechanisms to Foster Effective Communications Throughout the Development Team.

Utilize Peer Reviews and Inspections to Remove Defects from Processes and Work Products.

Ensure That Configuration Management Is Effective.

Foster an Independent QA Role That Proactively Assists and Supports the Development Team and Provides Value to the Project.

Ensure That Subcontractors Are Managed So That Their Contributions Are Effective.

Use Appropriate, Useful Metrics to Manage the Project.

Ensure That a Systematic Approach to Involving the Customer in This Entire Effort Is Working.

Manage Processes Quantitatively. Also, Use a Defect Prevention (DP) Process, a Technology Change Management (TCM) Process, and a Process Change Management (PCM) Process. Perform Extensive Reinsertion and Reuse Throughout the Organization.

Musings on Project Management.

Summary.

Key References and Suggested Readings.

III.What to Do Next.

12 How to Proceed.

Common Issues.

Key Factors in Addressing These Issues.

The Customer.

Requirements as a Key Driver to Any Systems or Software Effort.

Financing Improvements in the Requirements Process.

Survival of the Fittest.

Management Awareness and Expectations.

Metrics.

The Development Team.

Where to Start.

How to Prioritize Needed Efforts.

Relationship of the Recommended Effective Requirements Practices to the CMM.

But I Have So Many Things to Do....

What If We Are "Further Along" on Our Project?

Summary.

Key References and Suggested Readings.

Epilogue.

List of Acronyms.

Glossary.

Credits.

Bibliography.

Author Index.
Subject Index. 0201709120T04062001.

Preface

Dealing effectively with requirements tops the list of the challenges to managers and practitioners developing systems and software. Improving the effectiveness of requirements practices has been a focus for me throughout my career. My vision of this book is to help you in your life's work by providing practical, useful, effective requirements practices.

This book describes ten requirements practices that provide a framework for overcoming current industry problems. Although systems and software development efforts have been going on for five decades, the industry has major difficulty worldwide in delivering products that meet customer needs. By applying effective requirements practices, one can remove causes of project failure. The reasons for failure are well documented (see Chapter 1). The needed improvement activities can be financed via the one third of total project costs now wasted. This book is full of suggestions concerning how to transform this waste into productive use.

The theme of this book is that practitioners should insist on using effective requirements practices. The use of effective requirements practices will reduce costs, improve the quality of work products, and increase customer satisfaction. The practices, ideas, suggestions, and recommendations provided in this book can be used individually or collectively, and not all have to be implemented to achieve progress. One can gradually implement some good practices quickly, with good payback, and then continue to work toward a more sophisticated, high-performance set of requirements practices.

This book provides a baseline for managers and project leaders to use to ensure that they are doing what is necessary to make a project successful. The practices, methods, techniques, and the requirements process itself have been filtered through experience, so the ideas are practical, cost-effective, and proven.

This book deals with the practical difficulties of requirements elicitation and management from a pragmatic, organizational, and project perspective. Attention is given to the pitfalls, costs, and risks as well as to the benefits of these practices. Unfortunately, many good practices never get implemented because the benefits are oversold, and the costs and risks aren't recognized. Political realities of organizations and projects must also be considered.

Application of the practices in this book will result in more productive, healthier, and happier organizations for systems and software development. The analysis extends beyond the technical issues to human issues and values. This book emphasizes the need for a shared vision of project success and advises how to obtain the required customer and supplier commitment.

The effective requirements practices described in this book will help you whether you are in a small organization or a large one, whether you build systems or software. Advice is provided for the information technology executive, consultant, manager, architect, systems or software engineer, systems integrator, developer, tester, process improvement engineer, member of the quality assurance group, or one responsible for configuration management. This book is invaluable for systems and software engineering courses, at both the undergraduate and graduate levels, and also for venues relating practical, useful guidance such as industry association and corporate courses concerning management of systems, requirements, as well as systems and software process engineering.

Although one frequently sees references to "requirements management," let's be clear that the challenge to system and software developers extends far beyond simply managing requirements. The requirements process is a full life cycle systems engineering process. It requires special effort and practices at the beginning of a project or system to identify what I refer to as the real requirements. Because the world changes while we are developing systems and software, it's essential to address new and changed requirements within the requirements process.

The requirements process requires mechanisms, for example, to achieve a shared vision, to ensure joint customer and supplier responsibility for the requirements, and to enable effective project coordination. The requirements process impacts every other activity performed in developing systems and software. One needs an automated requirements tool that provides for attributes such as the priority of each requirement, how it is linked to the design, where it is met in the code, how it is verified and tested, and so forth. It should be apparent already that we as an industry do not spend enough time and effort on the requirements process, and that this itself is a root cause of our problems.

The requirements comprise the basis for all the development work that follows. If you don't get the requirements right, you are in for a long, hard, and expensive pull. Your chances of "finishing" are small, and the probability of satisfying the users of the planned system is nil. We know from industry experience that customers don't know their "real requirements" (even though they may have spent a lot of time defining them and believe they know them). Suppliers and system developers don't know them either. Identifying the real requirements requires an interactive requirements process, supported by effective mechanisms, methods, techniques, and tools. The requirements process need not be complicated or expensive. However, a requirements process is required for a project of any size. It's more important that a project or organization have a requirements process than the nature of its specific components.

This leads to another fundamental premise of this book: Continuous improvement and a quality ethic within a project or organization lead to repeatable processes and reuse that save time and money. My commitment to these values comes from my work experiences and also from my study under Dr. W. Edwards Deming. Dr. Deming clarified for me that many of the root causes of problems are not technical issues. Rather, the root causes concern our responsibility as organizational and project executives, managers, and leaders to provide the environment in which "the workers"can be effective, productive, and fulfilled. Management must empower its work force to unleash its incredible capabilities.

The systems and software development environment needs attention, as we all can attest, based on our experience. The effective practices advocated in this book will facilitate your creation of the needed environment and will empower and enable your development team. I have witnessed (as I hope you have too) the power and the results of effective teams in positive environments. My experience is that an empowered team can accomplish anything it sets out to do. We must work to create the needed environment for success.

To benefit from the information in this book, you need bring only your involvement in systems and software-related activities coupled with a desire to improve. If you are a customer or client of the system or software provider industry, you will be particularly interested in Chapters 1 through 5 and 12. If you are a practitioner already familiar with the issues and problems, you may proceed directly to whichever of Chapters 2 through 11 relate most closely to your specific work activities, noting the references to additional information and sources. If you are an executive or manager, you may want to focus on Chapters 1, 7, and 12 to gain added insight into the issues, to garner a high-level understanding, and to formulate some ideas concerning candidate improvement actions. If you are a student of systems or software engineering, you'll likely find it worth your time to proceed deliberately through the book. If you are participating in a requirements-related course, you'll find the entire book insightful and provocative.

A rich collection of suggested references is provided in the footnotes, the Key References and Suggested Readings sections provided for each chapter, and the bibliography. No source is included just because it provides related information. Rather, each and every one is noted because it provides additional insights, more detailed suggestions and ideas, a recommended technique/approach, or an alternative concept you might want to consider.

Primary Features of This Book

• Provides a practical organizational and project perspective.
• Emphasizes the need for a partnership approach and explains how to obtain commitment.
• Focuses on specific improvement activities.
• Explains how to evolve the real requirements.
• Considers the human dimension.
• Emphasizes the importance of effective communication.
• Provides sample templates (for example, for a requirements process and a requirements plan).
• Discusses the need to iterate the requirements and the architecture.
• Recommends how to deal with changing requirements.
• Explains requirements verification and validation.
• Suggests several mechanisms to facilitate self-correction and to help maintain momentum.
• Stresses the need for an automated requirements tool.
• Provides advice and recommendations for executives, project managers, and leaders.
• Enables organizations and projects to utilize their resources better.
• Includes a rich set of references.

I am very grateful to a large number of reviewers for the material presented in this book. They have been helping me for 28 years to understand what works. Some I've come to know only recently, and many of them are industry experts in requirements, systems, or software engineering. The publisher tasked some industry experts to review these materials, and their review comments were invaluable. Others provided informal reviews because they are experts in particular areas or because they are professionally interested. Addison-Wesley's publishing professionals have made an invaluable contribution to the final product.

All of the reviewers have reinforced something I already knew: These practices are urgently needed today on projects and efforts of all sizes in all systems and software efforts. My hope is that they will help you. Of course, different practices work well in different environments. This is something we all understand from our experience, no matter where that experience was acquired or what fields it concerned. So you will need to select appropriate practices, recommendations, and suggestions, and apply them with a large measure of common sense--always a great guide!

I hope that you take the time and effort to share with me your experiences in applying the practices, recommendations, and suggestions in this book. This will help me further strengthen and improve my own insights and understandings and, God willing, allow me to share them again with others. Please write to me at ryoungrr@aol.com

Ralph Young

February 2001

0201709120P04062001

Index

Subject Index

ABT Corporation, 266

Accountability, 238

Acronyms, 40, 72, 83, 301-308

Action Item (AI) list, 166-167

Action Plan, 285

Action planning worksheet, 35

Activities Checklist, 279-284

Actual cost of work performed (ACWP), 256n

Adversarial requirements development, 185

Advocate(s), 224

customer, 46n

project champion as, 59, 64

user, 46n

Agreement

basis of, 180

documentation of, 228, 253

partnering, 33, 36, 162

Algorithm analysis, 208

Aligning developers interests with work assignments, 241

Allocated requirement, 146

Allowing projects to get out of control, 220, 225

Analytic Hierarchy Process (AHP), 88

Appreciation, 241

Approaches, inadequate, 218

Architecture, 132-154

architectural framework, 147

architecture-based design (ABD), 135

baseline, 145

detailed, 150

development cycle, 151

development process, 147, 151

hierarchical, 17

high-level, 134, 135

open, 144, 146-147, 219

physical, 132

planned, 132, 144

robust, 132n

SA process, 136-146

software, 135

synthesis, 22

system, 7, 118, 121, 132, 163, 209

testbed, 243

TOGAF, 144, 149-151

views, 148-149

Architecture trades, 149n

Artifact evolution, 243-244

A spec, 291

Assumptions

for calculating rework costs, 50, 51

in OCD, 66, 69

about requirements, 105, 107, 108, 120-121, 152

reuse and, 153

Attitudes

fostered by PMs and chairs of project teams, 161

of mature organizations, 262, 266

toward peer reviews, 249

in quality cultures, 40, 108

Attribute, 85-86, 118

availability, 68, 70, 148n

maintainability, 68, 70, 148n

matrix, 87

performance, 148n

prioritization, 195

reliability, 68, 70, 148n

requirements creep, 224

requirements specification, 192

security, 148n

Audience for book, 17-18

Automated requirements tools, 104-105, 192

attributes, 85-86, 118

prioritization, 195

verification, 213

Bailing, 194

Barriers, 33, 42, 230

Barriers and aids analysis, 164

Baseline, requirements, 144-145, 212

Base Practices, 127, 150

Being "right," 249

Benchmarking, 22

Benefit to cost sensitivity analysis, 116, 117

Be our own worst enemies, 249

Best in class, 22, 198

Better requirements, 50-51, 98, 132n, 180, 183

Bottlenecks, 266

Bottom-up approach, 151

Brainstorming, 164

Branding, 147

Brown bag, 15, 165, 247

B spec requirement, 211

Budget at completion (BAC), 256n

Budgeted cost of work performed (BCWP), 256n

Budgeted cost of work scheduled (BCWS), 256n

Bugs, 189, 213

Business

activity (function), 103

goals, 9, 145

objectives, 9, 73, 219

requirement, 9, 50, 65, 73, 135n

scenarios, 9

Business opportunities, new, 193, 218

Buyer. See Customer

CAIV process, 135

Calculated cost at completion (CAC), 256n

Canceled project, 233, 298

Capability Maturity Model (CMM), 11-12, 241

CMMI, 111n, 125-126

intergroup coordination, 160n

key practices, 289-290

peer reviews, 249

People CMM, 110n

Software-CMM, 110-111, 126, 219n

subcontractor management, 253-255, 276

Systems Engineering-CMM, 63n, 110-111, 126-127, 150

Capture design results, 143, 145

Case study, 258

Champion, project, 59, 63-64

Change control, 186, 250

CHAOS Report, 103-104

Charter, project, 36

Chief Information Officers (CIO) Council, 157-158

Clinger Cohen Act of 1996, 157

Clueless project development staff, 235

CMM Integration (CMMI), 111n, 125-126

Code and fix development practices, 297

Commercial off-the-shelf (COTS), 9, 147

Commitment, 28-42

attainment of, 30-37

defined, 30

maintenance of, 30-37

partnering workshop, 30-34

recommendations, 37-41

rules of conduct, 41

suppliers, 28-29

Common causes, 21

Common feature, 289, 290

Common issues, 271, 273-277

Common sense, 49, 61n, 91, 164, 193, 245, 247

Communication, 160-174, 274

configuration control board (CCB), 161-164

customer, 162, 248, 276

documentation, 161

effective, 160, 161-164, 168, 247, 252, 275, 285, 289

proactive approach to, 161-162

e-mail, 167-172

ensuring, 161

fostering, 136, 247, 250

mechanisms, 162-164, 247-248

meetings, 165-167

negativism, 164-165

open, 36, 161

physical location, 174

vertical experts, 173

vocabulary, 172

Competitive business environment, 271, 276

Compliance, 107, 108, 119, 146, 147, 201

Components, 61n

architecture, 158

computer software (CSC), 259

framework, 147

legacy, 147

system, 68, 70, 109, 119, 121, 135n, 136, 144, 145, 146, 149, 152, 194, 253

Configuration control, 180, 183, 193

change control, 180, 193, 250, 283, 287

versions, 180, 250

Configuration control board (CCB), 161-164

characteristics of effective, 250-251

Configuration management, 250-251

formal, 174, 180, 193, 283

implementation of, 251

version control, 180, 250

Configuration management plan (CMP), 38n

Constraints

design, 17, 78, 133, 224

environmental, 109, 115, 136, 182

legal, 109, 115, 182

other, 182

Contingency/mitigation plans, 38n

Continuous improvement, xxv, 7, 12, 40, 55, 103, 103n, 107, 108, 124, 190, 232, 262, 267, 275, 276, 287

Contract, 225-226

Contractor. See Supplier

Contribution to society, 233

Cost As an Independent Variable (CAIV), 135, 156

Cost benefit analysis, 134, 225n

Costs, 60-62, 106, 118

defect prevention, 184

estimating, 51-52, 189-190

improvements, 276

overrun, 48

partnering, 32

peer reviews, 248

requirements creep, 107, 225-227

rework, 50-52, 79-81, 104-105

tracking, 49-50

Cost/schedule status reporting (C/SSR), 256

Cost Variance (CV), 256n

COTS software, 9, 153

Countermeasures, 164

Creep, requirements, 183, 218-229

cost, 107, 225-227

leakage, 221-224

rate of, 224-225

sources of, 219, 223

TCM, 219-220

volatility, 49-50, 220, 225

CS/10,000, 152n

Cubicles, 241

Customer, 14

communication, 162, 248, 276

development, 258-261

expectations, 152

experience of, 61, 162

involvement of, 31, 260

joint requirements planning (JRP), 198

negotiating with, 14, 134

partnering, 31-32, 41

prioritization, 193-194

real needs (requirements) of, 57-95

analyzing, prioritizing and tracking, 85-88

collecting from multiple viewpoints, 89-90

documentation of, 84

eliciting, 74-79

formal methods in developing software, 90

gold plating and, 74

project champion and, 63-64

project vision and scope, 64-65

requirements engineer and domain experts to address, 65-73, 79-84

requirements process and, 60-63

requirements creep, 228-229

requirements elicitation, 9-10

requirements review, 60, 61

requirements workshop, 60, 61

role of, 52-53

storyboard, 75

supplier's commitment, 28

valid requirements, 99

Database, 192

Database analysis, 208

Defect(s)

code, 183, 184

density, 295

design, 183, 184

document, 184

major, 249

minor, 249

performance, 184

requirements, 79-81, 104, 184, 185n

reuse and, 188-189

Defect prevention (DP), 78, 183-184, 234, 248-249, 261-262

Defense Advanced Research Projects Agency, 145n

Delta, 8

Department of Defense (DoD), 111n, 125-126, 128, 135n

Derive and allocate requirements, 110n, 111, 113, 117, 119-120, 121, 134, 144

Derived requirement, 145-146

Description, process, 101-102, 124

Design. See also Architecture

architecture-based design (ABD), 135

constraint, 17, 78, 133, 224

documentation, 145

Joint Application Design (JAD), 185, 225, 260

loop, 133

rationale, 145n

results, 145

solution, 145, 202

Designability, 10, 134-135

Developer, 74, 91, 194

Development, 277-278. See also Management

architecture, 147, 151

communication mechanisms, 247-248

customer involvement, 258-261

domain experts, 65, 72-73, 90-91, 244

effort, 3, 5, 9, 20, 231

environment, 243

guidelines, 286-287

peer reviews, 248-250

QA, 251-252

Rapid Application Development (RAD), 181

start-up checklist, 235-237

technologies, 246

training, 245

Development cycle

architecture, 151

in e-commerce environment, 13n

prototyping and, 185

system, 37

Development environment, 242, 243

Documentation, 7, 84, 182

communication, 161

design results, 145

process description (PD), 102-103

requirements creep, 227-228

requirements document, 107, 113

revision history, 193

Document defects, 184

Domain expert, 65, 72-73, 90-91, 244

DOORS, 15, 85, 86

Driver, requirements, 109, 276

Earned value analysis (EVA), 256

Earned value (EV) approach, 256-260

e-commerce, 13n, 61n, 152n

Electronics Industries Association (EIA), 110n, 126-127

Elicitation, requirements, 9-10, 74-79

E-mail, guidelines for effective, 167-172

Emoticons, 172n

Employee, indispensable, 178

Empowerment, 41, 233

of development team, 277, 278

from documented process, 103

by joint team, 46

by management, xxv

PCM and, 262

End products, 146, 243

Engineering groups, 15, 121, 165, 244, 247

Enterprise Process Improvement Collaboration (EPIC), 110, 127, 150n

Environment

development, 242, 243

maintenance, 242, 243

prototyping, 242

Environmental constraints, 109, 115, 136, 182

Error, requirements, 79-81, 104-105

defect prevention, 183-184, 261-262

peer reviews, 248-250

testing, 210

Estimated cost at completion (EAC), 256n

Estimation, software, 51-52, 189-190

Evolutionary cycle, 13n

Evolutionary delivery approach (EVO), 249n

Evolve System Architecture, 121, 150

Experience

of customers, 61, 162

industry, xxv, 14, 48, 58, 62, 104, 105, 105-107, 106, 122, 241, 277, 285, 291

Facilitator, 30, 60, 185, 284

Failure, project, 4-5

Fault tolerance, 243

Feasibility studies, 243

Financing improvements, 275-276

First-to-market, 218

Fixes, 213

Flowchart, process, 9, 99-101, 124

System Architecture (SA), 137-143

Formal configuration management, 250

Formal method, 90

Framework, architectural, 147

Functional document, 107, 113

Functional testing, 208

Functional view, 149

Function point analysis (FPA), 189-190, 226-227

Function points, 189-190, 227

cost per, for software produced in the U.S., 226

Function Point Workbench, 156n

Future releases, 193, 240

Getting to Yes (Roger & Ury), 54

Glossary, project, 172

Goal, 274, 285

Gold plating, 74

"Good" requirement, 82-84

Graphic, e-mail, 170-171

Guidelines

for "architecting," 151-153

for effective e-mailing, 167-172

for effective meetings, 165-167

for requirements traceability, 208-210

for system development, 39, 271, 285-289

Habits

of mature organizations, 262

of performers, 262

Hot swap, 61n

HTML message, 171

Human issues, xxiv, 160-161

Ilities, 78

designability, 10, 134-135

efficiency, 10, 68, 70, 175

human engineering, 10

modifiability, 10

portability, 10, 68, 70

reliability, 10, 68, 70, 148n

testability, 10

understandability, 10

Impact Estimation (IE), 249n

Impact study, 221n

Implementation, 135, 149

Improvement

continuous, xxv, 7, 12, 40, 55, 103, 103n, 107, 108, 124, 190, 232, 262, 267, 275, 276, 287

financing, 271, 275-276

ideas for, 113, 117, 277

process (PI), 13, 80, 90, 98, 104-5, 123, 126, 247, 253n, 262, 263-264, 289

product, 126

quality (QI), 99, 164, 236, 275

Incremental development approach, 224

Independent quality assurance (QA), 234, 251-252, 283

Independent requirements verification group, 213

Indispensable employee, 178

Industry experience, xxv, 14, 48, 58, 62, 104, 105, 105-107, 106, 122, 241, 277, 285, 291

Information Technology (IT), 144

Initial Operational Concept Definition, 113, 281

Inspections, 15, 60, 207, 234, 248-250

code, 183, 185n

design, 183, 185n

formal, 107, 183-185

Gilb, 249-250

Integrated product team (IPT), 47

Integration and Test (I&T), 161, 247

Interface requirement, 145

Interface testing, 208

International Council on Systems Engineering (INCOSE), 110n

International Function Point Users Group (IFPUG), 190, 197

International Standards Organization (ISO), 198

Interpersonal skills, 49, 165

Interrelationships, 144

ISO 9001, 198

Issue resolution ladder, 34

Iteration, 118, 132-154. See also Architecture

requirements loop, 133, 145

SA process, 136-146

System Engineering Process, 132-134

Joint Application Design (JAD), 185, 225, 260

Joint Requirements Planning (JRP), 198, 268

Joint team, 46-53

creation of, 48

frequency of meetings, 49

membership in, 48-49

as project CCB, 162

requirements creep, 221

team leader, 164

Jump-start kit, 124-125

Key practice, 289

Key process area (KPA), 160n, 219n, 253, 289

Key terms, 14-15

Last 10% of the work takes 90% of the time, 260

Leader, project, 164, 285

Leadership, 165, 238, 241

Leakage, requirements, 221-224

Legacy components, 147

applications, 156

systems, 192, 196, 244

Legal constraints, 109, 115, 182

Level

CMM, 11, 12, 90, 261

of the SW-CMM, 261, 262

Library, Web-based, 124

Life cycle, 11, 13

all-at-once, 126

customer and supplier roles throughout, 52-53

evolutionary, 13, 219

incremental, 219

spiral, 126

system, 11, 13, 47, 52, 53, 106-107

waterfall, 126

Lines of code (LOC) metric, 227

Litton PRC, 11, 110, 127, 259, 261

Locations, multiple, 174

Maintenance environment, 242, 243

Major defect, 249

Management, 235-244, 262-265, 277. See also Development

artifact evolution, 243-244

awareness, 271, 276

configuration, 250-251

metrics, 255-258

myths of, 239-240, 291-293

partnering workshop, 38

project manager, 62-63, 164, 232-233, 247, 263-264

quantitative, 277

risk resolution, 242-243

steps of, 238

subcontractors, 252-255

support, 5, 212, 252

verification, 212

Manifest, 64

Measurement

defect removal efficiency, 183

in earned value (EV) approach, 256n

Measure of effectiveness (MOE), 180

Mechanism, 15, 274-275

advantages, 40-41

communication, 162-164, 247-248

requirements creep, 221

Meetings, 165-167

guidelines for effective, 165-167

minutes, 113, 161, 166-167, 227

Method, 15, 180-182

advantages, 40-41

best, 183-184

formal, 90

verification, 207

Methodology, 15

Metric, 255-258, 277

lines of code (LOC), 227

seven core metrics, 257

Software Metrics Council, 267

Metrics programs, failure of, 256

Microsoft Enterprise Application Model, 46n

Middle out partitioning, 136

Milestone scheduling, 55

Mind-set for readers, recommended, 18

Minimum requirement, 192-193, 218

Minor defect, 249

Minutes of meetings, 113, 161, 166-167, 227

Modeling, 84, 181n, 245n

Monitoring and control methods, 238

Multidisciplinary team, 46n

Multiple locations, 174

Multivoting, 164

Mutual supportiveness, 160

National Defense Industrial Association (NDIA), 125-126

National Institute of Standards and Technology (NIST), 158

Negativism, 164-165

Negotiation

champion's role in, 64

with customer, 14, 134

open and explicit process of, 223

prioritization and, 209

requirements, 90

New business opportunities, 193, 218

Nonessential functionality, 193

Objective, 274, 285

Object-oriented (OO) paradigm, 78

Open architecture, 144

Open space, 241n

Open systems standard, 146-151

Operational Concept Definition (OCD), 65-72

Organizational working group, benefits of using, 123

Organization requirements policy, 118

Orientation training, 235

Overrun, cost, 48

Parable of the red beads, 24

Partitioning, 136

Partnering, 30-41

action planning worksheet, 35

benefits, 37

charter, 36

costs, 32

customer, 31-32, 41

issue resolution ladder, 34

joint team, 48

workshop, 30-34

Peer review, 248-250

formal, 250

purpose of, 249

types of, 248-249

People

acknowledging, 176

dimensions, 241

-related reasons for variability in software estimation, 214

"People aspects" of technical projects, 271

Performance, project, 288-289

Performance defects, 184

Performance testing, 208

Performers, 103, 251

project, 248, 277, 284, 285, 289

technical, 74, 245, 257

work habits of, 262

Personal Software Process (PSP), 55, 295

Personal traits, 178

Personnel issues, 68, 70, 267

Physical view, 149

Pitfalls

in defining real requirements, 90-91

of inflexible subject matter expert (SME), 73

of process approach, 12-14

of validation and verification, 211-213

Plan-Do-Check-Act (PDCA), 167

Plans, requirements, 38-39

Policy, requirements, 118-122

Practice, 15

PREview (Process and Requirements Engineering Viewpoints), 89-90

Primary features of this book, xxvi-xxvii

Prioritizing requirements, 10, 87-88, 118, 193-195

Private offices, 241n

Proactive approach

to communication, 161-162

to project management, 228

to sharing information, 107

to staffing changes, 227

to team development, 251

Probability of success indicator (PSI), 237

Problem solving, 30, 31

Process, 7-9, 15, 98-99, 275. See also Requirements process

approach, 11-14, 242-243

architecture, 118, 132, 134, 136-146

benefits of, 7, 103, 262

capability of, 236, 289n

conventional, 242-243

customer description in, 9

customer requirements for, 9, 99

customers of, 8-9, 98

departments involved in, 98-99

design of, 99-103

entrance criteria to, 9, 101

exit criteria for, 9, 101

high-level, 8, 98

identification (Id), 9, 100

indicators of, 9, 102

inputs to, 9, 101

lower-level, 8, 98-99

macro, 8, 98

micro, 8, 98-99

modern, 242-243

name of, 100

outputs from, 9, 101

persons involved in, 100

purpose, 9

quality indicators of, 9, 102

related, 9

repeatable, 102, 103

resources required for, 9

responsibilities of participants, 9, 101

reuse, 102

risk-confronting, 242

sub, 8, 98-99

tasks performed in, 9

templates used for, 100, 101-102

up-front, 108, 109

version number of, 9

Process Advisor, 276

Process approach, 11-14, 242-243

benefits of, 7, 11-12, 162

pitfalls of, 12-14

Process area (PA), 101, 110, 111, 119, 121

key (KPA), 160n, 219n, 253, 289

Process change management (PCM), 234, 261-262

Process description, 9, 99, 101-102

Process flowchart, 9, 99-101, 124

Process improvement (PI), 13, 80, 90, 98, 104-5, 123, 126, 247, 253n, 262, 263-264, 289

Process management, 164

Product

benefits, 224

development, 46n, 79, 162

features, 224

Product improvement, 126

Productivity, software development, 186-189

Product line, 135

Product manager, 14, 46n

Program Architecture Team, 136-144

Project champion, 59, 63-64

Project charter, 33, 36, 64

Project management, ten steps of, 237-241

Project Management Institute (PMI), 305

Project Management Plan (PMP), 236, 288

Project manager (PM), 62-63, 247. See also Management

budget and, 63

communication and coordination fostered by, 160, 161

informal sessions with, 247

quantitative management by, 261

requirements practices savings and, 80

requirements process and, 59, 62-63

responsibilities of, 232-233, 263-264

delegation of, 164

Project performers, 248, 277, 284, 285, 289

Project plan, 38n

Proposed system, 71

Prototype, 183-185, 243

disposable, 183

working, 183

Prototyping environment, 242

Quality assurance plan (QAP), 38n

Quality assurance (QA), 251-252

Quality culture, 40-41, 108

Quality Function Deployment (QFD), 190-191

Quality improvement (QI), 99, 164, 236, 275

ethic, 275

story, 177, 277n

techniques, 164, 177-78

tools, 277n, 175, 178

Quality in Daily Work (QIDW), 99

Rapid Application Development (RAD), 181n

Rational Corporation, 244n

Rational Unified Process (RUP), 245n

Rayleigh distribution, 268

Real requirements, 6, 13, 15, 58-91, 275

champion, 59, 63-64

developers, 74, 91

documentation, 84

emergent, 180, 192

formal methods, 90

and "good" requirements, 82-84

operational concept definition (OCD), 65-72

PREview, 89-90

prioritizing, 87-88

project manager, 62-63

QFD, 191

requirements engineer, 65, 72-73, 90-91, 107-110

requirements review, 60

and stated requirements, 60-61

up-front process, 109

use cases, 75-78

vision and scope, 64-65, 73

V&V, 202-203

Recruiting, 72, 233, 235

Relationships

initiating, 176

negotiating, 176

partnership, 47, 106, 111, 225, 274, 275

sustaining, 176

RE Macro/RE000, 110-117

Assess New/Changed Requirements, 113-114

Derive and Allocate Requirements, 116-117, 134, 144

macro flowchart, 112-113

Understand Customer Needs, 113-117, 134

Repeatability, 7, 12, 266

Request for Change (RFC), 306

Request for Information (RFI), 182

Request for Proposals (RFP), 61, 182

Request for Quote (RFQ), 182

Requirements engineer, 65

domain expert as, 72-73, 90-91

goals of, 107-110

Requirements Plan (RP), 38-40

Requirements policy, 118-122

Requirements process, 9-14

activities of, 9-11

allocated/derived requirements, 145-146

baseline, 144-145, 212

benefits, 11-12

defined, 9, 15

flowchart, 99-101

IPT, 47

life cycle, 11, 13

pitfalls, 12-14

process description (PD), 101-102

stated requirements, 6, 8, 13, 15, 60-61

taxonomy, 16-17

valid requirements, 8, 99

Requirements tools

automated test, 183, 214

C.A.R.E. 2.0, 86

Caliber RM, 86

CASE, 181, 187, 188

CORE, 84n, 86, 181n

defect tracking, 183, 184

DOORS, 15, 85, 86

inadequate, 188, 218

Measures of Effectiveness (MOE), 180

quality estimating, 187

RDD ISEE, 86

Requirements Traceability Matrix (RTM), 113, 120, 144, 203, 282

Requisite Pro (ReqPro), 15, 86

RTM Workshop, 86

rules of conduct, 181

SLATE, 86

SynergyRM, 86

Vital Link, 86

Xtie-RT Requirements Tracer, 86

Requirements volatility, 49-50, 53, 195, 220, 225, 256, 289

Requirements working group (RWG), 110-111

Requirements workshop, 165, 224n, 260, 284, 285

Return on investment (ROI), 50, 52

Reuse, 7, 153

defects, 186, 189

defects and, 188-189

documentation, 102-103

standards, 147

tailoring, 123-124

Revision history, 193

Rework cost, 50-52, 79-81, 104-105

Risk, 43, 242-243, 265

barriers to success, 279

identification of, 279

mitigation plan, 279

Risk management plan (RMP), 38n

Rocks in the road, 42

Role, 14, 52-53

of customer, 14, 52-53

of product or project champion, 63-64

of project manager, 14, 285n

of stakeholder, 14

of user, 14

Root cause analysis, 164

Rules of conduct, 41, 285

Rules of engagement, 64-65

Scalabibility, 147, 156n

Scenario, 77

Schedule, 3, 5, 7, 32, 147

adjustment of, 46, 50, 220

conventional problems affecting, 242-243

delays in, 120

delivery, 135

gold plating and, 74

joint team and, 47

milestone scheduling, 55, 262

overrun, 233

priority-based, 195

project failure due to, 189n

requirements changes and, 221

Schedule Variance (SV), 256n

Script, 213

Services

data interchange, 148

data management, 148

distributed computing, 148

User interface, 148

Seven deadly diseases, 21, 24

Shrink-wrapped software, 46n, 181n

Silver bullet, 181n, 235-236, 237

Simulation, 117, 149n, 181, 207, 208

Six Sigma Qualtec, 164n, 177

"Small project," 58

Software

costs, 22, 50n

custom, 181n

estimation, 189-190

problematic, 181n

shrink-wrap, 46n, 181n

systems, 181n, 186

Software Capability Maturity Model (SW-CMM), 110-111, 126, 219n. See also Capability Maturity Model (CMM)

Software development plan, 38n

Software engineer, 17

Software Engineering Institute (SEI), 110, 126, 135

Software industry, 3-6

Software Metrics Council, 267

Software Productivity Research (SPR), 182

Software Project Survival Guide (McConnell), 240-241

Software Project Survival Test, 240

Software verification and validation plan, 38n

Special causes, 24

Specification, requirements, 10, 192-193

A spec, 291

B spec, 211

C spec, 311

Stable system, 24

Stakeholder, 10, 14

Standard, open systems, 146-151

Standish Group, 4, 103

Start-up checklist, 235-237

Stated requirement, 6, 13, 15

costs, 60-61

and valid requirements, 8

Statement of Work (SOW), 61, 182, 208, 254

Stress testing, 208

Structured analysis, 22

Structured approach, 202, 210

Structured decomposition, 22

Subcontract management, 234, 252-255

goals of, 254

purpose of, 253

top-level activities of, 254-255

Subcontractor (sub), 252-255

communication with, 160, 161-162

crippled, 252

effective use of, 252-255

performance of, 253-254

workshop participation by, 32

Subject matter expert (SME), 65, 72-73, 90-91, 244

Subprocess, 8

Supplier, 28-29, 52-53, 276

Supportive environment, 232, 233

Supportiveness, mutual, 160

System architecture, 7, 121, 132, 163, 209

System architecture (SA) process, 112, 116, 118, 132, 136-146. See also Architecture

System components, 68, 70, 109, 119, 121, 135n, 136, 144, 145, 146, 149, 152, 194, 253

System concept documents, 117, 203

System cost estimates, 117

System-defined attribute, 85-86

System development, 37

foundation for, 180

guidelines for, 39, 285-287

life cycle cost of, 84

partitioning approach to, 136

real requirements and, 67, 80

System Development Life Cycle (SDLC), 307

System engineer, 17

System engineering, 10, 110, 111n

System engineering management plan (SEMP), 38n

System engineering process (SEP), 38, 132-134

System level requirements, 134, 146, 192, 196

System life cycle, 11, 13, 47, 52, 53, 106-107

System objectives, 47, 52

System requirement, 10

Systems Engineering Capability Maturity Model (SE-CMM), 63n, 110-111, 126-127, 150. See also Capability Maturity Model (CMM)

System version, 47, 50n, 92

Tailoring, 123-124

Taxonomy, requirements, 16-17

Team building, 165, 284

Team leader, 164, 165

Team Software Process (TSP), 55

Teamwork, 284-285. See also Joint team

communication and, 247, 248

orientation training to foster, 235

in partnering workshop, 34

in quality culture, 40

Technical performers, 74, 245, 257

Technical Reference Model (TRM), 144, 147-148

Technique, 15, 180-182

advantages, 40-41

V&V, 208

Technology Change Management (TCM), 219-220, 261

Technology insertion, 261

Technology reinsertion, 234, 261, 266

Template, process flowchart, 99-101

Test cases, 77, 78, 210, 240-241

Testing, 78, 210

Test procedures, 215, 259

Test process, 215

Test team, 212

Test techniques, 215

Test tools, 215

Risk Matrix, 215

Walk-Through, 215

The Open Group's Architectural Framework (TOGAF), 144, 149-151, 158

Theory of Constraints, 266

Theory W, 92

Timeline, 51

TOGAF, 144, 149-151, 158

Tool, 15, 40-41. See also Automated requirements tools

Top-down partitioning, 136

Total Quality Management (TQM), 40, 276

Traceability, 85n, 144, 208-210

Tracking, 49-50

Tracking requirements, 13, 15, 60, 85-88

Trade-offs, 88, 135, 243

fault tolerance/dynamic reconfiguration, 243

make/buy, 243

performance, 243

Trades, architecture, 149n

Trade study, 84, 135

Training, 245

Turnover, 277

Unessential function, 218

Unified Modeling Language (UML), 75

U.S. Department of Defense (DoD), 111n, 135n, 256

U.S. Navy Radar Warning System, 259

Unofficial requirement, 221-224

Unprecedented Solutions, 153

Untestable requirements, 210

Unverifiable requirements, 203-206

Up-front process, 108-109

Usability analysis, 117

Use case, 75-78, 186, 225n

User, 14

communication with, 24

education of, 46n

involvement of, 4, 6, 7-8, 24, 31

User-defined attribute, 85

User-friendly requirement, 204, 206, 212

Vague requirements, 210

Validation, 202-203

Valid requirements, 8, 9, 98, 99, 102, 111, 113, 120

Verification, 133, 202-213

defined, 202

group, 213

matrix, 211

methods and techniques, 207-208

outputs, 203

planning checklist, 207

testing, 210

traceability to support, 208-210

verifiable/unverifiable requirements, 204-206

Verification and validation (V&V), 202-207

importance of, 203

planning, 203-207

techniques of, 208

terminology of, 202-203

Version control, 250

Vertical expert, 173

View, architectural, 148-149

Vision and scope document, 64-65, 73

Vision of this book, xxiii

Vocabulary, common, 172

Volatility, requirements, 49-50, 53, 195, 220, 225, 256, 289. See also Creep, requirements

Walkthroughs, 208

Web-based library, 124

What's all the fuss?, 233-234

WinWin Spiral Model, 88

Workbench, 156n

Working group, 122-123

Workshops requirements, 165, 224n, 260, 284, 285

Zachman Framework, 155

Author Index

Adams, James L., 154

Adhikari, Richard, 78n

Allen, Karl, 110n

Andriole, Stephen J., 325

Bach, James, 43, 213n

Bachmann, Felix, 135n, 154

Bailey, Michelle, 94

Bass, Len, 118n, 154

Bennis, Warren, 54

Bentley, Lonnie D., 199

Bicknell, Barbara A. and Kris D., 190, 196

Biederman, Patricia Ward, 54

Boehm, Barry W., 20, 80, 88, 92, 214

Booch, Grady, 4n

Bough, Bennie, 175

Brassard, Michael, 164n, 175, 277n

Brennan, Leo, 33

Brodman, Judith G., 58n

Brooks, Frederick P., Jr., 235n, 294

Brown, Scott, 176

Bruggere, T., 326

Buede, Dennis M., 21, 181n

Bush, Marilyn, 229

Buzan, Tony, 326

Carr, Frank, 40n, 42

Carr, Marvin J., 327

Carriere, S. Jeromy, 156

Caswell, D., 256n, 267

Chastek, Gary, 154

Chrissis, Mary Beth, 23, 229

Christerson, Magnus, 333

Clark, Ralph, 267

Clements, Paul, 154

Condrill, Jo, 175

Connell, John L, 327

Constantine, Larry, 175

Covey, Steven, 95

Cox, Charles, 199

Cox, Jeff, 266

Curtis, Bill, 5, 23

Cusumano, Michael, 42

Davis, Alan M., 5n, 40n, 294

DeGrace, Peter, 126

DeMarco, Tom, 54, 241n

Deming, W. Edwards, 21, 24, 167, 299

Dittman, Kevin C., 199

Donohoe, Patrick, 154

Dorfman, Merlin, 214, 215, 298

Doyle, Michael, 176

Dreon, Barb, 167n, 328

Dustin, Elfriede, 213n, 214

Egyed, Alexander, 92

Ensey, Nancy, 328

Farry, Kristin A., 22, 48, 79, 145n, 193-194, 203

Ferguson, Pat, 295

Fisher, Roger, 54, 176

Fowler, Jim, 328

Fowler, Priscilla, 328

Frame, J. Davidson, 127

Frank, Milo O., 176

Freedman, Daniel P., 92, 249n

Gaffney, Steven, 165n, 176

Garcia, Suzanne M., 229

Gause, Donald C., 21, 40n, 74n, 80n, 92

Geiger, Jonathan G., 155

Gibbs, W. Wayt, 4n

Gilb, Tom, 21, 93, 249-250

Glass, Robert, 4n

Goguen, Joseph A., 61n, 180n

Goldratt, Eliyahu M., 266

Grady, Jeffery O., 16, 22, 82, 202, 204, 207n, 214

Grady, Robert, 256, 266-267

Graham, Dorothy, 93, 249n

Graham, Ian, 196

Griss, Martin, 155

Gruehl, Werner M., 62

Guenterberg, S., 323

Guiney, Eamonn, 77n, 245n

Hadden, Rita, 58n, 93

Hammer, Theodore F., 214

Handy, Charles, 177

Harwell, Richard, 15n, 30n, 42-43

Hatley, Derek, 155

Hayes, Jack, 321

Heen, Sheila, 178

Hefley, William E., 327

Henderson, Lisa G. R., 331

Herbsleb, James, 331

Highsmith, James A., III, 294

Hodgson, Bart, 343

Hofmeister, Christine, 155

Hohmann, Luke, 54

Hollenbach, Craig, 167n

Hooks, Ivy F., 22, 48, 60, 62, 79, 84n, 93, 104, 145n, 165n, 193-194, 203

Hoovler, Earl, 167n

Hruschka, Peter, 155

Huffman, Leonore L., 214

Humphrey, Watts S., 55, 177, 275, 295

Hurtado, Kim, 42

In, H., 43n

Inmon, W. H., 155

Ippolito, Laura M., 208, 215

Iscoe, N., 5n

Jackson, Michael, 197

Jackson, Sheila, 110n

Jacobson, Ivar, 155, 245n

Jirotka, Marina, 61n

Johnson, Donna L., 58n

Jones, Capers, 4n, 6, 22, 43, 50n, 78, 182-186, 190, 197-198, 218, 224, 225n, 267

Jonsson, Patrick, 155

Jordan, Kathleen, 327

Kalakota, Ravi, 296

Kaminski, Paul, 156

Kaplan, Craig, 75n, 267

Kar, Pradip, 94

Karlsson, Joachim, 87-88, 94

Karten, Naomi, 43

Kazman, Rick, 154, 156

Keegan, Jr., James G., 336

Kelliher, Timothy P., 336

Khajenoori, Soheil, 328

Kleiner, Art, 297

Konda, Suresh L., 327

Korson, Timothy, 77n

Krasner, Herb, 5n

Kroeger, Otto, 177

Kulak, Daryl, 77n, 245n

Kwan, Julie, 92

Lancaster, Charles, 42

Leffingwell, Dean, 23, 50, 55, 63, 65, 74, 77-79, 193n, 208

Linde, Charlotte, 330

Lister, Timothy, 54, 241n

Lubars, Mike, 181n, 296

McConnell, Steve, 5, 7n, 40n, 63, 75, 118n, 128, 177, 181, 233, 240-241, 267, 297

Macke, Susan, 328

Madachy, Ray, 92

Maguire, Steven A., 335

Maier, Mark W., 157

Marchegiani, Dan, 258, 324

Markert, Charles, 33-34, 39, 42, 43

Martin, James, 181n, 198

Martin, James N., 23, 42, 211n

Matvya, Annette, 328

May, Elaine L., 249n

Meadow, Andy, 336

Mengot, Roy, 331

Merrin, Barbara, 328

Miller, Hal, 245n

Miller, Sally, 327

Monarch, Ira, 327

Moore, John, 324

Moran, John W., 199

Myers, Ware, 268

Nasr, Eman, 77

Noah, Matt, 343

Nord, Robert, 155

O'Connell, Fergus, 235-240, 268, 285n, 297

Oliver, David W., 84

Orr, Ken, 294

Overgaard, Gunner, 333

Overmyer, Scott, 327

Palmer, James D., 85n, 214

Patrick, Mac, 328

Patton, Bruce, 178

Paul, John, 214

Paulk, Mark C., 23, 55, 58n, 110n, 160n, 190-191, 198, 219n, 229, 241n, 253n, 262n, 289n

Perry, William, 210, 215

Peruzzi, Fabio, 154

Petroski, Henry, 106n, 157

Petrozzo, Daniel P., 219, 229

Pflugrad, Al, 38n

Pirbhai, Imtiaz, 155

Pomata, Len, 261n

Port, Dan, 92

Poston, Robert M., 78

Potts, Colin, 296

Pressman, Roger S., 56

Ptack, Ken, 331

Putlock, Gary, 339

Putnam, Lawrence H., 268

Ramaswami, K. V., 190

Raphael, Rich, 337

Rashka, Jeff, 214

Reaves, John M., 134

Rechtin, Eberhardt, 153, 157

Reinertsen, Donald G., 190, 224, 230

Revelle, Jack B., 191n, 199

Richter, Charles, 296

Ritter, Diane, 164n, 175, 277n

Roberts, Charlotte, 297

Robertson, James and Suzanne, 128

Robinson, Marcia, 296

Roetzheim, William, 189n

Rosenberg, Linda, 199, 214

Ross, Richard, 297

Roth, George, 297

Royce, Walker, 124n, 241-242, 245, 256, 268

Rumbaugh, James, 75

Rutherford, Bette, 167n

Ryan, Kevin, 87-88, 94

Sabourin, Rob, 60n, 73n, 93, 118, 173, 186, 250n

Satir, Virginia, 95

Sawyer, Pete, 23, 74n, 89, 94

Schneider, Geri, 75, 94

Selby, Richard, 42

Senge, Peter, 297

Shafer, Linda, 75n

Shah, Archita, 92

Silver, Denise, 342

Smith, Bryan, 297

Smith, Doug, 156n, 167n

Smith, Preston G., 190, 224, 230

Sommerville, Ian, 23, 74n, 89, 90n, 94, 230

Soni, Dilip, 155

Stahl, Leslie Hulet, 126

Stapleton, J., 197

Starbuck, Ronald, 230

Stevens, Richard, 339

Stone, Douglas, 178

Strassmann, Paul A., 297

Straus, David, 176

Sullivan, Kevin J., 20

Tang, Victor, 267

Terninko, John, 191n, 199

Thayer, Mildred C., 340

Thayer, R. H., 214, 215, 298

Thomsett, Bob, 268

Thuesen, Janet M., 177

Tucker, Paul, 42

Ulrich, F. Carol, 327

Ury, William, 54

Vienneau, Robert, 90

Viller, S., 94

Vischer, Jacqueline, 241n

Walker, Clay F., 327

Wallace, Delores R., 208, 215

Walton, Mary, 24

Waters, John, 211n

Waugh, Penny, 167n

Weber, Charles V., 23, 229

Webster, Bruce F., 245n, 269

Weinberg, Gerald M., 21, 40n, 43, 74n, 75, 80n, 92, 95, 129, 178, 192n, 221, 224, 230, 249n, 298

Weller, Ed, 269

Whitten, Jeffrey L., 199-200

Whitten, Neal, 178, 192, 200, 218, 269

Widrig, Don, 23, 63, 65, 74, 77, 193n, 208

Wiegers, Karl E., 43-44, 59, 65, 75, 77, 87, 95, 298

Wieringa, R. J., 342

Wiley, Bill, 24, 136, 181n, 190n, 248n, 286

Williams, Louise, 58n

Winters, Jason P., 75, 94

Wood, Jane, 342

Young, Ralph, 329, 331, 343

Yourdon, Ed, 40n

Zachman, John A., 155, 200

Zimmer, Barbara A., 249n

Zultner, Richard, 125n, 190-191, 262



Updates

Submit Errata

