Home > Store > Programming > General Programming/Other Languages

Effective Requirements Practices

Register your product to gain access to bonus material or receive a coupon.

Effective Requirements Practices

Book

  • Your Price: $35.99
  • List Price: $44.99
  • Usually ships in 24 hours.

Description

  • Copyright 2001
  • Dimensions: 7-3/8x9-1/4
  • Pages: 400
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-70912-0
  • ISBN-13: 978-0-201-70912-4

"Ralph Young has written an excellent guide for those who must understand and manage their customer's requirements. And that means just about everyone in the systems and software world." --Roger Pressman

Requirements analysis and management is finally receiving the attention it deserves as a key factor in the success of systems and software development projects.

And with this new attention comes a pragmatic guide to proven industry practices for emerging and fulfilling customer requirements. More than just an idealized view of the topic, Effective Requirements Practices addresses both managerial and technical issues that determine the success--or failure--of a project. The requirements practices described in this book enable you to redirect resources to satisfy customers' real business needs. Together, these practices provide a proven framework and process that help keep projects on the right track and ensure that requirements are addressed properly throughout a project's life cycle.

This book demonstrates proven methods and techniques. Topics covered include

  • Strategies and methods for getting to the "real" customer requirements
  • Developing and improving a requirements process
  • The roles and responsibilities of the Joint Team for requirements elicitation
  • Designing system requirements with the system architecture in mind
  • Maintaining effective communication among team members
  • Maintaining a set of work products
  • Requirements verification and validation
  • Accommodating changes in requirements throughout the project
  • How the recommended requirements practices utilize the Capability Maturity Model (CMM) framework
  • Achieving an environment of continuous improvement and mutual support of one another

Also provided is a sample process that has been used in industry and deployed and tailored on dozens of projects. In addition, Effective Requirements Practices offers you recommendations for incorporating industry best practices into the development effort.

You will come away from this book well equipped to better satisfy your customers' needs.



0201709120B06012001

Downloads

CD Contents

Download the CD Contents related to this title.

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

More Information

Unlimited one-month access with your purchase
Free Safari Membership