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

MasteringtheRequirementsProcessSecond
Edition
BySuzanneRobertson,JamesRobertson
...............................................
Publisher:AddisonWesleyProfessional
PubDate:March17,2006
PrintISBN-10:0-321-41949-9
PrintISBN-13:978-0-321-41949-1
Pages:592

TableofContents|Index

"Ifthepurposeistocreateoneofthebestbooksonrequirementsyetwritten,theauthors
havesucceeded."
CapersJones
Itiswidelyrecognizedthatincorrectrequirementsaccountforupto60percentoferrors
insoftwareproducts,andyetthemajorityofsoftwaredevelopmentorganizationsdonot
haveaformalrequirementsprocess.Manyorganizationsappearwillingtospendhuge
amountsonfixingandalteringpoorlyspecifiedsoftware,butseemunwillingtoinvesta
muchsmalleramounttogettherequirementsrightinthefirstplace.
MasteringtheRequirementsProcess,SecondEdition,setsoutanindustry-proven
processforgatheringandverifyingrequirementswithaneyetowardtoday'sagile
developmentenvironments.Inthistotalupdateofthebestsellingguide,theauthorsshow
howtodiscoverpreciselywhatthecustomerwantsandneedswhiledoingtheminimum
requirementsworkaccordingtotheproject'slevelofagility.
Featuresinclude
TheVolererequirementsprocesscompletelyspecified,andrevisedforcompatibility
withagileenvironments
Aspecificationtemplatethatcanbeusedasthebasisforyourownrequirements
specifications
Newagilityratingsthathelpyoufunnelyoureffortsintoonlytherequirementswork

neededforyourparticulardevelopmentenvironmentandproject
Howtomakerequirementstestableusingfitcriteria
Iterativerequirementsgatheringleadingtofasterdeliverytotheclient


Checkliststohelpidentifystakeholders,users,nonfunctionalrequirements,andmore
Detailsongatheringandimplementingrequirementsforiterativereleases
Anexpandedprojectsociologysectionforhelpwithidentifyingandcommunicating
withstakeholders
Strategiesforexploitingusecasestodeterminethebestproducttobuild
Methodsforreusingrequirementsandrequirementspatterns
Examplesshowinghowthetechniquesandtemplatesareappliedinreal-world
situations


MasteringtheRequirementsProcessSecond
Edition
BySuzanneRobertson,JamesRobertson
...............................................
Publisher:AddisonWesleyProfessional
PubDate:March17,2006
PrintISBN-10:0-321-41949-9
PrintISBN-13:978-0-321-41949-1
Pages:592

TableofContents|Index

Copyright
PrefacetotheSecondEdition
ForewordtotheFirstEdition
Acknowledgments
Chapter1.WhatAreRequirements?
RequirementsGatheringandSystemsModeling
AgileSoftwareDevelopment
WhyDoINeedRequirements?
WhatIsaRequirement?
EvolutionofRequirements
TheTemplate
TheShell
TheVolereRequirementsProcess
Chapter2.TheRequirementsProcess
AgilityGuide
RequirementsProcessinContext
TheProcess
ACaseStudy
TrawlingforRequirements
PrototypingtheRequirements
Scenarios
WritingtheRequirements

TheQualityGateway
ReusingRequirements
ReviewingtheSpecification
IterativeandIncrementalProcesses
RequirementsRetrospective
YourOwnRequirementsProcess
InConclusion
Chapter3.ProjectBlastoff
AgilityGuide
IceBreaker

Scope,Stakeholders,Goals
SettingtheScope
Stakeholders
TheClient
TheCustomer
TheUsers:GettoKnowThem
OtherStakeholders
Consultants
Management
SubjectMatterExperts
CoreTeam
Inspectors
MarketForces
Legal
NegativeStakeholders
IndustryStandardSetters
PublicOpinion
Government
Special-InterestGroups
TechnicalExperts
CulturalInterests
AdjacentSystems
FindingtheStakeholders
Goals:WhatDoYouWanttoAchieve?
KeepingTrackofthePurpose
RequirementsConstraints
SolutionConstraints
ProjectConstraints
NamingConventionsandDefinitions

HowMuchIsThisGoingtoCost?
Risks
ToGoorNottoGo
BlastoffAlternatives
Summary
Chapter4.Event-DrivenUseCases
AgilityGuide
UnderstandingtheWork
UseCasesandTheirScope
TheWork
TheContextoftheWork
TheOutsideWorld

BusinessEvents
Time-TriggeredBusinessEvents
WhyBusinessEventsandBusinessUseCasesAreaGoodIdea
FindingtheBusinessEvents
BusinessUseCases
TheRoleofAdjacentSystems
Summary
Chapter5.TrawlingforRequirements
AgilityGuide
Responsibility
TrawlingandBusinessUseCases
TheRoleoftheCurrentSituation
Apprenticing
ObservingStructuresandPatterns
InterviewingtheStakeholders
GettingtotheEssenceoftheWork
SolvingtheRightProblem
InnovativeProducts
BusinessUseCaseWorkshops
CreativityWorkshops
Brainstorming
Personas
MindMaps
Wallpaper
VideoandPhotographs
Wikis,Blogs,andDiscussionForums
DocumentArcheology

SomeOtherRequirements-GatheringTechniques
DeterminingWhattheProductShouldBe
DoesTechnologyMatter?
ChoosingtheBestTrawlingTechnique
Summary
Chapter6.ScenariosandRequirements
AgilityGuide
Scenarios
NormalCaseScenarios
DiagrammingtheScenario
AlternativeCases
ExceptionCases
WhatIf?Scenarios
MisuseCasesandNegativeScenarios
ScenarioTemplate

ProductUseCaseScenarios
Summary
Chapter7.FunctionalRequirements
AgilityGuide
FunctionalRequirements
FindingtheFunctionalRequirements
LevelofDetailorGranularity
ExceptionsandAlternatives
AvoidingAmbiguity
TechnologicalRequirements
Requirements,NotSolutions
GroupingRequirements
AlternativestoFunctionalRequirements
Summary
Chapter8.NonfunctionalRequirements
AgilityGuide
NonfunctionalRequirements
UseCasesandNonfunctionalRequirements
TheNonfunctionalRequirements
LookandFeelRequirements:Type10
UsabilityandHumanityRequirements:Type11
PerformanceRequirements:Type12
OperationalandEnvironmentalRequirements:Type13
MaintainabilityandSupportRequirements:Type14

SecurityRequirements:Type15
CulturalandPoliticalRequirements:Type16
LegalRequirements:Type17
FindingtheNonfunctionalRequirements
Don'tWriteaSolution
Summary
Chapter9.FitCriteria
AgilityGuide
WhyDoesFitNeedaCriterion?
ScaleofMeasurement
Rationale
FitCriteriaforNonfunctionalRequirements
FitCriteriaforFunctionalRequirements
UseCasesandFitCriteria
FitCriterionforProjectPurpose
FitCriteriaforSolutionConstraints
Summary

Chapter10.WritingtheRequirements
AgilityGuide
TurningPotentialRequirementsintoWrittenRequirements
KnowledgeVersusSpecification
TheVolereRequirementsSpecificationTemplate
Section1.ThePurposeoftheProject
Section2.TheClient,theCustomer,andOtherStakeholders
Section3.UsersoftheProduct
Section4.MandatedConstraints
Section5.NamingConventionsandDefinitions
Section6.RelevantFactsandAssumptions
Section7.TheScopeoftheWork
Section8.TheScopeoftheProduct
TheShell
TheAtomicRequirement
WritingtheSpecification
Section9.FunctionalRequirements
NonfunctionalRequirements
ProjectIssues
Section18.OpenIssues
Section19.Off-the-ShelfSolutions
Section20.NewProblems

Section21.Tasks
Section22.MigrationtotheNewProduct
Section23.Risks
Section24.Costs
Section25.UserDocumentationandTraining
Section26.WaitingRoom
Section27.IdeasforSolutions
Summary
Chapter11.TheQualityGateway
AgilityGuide
RequirementsQuality
UsingtheQualityGateway
TestingCompleteness
TestingTraceability
ConsistentTerminology
RelevanttoPurpose?
TestingtheFitCriterion
ViablewithinConstraints?
RequirementorSolution?
CustomerValue

GoldPlating
RequirementsCreep
ImplementingtheQualityGateway
Summary
Chapter12.PrototypingtheRequirements
AgilityGuide
PrototypesandReality
Low-FidelityPrototypes
high-fidelityPrototypes
Storyboards
ObjectLifeHistory
ThePrototypingLoop
Summary
Chapter13.ReusingRequirements
WhatIsReusingRequirements?
SourcesofReusableRequirements
RequirementsPatterns
ABusinessEventPattern
FormingPatternsbyAbstracting

DomainAnalysis
TrendsinReuse
Summary
Chapter14.ReviewingtheSpecification
AgilityGuide
ReviewingtheSpecification
Inspections
FindMissingRequirements
HaveAllBusinessUseCasesBeenDiscovered?
CustomerValue
PrioritizingtheRequirements
ConflictingRequirements
AmbiguousSpecifications
RiskAnalysis
MeasuretheRequiredEffort
Summary
Chapter15.WhitherRequirements?
AdaptingtheProcess
WhatAboutRequirementsTools?
MappingToolstoPurpose
PublishingtheRequirements
RequirementsTraceability
DealingwithChange

RequirementsRetrospective
YourNotebook
TheEnd
AppendixA.VolereRequirementsProcessModel
TheVolereRequirementsProcessModel
DefineBlastoffObjectives(ProcessNotes1.1.1)
PlanPhysicalArrangements(ProcessNotes1.1.2)
CommunicatewithParticipants(ProcessNotes1.1.3)
DetermineProjectPurpose(ProcessNotes1.2.1)
DeterminetheWorkContext(ProcessNotes1.2.2)
DoFirst-CutRiskAnalysis(ProcessNotes1.2.3)
IdentifytheStakeholders(ProcessNotes1.2.4)
PartitiontheContext(ProcessNotes1.2.5)
ConsiderNon-Events(ProcessNotes1.2.6)
DetermineBusinessTerminology(ProcessNotes1.2.7)
DefineProjectConstraints(ProcessNotes1.2.8)




IdentifyDomainsofInterest(ProcessNotes1.2.9)

WriteBlastoffReport(ProcessNotes1.3.1)
ReviewBlastoffResults(ProcessNotes1.3.2)
HoldFollow-UpBlastoff(ProcessNotes1.3.3)
MakeInitialEstimate(ProcessNotes1.3.4)
ReviewCurrentSituation(ProcessNotes2.1.1)
ApprenticewiththeUser(ProcessNotes2.1.2)
DetermineEssentialRequirements(ProcessNotes2.1.3)
BrainstormtheRequirements(ProcessNotes2.1.4)
InterviewtheUsers(ProcessNotes2.1.5)
DoDocumentArchaeology(ProcessNotes2.1.6)
MakeRequirementsVideo(ProcessNotes2.1.7)
RunUseCaseWorkshop(ProcessNotes2.1.8)
BuildEventModels(ProcessNotes2.1.9)
BuildScenarioModels(ProcessNotes2.1.10)
RunCreativityWorkshop(ProcessNotes2.1.11)
StudytheAdjacentSystems(ProcessNotes2.2.1)
DefineUseCaseBoundary(ProcessNotes2.2.2)
GatherBusinessEventKnowledge(ProcessNotes2.3.1)
ChooseAppropriateTrawlingTechniques(ProcessNotes2.3.2)
AskClarificationQuestions(ProcessNotes2.4)
IdentifyPotentialRequirements(ProcessNotes3.1)
IdentifyFunctionalRequirements(ProcessNotes3.2)
IdentifyCompositeRequirements(ProcessNotes3.3)
FormalizeRequirement(ProcessNotes3.4)
FormalizeSystemConstraints(ProcessNotes3.5)
IdentifyNonfunctionalRequirements(ProcessNotes3.6)
WriteFunctionalFitCriteria(ProcessNotes3.7)
WriteNonfunctionalFitCriteria(ProcessNotes3.8)
DefineCustomerValue(ProcessNotes3.9)

IdentifyDependenciesandConflicts(ProcessNotes3.10)
ReviewRequirementFitCriteria(ProcessNotes4.1)
ReviewRequirementRelevance(ProcessNotes4.2)
ReviewRequirementViability(ProcessNotes4.3)
IdentifyGold-PlatedRequirements(ProcessNotes4.4)
ReviewRequirementCompleteness(ProcessNotes4.5)
PlanthePrototype(ProcessNotes5.1)
BuildLow-FidelityPrototype(ProcessNotes5.2.1)
Buildhigh-fidelityPrototype(ProcessNotes5.2.2)

Testhigh-fidelityPrototypewithUsers(ProcessNotes5.3.1)
TestLow-FidelityPrototypewithUsers(ProcessNotes5.3.2)
IdentifyNewandChangedRequirements(ProcessNotes5.3.3)
EvaluatePrototypingEffort(ProcessNotes5.3.4)
ConductPrivateIndividualReviews(ProcessNotes6.1.1)
ConductSeparateMeetingswithGroups(ProcessNotes6.1.2)
FacilitatorReviewsFacts(ProcessNotes6.1.3)
HoldRetrospectiveReviewMeeting(ProcessNotes6.2.1)
ProduceRetrospectiveReport(ProcessNotes6.2.2)
IdentifyFiltrationCriteria(ProcessNotes6.3.1)
SelectRelevantRequirementTypes(ProcessNotes6.3.2)
AddNewFiltrationCriteria(ProcessNotes6.3.3)
IdentifyMissingRequirements(ProcessNotes7.1.1)
IdentifyCustomerValueRatings(ProcessNotes7.1.2)
IdentifyRequirementInteraction(ProcessNotes7.1.3)
IdentifyPrototypingOpportunity(ProcessNotes7.1.4)
FindMissingCustodialRequirements(ProcessNotes7.1.5)
LookforLikelyRisks(ProcessNotes7.2.1)
QuantifyEachRisk(ProcessNotes7.2.2)
IdentifyEstimationInput(ProcessNotes7.3.1)
EstimateEffortforEvents(ProcessNotes7.3.2)
EstimateRequirementsEffort(ProcessNotes7.3.3)
DesignFormofSpecification(ProcessNotes7.4.1)

AssembletheSpecification(ProcessNotes7.4.2)
DictionaryofTermsUsedintheRequirementsProcessModel
AppendixB.VolereRequirementsSpecificationTemplate
Contents
Preamble
Volere
RequirementsTypes
TestingRequirements
RequirementsShell
Section9.FunctionalandDataRequirements
Section10.LookandFeelRequirements
Section11.UsabilityandHumanityRequirements
AppendixC.FunctionPointCounting:ASimplifiedIntroduction
MeasuringtheWork
AQuickPrimeronCountingFunctionPoints
CountingFunctionPointsforBusinessUseCases




AdjustforWhatYouDon'tKnow


What'sNextAfterCountingFunctionPoints?

AppendixD.ProjectSociologyAnalysisTemplates

StakeholderMapTemplate

StakeholderAnalysisTemplate

Glossary

Bibliography

InsideFrontCover

Index


Copyright
Manyofthedesignationsusedbymanufacturersandsellersto
distinguishtheirproductsareclaimedastrademarks.Where
thosedesignationsappearinthisbook,andthepublisherwas
awareofatrademarkclaim,thedesignationshavebeenprinted
withinitialcapitallettersorinallcapitals.
Theauthorsandpublisherhavetakencareinthepreparationof
thisbook,butmakenoexpressedorimpliedwarrantyofany
kindandassumenoresponsibilityforerrorsoromissions.No
liabilityisassumedforincidentalorconsequentialdamagesin
connectionwithorarisingoutoftheuseoftheinformationor
programscontainedherein.
Thepublisheroffersexcellentdiscountsonthisbookwhen
orderedinquantityforbulkpurchasesorspecialsales,which
mayincludeelectronicversionsand/orcustomcoversand
contentparticulartoyourbusiness,traininggoals,marketing
focus,andbrandinginterests.Formoreinformation,please
contact:
U.S.CorporateandGovernmentSales(800)3823419

ForsalesoutsidetheUnitedStatespleasecontact:
InternationalSales

ThisBookIsSafariEnabled
TheSafari®Enabledicononthecoverofyourfavorite


technologybookmeansthebookisavailablethroughSafari
Bookshelf.Whenyoubuythisbook,yougetfreeaccesstothe
onlineeditionfor45days.
SafariBookshelfisanelectronicreferencelibrarythatletsyou
easilysearchthousandsoftechnicalbooks,findcodesamples,
downloadchapters,andaccesstechnicalinformationwhenever
andwhereveryouneedit.
Togain45daySafariEnabledaccesstothisbook:
Goto />Completethebriefregistrationform
EnterthecouponcodeXTHN-UQII-LKJY-AZID-N9SN
IfyouhavedifficultyregisteringonSafariBookshelfor
accessingtheonlineedition,pleasee-mail
VisitusontheWeb:www.awprofessional.com
LibraryofCongressCataloging-in-PublicationData

Robertson,Suzanne.
Masteringtherequirementsprocess/SuzanneRobertson,JamesRobertso
p.cm.
Includesbibliographicalreferencesandindex.
ISBN0321419499(hardcover:alk.paper)
1.Projectmanagement.I.Robertson,James.II.Title.
TA190.R482006
005.10684dc22

2005036027


Copyright©2006PearsonEducation,Inc.
Allrightsreserved.PrintedintheUnitedStatesofAmerica.This
publicationisprotectedbycopyright,andpermissionmustbe
obtainedfromthepublisherpriortoanyprohibited
reproduction,storageinaretrievalsystem,ortransmissionin
anyformorbyanymeans,electronic,mechanical,
photocopying,recording,orlikewise.Forinformationregarding
permissions,writeto:
PearsonEducation,Inc.
RightsandContractsDepartment
75ArlingtonStreet,Suite300
Boston,MA02116
Fax:(617)8487047
10987654321
TextprintedintheUnitedStatesonrecycledpaperatCourierin
Westford,Massachusetts.
Firstprinting,March2006

Dedication

Foronegeneration,
MargaretandNick
andanother,
CarlottaandCameron


PrefacetotheSecondEdition

Inthesixyearssincewepublishedthefirsteditionofthisbook,
theworld'sknowledgeofrequirementshasgrown,andmore
peoplehaveajobcalled"businessanalyst,""requirements
engineer,"orsomethingsimilar.TheVolereRequirements
SpecificationTemplatehasbeendownloadedcountlesstimes.
TheVolereRequirementsProcessisinusebythousandsof
peoplewhoareengagedintheactivityofsuccessful
requirementsgathering.They,inturn,havegivenusfeedback
overtheyearsaboutwhattheyneededtoknow,andwhatthey
aredoingwhengatheringrequirements.
Thisbookisareflectionofthefeedbackwehavereceived,and
ofthewaypeoplehavemadeuseofthefirstedition.
Therequirementsactivityhasmovedawayfromwantingtobe
seenasanengineeringdiscipline,totherealizationthatitisa
sociotechnicalactivity.Requirementsanalystsnowseetheirrole
firstasoneofcommunication,andsecondasatechnician
addingrigorandprecisiontotheresultsofthehuman
communication.
Asaresult,wehaveupdatedandexpandedtheproject
sociologyanalysissectionofthebook.Inasimilarvein,we
haveaddedtheappropriaterigortothetechnicalitiesof
recordingandmeasuringtherequirements.
Perhapsthegreatestchangetocomealongsincethefirst
editionhasbeenthearrivalofagilemethods,accompaniedby
somewonderfultechnologicaladvances.Agilemethodshave
influencedthewaypeopledevelopsoftware,withtheresult
beingthatgreateremphasisisplacedonclosecustomer
relationships,andlessemphasisisplacedondocumentation.
Weheartilyapplaudthisadvance.However,wehavealsoseen
toomanypeople,who,inthenameofagility,rushtoasolution

withoutfirstunderstandingtherealbusinessproblemtobe
solved.
This,then,istheroleofrequirementsintheagileworld:to
ensurethatwehearnotonlyonecustomer'svoice,butalsothe
voicesoftheotherstakeholdersthosewithsomevaluetoaddto
therequirementsfortheproduct.Agilerequirementsanalysts
ensurethattheworkisconsidered,notjusttheproduct,and
thatthenonfunctionalrequirementsarestudied,notlefttothe
whimoftheprogrammer.
Agilemethodshavebroughtwiththemahealthydisdainfor
documentation.Weagreewiththisview.Throughoutthis
secondeditionweurgeyoutoconsiderthebenefitbefore
committinganythingtowriting.Butwhilewesuggest
sometimesyoucandevelopsoftwaresuccessfullywithout
formallywrittenrequirements,weneversuggestyoucandoit
withoutunderstandingtherequirements.
Theemphasisoniterativedevelopmentmeansthatthe
requirements"phase"isnolongercompletedbeforebuilding
begins.Thedrivetowardshort,sharpreleasecyclesmeans
requirementsanalystsgetfeedbackontheirrequirements
effortsmorequickly.Stakeholdersreceivepositive
reinforcementwhentheyseethetimetheyinvestin
requirementspaidbackwithprogressiveversionsofworking
softwarethatdoeswhattheyexpect,andwhattheyneed.
Technologicaladvanceshavechangedrequirementsgathering.
Blogsandwikismeanthatrequirementsanalystscangather
theirrequirementsinformallyanditerativelyusingthe
convenienceofnetworkingwiththeirstakeholders.Desktop

videoconferencingandinstantmessagingmeancloser,quicker
communicationwithstakeholders,whichis,ofcourse,
necessaryforgoodrequirementsgathering.
Thegapbetweenwhatwewrotein1999andwhatwefound
ourselvesdoingwhengatheringrequirementsgraduallygrew


wider,untilweknewitwastimetoupdateourbook.The
volumethatyouholdinyourhandsistheresultofthelastfew
yearsofourworkandteaching.Wetrustyoufinditinteresting,
enlightening,anduseful.
Fortheconvenienceofthereader,throughout
thisbookwehaveused"he"torefertoboth
genders.Theauthors(onemaleandone
female)findtheuseof"heorshe"disruptive
andawkward.


ForewordtotheFirstEdition
ItisalmosttenyearsnowsinceDonGauseandIpublished
ExploringRequirements:QualityBeforeDesign.Ourbook
isindeedanexploration,asurveyofhumanprocessesthatcan
beusedingatheringcomplete,correct,andcommunicable
requirementsforasoftwaresystem,oranyotherkindof
product.
Theoperativewordinthisdescriptionis"can,"foroverthis
decadethemostfrequentquestionmyclientshaveaskedis,
"HowcanIassemblethesediverseprocessesintoa
comprehensiverequirementsprocessforourinformation
systems?"

Gause,DonaldC.,andGeraldM.Weinberg.
ExploringRequirements:QualityBeforeDesign.
DorsetHouse,1989.

Atlonglast,JamesandSuzanneRobertsonhaveprovidedan
answerIcanconscientiouslygivetomyclients.Masteringthe
RequirementsProcessshows,stepbystep,templateby
template,examplebyexample,onewell-testedwayto
assembleacomplete,comprehensiverequirementsprocess.
Onewatchwordoftheirprocessis"reasonableness."Inother
words,everypartoftheprocessmakessense,eventopeople
whoarenotveryexperiencedwithrequirementswork.When
introducingthiskindofstructuretoanorganization,


reasonablenesstranslatesintoeasieracceptanceanessential
attributewhensomanycomplicatedprocessesaretriedand
rejected.

Robertson,James,andsuzanneRobertson.
CompleteSystemsAnanalysis:TheWorkbook,the
textbook,theAnswer.DorsetHouse,1998.

TheprocesstheydescribeistheVolereapproach,whichthey
developedasanoutcomeofmanyyearshelpingclientsto
improvetheirrequirements.AsidefromtheVolereapproach
itself,JamesandSuzannecontributetheirsuperbteachingskills
totheformidabletaskfacinganyonewhowishestodevelop
requirementsanddothemwell.

TheRobertsons'teachingskillsarewellknowntotheirseminar
studentsaswellastofansoftheirCompleteSystems
Analysisbooks.MasteringtheRequirementsProcess
providesamuch-requestedfrontendfortheiranalysisbooksor
foranyone'sanalysisbooks,forthatmatter.
Wecanuseallthegoodbooksonrequirementswecanget,and
thisisoneofthem!
GeraldM.Weinberg
www.geraldmweinberg.com
Febraury1999


Acknowledgments
Writingabookishard.Withoutthehelpandencouragementof
others,itwouldbenearlyimpossible,atleastfortheseauthors.
Wewouldliketotakeafewlinestotellyouwhohelpedand
encouragedandmadeitpossible.
AndyMcDonaldofVaisalawasgenerouswithhistime,andgave
usconsiderabletechnicalinput.Wehastentoaddthatthe
IceBreakerproductinthisbookisonlyadistantrelationto
Vaisala'sIceCastsystems.TheVaisalaUserGroup,ofwhichE.
M.Kennedyholdsthechair,alsoprovidedvaluabletechnical
input.
Thanksareduetothetechnicalreviewerswhogaveuptheir
timetowadethroughsomefairlyincomprehensiblestuff.Mike
Russell,SusannahFinzi,NeilMaiden,TimLister,andBashar
Nuseibehalldeservehonorablementions.
Wewouldliketoacknowledgeourfellowprincipalsatthe
AtlanticSystemsGuildTomDeMarco,PeterHruschka,TimLister,
SteveMcMenamin,andJohnPalmerfortheirhelp,guidance,and

incredulouslooksovertheyears.
ThestaffatPearsonEducationcontributed.SallyMortimore,
AlisonBirtwell,andDylanReisenbergerweregenerousand
skillful,andusedsuchpersuasivelanguagewheneverwespoke
aboutextendingthedeadline.
Forthesecondedition,PeterGordonprovidedguidanceand
persuasionatexactlytherighttimes.KimBoedigheimer,John
Fuller,andLaraWysongwereinvaluableatsteeringusthrough
thepublishingprocess.JillHobbstamedourfaultygrammar
andpunctuation,andmadethistextreadable.Thetechnical
inputofIanAlexander,EarlBeede,CapersJones,Chuck
Pfleeger,andTonyWassermangoesfarbeyondvaluable.Thank


you,gentlemen,foryourinsights.Andwehastentoaddthat
anyremainingtechnicalerrorsareoursandoursalone.
Andfinallywethankthestudentsatourseminarsandour
consultingclients.Theircomments,theirinsistenceonhaving
thingsclearlyexplained,theirinsights,andtheirfeedbackhave
allmadesomedifference,nomatterhowindirect,tothisbook.
Thankyou,everybody.
JamesandSuzanneRobertsonLondon,January2006


Chapter1.WhatAreRequirements?
inwhichweconsiderwhyweareinterestedin
requirements
Themostusefulproductsarethosewherethedevelopershave
understoodwhattheproductisintendedtoaccomplishforits
usersandhowitmustaccomplishthatpurpose.Tounderstand

thesethings,youmustunderstandwhatkindofworktheusers
wanttodoandhowtheproductwillaffectthatworkandfitinto
theorganization'sgoals.Whattheproductdoesforitsusers
andwhichconstraintsitmustsatisfyinthiscontextarethe
product'srequirements.Apartfromafewfortuitousaccidents,
noproducthaseversucceededwithoutpriorunderstandingof
itsrequirements.Itdoesnotmatterwhatkindofworktheuser
wishestodo,beitscientific,commercial,e-commerce,orword
processing.Nordoesitmatterwhichprogramminglanguageor
developmenttoolsareusedtoconstructtheproduct.The
developmentprocesswhetheragile,eXtremeProgramming,
prototyping,theRationalUnifiedProcess,oranyothermethodis
irrelevanttotheneedforunderstandingtherequirements.One
factalwaysemerges:Youmustcometothecorrect
understandingoftherequirements,andhaveyourclient
understandthem,oryourproductoryourprojectwillfail.

"...evenperfectprogramverificationcanonlyestablishthataprogram
meetsitsspecification.Thehardestpartofthesoftwaretaskisarrivingat
acompleteandconsistentspecification,andmuchoftheessenceof
buildingaprogramisinfactthedebuggingofthespecification."
Source:FredBrooks,NoSilverBullet:EssenceandAccidentsofSoftware
Engineering


Thisbookdiscusseshowtodiscovertherequirementsand
determinetheirprecisenature.Moreover,itexplainshowyou
willknowthatyouhavefoundthecorrectrequirementsand
howtocommunicatethem.
Anyimportantendeavorneedssomekindoforderlyprocess.

Moreover,thepeoplewhoareactiveintheprocessmustbe
abletoseewhydifferentpartsoftheprocessareimportant,
andwhichpartscarryparticularsignificancefortheirparticular
project.ThisbookpresentsVolereaprocess,arequirements
specificationtemplate,andasetoftechniquesforgathering,
confirming,organizing,anddocumentingtherequirementsfora
product.Thisprocessandtemplatecanbeindeed,have
beenusedforanykindofproductorproject.Sincethefirst
versionofVolerewasreleasedin1995,ithasbeenusedby
thousandsofprojectsinhundredsofcountries.
Therequirementsprocess,aswedescribeithere,isathorough
explorationoftheintendedproductwiththeintentionof
discoveringinsomecases,inventingthefunctionalityand
behavioroftheproduct.Theoutputofthisrequirements
processisawrittendescriptionoftherequirementstobeused
asinputtothedesignoftheproduct.
Requirementsarenotmeanttoplaceanextraburdenonyour
project.Instead,theyaretheretomakeyourprojectrunmore
smoothly.Thereislittlepointinattemptingtoconstructa
productunlessyouknowwhatyouaretryingtobuild.Thisdoes
notmeanthatyourunderstandingmustalwaysbeperfect
beforeyoustartconstruction,anditdoesnotmeanthatallthe
requirementshavetobewrittendown.Butitdoesmeanthatif
youintendtodeliverusefulandusableproductsatthelowest
costtoyourorganization,youmustpayattentionto
requirements.
Thisbookdiscusseshowyoucancometoanunderstandingof
therequirementsandhowyoumightwritethemdownsothat
theconstructors,andthefuturegenerationsofmaintenance

people,canunderstandthem.
Requirementsareusuallyexpressedasanabstraction.Thatis,
theyareexpressedinatechnologicallyneutralwaysoasto
intentionallyavoidinfluencingthedesignofthesolution.The
requirementsareapurestatementofbusinessneeds,without
anyimplementationbias.Theroleofproductdesignisto
translatetherequirementsintoaplantobuildsomephysical
realitythatwill,intherealworld,dowhatisneeded.Product
designdetermineswhichdevicesaretobeused,whichsoftware
componentsarenecessary,andhowtheyaretobeconstructed.
Itisimportanttothesuccessoftheproductthatfinaldesign
decisionsarenottakenbeforetherelevantrequirementsare
known.Itisequallyimportanttonotethatawell-organized
requirementsprocessmeansthatrequirements,design,and
implementationcanbedoneasanumberofiterativeloops.
Eachiterationproducessomeusablefunctionality.Figure1.1
depictstherequirementsprocessaspartoftheongoing
developmentlifecycle.

Figure1.1.
Thediagramillustratestheroleofrequirementsinthe
developmentlifecycle.TheRequirementsGatheringprocess
studiestheworkandthenspecifiestheproductthatmosthelps
withthatwork.Asanoutcomeofthisprocess,the
RequirementsSpecificationprovidesacompletedescriptionof
theneededfunctionalityandbehavioroftheproduct.System
Modelingproducesworkingmodelsofthefunctionsanddata
neededbytheproduct,aswellasmodelsoftheworkto
supporttherequirementsprocess.ProductDesignturnsthe

abstractspecificationintoadesignsuitablefortherealworld.
Oncebuilt,theproductisused,andthisreal-worldexperience
inevitablyprovidesmorenewrequirements.Thisdiagram
shouldbereadasiterative.Thatis,thecompleteRequirements
Specificationdoesnothavetobeproducedbeforedesignand