The Requirements Engineering Handbook For a listing of recent titles in the Artech House Technology Management and Professional Development Library, turn to the back of this book. The Requirements Engineering Handbook Ralph R. Young Artech House Boston • London www.artechhouse.com Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the U.S. Library of Congress. British Library Cataloguing in Publication Data A catalog record for this book is available from the British Library. Cover design by Igor Valdman © 2004 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 The following are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University: Capability Maturity Model, CMM, and CMMI. All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 1-58053-266-7 A Library of Congress Catalog Card number is available from the Library of Congress. 10987654321 For you Let’s improve requirements engineering! . Contents Foreword ..............xi Preface...............xv Acknowledgments ...........xix 1 The Importance of Requirements .......1 What Are Requirements and Why Are They Important? 1 Why Plan? 3 A Suggested Strategy 3 Requirements Activities in the System Life Cycle 3 Investment in the Requirements Process 5 A Process Approach 6 The Requirements Plan 7 Factors Affecting Your Career Decisions 10 A Comment Concerning Small Projects 11 Summary 11 Case Study 12 References 13 2 The Roles of the RA ...........15 Suggested Roles of the RA 15 Summary 23 Case Study 24 References 25 vii viii Contents 3 Skills and Characteristics of an Effective RA ...27 Skills of the RA 27 Characteristics of an Effective RA 34 Summary 42 Case Study 43 References 44 4 Types of Requirements..........45 Views of Requirements Types 45 Definitions and Descriptions of Requirements Types 48 Business Requirements 49 Stated Requirements Versus Real Requirements 50 User Requirements 50 High-Level or System-Level Requirements 50 Business Rules 50 Functional Requirements 51 Nonfunctional Requirements 52 Derived Requirements 52 Design Requirements and Design Constraints 52 Performance Requirements 53 Interface Requirements 53 Verified Requirements 53 Validated Requirements 53 Qualification Requirements 53 The “Ilities” and Specialty Engineering Requirements 53 Unknowable Requirements 54 Product Requirements 54 Process Requirements 54 Logistics Support Requirements 54 Environmental Requirements 55 System, Subsystem, and Component Requirements 55 Terminologies to Avoid 55 Source or Customer Requirements 55 Nonnegotiable Versus Negotiable Requirements 55 Key Requirements 56 Originating Requirements 56 Other Guidelines 56 Examples of Requirements Types 56 Summary 57 Case Study 57 References 60 Contents ix 5 Gathering Requirements .........61 Plan the Approach 62 Summary 104 Case Study 104 References 105 6 Best Practices for Requirements Development and Management ...........109 Summary 123 Case Study 123 References 126 7 The RA’s Specialty Skills .........127 Summary 159 Case Study 163 References 164 8 An Integrated Quality Approach ......169 Business Drivers for Quality 170 Management’s Role 170 Guiding Principles 171 Priority Management 172 The Components of an Integrated Quality Approach 172 Quality Improvement Techniques 173 The PDCA Cycle 179 How to Design a Process 180 Teamwork 187 Summary 189 Case Study: An Example of Quality Improvement Sidetracked 189 References 191 9 A Vision for Requirements Engineering ....193 How Should We Support PMs? 197 How Should We Support Customers? 198 How Should We Support Developers? 198 Summary 199 Case Study 200 References 202 x Contents 10 Moving Forward: Knowable Requirements, Manageable Risk ...........205 Where to Go from Here 207 Moving Forward 209 A Requirements Mandala 212 Summary 213 Case Study 213 References 215 Glossary ..............217 List of Acronyms ...........227 Bibliography ............233 About the Author ...........243 Index ...............245 Foreword ome years ago, a successful company won a contract for a fifty million Sdollar project. The product system had six operator consoles, another six racks of electronics equipment, and a sophisticated set of remote radios and computers. Development disciplines included software engineering, digital electronics, communications electronics, and mechanical engineering. Customer acquisition and user groups knew what operational capability they wanted, but there had yet been no technical requirements. Early in the project, the company developed and delivered a technical specification. Customer reviewers provided dozens of changes, including six additional requirements that they interpreted from the loose operational capability statements. In later discussion, however, customer people agreed that these additional requirements, although nice to have, were too expensive to add. Time passed. The project had political and funding problems, bouncing up and down over a period of four years like a short-hop shuttle airplane. Personnel changed several times; in one such change, the project apparently terminated and the entire acquisition group was reassigned. After two months of hiatus, a new acquisition group resumed the project. The technical specification went through several more revisions. Some- how, the record of those six requirements remained. The record of the agreement, however, was repeatedly lost. They were reinserted repeatedly by customer reviewers. After each revision, those six requirements were again deemed too expensive to add. But the specification was never quite approved to reflect the agreement. In the throes of responding to the fre- quent upheavals, the developers focused on completing the design and pro- duction. The specification faded onto a dusty shelf. Things on a dusty shelf have a way of coming back to haunt. Those six requirements came to light one last time. During system acceptance testing, customer monitors blew the dust off the specification and started a formal verification. The result of six missing requirements was a three million dollar overrun. Ralph Young’s book provides the tools that company needed and did not have. Building on Effective Requirements Practices and on his years of practical experience, Ralph offers a set of tools and techniques that are essential for modern requirements analysis, written into a handbook format for xi xii Foreword continued reference. This book describes both the philosophy and practice of requirements analysis, with down-to-earth pragmatism that can help to do the job in the face of today’s complex system challenges. Human communications are imprecise. It is one aspect of nature of humanity that we fail to understand each other completely. Recall the campfire games of your childhood. In the game “Whispers,” someone starts a short statement around the campfire circle by whispering to his neighbor. In turn, each player passes on the statement, always in a whisper. After only a few transfers, the original statement is modified beyond recognition. In the game, the differences are so astonishing as to bring laughter to all. Recall the last time you went to a restaurant and ordered from a menu. Written in front of you is a full description of the entree you want. Confi- dently, you tell the waiter the entree. The waiter silently sighs and starts the perennial sequence of questions about side items. “Salad or soup, ma’am?” “New potatoes or French fries?” “Green beans or succotash?” All these options were clearly written on the menu, but somehow you missed them. Requirements are also a form of human communications, an attempt to convey complex ideas from one mind to another. Requirements are also a sparse form of communications, using bare written words to strive for preci- sion. Like menu descriptions, requirements always fall short. It is literally impossible to write any requirement, no matter how simple, that cannot be misconstrued honestly by some recipient. Even the word “requirement” is itself a miscommunication, for individ- ual requirements are frequently flexible rather than required. If a trade-off promises a significant benefit to a key performance parameter, specifiers will gladly change lesser “requirements” to accommodate the trade-off. And yet requirements are still the best method we know to convey the complexity of a technical idea. To handle this complexity, we use require- ments to perform three important roles, all of which are enhanced by the tools and techniques in this book. First, requirements are a contractual tool. This is the most commonly understood purpose. In this role, a specification defines the technical scope of a development contract. The legal impact of this role is far from small. One recent lawsuit between a prime contractor and a subcontractor hinged on the grammar of a single requirements statement, resulting in a multimil- lion dollar settlement. For the protection of both acquirers and suppliers, contractual requirements