TLFeBOOK Discovering Real Business Requirements for Software Project Success TLFeBOOK For a listing of recent titles in the Artech House Computing Library, turn to the back of this book. TLFeBOOK Discovering Real Business Requirements for Software Project Success Robin F. Goldsmith Artech House Boston • London www.artechhouse.com TLFeBOOK 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 Goldsmith, Robin F. Discovering real business requirements for software project success. —(Artech House computing library) 1. Computer software – Developement 2. Computer software – Design – Methodology 3. Business – Computer programs I. Title 005.1’2 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  . Microsoft is a registered trademark of Microsoft Corporation. Contents outline reprinted with permission from IEEE Std. 830-1998, “Recommended Practice for Software Requirements,” Copyright 1998, by IEEE. The IEEE disclaims any responsibility or liability resulting from the placement and use in the described manner. 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-770-7 10987654321 TLFeBOOK To my requirements: Janice, Christian, and Tudor Noel, who sometimes give me the business TLFeBOOK . TLFeBOOK Contents 1 2 Introduction . . . . . . . . . . . . . xv How this book differs xvi REAL requirements xviii Applicability to various methodologies xviii Objectives xix What’s in it for you xx Origins and structure xxi What’s not in this book xxiii Thanks xxiv Who needs to know xix References xxiv Value up-front . . . . . . . . . . . . . 1 Preaching to the choir 1 Definition 2 Requirements impact 6 What it’s worth 9 Reconsidering iterative development 11 Is XP an eXception? 11 Mind traps that hinder improvement 12 Jolting awareness 13 Proactive Testing 14 CAT-Scan Approach 14 References 16 The “regular way” . . . . . . . . . . . 17 µUser review (test method #1) 18 vii TLFeBOOK viii Contents 3 4 µManagement review (test method #2) 18 µSupervisory review (test method #3) 19 µPeer review (test method #4) 19 µQA review (test method #5) 19 Exercise: Review requirements 20 Analysis of the regular way 21 Why requirements are hard to test 22 Other weaknesses of the regular way 23 Testing one’s own work 24 Strengthening the review 25 µUse formal technical review (test method #6) 26 Some key additional points about reviews 28 µPredefine topics, guidelines, and specifics to examine (test method #7) 29 References 30 Real requirements . . . . . . . . . . . 31 Ann Analyst’s definition of requirements 31 µAre they business requirements? (test method #8) 33 “As is” versus “should be” 33 Format and contents 35 What versus how 36 Business versus system requirements 36 Automated teller machine example 38 Level of detail 40 A few more mythical distinctions 43 Who defines the requirements? 44 Make users responsible 45 Three necessary elements 46 How much is enough? 47 References 48 Evaluating requirements form . . . . . . . 51 µClarity (test method #9) 52 Form versus content 52 Two quick distinctions 53 µDeliverable whats (test method #10) 54 µTestable (test method #11) 55 µReviewable (test method #12) 56 µItemized (test method #13) 57 TLFeBOOK ix Contents 5 6 7 µTraceable (test method #14) 57 µAmbiguity (test method #15) 58 µConsistent, known usage of terms (test method #16) 60 µIdentifies assumptions (test method #17) 61 µStated in the positive (test method #18) 61 µIdentifies objectives (test method #19) 61 µIdentifies major functions and limits (test method #20) 62 µIdentifies business rules (test method #21) 62 µAlternative consequences defined (test method #22) 63 µMagic words (test method #23) 63 µComplete (test method #24) 64 References 65 Discovering real requirements . . . . . . . 67 Why we say users don’t know what they want 68 Requirements gathering 69 Like a detective story 70 Focus on value 71 “Should be” model 72 Real and presumed processes 73 Some process pitfalls 75 Improving the process 76 References 77 Problem Pyramid . . . . . . . . . . . 79 The challenge 79 Problem Pyramid structure 80 Example: Reuse repository 82 Guidelines for evaluating the problem definition 83 Effects of applying the guidelines 84 Exercise: Prepare your own Problem Pyramid 85 Example: Social service software 86 Example: Web Site 88 Example: Opportunity 90 Exercise: Review your own Problem Pyramid 90 Applying the techniques . . . . . . . . . 91 Exercise: Review additional requirements 92 Analysis of Ann’s updated requirements 93 Identifying the real problem 93 TLFeBOOK [...]... take 75 to 1,000, or more times, greater effort than if the requirement had been cor­ rected before it was coded It takes so much more effort for a variety of rea­ sons The programmer who is fixing it probably is less familiar with the code, either because he is a different programmer from the one who wrote the code originally or simply because over time he’s forgotten how it was written (Many programmers... opportunity Moreover, this book’s approach is not heavy on formality Rather, I emphasize content I do not believe in busywork for its own sake That is not to say, though, that I am against writing things down, which alas I fear is some people’s definition of “agile.” Overattention to form can be a real problem and is not limited to requirements For example, some prominent software testing gurus actively... test the accuracy and adequacy of business requirements from perspectives of: ◗ Assessing suitability of form; ◗ Identifying overlooked requirements; ◗ Evaluating substance/content ◗ Enlist appropriate models and formats for analyzing and understanding the requirements data ◗ Apply 7 guidelines for documenting and communicating the business requirements ◗ Differentiate the scope of the business requirements... giving citations for ideas that I actually took from a particular identifiable source or represent good sources of added information I apologize in advance for not always know­ ing where I heard or read something, perhaps years ago (which may be an affliction of the practitioner as contrasted with an academic, or maybe it’s just a sign of growing ripe) A number of other books offer valuable information relevant... manifestations of silos 11 143 Updating the ElecTech Problem Pyramid 145 Formats for documenting requirements 147 Generally agreed-upon contents 148 Generic unstructured individual requirements 149 IEEE Std 830-1998 for Software Requirements Specifications 149 Pigeonholing 151 Nonfunctional requirements 151 Use cases 151 Seven guidelines for documenting hierarchical itemized deliverables 155 µHierarchical... facilitate scaling to the size and shape of one’s own situation The most well-known agile method, eXtreme Programming (XP), actively enlists users in creating user stories, which are a format for briefly documenting the requirements for the code that will be programmed [1] I salute XP and any other technique which actually does promote meaningful user involvement The XP community seems pretty convinced that... time and effort to implement the requirements 164 Detailed requirements 164 References 12 166 Finding overlooked requirements 167 µUsers, customers, and stakeholders (test method #26) 170 170 µQuality dimension: Quality of conformance (test method #28) 169 Exercise: Identify stakeholders µQuality dimension: Quality of design (test method #27) 170 µQuality dimension: Quality of performance (test... and business managers, including marketing staff, who seek an explanation for why the technical people repeatedly fail to understand what the business’ requirements really are and need ways to be sure they are defined appropriately ◗ Instructors and students, whether in universities or professional train­ ing situations, who need to learn these important lessons before join­ ing the above ranks Caveat:... applying the methods and knowledge of your business, as well as system development, greatly influence the value you’ll get from these or any methods Practice and review for improvement are essential for developing proficiency What’s in it for you Organizations that learn to identify business requirements well can gain an insur­ mountable advantage over competitors that persist in getting conventional results... heads of both IBM and Hewlett-Packard have announced independently that success today in the information systems industry demands primary attention to understanding the needs of the customer, in other words, the business’ requirements Isn’t this old news? We’ve been talking for decades about how necessary it is for IT to align with the business Surely alignment demands first that IT understand what the . Gathering data in conjunction with interviews 122 References 123 Formats for analyzing requirements . . . . . 125 Data versus information 125 Exercise: Identifying what we don’t know 126 Sorting,. Problem Pyramid 145 Formats for documenting requirements . . . . 147 Generally agreed-upon contents 148 Generic unstructured individual requirements 149 IEEE Std. 830-1998 for Software Requirements. Programming (XP), actively enlists users in creating user stories, which are a format for briefly documenting the requirements for the code that will be programmed [1]. I salute XP and any other technique