Addison wesley mastering the requirements process 2nd edition mar 2006 ISBN 0321419499

Publisher: Addison Wesley Professional Pub Date: March 17, 2006 Print ISBN-10: 0-321-41949-9 Print ISBN-13: 978-0-321-41949-1 Pages: 592 Table of Contents | Index "If the purpose is to

Mastering the Requirements Process Second Edition

By Suzanne Robertson, James Robertson

Publisher: Addison Wesley Professional Pub Date: March 17, 2006

Print ISBN-10: 0-321-41949-9 Print ISBN-13: 978-0-321-41949-1 Pages: 592

Table of Contents | Index

"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded."

Capers Jones

It is widely recognized that incorrect requirements account for up to 60 percent of errors

in software products, and yet the majority of software development organizations do not have a formal requirements process Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place.

Mastering the Requirements Process, Second Edition, sets out an industry-proven

process for gathering and verifying requirements with an eye toward today's agile

development environments In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.

Features include

The Volere requirements processcompletely specified, and revised for compatibility with agile environments

A specification template that can be used as the basis for your own requirements specifications

New agility ratings that help you funnel your efforts into only the requirements work needed for your particular development environment and project

How to make requirements testable using fit criteria

Iterative requirements gathering leading to faster delivery to the client

Checklists to help identify stakeholders, users, nonfunctional requirements, and more Details on gathering and implementing requirements for iterative releases

An expanded project sociology section for help with identifying and communicating with stakeholders

Strategies for exploiting use cases to determine the best product to build

Methods for reusing requirements and requirements patterns

Examples showing how the techniques and templates are applied in real-world

situations

Mastering the Requirements Process Second Edition

By Suzanne Robertson, James Robertson

Publisher: Addison Wesley Professional Pub Date: March 17, 2006

Print ISBN-10: 0-321-41949-9 Print ISBN-13: 978-0-321-41949-1 Pages: 592

Many of the designations used by manufacturers and sellers todistinguish their products are claimed as trademarks Wherethose designations appear in this book, and the publisher wasaware of a trademark claim, the designations have been printedwith initial capital letters or in all capitals

The authors and publisher have taken care in the preparation ofthis book, but make no expressed or implied warranty of anykind and assume no responsibility for errors or omissions Noliability is assumed for incidental or consequential damages inconnection with or arising out of the use of the information orprograms contained herein

The publisher offers excellent discounts on this book when

ordered in quantity for bulk purchases or special sales, whichmay include electronic versions and/or custom covers and

content particular to your business, training goals, marketingfocus, and branding interests For more information, please

All rights reserved Printed in the United States of America Thispublication is protected by copyright, and permission must beobtained from the publisher prior to any prohibited

reproduction, storage in a retrieval system, or transmission inany form or by any means, electronic, mechanical,

photocopying, recording, or likewise For information regardingpermissions, write to:

In the six years since we published the first edition of this book,the world's knowledge of requirements has grown, and morepeople have a job called "business analyst," "requirements

engineer," or something similar The Volere Requirements

Specification Template has been downloaded countless times.The Volere Requirements Process is in use by thousands of

people who are engaged in the activity of successful

requirements gathering They, in turn, have given us feedbackover the years about what they needed to know, and what theyare doing when gathering requirements

This book is a reflection of the feedback we have received, and

of the way people have made use of the first edition

The requirements activity has moved away from wanting to beseen as an engineering discipline, to the realization that it is asociotechnical activity Requirements analysts now see their rolefirst as one of communication, and second as a technician

being that greater emphasis is placed on close customer

relationships, and less emphasis is placed on documentation

We heartily applaud this advance However, we have also seentoo many people, who, in the name of agility, rush to a solution

solved

This, then, is the role of requirements in the agile world: to

ensure that we hear not only one customer's voice, but also thevoices of the other stakeholdersthose with some value to add tothe requirements for the product Agile requirements analystsensure that the work is considered, not just the product, andthat the nonfunctional requirements are studied, not left to thewhim of the programmer

Agile methods have brought with them a healthy disdain fordocumentation We agree with this view Throughout this

second edition we urge you to consider the benefit before

committing anything to writing But while we suggest

sometimes you can develop software successfully without

formally written requirements, we never suggest you can do itwithout understanding the requirements

The emphasis on iterative development means that the

requirements "phase" is no longer completed before buildingbegins The drive toward short, sharp release cycles means

requirements analysts get feedback on their requirements

efforts more quickly Stakeholders receive positive

reinforcement when they see the time they invest in

requirements paid back with progressive versions of workingsoftware that does what they expect, and what they need

Technological advances have changed requirements gathering.Blogs and wikis mean that requirements analysts can gathertheir requirements informally and iteratively using the

convenience of networking with their stakeholders Desktopvideoconferencing and instant messaging mean closer, quickercommunication with stakeholders, which is, of course,

necessary for good requirements gathering

The gap between what we wrote in 1999 and what we foundourselves doing when gathering requirements gradually grew

volume that you hold in your hands is the result of the last fewyears of our work and teaching We trust you find it interesting,enlightening, and useful

assemble a complete, comprehensive requirements process

One watchword of their process is "reasonableness." In otherwords, every part of the process makes sense, even to peoplewho are not very experienced with requirements work Whenintroducing this kind of structure to an organization,

Robertson, James, and suzanne Robertson

Complete Systems An analysis: The Workbook, the

textbook, the Answer Dorset House, 1998.

The process they describe is the Volere approach, which theydeveloped as an outcome of many years helping clients to

improve their requirements Aside from the Volere approachitself, James and Suzanne contribute their superb teaching skills

to the formidable task facing anyone who wishes to developrequirements and do them well

The Robertsons' teaching skills are well known to their seminar

students as well as to fans of their Complete Systems

Analysis books Mastering the Requirements Process

provides a much-requested front end for their analysis booksorfor anyone's analysis books, for that matter

We can use all the good books on requirements we can get, andthis is one of them!

Gerald M Weinberg

www.geraldmweinberg.com

Febraury 1999

Writing a book is hard Without the help and encouragement ofothers, it would be nearly impossible, at least for these authors

We would like to take a few lines to tell you who helped andencouraged and made it possible

Thanks are due to the technical reviewers who gave up theirtime to wade through some fairly incomprehensible stuff MikeRussell, Susannah Finzi, Neil Maiden, Tim Lister, and BasharNuseibeh all deserve honorable mentions

We would like to acknowledge our fellow principals at the

Atlantic Systems GuildTom DeMarco, Peter Hruschka, Tim Lister,Steve McMenamin, and John Palmerfor their help, guidance, andincredulous looks over the years

The staff at Pearson Education contributed Sally Mortimore,Alison Birtwell, and Dylan Reisenberger were generous and

skillful, and used such persuasive language whenever we spokeabout extending the deadline

For the second edition, Peter Gordon provided guidance andpersuasion at exactly the right times Kim Boedigheimer, JohnFuller, and Lara Wysong were invaluable at steering us throughthe publishing process Jill Hobbs tamed our faulty grammarand punctuation, and made this text readable The technicalinput of Ian Alexander, Earl Beede, Capers Jones, Chuck

Pfleeger, and Tony Wasserman goes far beyond valuable Thank

And finally we thank the students at our seminars and our

consulting clients Their comments, their insistence on havingthings clearly explained, their insights, and their feedback haveall made some difference, no matter how indirect, to this book.Thank you, everybody

James and Suzanne Robertson London, January 2006

in which we consider why we are interested in

requirements

The most useful products are those where the developers haveunderstood what the product is intended to accomplish for itsusers and how it must accomplish that purpose To understandthese things, you must understand what kind of work the userswant to do and how the product will affect that work and fit intothe organization's goals What the product does for its usersand which constraints it must satisfy in this context are the

product's requirements Apart from a few fortuitous accidents,

no product has ever succeeded without prior understanding ofits requirements It does not matter what kind of work the userwishes to do, be it scientific, commercial, e-commerce, or wordprocessing Nor does it matter which programming language ordevelopment tools are used to construct the product The

development processwhether agile, eXtreme Programming,

prototyping, the Rational Unified Process, or any other methodisirrelevant to the need for understanding the requirements Onefact always emerges: You must come to the correct

determine their precise nature Moreover, it explains how youwill know that you have found the correct requirements andhow to communicate them

Any important endeavor needs some kind of orderly process.Moreover, the people who are active in the process must beable to see why different parts of the process are important,and which parts carry particular significance for their particularproject This book presents Volerea process, a requirementsspecification template, and a set of techniques for gathering,confirming, organizing, and documenting the requirements for aproduct This process and template can beindeed, have

beenused for any kind of product or project Since the first

version of Volere was released in 1995, it has been used by

thousands of projects in hundreds of countries

The requirements process, as we describe it here, is a thoroughexploration of the intended product with the intention of

product unless you know what you are trying to build This doesnot mean that your understanding must always be perfect

before you start construction, and it does not mean that all therequirements have to be written down But it does mean that ifyou intend to deliver useful and usable products at the lowestcost to your organization, you must pay attention to

requirements

This book discusses how you can come to an understanding ofthe requirements and how you might write them down so thatthe constructors, and the future generations of maintenance

Requirements are usually expressed as an abstraction That is,they are expressed in a technologically neutral way so as tointentionally avoid influencing the design of the solution Therequirements are a pure statement of business needs, withoutany implementation bias The role of product design is to

translate the requirements into a plan to build some physicalreality that will, in the real world, do what is needed Productdesign determines which devices are to be used, which softwarecomponents are necessary, and how they are to be constructed

It is important to the success of the product that final designdecisions are not taken before the relevant requirements areknown It is equally important to note that a well-organizedrequirements process means that requirements, design, andimplementation can be done as a number of iterative loops.Each iteration produces some usable functionality Figure 1.1

should be read as iterative That is, the complete Requirements

Specification does not have to be produced before design and

environment, you will produce a minimal set of requirementscomponents and use those as a guide to planning iterations

be able to grow to accommodate the new demands If you areusing an agile process where new functionality is delivered

frequently, the partial product has an effect on the work

practices For example, it may trigger new, previously

unforeseen requirements, some of which may change the

requirements is a process that we cannot control or prescribe,but it is one that we must accept Requirements for a productare not frozen the moment that it is built Instead, they evolveover a period of time, and any requirements process must takethis fact of ongoing change into account

Requirements for a product are not frozen the

moment that it is built.

Requirements gathering and systems modeling have a

significant degree of overlapthe requirements gatherer usesmodels to help find the requirements, and the modeler uses therequirements to help model the functionality and data Bothproduce artifacts used to understand and specify requirements

In the beginning, the requirements-gathering activity is

dominant The only models being built are a context diagramand perhaps an exploratory data model and a stakeholder map.The requirements analysts are busy discovering the businessgoals, the stakeholders, the work (or business domain), and thedesired outcome

As the knowledge of the work increases and the business usecases evolve from fuzzy intentions to known quantities, the

models become more precise and provide valuable feedback tothe requirements gathering Similarly, the growing knowledge

of the requirements feeds the modeling process, enabling themodeling to be more productive This relationship is illustrated

development continues, the modeling activity expands to

occupy a continually greater proportion of the effort

functionality Provided that the model is complete and is

supported by a data dictionary and any needed process

descriptions or scenarios, it makes a suitable alternative to thetextual specification

The craft of systems modeling is well documented Several

books cover this area, including those mentioned in the margin

We encourage you to build models of your proposed productand to understand the work by building models of it We will notcover, except in a very rudimentary way, how to build thesemodels That is for you to explore We will, however, bring you

to a complete understanding of what a requirement is, how towrite one, and how requirements connect to models

Robertson, James, and Suzanne Robertson Complete

Systems Analysis: The Workbook, the Textbook, the Answers Dorset House, 1998.

Jacobson, Ivar, et al Object-Oriented Software

Engineering: A Use Case Driven Approach Addison-Wesley, 1992.

Since the first edition of this book was published, the agileapproach to developing systems has become popular, and

rightly so Agility refers to product development where the

team's development process is based on the principles of theAgile Manifesto We reproduce it here and, throughout thisbook, will show its relevance to the requirements activity

proponents of agile development believe that agility and

requirements are not compatible This view is both wrong anddangerous

these techniques involve some kind of personal interaction withthe appropriate stakeholders Requirements come from

humans, so the better you are at interacting with humans, thebetter you will be at gathering requirements There is no tool orprocess that, as far as we can see, will ever replace the

effectiveness of the requirements analyst and the stakeholdersitting down eyeball-to-eyeball and talking about what is

needed The skill of the requirements analyst here is to

introduce tools, models, and other measures that can help thestakeholder discover and explain his needs

Working software over comprehensive documentation

All too often, the requirements process is seen as a long-windedprocess that eventually delivers an unreadable (and often

contractoutsourcing or complying with departmental

responsibilities are examples that spring to mindand you cannotavoid creating a contractual requirements specification Thecourts are jammed with lawsuits between software suppliersand clients where the source of disagreement is not whetherthe software works, but whether it does what is needed

of what is needed Do not ask the client to sign off on the

requirements; instead, ask the client to sign on to them and

make them a collaborative effort

Responding to change over following a plan

what is delivered is what they asked for Good requirementspractices encourage change as early as possible in the cycle,when the changes are cheapest to make By using interactivemodels such as scenarios and prototypes, the requirementsanalyst encourages the stakeholder to make changes beforebuilding the software

Boehm, Barry, and Richard Turner Balancing Agility and

Discipline: A Guide for the Perplexed Addison-Wesley,

2003.

There is every reason to make your requirements activity asagile as possible We say "as possible" because in some

in such a way as to be as agile as you can, and get the correctresult

Rabbitthe most agile of projects You are a rabbit when you

delivering a small increment to the working functionality Rabbitprojects will not spend a great deal of time writing the

requirementsthat is not the same thing as not learning the

requirementsand probably will use scenarios and prototypes fordelivering the requirements to the developers In a rabbit

project the sources of domain knowledge are colocated with thedevelopers Rabbit projects, like their namesake, have relativelyshort lives

Horsefast, strong, and dependable Horse projects are

probably the most common corporate projects There is a needfor some documentation, because requirements likely must behanded from one department to another Horse projects usuallyinvolve more than a few stakeholders (often in a variety of

locations), thus necessitating the need for some consistentlywritten documentation The organization in this case has a

manufacture, where regulators demand that not only full

specifications be produced, but also the process used to

produce them be documented and auditable Elephant projectstypically have a long duration, and they involve many

Little uses a menagerie that includes skunks in his article for

IEEE Software Each author, including the current ones,

categorizes agility by looking at different aspects of productdevelopment and using an animal to represent each category

We do not claim the idea of using animals as an original one,but we persist with it, as we believe it to be a simple indicator

quickly Throughout this book, we will point out the relevancy ofparts of each chapter to rabbits, horses, and elephants In otherwords, we will guide you to select the parts of the requirementsprocess that return the best value for the effort expended The

discovering and managing requirements so that you can makechoices about how much requirements work you need to dobefore you can deliver your product.

The product is whatever you want to construct You might want

to produce it from scratch, buy it ready-made, install it for freeusing open source components, or acquire it in some other way.For the sake of simplicity, we will use the term "constructing"the product It stands to reason that the product's requirementsmust be understood before its construction begins The correctrequirements come from understanding the work that the

product is intended to support Only when you know the correctrequirements can you design and build the correct product,

which in turn enables the product's users to do their work in away that satisfies their business needs

Sadly, the requirements are not always correctly understood.Both Steve McConnell and Jerry Weinberg provide statistics thatshow that as many as 60 percent of errors originate with therequirements activity Clearly, although developers of productshave the opportunity to almost eliminate the entire largest

category of error, they chooseor, even worse, their managerschooseto rush headlong into constructing the wrong product As

a result, they pay many times the price for the product thanthey would have if the requirements and analysis had been

to understand requirements Programming is constructing the

solution to the problem Sure, you can turn out many iterations

of a solution in a weekbut they are still solutions Without anunderstanding of the fundamental work the user needs to doand of the broader ramifications of introducing your solutioninto the work environment, your solution can be no better thanthe user's perception of a fix to the current problem There is

no conflict between agile development and requirements, just adifference in the way you discover and manage the

organization of repair to substandard products, the cost of

cancelled projects that suffered requirements breakdown (noone could agree on the requirements), and the cost of the

opportunity lost by not having the correct products at the

correct time If this wastage is insignificant, then stop readingthis book You already have your requirements process undercontrol

Otherwise, read on