Transcription
Requirements Strategy ss Event ListOutsourceSupplierE-5E-7External Requirements -5I-1I-2PUCBUCStoriesI-6I-4DeveloperBusiness Event ListIterative Requirements intsBusiness Event ListSequential Requirements Strategy
TheWorkWorkingProductBusinessNeeds FeedbackDevelopment BacklogPriorityBusinessPrioritized edbackPrioritized iss #ONTEXTs "5#SArtifactss ATA ICTIONARYs 3TAKEHOLDERSWriteRequirementsIterative Requirements Process
OwnerBusinessNeedsStrategicPlan forProductNew NeedsProductUse andEvolutionInitial CostsProjectBlastoffEnterprise ProductReusableRequirementsReuse LibraryWork ScopeWants andNeedsStakeholdersRequirementsTemplateDesign andDevelopTrawl forKnowledge RequirementPrototypeforthe WorkExperimentArchitectureReview entialRequirementWrite theRequirementRisks alityGatewayRejectsStakeholdersStrategicPlan Stakeholders &Management
This page intentionally left blank
Mastering theRequirementsProcessThird Edition
This page intentionally left blank
Mastering theRequirementsProcessGetting RequirementsRightThird Edition Suzanne RobertsonJames RobertsonUpper Saddle River, NJ Boston Indianapolis San FranciscoNew York Toronto Montreal London Munich Paris MadridCapetown Sydney Tokyo Singapore Mexico City
Many of the designations used by manufacturers and sellers to distinguish their products are claimed astrademarks. Where those designations appear in this book, and the publisher was aware of a trademarkclaim, the designations have been printed with initial capital letters or in all capitals.Rabbit, horse, and elephant icons courtesy of all-silhouettes.com. Owl icon courtesy of iStockphoto.com;all rights reserved.The authors and publisher have taken care in the preparation of this book, but make no expressed orimplied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumedfor incidental or consequential damages in connection with or arising out of the use of the informationor programs contained herein.The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases orspecial sales, which may include electronic versions and/or custom covers and content particular to yourbusiness, training goals, marketing focus, and branding interests. For more information, please contact:U.S. Corporate and Government Sales(800) 382-3419corpsales@pearsontechgroup.comFor sales outside the United States, please contact:International Salesinternational@pearson.comVisit us on the Web: informit.com/awLibrary of Congress Cataloging-in-Publication DataRobertson, Suzanne.Mastering the requirements process : getting requirements right / Suzanne Robertson,James Robertson.—3rd ed.p. cm.Includes bibliographical references and index.ISBN 978-0-321-81574-3 (hardcover : alk. paper) 1. Project management. 2. Computersoftware—Development. I. Robertson, James. II. Title.TA190.R48 2012005.1068’4—dc232012018961Copyright 2013 Pearson Education, Inc.All rights reserved. Printed in the United States of America. This publication is protected by copyright,and permission must be obtained from the publisher prior to any prohibited reproduction, storage in aretrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying,recording, or likewise. To obtain permission to use material from this work, please submit a written requestto Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, New Jersey07458, or you may fax your request to (201) 236-3290.ISBN-13: 978-0-321-81574-3ISBN-10:0-321-81574-2Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.Third printing, July 2014
For one generation,Reginald, Margaret, Nick, and Helen,and another,Carlotta, Cameron, and Louise
This page intentionally left blank
ContentsPreface to the Third EditionxxiForeword to the First EditionxxiiiAcknowledgments1Some Fundamental Truthsxxv1in which we consider the essential contribution of requirements2Truth 1Truth 2Truth 3Truth 4Truth 5Truth 6Truth 7Truth 8Truth 9Truth 10Truth 11What Are These Requirements Anyway?Functional RequirementsNon-functional RequirementsConstraintsThe Volere Requirements Process12345677889910101111The Requirements Process13in which we present a process for discovering requirements anddiscuss how you might use itThe Requirements Process in ContextA Case StudyProject BlastoffTrawling for RequirementsQuick and Dirty ModelingScenariosWriting the Requirements14151517192020vii
viii Contents3Quality GatewayReusing RequirementsReviewing the RequirementsIterative and Incremental ProcessesRequirements RetrospectiveEvolution of RequirementsThe TemplateThe Snow CardYour Own Requirements ProcessFormality GuideThe Rest of This Book2223232425262729313233Scoping the Business Problem35in which we establish a definition of the business area to bechanged, thereby ensuring that the project team has a clearvision of what their project is meant to achieveProject BlastoffFormality GuideSetting the ScopeSeparate the Work from its EnvironmentIceBreakerFirst-Cut Work ContextScope, Stakeholders, and GoalsStakeholdersThe SponsorThe CustomerUsers: Understand ThemOther StakeholdersConsultantsManagementSubject-Matter ExpertsCore TeamInspectorsMarket ForcesLegal ExpertsNegative StakeholdersIndustry Standard SettersPublic OpinionGovernmentSpecial-Interest GroupsTechnical ExpertsCultural InterestsAdjacent SystemsFinding the StakeholdersGoals: What Do You Want to 4454748505151515152525252525353535353535454555656
Contents ix4ConstraintsSolution ConstraintsProject ConstraintsNaming Conventions and DefinitionsHow Much Is This Going to Cost?RisksTo Go or Not to GoBlastoff MeetingsSummary595960606162636465Business Use Cases67in which we discuss a fail-safe way of partitioning the work and sosmooth the way for your requirements investigation5Understanding the WorkFormality GuideUse Cases and Their ScopeThe Scope of the WorkThe Outside WorldBusiness EventsTime-Triggered Business EventsWhy Business Events and Business Use Cases Are a Good IdeaThe “System” Cannot Be AssumedStep BackFinding the Business EventsBusiness Use CasesBusiness Use Cases and Product Use vestigating the Work87in which we come to an understanding of what the business isdoing, and start to think about what it might like to doTrawling the BusinessFormality GuideTrawl for KnowledgeThe Business AnalystTrawling and Business Use CasesThe Brown Cow ModelThe Current Way of Doing Things (How-Now)ApprenticingBusiness Use Case WorkshopsOutcomeScenariosBusiness RulesInterviewing the StakeholdersAsking the Right QuestionsListening to the Answers878989919293949899101101101102104105
x ContentsLooking for Reusable RequirementsQuick and Dirty Process ModelingPrototypes and SketchesLow-Fidelity PrototypesHigh-Fidelity PrototypesMind MapsThe Murder BookVideo and PhotographsWikis, Blogs, Discussion ForumsDocument ArcheologyFamily TherapyChoosing the Best Trawling TechniqueFinally . . 129in which we look at scenarios, and how the business analystuses them to communicate with the stakeholders7Formality GuideScenariosThe Essence of the BusinessDiagramming the ScenarioAlternativesExceptionsWhat if? ScenariosMisuse Cases and Negative ScenariosScenario standing the Real Problem147in which we “think above the line” to find the true essence ofthe business, and so deliver the right product—one that solvesthe right problemFormality GuideThe Brown Cow Model: Thinking Above the LineThe EssenceAbstractionSwim Lanes BegoneSolving the Right ProblemMoving into the FutureHow to Be InnovativeSystemic ThinkingValuePersonasChallenging ConstraintsInnovation WorkshopsBrainstormingBack to the 4
Contents 8Starting the Solution177in which we bring the essence of the business into thetechnological world of the implementationIterative DevelopmentEssential BusinessDetermine the Extent of the ProductConsider the UsersDesigning the User ionFeelingSketching the InterfaceThe Real Origin of the Business EventAdjacent Systems and External TechnologyActive Adjacent SystemsAutonomous Adjacent SystemsCooperative Adjacent SystemsCost, Benefit, and RisksDocument Your Design DecisionsProduct Use Case ScenariosPutting It All Together9Strategies for Today’s Business 92193194195196199203in which we consider strategies for the business analyst to guiderequirements discovery in today’s changing environmentsBalancing Knowledge, Activities, and PeopleCommon Project Requirements ProfilesHow Much Knowledge Is Needed Before Each Breakout?External StrategyConception to ScopingScoping to Work InvestigationWork Investigation to Product DeterminationWork Investigation to Atomic Requirements DefinitionWork Investigation to BuildingProduct Determination to Atomic Requirements DefinitionProduct Determination to ConstructionAtomic Requirements Definition to BuildingIterative StrategyConception to ScopingScoping to Work InvestigationWork Investigation to Product DeterminationWork Investigation to Requirements DefinitionProduct Determination to Requirements DefinitionRequirements Definition to ConstructionSequential StrategyConception to ScopingScoping to Work 10210210211211212212212213213xi
xii ContentsWork Investigation to Product DeterminationProduct Determination to Requirements DefinitionRequirements Definition to BuildingYour Own StrategySharpening Your Requirements SkillsNo Longer a StenographerLimiting the Number of Requirements That Are WrittenReusing RequirementsInnovation and the Business AnalystLooking for Business RulesThe Business Analyst as Ideas BrokerSystemic Thinking and the Business AnalystThe Business Analyst as VisualizerSummary10Functional 1222223in which we look at those requirements that cause the productto do somethingFormality GuideFunctional RequirementsUncovering the Functional RequirementsLevel of Detail or GranularityDescription and RationaleData, Your Secret WeaponData ModelsData DictionaryExceptions and AlternativesConditional RequirementsAvoiding AmbiguityTechnological RequirementsGrouping RequirementsAlternatives to Functional RequirementsScenariosUser StoriesBusiness Process ModelsRequirements for COTSSummary11Non-functional 7238239239240241242245in which we look at the requirements that specify how wellyour product does what it doesAn Introduction to Non-functional RequirementsFormality GuideFunctional Versus Non-functional RequirementsUse Cases and Non-functional RequirementsThe Non-functional Requirements TypesLook and Feel Requirements: Type 10Usability and Humanity Requirements: Type 11246246247248249250253
Contents 12Performance Requirements: Type 12Operational and Environmental Requirements: Type 13Maintainability and Support Requirements: Type 14Security Requirements: Type 15AccessPrivacyIntegrityAuditing. . . And No MoreCultural Requirements: Type 16Legal Requirements: Type 17Sarbanes-Oxley ActOther Legal ObligationsStandardsFinding the Non-functional RequirementsBlogging the RequirementsUse CasesThe TemplatePrototypes and Non-functional RequirementsThe ClientDon’t Write a 9270271271271272274274275276277Fit Criteria and Rationale279in which we show how measuring requirements makes themunambiguous, understandable, communicable, and testableFormality GuideWhy Does Fit Need a Criterion?The Rationale for the RationaleDeriving Fit CriteriaScale of MeasurementFit Criteria for Non-functional RequirementsProduct FailureSubjective TestsStandardsLook and Feel RequirementsUsability and Humanity RequirementsPerformance RequirementsOperational RequirementsMaintainability RequirementsSecurity RequirementsCultural RequirementsLegal RequirementsFit Criteria for Functional RequirementsTest CasesForms of Fit CriteriaDefining the DataGraphic Fit CriteriaDecision 3294294294295295296296297297297298xiii
xiv ContentsUse Cases and Fit CriteriaFit Criterion for Project PurposeFit Criteria for Solution ConstraintsSummary13The Quality Gateway299299300301303in which we prevent unsuitable requirements from becomingpart of the specificationFormality GuideRequirements QualityUsing the Quality GatewayWithin Scope?RelevancyTesting CompletenessAre There Any Missing Attributes?Meaningful to Stakeholders?Testing the Fit CriterionConsistent TerminologyViable within Constraints?Requirement or Solution?Requirement ValueGold PlatingRequirements CreepImplementing the Quality GatewayAlternative Quality GatewaysSummary14Requirements and Iterative 317317319320321323in which we look at how to discover and implement requirementsin an iterative development environmentThe Need for Iterative DevelopmentAn Iterative Requirements ProcessThe WorkAnalyze Business NeedsWrite User StoriesDevelop ProductBusiness Value Analysis and PrioritizationHow to Write a Good User StoryQuestions to AskFormalizing Your User StoriesFleshing out the StoryIterative Requirements RolesBusiness KnowledgeAnalytical and Communication KnowledgeTechnical 33333334334335
Contents15Reusing Requirements337in which we look for requirements that have already beenwritten and explore ways to make use of themWhat Is Reusing Requirements?Sources of Reusable RequirementsRequirements PatternsChristopher Alexander’s PatternsA Business Event PatternContext of Event ResponseProcessing for Event ResponseData for Event ResponseForming Patterns by AbstractingPatterns for Specific DomainsPatterns Across DomainsDomain AnalysisSummary16Communicating the 1353in which we turn the requirements into communicable formFormality GuideTurning Potential Requirements into Written RequirementsKnowledge Versus SpecificationThe Volere Requirements Specification TemplateTemplate Table of ContentsTemplate DivisionsDiscovering Atomic RequirementsSnow CardsAttributes of Atomic RequirementsRequirement NumberRequirement TypeEvent/BUC/PUC #DescriptionRationaleOriginatorFit CriterionCustomer Satisfaction and Customer DissatisfactionPriorityConflictsSupporting MaterialsHistoryAssembling the SpecificationAutomated Requirements ToolsFunctional RequirementsNon-functional RequirementsProject 62362363363363364364365365365366367368369369 xv
xvi Contents17Requirements Completeness371in which we decide whether our specification is complete,and set the priorities of the requirementsFormality GuideReviewing the SpecificationInspectionsFind Missing RequirementsHave All Business Use Cases Been Discovered?1. Define the Scope2. Identify Business Events and Non-eventsNon-events3. Model the Business Use Case4. Define the Business Data5. CRUD Check6. Check for Custodial ProcessesRepeat Until DonePrioritizing the RequirementsPrioritization FactorsWhen to PrioritizeRequirement Priority GradingPrioritization SpreadsheetConflicting RequirementsAmbiguous SpecificationsRisk AssessmentProject DriversProject ConstraintsFunctional RequirementsMeasure the Required CostSummaryAppendix A Volere Requirements Specification 382383384385386388388389390390391391393a guide for writing a rigorous and complete requirementsspecificationContentsProject DriversProject ConstraintsFunctional RequirementsNon-functional RequirementsProject IssuesUse of This TemplateVolereRequirements TypesTesting RequirementsAtomic Requirements Shell1. The Purpose of the Project1a. The User Business or Background of the Project Effort1b. Goals of the Project2. The Stakeholders2a. The 0400
Contents 2b. The Customer2c. Other Stakeholders2d. The Hands-on Users of the Product2e. Personas2f. Priorities Assigned to Users2g. User Participation2h. Maintenance Users and Service Technicians3. Mandated Constraints3a. Solution Constraints3b. Implementation Environment of the Current System3c. Partner or Collaborative Applications3d. Off-the-Shelf Software3e. Anticipated Workplace Environment3f. Schedule Constraints3g. Budget Constraints3h. Enterprise Constraints4. Naming Conventions and Terminology4a. Definitions of All Terms, Including Acronyms, Used byStakeholders Involved in the Project5. Relevant Facts and Assumptions5a. Relevant Facts5b. Business Rules5c. Assumptions6. The Scope of the Work6a. The Current Situation6b. The Context of the Work6c. Work Partitioning6d. Specifying a Business Use Case7. Business Data Model and Data Dictionary7a. Data Model7b. Data Dictionary8. The Scope of the Product8a. Product Boundary8b. Product Use Case Table8c. Individual Product Use Cases9. Functional and Data Requirements9a. Functional RequirementsNon-functional Requirements10. Look and Feel Requirements10a. Appearance Requirements10b. Style Requirements11. Usability and Humanity Requirements11a. Ease of Use Requirements11b. Personalization and Internationalization Requirements11c. Learning Requirements11d. Understandability and Politeness Requirements11e. Accessibility Requirements12. Performance Requirements12a. Speed and Latency Requirements12b. Safety-Critical Requirements12c. Precision or Accuracy 441441442443xvii
xviii Contents12d. Reliability and Availability Requirements12e. Robustness or Fault-Tolerance Requirements12f. Capacity Requirements12g. Scalability or Extensibility Requirements12h. Longevity Requirements13. Operational and Environmental Requirements13a. Expected Physical Environment13b. Requirements for Interfacing with Adjacent Systems13c. Productization Requirements13d. Release Requirements14. Maintainability and Support Requirements14a. Maintenance Requirements14b. Supportability Requirements14c. Adaptability Requirements15. Security Requirements15a. Access Requirements15b. Integrity Requirements15c. Privacy Requirements15d. Audit Requirements15e. Immunity Requirements16. Cultural Requirements16a. Cultural Requirements17. Legal Requirements17a. Compliance Requirements17b. Standards RequirementsProject Issues18. Open Issues19. Off-the-Shelf Solutions19a. Ready-Made Products19b. Reusable Components19c. Products That Can Be Copied20. New Problems20a. Effects on the Current Environment20b. Effects on the Installed Systems20c. Potential User Problems20d. Limitations in the Anticipated Implementation EnvironmentThat May Inhibit the New Product20e. Follow-Up Problems21. Tasks21a. Project Planning21b. Planning of the Development Phases22. Migration to the New Product22a. Requirements for Migration to the New Product22b. Data That Must Be Modified or Translated for the New System23. Risks24. Costs25. User Documentation and Training25a. User Documentation Requirements25b. Training Requirements26. Waiting Room27. Ideas for 469470471
Contents xixAppendix B Stakeholder Management TemplatesStakeholder MapStakeholder TemplateAppendix C Function Point Counting: A SimplifiedIntroduction473473475479in which we look at a way to accurately measure the size orfunctionality of the work area, with a view toward using themeasurement to estimate the requirements effortMeasuring the WorkA Quick Primer on Counting Function PointsScope of the WorkData Stored by the WorkBusiness Use CasesCounting Function Points for Business Use CasesCounting Input Business Use CasesCounting Output Business Use CasesCounting Time-Triggered Business Use CasesCounting the Stored DataInternal Stored DataExternally Stored DataAdjust for What You Don’t KnowNow That I Have Counted Function Points, What’s endix D Volere Requirements Knowledge Model495Definitions of Requirements Knowledge Classes and AssociationsKnowledge ClassesAssociationsKnowledge Model Annotated with Template Section 523
This page intentionally left blank
Preface to theThird EditionWhy a third edition of Mastering the Requirements Process? Because we needit. Much water has passed under the bridge since the last edition of this bookwas published, and much has happened in the requirements and development world. We have applied the Volere requirements techniques describedin this book to many projects; we have received feedback from our projectsand those of clients and other practitioners of the Volere techniques; andarmed with that knowledge we felt it was time to update our book to reflectthe current state of requirements practice. Today’s systems, software, products, and services have to be more attractive and more appropriate if they areto be noticed, bought, used and valued. More than ever, we need to be assuredthat we are solving the real problem. More than ever, we need to be doing abetter job with requirements discovery.New techniques for software development—most noticeably the rise ofagile techniques—have changed the role of the requirements discoverer: notthe underlying truth of the requirements activity, but the way in whichrequirements are discovered. Business analysts working with agile teamsperform their task differently. Combinations of iterative, incremental, andspiral development techniques require the business analyst to go about therequirements task in a different way.Outsourcing has increased enormously, which, rather than lessening therequirements burden, means that there is an even greater need to produceaccurate, and unambiguous, requirements. If you are planning to send yourspecification to the far side of the world, you would like to think that youroutsourcer will understand it and know exactly what to build.Despite all these changes in the way in which we develop and deliver ourproducts and services, one underlying fact is still there, and it is this: If we areto build some software or a product or a service, then it must provide the optimalvalue for its owner.You will see the theme of optimal value developed in this edition, andwhat it comes down to is that it does not matter how you develop your software, but rather what that software does for its owner that matters. You canxxi
xxii Preface to the Third Editionfinish a project on time and on budget, but if the delivered software bringslittle benefit to the owning organization, it is a waste of money. Alternatively, you can overspend and be late, but if the delivered product bringsseveral million dollars of value, then it is more beneficial than its cheapercounterpart.The task of the business analyst is to discover the real business that thesoftware is supposed to improve. This cannot be done at the keyboard simply because software is a solution, and to provide a valuable solution youfirst have to understand the problem—the real problem—that it is meant tosolve. In this edition we have written about thinking above the line. The linein this case comes from the Brown Cow Model (you’ll have to read the bookto find out what it is) and represents the division between the technologicalimplementations and the abstract, essential world where you discover thereal needs. We have written about innovation as a way of finding better, moreappropriate needs and solutions.This, then, is the task of the requirements discoverer, and indeed of thisedition: to delve more deeply into how we understand our client organizations, and how we find better solutions by discovering and communicatinga better understanding of the problem.London, June 2012For college instructors who adopt this book for their courses, some of thegraphics used herein are available in the Pearson Instructor Resource Center (www.pearsonhighered.com) for your use in preparing course materials.
Foreword to theFirst EditionIt is almost ten years now since Don Gause and I published Exploring Requirements: Quality Before Design. Our book is indeed an exploration, a survey ofhuman processes that can be used in gathering complete, correct, and communicable requirements for a software system, or any other kind of product.The operative word in this description is “can,” for over this decade themost frequent question my clients have asked is, “How can I assemble thesediverse processes into a comprehensive requirements process for our information systems?”At long last, James and Suzanne Robertson have provided an answer I canconscientiously give to my clients. Mastering the Requirements Process shows,step by step, template by template, example by example, one well-tested wayto assemble a complete, comprehensive requirements process.One watchword of their process is “reasonableness.” In other words, everypart of the process makes sense, even to people who are not very experienced with requirements work. When introducing this kind of structure toan organization, reasonableness translates into easier acceptance—an essential attribute when so many complicated processes are tried and rejected.The process they describe is the Volere approach, which they developedas an outcome of many years helping clients to improve their requirements.Aside from the Volere approach itself, James and Suzanne contribute theirsuperb teaching skills to the formidable task facing anyone who wishes todevelop requirements and do them well.The Robertsons’ teaching skills are well known to their seminar studentsas well as to fans of their Complete Systems Analysis books. Mastering theRequirements Process provides a much-requested front end for their analysisbooks—or for anyone’s analysis books, for that matter.We can use all the good books on requirements we can get, and this isone of them!Gerald M. Weinbergwww.geraldmweinberg.comFebruary 1999READINGGause, Donald C., andGerald M. Weinberg.Exploring Requirements:Quality Before Design.Dorset House, 1989.READINGRobertson, James, andSuzanne Robertson.Complete Systems Analysis:The Workbook, the Textbook,the Answers. Dorset House,1998.xxiii
This page intentionally left blank
AcknowledgmentsWriting a book is hard. Without the help and encouragement of others, itwould be nearly impossible, at least for these authors. We would like to takea few lines to tell you who helped and encouraged and made it possible.Andy McDonald of Vaisala was generous with his time, and gave us considerable technical input. We hasten to add that the IceBreaker product inthis book is only a distant relation to Vaisala’s IceCast systems. The VaisalaUser Group, of which E. M. Kennedy holds the chair, also provided valuabletechnical input.Thanks are due to the technical reviewers who gave up their time towade through some fairly incomprehensible stuff. Mike Russell, SusannahFinzi, Neil Maiden, Tim Lister, and Bashar Nuseibeh all deserve honorablementions.We would like to acknowledge our fellow principals at the Atlantic Systems Guild—Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin,and John Palmer—for their help, guidance, and incredulous looks over theyears.The staff at Pearson Education contributed. Sally Mortimore, Alison Birtwell, and Dylan Reisenberger were generous and skillful, and used such persuasive language whenever we spoke about extending the deadline.For the second edition, Peter Gordon provided guidance and persuasion at exactly the right times. Kim Boedigheimer, John Fuller, and LaraWysong were invaluable at steering us through the publishing process. JillHobbs tamed our faulty grammar and punctuation, and made this text readable. The technical input of Ian Alexander, Earl Beede, Capers Jones, andTony Wasserman goes far beyond valuable. Thank you, gentlemen, for yourinsights. And we hasten to add that any remaining technical errors are oursand ours alone.One would imagine that by the time one got to the third edition, onewould not need help. Not so. We gratefully acknowledge the alphabetictrinity of Gary Austin, Earl Beede, and John Capron. Our Volere colleagueStephen Mellor sorted out some of the trickier issues we encountered. Ourxxv
xxvi Acknowledgmentsother Volere colleagues James Archer and Andrew Kendall have helped overthe years with their ideas, experience, and meaningful conversations over aglass of wine.The Pearson crew of Peter Gordon, Kim Boedigheimer, and Julie Nahilwere invaluable. We want to point out the special work done by Alan Clements to design the cover. Once again, Jill Hobbs stepped up to tame ourgrammatical misdemeanors and semantic transgressions.And finally we thank the students at our seminars and our consultingclients.
Quick and Dirty Process Modeling 107 Prototypes and Sketches 109 Low-Fidelity Prototypes 111 High-Fidelity Prototypes 115 Mind Maps 116 The Murder Book 119 Video and Photographs 120 Wikis, Blogs, Discussion Forums 122 Document Archeology 123 Family Therapy 125 Choosing the Best Trawling Technique 125 Finally . . . 127 6 Scenarios 129
