Available:*
Library | Item Barcode | Call Number | Material Type | Item Category 1 | Status |
|---|---|---|---|---|---|
Searching... | 30000004455147 | TS170 H66 2000 | Open Access Book | Book | Searching... |
Searching... | 30000004571323 | TS170 H66 2001 | Open Access Book | Book | Searching... |
Searching... | 30000004455188 | TS170 H66 2000 | Open Access Book | Book | Searching... |
On Order
Summary
Summary
"Never time enough to do it right, but always time enough to do it over."" In today's ""faster-better-cheaper-at-any-cost"" world, this is not just a joke, but an all-too-frequent reality. And, most often, a poor understanding of the requirements for a product is the reason it must be done over. Customer-Centered Products is a highly practical new book that helps readers gain a clear understanding of how to elicit the right requirements early on in a project - and make the right product the first time. Packed with useful information, enlightening real-life examples, and money-saving solutions, this book shows readers how to: * Identify where their current requirements process is weak * Bridge communication breakdowns that lead to muddy requirements * Eliminate costly mistakes and rework * Improve product quality without increasing cost * Use operational concepts to improve requirements quality * Improve the fit between the product and the customers' needs * Prove that faster, better, cheaper is possible, and more." "
Author Notes
"Ivy F. Hooks (Fair Oaks Ranch, TX) is president and CEO of Compliance Automation, Inc. She has provided training and consulting in requirements for a variety of corporations and government organizations, including Kodak and NASA.
Kristin A. Farry (Friendswood, TX) is an engineer with over two decades' experience in aerospace, robotics, and biomedical engineering."
Reviews 1
Choice Review
Hooks and Farry draw on their professional experiences in government and industry in this book on managing project requirements to ensure successful product development. Their intent is to guide managers on how to focus on improving the requirement process. The authors argue that an investment in better requirement definition combined with an organizational culture emphasizing the importance of requirements management may be the keystone of competitive advantage. The book's 17 chapters cleverly integrate contemporary management theory and requirements engineering into a nine-step requirement model. An informal writing style combined with humor and a series of interesting case studies from well-known companies bring insight into the ways in which today's leaders are adapting requirements management as an intrinsic component of an organization's strategic planning. Practical experience with managerial planning and control is necessary to maximize the volume's usefulness. Practitioner collections. S. R. Kahn; University of Cincinnati
Table of Contents
| List of Figures | p. xiii |
| List of Tables | p. xv |
| Foreword | p. xix |
| Preface | p. xxiii |
| Acknowledgments | p. xxv |
| Introduction: Managers and Requirements | p. xxvii |
| Chapter 1 Requirements: Structure for Success | p. 1 |
| Chapter 2 Why Johnny Can't Write Requirements: Cultural, Educational, and Management Influences of Requirement Definition | p. 15 |
| American Culture | p. 16 |
| Samples from Other Cultures | p. 20 |
| Corporate Requirement Management Myths | p. 21 |
| The Individual | p. 25 |
| What Is the Solution? | p. 29 |
| Chapter 3 The View from the Top: Steps to Creating and Managing Good Requirements | p. 32 |
| Why Adopt a Process? | p. 33 |
| Requirements for a Requirement Definition Process | p. 35 |
| What Process? | p. 37 |
| What Is the Manager's Role? | p. 41 |
| Just the Beginning | p. 42 |
| Chapter 4 Creating a Shared Vision: Scoping the Project Up Front | p. 43 |
| Why Scope? | p. 44 |
| What Is Scope? | p. 45 |
| How Do You Communicate Scope? | p. 54 |
| How Much Effort Should You Invest in Defining Scope? | p. 55 |
| What is the Manager's Role in Scope Definition? | p. 55 |
| Scoping Success | p. 56 |
| Chapter 5 One Day in the Life of A Product: Using Operational Concepts to Improve Requirement Quality | p. 59 |
| Why Should You Develop Operational Concepts? | p. 61 |
| How Do You Develop Operational Concepts? | p. 64 |
| Beyond Basic Usage | p. 68 |
| The Abnormal | p. 74 |
| Human Interface Detail | p. 77 |
| Assessing Completeness | p. 78 |
| Early Validation Opportunities | p. 79 |
| What Is the Manager's Role in Operational Concepts? | p. 81 |
| Operational Concepts Have High Return on Investment | p. 82 |
| Chapter 6 Collision Course: Identifying and Managing Interfaces | p. 83 |
| Why Define External Interfaces So Soon? | p. 84 |
| How Do You Identify Interfaces Early? | p. 85 |
| The External Interfaces | p. 86 |
| The Internal Interfaces | p. 96 |
| Document, Document! | p. 97 |
| What Is the Manager's Role with Interfaces? | p. 98 |
| Ignoring Interface Issues Makes Them Bigger | p. 99 |
| Chapter 7 Be Careful What You Ask For: Writing Good Requirements | p. 101 |
| Why Are Individual Requirements So Important? | p. 102 |
| How Do You Recognize the Good? | p. 103 |
| The Bad and the Ugly | p. 107 |
| What Is the Manager's Role in Writing Requirements? | p. 117 |
| A Review Mindset | p. 118 |
| Chapter 8 Theirs But to Reason Why: The Value of Recording Rationale | p. 120 |
| Why Record Rationale? | p. 121 |
| What Should Rationale Include? | p. 127 |
| How and When Should You Capture Rationale? | p. 129 |
| What Is the Manager's Role in Rationale? | p. 131 |
| The Rationale for Rationale | p. 132 |
| Chapter 9 Everything in Its Place: Levels, Allocating, and Tracing Requirements | p. 134 |
| What Are Requirement Levels? | p. 135 |
| Why Is Writing Requirements to Levels Important? | p. 135 |
| What Is Allocation? | p. 140 |
| Why a Top-Down Requirement Allocation? | p. 140 |
| What Is Traceability? | p. 141 |
| Why Start Tracing Requirements Now? | p. 141 |
| How Do You Get Every Requirement in the Right Place at the Right Time? | p. 145 |
| What Is the Manager's Role in Levels, Allocation, and Traceability? | p. 155 |
| Wrapping Up with Neat Packages | p. 156 |
| Chapter 10 But Will It Work? Thinking Ahead to Verification | p. 157 |
| Why Look at Verification during Requirement Definition? | p. 158 |
| How Do You Address Verification during Requirement Definition? | p. 160 |
| What Is the Manager's Role in Assessing Verification? | p. 168 |
| Verifying Your Assessment | p. 168 |
| Chapter 11 A Needle in a Haystack: Formatting Requirements | p. 171 |
| What's Wrong with Just a List of Requirements? | p. 171 |
| What Are the Requirements for a Requirement Format? | p. 174 |
| How Do You Tailor? | p. 178 |
| What Is the Manager's Role in Formatting Requirements? | p. 180 |
| Maintaining Perspective among the Piles of Paper | p. 181 |
| Chapter 12 Drawing a Line in the Sand: Preparing to Baseline Requirements | p. 183 |
| What's the Big Deal about a Baseline? | p. 183 |
| Drawing the Line | p. 185 |
| All at Once or Step-by-Step? | p. 198 |
| What Is the Manager's Role in Baselining? | p. 199 |
| The Bottom Line on Drawing the Line | p. 200 |
| Chapter 13 Not All Requirements Are Created Equal: The Case for Prioritizing Requirements | p. 202 |
| The Case for Early Prioritization | p. 203 |
| Selling the Concept of Prioritizing Requirements | p. 204 |
| How Do You Prioritize Requirements? | p. 207 |
| What Is the Manager's Role in Prioritizing Requirements? | p. 210 |
| The Bottom Line on Prioritizing Requirements | p. 210 |
| Chapter 14 Keeping Sane: Automating Requirement Management | p. 212 |
| Why Automate? | p. 213 |
| How Do You Automate? | p. 216 |
| What Is the Manager's Role in Automating Requirement Management? | p. 224 |
| No Magic Here | p. 224 |
| Chapter 15 Death, Taxes, and Requirement Change: Managing Change | p. 226 |
| Why Formal Change Control? | p. 227 |
| How Do You Control Change? | p. 228 |
| What Is the Manager's Role in Change Management? | p. 231 |
| A Balancing Act | p. 233 |
| Chapter 16 Cap'n, Are We There Yet? Measuring Requirement Quality | p. 235 |
| Why Measure Requirement Quality? | p. 236 |
| Using Common Data for Quality Measurement | p. 237 |
| The Fifth Amendment Syndrome | p. 243 |
| What Is the Manager's Role in Measuring Requirement Quality? | p. 244 |
| Measurement Is the Foundation of Improvement | p. 245 |
| Chapter 17 It Can Happen on Your Watch: Making Changes in an Organization's Requirement Definition Process | p. 246 |
| The Process | p. 248 |
| The Culture | p. 250 |
| The Pitfalls | p. 254 |
| The Price | p. 259 |
| Endnotes | p. 261 |
| About the Authors | p. 267 |
| Index | p. 269 |
