2017520 RequirementsEngineering

Page1

Page2

RequirementsEngineering

https://translate.googleusercontent.com/translate_f 1/211
2017520 RequirementsEngineering

Page3

wwwwww

https://translate.googleusercontent.com/translate_f 2/211
2017520 RequirementsEngineering

Page4

ElizabethHullKenJackson
JeremyDick

RequirementsEngineering

https://translate.googleusercontent.com/translate_f 3/211
2017520 RequirementsEngineering

Page5

ElizabethHull,BSc,PhD,CEng,FBCS JeremyDick,BSc(Eng),ACGI,
SchoolofComputingandMathematics DPhil,DIC,MA
UniversityofUlster IntegrateSystemsEngineeringLtd
Newtownabbey,CoAntrim Bath
UK UK
mec.hull@ulst.ac.uk jeremy.dick@integrate.biz

KenJackson,BSc,MSc,MBCS
UniversityofUlster
Newtownabbey,CoAntrim
UK
kenjackson@fastmail.fm

ISBN9781849964043 eISBN9781849964050
DOI10.1007/9781849964050
SpringerLondonDordrechtHeidelbergNewYork

BritishLibraryCataloguinginPublicationData
AcataloguerecordforthisbookisavailablefromtheBritishLibrary

LibraryofCongressControlNumber:2010937427

SpringerVerlagLondonLimited2011
Apartfromanyfairdealingforthepurposesofresearchorprivatestudy,orcriticismorreview,as
permittedundertheCopyright,DesignsandPatentsAct1988,thispublicationmayonlybereproduced,
storedortransmitted,inanyformorbyanymeans,withthepriorpermissioninwritingofthepublishers,
orinthecaseofreprographicreproductioninaccordancewiththetermsoflicensesissuedbythe
CopyrightLicensingAgency.Enquiriesconcerningreproductionoutsidethosetermsshouldbesentto
thepublishers.
Theuseofregisterednames,trademarks,etc.,inthispublicationdoesnotimply,evenintheabsenceof
aspecificstatement,thatsuchnamesareexemptfromtherelevantlawsandregulationsandtherefore
freeforgeneraluse.
Thepublishermakesnorepresentation,expressorimplied,withregardtotheaccuracyoftheinformation
containedinthisbookandcannotacceptanylegalresponsibilityorliabilityforanyerrorsoromissions
thatmaybemade.

Printedonacidfreepaper

SpringerispartofSpringerScience+BusinessMedia(www.springer.com)

https://translate.googleusercontent.com/translate_f 4/211
2017520 RequirementsEngineering

Page6

Wewouldliketodedicatethisbookasfollows:

TomylateparentsJohnandEdnaHull
ElizabethHull
TomywifeChris,
TomychildrenandtheirspousesKate,Stef,
Andy,AmyandPete
andtomygrandchildrenLizzie,Alice,Emily
andAnnabel
KenJackson
Tomywife
Yvonneandtomychildren
Sebastian,Timothy,Angus,RobinandFelicity
JeremyDick

Page7

https://translate.googleusercontent.com/translate_f 5/211
2017520 RequirementsEngineering

wwwwww

Page8

https://translate.googleusercontent.com/translate_f 6/211
2017520 RequirementsEngineering

PrefacetotheThirdEdition

Inourdesiretokeepthematerialinthisbookcurrent,themaindriverincreatinga
neweditionhasbeentoadapttothelatestreleaseofDOORS.Sincethepublication
ofEdition2,TelelogicthedeveloperofDOORShasbeenacquiredbyIBM,and
thetoolhasbecomepartoftheIBM/Rationalstable.Whilethebasicfunctionsof
thetoolremainunchanged,thelookandfeelhasadvancedconsiderably.Therefore,
Chapter9hasbeenupdatedforDOORSversion9.2.
Atthesametime,wefelttheneedtoprovideamoreexplicitdefinitionof
RequirementsEngineering.Insearchingtheliterature,wecouldnotfindasatisfac
torydefinition,andwehaveaddressedthisinChapter1.
Apartfromthis,thereisanexpandeddescriptionofProductFamilyManagement
inChapter8,andavarietyofsmallcorrectionsthroughout.
Wehopeourreadersstudentsandpractitionerscontinuetofindthisavalu
abletextinadvancingtheirunderstandingofthetopic.

April2010 ElizabethHull
KenJackson
JeremyDick

vii

Page9

wwwwww

https://translate.googleusercontent.com/translate_f 7/211
2017520 RequirementsEngineering

Page10

PrefacetotheSecondEdition

https://translate.googleusercontent.com/translate_f 8/211
2017520 RequirementsEngineering

Thissecondeditionfollowsquicklyonthefirsteditionandisanindicationofhow
fastthesubjectischanginganddeveloping.Inthepast2yearstherehavebeen
significantadvancesandthesearereflectedinthisnewedition.
Essentially,thisisanupdatethatplacesmoreemphasisonmodellingbydescrib
ingagreaterrangeofapproachestosystemmodelling.ItintroducestheUML2,
whichistherecentstandardapprovedbytheOMG.Thereisalsoanenhanced
discussionontherelationshipbetweenrequirementsmanagementandmodelling,
whichrelateswelltotheconceptofrichtraceability.
ThechapterontherequirementsmanagementtoolDOORShasbeenrevisedto
useVersion7ofthetoolandthisiscomplementedwithexamplestakenfromthe
DOORS/Analysttoolwhichdemonstrateshowtheconceptsofmodellingcanbe
capturedandcreatedwithinDOORS.
Thetextisstillaimedatstudentsandpractitionersofsystemsengineeringwho
arekeentogainknowledgeofusingrequirementsengineeringforsystem
development.
Asbefore,awebsitesupportingadditionalmaterialisavailableat:
http://www.requirementsengineering.info

June2004 ElizabethHull
KenJackson
JeremyDick

ix

Page11

wwwwww

https://translate.googleusercontent.com/translate_f 9/211
2017520 RequirementsEngineering

Page12

PrefacetotheFirstEdition

https://translate.googleusercontent.com/translate_f 10/211
2017520 RequirementsEngineering

RequirementsEngineeringiscommonsense,butitisperceivedtobedifficultand
isnotwellunderstood.Forthesereasonsitisgenerallynotverywelldone.The
everincreasingpressuresonanorganisationareoftengivenasthemainreasonsfor
notintroducingamoredisciplinedapproachtorequirementsengineering,butits
aimwillbetodothejobproperly,sothetaskoftherequirementsengineeristo
workouthowbesttohelptheorganisationachieveitsgoal.
Systemsengineeringiscriticalintodaysindustryandrequirementsengineering
isanimportantstageofthatoverallprocess.Agoodprocessiskeytorequirements
engineeringitdetermineshowefficientlyandrapidlyproductscanbegenerated.
Thisisparticularlyimportantinaglobalcompetitivemarketwherethetimeto
marketandmeetingstakeholderrequirementsarethekeysuccessfactors.
Requirementsengineeringisalsoaboutmanagementandhenceissuesinrela
tiontorequirementsandmanagementblendtoshowhowrequirementscanbeused
tomanagesystemsdevelopment.
Thebookisconcernedwithengineeringrequirementsandhowsystemsengi
neersmaybehelpedtocreatebetterrequirements.Agenericprocessispresented
whichassiststhereaderingainingagoodunderstandingoftheessenceofrequire
mentsengineering.Theprocessistheninstantiatedfortheproblemandsolution
domainsofdevelopment.Thebookalsoaddressestheconceptofsystemmodelling
andpresentsvarioustechniquesandmethodswhicharewidelyused.Animportant
featureofthebookisthepresentationofapproachestotraceability,thewayin
whichitiscapturedanddiscussesmetricswhichcanbederivedfromtraceability.
FinallythebookpresentsanoverviewofDOORSwhichisatoolforrequirements
management.Acasestudyisusedtoillustratetheprocesspresentedinthebook
andthefeaturesofthetool.
Thisbookshouldbereadbythosesystemsengineers(requirementsengineers)in
industry,who,beingpractitionersarekeentogainknowledgeofusingrequirements
engineeringforsystemdevelopment.Thebookwillalsobeofinteresttofinalyear
undergraduatestudentsinComputerScience,SoftwareEngineeringandSystems
EngineeringstudyingacourseinRequirementsEngineeringandalsotopostgraduate
researchstudentsinComputerScienceormoregenerallyinEngineering.

xi

Page13
xii PrefacetotheFirstEdition

TheapproachtakeninthebookisbasedoncurrentresearchinRequirements
Engineering,howeverithasnotonlytakentheacademicviewbuthasalsobuilt
substantiallyoncurrentexperienceofworkinginindustrytoenablesystemengi
neerstomanagerequirements(andprojects)moresuccessfully.Itprovidesasnap
shot,inthisrapidlyevolvingsubject,ofwhatweseeasbestpracticeinRequirements
Engineeringtoday.
Awebsitesupportingadditionalmaterialforthebookcanbefoundat:http://
www.requirementsengineering.info/

May2002 ElizabethHull
KenJackson
JeremyDick

https://translate.googleusercontent.com/translate_f 11/211
2017520 RequirementsEngineering

Page14

Acknowledgements

Thanksareduetoanumberofindividualsandorganisationswhohelpedinvarious
ways:
RichardStevens,whoinspireduswithhisworkonrequirementsmanagement
andwholaidthefoundationfortheworkinthisbook.Hewasafounderof

https://translate.googleusercontent.com/translate_f 12/211
2017520 RequirementsEngineering

RequirementsEngineeringLtd.(laterQualitySystemsandSoftwareLtd.),which
developedtheDOORStool.
LesOliver(whoworkedforAstriumatthetime)forassistanceinthedevelop
mentofstatechartsforagreement,qualificationandsatisfaction.
PraxisCriticalSystems(nowAltranPraxis)fortheinitialconceptofdesign
justificationwhichbecomeRichTraceability.
KeithCollyer,JillBurnettandothercolleaguesofTelelogicLtd.forcontribu
tionstoideaspresentedinthisbookandforreviews,comments,suggestionsand
encouragement.

xiii

Page15

wwwwww

https://translate.googleusercontent.com/translate_f 13/211
2017520 RequirementsEngineering

Page16

Contents

1Introduction............................................................................................... 1
1.1IntroductiontoRequirements.......................................................... 1
1.2IntroductiontoSystemsEngineering............................................... 4
1.3DefiningRequirementsEngineering................................................ 6
1.3.1DefinitionofaRequirement................................................. 6
1.3.2DefinitionofaStakeholder.................................................. 7
1.3.3DefinitionofRequirementsEngineering............................. 7
1.4RequirementsandQuality................................................................ 9
1.5RequirementsandtheLifecycle.......................................................10
https://translate.googleusercontent.com/translate_f 14/211
2017520 RequirementsEngineering

1.6RequirementsTracing......................................................................13
1.7RequirementsandModelling...........................................................17
1.8RequirementsandTesting................................................................19
1.9RequirementsintheProblemand
SolutionDomains............................................................................20
1.10HowtoReadthisBook....................................................................22

2AGenericProcessforRequirementsEngineering.................................25
2.1Introduction......................................................................................25
2.2DevelopingSystems.........................................................................25
2.3GenericProcessContext..................................................................28
2.3.1InputRequirementsandDerivedRequirements..................29
2.3.2AcceptanceCriteriaandQualificationStrategy..................30
2.4GenericProcessIntroduction...........................................................31
2.4.1IdealDevelopment...............................................................31
2.4.2DevelopmentintheContextofChange...............................31
2.5GenericProcessInformationModel................................................33
2.5.1InformationClasses..............................................................34
2.5.2AgreementState...................................................................36
2.5.3QualificationState................................................................37
2.5.4SatisfactionState..................................................................37
2.5.5InformationModelConstraints............................................38

xv

Page17
xvi Contents

2.6GenericProcessDetails...................................................................38
2.6.1AgreementProcess...............................................................38
2.6.2AnalyseandModel...............................................................40
2.6.3DeriveRequirementsandQualificationStrategy
Fig.2.1.3PortraystheProcessforDerivingRequirements
andQualificationStrategy....................................................42
2.7Summary..........................................................................................45

3SystemModellingforRequirementsEngineering.................................47
3.1Introduction......................................................................................47
3.2RepresentationsforRequirementsEngineering...............................48
3.2.1DataFlowDiagrams............................................................48
3.2.2EntityRelationshipDiagrams..............................................54
3.2.3Statecharts............................................................................55
3.2.4ObjectOrientedApproaches................................................56
3.3Methods............................................................................................58
3.3.1ViewpointMethods..............................................................59
3.3.2ObjectOrientedMethods.....................................................67
3.3.3TheUMLNotation...............................................................70
3.3.4FormalMethods...................................................................75
3.4Summary..........................................................................................76

4WritingandReviewingRequirements....................................................77
4.1Introduction......................................................................................77
4.2RequirementsforRequirements......................................................78

https://translate.googleusercontent.com/translate_f 15/211
2017520 RequirementsEngineering

4.3StructuringRequirementsDocuments.............................................79
4.4KeyRequirements............................................................................80
4.5UsingAttributes...............................................................................80
4.6EnsuringConsistencyAcrossRequirements...................................82
4.7ValueofaRequirement....................................................................83
4.8TheLanguageofRequirements.......................................................84
4.9RequirementBoilerplates.................................................................85
4.10GranularityofRequirements............................................................88
4.11CriteriaforWritingRequirementsStatements.................................89
4.12Summary..........................................................................................90

5RequirementsEngineeringintheProblemDomain..............................93
5.1WhatistheProblemDomain?.........................................................93
5.2InstantiatingtheGenericProcess.....................................................94
5.3AgreeRequirementswithCustomer................................................95
5.4Analyse&Model.............................................................................96
5.4.1IdentifyStakeholders...........................................................96
5.4.2CreateUseScenarios...........................................................98
5.4.3ScopingtheSystem..............................................................101
5.5DeriveRequirements.......................................................................102
5.5.1DefineStructure...................................................................102
5.5.2CaptureRequirements.........................................................106

Page18
Contents xvii

5.5.3DefineAcceptanceCriteria..................................................112
5.5.4DefineQualificationStrategy..............................................113
5.6Summary..........................................................................................114

6RequirementsEngineeringintheSolutionDomain..............................115
6.1WhatistheSolutionDomain...........................................................115
6.2EngineeringRequirementsfromStakeholderRequirements
toSystemRequirements..................................................................116
6.2.1ProducingtheSystemModel...............................................117
6.2.2CreatingSystemModelstoDerive
SystemRequirements..........................................................118
6.2.3BankingExample.................................................................123
6.2.4CarExample........................................................................126
6.2.5DerivingRequirementsfromaSystemModel....................131
6.2.6AgreeingtheSystemRequirements
withtheDesignTeam..........................................................132
6.3EngineeringRequirementsfromSystem
RequirementstoSubsystems...........................................................133
6.3.1CreatingaSystemArchitectureModel................................134
6.3.2DerivingRequirementsfromanArchitectural
DesignModel.......................................................................134
6.4OtherTransformationsUsing
aDesignArchitecture.......................................................................135
6.5Summary..........................................................................................136

7AdvancedTraceability..............................................................................137
7.1Introduction......................................................................................137
https://translate.googleusercontent.com/translate_f 16/211
2017520 RequirementsEngineering

7.2ElementaryTraceability...................................................................137
7.3SatisfactionArguments....................................................................139
7.4RequirementsAllocation..................................................................143
7.5ReviewingTraceability....................................................................144
7.6TheLanguageofSatisfactionArguments........................................144
7.7RichTraceabilityAnalysis...............................................................145
7.8RichTraceabilityforQualification..................................................146
7.9ImplementingRichTraceability......................................................146
7.9.1SingleLayerRichTraceability............................................146
7.9.2MultiLayerRichTraceability.............................................147
7.10DesignDocuments...........................................................................147
7.11MetricsforTraceability....................................................................152
7.11.1Breadth...............................................................................153
7.11.2Depth..................................................................................153
7.11.3Growth...............................................................................153
7.11.4Balance...............................................................................154
7.11.5LatentChange....................................................................155
7.12Summary..........................................................................................158

Page19
xviii Contents

8ManagementAspectsofRequirementsEngineering.............................159
8.1IntroductiontoManagement............................................................159
8.2RequirementsManagementProblems.............................................160
8.2.1SummaryofRequirementManagementProblems..............162
8.3ManagingRequirementsinanAcquisitionOrganisation................162
8.3.1Planning...............................................................................162
8.3.2Monitoring...........................................................................165
8.3.3Changes................................................................................165
8.4SupplierOrganisations.....................................................................167
8.4.1BidManagement..................................................................167
8.4.2Development........................................................................171
8.5ProductOrganisations......................................................................173
8.5.1Planning...............................................................................173
8.5.2Monitoring...........................................................................177
8.5.3Changes................................................................................178
8.6Summary..........................................................................................179
8.6.1Planning...............................................................................179
8.6.2Monitoring...........................................................................179
8.6.3Changes................................................................................180

9DOORS:ATooltoManageRequirements.............................................181
9.1Introduction......................................................................................181
9.2TheCaseforRequirementsManagement........................................182
9.3DOORSArchitecture.......................................................................182
9.4Projects,ModulesandObjects.........................................................183
9.4.1DOORSDatabaseWindow..................................................183
9.4.2FormalModules...................................................................183
9.4.3Objects.................................................................................186
9.4.4GraphicalObjects................................................................189
9.4.5Tables...................................................................................189
https://translate.googleusercontent.com/translate_f 17/211
2017520 RequirementsEngineering

9.5HistoryandVersionControl............................................................190
9.5.1History.................................................................................190
9.5.2Baselining............................................................................190
9.6AttributesandViews........................................................................191
9.6.1Attributes..............................................................................191
9.6.2Views...................................................................................192
9.7Traceability......................................................................................192
9.7.1Links....................................................................................192
9.7.2TraceabilityReports.............................................................193
9.8ImportandExport............................................................................195
9.9UMLModellingwithDOORS/Analyst...........................................197
9.10Summary..........................................................................................198

Bibliography....................................................................................................199

Index.................................................................................................................203

Page21
Page20

Chapter1
Introduction

Thereisnofairwindforonewhoknowsnotwhitherheis
bound.

LuciusAnnaeusSeneca,philosopher,365AD

1.1IntroductiontoRequirements

Ifeversystemsdevelopmentprojectsneededafairwind,theycertainlydoso
today.Fastchangingtechnologyandincreasedcompetitionareplacingever
increasingpressureonthedevelopmentprocess.Effectiverequirementsengineering
liesattheheartofanorganisationsabilitytoguidetheshipandtokeeppacewith
therisingtideofcomplexity.
Softwareiscurrentlythedominantforceofchangeofnewproducts.Thetrend
isdrivenbythreekeyfactors:

Arbitrarycomplexity.Themostcomplexsystemstendtobethosewithsoftware,
oftenintegrateddeepinsidethesystemscomponents.Thecomplexityofsuch
productsislimitedonlybytheimaginationofthosewhoconceivethem.
Instantdistribution.Todayacompanycanthinkofanewproduct,implementitin
https://translate.googleusercontent.com/translate_f 18/211
2017520 RequirementsEngineering

software,andrapidlydistributeitaroundtheworld.Forexample,acarmanu
facturercanimprovethesoftwareinitsdiagnosticsystem,andthentransmitit
electronicallyaroundtheworldtotensofthousandsofcarshowroomsinaday.
Offtheshelfcomponents.Systemsarenowconstructedfromboughtintechnology
andreadymadecomponentswithacorrespondingreductionintheproduct
developmentcycle.

Thenetimpactofthesetrendsisasuddenintensityofcompetition,andtheabilityto
monopolisetherewardsfromthenewtechnologywithoutneedinglargefactories.The
resultispressuretoreducethedevelopmentcycleandthetimetodeploytechnology.
Buttimetomarketisnotsufficient.Therealgoalistimetomarketwiththeright
product.Establishingtherequirementsenablesustoagreeonandvisualisetheright
product.Avitalpartofthesystemsengineeringprocess,requirementsengineeringfirst

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_1, 1
SpringerVerlagLondonLimited2011

Page22
2 1Introduction

definestheproblemscopeandthenlinksallsubsequentdevelopmentinformationtoit.
Onlyinthiswaycanoneexpecttocontrolanddirectprojectactivitymanagingthe
developmentofasolutionthatisbothappropriateandcosteffective.
Requirementsarethebasisforeveryproject,definingwhatthestakeholdersusers,
customers,suppliers,developers,businessesinapotentialnewsystemneedfromit,
andalsowhatthesystemmustdoinordertosatisfythatneed.Tobewellunderstood
byeverybodytheyaregenerallyexpressedinnaturallanguageandhereinliesthechal
lenge:tocapturetheneedorproblemcompletelyandunambiguouslywithoutresorting
tospecialistjargonorconventions.Oncecommunicatedandagreed,requirementsdrive
theprojectactivity.Howevertheneedsofthestakeholdersmaybemanyandvaried,
andmayindeedconflict.Theseneedsmaynotbeclearlydefinedatthestart,maybe
constrainedbyfactorsoutsidetheircontrolormaybeinfluencedbyothergoalswhich
themselveschangeinthecourseoftime.Withoutarelativelystablerequirementsbase
adevelopmentprojectcanonlyflounder.Itislikesettingoffonaseajourneywithout
anyideaofthedestinationandwithnonavigationchart.Requirementsprovideboththe
navigationchartandthemeansofsteeringtowardstheselecteddestination.
Agreedrequirementsprovidethebasisforplanningthedevelopmentofasystem
andacceptingitoncompletion.Theyareessentialwhensensibleandinformed
tradeoffshavetobemadeandtheyarealsovitalwhen,asinevitablyhappens,
changesarecalledforduringthedevelopmentprocess.Howcantheimpactofa
changebeassessedwithoutanadequatelydetailedmodelofthepriorsystem?
Otherwisewhatistheretoreverttoifthechangeneedstobeunwound?
Evenastheproblemtobesolvedandpotentialsolutionsaredefinedonemust
assesstherisksoffailingtoprovideasatisfactorysolution.Fewsponsorsorstake
holderswillsupportproductorsystemsdevelopmentwithoutaconvincingrisk
managementstrategy.Requirementsenablethemanagementofrisksfromtheearliest
possiblepointindevelopment.Risksraisedagainstrequirementscanbetracked,
theirimpactassessed,andtheeffectsofmitigationandfallbackplansunderstood,
longbeforesubstantialdevelopmentcostshavebeenincurred.
Requirementsthereforeformthebasisfor:

Projectplanning
Riskmanagement
Acceptancetesting
Tradeoff

https://translate.googleusercontent.com/translate_f 19/211
2017520 RequirementsEngineering

Changecontrol
ThemostcommonreasonsforprojectfailuresarenottechnicalandTable1.1iden
tifiesthemainreasonswhyprojectsfail.Thedataisdrawnfromsurveysconducted
bytheStandishGroupin1995and1996,andshowsthepercentageofprojectsthat
statedvariousreasonsforprojectfailure.Thosemarkedwithanasteriskaredirectly
relatedtorequirements.
Theproblemsfallintothreemaincategories:

Requirementseitherpoorlyorganised,poorlyexpressed,weaklyrelatedtostake
holders,changingtoorapidly,orunnecessaryunrealisticexpectations

Page23
1.1IntroductiontoRequirements 3

Table1.1Reasonsforprojectfailure
*Incompleterequirements 13.1%
*Lackofuserinvolvement 12.4%
Lackofresources 10.6%
*Unrealisticexpectations 9.9%
Lackofexecutivesupport 9.3%
*Changingrequirements/specifications 8.7%
Lackofplanning 8.1%
*Didntneeditanylonger 7.5%
StandishGroup1995&1996
ScientificAmerican,Sept.1994

Table1.2Projectsuccessfactors
*Userinvolvement 15.9%
Managementsupport 13.9%
*Clearstatementofrequirements 13.0%
Properplanning 9.6%
*Realisticexpectations 8.2%
Smallermilestones 7.7%
Competentstaff 7.2%
*Ownership 5.3%
StandishGroup1995&1996
ScientificAmerican,Sept.1994

Managementproblemsofresourcesfailuretohaveenoughmoney,andlackof
support,orfailuretoimposeproperdisciplineandplanning,manyofthesearise
frompoorrequirementscontrol
Politicswhichcontributestothefirsttwoproblems
Allthesefactorscanbeaddressedatfairlylowcost.
Projectsuccessfactorsarenotquitetheinverseofthefailurefactors,butascanbe
seeninTable1.2,Managementsupportandproperplanningareclearlyseenas
importantherethelargertheproject,andthelongeritsschedule,thehigherthe
chanceoffailure(ScientificAmerican,Sept.1994).
Thisbookconsidersanengineeringapproachtorequirementsingeneraland
requirementsmanagementinparticular.Itexplainsthedifferencesbetweenstake
holderrequirementsandsystemrequirementsandindicateshowrequirementscanbe
usedtomanagesystemdevelopment.Italsoshowshowtraceabilityfromstakeholder
https://translate.googleusercontent.com/translate_f 20/211
2017520 RequirementsEngineering

requirementsthroughsystemrequirementstodesigncanbeusedtomeasureprogress,
managechangeandassessrisks.Itexposesthereadertothosequalitiesofrequire
mentsthatmakethemsuitableforvalidatingandverifyingdesignsandsolutions,and
stressestheneedtoproducedesignsthatcanbeintegratedandtestedeasily.
Requirementsmanagementhasimportantinterfacestoprojectmanagement,
whichisrecognisedinthebookthroughthepresenceofChapter8,Management
AspectsofRequirementsEngineering.

Page24
4 1Introduction

1.2IntroductiontoSystemsEngineering

Thisbookisnotjustaboutrequirementsforsoftware.Theprinciplesandpractice
ofrequirementsengineeringapplytocompletesystemsinwhichsoftwaremayonly
playasmallpart.
Forexample,considerarailwaysystemsuchastheWestCoastMainlinefrom
LondontoGlasgow.Ahighlevelrequirementonthesystemmaybetoachievea
journeytimefromEustonStationinLondontoGlasgowinScotlandinlessthan
250min.Satisfactionofthissinglerequirementarisesfromthecoordinatedinterac
tionofeverymajorcomponentofthesystem:

Thetrains,andtheirspeed
Thetracks,andtheirabilitytosupporthighspeedtrains
Thestationsandstationstaff,andthewaitingtimetheyimposeonthetrains
Thedrivers,andtheirabilitytocontrolthetrains
Thesignallingsubsystems
Thetraincontrolanddetectionsubsystems
Thepowerdeliverysubsystems

Whilethesoftwareinthesignallingandcontrolsubsystemsplaysavitalpartin
achievingthisrequirement,itcannotdeliveralone.Thecompletesolutioninvolves
thewholesystem.Infact,mostrequirementsaresatisfiedbythepropertiesthat
emergefromthewaythesystemasawholebehaves.
Whatthenismeantbyasystem?

System:acollectionofcomponentsmachine,softwareandhumanwhich
cooperateinanorganisedwaytoachievesomedesiredresulttherequirements.

Thussystemsincludepeople.IntheWestCoastMainline,thedriversandstation
staffthetrainingtheyreceiveandtheprocedurestheyusearejustasimportant
asthesoftwareandmachinecomponents.
Sincecomponentsmustcooperate,interfacesbetweencomponentsareavital
considerationinsystem(andrequirements)engineeringinterfacesbetweenpeo
pleandmachinecomponents,betweenmachinecomponents,andbetweensoftware
components.Anexampleofamachinetomachineinterfaceinarailwaysystemis
thewaytrainwheelsinterfacewiththetrack.Apartfromthephysicalarrangements
(whicharedesignedtoallowthetraintobeguidedalongthetrackwithoutsliding
off),electricalcurrentsacrosstherailsmaybeusedtodetectthepresenceofthe
trainaspartofthetraincontrolsubsystem.

https://translate.googleusercontent.com/translate_f 21/211
2017520 RequirementsEngineering

Attheheartoftheconceptofasystem,liestheideaofemergentproperties.
Thisreferstothefactthattheusefulnessofasystemdoesnotdependonany
particularpartofthesystem,butemergesfromthewayinwhichitscomponents
interact.Emergentpropertiesmaybedesirable,inthattheyhavebeenanticipated
anddesignedintothesystemsoastomakethesystemusefulortheymaybe

Page25
1.2IntroductiontoSystemsEngineering 5

undesirable,inotherwordsunanticipatedsideeffects,suchasharmtotheenvironment.
Thetrickinsystemengineeringistobeabletoharnessdesirableemergentproperties,
andavoidtheundesirableones.
Anotherimportantconceptisthatofsystemsofsystems.Everysystemcanbe
construedasbeingpartofalarger,enclosingsystem.Forexample,theWestCoast
Mainlineispartofawiderrailwaysystem,andintersectswithothermajorandminor
routes.Theentirerailwaysystemispartofthewidertransportsystem,andinteractsin
allkindsofwayswiththeroadandairtransportnetworks.Thetransportsystemitself
providesessentialinfrastructureforthetransportofgoodsandpeopleaspartofthe
economyofthecountry.Andthecountryispartofthewiderworld,andsoforth.
Tounderstandtherequirementsofasystemproperlyistounderstanditsenclosing
system.Oftenthecorrectfunctioningofasystemdependsonprovisionsofthe
enclosingsystem.Forexample,theabilityofahelicoptertoflydependsonthe
environmentprovidedbytheearth,itsgravitationfieldandatmosphere.
Takeanother,verysimple,example:acup(Fig.1.1).Itisevidentthatithas
components:ahandleandabowlshapedcontainer.Whatpurposedothesecom
ponentsserve?Thebowlisforcontainingliquid,andthehandleistoallowthe
bowltobeheldbysomeonewithoutgettingburnt.Onemaydeducethatthepur
poseoforrequirementforthecupistoallowahumanbeingtotransferhot
liquidintothemouthwithoutspillingitorgettingburnt.
Thecupisrichininterfaces.Itcanbeplacedonaflatsurfaceforstabilityitcan
beheldinahumanhanditcanbefilledwithfluidandemptieditmustinterfacewith
thefluidforsustainedcontainmentanditmustdeliverfluidtothehumanmouth.
Butthereareotherobservationstobemade:

Thecupisnogoodonitsown.Itdependsonthemotormovementofthehuman
armtoachieveitspurpose.
Thebowlpartofthecupdependscruciallyonthepresenceofgravityforits
correctfunctioning.Italsohastobeusedcorrectly:holdingthecupupsidedown
wouldcausespilling,andmaycausescalding.

Attheendoftheday,theabilityofthissimplecuptofulfilitspurposedependson:

https://translate.googleusercontent.com/translate_f 22/211
2017520 RequirementsEngineering

Fig.1.1Acupasaverysimplesystem

Page26
6 1Introduction

Thepropertiesthatemergefromtheinteractionofitscomponents
Appropriateinterfacestoexternalcomponents
Itscorrectembeddingintheenclosingsystembeingheldinthehumanhand
andliftedbythearm
Thepresenceoftheproperenvironmentanothersolutionwouldbenecessary
inweightlessconditions

Insummary,theengineeringofrequirementsmusttakethenatureofsystemsinto
account.Essentialconsiderationsareemergentproperties,theconstraintsandpro
visionsoftheexternalenvironment,andtheinterfaceswithsurroundingsystems.

1.3DefiningRequirementsEngineering

Becauseoftheinterconnectednessofrequirementswithotheraspectsofsystems
engineeringandprojectmanagement,itisquitechallengingtofindasatisfactory
scopeforadefinitionofrequirementsengineering.

1.3.1DefinitionofaRequirement

Firstofall,whatismeantbyarequirement?Hereisatypicaldefinitiondrawnfrom
IEEESTD12201998(IEEE1998):

Requirement:astatementthatidentifiesaproductorprocessoperational,
functional,ordesigncharacteristicorconstraint,whichisunambiguous,
testableormeasurable,andnecessaryforproductorprocessacceptability(by
consumersorinternalqualityassuranceguidelines).

Thisdefinitiondrawsoutanumberoffacetsofarequirementthatarebrieflydis
cussedhere,andingreaterdetaillater:

Statement.Thatarequirementshouldbeastatementisperhapsbiasedtowardstextual
expression,whereastheycanalsobecapturedintabularform,suchasinTomGilbs
Planguage(Gilb2005),indiagrammaticforminnotationssuchasUML(OMG
2003),informalnotations,suchasZ(Spivey1989),VDM(Jones1986),LOTOS
(Bjorner1987)andtheBMethod(Abrial1996),orindomainspecificnotations,e.g.
(Chaochen,ZHoare,C.A.R.Ravn,A.P.1991).Theimportantconcept,though,isto
haveasetoftraceable,manageableelementsidentifiedasrequirements.
Productorprocess.Completesolutionscontainvaryingmixturesofproduct
(thingsthatarebuiltinresponsetorequirements)andprocess(proceduresfor
usingthethingsthatarebuilt).Requirementsmaythereforedefineprocessas
wellasproduct.Inadditiontothis,theremayberequirementsthatstipulatehow
https://translate.googleusercontent.com/translate_f 23/211
2017520 RequirementsEngineering

theproductshouldbedeveloped,usuallyforqualitycontrolpurposes.

Page27
1.3DefiningRequirementsEngineering 7

Operational,functional,ordesigncharacteristicorconstraint.Therearemany
differentkindsofrequirement,givingrisetodifferentkindsoflanguage,analysis,
modelling,processandsolution.Notethatthisdefinitionhascarefullyavoided
thetermnonfunctional,sincethereisheateddebateaboutwhatthisactually
means.Designcharacteristicscoverperformance,usability,safety,maintainabil
ityandahostofotherqualities.
Unambiguous.Astatementofrequirementhasdesirablequalitiesthatwillbe
addressedindetaillater.Inbrief,arequirementshouldlenditselftoaclear,
singleunderstanding,commontoallpartiesinvolved.
Testableormeasurable.Requirementsareusedtotestthatthedesignorsolution
isacceptable.Forthistobepossible,therequirementshouldbequantified,thus
providingameansofmeasuringthesolutionagainstit.
Necessaryforproductorprocessacceptability.Thishighlightsthemultidimensional
rolethatrequirementsplay:theyservetodefinewhatshouldbedesignedand
developed,andalsodefinehowthesolutionshouldbetestedandaccepted.They
haveaninfluenceintheearlieststagesofthedevelopmentprocessaswellasin
thelateststagesduringacceptance.
Byconsumersorinternalqualityassuranceguidelines.Requirementscome
frommanysources,includingbutnotlimitedtocustomers,regulatorybodies,
usersandinternalqualityprocedures.

Someothersynonymsforrequirementsare:aims,aspirations,capabilities,criteria,
constraints,directives,doctrines,duties,expectations,features,functions,goals,
missions,needs,obligations,objectives,orders,regulations,rules,etc.

1.3.2DefinitionofaStakeholder

Thetermstakeholderhasalreadybeenusedwithoutgivingadefinition:

Stakeholder:Anindividual,groupofpeople,organisationorotherentitythat
hasadirectorindirectinterest(orstake)inasystem.

Astakeholdersinterestinasystemmayarisefromusingthesystem,benefiting
fromthesystem(intermsofrevenueorotheradvantage),beingdisadvantagedby
thesystem(interms,forinstance,ofcostorpotentialharm),beingresponsiblefor
thesystem,orotherwisebeingaffectedbyit.
Stakeholdersarelegitimatesourcesofrequirements.

1.3.3DefinitionofRequirementsEngineering

Thetermrequirementsengineeringisoftentoonarrowlyequatedwithrequire
mentsanalysis,whichisjustoneoftheactivitieswithinthewiderdiscipline.The
emphasisonengineeringisusefulfortwomainreasons:

https://translate.googleusercontent.com/translate_f 24/211
2017520 RequirementsEngineering

Page28
8 1Introduction

1.Dealingwithrequirementsisanessentialpartofeveryengineeringendeavour.
Indeed,requirementsengineeringisasubsetofsystemsengineeringingeneral,
notjustsoftwareengineering.
2.Thetermsubsumesthewidevarietyofothertitlesgiventoactivitiesrelatingto
requirements,suchasrequirementsanalysisandthetwotermsusedforkey
processareasinCMMI(CarnegieMellon2006):requirementsmanagement
andrequirementsdevelopment.

Thefollowing,broaderdefinitionisoneofthemostlongstanding,andcomesfrom
aDoDsoftwarestrategydocumentdated1991:
Requirementsengineeringinvolvesalllifecycleactivitiesdevotedtoidentificationofuser
requirements,analysisoftherequirementstoderiveadditionalrequirements,documentation
oftherequirementsasaspecification,andvalidationofthedocumentedrequirements
againstuserneeds,aswellasprocessesthatsupporttheseactivities(DoD1991).

Whilethisdefinitioncoverstheidentification,analysis,developmentandvalidation
ofrequirements,itomitstomentionthevitalrolethatrequirementsplayinaccepting
andverifyingthesolution(usuallycalledverificationratherthanvalidation.)A
morerecentdefinition,giveninthecontextofsoftwareengineering,suffersthe
samedefect,butemphasizesthegoaloriented(orpurposeoriented)natureof
requirementsengineering,andhintsattheimportanceofunderstandinganddocu
mentingtherelationshipsbetweenrequirementsandotherdevelopmentartefacts:
Requirementsengineeringisthebranchofsoftwareengineeringconcernedwiththereal
worldgoalsfor,functionsof,andconstraintsonsoftwaresystems.Itisalsoconcernedwith
therelationshipofthesefactorstoprecisespecificationsofsoftwarebehavior,andtotheir
evolutionovertimeandacrosssoftwarefamilies(Zave1997).

Forthepurposesofthisbook,thefollowingdefinitionwillbeused:

Requirementsengineering:thesubsetofsystemsengineeringconcernedwith
discovering,developing,tracing,analyzing,qualifying,communicatingand
managingrequirementsthatdefinethesystematsuccessivelevelsofabstraction.

Thisdefinitionlistscarefullyselectedkeyactivitiesthatareconsideredproperto
requirementsengineering.Therearesomeactivitiescloselyrelatedtorequirements
thatareconsideredtobepartofsomeotherdiscipline.Anexampleofthisissystem
testingorverificationwhilerequirementsshouldhavethequalitiesnecessarytoallow
thesolutiontobeverified,theverificationactivityitselfisanotherdiscipline.Italso
referencestheconceptofrequirementsexistingatmultiplelevelsofdevelopment.
Herearesomenotesonthedefinition:

Discovering.Thiscoversanumberoftermsoftenused,suchasrequirements
elicitationandcapture.
Tracing.Tracingofrequirementstootherartefacts,includingrequirementsat
otherlayers,providesameansofvalidatingrequirementsagainstrealworld

https://translate.googleusercontent.com/translate_f 25/211
2017520 RequirementsEngineering

Page29

1.4RequirementsandQuality 9

needs,ofcapturingrationaleforthedesign,andofverifyingthedesignagainst
requirements.
Qualifying.Thisreferstoallkindsoftestingactivity,coveringtestingofthe
designandsolution,includingunit,component,integration,system,acceptance
testing.Thereisconsiderabledisagreementoverthemeaningoftheterms
verificationandvalidation.Thetermqualifyingispreferred,becauseitis
aboutensuringthatthesolutionhastherequiredqualities.Insomuchasthe
termsareusedinthisbook,tovalidaterequirementsistocheckaformalexpres
sionofrequirementsagainstinformalneedsasunderstoodinthemindsofstake
holders,andtoverifyrequirementsistochecktheirinternalconsistencywithin
layersandbetweenlayersofabstraction.
Communicating.Requirementsarethemeansofcommunicationthroughwhich
customers,suppliers,developers,usersandregulatorscanagreeonwhatistobe
achieved.
Levelsofabstraction.Thismakesreferencetothepracticeoforganizing
requirementsintolayersandoftracingthesatisfactionrelationshipbetween
thoselayers.Therequirementsofthetoplayerdefinethesystemintermsofthe
problemstobesolvedasagreedbythestakeholdersandvalidatedagainsttheir
realneedsrequirementsatsubsequentlayersdefinethewholeorpartofthe
systemintermsofanimplementablesolutionasverifiedagainsttherequire
mentsatthelayeraboverequirementsateverylayerprovideaprecisemeans
ofqualifyingthesolution.Somepeoplerefertotherelationshipbetween
requirementsinducedbyrecordingsatisfactionbetweenlayersasarequire
mentshierarchy,butinrealitythemanytomanyrelationshipformsagraphor
heterarchy.

1.4RequirementsandQuality

Theconsequencesofhavingnorequirementsaremanyandvaried.Thereisample
evidencearoundusofsystemsthatfailedbecauserequirementswerenotproperly
organised.Howeverwellthesystemmayappeartoworkatfirst,ifitisnotthe
systemthatuserswantorneedthenitwillbeuselessoruserless.
Itisinterestingtoconsidertherelationshipbetweenrequirementsandquality.
Thetermqualitymaybeunderstoodinavarietyofways.Whenaskedabout
qualitycars,onemightmentionRollsRoyce,MercedesorJaguar.Thisinherent
confusionbetweenqualityandluxuryisexposedifconsiderationisgivento
choosingthebestcarfortheannualRACrally.NeitherRollsRoyce,Mercedesnor
Jaguarischosen,sincenoneofthemexhibittherightweight/powerratio,ground
clearanceandrobustnessproperties.Recenthistoryshowsthatthebestqualitycar
initsclassisaSkodanotaluxurycar,buttherightqualityofcarforthejob.
Quality,then,isfitnessforpurposeorconformancetorequirementsitis
providingsomethingthatsatisfiesthecustomerandindoingsoensuresthatthe
needsofallthestakeholdersaretakenintoaccount.

Page30
https://translate.googleusercontent.com/translate_f 26/211
2017520 RequirementsEngineering

10 1Introduction

AsisseeninChapter8,requirementsengineeringactsasacomplimenttoother
managementconsiderations,suchascostandschedule,byprovidingavitalfocus
onthedeliveryofquality.Everymanagementdecisionisacompromisebetween
cost,scheduleandquality,threeinterrelatedaxes.
Sincerequirementsengineeringisadisciplinethatappliesfromthestartofthedevel
opmentlifecycle,theleverageonqualitythatcanbeexercisedbyproperrequirements
managementisproportionatelygreater.Relativelylittleeffortexpendedinearlystages
ofdevelopmentcanreapdividendsinthelaterstages.TheadageQualityisFree(the
titleofabookbyPhilCrosby)holdstrue,inthatgettingitrightattheoutsetcansave
hugeamountsofeffortthatwouldhavebeennecessarytoputthingsrightlater.
Improvingrequirementsmeansimprovingthequalityoftheproduct.

1.5RequirementsandtheLifecycle

Thereisacommonmisconceptionthatrequirementsengineeringisjustasingle
phasethatiscarriedoutandcompletedattheoutsetofproductdevelopment.The
purposeofthissectionistodemonstratethatrequirementsengineeringhasavital
roletoplayateverystageofdevelopment.
Asaninitialapproach,consideroneoftheverylastactivitiesinthedevelopment
process:acceptancetesting.Whatisasystemacceptedagainst?Thestakeholder
requirements.Soitcanbeseenstraightawaythatrequirementsdevelopedatthe
outsetarestillinuseinthefinalstagesofdevelopment.
TheclassicVModel,whichisusedtoportraythevariousstagesofdevelop
ment,hasitsbasisinthisrelationshipbetweentestingandrequirements.Figure1.2
showsthisrelationshipateverystageofdevelopment.

Testingiswith
Stakeholder respectto Acceptance
Requirements requirements test

System System
Requirements test

Subsystem Integration
Requirements test

Component Component
Requirements test

Fig.1.2RequirementsintheVModel

Page31
1.5RequirementsandtheLifecycle 11

https://translate.googleusercontent.com/translate_f 27/211
2017520 RequirementsEngineering

definingresultsforstakeholders,
Stakeholder Acceptance
validatingtheproduct
Requirements test

definingwhatthesystemmustdo,
System verifyingthesystem System
Requirements test
optimisingthecostbenefits,
qualifyingtherequirements

Subsystem Integration
Requirements test
allocatingrequirements,
qualifyingcomponents
Component Component
Requirements test

Fig.1.3Requirementsengineeringinlayers

TheVModelalsoviewsdevelopmentintermsoflayers,eachlayeraddressingthe
concernspropertothecorrespondingstageofdevelopment.Althoughslightlydiffer
entprocessesmaybeusedateachlayer,thebasicpatternofrequirementsuseisthe
sameapointreinforcedthroughtheintroductionofagenericprocessinChapter2.
Figure1.3showsthemainconcernofrequirementsengineeringateachlayer.
Anotherrolethatrequirementscanplayinanorganisationistoactasameans
ofcommunicatingbetweenprojects.Thisisagoodidea,becausemanyorganisa
tionswishto:

Maximisereuseofartefactsacrossprojects
Managefamiliesofsimilarproducts
Useprogrammemanagementtocoordinateactivities
Optimiseprocessbylearningfromtheexperiencesofotherprojects

Agoodsetofstakeholderrequirementscanprovideaconcisenontechnical
descriptionofwhatisbeingdevelopedatalevelthatisaccessibletoseniormanage
ment.Similarly,thesystemrequirementscanformanexcellenttechnicalsummary
ofadevelopmentproject.Thesedescriptionscanserveasabasisforcomparison
withotheractivities.ThisisillustratedinFig.1.4.
Ifrequirementsaretoplaysuchacentralroleinsystemsdevelopment,theyneed
tobemaintained.Tochangethedesignofaproductwithouthavingalsoupdated
therequirementstoreflectthatchange,istostoreuphugeproblemsforlaterstages
ofdevelopment.Hencerequirementsengineeringconnectsstronglywithchange
management.
Whetherchangeoriginatesfromwithinaprojecte.g.technicalissuesarising
fromdetailsofthedesignorfromwithoute.g.evolvingstakeholderneedsthe
impactofthatchangeonquality,costandscheduleneedstobeassessed.This
assessmentformsthebasisonwhichto:

Page32
12 1Introduction

informingthe learningfrom
enterprise theenterprise

https://translate.googleusercontent.com/translate_f 28/211
2017520 RequirementsEngineering
Stakeholder Acceptance
Requirements test

System System
Requirements test

Subsystem Integration
Requirements test

Component Component
Requirements test

Fig.1.4Enterpriserequirementsengineering

usingtraceability
andimpactanalysis
Stakeholder Acceptance
tomanagechange
Requirements test

System System
Requirements test

Subsystem Integration
Requirements test

Component Component
Requirements test

Fig.1.5Roleoftracebilityinchangemanagement

Acceptorrejectthechange(wherethatisachoice)
Negotiatethecostofthechangewiththecustomer/suppliers
Organisetheredevelopmentwork

Thekeyconceptthatenablesthiskindofimpactanalysisisrequirementstracing,
atopictreatedingreaterdetailinSection1.6,andinChapters2and7.Sufficeto
saythatchangemanagementisanintegralpartoftherequirementsengineering
process.ThisroleisillustratedinFig.1.5.
Quiteapartfromchangemanagement,amanagersabilitytocontrolaprojectis
considerablyenhancedbygoodrequirementsengineering.Withoutrequirements,

Page33
1.6RequirementsTracing 13

projectmanagershavenomeansofgauginghowwelltheprojectisgoing,oreven
ifitisgoingintherightdirection.Whenitcomestochangesthereisnothing
againstwhichchangecanbejudged.Whatismore,whentheydocometointer
vene,theironlyapproachisatatechnicallevel,whichisinappropriatetotheirrole,
andwhichinterfereswiththetechnicalroleproperlyplayedbytheengineers.

https://translate.googleusercontent.com/translate_f 29/211
2017520 RequirementsEngineering

Requirementswellexpressedattheappropriatelevelgivemanagersjusttheright
viewoftheprojecttobeabletoperformtheirrole.
Insummary,requirementsareessentialtothehealthofeverysystemdevelop
ment.Theyinfluencethewholedevelopmentfrombeginningtoendandfromtop
tobottom.Withouteffectiverequirementsengineering,developmentprojectsare
likeshipsdriftingrudderlessinastorm!Aboveallelse,withgoodrequirements
management,hearingthevoiceoftheusersandcustomersceasestobeagameof
Chinesewhispers,andbecomesamatterofclearlinesofcommunicationthroughout
thedevelopmentprocess.

1.6RequirementsTracing

Intherequirementsengineeringcontext,tracingisaboutunderstandinghowhigh
levelrequirementsobjectives,goals,aims,aspirations,expectations,needsare
transformedintolowlevelrequirements.Itisthereforeprimarilyconcernedwith
therelationshipsbetweenlayersofinformation.
Inabusinesscontext,onemaybeinterestedinhow

Businessvision isinterpretedas
Businessobjectives areimplementedas
Businessorganisationandprocesses

Inanengineeringcontext,theinterestmayfocusonhow

Stakeholderrequirements aremetby
Systemrequirements arepartitionedinto
Subsystems areimplementedas
Components

Tracingcancontributetothefollowingbenefits:

Greaterconfidenceinmeetingobjectives.Establishingandformalisingrelation
shipsengendersgreaterreflectiononhowobjectivesaresatisfied.
Abilitytoassesstheimpactofchange.Variousformsofimpactanalysisbecome
possibleinthepresenceoftracing.
Improvedaccountabilityofsubordinateorganisations.Greaterclarityinhow
supplierscontributetothewhole.
Abilitytotrackprogress.Itisnotoriouslydifficulttomeasureprogresswhenallthat
youaredoingiscreatingandrevisingdocuments.Processessurroundingtracing
allowprecisemeasuresofprogressintheearlystages.
Abilitytobalancecostagainstbenefit.Relatingproductcomponentstotherequire
mentsallowsbenefittobeassessedagainstcost.

Page34
14 1Introduction

Stakeholder Acceptance
Requirements testPlan

System System
Requirements testplan

https://translate.googleusercontent.com/translate_f 30/211
2017520 RequirementsEngineering

Subsystem Integration
Requirements testplan

Component Component
Requirements testplan

Fig.1.6Requirementstracing

Traceabilityrelationshipsareusuallymanytomanythatis,onelowerlevel
requirementmaybelinkedtoseveralhigherlevelones,andviceversa.Thesimplest
waytoimplementtracingistolinkrequirementsstatementsinonelayerwithstatements
inanother.Requirementsmanagementtoolstypicallyallowsuchlinkingbydrag
anddropbetweenparagraphsofdocuments.Thelinksareratherlikehyperlinksin
webpages,butshouldideallybetraversableineitherdirection.Figure1.6shows
tracingdownwardsthroughthelayersofrequirements,andacrosstothetest
information.
Thedirectionofthearrowsfollowsaparticularconvention:information
tracesbacktotheinformationitrespondsto.Thereareanumberofreasonsforthis
convention:

Itusuallycorrespondstothechronologicalorderinwhichinformationiscreated:
alwayslinkbacktotheolderinformation.
Itusuallycorrespondstoaccessrightsduetoownership:oneownstheoutgoing
linksfromadocument,someoneelseownstheincominglinks.

Variousformsoftraceabilityanalysiscanbeusedtosupportrequirementsengineering
processes,presentedinTable1.3.
Whenperformingcoverageanalysis,itisimportanttorealisethatcountinglinks
tellsonlyasmallpartofthestory.Thepresenceofoneormorelinksgivesno
indicationthatthecoverageprovidescorrectorcompletesatisfaction,whichmust

Page35
1.6RequirementsTracing 15

Table1.3Typesoftraceabilityanalysis
Typeofanalysis Description Processessupported
Impactanalysis Followingincominglinks,inanswerto Changemanagement
thequestion:Whatifthiswasto
change?
Derivationanalysis Followingoutgoinglinks,inanswerto Cost/benefitanalysis
thequestion:Whyisthishere?
Coverageanalysis Countingstatementsthathavelinks, Generalengineering
inanswertothequestion:HaveI Managementreporting
coveredeverything?
(Maybeusedasanapproximate
measureofprogress,butnotof

https://translate.googleusercontent.com/translate_f 31/211
2017520 RequirementsEngineering
sufficiencyseebelow.)

Acceptance
Stakeholder
Requirements testPlan

System System
Requirements testplan
D
e
riva
tio Impactanalysis
Subsystem n Integration
Requirements a testplan
Impactanalysis
n
a Derivationanalysis
lysis

Component Component
Requirements testplan

Fig.1.7Impactandderivationanalysis

remainanengineeringjudgement.Wewillseelaterthattwoaspectshavetobe
consideredwhenassessingthequalityoftracing:sufficiencyandnecessity.
Impactanalysisisusedtodeterminewhatotherartefactsinthedevelopment
mightbeaffectedifaselectedartefactchanges.ThisisillustratedinFig.1.7.The
impactispotentialcreativeanalysishastobecarriedoutbyanengineertodeter
minetheexactnatureoftheimpact,ifany.
Derivationanalysisworksintheoppositedirectiontoimpactanalysis.Alow
levelartefactsuchasarequirement,designelementortestisselected,andthe
tracingisusedtodeterminewhathigherlevelrequirementshavegivenrisetoit.
Elementsinthedesignthatdonotsotracebackarepotentiallyaddingcostwithout
benefit.

Page36
16 1Introduction

Finally,coverageanalysiscanbeusedtodeterminethatallrequirementsdo
tracedownwardstolowerlayers,andacrosstotests.Theabsenceofsuchatraceis
afairlycertainindicationthattherequirementwillnotbemetortested.The
presenceofalinkdoesnot,ofcourse,ensurethattherequirementwillbemetthat
againrequirescreativeengineeringjudgement.
Coveragecanalsobeusedasameasureofprogress:howfarhavethesystems
engineersgotinrespondingtothestakeholderrequirements?Supposethetaskof
writingsystemsrequirementsinresponsetostakeholderrequirementsisgiventoan
engineer.Asshewritessystemrequirements,shelinksthembacktothestakeholder
requirementssheisrespondingto.(Bydoingitasshegoesalong,theinsertionof
tracingisverylittleextraoverheaditismuchmoredifficulttoestablishtracing
afterbothdocumentshavebeenwritten!)
Atanystageofthetask,theengineersprogresscanbemeasuredintermsofthe

https://translate.googleusercontent.com/translate_f 32/211
2017520 RequirementsEngineering

percentageofstakeholderrequirementsthathavebeencoveredsofar.Thisisavery
usefulmanagementtoolduringtheearlystagesofdevelopment.
Thesameprinciplecanbeusedtomeasureprogressinplanningtests.What
percentageoftherequirementshavetestsdefinedsofar?Thesetwodimensionsof
coveragearesummarizedinFig.1.8.
Becauseofthekindsofanalysisthatcanbecarriedout,tracingisasimpleconcept
thatliesattheheartoftherequirementsengineeringprocess.Moreadvancedforms
oftracingarediscussedindetailinChapter7.

Areall Acceptance
Stakeholder
requirements testPlan
Requirements
coveredbythe
layerbelow?

System System
Requirements testplan

Subsystem Integration
Areall
Requirements testplan
requirements
coveredbytests?

Component Component
Requirements testplan

Fig.1.8Coverageanalysis

Page37
1.7RequirementsandModelling 17

1.7RequirementsandModelling

Itisimportanttounderstandtherelationshipbetweenrequirementsmanagement
andsystemmodelling.Theyaremutuallysupportiveactivitiesthatshouldnotbe
equated.Figure1.9comparestherelationshiptoasandwich.Inthisanalogy,
requirementsmanagementisthebreadandbutterofthedevelopmentcycle.The
fillingprovidedbysystemmodellingexplainsandexposestheanalysisand
designthathasledtosubsequentlayersofrequirements.
Somepeopletalkaboutrequirementsmodelling.Thisisamisnomer.You
modelthesystemdesign,nottherequirements.Modellingsupportsthedesign
activity,andiswheremostofthecreativeworktakesplace.Itassiststheengi
neerinunderstandingenoughofthesystemtodecomposetherequirementsata
particularlevelintothenextleveldown.Therequirementsthemselvesarea
completesnapshotofwhatisrequiredateachlevelinincreasinglevelsof
detail.

https://translate.googleusercontent.com/translate_f 33/211
2017520 RequirementsEngineering

Aparticularmodelneversayseverythingaboutasystemifitdid,itwouldnot
beamodel.Forthisreason,severaldifferent,possiblyinterrelated,modelsof
systemsareoftenusedtocoveravarietyofdifferentaspects.Itislefttotheexpres
sionofrequirementsusuallyintextualformtocoverthoseaspectsnot
modelled.
Amodelisanabstractionofasystemthatdeliberatelyfocusesonsomeaspects
ofasystemtotheexclusionofothers.Abstractionis,inthissense,avoidanceof
distractionignoringthosedetailsthat,althoughimportant,arenotrelevanttoa
particularmodel.Theadvantageofthisisthatsmalleramountsofrelatedinforma
tioncanbecollected,processed,organisedandanalysed,applyingvariousspecific
techniquespertinenttotheaspectsunderstudy.
Wherealargeamountofcomplexinformationhastobemanaged,model
lingprovidesameansofzoomingin,collectingtogethersubsetsofthedatafora
particularpurpose,andzoomingoutoncemoretoappreciatethewhole.Itaids
inmaintainingasystemwidegraspthroughfocussingonsmallamountsof
informationatatime.

Requirementslayer

Modellinglayer

Requirementslayer

Modellinglayer

Requirementslayer

Modellinglayer

Requirementslayer

Fig.1.9Thesystemsengineeringsandwich

Page38
18 1Introduction

Statement
Requirementslayer ofneed

Modellinglayer Usagemodelling

Stakeholder
Requirementslayer requirements

Functional
Modellinglayer modelling

System
Requirementslayer requirements

Modellinglayer Performance
modelling

Subsystem
Requirementslayer
requirements

Fig.1.10Requirementsandmodeling

Figure1.10portraystheinterrelatedrolesthatrequirementsandsystemmodelling
play.Modelsassisttherequirementsengineerinanalysingtherequirementsata

https://translate.googleusercontent.com/translate_f 34/211
2017520 RequirementsEngineering

particularlevelsoasto:
Communicatewiththecustomer,andimprovemutualunderstandingofthesystem
tobedeveloped.
Analysethesystemtoascertainthepresenceofdesiredemergentproperties
(andtheabsenceofundesirableones).
Determinehowtosatisfytherequirementsbyderivingnewrequirementsatthe
layerbelow.

Thenatureofthemodelsusedwillvaryfromlayertolayer.Atthetoplayer,usage
modelssuchasstakeholderscenariosareusedtoderivethefirststatementof
stakeholderrequirements.Followingthis,variouskindsoffunctionalmodelmaybe
usedtoderivesystemrequirementsfromthestakeholderrequirements.Forsoft
ware,suchmodelscouldincludeUMLclassdiagrams,messagesequencecharts
andstatecharts(seeChapter3formoredetailsonthesemodellingtechniques).
Movingfromsystemrequirementstoarchitecture,theconcernsbecomefocused
onvariousaspectsofperformance.Multiplemodelsmaybeusedtogiveconfidence
thattheselectedarchitecturecandeliveragainstnonfunctionalaswellasfunctional
requirements.Here,modelsmayincludequeuingtheoryusedtoassessperformance,
windtunnelsforassessingaerodynamics,timetablemodellingtoassessviabilityof
journeytimes.
Asisevidentfromtheseexamples,thenatureofthemodelsalsovariesfrom
applicationtoapplication.Themodellingoftimetablesmaybeappropriateforthe
designofrailwaysystems,butnotforaircraftdesign,wherethemodellingofaero
dynamicsisrathermoreappropriate.(Aerodynamicsmayalsobeimportantto
highspeedtrains,ofcourse.)Messagesequencechartsmaybeusedincommunica
tionssystems,butdatarichapplicationswillfinddatafocusedmodellingsuchas
entityrelationshipdiagrammingmoreappropriate.

Page39
1.8RequirementsandTesting 19

Whereasthemodelsmayvary,theprinciplesofrequirementsmanagement
remaingenericacrossapplications.Sincethisbookisaboutrequirementsengineering,
italsocoversthecloselyassociatedsubjectofmodellingandmethods.

1.8RequirementsandTesting

Ashasbeendiscussedabove,testingiscloselyrelatedtorequirementsatevery
level.Initsbroadestsense,testingisanyactivitythatallowsdefectsinthesystem
tobedetectedorprevented,whereadefectisadeparturefromrequirements.So
testingactivitiesincludereviews,inspections,analysisthroughmodellingaswell
astheclassicaltestsofcomponents,subsystemandsystemsthatarecarriedout.
Becauseofthediversityoftestingactivities,thetermqualificationisusedinthis
booktorefertoallsuchactivities.
Qualificationshouldbeginasearlyaspossible,sincewaitinguntilthesystemis
almostcompletebeforecarryingoutanykindoftestingcanleadtoveryexpensive
designchangesandrebuilds.Theearliestkindsofqualificationactiontakeplace
duringthedesignofthesystem,andincluderequirementsreviews,designinspec
tions,andvariousformsofanalysiscarriedoutonsystemmodels.
Figure1.11portraysthequalificationstrategyalongatimelinebelowthe

https://translate.googleusercontent.com/translate_f 35/211
2017520 RequirementsEngineering

VModel.EarlyqualificationactionsrelatetothelefthandsideoftheVModel,
lateronestotheteststagesontherighthandside.

Stakeholder Acceptance
Requirements test

System System
Requirements test

Subsystem Integration
Requirements test

Component Component
Requirements test

Reviews/Designinspections/Analysis/Prototypes/Componenttests/Rigtests/Systemtests/Trials

QualificationStrategy/Programme
time

Fig.1.11QualificationstrategyandtheVModel

Page40
20 1Introduction

Asinglestakeholderrequirementwilltypicallygiverisetoamultitudeof
qualificationactivitiesatvariousstagesofdevelopment.Wherearequirementis
satisfiedthroughusefulemergentproperties,qualificationofcomponentsalone
isinsufficienttestshavetobecarriedoutatthelevelwhereemergentproperties
aremanifest.

1.9RequirementsintheProblemandSolutionDomains

Systemsengineeringisconcernedwithdevelopingandmanagingeffectivesolu
tionstoproblems.Ashasbeendiscussed,itisastagedprocessvitalforbusinesses
inenablingthemtoproducetherightproductwithinacceptabletimescalesand
costs.
Earlyintheprocess,thedefinitionoftherequirementsfortheproducttobebuilt
isofprimeimportance.Fromamanagementandengineeringpointofview,aclear
distinctionshouldbemadebetweentheproblemdomainandthesolution
domain.Thosestagesofdevelopmentassociatedwiththehighestlevelsofsystem
descriptionstatementofneed,usagemodellingandstakeholderrequirements
shouldbefirmlyrootedintheproblemdomain,whereassubsequentlayers,starting
withsystemrequirements,operateinthesolutiondomain.
Table1.4portraystheidealboundarybetweentheproblemandsolution
domains,andtherolesthatthetoprequirementslayersplay.
Thereisanimportantprincipleofabstractionatplayhere.Theinitialstatement

https://translate.googleusercontent.com/translate_f 36/211
2017520 RequirementsEngineering

ofcapabilityshouldstatenomorethanisnecessarytodefinetheproblem,andavoid
anyreferencetoparticularsolutions.Thisallowsfreedomtothesystemengineersto
carryouttheirrole,whichistodevisethebestsolutionwithoutpreconceivedideas.
Modellingassistsinthederivationofthenextlayerofrequirements,andtendsto
considerpossiblesolutions,evenatahighlevel.Toavoidinappropriatesolution
bias,ratherthanfocusonthesysteminquestion,earlymodellingshouldfocuson
theimmediatelyenclosingsystem.Forinstance,ifaradiosystemisbeingdeveloped

Table1.4Problemandsolutionspaces
Requirements
layer Domain View Role
Stakeholder ProblemdomainStakeholders Statewhatthestakeholders
requirements view wanttoachievethrough
useofthesystem.Avoid
referencetoanyparticular
solution.
System SolutiondomainAnalystsview Stateabstractlywhatthesystem
requirements willdotomeetthestakeholder
requirements.Avoidreference
toanyparticulardesign.
Architectural SolutiondomainDesignersview Statehowthespecificdesignwill
design meetthesystemrequirements.

Page41
1.9RequirementsintheProblemandSolutionDomains 21

forasailingboat,thenearlymodellingshouldfocusonthevesselandnotsomuch
ontheradio.Thisleadstoastatementoftheproblemtobesolvedinthecontextof
theenclosingsolution.
Thesameprincipleappliestothesystemsengineers:theyshouldallowthe
designersthefreedomtoperformtheirrole,thatofdesigningagainstanabstract
solution.Theelementsofsolutionintroducedthroughfunctionalmodellingremain
atahighlevel,leavingthedetailtobedefinedinsubsequentstages.
Forexample,inatrafficcontrolsystem:

Thestakeholdersmayexpresstheproblemintermsofmaximisingtrafficflow
whileminimisingtheriskofaccidentsatatrafficjunctionandminimisingcost
ofmaintenance.
Thesystemsengineersmayconsideravarietyofsolutions,suchasbridges,traffic
lightsorroundabouts,andabridgeastheapproachthatbestsolvestheproblem
withinconstraintsofdevelopmentandmaintenancecosts.
Thedesignersthensettoworkdesigningthebridgewithinthephysicalconstraints
presentedbythephysicalenvironment.

Itisfrequentlythecasethatthestakeholderswillexpresstheproblemintermsof
apreconceivedsolution.Itthenbecomestherequirementsengineersjobtodeter
minewhetherthereisagoodreasonformandatingaparticularsolution,orwhether
itisanunnecessaryconstraint.Forexample,thecustomerstartsbytryingto
procuretrafficlightsthesupplierasksquestionsthatleadtoanunderstandingof
theunderlyingobjectivesmaximisetrafficflowandminimiseriskfordriversand
pedestriansleadingtoasolutionindependentexpressionoftheproblemthe
reasonsforthechoiceofsolutionarenowbetterunderstood,andperhapsconfirmed
throughappropriatemodelling,leadingtoapreciseandwellinformedspecification

https://translate.googleusercontent.com/translate_f 37/211
2017520 RequirementsEngineering

oftheabstractsolution.
Whenitcomestoprocuringsystems,ajudgementneedstobemadeasto
whethertoprocureagainsttheproblemdomain(stakeholderrequirements)or
againsttheabstractsolutiondomain(systemrequirements).Oftenthenatureofthe
solutionisknowninadvance,anditmakessensetoprocureagainstsystemrequire
mentsframedintermsofthatsolution.However,evenifprocuringagainsta
particularsolution,thedisciplineofcapturingastatementofthepureproblemprior
toasolutionstilloffersimportantadvantages.
Withoutacleardistinctionbetweenproblemandsolution,thefollowingmay
result:

Lackofunderstandingoftherealproblem
Inabilitytoscopethesystem,andunderstandwhichfunctionstoinclude
Dominationofdebateaboutthesystembythedevelopersandsuppliers,because
theonlydescriptionsofthesystemareexpressedintermsofsolutions
Inabilitytofindoptimalsolutionsduetolackofdesignfreedom

Forthesereasons,thebookmakesthedistinctionbetweenstakeholderandsystem
requirements,intermsofhowrequirementsarecaptured,modelledandexpressed.

Page42
22 1Introduction

1.10HowtoReadthisBook

Thisbookisconcernedwithengineeringrequirementsandhowthisprocessmay
helpthosesystemengineersandsoftwareengineerstocreatebetterrequirements.
Chapter1hasdiscussedtheimportanceofrequirementsandhasinvestigatedthe
roleofrequirementsengineeringinallpartsofthedevelopmentlifecycle.
Becauseofmultipledependenciesbetweenchapters,theorderingofmaterial
hasbeencarefullychosentoreducethenumberofforwardreferences.Whileitis
besttoreadthechaptersinthesequencepresented,someguidelinesaregivenhere
toassistreaderswithparticularobjectivestomakeefficientuseofthebook.
Chapter2presentsrequirementsengineeringinagenericformthatisapplicable
toalllayersofdevelopment.Whilethisapproachassiststhereaderingaininga
goodunderstandingoftheessenceofrequirementsengineering,itremains,of
necessity,quiteabstract.Thegenericprocessis,however,mademoreconcretein
Chapters5and6,whereitisadaptedtothestakeholderandsystemlayersofdevel
opmentusingnumerousexamples.
Chapter3talksaboutsystemmodelling,coveringvarioustechniquesand
methodsinwideuse.ThisisagaininpreparationforChapters5and6,where
particularmodellingtechniquesareplacedinthecontextofstakeholderandsystem
requirements.

Chapter1Introduction

Chapter2AGenericProcessforRequirementsEngineering

Chapter3SystemmodellingandmethodsforRequirementsEngineering

https://translate.googleusercontent.com/translate_f 38/211
2017520 RequirementsEngineering

Chapter4WritingandReviewingRequirements

Chapter5RequirementsEngineeringintheProblemDomain

Chapter6RequirementsEngineeringintheSolutionDomain

Chapter7AdvancedTraceability

Chapter8ManagementAspectsofRequirementsEngineering

Chapter9DOORS:aTooltoManageRequirements

Fig.1.12Chapterdependencies

Page43
1.10HowtoReadthisBook 23

Chapter4addressesthestructuringofrequirementsdocuments,andtheexpression
ofrequirementsstatements.Herethelanguageofdifferentkindsofrequirementis
discussed.
Chapter5instantiatesthegenericprocesstoaddresstheproblemdomain,in
whichstakeholderrequirementsaretheprimaryfocus.
Chapter6thendoesthesameforrequirementsinthesolutiondomain,from
systemrequirementsdownwardsthroughsubsystemsandcomponents.
Chapter7presentsfurtherapproachestotraceability,aimedatimprovingthe
wayinwhichrationalefortraceabilityiscaptured,anddiscussesmetricsthatcan
bederivedfromtraceability.
Chapter8addressesprojectmanagementinarequirementsmanagementcontext,
coveringavarietyoforganisationtypes.
Finally,Chapter9providesanoverviewofDOORSasanexampleofasoftware
toolwhichservesasanenablerofarequirementsmanagementprocess.Acasestudy
isusedtoillustratetheprocessespresentedinthebook,andfeaturesofthetool.
Figure1.12depictsthechapterdependencies.

https://translate.googleusercontent.com/translate_f 39/211
2017520 RequirementsEngineering

Page45
Page44

Chapter2
AGenericProcessforRequirements
Engineering

Ifyoucantdescribewhatyouaredoingasaprocess,
youdontknowwhatyouredoing.

WilliamEdwardsDeming,
managementconsultant,19001993AD

2.1Introduction

Thischapterintroducestheconceptofaprocessforthedevelopmentofsystems.
Itstartsbyexaminingthewayinwhichsystemsaredeveloped.Thisleadstothe
identificationofadevelopmentpatternthatcanbeusedinmanydifferentcontexts.
Thisdevelopmentpatternisexpressedasagenericprocessandisexplainedinsome
detail.Subsequentchaptersindicatehowthegenericprocesscanbeinstantiatedfor
specificpurposes.Therelationshipbetweenprocessmodelsandinformationmodels
isalsoexploredandaninformationmodelforthegenericprocessisdeveloped.

2.2DevelopingSystems

Beforeanysystemcanbedevelopeditisessentialtoestablishtheneedforthesystem.

https://translate.googleusercontent.com/translate_f 40/211
2017520 RequirementsEngineering

Ifthepurposeofasystemisnotknown,itisunclearwhatsortofsystemwillbedevel
oped,anditisimpossibletodeterminewhetherthesystem,whendeveloped,will
satisfytheneedsofitsusers.ForestGumpsummeditupquitenicelywhenhesaid:
Ifyoudontknowwhereyouaregoing,youareunlikelytoendupthere.

Therigourwithwhichtheneedisexpressedwilldependuponthenatureoftheindi
vidualresponsibleforstatingtheneedandhis/herrolewithintheorganisationin
whichtheywork.Theneedmaybeexpressedinfairlyvaguetermsinitially,e.g.
Iwouldlikeasystemthatimprovestheefficiencyofmydepartment.Clearly,such
aspecificationisnotappropriatetobeusedasthebasisforgoingouttobuya
system.However,itcouldbethebasisforastudytodetermineexactlywhattheperson

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_2, 25
SpringerVerlagLondonLimited2011

Page46
26 2AGenericProcessforRequirementsEngineering

reallywants.Suchastudywouldhavetodeterminewherethedepartmentiscurrently
inefficientandtopostulatehowthecapabilitiestobeprovidedbytheproposed
systemwouldbeusedtoimprovetheefficiency.Theseactivities,whichtransforma
vaguestatementofneedintoasetofrequirementsthatcanbeusedasthebasisfor
purchasingasystem,constitutetheprocessofdevelopingtheStakeholderRequirements.
Stakeholdersincludepeople,whowilldirectlyinteractwiththesystem,butalsoother
peopleandorganisationsthathaveotherinterestsinitsexistence.Thetopicofcreating
StakeholderrequirementsisdealtwithindetailinChapter5.
Figure2.1illustratesthedevelopmentprocess.Inthediagrammaticconventions
usedforprocessmodels,circles(orovals)representprocessesandrectangles
representdataorinformationthatisreadorproduced.Thearrowsindicatewhether
dataisreadorwritten.Thus,Fig.2.1statesthattheDevelopStakeholderRequirements
processtakestheStatementofNeedsandproducestheStakeholderRequirements.
ItalsocreatesandreadsaUseModel.
OnceasoundsetofStakeholderRequirementsexistthatdefinewhatthestake
holderswanttobeabletodowiththeproposedsystem,itispossibletobeginto
thinkaboutpotentialsolutions.Ratherthanjumpingstraighttoadesign,itisgood
practicetofirstdeterminewhatcharacteristicsthesystemmusthaveirrespectiveof
thefinaldetaileddesign.ThisprocessisknownasestablishingtheSystem

StatementofNeeds

Develop Problem
Use
Stakeholder Domain
Requirements Model

StakeholderRequirements

Develop
Abstract
System
Model
Requirements

SystemRequirements

Develop
SystemDesign
System
Architecture
Design
Solution
Domain
SystemComponentRequirements
(SubsystemRequirements)

https://translate.googleusercontent.com/translate_f 41/211
2017520 RequirementsEngineering

Develop
SubsystemDesign
Subsystem
Architecture
Design

SubsystemComponentRequirements
(lowerlevelsubsystemrequirements)

Fig.2.1Systemdevelopmentprocess

Page47
2.2DevelopingSystems 27

Requirements.Itisrecommendedthatanabstractmodeloftheproposedsystembe
produced.Thismodelprovidesabasisfordiscussionwithinthedevelopmentteam
andhenceprovidesameansofestablishingacommonunderstandingofthepro
posedsolution,albeitatanabstractlevel.Themodelcanalsobeusedtoexplainthe
solutionconceptstothoseStakeholderswhowishtobeassuredthatthedevelopers
aremovingalongtherightlines.Finally,themodelprovidesastructureforpresent
ingthesystemrequirementsinadocumentform.Eachelementinthemodelcan
formasectioninthedocument.Thisplaceseachrequirementinarelevantcontext
andisanindispensableaidtoreviewingthecompleterequirementssetfromacon
sistencyandcompletenesspointofview.
Fromthesystemrequirementsitispossibletoconsideralternativedesignarchi
tectures.Adesignarchitectureisexpressedasasetofinteractingcomponentsthat
collectivelyexhibitthedesiredproperties.Thesepropertiesareknownastheemer
gentpropertiesofthesystemandshouldexactlymatchthedesiredcharacteristics
ofthesystemasexpressedinthesystemrequirements.Thedesignarchitecture
defineswhateachsystemcomponentmustdoandhowthesystemcomponents
interactwitheachothertoproducetheoveralleffectsspecifiedinthesystem
requirements.Inotherwords,thedesignarchitecturedefinestherequirementsfor
eachsystemcomponent(seeFig.2.1)intermsoftheirfunctionalityandinteraction
obligations.Thedesignarchitectureandhencethesystemcomponentrequirements
mustalsostipulateanyotherrequiredpropertiessuchasphysicalsize,perfor
mance,reliability,maintainability,etc.
Forallbutthesmallestofsystems,thecomponentsinthedesignarchitecture
willbetoocomplextobeimplementeddirectly.Componentsatthislevelare
frequentlyknownassubsystemsbecausetheyarecomplexenoughtobeconsid
eredassystemsintheirownright,butyettheyarestillonlypartofthehigherlevel
systemforwhichtheyaredesigned.
Theprocessofestablishingthedesignarchitectureforeachsubsystemandthen
usingthistoderivecomponentrequirementsissimilartothatdescribedforthe
overallsystem.Eventuallyasubsystemdesignarchitectureandsubsystemcompo
nentrequirementswillbeproducedforeachsubsystemasindicatedinFig.2.1.
Thisdescriptionofthedevelopmentprocesshasindicatedthatdevelopmentof
systemstakesplaceatseverallevelsandthatdifferentactivitiestakeplaceateach
level.Figure2.1alsoindicatesthateachactivityissupportedbyamodel(e.g.Use
model,AbstractModel,DesignArchitecture),althoughthenatureofthemodels
differsquitesignificantly.Thisisanexampleofacommonaspect:eachlevelof
developmentusesamodel.Inthefollowingsectionsofthischapter,thesesimilarities
arefurtherexploredinordertodefinethepropertiesofagenericprocess.
Itisessentialtorealisethattherearerequirementsateachofthelevels:

https://translate.googleusercontent.com/translate_f 42/211
2017520 RequirementsEngineering

Needsstatement
Stakeholderrequirements
Systemrequirements
Systemcomponentrequirements
Subsystemcomponentrequirements

Page48
28 2AGenericProcessforRequirementsEngineering

Consequently,requirementsengineeringisnotsomethingthatisdoneonceand
thenforgotten.Ithappensateachlevel,andoftenworkisundertakenconcurrently
atdifferentlevels.Atalllevelsfromthesystemcomponentsdownward,thereis
multipleconcurrentworkonrequirementsateachlevel.(Thegreybackgroundof
therelevantsymbolsinFig.2.1indicatethis.)

2.3GenericProcessContext

AnalternativewayofconsideringthedevelopmentprocessisshowninFig.2.2.
Thisdiagramsuggeststhatthesamedevelopmentprocess,EngineerRequirements,is
usedateachlevel,althoughtheexplanationgivenaboveindicatesthatthework
involvedisdifferentateachlevel.Thisapparentlystrangewayofdescribingthe
processisusedtointroducethefactthatthereis,infact,asignificantdegreeofcommonality

StatementofNeeds

Engineer Problem
Requirements Domain

StakeholderRequirements

Engineer
Requirements

SystemRequirements

Engineer
Requirements

Solution
Domain
SystemComponentRequirements
(SubsystemRequirements)

Engineer
Requirements

https://translate.googleusercontent.com/translate_f 43/211
2017520 RequirementsEngineering
SubsystemComponentRequirements
(lowerlevelsubsystemrequirements)

Fig.2.2Differentlevelsofrequirementsengineering

Page49
2.3GenericProcessContext 29

intheworkdoneateachlevel.Thepurposeofthischapteristoexplorethesecom
monaspectsandtopresentagenericprocessthatnotonlyaddressesthecommon
aspectsbutalsoenablesthedifferentaspectstobeaccommodated.
Itisimportanttostressthatinamultileveldevelopment,eachlevelofdevelop
mentdemandsrelevantexpertise.Atthehigherlevels,domainknowledgeinthe
problemdomainisvital.Atthesystemlevel,itisimportantthatasystemwide
viewistakentoavoidtoonarrowaninterpretationoftheStakeholderRequirements.
Atthisleveltherewillinevitablybeasolutionbiasintroduced.Peopleororganisa
tionswithaproventrackrecordinthedevelopmentofsimilarsystemsareneces
sary.Similarly,thesubsystemdeveloperswillbringtheirowndomainexperience
fortheparticularspecialistareaoftheirsubsystem.
Thus,itisunlikelythatthesamepeoplewillundertakedevelopmentatevery
level.Evenwhenthesameorganisationisworkingonseverallevels,itislikelythat
differentpeoplewillbeinvolved,oftenfromdifferentdepartments.Therefore,itis
usefultointroducetheideathateachlevelofdevelopmentisdoneinresponsetoa
customeratthelevelabove,andwillinvolvesuppliersatthelevelbelow.

2.3.1InputRequirementsandDerivedRequirements

Figure2.3showsanalternativeviewofFig.2.2inwhichtheindividualprocesses
havebeenseparated.Thisemphasisesthattherequirementsderivedbyoneprocess
becometheInputRequirementsofanotherprocessandleadsnaturallytotheidea

StatementofNeeds
Input Input
Requirements Requirements

Engineer
Requirements Generic
Process
Engineer
StakeholderRequirements StakeholderRequirements Requirements

Engineer
Requirements Derived
Requirements

SystemRequirements SystemRequirements

Engineer
Requirements

SystemComponentRequirements SystemComponentRequirements
Derived
Input
(SubsystemRequirements) (SubsystemRequirements)
Requirements
Requirements

Engineer
Requirements

SubsystemComponentRequirements
(lowerlevelsubsystemrequirements)

https://translate.googleusercontent.com/translate_f 44/211
2017520 RequirementsEngineering

Fig.2.3Identifyinginputandderivedrequirementsofthegenericprocess

Page50
30 2AGenericProcessforRequirementsEngineering

thatthegenericEngineerRequirementsprocesstakesinInputRequirementsand
generatesDerivedRequirements(alsoasshowninFig.2.3).

2.3.2AcceptanceCriteriaandQualificationStrategy

BeforemovingontoexplaintheinternaldetailsoftheEngineerRequirements
process,itisnecessarytoconsideranotherclassofinformationthatisbothaninput
totheprocessandderivedbytheprocess.Thisisinformationconcerningthequali
ficationstrategyfortherequirements.
Tofullyunderstandthesignificanceofrequirementsandcometoasatisfactory
agreementthattherequirementsformagoodbasisfordevelopment,itisnecessary
toconsiderhowtherequirementswillbedemonstratedwhenthesystem(orcom
ponent)hasbeenimplemented.Thisispartlyachievedbydetermining,foreach
requirement,thecriteriathatwillbeusedtoestablishwhetherornotthesystemthat
claimstoimplementtherequirementisacceptabletothecustomer.
Itisalsonecessarytodeterminethecircumstancesunderwhichthecriteriawill
beexamined.InChapter1thenotionoftestplansateachlevelwasintroduced.
Testingisjustonetypeofqualificationstrategy.Othersincludetrials,certification
andinspections.Thetypeofqualificationstrategytobeusedwilldependonthe
natureofthesystemforexample,systemsthathavesafetycriticalaspectswillhave
tobecheckedmuchmorecarefullythan,say,amanagementinformationsystem.
ThefullcontextoftheEngineerRequirementsgenericprocessisthereforeas
showninFig.2.4.
TheQualificationStrategyoftenintroducesnewrequirementsfortestequip
ment,theuseofexistingfacilities(e.g.windtunnels,anechoicchambers,etc.)and
specialdiagnosticfunctionsormonitorpoints.Insomecircumstancesawhole
newprojectmayevolvetodevelopthetestequipmentandotherfacilitiesrequired.

Qualificationstrategy
Input
forInput
Requirements
Requirements

Engineer
Requirements

Qualificationstrategy
Derived
Requirements forDerived
Requirements

Fig.2.4Qualificationstrategyisessential

https://translate.googleusercontent.com/translate_f 45/211
2017520 RequirementsEngineering

Page51
2.4GenericProcessIntroduction 31

Forexample,inavionicsdevelopmentitisnecessary(forcostandsafetyreasons)
toperformasmuchtestingaspossiblebeforetheequipmentisinstalledinan
aircraft.Evenwhenitisinstalled,itwillalsobenecessarytorunwithsimula
tionspriortoflighttrials.Clearlythetestpilotmustbeassuredthattheavionics
willperformtoaknownstandardpriortofirstflight.
Atlowerlevelsinthehierarchywhereitemsaretobemanufactured,thequali
ficationstrategymayconsiderissuessuchaswhetherthesupplierorthecustomer
isresponsibleforthetestingofeachitemsupplied.Possiblestrategiesincludefull
testingofeveryitempriortodelivery,batchtestingbythesupplierandpossible
randomchecksbythecustomer.

2.4GenericProcessIntroduction

Havingestablishedthecontextforthegenericprocessitisnowpossibletolook
insidetheEngineerRequirementsprocess.Theprocessisintroducedfirstlyinan
idealworldinwhichnothingeverchangesandthenwithmodificationstoaccom
modatechanges.

2.4.1IdealDevelopment

TheEngineerRequirementsprocessfortheidealworldisshowninFig.2.5.
Theprocesscommenceswiththeneedtoagreetheinputinformationfortheproject
withthecustomeratthelevelabove.Thesecondactivityintheprocessistoanalyse
theinputinformationandconsiderhowtodeveloptheoutputsrequired.This
activity,whichoftengoesoninparallelwithagreeingtherequirements,almost
alwaysinvolvesthecreationofoneormoremodelsandleadstoanalysisreports
thattogetherprovideabasisforthederivationofrequirementsandqualification
strategyforthelowerlevelsupplier(s).Theserequirementsmust,whentheyare
sufficientlymature,beagreedwiththesupplierstoformthebasisforacontractfor
thelowerleveldevelopment.
Figure2.5alsoindicatesthattheremaybeseveralsetsofderivedrequirements
generated.Eachsetmustbeagreedwiththerelevantsupplierandsomesuppliers
mayberesponsibleformorethanonecomponent.

2.4.2DevelopmentintheContextofChange

Unfortunatelytheworldhardlyeverstandsstill.Thisisespeciallytrueinthearena
ofsystemdevelopment.Itseemsthateverybodyisconstantlychanginghisorher
mindorfindingthatwhatwaspreviouslyagreedisnolongerpossible.Therefore

https://translate.googleusercontent.com/translate_f 46/211
2017520 RequirementsEngineering

Page52
32 2AGenericProcessforRequirementsEngineering

Agree Qualification
Input
Requirements Requirements Strategyfor
InputRequirements

Analyse
&
Model
Analysis
Model
Results

Derive
Requirements
&
Qualification
Strategy

Agree Qualification
QualificationStrategy
Output
Derived Requirements Strategy
forDerived
Requirements
Requirements Requirements

Fig.2.5Engineerrequirementsprocessforanidealworld

thegenericprocesshastobemodified,asindicatedinFig.2.6,toreflectthis
necessaryevil.
Theformalitywithwhichchangeismanagedwilldependuponthenatureand
stateoftheproject.Duringtheearlystages,changescanandmustbemadewith
easesothatprogresscanbemade.However,therecomesatimeatwhichacommit
mentmustbemadeandformalagreementstruck.Fromthistime,itisusualtohave
amoreformalarrangementinwhichchangesarenotjustinsertedatthewhimof
anyoneontheproject.Insteadaprocessisusedinwhichchangesarefirstrequested
orproposedandthentheyaredecideduponinthecontextoftheirimpactonthe
project.Thedecisionprocesswillusuallyinvolveapersonsuchastheproject
manager,whohastheauthoritytomakethedecisionsupportedasnecessarybya
groupofpeoplewhoconstituteachangecontrolboard.Againthedegreeof
formalitywithwhichthesepeopleoperatewilldependonthenatureoftheproject.
ThetopicofchangemanagementisaddressedinmoredepthinChapter8inthe
contextofprojectmanagement.
InFig.2.6itcanbeseenthatalmostanyactivitycanleadtothecreationofa
changeandthatthesechangesusuallyflowupwards.Thisdoesnotmeanthat
customersneverchangetheirmindsorthattheonlyproblemsdiscoveredarelower
leveldetailproblemsthatflowfromatopdownstrategy.Thesituationisthatthe
downwardpathisalreadyaccountedforinthenormalflows,butthereturnpathhas
tobeexplicitlycateredfor.Onetypicalsituationinwhichachangerequestmight

https://translate.googleusercontent.com/translate_f 47/211
2017520 RequirementsEngineering

Page53
2.5GenericProcessInformationModel 33

ChangeRequest

Input Agree Qualification

Requirements Requirements Strategyfor
InputRequirements

ChangeRequest

Analyse
&
Model
Model Analysis
Results

Change
Request

Derive
Requirements
&
Qualification
Strategy

ChangeRequest

Agree Qualification
QualificationStrategy
Output
Derived Requirements Strategy
Requirements forDerived
Requirements
Requirements

ChangeRequest

Fig.2.6Engineerrequirementsprocessincontextofchanges

ariseis,forexample,thatalimitationinamodelorananomalyinanalysisresults
maywellbediscoveredwhilstattemptingtogenerateaderivedrequirementorthe
qualificationstrategyforaderivedrequirement.Achangerequestwillrecommend
amodificationtothemodel(s)and/oradditionalanalysisworktoinvestigatethe
problem.Similarlyaproblemwithininputrequirementmaybeidentifiedduring
theanalysisandmodellingprocessleadingtothecreationofachangerequestfor
theAgreeRequirementsprocess.

2.5GenericProcessInformationModel

BeforeconsideringthesubprocesseswithinthegenericEngineerRequirementsprocess,
itisusefultointroduceagenericinformationmodelthatsupportstheprocess.
Thediagramsusedtorepresentthegenericprocesscontainbothprocesssymbols
anddataorinformationsymbols.Thediagramsindicate,viathearrows,which
informationisbeinggeneratedandusedbyeachprocess.
Thepurposeofaninformationmodelistoindicatewhattypesofinformation
existandwhetherrelationshipscanorshouldexistbetweentheitemsofinformation.

Page54
34 2AGenericProcessforRequirementsEngineering

https://translate.googleusercontent.com/translate_f 48/211
2017520 RequirementsEngineering

Itisalsousefultointroducestatetransitiondiagramstoindicatehowthestateof
eachtypeofinformationcanbechangedastimeproceeds.Consequentlythesestate
transitiondiagramscangiveavisualindicationofwhenandhowprocessesinteract
witheachotherviatheinformation.

2.5.1InformationClasses

Informationtypesalreadyencounteredinthegenericprocesscontextinclude:

Inputrequirement
Derivedrequirement
Qualificationstrategyforinputrequirements
Qualificationstrategyforderivedrequirements
Changerequest

Figure2.7showsthesefivetypesofinformationexpressedasaUnifiedModelling
Language(UML)classdiagram.Thenameoftheclassisalwaysshowninthe
uppermostsection(oronlysection)oftheclasssymbol.Themiddlesection
(ifpresent)indicatesthenamesofattributesthattheclasscanhave.Thebottom
section(ifpresent)containsanyoperations(oftencalledmethods)thatcanoperate
ontheclass.

Qualifies Qualification
Input *
Strategyfor
Requirement Qualified
* InputRequirements
by
AgreementState
AgreementState
QualificationState
SatisfactionState

Imposed
Satisfies* Details *
May
by * for
Impact
ChangeRequest *
Impacted *
By Satisfied Detailed
by * * Imposedon by
*
Qualifies Qualification
Derived *
Strategyfor
Requirement * Qualified
by
DerivedRequirements

AgreementState AgreementState
QualificationState
SatisfactionState

Fig.2.7Informationmodelforthegenericprocess

Page55
2.5GenericProcessInformationModel 35

Thelinesconnectingtheclasssymbolsshowrelationshipsbetweenclasses,and
thesearecalledAssociationsintheUML.ThusanInputRequirementcanberelated

https://translate.googleusercontent.com/translate_f 49/211
2017520 RequirementsEngineering

toaDerivedRequirementbyaSatisfiedbyrelationship.SimilarlytheDerived
RequirementcanberelatedtoanInputRequirementbytheinverseSatisfiesrelationship.
(TheselabelsareknownasrolesintheUML.)Theasteriskindicatesthatzeroor
moreinstancesoftheclasscanbeinvolvedintheassociation.Asterisksatbothends
indicatethattheassociationcanbemanytomany.ThusinthemodelofFig.2.7zero
ormoreInputRequirementscanbesatisfiedbyaDerivedRequirementandanInput
RequirementcanbesatisfiedbyzeroormoreDerivedRequirements.Somereaders
mayquestionthezerolowerlimit,becauseitsuggeststhatitisnotnecessarytohave
anyassociation.However,ifthelowerlimitweresetto1,thiswouldmeanthatan
InputRequirementcouldnotexistunlessitwasassociatedwithatleastoneDerived
Requirement.Clearlythisisanimpossiblesituation.ItisessentialthatInputRequirements
canexistpriortoDerivedRequirementsbeinggenerated.Consequentlythisisa
reasonablemodel,becausetheremaybetimesduringaprojectwhentherewillbeno
linksbetweeninputrequirementsandderivedrequirementsforexample,earlyinthe
developmentbeforethelinkshavebeenestablished.However,aprojectmanager
wouldexpectthattherewerelinksestablishedassoonaspossible.Thiswouldthen
indicatethatprogresshadbeenmadeandthatallderivedrequirementswerejustified
bybeingtheretosatisfyaninputrequirement,andconverselythatallinputrequirements
hadbeensatisfied.
TheQualificationstrategyclassescaneachqualifytheappropriatetypeofrequire
mentandthequalificationstrategyforthederivedrequirementscanprovidemore
detailsofanInputRequirementqualification.Thiscanoccur,forexample,insafety
criticalsystemswhereitmaybenecessarytoperformlowerleveldetailedinspections
thatcontributetothesatisfactionofthehigherlevelqualificationcriteria.
Asmentionedearlier,itispossiblethataqualificationstrategymayleadtothe
creationofspecialtestrigs.Thiswouldbeanexampleoftheimposedonrelation
shipbetweenthequalificationstrategyforaninputrequirementandoneormore
derivedrequirements.Furtherexamplesofthisrelationshipoccurwhen,inorderto
beabletocheckacomponent,itisnecessarytoprovideamonitorpoint.Such
monitorpointsareoftenessentialtobeabletochecktheperformance(speed,
response,throughput,etc.)ofasystemunderoperationalconditions.
AChangeRequestcanapplytoanyoftheotherfourclasses.Enclosingthefour
classesinsideanouterrectangleandmakingtherelationshiplinetouchthisouter
rectangleindicatesthis.
Themiddlesectionoftheclasssymbolsisusedtodefineattributesthattheclass
willhave.Therequirementclasseseachhavethethreeattributes:

Agreementstate
Qualificationstate
Satisfactionstate

Thesearedefinedinthefollowingsectionsbymeansofstatechartdiagrams.Theagree
mentstateofthequalificationclassesisassumedtohavethevalues:AgreedorNot
Agreed.

Page56
36 2AGenericProcessforRequirementsEngineering

2.5.2AgreementState

ThestatechartfortheAgreementstateisshowninFig.2.8.Inthistypeofdiagram
each(rounded)rectanglerepresentsthestateofasinglerequirementatsomepoint

https://translate.googleusercontent.com/translate_f 50/211
2017520 RequirementsEngineering

initshistory.TherectanglelabelledBeingAssessedisknownasasuperstate
becauseitcontainsotherstateswithinit.Thelinesconnectingonestatetoanother
indicatetransitionsthatcausethestatetochange.
TherequirementstatestartsoffintheProposedstate.Whenthecustomeris
contentthattherequirementissufficientlywellformulatedtobesenttothe
supplier,hesendsit.TheagreementstatethenenterstheBeingassessedsuper
state.Duringthisstate,thecustomerandsuppliernegotiateuntilanagreedrequire
mentemerges.
OnceintheAgreedstate,therequirementwillstaythereuntileitherthe
CustomerortheSuppliercreatesaChangeRequest.Whenthishappenstherequire
mentsstatereenterstheBeingAssessedstateuntilanewagreedrequirement
emerges.
WithintheBeingAssessedstate,thecustomerandsuppliertaketurnstosuggest
alternativeformsoftherequirementuntilanagreementisreached.Theagreement
statewillthereforebeinoneofthetwostatesshowndependingonwhichpartyis
currentlymakingtheassessment.

Proposed

Requirement
Proposedto
Supplier

Beingassessed
Alternative
proposalfrom
Supplier
Customer Supplier
assessingrequirement assessingrequirement
from from
Supplier Customer
Alternative
proposalfrom
Customer

Requirement
Change Change
Acceptable
from from
Supplier Customer
Agreed

Fig.2.8Statechartforagreementstate

Page57
2.5GenericProcessInformationModel 37

NoQualification
Strategydecided

Verification
criteria
agreed

https://translate.googleusercontent.com/translate_f 51/211
2017520 RequirementsEngineering

Changeimpacts
Qualification Qualification
Strategydecided Strategy
Changedoesnot
impact Change
Qualification proposed
Strategy
Qualification
Strategysuspect

Fig.2.9Qualificationstate

2.5.3QualificationState

ThequalificationstateofarequirementisshowninthestatechartofFig.2.9.Theinitial
stateisthatthereisNoQualificationStrategydecided.Whenthequalification
strategyhasbeenagreed,thestatecanproceedtothestateQualificationStrategy
decided.Thisstatecanthenremainuntilachangerequestisreceived.Thechange
maybedirectedeitherattherequirementitselforatthequalificationstrategy
associatedwithit.Whenachangeisrequested,thestatebecomesQualification
Strategysuspectuntiltheimpactofthechangehasbeenassessed.Thisassessment
determineswhethertheexistingqualificationstrategycanstand,andthestatecan
returntoQualificationStrategydecided,orwhetheranalternativestrategymustbe
decided,inwhichcasethestatebecomesNoQualificationStrategydecided.

2.5.4SatisfactionState

ThestatechartfortheSatisfactionstateisshowninFig.2.10.Thelogicofthisstateis
verysimilartothequalificationstates.ThestartingpointistheNotsatisfiedstateindicating
thatnoDerivedRequirementshavebeenrelatedtothisrequirement.Whentheinput
requirementhasbeensatisfiedbyoneormoreDerivedRequirements,thelowerlevel
supplieragreestherequirementandthehigherlevel(customer)agreesthattheDerived
Requirementswill,indeed,satisfytheInputRequirement,thestatecanbemovedtothe
Satisfiedstate.ItshouldbenotedthattheremightbemanyDerivedRequirementsthat
havetobeagreedbeforeeachsingleInputRequirementcanachievetheSatisfiedstate.

Page58
38 2AGenericProcessforRequirementsEngineering

Notsatisfied

Requirement
satisfied

Changeimpacts
lowerlevel
Satisfied
supplier

Changedoesnot
Change

https://translate.googleusercontent.com/translate_f 52/211
2017520 RequirementsEngineering
impactlower proposed
levelsupplier

Satisfaction
suspect

Fig.2.10Satisfactionstates

Whenachangeisproposed,theSatisfactionstateimmediatelybecomesSatisfaction
suspectirrespectiveofwhethertheproposedchangeisdirectedatthehigherorlower
levelrequirements.Thissuspectstateisretaineduntiltheimpactoftheproposedchange
hasbeenassessedandthesatisfactionstatecanthenbecomeNotsatisfiedorSatisfied.

2.5.5InformationModelConstraints

ChangerequestsbindtogethertheAgreement,QualificationandtheSatisfactionstate.
Registeringachangerequestimmediatelychangesallthreestatesandrequiresadditional
work,firstlytodeterminewhetherthereisanyimpact,andsecondlytoaddresstheconse
quences,ifany,oftheimpact.NotethattheSatisfactionstatecanrippleupanddownthe
requirementsthatarethesubjectoftheSatisfactionrelationship.Thisrippleeffectestab
lishesthepotentialextentofanyconsequentialchange,i.e.theimpactofthechange.
TheAgreementstateofDerivedRequirementsmustbeconsistentwiththeSatisfaction
stateofInputRequirements,sinceanInputRequirementcannotachieveitsSatisfiedstate
untilthelowerlevelsupplierhasagreedalloftheDerivedRequirementsthatsatisfyit.

2.6GenericProcessDetails

2.6.1AgreementProcess

Theagreementprocessisalwaysaconcurrentactivitybetweenasupplieratone
levelandthecustomeratthelevelaboveasindicatedinFig.2.11.

Page59
2.6GenericProcessDetails 39

Deriv eReq u iremen ts

&
Qu alificatio n Strateg y

Ch an g e
Req uest

Agree
Deriv ed Req u iremen ts Qualificatio nstrateg y
Deriv ed
Hig herLevel
& fo rDerived
Req u iremen ts
Resp on sib ility
Qu alificatio n Strateg y Requ irements

Ch an g e Chang e
Req u est/Prop o sal Req uest/Pro po sal
fro m fro m
Su p p lier Cu sto mer

Agree
Deriv ed Req u iremen ts Qualificatio nstrateg y
In p u t Lo werLevel
& forIn pu t
Req u iremen ts Resp on sib ility
Qu alificatio n Strateg y Requ irements

https://translate.googleusercontent.com/translate_f 53/211
2017520 RequirementsEngineering

Ch an g e
Req uest

An aly se

&
Mod el

Fig.2.11Theagreementprocess

Beforeanyderivationworkcancommence,itisnecessarytoassesstheInput
requirementstoascertainwhethertheyformanadequatebasisforthedevelopment
toproceed.
Theassessmentmustanswerthequestions:

Istherequirementcomplete?
Istherequirementclear?
Istherequirementimplementable?
Isthequalificationplanclearandacceptable?

Potentialanswerstothesequestionsleadnaturallytothefollowingreasonswhya
requirementmayberejected:

Missinginformatione.g.placeholderssuchasTBA(Tobeagreed),TBC(To
becompleted)orTBD(Tobedecided)maybeused
Lackofclarityambiguity,contradiction,confusion,etc.
Impossibletoimplementnoknownsolution
Unacceptablequalificationplan

Followingthereview,ifarequirementanditsqualificationplanareacceptablethe
statuscanbesettoAgreed.
Iftherequirementisnotacceptablethenanalternativeformissenttothe
customerandtheonuspassestothecustomer,andtheAgreementstate(see
Fig.2.8)becomesCustomerassessingrequirementfromSupplier.Ifthecustomer
iscontentwiththealternativewording,thenhecansetthestatetoAgreed.Ifnot,

Page60
40 2AGenericProcessforRequirementsEngineering

thenheproposesafurtheralternativeandsendsittothesupplier.TheAgreementstate
becomesSupplierassessingrequirementfromSupplier,andtheonusreturnsto
thesupplier.
Thisprocessofproposalandcounterproposalcontinuesuntilanagreementis
reached.Ofcourseitispossiblethatagreementmayneverbereachedandadispute
emerges.
WheneitherpartyproposesachangetheBeingassessedsuperstateisentered
withtheonusonthepartyreceivingthechange.Negotiationfollowsasdescribed
earlieruntilanewagreedformcanbereached.
Duringtheagreementprocess,ChangeRequestsmaybegeneratedbythecus
tomersidetorequestthatthederivedrequirementismodified.Thesewillpasstothe
DeriveRequirementsandQualificationstrategyprocesssothattheeffectofthe
changecanbeassessedand,wherenecessary,adjustmentsmadetooneormoreof
thederivedrequirements.Ofcourseitcanhappenthatthechangecannotbehandled
completelyatthislevelandthechangemayhavetobeescalatedtotheModelling

https://translate.googleusercontent.com/translate_f 54/211
2017520 RequirementsEngineering

andAnalysisprocess.Thisneedtoescalatethedecisionprocessupthroughthe
levelsmakesitimperativethatpeopleareworkingateachlevel.Inotherwordsitis
necessarytoworkconcurrentlyonseverallevelssimultaneously.Thisneedcompletely
destroysthenotionofthewaterfalllifecycleinwhichasequenceofactivitiestakes
placeinastricttopdownorder.Insteadofasequenceofactivities,development
takesplaceasaconcurrentsetofnegotiationsanddecisiontaking.
Inmanyprojectstheacceptancecriteriaandqualificationplansareonlydecided
quitelate.Thiscanbewellaftertherequirementsthemselveshavebeenagreedand,
insomecases,agreementisonlyreachedjustpriortothecommencementoftest
ing.Thisisverybadpracticeandusuallyleadstodelayscausedbylatechangesin
requirementstomakethemtestable!

2.6.2AnalyseandModel

Figure2.12portraystheAnalyseandModelprocess.Theanalysispartofthispro
cessisprimarilyconcernedwithunderstandingthenatureandscopeoftheinput
requirementstoassessthelikelyrisksinvolvedinsatisfyingthem.Analysisworkcan
rangefromfeasibilitystudiestoexplorepotentialimplementationoptionstothe
buildingofprototypesofsomevitalorhighriskcomponents.Itisoftennecessaryto
buildperformancemodelstoinvestigatepotentialthroughputandresponsefigures.
Theotherusesofmodelsinthisprocessaretounderstandthenatureofand
provideastructureforthederivedrequirements.Themostcommonmodelsfor
understandingandstructuringStakeholderRequirementsareusecasesorUser
Scenarios.Thesehelptounderstandhowpeoplewillusetheintendedsystem.
Themostcommonmodelsforstructuringsolutionsinthesolutiondomainaredesign
architectures.Theseidentifyelementsofthesolutionandindicatehowtheyinteract.
Inalotofcasesthemodelisusedtoestablishthedesignarchitectureofthe
proposedsolution.Thesemodelsarefrequentlyquiteobviousforwellestablished

Page61
2.6GenericProcessDetails 41

developmentdomains(e.g.automobiles,telecommunications,aircraft,etc.)where
adefactoarchitectureexists.However,forinnovativedevelopmentswherethereis
noestablishedarchitecturethemodelmaybemoreabstracttoallowforpotential
alternatives.
Ingeneral,themodelsusedwilldependentirelyonthenatureofthedevelop
mentthatisbeingundertaken.Asindicatedearlierthetypesofmodelsusedare
verymuchdomainspecific.Insoftwaresystemsitisincreasinglythecasethat
objectmodelsareused.Table2.1indicatesdifferentsortsofmodelsusedinthree
industrialdomains.
Thepointofdevelopingthemodelsistounderstandtheinputrequirements
togetherwiththeproposedqualificationstrategyandexperimentwithalternative
solutionoptionspriortodecidinghowtoproceedwiththecreationofderived
requirements.Thisworkwillalsoconsiderpossiblequalificationstrategiesforthe
derivedrequirementsandthis,inturn,mayleadtothecreationofrequirementsfor
testequipmentand/orsoftware.Itcanalsoleadtotheidentificationofqualification
requirementsforthederivedrequirements.
TheAnalyseandModelprocesscanbeundertakeninparallelwiththeAgree
processsinceitislikelytogeneratedeeperinsightintothenatureofthe
https://translate.googleusercontent.com/translate_f 55/211
2017520 RequirementsEngineering

requirements.
InChapter3somewidelyusedmodellingtechniquesarereviewedespecially
consideringthoseusedinthesoftwareindustry.Chapter5explainshowtouseUser
ScenariomodelstoaidtheunderstandingofStakeholderrequirements,while
Chapter6considersfunctionorientedmodelsthathelptoprovideaframeworkfor
systemrequirements.
Duringtheanalysisandmodellingprocess,itisquitelikelythatfurtherques
tionswillariseconcerningthemeaningandformulationofinputrequirements.This
givesrisetochangerequests,whichcausetheAgreeRequirementsprocesstobe
reentered.

Table2.1Examplesof
modelingtechniques
Aircraftindustry
Aerodynamicmodel
Threedimensionalspatialmodel
Weightdistributionmodel
Flightsimulator
Railindustry
Timetablesimulation
Safety,reliabilityandmaintainability
models
Carindustry
Stylingmodel
Dashboardmodel
Aerodynamicmodel

Page62
42 2AGenericProcessforRequirementsEngineering

Agree
Input Qualificationstrategy
IR&IQS
Requirements forInput
Requirements

Change
Request

Analyse
&
Model

Model Analysis
Model
Results
Change
Request

Derive
Requirements
&
Qualification
Strategy

Fig.2.12Analyseandmodelprocess

https://translate.googleusercontent.com/translate_f 56/211
2017520 RequirementsEngineering

2.6.3DeriveRequirementsandQualificationStrategy
Fig.2.13PortraystheProcessforDeriving
RequirementsandQualificationStrategy

2.6.3.1DerivingRequirements

Thewayinwhichthemodelsareusedforthispurposevaries,butthesimplestone
toconsiderinitiallyisthederivationofcomponentrequirementsbasedonadesign
architecture.Hereitispossibletodeterminethespecificrequirementsthatmustbe
satisfiedbyeachcomponent.Someoftheserequirementsmaybeidenticaltoone
ormoreinputrequirementsothersmayhavebeenderivedfrominputrequirements
inordertopartitionthemamongstthecomponents.Afurthersetofrequirements
consistsofconstraintsimposedeitherbythecomponentarchitectureorinput
requirements.Theseconstraintsincludeinterfaceconstraintsandpossiblephysical
constraintssuchasmass,volume,powerusageandheatdissipation,etc.
Inpractice,someworkontheallocationorderivationofrequirementsforcom
ponentsmayproceedinadvanceoffinalagreementsontheinputrequirementsand
theirqualificationstrategy.However,itisnotpossibletocompletethisactivityprior
tofinalagreement.
Inadditiontoestablishingthecomponentrequirements,itisalsonecessaryto
establishthesatisfactionrelationshipbetweentheinputrequirementsandthe
derivedrequirements.Thisrelationshipindicateswhichinputrequirementsare
satisfiedbywhichderivedrequirementsandcanbeusedtoestablishthat:

Page63
2.6GenericProcessDetails 43

Analyse
& Qualificationstrategy
Input
Model forInput
Requirements Requirements
Model Analysis
Model
Results
Change
Request

Derive
Requirements
&
Qualification
Strategy

Change
Request

Output Agree Qualificationstrategy

Derived Qualificationstrategy
Requirements DR&DQS forInput
Requirements forDerived
Requirements
Requirements

Fig.2.13Deriverequirementsandqualificationstrategyprocess

Allinputrequirementsaresatisfied.
https://translate.googleusercontent.com/translate_f 57/211
2017520 RequirementsEngineering

Allderivedrequirementsarenecessary(i.e.theydirectlyorindirectlysatisfyone
ormoreinputrequirements).

Itisnotsufficientjusttoassertthatasatisfactionlinkexists,asforexampleina
crossreferencematrix.Thejustificationforeachlinkshouldalsobestated.These
justificationstatementsconstituteasatisfactionargument.
Duringtheprocessofgeneratingrequirementsfromthemodels,itmaybecome
clearthatthereisadefectoranomissioninoneormoreofthemodels.Thiscauses
achangerequesttobeissuedbacktothemodellingteamwhowilltheneither
modifythemodeldirectlyoraskforfurtherclarificationorchangetoinputrequire
ments.Thusthechangeescalationprocesscontinues.

2.6.3.2DerivingtheQualificationStrategy

Asdiscussedabove,thesatisfactionrelationshipisaboutgeneratingderived
requirementsfrominputrequirementshowthesystemisdesigned.Incontrast,the
qualificationstrategyplanshoweachrequirementwillbetestedateachlevel.
Thequalificationstrategyconsistsofasetofqualificationactions,eachonea
particularkindoftrial,testorinspection.Theremaybeseveralqualificationactions
definedagainsteachrequirement.
Eachqualificationactionshouldtakeintoaccountthefollowingaspects:

Page64
44 2AGenericProcessforRequirementsEngineering

The kindofactionthatwouldbeappropriatefortherequirement.
The stageatwhicheachactioncouldtakeplace,theearlierthebetter.
Anyspecial equipmentthatwouldbeneededfortheaction.
Whatwouldconstituteasuccessful outcome?

Thequalificationplanmaybestructuredeitheraccordingtothestageoraccording
tothetypeofaction.
Thequalificationactionsdefinedshouldbeappropriatetothelevelofrequire
ments.Inotherwords,stakeholderrequirementsgiverisetoacceptancetrials,
whereassystemrequirementsgiverisetosystemtests,i.e.priortodeliverytothe
customer.Itisnotnecessarytodefinesystemtestsagainststakeholderrequire
ments,sincethosesystemrequirementsderivedfromthestakeholderrequirement
willhavetheirownsystemtests.
Take,forinstance,theexampleshowninFig.2.14inwhichasystemrequire
mentforashipisdecomposedintotworequirementsondifferentsubsystems,the
hullandthepropulsionsystem.Twoqualificationtestsareplannedagainstthe
systemlevelrequirement,andtwomoreagainstthesubsystemrequirements.
Thus,forafullunderstandingofhowarequirementwillbetested,boththe
satisfactionrelationshipandthequalificationstrategyarenecessary.Tounderstand
thequalificationstatusofahighlevelrequirement,theresultsofqualification
actionsagainstrequirementsthatflowdownfromitatalllevelshavetobetakeninto
account,bymakinguseofthesatisfactionaswellasthequalificationrelationship.

System
SystemQualification
Requirements
Strategy
Thevesselshallbe

https://translate.googleusercontent.com/translate_f 58/211
2017520 RequirementsEngineering
capableoftravelling qualification Seatrialofvesselin
at40knotswhileinupto seaconditionA
seaconditionD.
Seatrialofvesselin
seaconditionD

satisfaction
Subsystem
QualificationStrategy
Subsystem
Dragcoefficenttests
Requirements
usingaprebuildscale
Thehullshallpresenta
model.
maximumdrag
coefficentofX.
Subsystem
Subsystem QualificationStrategy
Requirements Useoffactorytestrig
Theenginesshalldeliver tomeasurepoweroutput.
aminimumthrustofY.

Reviews/Designinspections/Analysis/Prototypes/Componenttests/Rigtests/Systemtests/Trials

QualificationProgramme
time

Fig.2.14Qualificationinformation

Page65
2.7Summary 45

2.7Summary

Agenericprocessthatcanbesimultaneouslyappliedateachlevelinasystem
developmenthasbeenpresented.Thebenefitofthisgenericprocessisthatitidenti
fiescommonactionsthatarerelevantateverylevel:

Agreeinginputrequirementswithcustomer
Analysisofinputrequirementstodeterminetherisksandpotentialpitfallsin
satisfyingtherequirements
Creatingoneormoremodelstoinvestigatepossiblestrategiesforderiving
requirements
Generatingrequirementsderivedfromtheinputrequirementsviatheanalysis
andmodellinginformation
Agreeingthederivedrequirementswiththeteam(s)thatwillberesponsiblefor
implementingthem
EstablishingthesatisfactionrelationshipbetweenInputRequirementsand
derivedrequirements
Establishingthequalificationrelationshipbetweenderivedrequirementsandthe
relevantqualificationstrategy

Theseactionsleadtotheestablishmentofinformationaccordingtotheinformation
modelpresented.Thecurrentstateoftheinformationcanbeusedtomeasure
progress,toassesstheimpactofproposedchangesandtodefinemetricsonhowa
projectisperforming.Forexample,thestateofarequirementcanbecapturedby
itsthreeattributes:

Agreement
Satisfaction
Qualification

https://translate.googleusercontent.com/translate_f 59/211
2017520 RequirementsEngineering

Theidealstateforanyrequirementinanysystemdevelopmentisthatitshouldbe:

Agreedbetweencustomerandsupplier
Haveaqualificationstrategyagreedforit
Besatisfiedbylowerlevelrequirements(ordesign)

Theextenttowhichaprojectsrequirementsdeviatefromthisidealstaterepresents
thedegreeofrisktowhichtheprojectisexposedfromtherequirementsmanage
mentpointofviewandalsoindicatestheextentoftheworknecessarytogetthe
requirementsintotheidealstate.

Page67
Page66

Chapter3
SystemModellingforRequirements
Engineering

Artandsciencehavetheirmeetingpointinmethod.

EdwardBulwerLytton,poet,18031873AD

3.1Introduction

Systemmodellingsupportstheanalysisanddesignprocessbyintroducingadegree
offormalityintothewaysystemsaredefined.Duringsystemdevelopmentitis
oftenthecasethatpicturesareusedtohelpvisualizesomeaspectsofthedevelop
ment.Modellingprovidesawayofformalisingtheserepresentations,through
diagrams,bynotonlydefiningastandardsyntax,butalsoprovidingamediumfor
understandingandcommunicatingtheideasassociatedwithsystemdevelopment.
Theartofmodellingisarguablythemostcreativeaspectoftheworkofthe
systemsengineer.Thereisnorightsolutionandmodelswillevolvethroughvari
ousstagesofsystemdevelopment.Modelsaremostoftenrepresentedvisuallyand
theinformationisthereforerepresentedthroughconnecteddiagrams.Newmethods
suchasobjectorientationhaveadvancedtheconceptofmodelling,howevermost
https://translate.googleusercontent.com/translate_f 60/211
2017520 RequirementsEngineering

approachesarealsobasedontheprinciplesusedandtestedovertime.
Agoodmodelisonewhichiseasilycommunicated.Theyneedtobeusedfor
communicationwithinadevelopmentteam,andalsotoanorganisationasawhole
includingthestakeholders.Theusesofamodelcanbediverseandcoverawide
spectrum.Itmightbetomodeltheactivitiesofanentireorganisationortomodel
aspecificfunctionalrequirementofasystem.
Modellinghasthefollowingbenefits:

Encouragestheuseofa preciselydefinedvocabularyconsistentacrossthe
system.
Allowssystemspecificationanddesigntobe visualizedindiagrams.
Allowsconsiderationof multipleinteractingaspectsandviewsofasystem.
Supportsthe analysisofsystemsthroughadefineddiscipline.
Allows validationofsomeaspectsofthesystemdesignthroughanimation.

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_3, 47
SpringerVerlagLondonLimited2011

Page68
48 3SystemModellingforRequirementsEngineering

Allows progressiverefinementtowardsdetaileddesign,permittingtestcase
generationandcodegeneration.
Encourages communicationbetweendifferentorganizationsbyusingcommon
standardnotations.

Muchofthecreativityandartofthesystemsengineerisexpressedintheuseof
modellingtechniques.Thischapterconsidersanumberoftheserepresentationsand
alsosomemethodsforRequirementsEngineeringthatusethem.

3.2RepresentationsforRequirementsEngineering

3.2.1DataFlowDiagrams

Dataflowdiagrams(DFDs)arethebasisofmosttraditionalmodellingmethods.
Theyaretheminimalistgraphicalrepresentationofthesystemstructureandinter
facesandalthoughinitiallyproducedforuseindatarepresentationandflow,the
diagramscaninfactbeusedtoshowanytypeofflow,whetheracomputerbased
systemornot.TheoneoutputwhichDFDsdonotshowisthatofcontrolflow.
Theelementsinadataflowdiagramconsistof

Dataflows(labelledarrows)
Datatransformations(circlesorbubbles)
Datastores(horizontalparallellines)
Externalentities(rectangles)

ThesimpleexampleinFig.3.1showstheuseofadataflowdiagraminitstradi
tional,informationsystemscontext.
Flowsrepresenttheinformationormaterialexchangedbetweentwotransforma
tions.Inrealworldsystems,thismaybecontinuous,ondemand,asynchronousetc.
Whenusingthenotation,diagramsmustbesupportedbytextualdescriptionsof
eachprocess,datastoreandflow.

https://translate.googleusercontent.com/translate_f 61/211
2017520 RequirementsEngineering

Adatadictionaryisusedtodefinealltheflowsanddatastores.Eachleafnode
bubbledefinesthebasicfunctionalityprovidedbythesystemcomponents.These
aredescribedintermsofaPspecorminispec.Thisisatextualdescriptionoften
writteninapseudocodeform.
ThecontextdiagramisthetopleveldiagramofaDFDandshowstheexternal
systemsinteractingwiththeproposedsystem,asinFig.3.2.
Bubblescanbedecomposedanotherlayerdown.Eachbubbleisexplodedinto
adiagramwhichitselfmaycontainbubblesanddatastores.Thisisrepresentedin
Fig.3.3.
ToillustratetheuseofaDFD,consideranexampleofacontextdiagramforan
AmbulanceCommandandControlsystem(Fig.3.4).Thisisthestartingpointfor
adataflowanalysisofthesystem.

Page69
3.2RepresentationsforRequirementsEngineering 49

Creditcardholder

Checkdetails

Transactions

Process
transaction

Printreceipt

Printer
Accountssystem

Fig.3.1Dataflowdiagram

Creditcardholder

ATM
system

Printer
https://translate.googleusercontent.com/translate_f 62/211
2017520 RequirementsEngineering
Accountssystem

Fig.3.2Contextdiagram

Theprimaryexternalentitiesarethecallers,whomaketheemergencycalls,and
theambulances,whichwillbecontrolledbythesystem.Notethatrecordsarean
importantoutputofthesystem(infactalegalrequirement)andaveryimportant
meansofmeasuringperformance.

Page70
50 3SystemModellingforRequirementsEngineering

3.5.1
1 4 3.1
3.5
0
3.2 3.5.3

3
2
3.4 3.5.2
3.3

Context Level1
diagram Level2

Level3

Fig.3.3Functionaldecomposition

Context Caller
Otherpotential
external
entities
Police

Firebrigade

Other
ambulance
C&C
systems

Civildefence
Ambulance Records

Fig.3.4ContextdiagramforAmbulanceC&CSystem

Otherpotentialexternalentitiesthatwouldberequiredforarealsystemare
showninthediagram,butforsimplicityweshallignorethem.
Thenextstepistoidentifytheinternalfunctionalityofthesystem.Usuallystart
ingbydrawingafunctionforeachexternalentityastheminimaldecomposition
andthendrawingthebasicdatathatmustflowbetweenthesetoplevelfunctions
seeFig.3.5.
Followingthis,decompositionofthetoplevelfunctionstakesplacethus
includingmoredetail,asshowninFig.3.6.
Thefunctionalhierarchyinasetofdataflowdiagramscanbeusedasaframe
workforderivingandstructuringsystemrequirements.Figure3.7showsthe
functionalstructurefortheAmbulanceCommand&Controlexamplederived
https://translate.googleusercontent.com/translate_f 63/211
2017520 RequirementsEngineering

fromFig.3.6.
Figure3.7alsoindicatessomeexamplesofrequirementsderivedfromthis
structure.
Thehierarchicalbreakdownandinterfacesgiveagoodviewofthecomponent
model,buttheygiveapoorviewofthetransactionsacrossthesystemi.e.from
inputtooutput(ortocompletesomesystemaction)ascanbeseeninFig.3.8.

Page71
3.2RepresentationsforRequirementsEngineering 51

Caller

Handlecallers

Currentincidents

Handleambulances

Keeprecords

Ambulancestates Records
Ambulance

Fig.3.5ModelforAmbulanceC&Csystem

Caller
Communicate
Handle with
callers caller

Obtain
incident Provide
online
details
advice
Analyze
incident

Handle
Allocate
ambulances ambulance
Currentincidents

Communicate
with Keep
Monitor Provide
ambulances Monitor records
incidents statistics
ambulance
states

Ambulancestates Records
Ambulance

Fig.3.6DetailedmodelforAmbulanceC&Csystem

https://translate.googleusercontent.com/translate_f 64/211
2017520 RequirementsEngineering

Itisthereforenecessarytoobservethesetransactionsacrossthesysteminterms
ofthepath(s)theyfollow,thetimetheytakeandtheresourcestheyabsorb.
Animatingthestakeholderrequirementsandbeingabletoseewhichfunctionsare

Page72
52 3SystemModellingforRequirementsEngineering

Communicatewithcaller

Obtainincidentdetails
Theobtainincident
Handle detailsfunctionshall
callers Analyzeincident allowthecallcentrestaff
toobtainandrecord
incidentdetailsfromthe
Provideonlineadvice caller.

Theallocateambulance
Allocateambulance
C&C functionshallallowthe
system controllertoallocatean
Handle
Communicatewithambulances ambulancetoanincident.
ambulances

Monitorambulancestates

Monitorincidents
Keep
records
Providestatistics

Fig.3.7FunctionalstructureforAmbulanceCommand&Controlsystem

Aninput
here.
Communicatewithcaller

Obtainincidentdetails

Handle
callers Analyzeincident
Performance:
endtoendtime
Provideonlineadvice
<15seconds

Allocateambulance
C&C
system
Handle Communicatewithambulances
ambulances .causes
output
Monitorambulancestates here.

Monitorincidents
Keep
records
Providestatistics

Fig.3.8Systemtransactions

operating,willillustratemajortransactions,butanalternativewayofshowingthe
systemtransactionsistomarkthemontoadataflowdiagramasshowninFig.3.9,
https://translate.googleusercontent.com/translate_f 65/211
2017520 RequirementsEngineering

usingthethickarrows.

Page73
3.2RepresentationsforRequirementsEngineering 53

Communicate Caller

Handle with

Paththroughmodel callers caller

shownbyarrows:
Obtain
Provide
incident
online
details
advice
Analyze
incident

Handle
Allocate
ambulances
ambulance
Currentincidents

Communicate
with
Keep
ambulances Monitor Provide records
Monitor incidents statistics
ambulance
states

Ambulancestates Records
Ambulance

Fig.3.9SystemtransactionsforAmbulanceCommand&Controlsystem

DFDsaregoodatpresentingstructuresbuttheyarenotveryprecise.DFDsare
lessprecisethantextfordevelopingacompletedefinitionofasysteminterface
linescanmeananything,andsinglewordscansummarizeanything.Theycannot
handleconstraintsproperly.
ADFDclearlyshowsfunctionsandinterfaces.Itcanbeusedtoidentifyendto
endtransactions,butdoesnotdirectlyshowthem.Ideallywewouldliketoview
thediagramswithanexpandinplaceapproachsothatitispossibletoviewthe
contextinwhicheachlevelofdecompositionisintendedtowork.FewCASEtools
providethisleveloffacility.
Figure3.6actuallybreakstheconventionsfordrawingDFDs,becauseitshows
adecompositionoftheoverallsystemintoseveralprocessesanditalsoshows
externalagencieswithwhichthesystemmustinteract.Weadvocateapragmatic
useofDFDs,ratherthanstrictadherencetoaconceptuallypureideal.Tofollow
preciselytherulesfordrawingDFDs,theexternalagenciesshouldappearonlyin
thecontextdiagram,andhenceshouldnotbevisibleatthislevel.However,the
diagramwouldbefarlessmeaningfuliftheexternalagencieswerenotshownand
theflowstothemleftdangling(whichisthedefinedconventionforthem).
Insummary,DFDs:

Showoverallfunctionalstructureandflows.
Identifyfunctions,flowsanddatastores.

https://translate.googleusercontent.com/translate_f 66/211
2017520 RequirementsEngineering

Page74
54 3SystemModellingforRequirementsEngineering

Identifyinterfacesbetweenfunctions.
Provideaframeworkforderivingsystemrequirements.
Toolsareavailable.
Widelyusedinsoftwaredevelopment.
Applicabletosystemsingeneral.

3.2.2EntityRelationshipDiagrams

Modellingtheretainedinformationinasystem,forexampleflightplans,system
knowledgeanddatabaserecords,isoftenimportant.Entityrelationshipdiagrams
(ERDs)provideameansofmodellingtheentitiesofinterestandtherelationships
thatexistbetweenthem.Chen(1976)initiallydevelopedERDs.Thereisnowa
verywidesetofalternativeERDnotations.
Anentityisanobjectthatcanbedistinctlyidentifiedsuchas:customer,supplier,
part,orproduct.Aproperty(orattribute)isinformationthatdescribestheentity.
Arelationshiphascardinality,whichexpressesthenatureoftheassociation(one
toone,onetomany,manytomany)betweenentities.Asubtypeisasubsetof
anotherentity,i.e.atypeXisasubtypeofYifeverymemberofXbelongstoY.
ERDsdefineapartialmodelofthesystembyidentifyingtheentitieswithinthe
systemandtherelationshipsbetweenthem.Itisamodelthatisindependentofthe
processingwhichisrequiredtogenerateorusetheinformation.Itisthereforean
idealtooltousefortheabstractmodellingworkrequiredwithinthesystemrequire
mentsphase.ConsidertheexampleAmbulanceC&CsysteminFig.3.10.

0..N 0..N
Person Incident
involves
1..1 1..1

isa isallocated

0..1 0..1
isallocated
Crewmember Allocation Hospital
0..1 0..N
1..N 0..1

consistsof hasresource

0..N 0..N

0..1 0..1
Crew Ambulance
isstaffedby

Fig.3.10ERDforAmbulanceC&Csystem

https://translate.googleusercontent.com/translate_f 67/211
2017520 RequirementsEngineering

Page75
3.2RepresentationsforRequirementsEngineering 55

3.2.3Statecharts

Functionalityanddataflowsarenotenoughforrequirementsdefinition.Itisalso
necessarytobeabletorepresentthebehaviourofthesystemandinsomecircum
stancesconsiderthesystemashavingafinitenumberofpossiblestates,with
externaleventsactingastriggersthatleadtotransitionsbetweenthestates.
Torepresenttheseaspectsitisnecessarytoexaminewhatstatesthesystemcan
beinandhowitrespondstoeventsinthesestates.Oneofthemostcommonways
ofdoingthisistouseHarelsStatecharts(Harel1987).
Statechartsareconcernedwithprovidingabehaviouraldescriptionofasystem.
Theycapturehierarchywithinasinglediagramformandalsoenableconcurrency
tobedepictedandthereforetheycanbeeffectiveinpracticalsituationswhere
parallelismisprevalent.Alabelledboxwithroundedcornersdenotesastate.
Hierarchyisrepresentedbyencapsulation,anddirectedarcs,labelledwitha
descriptionoftheevent,areusedtodenoteatransitionbetweenstates.
Thedescriptionsofstate,eventandtransitionmakestatechartssuitablefor
modellingcompletesystems.
Figure3.11presentsastatechartforanaircraftflight.Thetwotoplevelstates
areAirborneandOnGround,withdefinedtransitionsbetweenthem.Inside
theAirbornestate,therearethreeindependentsetsofstates,whilewithinthe

OnGround Aircraft
Abletotaxi

Ta x iin

Taxiing OnStand

Ta x io ut

Clearedfortakeoff

OnRunway

Readyfor Airborne
takeoff

Ascending
Wheelsoff

Takingoff
Inflight
Abort

Cruising
Abort Takeoff
aborted
Cleared
toland
Land Touchdown
Landed Descending

Abort

Fig.3.11Statechartforaircraftflight

https://translate.googleusercontent.com/translate_f 68/211
2017520 RequirementsEngineering

Page76
56 3SystemModellingforRequirementsEngineering

OnGroundstatetherearestatesforAbletoTaxiandOnRunway.Inside
theOnGroundstate,therearefurtherstatesfortaxiingandonstand.
TheAirbornestateisenteredwhentheaircraftwheelsleavethegroundandthe
OnGroundstateisenteredwhenthewheelstouchdown.Eachofthesestatescan
nowbefurtherrefinedinahierarchicalway.
Statechartsintroduceonefurtherusefulnotion,thatofhistory.Whenastatewith
the(H)annotationisreentered,thenthesubstatethatwasexitedisalsoreentered.

3.2.4ObjectOrientedApproaches

Objectorientationprovidesaratherdifferentapproachfromthatofthestructured
analysisapproach.Objectsdescribestable(andhopefully)reusablecomponents.
Objectorientationtriestomaximizethisreusabilitybyaskingthesystems
engineertopickpersistentobjectsi.e.thosethatcanbeusedinsystemrequirements
anddesign.
Sothegoalsofobjectorientationareto:

Encapsulatebehaviour(statesandevents),information(data)andactionswithin
thesameobjects.
Trytodefine persistentobjects,whichcanbeusedwithinbothrequirementsand
designphases.
Addinformationbydefiningthe objectsinmoredetail.
Createnewobjectsbyspecialisationofexisting objects,notcreationofnew
objects.

Objectorientationfocusesonthebehaviourofobjects,andtheirinter
relationships.Aflatorganizationofobjectsissometimesassumed,butthisisnot
necessary,orevendesirable.Theanalystlooksforentitiesthatarelonglived,and
modelsthebehaviourofthesystemaroundthem.Thisapproachgivesacoherent
behaviouraldefinitionofthesystem.Systemelementsshouldbereusablebecause
theelements(ifnottheirbehaviour)canbeincrementallyenhanced.
Somemethodologistsinsistthatdesign(andevenimplementation)isrefinement
oftheanalysismodels.Thiscanbeatallorderfornontrivialsystems.However,
theprogressionfromanalysis,designtoimplementationisoftenfarclearerin
objectorientationthaninotherapproaches.Moreanalysiselementsendupbeing
representedintheimplementationthaniscommoninstructuredanalysisand
design.Thisisatremendousaidtotraceabilityandmaintainability.

3.2.4.1ClassDiagrams

Theclassdiagramisthebasicdiagrammingnotationfromobjectorientedanalysis
anddesign.Objectorientationaroseoutofcomputerbasedsimulation.Thebasic
principleisthatthecontentsofasoftwaresystemshouldmodeltherealworld.

Page77
3.2RepresentationsforRequirementsEngineering 57

https://translate.googleusercontent.com/translate_f 69/211
2017520 RequirementsEngineering

Account Owner

balance name

checkbalance
deposit
withdraw

Fig.3.12Classdiagram

Thenaturalwaytohandlethisistohaveobjectsinthesoftwarethatrepresent
entitiesintherealworld,bothintermsofinformationandactions.
Forexample,inabankingsystem,insteadofhavinganaccountsfileand
separateaccountsprograms,thereareaccountsobjectsthathaveinformation
suchasbalanceandoverdraftlimitandrelationshipstootherobjectssuchas
accountowner.Theseobjectshaveoperations(alsocalledmethods)tohandle
theactionsthatareperformedonaccounts,likecheckbalance,deposit,with
draw,etc.
Theoriginalreasoningbehindthisapproachwasthatitmadesoftwaredevelop
mentfarmoreakintomodelling,andthereforemorenatural.Aswithmanygood
ideas,practicalitiesintervene,andfewobjectorientedsoftwaresystemscanbe
seenaspurerepresentationsoftherealworld.Nevertheless,thereisstillconsider
ablemeritinthemethod.
Aclass(orobject)diagramisshowninFig.3.12.
Classdiagramsexpressinformationaboutclassesofobjectsandtheirrelation
ships.Inmanyways,theyaresimilartoentityrelationshipdiagrams.Likethem,
theyshowhowobjectsofacertainclassrelatetootherobjectsofthesameor
differentclasses.Theprincipaladditionalpiecesofinformationare:

Operations(methods)
Theconceptofgeneralization
Attributeswithintheobjects

3.2.4.2UseCases

Usecasesdefinetheinteractionthattakesplacebetweenauserofasystem(an
actor)andthesystemitself.TheyarerepresentedasprocessbubblesinaDFDtype
ofcontextdiagram.Theusecasediagramcontainstheactorsandtheusecasesand
showstherelationshipbetweenthem.Eachusecasedefinesfunctionalrequire
mentsforthesystem.Actorsdonotneedtobehuman,eventhoughtheyarerepre
sentedasstickfigures,butinfactrepresentroles.Eachoftheactorswillhavean
associationwithatleastoneusecase.

Page78
58 3SystemModellingforRequirementsEngineering

Banking

https://translate.googleusercontent.com/translate_f 70/211
2017520 RequirementsEngineering
System
OpenA/C

CheckBalance

Customer

Deposit

SetupA/C

Withdrawal

Manager
SetOverdraft
Limit

Fig.3.13Usecasediagramforbankingsystem

Thesystemboundaryisalsodefinedontheusecasediagrambyarectangle,
withthenameofthesystembeinggivenwithinthebox.Normallysignificant,and
useful,textualinformationisassociatedwitheachusecasediagram.
Figure3.13presentsausecasediagramforabankingsystem.

3.3Methods

Amethodisadegreemoreprescriptivethanamodellingapproachittellsuswhat
todotoandinwhatordertodoit.Methodsusevariousrepresentationsranging
fromnaturallanguage,throughdiagrammaticformstoformalmathematics.
Methodsindicatewhenandwheretousesuchrepresentations.Thosemethodsthat
usediagrammaticrepresentationsareusuallyreferredtoasstructuralmethods
thosethatuseobjectorientationarereferredtoasobjectorientedmethodsand
thosethatusemathematicsarereferredtoasformalmethods.
Thepurposeoftherepresentationsusedinamethodistocaptureinformation.
Theinformationcaptureisaidedbydefiningthesetofconceptsthatadiagram
represents,andthesyntacticrulesthatgovernthedrawingofdiagrams.
Aswehaveseenintheearliersectionsofthischapter,thereareavarietyof
differentrepresentationsusedforsystemmodelling.MostmethodsYourdon(1990),
DeMarco(1978),ShlaerandMellor(1998),Rumbaugh(1991),tonamebutafew,

Page79
3.3Methods 59

areareorganizationoftheseconcepts,varyingthechoiceandtheorderinwhichthey
aredone,oftenwithminorenhancements.Interestingly,similaritiesbetweenthese
methodsarefarmorestrikingthantheirdifferences.

https://translate.googleusercontent.com/translate_f 71/211
2017520 RequirementsEngineering

3.3.1ViewpointMethods

AviewpointbasedapproachtoRequirementsEngineeringrecognisesthatrequire
mentsshouldnotbeconsideredfromasingleperspective.Itisbuiltonthepremise
thatrequirementsshouldbecollectedandindeedorganisedfromanumberof
differentviewpoints.Basicallytwodifferentkindsofviewpointhavebeenproposed:

Viewpointsassociatedwithstakeholders
Viewpointsassociatedwithorganisationalanddomainknowledge

TheroleofthestakeholderiswellunderstoodinRequirementsEngineering,
howeverviewpointsassociatedwithorganisationanddomainknowledgemaybe
thoseassociatedwithsomeaspectofsecurity,marketing,databasesystem,regu
lation,standardetc.Suchviewpointsarenotassociatedwithaparticularstake
holder,butwillincludeinformationfromarangeofsources.
Thefollowingsectionsconsiderthreedifferentmethodsbasedonviewpoints.

3.3.1.1ControlledRequirementsExpression(CORE)

COREwasoriginallydevelopedfollowingworkonrequirementsanalysiscarried
outfortheUKMinistryofDefence.Akeyfindingofthisworkwasthatmethods
oftenstartedbydefiningthecontextofasolutiontoaproblem,ratherthanattempting
todefinetheproblemitself,beforebeginningtoassesspossiblesolutions.CORE
wasspecificallydesignedtoaddressthelatterapproach.Figure3.14indicatesthe
conceptsandrepresentationsusedinCORE.
ThecentralconceptofCOREistheviewpointandtheassociatedrepresentation
knownastheviewpointhierarchy.Aviewpointcanbeaperson,roleororganisation
thathasaviewaboutanintendedsystem.(Thisconcepthasbeenusedasthebasis
ofuserviewpointanalysisbyDarkeandShanks1997).Whenusedforsystem
requirementstheviewpointscanalsorepresenttheintendedsystem,itssubsystems
andsystemsthatexistwithintheenvironmentofthesystemthatmayinfluence
whatthesystemmustdo.Theviewpointsareorganisedinahierarchytoprovidea
scopeandalsotoguidetheanalysisprocess.
Ifweconsiderasanexample,anaircraftbrakeandcontrolsystem(ABCS),
thenFig.3.15showsapossiblelistofinitialviewpointsarrivedatbymeansof
brainstorming.
Havingproducedalistofpotentialviewpoints,theyareorganisedintoahierarchy
bygroupingrelatedcandidates.Boundariesaredrawnaroundrelatedsetsandthisis
repeateduntilallcandidateshavebeenenclosedandahierarchyisproduced.

Page80
60 3SystemModellingforRequirementsEngineering

StandardCORE StandardCORE
Representations Concepts

Viewpoint
Viewpoint
Structures
Hierarchy

https://translate.googleusercontent.com/translate_f 72/211
2017520 RequirementsEngineering

Tabular Flow

Collection
InterViewpoint
Form Flow
(TCF)

Internal

Flow

System

Transaction
Canbe Canbe Can Can Can
produced usedby trigger control change
by

Single

Viewpoint

Model Function

(SVM)

DataStore

Fig.3.14RepresentationsandconceptsinCORE

Figure3.16showsapartialhierarchyfortheaircraftbrakingcontrolsystem.
InCOREtheactionsthateachviewpointmustperformaredetermined.Each
actionmayuseorproduceinformationorotheritems(e.g.commodities)relevant
tothesysteminquestion.Theinformationgeneratedbytheanalysisisrecordedin
aTabularCollectionForm(TCF)asindicatedinTable3.1.
Linesaredrawnbetweenadjacentcolumnstoindicatetheflowsthattakeplace.
Onceeachviewpointhasbeenanalysedinthisway,theTCFsateachlevelin
theviewpointhierarchyarecheckedasagrouptoensurethattheinputswhicheach
viewpointexpectsaregeneratedbythesourceviewpointandthattheoutputswhich
eachactiongeneratesareexpectedbytheviewpoint(s)indicatedasthedestination(s)
forthem.
Returningtotheexampleaircraftbrakingcontrolsystem,partoftheTCFforthe
systemisshowninTable3.2.
Furtheranalysisconsistsofdevelopingamoredetaileddataflowmodelforeach
viewpointinturn.ThestartingpointfortheseSingleViewpointModels(SVMs)is

Page81
3.3Methods 61

Pilots

Environment
Maintenance
engineer

Aircraft

Cockpit

https://translate.googleusercontent.com/translate_f 73/211
2017520 RequirementsEngineering

Brakingsystemx2 System
Sensors recording

Steeringsystem Brakepedals

Fig.3.15InitialviewpointsforABCS

System

Aircraft Maintenance

Braking Recording
Cockpit Sensors
System system

Brake Steering
Pilots
controls controls

Fig.3.16Hierarchyexample

theinformationrecordedintheTCFs.SVMsaddflowsthatareentirelywithina
viewpointanddatastores.TheSVMsalsodefinehowactionsarecontrolledand
triggeredbyflowsfromotheractions.
Thustheanalysisisdriventopdownbyanalysingeachstratumintheviewpoint
hierarchy.Withtopdownanalysis,itcanbedifficulttoknowwhentostopandto

Page82
62 3SystemModellingforRequirementsEngineering

Table3.1Tabularcollectionform
Source Input Action Output Destination
Theviewpointfrom Thenameof Theactionperformed Thename(s)ofany Theviewpoint
whichtheinput theinput ononeormore outputsgenerated towhich
comes item inputstogenerate bytheaction theoutput
requiredoutputs issent

Table3.2TCFexample

Source Input Action Output Destination

Channel1,2 Selftestok Channel1,2

https://translate.googleusercontent.com/translate_f 74/211
2017520 RequirementsEngineering
Poweronof
channel1,2

Selftestfail

Cockpit Powerup Powerup Channelfault

selftest

NWSisolator
valvefault

Autobrake System
fault recording

Shutoffvalve
fault

Towingstate

Other Towing Monitor Towing Aircraft

sensors/ controlled towing controlon
actuators

Towing
controloff

Channel1,2 Operational
ofchannel1,2

Wheelspeed Wheelspeeds Monitor Speed>70 Cockpit

wheelspeeds knots

predictwheretheanalysiswilllead.Theapproachoffirstidentifyingtheviewpoints
andthenusingthemtocontrolthesubsequentanalysisprovidesacontrolledway
ofdoinganalysisinatopdownmanner.Thisovercomesamajorproblemassoci
atedwithdataflowbasedanalysis.Thiselementofcontrolisalludedtoin
ControlledRequirementsExpression,thefullnameofCORE.

Page83
3.3Methods 63

TheothermainconceptofCOREisthesystemtransaction.Thisisapath
throughthesystemfromoneormoreinputs,dataflowsoreventstooneormore
specificoutputflowsorevents.Thesystemtransactionsaddresshowasystemis
intendedtooperate.Theyprovideavieworthogonaltothetopdownanalysis.
Systemtransactionsprovideasoundbasisfordiscussingthenonfunctional
requirements.

3.3.1.2StructuredAnalysisandDesignTechnique(SADT)

SADTisamethodofstructuredanalysis,basedontheworkundertakenby
RossonStructuredAnalysis(SA)inthe1970s(Ross1977).Itisgraphically
orientedandadoptsapurelyhierarchicalapproachtotheproblemwithasuc
cessionofblueprintsbothmodularisingandrefiningituntilasolutionis

https://translate.googleusercontent.com/translate_f 75/211
2017520 RequirementsEngineering

achieved.ThebasicelementofSADTisthebox,whichrepresentsanactivity
(inactivitydiagrams)ordata(indatadiagrams).Theboxesarejoinedby
arrowsrepresentingeitherthedataneededorprovidedbytheactivityrepre
sentedbythebox(inactivitydiagrams),ortheprocessprovidingorusingthe
data(indatadiagrams).
Therearefourbasicarrowsassociatedwithabox,asshowninFig.3.17.The
typeofarrowisimpliedbyitspointofconnectiontothebox:

Inputarrowsentertheboxfromtheleftside,andrepresentdatathatisavailable
totheactivityrepresentedbythebox.
Outputarrowsexittheboxfromtherightside,andrepresentdatathatis
producedbytheactivityrepresentedbytheboxi.e.theinputdatahasbeen
transformedbytheactivityrepresentedbytheboxtoproducethisoutput.
Controlarrowsentertheboxfromthetop,andgovernthewayinwhichthe
transformationtakesplace.
Mechanismarrowsentertheboxfrombelowandcontrolthewaytheactivity
mayuseoutsidemechanismse.g.aspecificalgorithmorresources.

Control

Input Output
Activity

Mechanism

Fig.3.17SADTboxandarrows

Page84
64 3SystemModellingforRequirementsEngineering

More
SystemTop
general
Level

2nd
Level

More 3rd
detailed Level

Fig.3.18DecompositionusingSADTdiagrams

https://translate.googleusercontent.com/translate_f 76/211
2017520 RequirementsEngineering

Systemsactions
Computer
system
A04 Sensors
Remote
steering
commands

ABCSreset
B&Scommands
Cockpit
A05

Valvecurrents
Info Steering
System
System
A0
Warning Valve A02

System A03
Commands energisation

Brakingvalve
currents
ABCSinfo
Speed
sensors
Braking
Flightcrewinfo System A01
Shutoffvalve
energisation

Fig.3.19SADTexample

AnSADTdiagramismadeupofanumberofboxeswiththeassociatedsetof
arrows.Aproblemisrefinedbydecomposingeachboxandgeneratingahierarchi
caldiagram,asshowninFig.3.18.

Page85
3.3Methods 65

Figure3.19showsanexampleactivitydiagramforanABCS.Thisdecomposition
proceedsuntilthereissufficientdetailforthedesigntoproceed.

3.3.1.3ViewpointOrientedRequirementsDefinition(VORD)

VORD(Kotonya1996)isamethodbasedonviewpoints.Themodelusedisa
serviceorientedone,wheretheviewpointsareconsideredtobeclients,ifonewas
tothinkofitasaclientserversystem.
AviewpointinVORDreceivesservicesfromthesystemandinturnpasses
controlinformationtothesystem.TheserviceorientedapproachmakesVORD
suitedforspecifyinginteractivesystems.
TherearetwotypesofviewpointinVORDdirectandindirect:

Directviewpointsreceiveservicesfromthesystemandsendcontrolinforma
tionanddatatothesystem.
Indirectviewpointsdonotinteractdirectlywiththesystembutratherhavean
interestinsomeoralloftheservicesdeliveredbythesystem.

Therecanbealargevariationofindirectviewpoints.Examplesincludeengi
neeringviewpointsconcernedwithaspectstobeundertakenbythesystems
https://translate.googleusercontent.com/translate_f 77/211
2017520 RequirementsEngineering

engineerexternalviewpointswhichmaybeconcernedwithaspectsofthe
systemsenvironmentorganisationviewpointswhichmaybeconcernedwith
aspectsofsafetyetc.
TherearethreemainiterativestepsinVORD:

1.Viewpointidentificationandstructuring
2.Viewpointdocumentation
3.Viewpointrequirementsanalysisandspecification

ThegraphicalnotationforaviewpointisshowninFig.3.20.Aviewpointisrepre
sentedbyarectangle,whichcontainsanidentifier,labelandtype.Viewpointattri
butesarerepresentedbylabelsattachedtoaverticallinedroppingdownfromthe
lefthandsideoftherectangle.
TheVORDmethodguidesthesystemsengineerinidentifyingviewpoints.It
providesanumberofabstractviewpointswhichactasastartingpointforiden
tification.SeeFig.3.21.(FollowingtheconventionforVORDdiagrams,direct
viewpointsareunfilledrectanglesandindirectviewpointsareingreyscale).
Thisclasshierarchyisthenprunedtoeliminateviewpointclasseswhicharenot
relevanttoaparticularproblem.Thesystemstakeholders,theviewpointsrepre
sentingothersystemsandthesystemoperatorsarethenidentified.Finally,for
eachindirectviewpointthathasbeenidentifiedconsiderationisgiventowho
mightbeassociatedwithit.
Basedonthisapproach,Fig.3.22givestheviewpointsforaPay&DisplayCar
ParkSystem.
CashUserandCreditCardUserviewpointsarespecialisationsoftheCarPark
Customerviewpoint.CashCollectorandCarParkManagerarespecialisationsof

Page86
66 3SystemModellingforRequirementsEngineering

Viewpointidentifer n.1

n Type

Label

n.2
[mattribute]

Attributeidentifer

Fig.3.20Viewpointnotation

System

Direct

Operator

Maintenance
Engineering
Viewpoint

Standards

Regulatory

Indirect
Customer

https://translate.googleusercontent.com/translate_f 78/211
2017520 RequirementsEngineering
Organisation
Policy

Environment

Training

Fig.3.21Viewpointclasses

CarParkStaff.TheTicketIssuingviewpointrepresentsthedatabaseofthe
organisationresponsibleforissuingthepay&displaytickets.TheCreditCard
Databaseisexternalandholdsdetailsofthecustomerscreditcarddetails.
ThenextstepinVORDistodocumenteachoftheviewpointrequirements.An
exampleofhowthisisachievedisgiveninTable3.3whichshowstheinitialview
pointrequirementsfortheCarParkCustomerviewpoint.Therequirementtype
referstoaservice(sv)ortoanonfunctionalrequirement(nf).
VORDalsoallowsforattributesofviewpointstobeprovidedwhichcharacterise
theviewpointintheproblemdomain.Theseareimportantastheyprovidethe
dataonwhichthesystemoperates.Asstatedpreviously,thesearerepresentedon
theviewpointdiagrambylabelsattachedtoaverticallinedroppingdownfromthe
lefthandsideoftherectangleasshowninFig.3.23.
Systembehaviourismodelledusingeventscenarios.Thesedescribehowthe
systeminteractswiththeenvironmentandprovideawayofdescribingthecomplex
interactionsbetweenthevariousviewpointsandthesystem.

Page87
3.3Methods 67

1.1 Operator/customer

Organisation
CashUser

1 Operator ParkingCompany

CarParkCustomer 1.2 Operator/customer

CreditCardUser
System

CreditCardD/B

2.1 Operator/staff
2 Operator

CashCollector System
CarParkStaff

TicketIssuingSystem

2.2 Operator/staff

CarParkManager

Fig.3.22Payanddisplaymachineviewpoints

Table3.3Requirementsfromthecarparkcustomerviewpoint
Viewpoint Requirement

https://translate.googleusercontent.com/translate_f 79/211
2017520 RequirementsEngineering
Identifier Label Description Type
1 Customer 1.1 Providefacilityforticketbasedonsuitable sv
paymentandlengthofstay
1.1 Creditcarduser 1.1.1 Providefacilitybasedonvalidcreditcard sv
1.1.2 Provideticketissuingserviceforcustomer sv
1.1.3 Ticketissuingserviceshouldbeavailable nf
99/100requests
1.1.4 Ticketissuingserviceshouldhavearesponse nf
timeofnomorethan30s
1.2 Cashuser

ThefinalstageofVORDistotranslatetheresultsoftherequirementsanalysis
processintoarequirementsdocument,basedonanindustrystandard.

3.3.2ObjectOrientedMethods

Duringthelate1980sandearly1990snumerousobjectorientedmethodsemerged
proposingdifferentapproachestoobjectoriented(OO)analysisanddesign.The
earliestusesofOOmethodswerethosecompanieswheretimetomarketand

Page88
68 3SystemModellingforRequirementsEngineering

1.1 Operator/customer

Organisation
CashUser

1 Operator ParkingCompany
[1|cash]
CarParkCustomer
1.2 Operator/customer

CreditCardUser System

CreditCardD/B
[1|card]

2.1 Operator/staff [1|customerdetails]

2 Operator

CashCollector System
CarParkStaff

[1|float] TicketIssuingSystem
[1|staffPIN] [2|pager]

2.2 Operator/staff [1|ticketinformation]

CarParkManager

Fig.3.23Representationofviewpointattributes

resistancetochangewereparamount.Theyincludedtelecommunications,financial
organisationsandlateraerospace,healthcare,banking,insurance,transportationetc.
ThemainplayerswereObjectOrientedAnalysis(OOA),ObjectModelling
Technique(OMT),Booch,andObjectory.ShlaerMellorwasalsothere,butwould

https://translate.googleusercontent.com/translate_f 80/211
2017520 RequirementsEngineering

nothavebeenregardedasatrulyOOmethod.Howeveritdidplayanimportant
roleinassistingintheidentificationofobjects.

3.3.2.1OOA

Objectorientedanalysis(OOA)wasdevelopedbyCoadandYourdon(1991a).
OOAisspreadacrossthreelayers,astheyarecalled.Thefirstlayeristhesubject
layer,whichisconcernedwithobjectidentification.Heretheusersareableto
simplyrepresenttheirunderstandingoftheproblemdomainbyidentifyingrelevant
problemdomainobjects.Thesecondlayer,calledtheattributeslayer,isconcerned
withidentifyingattributes(dataelements)associatedwithproblemdomainobjects.
Thethirdandfinallayeristheserviceslayer.Thisspecifiestheservices(oropera
tions)performedbyeachobject.
Ineffect,OOAhelpsthesystemsengineerinidentifyingtherequirements
ofasystem,ratherthanhowthesoftwareshouldbestructuredorimplemented.
Itthereforedescribestheexistingsystem,itsoperationandhowthesoftware
systemshouldinteractwithit.

Page89
3.3Methods 69

3.3.2.2OMT

TheOMTmethodwasdevelopedbyRumbaugh.Itaimstoconstructaseriesof
objectmodelsthatrefinethesystemdesignuntilthefinalmodelissuitablefor
implementation.Theapproachisachievedinthreephases.Theanalysisphase
producesmodelsoftheproblemdomain.Threetypesofmodelareproducedthe
objectmodel,thedynamicmodelandthefunctionalmodel.Theobjectmodelis
thefirstonetobebuilt.ItusesnotationsimilartothatusedinOOA,whichisbased
ontheconceptofERmodellingwhichdescribestheobjects,theirclassesandthe
relationshipsbetweentheobjects.Thedynamicmodelrepresentsthebehaviourof
thesystemandusesanextensionofHarelsstatecharts.Thefunctionalmodel
describeshowthesystemfunctionsareperformedthroughtheuseofDFDs.
Thesemodelsarearrivedatbyusinganiterativeapproach.Thedesignphasethen
structuresthemodelandtheimplementationphasetakesintoaccounttheappropriate
targetlanguageconstructs.InthiswayOMTcoversnotonlytherequirementscap
turingphasebutalsohelpstoinformthearchitecturaldesignprocess.

3.3.2.3Booch

TheBoochmethodisoneoftheearliestOOmethodsproposed.Althoughthe
methoddoesconsideranalysis,itsstrengthliesinthecontributionitmakesto
thedesignofanobjectorientedsystem.Theapproachisbothincrementaland
iterativeandthedesignerisencouragedtodevelopthesystembylookingatboth
logicalandphysicalviewsofthesystem.
Themethodinvolvesanalysingtheproblemdomaintoidentifythesetofclasses
andobjectsandtheirrelationshipsinthesystem.Thesearerepresentedusinga
diagrammaticalnotation.Thenotationisextendedfurtherwhenconsideringthe
implementationofclassesandobjectsandtheservicestheyprovide.Theuseof
statetransitiondiagramsandtimingdiagramsarealsoanimportantpartofthis

https://translate.googleusercontent.com/translate_f 81/211
2017520 RequirementsEngineering

method.

3.3.2.4Objectory

JacobsonproposedtheObjectorymethod.Manyofitsideasaresimilartoother
OOmethods,butthefundamentalaspectofthismethodisthescenarioorusecase,
asdescribedearlierinthischapter.Thesystemsfunctionalityshouldthereforebe
abletobedescribedbasedonthesetofusecasesforasystemtheusecase
model.
Thismodelisthenusedtogenerateadomainobjectmodel,whichcanbecome
ananalysismodelbyclassifyingthedomainobjectsintothreetypes:interface
objects,entityobjectsandcontrolobjects.Thisanalysismodelisthenconvertedto
adesignmodel,whichisexpressedintermsofblocks,fromwhichthesystemis
implemented.

Page90
70 3SystemModellingforRequirementsEngineering

3.3.2.5TheUML

TheUnifiedModellingLanguage(UML)(OMG2003)wasanattempttobring
togetherthreeoftheOOapproacheswhichhadgainedgreatestacceptance
Booch,OMTandObjectory.Inthemid1990sBooch,RumbaughandJacobson
joinedRationaltoproduceasingle,commonandwidelyusablemodelling
language.Theemphasiswasverymuchontheproductionofanotationratherthan
amethodorprocess.
SinceitsinceptiontheUMLhasundergoneextensivedevelopmentandchange
withvariousversionsbeinglaunched.UML1.0becameastandardin1997following
acceptancebytheObjectManagementGroup(OMG).Version1.3wasreleasedin
1999andin2003theUML2.0wasreleased,whichistheversionusedinthisbook.
AdiscussionoftheUMLisprovidedinthefollowingsection.

3.3.3TheUMLNotation

TheUMLismadeupofanumberofmodels,whichtogetherdescribethesystem
underdevelopment.Eachmodelrepresentsdistinctphasesofdevelopmentand
eachwillhaveaseparatepurpose.Eachmodeliscomprisedofoneormoreofthe
followingdiagrams,whichareclassifiedasfollows:

Structurediagrams
Behaviourdiagrams
Interactiondiagrams

The13diagramsofUML2areshowninFig.3.24andrepresentallthediagrams
whichareavailabletothesystemsengineer.Inrealitymanywillnotbeusedand
oftenonlyasmallsubsetofthediagramswillbenecessarytomodelasystem.
Classdiagrams,usecasediagramsandsequencediagramsareprobablythemost
frequentlyused.Ifdynamicmodellingisrequiredthenactivitydiagramsandstate
machinediagramsshouldbeused.
ItishowtheUMLdiagramscontributetomodellingwhichisofinterestto
https://translate.googleusercontent.com/translate_f 82/211
2017520 RequirementsEngineering

us.ThepurposeofthissectionisnotsomuchtoprovideanoverviewofUML2,
butrathertoshowhowmodelscanbeusedinvariousaspectsofRequirements
Engineering.
Considerthebankingexampleusedearlierinthischapter.Theclassisthebasic
modellingdiagramoftheUML.Figure3.25presentsaUMLclassdiagram
extendingthesetofclassestoincludeAccount,Owner,CurrentAccountand
IssuedChequeusedtomodelthesystem.Asshown,eachclasshasanassoci
atedsetofattributesandoperations,i.e.therelationships(inthiscase,generalisa
tionandassociation)whichexistbetweenoneormoreclasses.
Figure3.26givesadifferentexample,thatofaBaggageHandlingSystem.
Thisconsidersthestakeholderrequirementswhicharefirmlywithintheproblem
domain.Whenmodelling,itisoftenthecasethatthereareexternalsystems,or

Page91
3.3Methods 71

StructureDiagrams BehaviourDiagrams InteractionDiagrams

ClassDiagram ActivityDiagram

SequenceDiagram

ComponentDiagram
UseCaseDiagram

CommunicationDiagram

CompositeStructureDiagram
StateMachineDiagram

ObjectDiagram InteractionOverviewDiagram
InteractionDiagrams

DeploymentDiagram
TimingDiagram

PackageDiagram

Fig.3.24UMLdiagrams

Class
Name

Account Owner

Attributes
balance name

checkbalance
Operations deposit
withdraw
Association

https://translate.googleusercontent.com/translate_f 83/211
2017520 RequirementsEngineering

Generalization
Class

CurrentAccount IssuedCheque
1
* number
overdraftlimit
amount
paycheque

Fig.3.25ExtendedUMLclassdiagram

Page92
72 3SystemModellingforRequirementsEngineering

Conveyor
putsLuggage

Passenger

controls

BaggageCheckInSystem

talks

manages

Clerk
controls

prints

Printer WeightSystem

Fig.3.26ClassdiagramforBaggageHandlingSystem

perhaps,deviceswhichthesystemwilluse.Thesecanberepresentedbyclasses.
FortheBaggageHandlingSystem,classesareidentifiedsuchasPassenger,
Clerk,ConveyoretcandalsotwoembeddedsystemsBaggageCheckInSystem
andWeightSystem.Theassociationsbetweenthesystemsandotherclassesserve
todefineaspectsofthesystemcontext.
Ifweturntothesolutiondomain,thenitbecomesnecessarytoreasonabout
functionandbehaviour.Theclassdiagramthereforeneedstobeelaboratedinorder
toshowtheseattributeswhichwillbenecessaryformodellingthesystemrequire
ments.ThisisshowninFig.3.27.
Usecasemodellingisusedtodescribethefunctionalrequirementsofsystems.
ForourexamplewewillconsidertwousecasediagramsonefortheBaggage
HandlerSystemandonefortheBaggageCheckinSystem.Figure3.28showsthe
firstoftheseportrayedasthetoplevelsystem.Figure3.29istheusecasediagram
fortheBaggageCheckinSystem.Bothdiagramsidentifytheirrespectivesystem
boundaries(markedbyarectangle)andidentifythevariousstakeholdersoractors
whichlieoutsidethesystemboundary.Itshouldbenotedthatthehighestlevel
goalsofthestakeholdersarerepresentedbytheusecases.Theincluderelation

https://translate.googleusercontent.com/translate_f 84/211
2017520 RequirementsEngineering

shipshowsthatausecaseisincludedinanotherusecase,indicatingthestartof
hierarchicaldecomposition.
TheUMLalsoprovidesdiagramstoallowthesystemsengineertomodelfunc
tionalityandbehaviour.Asequencediagramshowstheinteractionandcollabora
tionwhichexistsbetweenobjectsandthuscanmodelcomplexbehaviour.Itis
depictedbymessageswhichflowbetweenobjectsovertime.Figure3.30showsa
samplesequencediagram.Theobjectsarerepresentedbyrectanglesatthetopof

Page93
3.3Methods 73

putsLuggage Conveyor

Passenger

PassportID:Integer

controls

BaggageCheckInSystem
LuggageID:Integer
talks LuggageWeight:Real

manages

Clerk
controls

prints

checkTicket()
Printer WeightSystem

printLabel() Weigh()

Fig.3.27Elaboratedclassdiagram

BaggageHandlingSystem

CheckInPassenger

include

Passenger

CheckInBaggage CheckInClerk

LoadBaggage

UnloadBaggage
BaggageHandler

Fig.3.28UsecasediagramforBaggageHandlingSystem

https://translate.googleusercontent.com/translate_f 85/211
2017520 RequirementsEngineering

thediagramandeachisattachedtoaverticaltimeline.Messagesareorderedby
theirsequenceandarerepresentedbyarrowsbetweenthetimelines.Alsoincluded
isthefeatureofaninteractionframeandtheoperationrefhasbeenusedto

Page94
74 3SystemModellingforRequirementsEngineering

BaggageCheckInSystem

WeighBaggage

include
Passenger

CheckInBaggage

include

LabelBaggage
CheckInClerk

Fig.3.29UsecasediagramforBaggageCheckinSystem

Passenger CheckInClerk BaggageCkeckInSystem

YourTicketsPlease()

HereYouAre()

BaggagePlease()

PutBaggage()

ref
WeighBaggage

ref
LabelBaggage

TransportBaggage()
YourBoardingCard()

Fig.3.30Examplesequencediagram

indicatereferencei.e.referstoaninteractiondefinedinanotherdiagram,inthis

https://translate.googleusercontent.com/translate_f 86/211
2017520 RequirementsEngineering

caseWeighBaggageandLabelBaggage.Theseframeshavebeenincludedto
coverthelifelinesinvolvedintheinteraction.

Page95
3.3Methods 75

3.3.4FormalMethods

Formalmethodsprovideamorerigorousrepresentationbasedonmathematics,
andcanbeusedtoconductmathematicalproofsofconsistencyofspecificationand
correctnessofimplementation.Rigorouscheckingispossible,whichcaneliminate
somekindsoferrors.Thismaybenecessaryincertaintypesofsystems,e.g.
nuclearpowerstations,weapons,andaircraftcontrolsystems.
Z(Spivey1989),VDM(Jones1986),LOTOS(Bjorner1987)andtheBMethod
(Abrial1996)arethemostcommonformalmethodsforformaldefinitionoffunc
tionality.LOTOS(LanguageofTemporalOrderingSpecification),VDM(the
ViennaDefinitionLanguage)andZareformalmethodsstandardizedbyISO.Band
LOTOSmodelsareexecutable,andBmodelscanberefinedintocode.
Formalmethodsareparticularlysuitableforcriticalsystemsi.e.onesinwhich
potentialfinancialorhumanlosswouldbecatastrophic,andthecostofapplying
mathematicallyrigorousmethodscanbejustified.
Formalmethodsareslowlybecomingmoreimportant.Iftheirscopecanbe
broadenedtoaddresswidersystemissues,theywillbecomemoreuseful.

3.3.4.1ZAModelBasedFormalMethod

Zisaformalspecificationnotationbasedonfirstorderpredicatelogicandset
theory.Thenotationallowsdatatoberepresentedassets,mappings,tuples,rela
tions,sequencesandCartesianproducts.Therearealsofunctionsandoperation
symbolsformanipulatingdataofthesetypes.
Zspecificationsarepresentedinasmall,easytoreadboxednotationcalleda
schema.Schemastaketheformofasignaturepartandapredicatepart.The
signaturepartisalistofvariabledeclarationsandthepredicatepartconsistsofa
singlepredicate.Namingaschemaintroducesasyntacticequivalencebetween
thenameandtheschema.SeeFig.3.31.
SpecificationsinZarepresentedasacollectionofschemaswhereaschema
introducessomespecificationentitiesandsetsouttherelationshipsbetweenthem.
Theyprovideaframeworkwithinwhichaspecificationcanbedevelopedand
presentedincrementally.
Figure3.32showsaZspecificationfortheissueoperationforalibrary,where
thegeneralbehaviouroftheoveralllibrarysystemwouldbespecifiedinaschema

SchemaName

Variabledeclarations

Predicates

Fig.3.31Zschema

https://translate.googleusercontent.com/translate_f 87/211
2017520 RequirementsEngineering

Page96
76 3SystemModellingforRequirementsEngineering

Fig.3.32Exampleschema Library==[shelved:PPBook:readers:PPReader:
stock:PPBook:issued:PPBook]

Issue

Library
b?:Book
r?:Reader

b?shelvedr?readers
issued=issued{b?r?}
shelved=shelved\{b?}
stock=stock:readers=readers

namedlibrary.ThenotationLibraryiscalledadeltaschemaandindicatesthat
theIssueoperationcausesastatechangetooccurintheLibrary.
TheschemainFig.3.32distinguishesbetweeninputsandoutputs,andbefore
statesandafterstates.Theseoperationsaredenotedasfollows:

?denotesthevariableasaninputtotheoperation
!denotesthevariableasanoutputoftheoperation

Astateaftertheoperationisdecoratedwiththesymbol,e.g.stocktodistinguish
itfromthestatebeforetheoperation.

3.4Summary

Thischapterhasaddressedtheissuesofsystemmodelling,particularlywithrespect
tothesolutiondomain.Arangeoftechniquesandmethodshavebeenpresented
rangingfromthosewhichhavestoodthetestoftimetothosewhichhavebeen
developedmorerecently.Allhavebeenwidelyusedinindustry.Thecontentsofthe
chapterprovideabasisforthediscussiononmodellingstakeholderandsystem
requirementsinsubsequentchapters.

https://translate.googleusercontent.com/translate_f 88/211
2017520 RequirementsEngineering

Page97

Chapter4
WritingandReviewingRequirements

Towritesimplyisasdifficultastobegood.

WilliamSomersetMaugham,author,18741965AD

4.1Introduction

Requirementsengineeringisatechnicalprocess.Writingrequirementsistherefore
notlikeotherkindsofwriting.Itiscertainlynotlikewritinganovel,orabooklike
thisitisnotevenlikethekindoftechnicalwritingseenininstructionmanuals
anduserguides.
Thepurposeofthischapteristopresentthoseaspectsofwritingrequirements
thatarecommontoeverydevelopmentlayer.Whereverthegenericprocessis
instantiated,certainprinciplesandtechniquesareconstantintheirapplicationto
theexpressionandstructuringofrequirements.
Inwritingarequirementsdocument,twoaspectshavetobecarefullybalanced:

1.Theneedtomaketherequirementsdocumentreadable
2.Theneedtomakethesetofrequirementsprocessable

Thefirstoftheseconcernsthestructureofthedocument,howitisorganisedand
howtheflowofithelpsthereviewertoplaceindividualrequirementstatementsinto
context.Thesecondfocusesonthequalitiesofindividualstatementsofrequirement,
thelanguageusedtopromoteclarityandpreciseness,andhowtheyaredividedinto
singletraceableitems.
Theexperiencedrequirementsengineercomestorealisethatawordprocessor
aloneisnotsufficienttomanageasetofrequirements,fortheindividualstatements
needtobeidentified,classifiedandtraced.Aclassicproblem,forinstance,isthe
useofparagraphnumberstoidentifyrequirements:insertanewoneinthemiddle,
andsuddenlyallthesubsequentrequirementidentifiershavechanged.
Equally,thosewhohavetriedsimplytomanagetheirrequirementsinadatabase
quicklyrealisethattablesfullofindividualstatementsareunmanageable.Despite
havingtheabilitytoidentify,classifyandsortrequirements,vitalcontextualinformation

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_4, 77
SpringerVerlagLondonLimited2011

https://translate.googleusercontent.com/translate_f 89/211
2017520 RequirementsEngineering

Page98

78 4WritingandReviewingRequirements

providedbythedocumenthasbeenlostsinglestatementslosemeaningwhen
separatedfromtheirplaceinthewhole.
Sobothaspectsdocumentandindividualityneedtobemaintained.
Thewritingandthereviewingofrequirements(oranyotherkindofdocument,
forthatmatter)shouldgohandinhand,inthatthecriteriaforwritingagood
requirementareexactlythosecriteriaagainstwhichtherequirementshouldbe
reviewed.Hencethesubjectsaretreatedtogetherinthischapter.

4.2RequirementsforRequirements

Beforediscussinghowrequirementsdocumentsandstatementsshouldbewritten,itis
besttoreviewsomeoftheobjectivesandpurposeforthewritingofrequirementsin
thefirstplace.Thiswillhelpinunderstandingwhycertainprinciplesaresuggested.
Thestartingplaceistheidentificationofstakeholders,whichisshowninTable4.1.

Table4.1Stakeholdersforrequirements
Stakeholder Role
Author Createstherequirementsandincorporateschanges
Publisher Issuesandarchivestherequirementsdocument
Reviewer Reviewstherequirementsandsuggestschanges
Implementer Analysestherequirementsandnegotiateschanges

Table4.2Abilitiesrequiredforrequirements
Ability
Abilityuniquelytoidentifyeverystatementofrequirement.
Abilitytoclassifyeverystatementofrequirementinmultipleways,suchas:
Byimportance
Bytype(e.g.functional,performance,constraint,safety)
Byurgency(whenithastobeprovided)
Abilitytotrackthestatusofeverystatementofrequirement,insupportofmultipleprocesses,
suchas:
Reviewstatus
Satisfactionstatus
Qualificationstatus
Abilitytoelaboratearequirementinmultipleways,suchasbyproviding:
Performanceinformation
Quantification
Testcriteria
Rationale
Comments
Abilitytoviewastatementofrequirementinthedocumentcontext,i.e.alongsideits
surroundingstatements.
Abilitytonavigatethrougharequirementsdocumenttofindrequirementsaccordingtoa
particularclassificationorcontext.
Abilitytotracetoanyindividualstatementofrequirement.

Page99

https://translate.googleusercontent.com/translate_f 90/211
2017520 RequirementsEngineering
4.3StructuringRequirementsDocuments 79

Table4.2listscapabilitiesrequiredbythevariousstakeholdersthatrelatetohow
requirementsdocumentsandstatementsarewritten.Thesearethebasicthingsthat
oneneedstobeabletodotoandwithrequirements,includingidentification,
classification,elaboration,trackingstatus,tracing,placingincontextandretrieving.
Howrequirementsareexpressedandorganisedhasagreatinfluenceonhow
useablethesetsofrequiresbecomes.

4.3StructuringRequirementsDocuments

Requirementsdocumentationcanbeverylarge.Onpaper,thecompletesubsystem
requirementsforanaircraftcarrier,forinstance,mayfillmanyfilingcabinets.
Itisnotunknownforsupplierresponsestolargesystemstobedeliveredin
lorries.Insuchsituations,havingawellunderstood,clearlydocumentedstruc
tureforthewholerequirementssetisessentialtotheeffectivemanagementof
complexity.
Organisingrequirementsintotherightstructurecanhelp:

Minimizethenumberofrequirements
Understandlargeamountsofinformation
Findsetsofrequirementsrelatingtoparticulartopics
Detectomissionsandduplications
Eliminateconflictsbetweenrequirements
Manageiteration(e.g.delayedrequirements)
Rejectpoorrequirements.
Evaluaterequirements
Reuserequirementsacrossprojects

Documentsaretypicallyhierarchical,withsectionsandsubsectionstomultiple
levels.Hierarchiesareusefulstructuresforclassification,andonewayofstructuring
arequirementsdocumentistousethesectionheadingstructuretocategorisethe
requirementsstatements.Insucharegime,thepositionarequirementstatementhas
inthedocumentrepresentsitsprimaryclassification.(Secondaryclassificationscan
begiventhroughlinkstoothersections,orbyusingattributes.)
Chapter3describeshowsystemmodelsfrequentlyusehierarchiesintheanalysis
ofasystem.Examplesare:

Goalorcapabilitydecompositionasinstakeholderscenarios
Functionaldecompositionasindataflowdiagrams
Statedecompositionasinstatecharts

Whererequirementsarederivedfromsuchmodels,oneoftheresultinghierarchies
canbeusedaspartoftheheadingstructurefortherequirementsdocument.
Inadditiontorequirementsstatementsthemselves,requirementsdocuments
maycontainavarietyoftechnicalandnontechnicaltext,whichsupporttheunder
standingoftherequirements.Thesemaybesuchthingsas:

Page100
80 4WritingandReviewingRequirements

Backgroundinformationthatplacestherequirementsincontext
https://translate.googleusercontent.com/translate_f 91/211
2017520 RequirementsEngineering

Externalcontextdescribingtheenclosingsystem,oftencalleddomainknowledge
Definitionofthescopeoftherequirements(whatsinandwhatsout)
Definitionsoftermsusedintherequirementstatements
Descriptivetextwhichbridgesdifferentsectionsofthedocument
Stakeholderdescriptions
Summaryofmodelsusedinderivingtherequirements
Referencestootherdocuments

4.4KeyRequirements

Manyorganisationsusetheconceptofkeyrequirements,particularlyatthe
stakeholderlevel.OftenreferredtoasKURs(KeyUserRequirements)orKPIs
(KeyPerformanceIndicators),theserequirementsareasmallsubsetabstracted
fromthewholethatcapturetheessenceofthesystem.
Theguidingphilosophywhenselectingkeyrequirementsissimilartothatused
byJeromeK.JeromesThreeMeninaBoat,who,whenplanningforthetrip,
realisedthat
theupperreachesoftheThameswouldnotallowthenavigationofaboatsufficientlylarge
totakethethings[they]hadsetdownasindispensable.

Georgesaid,Wemustnotthinkofthethingswecoulddowith,butonlythethingsthatwe
cannotdowithout.

Everykeyrequirementshouldsolicitanegativeresponsetothequestion:
Ifthesolutiondidntprovidemewiththiscapability,wouldIstillbuyit?

or,ifatthesystemlevel,
Ifthesystemdidntdothis,wouldIstillwantit?

Inthisway,thekeyrequirementsbecomethosethatareabsolutelymandatory.(Of
course,everythingisnegotiable,buttradingkeyrequirementswouldalways
engenderverycarefulconsideration.)
Whereappropriate,eachkeyrequirementshouldbequantifiedwithperformance
attributes.DoingthisallowsthemtobeusedasKPIs,usedtoassessalternative
proposalsagainsttherequirements,orusedasasummaryofvitalstatisticsonproject
progress.

4.5UsingAttributes

Itisclearfromthediscussionsofprocessinpreviouschapters,andfromthelistof
abilitiesinTable4.2,thatasimpletextualstatementisnotsufficientfullytodefine
arequirementthereisotherclassificationandstatusinformationthateachrequire
mentcarries.

Page101
4.5UsingAttributes 81

Ratherthanclutterthetextofarequirement,additionalinformationshouldbe
placedinattributesattachedtotherequirement.Attributesallowtheinformation
associatedwithasinglerequirementtobestructuredforeaseofprocessing,filtering,

https://translate.googleusercontent.com/translate_f 92/211
2017520 RequirementsEngineering

sorting,etc.AttributescanbeusedtosupportmanyoftheabilitiesinTable4.2,
enablingtherequirementstobesortedorselectedforfurtheraction,andenabling
therequirementsdevelopmentprocessitselftobecontrolled.Figure4.1showsan
exampleofarequirementwithanumberofattributes.
Theparticularattributesusedwilldependontheexactprocessesthatneedtobe
supported.Someattributesareentirelyautomatice.g.dates,numberssome
comefromuserse.g.priorityotherattributesareflags,whicharesetafteranalysis
worke.g.checkability.
Thefollowingsuggestionsforattributecategoriesaredrawninpartfromsome
workcarriedoutbyarequirementsworkinggroupintheUKchapterofINCOSE
(Table4.3).

[SH234]Theambulancecontrolsystemshallbeabletohandleupto100
simultaneousemergencycalls.
Source: R.Thomas
Priority: Mandatory
Release: 1
Reviewstatus:Accepted

Verifiable: Yes
Verification: Bysimulation,thenbysystemtest.

Fig.4.1Requirementsattributes

Table4.3CategoriesofAttributes
Category ExampleValues
Identification
Identifier Uniquereference
Name Uniquenamesummarisingthesubjectoftherequirement.
Intrinsiccharacteristics
Basictype Functional,performance,qualityfactor,environment,
interface,constraint,nonrequirement
Qualityfactorsubtype Availability,flexibility,integrity,maintainability,
portability,reliability,safety,security,supportability,
sustainability,usability,workmanship
Product/processtype Product,process,data,service
Quantitative/qualitativetype Quantitative,qualitative
Lifecyclephase Preconcept,concept,development,manufacturing,
integration/test,deployment/delivery/installation,
operation,support,disposal
Priorityandimportance
Priority(compliancelevel) Key,mandatory,optional,desirable
or
Must,Should,Could,Would(MoSCoW)
Importance 110
(continued)

Page102
82 4WritingandReviewingRequirements

Table4.3(continued)
Category ExampleValues
Sourceandownership
Derivationtype Allocation,decomposition
Source(origin) Nameofdocumentorstakeholder
Owner Nameofstakeholder

https://translate.googleusercontent.com/translate_f 93/211
2017520 RequirementsEngineering
Approvalauthority Nameorperson
Context
Requirementsset/document (Besthandledthroughpositioningtherequirementina
Subject structureddocument.)
Scope
Verificationandvalidation
V&Vmethod Analysis,inspection,systemtest,componenttest
V&Vstage (Seelifecyclephase.)
V&Vstatus Pending,pass,failed,inconclusive
Satisfactionargument Rationaleforchoiceofdecomposition
Validationargument RationaleforchoiceofV&Vmethods
Processsupport
Agreementstatus Proposed,beingassessed,agreed
Qualificationstatus Notqualified,qualified,suspect
Satisfactionstatus Notsatisfied,satisfied,suspect
Reviewstatus Tobereviewed,Accepted,Rejected
Elaboration
Rationale Textualstatementaboutwhytherequirementispresent.
Comments Textualcommentsofclarification.
Questions Questionstobeposedforclarification.
Responses Responsesreceivedforclarification.
Miscellaneous
Maturity(stability) Numberofchanges/time
Risklevel High,Medium,Low
Estimatedcost
Actualcost
Productrelease Version(s)ofproductmeetingtherequirement.

4.6EnsuringConsistencyAcrossRequirements

Afrequentconcerninmanaginglargesetsofrequirementsisbeingabletoidentify
conflictingrequirements.Thedifficultyisinspottingthattwostatementsmany
pagesapartareinconflict.Whattechniquescanbeappliedtoassistinidentifying
thesepotentialinconsistencies?
Oneanswerliesinclassifyingrequirementsinseveralways,andusingfiltering
andsortingtechniquestodrawtogethersmallnumbersofstatementsthataddress
thesametopic.Manyrequirementswilltouchonseveralaspectsofasystem.For
instance,arequirementprimarilyaboutengineperformancemayalsocontaina
safetyelement.Suchastatementshouldthereforebeviewedinbothanengine
performancecontextaswellasinasafetycontext.

Page103
4.7ValueofaRequirement 83

Tofacilitatethis,requirementscanbegivenprimaryandsecondaryclassifications,
asdiscussedinSection1.3.Typically,eachhasasingleprimaryclassification
(perhapsbyvirtueofitspositioninthedocument),andmultiplesecondaryclassi
fications,perhapsusinglinksorattributes.
Athoroughreviewprocesscannowincludethesystematicfilteringofstate
mentsbykeywordsusedinprimaryandsecondaryclassifications.Forexample,
filteringonallrequirementstodowithsafetywilldrawtogetherstatementswhose
primaryclassificationsmaybequitediverse.Thesecanthenbereviewedinprox
imityforpotentialconflicts.
https://translate.googleusercontent.com/translate_f 94/211
2017520 RequirementsEngineering

4.7ValueofaRequirement

Somerequirementsarenonnegotiable.Iftheyarenotmet,theproductisofnouse.
Otherrequirementsarenegotiable.Forinstance,ifasystemisrequiredto
supportatleast100simultaneoususers,butthedeliveredsolutiononlysupports99,
thenitismostlikelystillofsomevaluetothecustomer.
Capturingthevalueofarequirementcanbeachallenge.Awayneedstobe
foundofexpressingtheideathat,whilethetargetmaybe100simultaneoususers,
75wouldbeacceptable,butanythinglessthan50isnotacceptableandmaybe200
wouldbeevenbetter.
Oneapproachtothisistoprovideseveralperformancevalues.Hereisan
exampleofathreevaluedapproach:

M:themandatorylower(orupper)limit
D:thedesiredvalue
B:andthebestvalue

Thesethreevaluescanbeheldinseparateattributes,orrepresentedwithinthetext
inalabelledform,suchasThesystemshallsupport[M:50,D:100,B:200]simul
taneoususers.
Anotherapproachistorepresentthevalueofarequirementbysupplyingafunction
thatmapsperformancetosomerepresentationofvalue,usuallyafigurebetween1and
100.Figure4.2showsfourexamplesofdifferentshapesofvaluefunction.Function
(a)showstheexampleabove,wherethenumberofsimultaneoususersshouldbe
maximised,butmorethanaminimumnumberismandatory.Function(b)isthebinary
case:eithertheperformanceof100isexceededornot.Aperformanceof200doesnot
addextravalue.Function(c)showsaperformancethatistobeminimised(weight,for
instance),whereas(d)showsonethatistobeoptimised(enginerevs,forexample).
Thisisaveryvisualwayofpresentingvalue.Oneglanceattheshapeofthevalue
curveindicatesthenatureoftherequirement:minimise,maximise,optimise,etc.It
alsoallowstheengineerstounderstandthedegreesoffreedomtheyhaveindesigning
solutionsthatdeliverthebestoverallvalue,bytradingoffperformancebetween
requirements.Thisiswhythisapproachisfrequentlyusedaspartofthetender
assessmentprocess,tojudgebetweentherelativevaluesofalternativeproposals.

Page104
84 4WritingandReviewingRequirements

a b
100 100

e e

valu valu

0 0
50100200users 50100200users
performance performance

maximise exceed

c d
https://translate.googleusercontent.com/translate_f 95/211
2017520 RequirementsEngineering
100 100

e e
lu
a
v valu

0 0
5 10 20kg 37 10Krpm
performance performance

minimise optimise

Fig.4.2Typicalvaluefunctions

Anattributecanbeusedtorepresentavaluefunctionasasetofperformance/
valuepairs.

4.8TheLanguageofRequirements

Theuseofconsistentlanguagemakesiteasiertoidentifydifferentkindsofrequire
ments.Asimpleexampleofthisistheuseofshallasakeywordtoindicatethe
presenceofarequirementinthetext.Someapproachesgosofarastouseshall,
shouldandmaytoindicatedifferentprioritiesofrequirement.
Thelanguageusedwillvarydependingonthelevelofrequirementbeing
expressed.Theprincipledifferenceisbetweenstakeholderrequirementsthatliein
theproblemdomainandsystemrequirementsthatlieinthesolutiondomain(see
Chapter1,Section1.9).
AsisemphasisedinSection1.9,stakeholderrequirementsareprimarilyconcerned
withcapabilityandconstraintsoncapability.Acapabilitystatementshouldexpressa
(single)capabilityrequiredbyoneormoreidentifiedstakeholdertypes(oruser
groups).Thetypesofstakeholdershouldbestatedintherequirementtext.
Atypicalcapabilityrequirementtakesthefollowingform:
The<stakeholdertype>shallbeableto<capability>.

Wheretherearesomeaspectsofperformanceorconstraintassociatedsolelywith
therequirement,theymayalsobestatedinthetext,forinstancegivingtheform:

Page105
4.9RequirementBoilerplates 85

The<stakeholdertype>shallbeableto<capability>
within<performance>of<event>
while<operationalcondition>.

Forexample,thefollowingcapabilityrequirementhasaperformanceandconstraint
attached:
Theweaponsoperatorshallbeabletofireamissile
within3secondsofradarsightingwhileinsevereseaconditions.

Lesscommonly,asingleperformanceattributeisassociatedwithseveralcapabili
ties.Forexample,severalcapabilitiesmayneedtobeprovidedwithasettime.In
practicethesecapabilitiesareusuallysubdivisionsofahighlevelcapability,to
whichtheperformanceattributeshouldbeattached.
Itfrequentlyoccurs,however,thatconstraintshavetobeexpressedseparately
fromthecapabilities,eitherbecausetheyapplytothewholesystem,orbecausethey

https://translate.googleusercontent.com/translate_f 96/211
2017520 RequirementsEngineering

applytodiversecapabilities.Generally,constraintsinstakeholderrequirementsare
basedeitheronminimumacceptableperformanceorarederivedfromtheneedto
interactwithexternalsystems(includinglegalandsocialsystems).
Atypicalconstraintrequirementtakesthefollowingform:
The<stakeholder>shallnotbeplaced
inbreachof<applicablelaw>.

E.g.Theambulancedrivershallnotbeplaced
inbreachofnationalroadregulations.

Sincetheylieinthesolutiondomain,thelanguageofsystemsrequirementsisa
littledifferent.Herethefocusisonfunctionandconstraintsonthesystem.The
languagedependsonthekindsofconstraintorperformanceassociatedwiththe
requirement.Hereisanexampleofafunctionwithacapacityperformance:
The<system>shall<function>
notlessthan<quantity><object>while<operationalcondition>.

E.g.Thecommunicationssystemshallsustaintelephonecontact
withnotlessthan10callerswhileintheabsenceofexternalpower.

Hereisanotherthatexpressesaperiodicityconstraint:
The<system>shall<function><object>
every<performance><units>.

E.g.Thecoffeemachineshallproduceahotdrink
every10seconds.

Furtherdiscussionofthistopiccanbefoundinthefollowingsection.

4.9RequirementBoilerplates

ThelanguageofrequirementsinSection4.8wasexpressedintermsofboilerplates.
Thissectionextendsthisconcept,andappliesittothecollectionandexpressionof
constraintrequirements.

Page106
86 4WritingandReviewingRequirements

UsingboilerplatessuchastheexamplesinSection4.8isagoodwayofstandardis
ingthelanguageusedforrequirements.Apaletteofboilerplatescanbecollectedand
classifiedasdifferentwaysofexpressingcertainkindsofrequirement.Asanorganisa
tiongainsexperience,thepalettecanbeexpandedandreusedfromprojecttoproject.
Expressingarequirementthroughaboilerplatenowbecomesaprocessof

Selectingthemostappropriateboilerplatefromthepalette
Providingdatatocompletetheplaceholders

Therequirementcanrefertoasingledocumentwideinstanceoftheboilerplate,
andplaceholderscanactuallybecollectedseparatelyasattributesoftherequire
ment.ThisisillustratedinFig.4.3.
Fromthisinformation,thetextualformoftherequirementcanbegenerated
whenneeded.Separatingthetemplatehasthefollowingadvantages:

Globalchangesinstylecanbeeffected:Tochangethewayscertainrequirements
areexpressed,onlythecentrallyheldboilerplateneedstobeedited.
Systeminformationcanbeprocessedmoreeasily:Collecting,forinstance,allthe
https://translate.googleusercontent.com/translate_f 97/211
2017520 RequirementsEngineering

<operationalcondition>placeholdersintoaseparateattributeallowsforeasy
sortingandfilteringonoperationalconditions.
Confidentialinformationcanbeprotected:Incontextswhererequirementscontain
classifiedorsecretinformation,boilerplatescanbeusedtoseparateoutjust
thosepartsofeachstatementthatneedtobeprotected.

Thislastpointmeritssomeelaboration.Inmilitaryorcommerciallysensitiveprojects,
thereisaneedtorestricttheavailabilityofsomeinformation,butnotall.Quiteoften,
asinglestatementofrequirementwillcontainamixtureofinformationclassifiedat

Template34
The<system>shall<function><object>
every<performance><units>.

<system>=coffeemachine
<function>=produce
Requirement347=Template34+ <object>=ahotdrink
<performance>=10
<units>=seconds

<system>=coffeemachine
<function>=produce
Requirement348=Template34+ <object>=acolddrink
<performance>=5
<units>=seconds

Fig.4.3Globaltemplates

Page107
4.9RequirementBoilerplates 87

variouslevels.Forinstance,itisobviousthattheshipisgoingtofiremissileswhatis
classifiedistheperformanceassociatedwiththatcapability:thestateofreadiness,the
frequency,andtherange,etc.Ratherthanhavingtohidethewholestatementbecause
someoftheelementsareconfidential,boilerplatespermitthestatementtobevisible
withoutsomeofitsmoresensitiveattributes.Indeed,differentreadersmaybeableto
seedifferentsetsofattributes.
Sincetherearesuchawidevarietyofconstraints,thesetendtobethemost
difficulttoexpress,andthisiswhereboilerplatescanhelpthemost.Hereisan
approachtocapturingconstraintrequirements:

1.Collectallcapabilityrequirementsfirst.
2.Constructalistofallthedifferentkindsofconstraintthatmayneedtobeexpressed.
Ifthislistisbasedonpastexperienceofthesamekindofsystem,thenboilerplates
shouldexistforeachkind.Otherwisesuitableboilerplatesmayhavetobedefined.
3.Foreachcapability,considereachkindofconstraint,anddeterminewhetheracon
straintneedstobecaptured.Alargetablecouldbeusedforthisineachcell,indicate
whereconstraintsexistbyenteringtheappropriatesubordinateclausestotherequire
mentwherenoconstraintisnecessary,enterN/Aintheappropriatecell.
4.Selecttheboilerplatethatbestmatchestheconstrainttobeexpressed,andinstantiateit.
5.Theprocessisfinishedwheneverycellhasbeenconsidered.
https://translate.googleusercontent.com/translate_f 98/211
2017520 RequirementsEngineering

Thisprocessanswerstwofrequentlyaskedquestions:

HowdoIexpressconstraintrequirements?(Useboilerplates.)
HowdoIknowwhenallconstraintshavebeencollected?(Usethissystematic
coverageapproach.)

Table4.4showssomeexamplesofboilerplatesclassifiedbytypeofconstraint.
Notethattheremaybeseveralwaysofexpressingsimilarlyclassifiedconstraints,

Table4.4Exampleboilerplatesforconstraintrequirements
TypeofConstraint
Performance/capability
Performance/capability
Performance/capacity
Performance/timeliness
Performance/periodicity
Interoperability/capacity
Sustainability/periodicity
Environmental/operability
BoilerPlate
The<system>shallbeableto<function><object>
notlessthan<performance>timesper<units>.
The<system>shallbeableto<function><object>
oftype<qualification>within<performance><units>.
The<system>shallbeableto<function>
Notlessthan<quantity><object>
The<system>shallbeableto<function><object>
within<performance><units>from<event>.
The<system>shallbeableto<function>notlessthan
<quantity><object>within<performance><units>.
The<system>shallbeableto<function><object>
composedofnotlessthan<performance><units>
with<externalentity>.
The<system>shallbeableto<function><object>
for<performance><units>every<performance><units>.
The<system>shallbeableto<function><object>
while<operationalcondition>.

Page108
88 4WritingandReviewingRequirements

andthatconstraintsmayhaveacompoundclassification.Onlythosepartsofthe
boilerplatethatareinboldfontareactuallyrelevanttotheconstraint.

4.10GranularityofRequirements

Theuseofrequirementsboilerplatesencouragesthepracticeofplacingsome
constraintsandperformancestatementsassubclausesofcapabilityorfunctional
requirements.Insomecases,itmaybedesirabletocreatetraceabilitytoandfrom
justthosesubclauses.
Thisraisesthequestionofgranularityofinformation.Howfardowesplitthe
atominrequirementsmanagement?
Statementsofrequirementscanbedecomposedintosubclauses,aslongastool
supportensuresthatclausesarealwaysvisibleincontext.Oneschemeistoextend
therequirementshierarchytomakethesubclauseschildrenofthemainrequire
ment,asshowninFig.4.4.Whereasthemainrequirementisreadable(andtrace
able)onitsown,thesubclauses,albeitseparatelyreferenceablefortracing
purposes,makesenseonlyinthecontextoftheirparentstatement.
Traceabilitycannowreferenceaspecificsubclause,buttheclauseshouldonly
everbecitedwiththecontextofitsancestorstatements.Forinstance,thetraceable
statementsthatcanbecitedfromFig.4.4,withcontextinitalics,are

https://translate.googleusercontent.com/translate_f 99/211
2017520 RequirementsEngineering

Thecommunicationssystemshallsustaintelephonecontact.
Thecommunicationssystemshallsustaintelephonecontactwithnotlessthan
10callers.
Thecommunicationssystemshallsustaintelephonecontactwhileintheabsence
ofexternalpower.

Theremaybeseveralwaysoforganisingthehierarchyofclauses.Suppose,for
instance,thattherearemultiplecapabilitiesrequiredintheabsenceofexternal
power.ThenthearrangementmaybeasinFig.4.5.
Nowthetraceablestatementsthatcanbecitedare:

Whileintheabsenceofexternalpower,thecommunicationssystemshallsustain
telephonecontact.
Whileintheabsenceofexternalpower,thecommunicationssystemshallsustain
telephonecontactwithnotlessthantencallers.
Whileintheabsenceofexternalpower,thecommunicationssystemshallsustain
radiocontactwithnotlessthan15ambulancedrivers.

Thecommunicationssystemshallsustaintelephonecontact

withnotlessthan10callers

whileintheabsenceofexternalpower.

Fig.4.4Performanceandconstraintsassubclauses

Page109
4.11CriteriaforWritingRequirementsStatements 89

Whileintheabsenceofexternalpower,

thecommunicationssystemshallsustaintelephonecontact

withnotlessthan10callers.

thecommunicationssystemshallsustainradiocontact

withnotlessthan15ambulancedrivers.

Fig.4.5Alternativearrangementofsubclauses

Indeed,asageneralprinciple,requirementscouldbeorganisedinsuchawaythat
thesetofancestorobjectsprovidethecompletecontextforeachstatement,including
sectionandsubsectionheadings.

4.11CriteriaforWritingRequirementsStatements

Apartfromthelanguageaspects,therearecertaincriteriathateverystatementof
requirementshouldmeet.Thesearesummarisedasfollows:

Atomic:eachstatementcarriesasingletraceableelement.
Unique:eachstatementcanbeuniquelyidentified.
Feasible:technicallypossiblewithincostandschedule.

https://translate.googleusercontent.com/translate_f 100/211
2017520 RequirementsEngineering

Legal:legallypossible.
Clear:eachstatementisclearlyunderstandable.
Precise:eachstatementispreciseandconcise.
Verifiable:eachstatementisverifiable,anditisknownhow.
Abstract:doesnotimposeasolutionofdesignspecifictothelayerbelow.
Inaddition,thereareothercriteriathatapplytothesetofrequirementsasawhole:

Complete:allrequirementsarepresent.
Consistent:notworequirementsareinconflict.
Nonredundant:eachrequirementisexpressedonce.
Modular:requirementsstatementsthatbelongtogetherareclosetoone
another.
Structured:thereisaclearstructuretotherequirementsdocument.
Satisfied:theappropriatedegreeoftraceabilitycoveragehasbeenachieved.
Qualified:theappropriatedegreeoftraceabilitycoveragehasbeenachieved.

Twonightmareexamplesofactualrequirementsaregivenbelow.

1.Thesystemshallperformatthemaximumratingatalltimesexceptthatinemer
genciesitshallbecapableofprovidingupto125%ratingunlesstheemergency
conditioncontinuesformorethan15mininwhichcasetheratingshallbereduced
to105%butintheeventthatonly95%canbeachievedthenthesystemshall

Page110
90 4WritingandReviewingRequirements

activateareducedratingexceptionandshallmaintaintheratingwithin10%of
thestatedvaluesforaminimumof30min.
2.Thesystemshallprovidegeneralwordprocessingfacilitieswhichshallbeeasy
tousebyuntrainedstaffandshallrunonathinEthernetLocalAreaNetwork
wiredintotheoverheadductingwithintegratedinterfacecardshousedineach
systemtogetherwithadditionalmemoryifthatshouldbenecessary.

Someclassicproblemsarepresentintheseexamples.Thefollowingpitfallsshould
beavoided:

Avoidrambling:concisenessisavirtueitdoesnthavetoreadlikeanovel
Avoidletoutclauses:suchasifthatshouldbenecessarytheyrenderthe
requirementsuseless.
Avoidputtingmorethanmorerequirementinaparagraph:oftenindicatedby
thepresenceofthewordand.
Avoidspeculation.
Avoidvaguewords:usually,generally,often,normally,typically.
Avoidvagueterms:userfriendly,versatile,flexible.
Avoidwishfulthinking:100%reliable,pleaseallusers,safe,runonallplatforms,
neverfail,handleallunexpectedfailures,upgradeabletoallfuturesituations.

Ananalysisofthefirstexampleaboveadmitsthattherecouldbe12requirements
present.Abetterapproachwouldbetoidentifyclearlythefourdifferentopera
tionalmodesoftheaircraft:normal,emergency,emergencymorethan15min,and
reducedratingexception,andexpressaseparaterequirementforeach.
Notetheletoutclauseinthesecondexample.Itisnotclearwhatthescopeof
theclauseis.OneinterpretationisThesystemshallprovidegeneralwordprocessing
facilitiesifthatshouldbenecessary.Wellisitrequired,ornot?

https://translate.googleusercontent.com/translate_f 101/211
2017520 RequirementsEngineering

4.12Summary

Oneofthehardestthingstodoinrequirementsistogetstarted.Itisimportantto
haveanapproach,butaboveallitisimportanttostartwritingdowntherequire
mentsfromday1andshowthemtoothersforcomment.Thefollowinglistis
intendedasasafewaytoproceed:

Defineanoutlinestructureattheoutset,preferablyhierarchical,andimproveit
asyougo.
Writedownrequirementsassoonaspossible,eveniftheyareimperfect.
Determineinadvancewhatattributeswillbeusedtoclassifyandelaboratethe
textualstatement.
Produceaninitialversionrapidlytostimulateimmediatefeedback.
Perfecttherequirementsasyougo,removingrepetition,unwarranteddesign,
inconsistency.

Page111
4.12Summary 91

Brainstormandholdinformalreviewscontinually,withrapidturnaroundof
versions.
Exposuretousersismuchbetterthananalysisbyexperts.

Therulestofollowwhenwritingrequirementsareasfollows:

Usesimpledirectlanguage
Writetestablerequirements
Usedefinedandagreedterminology
Write onerequirementatatime

https://translate.googleusercontent.com/translate_f 102/211
2017520 RequirementsEngineering

Page113
Page112

Chapter5
RequirementsEngineeringintheProblem
Domain

Itisntthattheycantseethesolution.
Itisthattheycantseetheproblem.

GilbertKeithChesterton,author,18741936AD

5.1WhatistheProblemDomain?

Theproblemdomainisthedomaininwhichasystemisgoingtobeused.Therefore
itisimportanttolookatrequirementsfromanoperationalpointofview.Asystem
oranyotherproductenablessomebodyorsomeequipmenttodosomething.Itis
thisenablingaspectthatisattheheartofrequirementsengineeringintheproblem
domain.Facedwiththechallengeofelicitingrequirementsfrompotentialusersone
mightthereforebetemptedtoaskauserthequestion:
Whatdoyouwantthesystemtodo?

Someuserswillhavelittleornoideaofwhattheywantthesystemtodo.Those
whohaveanexistingsystemwillusuallyhaveideasabouthowtoimprovethe
system,butwhenthereisnoexistingsystemthissourceofinspirationisnotavailable.

https://translate.googleusercontent.com/translate_f 103/211
2017520 RequirementsEngineering

Answersmaybeforthcomingfromthosewithinsightintowhatispossible,butthey
aremostlikelytocomeupwithasolutionbecausethequestionisfocussingonthe
functionalitytobeprovidedbytheintendedsystem.
Toavoidthisprematurejumpintothesolutiondomain,itisnecessarytoaskthe
question:
Whatisthepurposeofthesystemyouwant?

Whenconsideringthepurposeofasystem,peopleimmediatelythinkaboutwhat
theywanttobeabletodowiththesystem,ratherthanhowtheywilldoit.What
peoplewanttoachievecanbestatedwithoutanyimplementationorsolutionbias
andthisleavesthesolutionspaceopentothesystemsengineersandarchitects.

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_5, 93
SpringerVerlagLondonLimited2011

Page114
94 5RequirementsEngineeringintheProblemDomain

Itcanbearguedthatevenmentioningthesysteminthequestioncouldbe
misleadingandthequestionreducesto:
Whatdoyouwanttobeabletodo?

Theanswerstothisquestionshouldbeoftheform:
Iwanttobeableto

Thisisknownasacapabilityrequirementandisoneofthekeyformsofrequire
mentintheproblemdomain.
Havingestablishedthatrequirementsengineeringintheproblemdomainispri
marilyaboutelicitingcapabilities,thenextquestionis
Whoshouldbeasked?

Thisleadstotheidentificationofstakeholders.RecallfromthedefinitioninChapter1
thatastakeholderisanindividual,groupofpeople,organisationorotherentitythathas
adirectorindirectinterest(orstake)intheintendedsystem(seeSection1.3.1).
Finallywemustexaminewhatsortsofmodelsarerelevanttotheproblem
domain.Clearlyanymodelsthatareusedmustbeunderstandabletothestakeholders,
becausetheyaregoingtoberesponsibleforvalidatingthem.Sincethestakeholders
havebeenchosenfortheirspecialistknowledgeintheproblem,theyaregenerally
unwillingorunabletocomprehendanymodelthatistheslightestbittechnical.For
example,ifyouweretogointoacarshowroomandexaminethecarsondisplay,
youwouldbeveryunlikelytobeinterestedinastatetransitiondiagramofthe
enginemanagementsystem.Youaremorelikelytobeconcernedabouttheperfor
manceofthecarintermsofitsacceleration,fuelefficiency,itscomfortleveland
theincarentertainmentfacilities.Inotherwords,youareconsideringwhatthecar
mightbeliketodriveonalongjourney.Inyourmindseyeyouarethinkingabout
animaginaryjourneyinthecarandconsideringalltheaspectsofthecarthatwould
beusefulorbeneficialduringthatjourney.Thisisanexampleofausescenario.
Ithasbeenfoundthatusescenariosareaverygoodwayofmodellingwhat
peopledoorwanttobeabletodo.Theyaredirectlyrelatedtothewaytheythink
abouttheirjobortheirproblems.Thescenariocanbeconstructedwiththestake
holdersandthenusedasabasisfordiscussingthecapabilitiesthatarerequired.
Thefinalaspectofrequirementsengineeringintheproblemdomain,isthatthere
maybesomeoverridingconstraints.Intheexampleofbuyingacar,youmayhave

https://translate.googleusercontent.com/translate_f 104/211
2017520 RequirementsEngineering

alimitedbudget,oryoumayrequirethecartobedeliveredwithinagivenperiod
oftime.Youmaywanttherunningcoststobebelowagivenlevel.
Itisnowpossibletoconsiderhowtoinstantiatethegenericprocessforthe
creationofstakeholderrequirements.

5.2InstantiatingtheGenericProcess

Figure5.1containsaninstantiationofthegenericprocessfortheelicitationof
stakeholderrequirements.ThestartingpointistheStatementofneed.Thismaybe
quiteasmallitem,e.g.itcouldbeanemailfromtheChiefExecutiveOfficer(CEO)

Page115
5.3AgreeRequirementswithCustomer 95

Statementof Agree Qualification

need Requirements Strategy

ChangeRequest

Use Analyse Stakeholders

Scenarios &
Model

Change
Request

Derive
Stakeholder
Requirements
&
Qualification
Strategy

ChangeRequest

Qualification
Stakeholder Agree Qualification
Qualification
Strategy
Strategy
Requirements Requirements Strategy

Fig.5.1Stakeholderrequirementsprocess

totheChiefTechnicalOfficer(CTO)statingthatanewproductisrequiredtoget
onestepaheadofthecompetition.Alternatively,theremayalreadyhavebeena
studyperformedtolookatpossibleoptionsandaconceptofoperationsdocument
producedthatidentifiessomeusescenarios.
Figure5.1indicatesthattheAnalyseandModelprocesscreatesasetofUse
ScenariosplusalistoftheStakeholders.Thederivedrequirementswillbestake
holderrequirements.
ThedetailsoftheAnalyse&ModelandDeriveStakeholderRequirementsand
QualificationStrategyprocessesareintroducedinthefollowingsections.

https://translate.googleusercontent.com/translate_f 105/211
2017520 RequirementsEngineering

5.3AgreeRequirementswithCustomer

Theagreementprocessatthestartofthestakeholderrequirementsprocessisusually
veryinformal.ItisquitelikelythattheStatementofNeedsisasimpledocumentthat
hasnotbeenengineeredfromarequirementspointofview.Inotherwordsitislikely
tocontainwoollyexpressionsofneedmixedwithdescriptiveinformation.Itwillnot
containatomicrequirementsthatcanbethetargetofsatisfactionrelationships.In
thisrespectthestakeholderrequirementsprocessisdifferenttootherrequirements

Page116
96 5RequirementsEngineeringintheProblemDomain

processesbecauseitstartsfromthisrathervagueposition.Oneofthekeyelements
inelicitingstakeholderrequirementsistoestablishthescopeoftheintendedsystem.
Thisisusuallydoneonceasetofusescenarioshasbeenestablished.

5.4Analyse&Model

TheAnalyse&Modelprocessisinstantiatedfortheproblemdomainasshownin
Fig.5.2.ThefirstactivityistoidentifystakeholdersandthentheUseScenarioscan
becreatedinconsultationwiththem.

5.4.1IdentifyStakeholders

Asindicatedearlier,astakeholdercanbeanypersonororganisationthathasan
opinion,aresponsibilityfor,orwhomaybeinfluencedoraffectedbytheproposed
system.Thetypesofstakeholdersvaryaccordingtothenatureofthesystem
e.g.onwhetherthesystemisaconsumerproduct,orapublicservicesuchasair
trafficcontrolorarailway.
Peoplewhohaveanopinionabouttheproposedsystemincludethosepeople
whowillusethesystemdirectly.Notethatthiscanincludethegeneralpublicwho
maybepassengersonaircraftortrains,ormaybeaffectedbyacrashwhenthey
wereotherwisenotinvolvedintravelling.Peoplewithresponsibilityforasystem
maybemanagersinchargeofoperatingthesystem,orsafetyauthorities.
Thefollowinglistcontainspossiblestakeholdercategoriesthatcanbeusedas
thebasisforestablishingwhetheracompletelistofstakeholdershasbeenidentified.

Statementof ChangeRequest
need

Analyse
Identify & Create
Stakeholders Model models

https://translate.googleusercontent.com/translate_f 106/211
2017520 RequirementsEngineering

Use
Fig.5.2Analyse&Modelpro Stakeholders
Scenarios
cessforStakeholderRequirements

Page117
5.4Analyse&Model 97

Thelistdoesnotclaimtobecomplete,butprovidesguidancetohelpwhenbrainstorming
tocreatethelist:

Managers:Peoplewhohavearesponsibilityforeitherthedevelopmentbudgetor
operatingbudgetoftheproposedsystem.Itisalsoagoodplantoinvolvesenior
policymakerswhowilltakeaviewonwhethertheproposeddevelopmentcon
formstotheaimsandphilosophyofthecompanyororganisation.
Investors:Peoplewhoeitherhavemadeorarebeinginvitedtomakeacontribution
tothefundingoftheproposedsystem,ortheorganisationsresponsiblefordevel
opingoroperatingthesystem.
Systemusers:Clearlythisisaveryimportantgroupofstakeholders.Theyhavea
directinterestinthecapabilitiesprovidedbythenewsystemorservice.Note
thattheremayalsobeuserswhodonotinteractdirectlywiththesystem.For
example,theusersoftheHubbletelescopeareastronomers.Theyaskforpho
tographstobetakeninspecificdirections,andtheyreceivetheinformation
whenitarrives,buttheydonotdirectlycontrolthetelescopeitself.Usersofan
existingsystemarealsovaluablesourcesofknowledgeofproblemswiththat
system.Theycangiveinvaluableinsightintohowtheywouldliketoseethe
systemimproved.
Maintenanceandservicestaff:Althoughtheirprimeresponsibilityistokeepthe
systemrunningonceithasbeendelivered,theydohaveimportantrequirements
thatthesystemmustaddressinordertohelpthemdotheirjob.
Productdisposers:Thisisanincreasinglyimportantroleasenvironmentalprotec
tionlegislationdevelops.Requirementsfromthissourcecanhaveamassive
impactondesignespeciallywithrespecttothematerialsemployed.
Trainingpersonnel:Likethemaintenancestaff,thesepeoplehaveavestedinterest
inmakingthesystemeasytouseandconsequentlyeasytotrainpeopletouse.
Thesepeoplemayalsorequirethesystemtobeabletoworksimultaneouslyin
amodewherelivedataandtrainingdatacanbemixedwithoutinterferingwith
thesafeoperationofthesystem.
Systembuyers:Forpublicservicesandotherlargesystems,thepersonwhobuysthe
systemmaynotbeinvolveddirectlywithitsdevelopmentoroperation.Theywill,
though,haveanimportantroletoplayinscopingthesystemfromthepointofview
ofcostversusperceivedbenefit.Forproductbaseddevelopments,thebuyermay
betheactualuser,e.g.mobilephoneuser,cardriveretc.
Salesandmarketing:Thesepeoplehaveavitalroletoplayinformulatingthe
capabilitiesfornewsystems,especiallyforproductbaseddevelopments,
because,formassproducedconsumerproducts,itisnotpossibletohaveaccess
toallpotentialusers.
Usabilityandefficiencyexperts:Thesepeoplehaveaviewonhowthesystemcan
beoptimisedtomakeitefficientinuse.Thesefactorsincludeergonomics,ease
oflearningand,whererelevant,abilitytobeusedreliablyunderpressure(e.g.
inairtrafficcontrol).

https://translate.googleusercontent.com/translate_f 107/211
2017520 RequirementsEngineering

Operationalenvironmentexperts:Usuallyanewsystemisnotcreatedtoworkin
agreenfieldssituationitwillhavetointeroperatewithexistingsystems.

Page118
98 5RequirementsEngineeringintheProblemDomain

Theremayalsobeotherenvironmentalaspectssuchasemissioncontrolwhere
thesystemmustnotpollutetheenvironment,andconversely,aspectswherethe
systemmustbeabletotoleratetheenvironmentinwhichitisplaced(e.g.in
extremeweatherconditions,submersedinwateretc.)
Government:Rules,regulationsandlawsdetermineandinfluencewhatasystem
mayormaynotdo.
Standardsbodies:Existingandfuturestandardscanaffectthegoalsofaproposed
system.ThesemaybeinternationalsuchastheGSMmobilephonestandards,
nationalstandardsorinternalcompanystandards.
Publicopinionandopinionleaders:Differentregionsoftheworldhavedifferent
attitudes.Thesefactorsmustberecognisedwhereaproductistobemarketedin
awiderangeofcountries.
Regulatoryauthorities:Theseorganisationsmayrequirethatcertainevidencebe
collectedaspartofacertificationorauthorisationprocess.Examplesincludethe
RailRegulatorintheUKandtheFoodandDrugAdministration(FDA)inthe
USA.

Havingarrivedatalistofpotentialstakeholdertypes,itisnecessarytodetermine
whichtypesarerelevantandhoweachstakeholdertypecanbeaccessed.Insomecases,
e.g.systemusers,itmaybepossibletohavedirectaccesstothem.Inother
cases,e.g.generalpublic,itisnotpossible.Itisnecessarytodecide,forthosethat
areaccessible,whowillbenominatedasthestakeholder(s)andforthosenot
accessible,whowilltakeontheroleofthatstakeholderandspeakontheirbehalf.
ThislistthenconstitutestheoutputStakeholdersfromthisprocess(seeFig.5.2).

5.4.2CreateUseScenarios

Mostconversationsarebuiltaroundasetofassumptionsonwhichthespeakers
agree.Theseassumptionscanbeinterpretedtobeamodeloftheirmutualunder
standing.Attemptingtodiscussrequirementsintheabsenceofanyagreedground
ruleswouldbeunproductive.
Onebasicstructuringmechanismfordiscussingcapabilityrequirementsisthe
operationalorusescenario.Thisproducesastructurethatisorganisedhierarchi
callybytime.Stakeholderrequirementsusethenotionofascenarioasameansof
establishingaframeworkinwhichmeaningfuldialoguecantakeplace.
Thescenarioencouragesthestakeholderstothinkaboutthejobthattheyare
doingandhowtheywouldliketodoit.Ineffect,theyarerehearsingthewaythey
wouldliketodotheirjob.Oncethescenarioisagreed,individualrequirementscan
begeneratedtodefinepreciselywhatitisthestakeholderswouldliketobeableto
doateachpointinthescenario.
Scenariosprovideanexcellentmethodforexploringrequirementswith
stakeholders.Theyareinherentlyaboutwhatthestakeholderswanttoachieve.
Ascenarioisthesequenceofresultsproduced(orstatesachieved)throughtime
forthestakeholders.AsshowninFig.5.3ausescenariomayberepresentedas

https://translate.googleusercontent.com/translate_f 108/211
2017520 RequirementsEngineering

Page119
5.4Analyse&Model 99

Fig.5.3Usescenarioas
ahierarchyofgoals e
Subgoal
Subgoal Subgoal

Subgoal

Subgoal
Final
Subgoal
goal
erationalsequenc
p
O
Subgoal
Subgoal Subgoal

Subgoal

Stepsleading
toendgoals

ahierarchyofgoalsandrepresentsthecapabilitiesprovidedbythesystemtothe
stakeholderswithoutsayinghowtoprovidethem.Inotherwordstheuse
scenarioisacapabilityhierarchy.
Thetimeorientationallowsarehearsalofwhatthesystemwillprovideand
thestakeholderscanstepthroughandseemissingandoverlappingelements.
Thisstructurethereforeavoidsovercommitmenttosolutionswhiledefiningthe
problemwell.
Thereisaclearlydefinedapproachtofollowwhencreatingusescenarios.The
basicquestiontoaskthestakeholderiswhatdoyouwanttoachieve?orwhat
statedoyouwanttobein?Theapproachisthentostartwiththefinalstateand
thenexpandthat,byaskingwhatstates,orintermediatesteps,needtobeattained
ontheway.Thestatesarethenexploredasatreeorhierarchy.Sothefollowing
procedureemerges:

Startwiththeendgoal
Derivethenecessarycapabilitiestogettothatpoint
Breaklargestepsintosmallersteps
Keepthesethierarchical
Reviewinformallyateachstage
Bewaryofdefiningsolutions

Ifthestakeholderfindsitdifficulttodefinetheintermediatestages,thestakeholder
canbeaskedtodescribeatypicalsituationitisimportanttoknowwhatthestake
holderwoulddoinasituationsuchasthis.Ifthesystemiscompletelynew,they
mayneedtousetheirimagination.Theycanpostulatewhattheywantorexpectto
happenorachieveateachstep.Itisimportantatthispointalsotoidentifyifany
stagesareoptional,orifthereareanyrepetitions.Woulddifferentconditionslead
todifferentsequences?
Thestakeholderalsoneedstoidentifytheorderofthecapabilitiesandwhether
thisisfixedorvariable,andifitisvariable,underwhatcircumstancesdoesitvary.
Forexample,beforeyoucanpaintapictureyoumusthavepaper(orcanvasetc.),

https://translate.googleusercontent.com/translate_f 109/211
2017520 RequirementsEngineering

Page120
100 5RequirementsEngineeringintheProblemDomain

paintsandbrushes,butitdoesnotmatterwhichisreadyfirst.Thisgivestheopportunity
tochangesequencingordothingsinparallel.
Itisimportant,asinallformsofrequirementscapture,toaccepteverythingthat
thestakeholderssay.Itcanalwaysberefinedlater.Frequentlyitwillbenecessary
toaskthestakeholderstoexpandonwhattheymean.
Scenariosrepresentthecapabilitiestobeprovidedbythesystem(inproblem
domainterms)organisedintoahierarchywithoutsayinghowtoprovidethem.
Theyareseentobebeneficialforthefollowingreasons:

Enablesstakeholderstostepthroughoperationaluse
Missingstepscanbefound
Differentstakeholderscanhavedifferentscenarios
Timeconstructscanbeidentified

5.4.2.1CharacteristicsofUseScenarios

Figure5.4containsanexamplescenariobasedonadayoutwithasailingboat,
whichcanbetransportedonacar.Itcoversalltheaspectsofthetripstarting
withloadingtheboatontothecar,gettingreadytosail,sailingandreturning
home.
Thescenarioalsoillustratessomeotherpoints:
Generally,itfollowsatimesequence.

Itsnodesarehighlevelcapabilities.
Itshowsalternatives.
Itshowsperiodicrepeatedbehaviour.
Itshowswheresequenceisnotimportant(parallelbranches).
Itshowsexceptions.

Theuseofatimesequenceisimportant.Notonlydoesitprovideasimpleframe
workforthestakeholdertounderstand,butitalsohelpstoplacestakeholder
requirementsintoacontext.
Itisimportantthatallthenodesareexpressedascapabilitiesattheappropriate
level.Usingthephraseabletointhenamesofthesenodeshelpstoavoidthe
tendencytothinkofthecapabilitiesasfunctions(andhencetomovetowards
implementationdetail).
Scenariosprovideaverypowerfulmethodofexploringexceptions.Inmany
systems,thefunctionalitytohandleexceptionsismorecomplexthanthatneeded
toprovidethemainstakeholdercapabilities.Thestakeholdercanbepromptedfor
exceptionsbyaskingquestionssuchaswhatcangowronginthisstate?orwhat
cangowronginreachingthisstate?Recoveryactionscanbeexploredbyasking
whatshouldbedone(orhappen)ifsomethingdoesgowrong.
IntheexampleofFig.5.4,itcanbeseenthatthescenarioincludestheneedto
communicatewhentheboatiscapsized.Intheabsenceofascenariothisrequire
mentmaynotbespotted.

https://translate.googleusercontent.com/translate_f 110/211
2017520 RequirementsEngineering

Page121

5.4Analyse&Model 101

Ableto Boatlifted

loadboat
Boatoncar

Ableto
getready Ableto
tosail unload
boat
sequential
Abletorigmast

Able
togo Ableto Abletorigrudder
sailing rigboat

parallel Abletorigcentreplate

Abletogibe
Ableto
sail Abletotack
Ableto Ableto
normally
sail manoeuvre
alternate Abletocruise
periodic alternate

Abletoright
Ableto
Ableto survive capsize
return capsize
home exception

Abletocontact
Ableto
goashore CoastGuard

Fig.5.4Exampleusescenario

Theexamplealsoillustrateshowscenarioscanmakeiteasytospotmissing
areasofrequirements.Inthiscasethecapabilitiesofbeingabletotransportthe
loadedboat(totheplacewhereitwillbesailed)andbeingabletolaunchare
missing.
Thepurposeofcreatingascenarioistopromoteunderstandingandcommunica
tion.Ascenarioisnotitselfarequirementitisratherastructureforelicitationof
requirements.Itisanaidtofindingacompletesetofrequirements,bycovering
everyaspectofoperationaluse.Anyonemodellingtechniquedoesnotattemptto
representallpossibleconcepts.Thereisnosinglecorrectwayofmodellingagiven
operation.Differentpeoplecomeupwithdifferentmodels.

5.4.3ScopingtheSystem

Whenpreparingthescenariositisbesttosettheboundaryabitwiderthanthe
anticipatedsystemboundary.Thisensuresthattheviewtakenisnotblinkered
andservestosetthesysteminitscontext.Atsomepointitisessentialtodetermine
wheretheboundaryofthesystemistobeplacedandhencetosetitsscope.

Page122
https://translate.googleusercontent.com/translate_f 111/211
2017520 RequirementsEngineering

102 5RequirementsEngineeringintheProblemDomain

Oncethecompletesetofscenarioshasbeenassembled,thescopeofthesystem
canbefinalised.Thisdecisionmayhavetobechanged,oncethecostofdeveloping
thesystemhasbeenestimated.Suchestimationcanbemadebypeoplewithexperi
enceofsystemdevelopmentforthedomainoftheproposedsystem.Estimates
basedpurelyonscenariosareverycoarseandconsequentlymusthaveahigh
degreeofuncertaintyassociatedwiththem.Neverthelessmakingsuchanestimate
canservetogiveaninitialideaofwhethertheproposedbudgetisintheright
ballpark.

5.5DeriveRequirements

TheDeriveRequirements&Qualificationstrategyprocesshasbeensplitintotwo.
Thesetwopartsarehandledinthissectionandthenext.
ThederiveRequirementsprocessisinstantiatedfortheproblemdomainas
showninFig.5.5.Thekeyactivitiesaretocapturerequirementsanddefineastruc
tureintowhichtoplacethem.Oncethestructureandthecandidaterequirements
havebeendecided,itispossibletoplacethecandidaterequirementsintothestruc
ture.Inpracticethetwoactivitiesgooninparallelandthestructureevolvesas
experienceofusingitdevelops.Therefore,insteadofhavingaseparateactivityto
takethecandidatesandplacethemintothestructureFig.5.5indicatesthatboth
activitiescontributetothecreationofstructuredrequirements.
Whenthestructurehasbeencompleted,therequirementsandthestructurecan
bereviewedandrefined.

5.5.1DefineStructure

Structureiscriticalforhandlingallcomplexelementsinthewholelifecycle.
Stakeholderrequirementsareusuallycapturedonebyone,cleanedupandthen
attachedintothestructure.
Someapproachesassumethat:

Stakeholderrequirementsareinherentlyunstructured.
Traceabilitytodesignisenough.
Weneverseeacompleterequirementsmodelrequirementsneedbeviewedonly
oneatatime.

Theseapproacheshavenothingtodowithquality,butaremerelyintheshortterm
interestsofthedeveloper.
Requirementsneedtobeorganised,andthereneedstobeagoodstructureto
managetheindividualrequirementsastheyemerge.Theargumentsaboutstructure
andtheneedforitarethesameforrequirementsengineeringinboththeproblem

Page123
5.5DeriveRequirements 103

https://translate.googleusercontent.com/translate_f 112/211
2017520 RequirementsEngineering
Stakeholders
Statementof
need
Use
Scenarios

Define Capture
structure Requirements

Structured Candidate
Structure
Requirements Requirements

Refine
Requirements
Generatestakeholder
requirements

Stakeholder
Requirements

Fig.5.5Deriveoutputrequirementsforproblemdomain

domainandthesolutiondomain.ThereforetheyhavebeenputtogetherinChapter4.
Inthischapteritisassumedthatprovidinganunderstandablestructureisvitally
important.Itremainsthereforetoindicatehowtoderiveastructureforstakeholder
requirements.
Themainstructuringconceptforstakeholderrequirementsistheusescenario.
However,therecanbemanysuchscenarios,dependingonthenatureofthesystem.
Itisrecommendedthattimeandeffortisexpendedtotryandmergescenarios
togethertomake,ifpossible,asingleoverallscenario.Obviouslythiswillnot
alwaysbepossible,butitisagoodideatoattempttodoit.Apartfromanyother
results,itreallymakespeopleawareoftheoverallextentofthesystemand
frequentlyexposesmanyissues.
Toexplainthewayinwhichscenarioscansometimebemerged,anexampleof
runningarestaurantwillbetaken.Threescenarioscanbeusedtodescribethe
restaurantasfollows:

TheoveralllifeoftherestaurantOwnersscenario
AdayinthelifeoftherestaurantManagersscenario
AmealattherestaurantCustomersscenario

Page124
104 5RequirementsEngineeringintheProblemDomain

Fig.5.6Restaurantlife 1Acquired
scenario

RestaurantLife
https://translate.googleusercontent.com/translate_f 113/211
2017520 RequirementsEngineering
2Operating

3Sold

1.1.1Meatdelivered

1.1.2Fishdelivered
1.1Fooddelivered

1.1.3Vegetablesdelivered
1Replenished
1.1.4Breaddelivered

1.2Drinksdelivered
RestaurantDay 2Open

4.1Tablescleared

4.2Washingupcomplete
3Closed
4.3Wastebinsready

4.4Replenishmentslisted

Fig.5.7Restaurantdayscenario

Fig.5.8Customermeal 1Tablebooked
scenario
2Arrivedandseated

3Foodserved
CustomerMeal
4Foodeaten

5Billreceived

6Billpaid

TheseareshowninFigs.5.6,5.7and5.8.
Thefirstgoalintherestaurantlifescenarioisthattheowneracquiresthe
restaurant.Thisisfollowedbyaperiodofoperatingtherestaurantandfinallythe
restaurantissold.
Therestaurantdayscenarioconsidersthestatesthattherestaurantisinduringtheday.
Thefirstgoalistoreplenishthestocksoffoodanddrink.Theseaspectsofthescenario
indicatethattherewillbeseveralsuppliers,butitdoesnotmatterwhichordertheir
deliveriesarrive.Itcouldbearguedthatthecompletionofreplenishmentisnotnecessary
beforetherestaurantisopened,butforthesakeofcreatingareasonableexampleithas
beendecidedthatnodeliverieswillbeacceptedwhilsttherestaurantisopentocustomers.
Thedayscenariothanhasaperiodofbeingopenandendsthedayclosedwithevery
thingtidiedupandthereplenishmentneedsrecordedreadyforthefollowingday.
Thecustomermealscenarioisastraightforwardsequenceofstates.

Page125
5.5DeriveRequirements 105

Ifwenowexaminehowthesescenarioscanbeputtogether,itcanbeseenthat:

TherestaurantdayscenariocanbearepeatingscenariointheOperatingstateof
therestaurantlifescenario,and
ThemealscenariocanbeaparallelrepeatingscenariointheOpenstateofthe
restaurantdayscenario.
https://translate.googleusercontent.com/translate_f 114/211
2017520 RequirementsEngineering

Thusanoverallstructureforthesethreedifferentstakeholderscenariosisshown
inFig.5.9.
Thiscanthenbecomethestructurefortheheadingsofthecapabilitiesinthe
requirementsdocument.
Thereare,ofcoursecircumstanceswhenitisjustnotpossibletofitscenarios
together.Thereisnoeasyanswerhere.Ifallelsefailsthenalltheseparatesce
narioscanbeusedoneaftertheother.ThusthestructureoftheStakeholderrequire
mentsdocumentwillbeasequenceofscenarios,eachwiththeirownrequirements
embedded.Essentiallythestructureisdrivenfromthelistofstakeholders.Even
inthisapproachattemptsshouldbemadetonestonescenarioinsideanother.
However,caremustbeexercisedtoensurethatthereisnoduplication.Where
thereisduplicationtheduplicatedpartsmustoccuronce.Twoapproachescanbe
used.Thefirstentailscuttingoutthecommonitemsandputtingtheminaseparate
sectionoftheirown.Theneachoccurrencemustreferencetheseparatedsection
attheappropriatepoint.Theotherapproachistoplacetheduplicatesectionin
thefirstscenariointhedocumentandthenreferencethisfromalltheother
occurrences.

2.1.1.1.1Meatdelivered

2.1.1.1.2Fishdelivered
2.1.1.1Food
delivered 2.1.1.1.3Vegetables
1Acquired 2.1.1Replenished delivered
2.1.1.1.4Breaddelivered
2.1.1.2Drinks
delivered

2.1.2.1.1Tablebooked

Restaurant 2.1.2.1.2Arrivedandseated
Life
2.1Restaurant 2.1.2 2.1.2.1Customer 2.1.2.1.3Foodserved
2Operating
Day Open Meal
2.1.2.1.4Foodeaten

2.1.2.1.5Billreceived

2.1.2.1.6Billpaid

2.1.3.1Tablescleared

3Sold 2.1.3.2Washingupcomplete
2.1.3Closed
2.1.3.3Wastebinsready

2.1.3.4Replenishmentslisted

Fig.5.9Overallscenarioandstructureforrestaurantcapabilities

Page126
106 5RequirementsEngineeringintheProblemDomain

5.5.2CaptureRequirements

5.5.2.1SourcesofStakeholderRequirements

Stakeholderrequirementscancomefromavarietyofsourcesasillustratedbythe
followinglist:

Interviewswithstakeholders
https://translate.googleusercontent.com/translate_f 115/211
2017520 RequirementsEngineering

Scenarioexploration(generallythroughstakeholderinterviews)
Descriptivedocumentation(perhapsfromstudiesormarketresearch)
Existingsystemswhicharebeingupgraded
Problemsandchangesuggestionsfromexistingsystems
Analogoussystems
Prototyping,eitherpartialsystems,mockups,orevensimplesketches,ofthe
productortherequirementsthemselves
Opportunitiesfromnewtechnology(approvedbystakeholders)
Studies
Questionnaires
Anthropomorphicstudiesoranalysisofvideos

5.5.2.2StakeholderInterviews

Toundertakethistask,therequirementsengineermustbeagoodcommunicator,
abletodigoutrealrequirementsfromstakeholderinterviews.Itisanintensepsychological
task,withlittleincommonwiththetechnicaloroperationalsideofsystemdevelop
ment.Itisimportanttorememberthatextractingstakeholderrequirementsisa
human,notatechnicalproblemandthereforepreparinginadvanceisimportantso
thattheworldofthestakeholderisunderstood.
Itisimportanttotalkthestakeholderslanguageaboutthestakeholders
world,notaboutthefinalproductoranytechnicalissues.Duringtheinterview
thestakeholdershouldbeaskedtostepthroughtheprocessofhis/herwork.A
comprehensivesetofnotesshouldbetaken,whichlatercanbeorganisedintoa
structuredsetofrequirementsandreturnedtothestakeholder.Interviewsarean
interactiveprocess,itisimportantthattherequirementsengineershouldnotbe
judgmental,butshouldrepeatedlyaskthequestionWhy?Thereareseveral
waysofaskingthisquestionincluding:WhatisthepurposeofthisorCan
yougivememorebackgroundonthisClearlytherequirementsengineeris
notexpectedtobeanexpertinthestakeholdersdomainandthereforewillneed
clarificationatvariouspoints.Dontworryaboutasking(apparently)stupid
questions.Theonlystupidquestionistheonethatitnotasked!Itisimportant,
however,thatfinallythestakeholderwilltaketheresponsibilityforthe
requirements.

Page127
5.5DeriveRequirements 107

Discussscenarioswiththepeopleinterviewed!
Thefollowingprovidesasetoftipsforstakeholderinterviews:

Intervieweverytypeofstakeholder.
Takethemseriously.
Documenttheinterviewsandinvitestakeholderstosigntherecordofthe
interview.
Identifywhichscenariosarerelevanttothestakeholder(s)beinginterviewedand
talkthemthroughit(them)invitingtheinterviewee(s)tostatewhattheywantto
beabletodoineachstateofthescenario.
Ifnecessarycreatenewscenariosasthediscussionproceedsandthendevelop

https://translate.googleusercontent.com/translate_f 116/211
2017520 RequirementsEngineering

requirementsfromthem.
Attempttodiscovertherelativeimportancetothestakeholderofeach
requirement.
Ifthestakeholderisvagueaboutanyrequirementaskfirstlywhatisthepurposeofthe
requirementandsecondlyaskhowtheproposedrequirementcouldbedemonstrated.
Enquireaboutanyconstraintsthestakeholderisawareof.
Makestakeholdersawarethattheirrequirementswillshapethesystem.
Stimulateandprovokethestakeholderstorespond.
Dontbejudgmentalaboutstakeholderrequirements.
Processthenotesintosinglerequirementsquickly,andtheniterate.

Generally,thequestioningwillproceedfromthegeneraltothespecific.Itisimpor
tanttobesuretocoveralltheground,definingwhichareasareirrelevant.Experience
ininterviewingdictatestheformofquestioningthattakesplace,dependingonthe
stakeholderandthesituation.

5.5.2.3ExtractingRequirementsfromInformalDocuments

Informaldocumentssuchasletters,studies,actionlistsandothertypesofdescrip
tivematerialmayallcontainrequirementshiddeninthedocumentation.Suchuser
requirementsshouldnotremainhidden,butshouldbebroughtoutintotheopen.
Butindoingsoitisimportanttorecordwherethestakeholderrequirementshave
comefrominotherwordsthesourcemustberecorded.Further,requirements
extractedinthiswaymustbesubstantiatedbyoneofthestakeholders.

5.5.2.4IdentifyingCapabilityRequirementsfromScenarios

Whenanoutlinescenariohasbeendeveloped,itispossibletopostulatecapability
requirementsdirectlyfromthem.Sometimes,asimpleparaphraseofthestateisall
thatisrequired.Forexample,thestatereadytosailcanbeparaphrasedasthe
capabilitytheusershallbeabletomakethesailingboatreadytosail.Inother
cases,moreworkisrequiredFig.5.10showssomeexamples,althougharenotvery
wellformulated.Considertherequirement:

Page128
108 5RequirementsEngineeringintheProblemDomain

Ableto Boatlifted

loadboat Twopeopleshallbeableto

Boatoncar lifttheboatintotheroofof
theaveragesalooncar

Ableto
Ableto
getready
tosail unload
boat
sequential
Abletorigmast

Able
togo Ableto Abletorigrudder
Thesailorshallbeable
sailing rigboat toperformagibe

parallel Abletorigcentreplate

Abletogibe

Ableto
Stakeholder
sail Abletotack
Ableto Requirements
Ableto normally
manoeuvre
sail

https://translate.googleusercontent.com/translate_f 117/211
2017520 RequirementsEngineering
alternate Abletocruise
periodic alternate

Ableto Abletoright
Ableto survive capsize
Thesailorshallbeable
return capsize tocontactthecoastguard
home exception

Ableto Abletocontact
CoastGuard
goashore

Fig.5.10Derivingcapabilitiesfromscenarios

Twopeopleshallbeabletolifttheboatontotheroofoftheaveragesalooncar

Thisraisesthequestions:

1.Howstrongarethepeople?
2.Whatisanaveragesalooncar?

Thesequestionsmusteventuallybeanswered.However,theimportantthingwhen
gatheringrequirementsistowritethemdown.Itdoesntmatteriftherearenot
wellformulatedatfirsttheycanalwaysbeimproved.Thecriticalissueisnotto
losetheidea!Misquotingawellknownproverbsumsupthisapproach:
Ajobworthdoingisajobworthdoingbadly!

Moreinformationonhowtoformulaterequirementsproperlycanbefoundin
Chapter4.

5.5.2.5RequirementsWorkshops

Analternativewayofcollectingstakeholderrequirementsistoholdrequirements
workshops.Thiscanbeanexcellentwayofrapidlyelicitingandcapturingrequire
ments.Itisimportantfromtheoutsetthatthestakeholdersaregatheredinanenvi
ronmentthatisconducive,andthattheyrealisethatcapturingrequirementsisnot
hardandneednottakealongtime.Thereshouldbeastructuretotheworkshop,but

Page129
5.5DeriveRequirements 109

Gatherstakeholdersina
conduciveenvironment

Structurethemeeting
teachthesubjectarea

Presentstakeholderswith
arequirementsdocument
or
asetofusescenarios

Encouragecriticismand
interactionamong
stakeholders

https://translate.googleusercontent.com/translate_f 118/211
2017520 RequirementsEngineering

Rapidlyprocessthe
amendments

Produceanewversion

Fig.5.11Workshopsforrequirementscapture

itshouldalsobeiterative.AsshowninFig.5.11,stakeholdersshouldbeeducatedto
understandwhatisexpectedofthem.Forexample,theyneedtounderstandthe
conceptsof:

Stakeholder
Usescenarios
Capabilityrequirements

Dependinguponthestartingpointoftheworkshop,theremaybeanexistingsetof
requirementsalreadyindraftform.Alternatively,startbysplittingtheattendees
intoteamsandgetthemtocreatescenariosfortheintendedsystem.Thenreview
thesetofscenariosgeneratedwiththefullgroup.Makeanyrequiredchangestothe
scenariosandthenmoveontoextractingrequirementsbasedonthem.
Assoonaspossiblepresentthedraftrequirementstothefullgroupandencourage
criticismanddiscussion.Thepossibilityofinteractionsbetweenthedifferentstake
holdergroupsaddssignificantvaluetotherequirements.Oftenthiscanbethefirst
timethatsuchagrouphaseverbeentogether.Itisalwaysinterestingandsatisfying
whentheinteractionsbetweenthegroupsleadstothecreationofrequirementsthat

Page130
110 5RequirementsEngineeringintheProblemDomain

giveagreaterinsightintowhateachgroupwantstobeabletodoandhowthese
capabilitiesfitinwiththoseofothergroups.
Thesedayswithvideoprojectors,thewholegroupcanbeinvolvedwithediting
therequirementsonline,butitcanbemoreproductivetosplitintosmallergroups
toworkonsubsetsforaperiodandthenreviewthewholesettogether.Inthisway,
foratypicalproject,asetofrequirementscanbeproducedin34days.
Thekeyelementofaworkshopisfirstlytoestablishmomentumandthento
keepitup.Runningaworkshopcanbeverydemanding,buttheresultscanbevery
rewardingforallconcerned.
Itisvitalthatallstakeholdergroupsarerepresentedandthattheyareempowered
tomakedecisions.

5.5.2.6RequirementsLearntfromExperience

Problemsreportedbyrealusersofasystemaregolddustyetthisinformationis
oftenthrownaway.Thereissomehowanegativeattitudetosuchinformation
becauseitisassociatedwithaproblem,butitcanbeofrealvalue.Obviouslythe

https://translate.googleusercontent.com/translate_f 119/211
2017520 RequirementsEngineering

earliertheproblemisdetectedthelessthecostofchange,andallowingchangesto
bemadetooeasilykillsaproject.Howeverinaniterativedevelopment,itisoften
possibletopostponechangesuntilthenextpassthroughthesystem.

5.5.2.7RequirementsfromPrototypes

Prototypescanbeinvaluablewhencreatingunprecedentedsystems.Theycanbe
usedtogivestakeholdersanideaofwhatmaybepossible.Theyarealsovery
importantinthedevelopmentofsoftwarebasedsystemswheretheuserinterfaceis
difficulttoimagine.Theproblemwithprototypescanbethatthedevelopersget
carriedawayandspendtoomuchtimeandeffort.Prototypedevelopmentshould
thereforealwaysbetreatedasasmallsubprojectwithitsownstakeholderrequire
ments.Theobjectiveoftheprototypeshouldalwaysbeclearlyindicatedandwill
usuallybetoprovidegreaterinsightsothatstakeholderrequirementscanbemore
easilyandaccuratelyformulated.
Therearethreeproblemswithprototyping:

1.Thedevelopersgetcarriedawayandgointofartoomuchdetail.
2.Theprototypetendstocausestakeholderstostrayintoimplementation.
3.Thestakeholdersmaybesoimpressedwiththeprototypethattheywanttouseit
operationally.

Thefirsttwoproblemscanbecounteredbyproperlyformulatingtherequirements
fortheprototype.Tocounterthethirdproblemitisalwaysimportanttoensurethat
stakeholdersarefullyawareoftheillusorynatureofaprototype,sinceaprototype
canbeapartialsystem,amockup,orevenasetofsimplesketches.

Page131
5.5DeriveRequirements 111

5.5.2.8ConstraintsintheStakeholderRequirements

Aconstraintisatypeofrequirementthatdoesnotaddanycapabilitytoasystem.
Insteaditcontrolsthewayinwhichoneormorecapabilitiesaretobedelivered.
Forexample,considerthefollowing:
Acustomershallbeservedwithin15minutesofplacingtheorder.

Thisdoesnotmakethesystemdifferentperseitjustquantifiestheservicetobe
provided.
Nevertheless,awordofcautionisrequiredhere.Amassofconstraints,eachone
reasonable,canmakeadevelopmentimpossible,thereforetheyhavetobeanalysed
asasystemaswellasindividually.
Whenthedesignisknown,eachconstraintshouldbeanalysedforitscost/
benefitvalueorimpactuponthesystem.Aconstraintmaybringafunctioninto
existence,forexample,acautionandwarningsystemorabackup.Thecostofa
constraintcanonlybeguessedbeforethedesignisknown.Thisunfortunately
dependsonthedesignchoice,butsomeminimumassumptionscanbemadetoo
manyunnecessaryconstraintscanruinasystem.
Bydefault,aconstraintappliestothetopcapabilityandallitschildcapabilities
inheritit.Theapplicabilityshouldbepusheddownthecapabilityhierarchyasmuch
aspossible(seeFig.5.12)tolimititsapplicabilityandhenceitscostimpact.When

https://translate.googleusercontent.com/translate_f 120/211
2017520 RequirementsEngineering

aconstraintappliestojustonecapability,thatconstraintcanbewrittenaspartof
thecapability.
Itisinterestingtonotethedifferencebetweenstakeholderconstraintsand
systemrequirementsconstraints.Stakeholderconstraintsrefertotheresultsthatthe
stakeholderswant.Systemconstraintsareprofessionalorengineeringconstraints
thataffectthequalityoftheproduct.Allofthestakeholderconstraintsmustbe
addressedinthesystemrequirements.Sometimestheymustbereformulated
sometimestheycanbepassedonwithoutchange.

Constraints Capabilities

Safety
Comfort
Applicabilitylink
Availability
Easeofuse
Runningcosts

Fig.5.12Capabilitiesandconstraints

Page132
112 5RequirementsEngineeringintheProblemDomain

5.5.2.9RefineRequirements

Revieweachrequirementinitscontextandensurethat

1.Itbelongsintheplaceitisin.
2.ItconformstothecriteriaforwellwrittenrequirementsasexplainedinChapter4.

5.5.2.10DeriveQualificationStrategy

Therearetwosubprocessesusedtoderivethequalificationstrategyasshownin
Fig.5.13.Thesearedescribedinthefollowingsubssections.

5.5.3DefineAcceptanceCriteria

Understandingthecriteriathatwillsatisfythestakeholdersthatarequirementhasbeen
metisanessentialandvitalpartofgatheringrequirements.Askingthequestion:
Whatwillconvinceyouthatthisrequirementhasbeensatisfied?

canoftenleadtoaclearerandmorefocussedformulationofarequirement.This
questionisthereforeoftenusedduringstakeholderinterviews.Thequestioncanbe
answeredintwoways:

https://translate.googleusercontent.com/translate_f 121/211
2017520 RequirementsEngineering

1.Stakeholdersmaydefineanoperationalsituationinwhichtherequirementcan
bedemonstratedand/or
2.Stakeholdersmaydefineanumericalvalueforalevelofachievementthatmust
bedemonstrated.

Use
Stakeholders Scenarios

Derive
Qualification
Strategy
Define Define
acceptance qualification
criteria strategy

Acceptance Stakeholder Qualification

criteria Requirements strategy

Fig.5.13Processestoderivethequalificationstrategy

Page133
5.5DeriveRequirements 113

Thefirsttypeofanswerfeedsdirectlyintotheprocessofcreatingasetoftests,
trialsordemonstrationsthatmustbepartofthequalificationstrategy.Thesecond
typeofanswerindicatesthepassmarkforatrialtestordemonstration,i.e.it
indicatestheacceptancecriterionfortherequirement.
Acceptancecriteriadefine,foreachrequirement,whatwouldbeasuccessful
outcomefromthequalificationapproachadopted.Acceptancecriteriaareusually
recordedinanattributeassociatedwiththerequirement.Inotherwordsthereis
usuallyaonetoonerelationshipbetweenarequirementanditsacceptancecrite
rion.Intheexampleoftherestaurant,theacceptancecriterionfortherunningof
therestaurantmaybethatitissuccessful.Successcanbemeasuredinanumber
ofwayse.g.:

1.Profitability.
2.Returnoninvestment.
3.Reputationasindicatedinguidebooks,newspaperarticles,etc.
4.Forwardloadintermsofhowfaraheadistherestaurantfullybooked.

Differentstakeholdersmaywellhavedifferingideasaboutsuccess,forexample,
theownersbankmanagerwillbemoreinterestedinthefirsttwo,butthechefwill
certainlybemoreinterestedinthelasttwo.
Thusitisimportanttodeterminetheacceptancecriteriaforanyrequirement
fromallthestakeholderswhomayhaveanopinion.

5.5.4DefineQualificationStrategy

https://translate.googleusercontent.com/translate_f 122/211
2017520 RequirementsEngineering

Thewayinwhichacceptabilityisdemonstrateddependstoaverylargeextenton
thenatureoftheapplicationandthewayinwhichithasbeenacquired.Forlarge
oneoffsystemssuchasairtrafficcontrol,itwillbenecessarytomakesurethatall
thefunctionalityhasbeenproperlyprovidedandthatthecontrollersarehappythat
thesystemcanusedeasilyandquicklywhentheyarebusy.Thiswillrequirea
mixtureoftestsandtrials.Firstlythecapabilityofthesystemunderlightloading
mustbedemonstrated.Ifthiscapabilityisnotacceptablethenthereisnopointin
progressingtoteststhatinvolvemuchmoreinvestmentsuchaslivetrialsatabusy
timeofday.
Thecostofthequalificationstrategymustalsobeborneinmind.Mounting
extensivetrialsisaverycostlybusinessandsotheremustalwaysbeagradual
buildup.Forexample,mostshipswillundergoharbourtrialsbeforeseatrials.
Theoverallcostmustalsobetakenintoconsideration,butthismustbeset
againsttheriskoffailingtodiscoverasignificantflawinthesystemduringopera
tionaluse.Thus,wherethereisalargesafety,environmentalorfinancialrisk,the
qualificationstrategymustbeverycarefullyengineeredtoensureagradualbut
steadybuildupofconfidenceinthesystem.Ontheotherhand,wheretheconse
quencesofmalfunctionarequitelight,alessexpensiveapproachcanbeunder
taken.Thebottomlineisthatarequirementthatcannotbedemonstrated(insome

Page134
114 5RequirementsEngineeringintheProblemDomain

way)isnotarequirement.Properlyengineeredrequirementsarerequirementsthat
areeasytounderstandanddemonstrate.

5.6Summary

Stakeholderrequirementsmustbekeptassmallaspossibleandeasytounderstand.
Thestakeholderrequirementsmustbenontechnicalandatthesametimerealistic.
Theremustbeafocusonrolesandresponsibilities,anditisimportanttoproperly
distinguishbetweenstakeholdergroups.
Thecommonproblemsthatcanoccur,whenderivingstakeholderrequire
ments,are:

Overemphasisonsolutions.
Underemphasisondefiningtherealproblemstobesolved.
Failuretounderstandthatstakeholdersmustownandapprovetheserequirements.

Stakeholderrequirementsshouldbebuiltasquicklyaspossible,theydefinethe
capabilitiesthatthestakeholdersrequire,expressedintermswithwhichtheyare
comfortableandfamiliar.Thereshouldthereforebeaconcentrationonthestake
holderdomain,notonsystemsolutions.Theyshouldbestructuredandtraceableto
thesourceoftheinformation.Stakeholderrequirementsareownedbystakeholders,
scopedbythebudgetholderandoftenwrittenbyrequirementengineering
specialists.

https://translate.googleusercontent.com/translate_f 123/211
2017520 RequirementsEngineering

Page135

Chapter6
RequirementsEngineeringintheSolution
Domain

Nevertellpeoplehowtodothings.Tellthemwhattodo,and
theywillsurpriseyouwiththeiringenuity.

GeorgeSmithPatton,general,18851945AD

6.1WhatistheSolutionDomain

Thesolutiondomainiswhereengineersusetheiringenuitytosolveproblems.The
primarycharacteristicthatdifferentiatesthesolutiondomainfromtheproblem
domainisthat,invariablyrequirementsengineeringinthesolutiondomainstarts
withagivensetofrequirements.Intheproblemdomainrequirementsengineering
startswithavagueobjectiveorwishlist.Theextenttowhichtheinputrequirements
forthesolutiondomainarewellformeddependsuponthequalityofthepeople
withinthecustomerorganisationthatdevelopedthem.Inanidealworld,allthe
requirementswouldbeclearlyarticulated,individualtestablerequirements.
AsindicatedinChapter2,thesolutionisveryrarelyarriveditinasinglestep
(seeFig.6.1).
Ateachlevelthereismodellingandanalysisdonetofirstlyunderstandtheinput

https://translate.googleusercontent.com/translate_f 124/211
2017520 RequirementsEngineering

requirementsandsecondlytoprovideasoundbasisforderivingtherequirements
forthenextleveldown.Thenumberoflevelsofdesignisdictatedbythenatureof
theapplicationdomainandthedegreeofinnovationinvolvedinthedevelopment.
Nomatterhowmanylevelsarenecessaryitisalwaysvitaltounderstandhowmany
solutiondetailsthehowshouldbeintroducedateachstep.
Ateverylevelinthesolutiondomain,engineersmustmakedecisionsthatmove
towardsthefinalsolution.Eachofthesedecisions,bytheirverynaturereducesthe
availabledesignspace,i.e.theyprecludecertaindesignoptions,butitisimpossible
tomakeprogressintheabsenceofdecisions.Engineersarealwaysverystrongly
temptedtogointotoomuchdetailtoosoon.Thistemptationmustbeavoided,in
ordertoallowcreativityandingenuitytoworktogethertoproduceinnovative
solutionsthatcouldneverbeachievedinthepresenceoftheconstraintsimposed
byprematuredesigndecisions.

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_6, 115
SpringerVerlagLondonLimited2011

Page136
116 6RequirementsEngineeringintheSolutionDomain

StakeholderRequirements Acceptancestrategy

Define
Engineer System Analysis
System Requirements Model Results
Requirements

SystemRequirements Systemteststrategy

CreateDesign Engineer System Analysis

Architecture Requirements ArchitectureModel Results

SystemComponentRequirements
Subsystemteststrategy
(SubsystemRequirements)

CreateSubsystem Engineer Subsystem Analysis

Architecture Requirements ArchitectureModel Results

SubsystemComponentRequirements
Subsystemcomponentteststrategy
(lowerlevelsubsystemrequirements)

Fig.6.1Possibleinstantiationsofthegenericprocess

Typicallythefirstlevelofsystemdevelopmentinthesolutiondomainistotransform
thestakeholderrequirementsintoasetofsystemrequirements.Thesemustdefinewhat
thesystemmustdoinordertosolvetheproblemsposedbythestakeholderrequirements.
ThisfirstlevelisillustratedbythetopinstantiationofthegenericprocessinFig.6.1.
Theissueofprematuredesigndetailisespeciallyproblematicatthefirststep.The
SystemModelindicatedinFig.6.1mustbecreatedatalevelofabstractionthatenables
thefunctionalityofthesystemtobedefinedwithoutgoingintounnecessarydetail.
Thenextsteponfromdefiningthesystemrequirementsistocreateanarchitec
turaldesignasindicatedbythesecondinstantiationofthegenericprocessin
Fig.6.1.Thismustbeexpressedintermsofasetofcomponentsthatinteractto
generatetheemergentpropertiesidentifiedbythesystemrequirements.The
derivedrequirementsfromthearchitecturaldesignprocess(Fig.6.1)definethe
requirementsthatthecomponentsuppliersmustsatisfyforeachcomponent.
Developmentproceedsbyfurtherlevelsofdesignthatmovefurthertowards
implementationdetail.
Thischapterconcentratesonthetransformationfromstakeholderrequirements
https://translate.googleusercontent.com/translate_f 125/211
2017520 RequirementsEngineering

tosystemrequirementsbecauseitisthemostproblematicinmostdevelopments,
becausetypicallytoomuchdetailisaddedtoosoon.

6.2EngineeringRequirementsfromStakeholder
RequirementstoSystemRequirements

Thefullinstantiationofthegenericmodelforthistransformationisshownin
Fig.6.2.
Aswithallinstantiations,theprocesscommencesbyagreeingtheinputrequire
ments,which,inthiscase,arethestakeholderrequirements.Theagreementprocess

Page137
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 117

Stakeholder Agree Qualification

Requirements Requirements Strategy

ChangeRequest

System Analyse Analysis

Models & Results
Model

Change
Request

Derive
Requirements
&
Qualification
Strategy

ChangeRequest

System Agree Qualification

Requirements Requirements Strategy

Fig.6.2Instantiationofgenericprocesstocreatesystemrequirements

mustnotassumethattheinputrequirementshavebeenproducedaccordingtothe
guidelinesgivenearlierinthisbook.Instead,itisnecessarytoconsidertherequire
mentsandtheassociatedqualificationstrategyontheirmeritsandapplythereview
criteriaforstakeholderrequirementswithrigourandthoroughness.

6.2.1ProducingtheSystemModel

https://translate.googleusercontent.com/translate_f 126/211
2017520 RequirementsEngineering

Toavoidthetendencytogointotoomuchdetail,engineersshouldalwaysworkin
thecontextofamodel(seeFig.6.1)thatissufficientlydetailedforthepurposeof
definingrequirementsintermsofwhatshouldbedoneratherthanhow.Thelevel
ofdetailthatshouldbeprovidedinderivedrequirementsdependsuponthelevelof
developmentatwhichrequirementsengineeringisbeingdone,butthemaximis
alwaysdonotaddmoredetailthanisnecessary.Thetemptationtogointodetail
isalwaysgreatestatthetoplevelwhereStakeholderrequirementsexpressedin
problemdomaintermsarebeingtranslatedintohighlevelsystemrequirementsthat
indicatewhatthesystemmustdotosolvetheproblemsposedbytheStakeholders.

Page138
118 6RequirementsEngineeringintheSolutionDomain

Thedifficultyarisesbecauseoftheneedtoworkatanabstractlevel.Thecreation
ofanabstractsystemmodel,whichwillprovidetheframeworkforthesystem
requirements,alwayscausesproblems.Atalllevelsbelowthis,developmentwork
progressesinthecontextofadesignarchitecture.Engineersaremuchmore
comfortablewiththislevelofdetail,becausetheycangetinvolvedwithdetermining
howthesystemwillwork.Evenattheselevels,caremustbeexercisedtoensure
thattheamountofdetailimposedisappropriate.Consequently,thearchitecture
modelsshouldbeexpressedintermsofcomponentsthatworktogether,butcareshould
betakentoensurethatcomponentsaredefinedintermsofwhattheyarerequiredtodo
ratherthanhowtheyshouldachieveit.Inotherwordscomponentsshouldbe
specifiedasblackboxeswhoseinternaldetailsareofnoconcernprovidedthat
theyachievetheiroverallpurposeasdefinedintherequirements.
Thenextsectionsofthischapterconcentrateonthepreparationofsystem
modelsforthederivationofsystemrequirements.Followingthis,thewaysin
whichthesameapproachisappliedatmoredetailedlevelsisexplained.

6.2.2CreatingSystemModelstoDeriveSystemRequirements

Thesystemmodelmustbecreatedatanappropriatelevelofabstractionsuchthat
itencompasses:

Internalfunctionalitythatthesystemmustexhibitthismustconcentrateon
whatthesystemmustdoratherthanonhowitshouldbedonetoavoid
preemptingthedesign.
Functionalitynecessarytoenablethesystemtointeractwithothersystemsinits
environment.
Functionalitynecessarytoenablepeopletosuccessfullyinteractwithit.
Functionalitytopreventthesystemfrommalfunctioningduetothepresenceof
othersystems(threats)initsenvironment.(Notethatsomeofthesesystemsmay
notbedeliberatelythreatening,e.g.electromagneticemissionsfromneighbouring
equipments.)

Thissafeguardfunctionalitymustalsopreventthesystemfrominterferinginan
adversewaywiththeenvironment.
Thewayinwhichthesetypesoffunctionalityinteractwitheachotherandwith
elementsinthesystemsenvironmentisexpresseddiagrammaticallyinFig.6.3.Itisclear
thatthecontextofthesystemwithinitsenvironmentmustbedefinedwithrespectto:

Theexistingsystemswithwhichthenewsystemisrequiredtocooperate

https://translate.googleusercontent.com/translate_f 127/211
2017520 RequirementsEngineering

Thetypesofpeoplewhoareintendedtointeractwiththesystem
Thethreatsthatthesystemmustdefendagainstand
Theadverseeffectsthatmustbeprevented

Thefunctionalitycanberepresentedinanumberofways,forexample,

Operationsormethodsonclassesinclassdiagrams
Messagesequencecharts

Page139
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 119

External Human
Cooperating Interface Internal People
Interaction
Systems Functionality Functionality
Functionality

Safeguard
Functionality

External
Threatening
Systems

Fig.6.3Systemcontextandtypesoffunctionality

Model Model System

A B Information
Domain

Model Model
C D

Model
E

Fig.6.4Scopeofsystemmodels

Statetransitiondiagrams
Functionflowblockdiagrams
Processesindataflowdiagrams

Inpracticeitwillbenecessarytouseseveralmodelsinordertocoverthemanydifferent
aspectsrequired.Eachmodelcontainsinformationofadefinedsetoftypesandeach
modellingtechniquecarriesitsownsemantics.Theinformationforsomemodelsmay
bequiteseparatefrominformationinothermodels.Ontheotherhandthesame
informationmayappearinmorethanonemodel.Inthelattercaseitisessentialthat,
wheninformationischanged,thechangeisreflectedinallothermodelsinwhichthat
informationoccurs.Ideallythiswouldbeachievedautomaticallybylinkingthe
modellingtools.Ifthisisnotthecasethenextremecareshouldbeexercisedtoensure
thatanychangeisappliedidenticallyinallrelevantmodels.TheVenndiagramin
Fig.6.4indicatesthatsomemodelsrepresentislandsofinformationwhereasothers
mayhavecommoninformationpresentedindifferentforms.Figure6.4alsoindicates
thattheremaybesomesysteminformationthatisnotpresentinanymodel.

https://translate.googleusercontent.com/translate_f 128/211
2017520 RequirementsEngineering

6.2.2.1InternalFunctionality

Thisistheprimaryelementofthecreationofthesystemrequirements,because
itisthemainfocusofdefiningwhatthesystemwilldo.Itisnecessarytocreate

Page140
120 6RequirementsEngineeringintheSolutionDomain

astructureormodelthatcanbethebasisforcreatingthesystemrequirements.
Thismodelmusthavethecapabilitytoexpresssomeformofdecompositionof
thesystemintomodulesorhighlevelcomponentssuchassubsystems.Theuse
oftermssuchasmoduleorcomponenttendstomakedevelopersthinkmore
intermsofimplementationratherthanspecification.Thisisgenerallyconsidered
tobebadpractice,especiallyinsoftwarebasedsystems.Ingeneralsystems,the
needtomovetoamorephysicalmodelisnotconsideredtobeparticularly
problematic,sincetheapplicationdomainwillgenerallybeofamorephysical
nature.
Asanalternativetoterminologythatmayinduceprematureimplementation,
thereisanincreasingtendency(somewouldsayfashion)tousethetermobject
asthedecompositionelement,especiallyforsoftwarebasedsystems,sinceobjects
canrefertoitemsintheproblemdomain.Thisdisciplinehelpstopreventthe
prematuredescentintosolutionterms.Functionalitycanthenbeintroducedas
methodsoroperationsonobjectsandasinteractionsbetweenobjects.
Theuseofthisobjectorientedapproachcanalsomakethecreationoftrace
abilityfromthesystemrequirementstothestakeholderrequirementsaneasiertask,
becausethesameobjectstendtobevisibleinboththeproblemdomainandthe
solutiondomain.
Inadditiontostatingwhatthesystemmustdo,thesystemmodelmayalsobe
requiredtoindicatetheintendedbehaviourofthesystem.Thereareanumberof
waysinwhichtorepresentthistypeofinformation.Modelsinthisareausually
representthefactthereareanumberofconcurrentlyactiveactorsthatinteractin
someway.Examplesofthissortofnotationaremessagesequencechartsand
behaviourdiagrams.Messagesequencechartshavelongbeenusedinthetelecom
municationsindustry.BehaviourdiagramsoriginatedintheUSballisticmissile
earlywarningsystem(BMEWS)inthe1970sandhavebeenimplementedintools
suchasRDD100fromAscentLogicCorporationandCOREfromVitech
Corporation.
Behaviourcanalsobemodelledusingstatetransitiondiagramsorstatecharts.
Statetransitiondiagramshavethelimitationthattheycanonlymodelasequence
ofstatesandtheitembeingmodelledcanonlybeinoneofthesestatesatanyone
time.Statetransitiondiagramscannotrepresenthierarchicalstatesdirectly.
Separatediagramsmustbeusedforeachlevelinthehierarchyand,insomecases
thismeansthattheremaybeasetofactivediagramsatcertaintimes.Suchsetsof
diagramscanbedifficulttounderstand.Toavoidthiscomplexityitisbettertouse
statechartsbecausetheyhavebeendevelopedtodirectlyhandlestatehierarchies.
Theyalsoaddressparallelstates.
Inanysystemitisnecessarytoconsiderwhetherthereisinformationtobe
handled.Somesystems,e.g.insurancecompanysystems,requirethatinformation
mustbegatheredandretainedforuseoveranumberofyears.Inothersystems,
e.g.radardataprocessingsystemsforairtrafficcontrol,thereissomeinformation
thathasalonglifetime,e.g.flightplans,whereasthecurrentpositionofanaircraft
inflight,byitsverynature,soongetsoutofdate.Thustheinformationrequire

https://translate.googleusercontent.com/translate_f 129/211
2017520 RequirementsEngineering

mentsmustbeexaminedtoascertain:

Page141
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 121

Thelongevityoftheinformationi.e.forhowlongistheinformationrelevant,
andforhowlongmustitberetained?
Thefreshnessoftheinformationi.e.howuptodatemustitbe(seconds,minutes
orhours)?

Itisalsoveryrelevanttoknowtheamountofinformationthatmaybeinvolved.
Thiscanhaveaprofoundeffectonthedesignofthesystem.

6.2.2.2InterfaceFunctionality

Itisnecessarytodefinethenatureoftheinteractionsrequiredwithanyother
system.Interactionsmayinvolvethemovementofinformation,ormaterialbetween
thesystems.Themovementmaybeinonedirectionorboth,andtheremaybe
limitsonthecapabilitythatcanbetransferred.Itmaybenecessarytoprovide
temporarystorage(e.g.databufferorwarehouse)foritemsthatareheldup.There
maybetimeresponserequirementsonthespeedwithwhicheithersystemmust
reacttoastimulusfromtheother.
Thenatureofinterfacesvariessignificantly.However,theremustalwaysbea
baselinereferencethatindicateswhateachpartyundertakestodoorprovideaspart
oftheinterface.TheseobligationsarefrequentlydocumentedinanInterface
ControlDocument(ICD).Wheretheinteractionsarecontrolledbynationalor
internationalstandards,thestandardbecomestheinterfacecontroldocumentto
whichallrelevantpartiescanwork.Wheretheinterfaceislesswelldefined,the
obligations(i.e.interfacerequirements)muststillbewrittendownandagreed.
Controloftheserequirementsisnotoriouslydifficultbecausethereisoftenno
organisationwithaclearmandatetocontroltheinterface.Consequentlyeachparty
totheinterfacetendstohaveitsownversionofthedocumentand,worse,each
partytendstohaveitsowninterpretationofit.
Itisusualforinterfacedocumentstobecontrolledbytheorganisationthathas
responsibilityforthesystemthatencompassesthetwo(ormore)systemsthatinteract.
Suchanorganisationisquitedifficulttodefinewhenanewsystemisbeingdeveloped.
Oftentheexistingsystem(s)willhavebeendevelopedearlierandtheinterfaces
maynotbeproperlydocumented.Further,thedevelopmentorganisationmaywell
nolongerhaveanyresponsibilityforthatsystem,havinghandeditovertoahigher
levelcustomerorotheroperatingauthority.
Caremustbeexercisedtoensurethatallinterfaceobligationsareaccurately
reflectedinderivedrequirementsattheappropriateleveland,sofarasispossible,
theinterfacecontrolauthorityisclearlydefined.

6.2.2.3HumanInteractionFunctionality

Thecrucialissueforhumaninteractionswithasystemistoknowwhatinteractions
aregoingtoberequired.Thecontextinwhichtheuserswillworkisalsoimportant.

https://translate.googleusercontent.com/translate_f 130/211
2017520 RequirementsEngineering

Page142
122 6RequirementsEngineeringintheSolutionDomain

Thiscanhaveanimpactonthewaytheycanwork.Forexample,usersworkingin
astandardofficeenvironmentwillbewarmandabletoworkconvenientlywithout
gloves.Otherusersmayhavetooperatethesysteminharshenvironmentssuchas
extremecoldweather,orhazardoussituationswhereprotectiveclothingwillbe
necessary.Inthesecircumstancesthedesignofthedisplaysandkeyboardsmust
takenoteoftheseaspects.

6.2.2.4SafeguardFunctionality

Theenvironmentinwhichasystemmustoperatewillalsohaveasignificantinflu
enceespeciallywithrespecttosafetyandsecurity.Forexample,inabankingsystem
itisnecessarytoprovideassurancethatinformationandmoneywillnotbegivento
unauthorisedpeople.Inacar(system)itisnecessarytobeassuredthatthecarwill
stopwhenthebrakepedalisoperated.
Theremayalsobeothersystemsoperatingintheenvironmentofthesystemthat
maybecompetingwiththesystembeingdeveloped.Thiscompetitioncouldbe
commercialcompetitionasinonlinebankingforexample.Heretheneedforany
systemtobeevolvedrapidlycanbeofprimeimportance.
Othercompetingsystemsincludethosethatcouldinterferewiththecorrect
operationofasystemby,forexample,makingradiotransmissionsthatconfusethe
systemoroverloadsensitivereceivers.Anexampleofthisistheworrythattheuse
ofmobiletelephonesonboardaircraftinflightcouldinterferewiththeaircrafts
navigationsystems.

6.2.2.5SystemTransactions

Itisworthwhilerevisitingtheusescenariosthatweredevelopedforthesystem
fromthestakeholders,orifnoneexisttocreateasetofrelevantscenarios.These
canbeappliedtothesystemmodel(s)tomakesurethattheyarepossiblewithinthe
systembeingspecified(seeFig.6.5).Workingthroughthesesystemtransactions
providesreassurancethatelementsofsystemfunctionalityhavenotbeenlostbya
blinkeredapproachtoobjectmodellingorfunctionaldecomposition.(Notethatthis
useofthetermsystemtransactionisdifferenttotheuseofthetermwithinthe
COREmethoddescribedinChapter3.)
ThesystemtransactionsshowninFig.6.5asUserSystemTransactionsarethose
derivedfromtheusescenarios.Figure6.5alsoindicatesthattherecanbeother
transactionderivedfromthewayinwhichthesystembeingdevelopedmustinteract
withexternalsystems.
Systemtransactionsencouragesystemengineerstostandbackandtakea
holisticviewofthesystem.Itisalltooeasytoconcentrateonthedetailand
forgetthebigpicturei.e.howdothedetailedpartsworktogethertoachievethe
overallaim?

https://translate.googleusercontent.com/translate_f 131/211
2017520 RequirementsEngineering

Page143
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 123

External User
System System
Transactions Transactions

External Human
Interface Internal People
Cooperating Interaction
Functionality Functionality Functionality
Systems

Safeguard
Functionality

External
Threatening
Systems

Fig.6.5Systemtransactions

6.2.2.6ModesofOperation

Differentfunctionalitymayberequiredinsomecircumstances.Atypicalexample
forinformationbasedsystemsistheneedtobeabletoprovidetrainingforstaff
withoutcompromisingtheintegrityofthedataheldinthesystem.Otherexamples
includefallbackmodesofoperationfollowingafailureor,inmilitarysystems,
differentmodesdependingonthecurrentstateofalertness.Thesemayberelated
totheusescenariosinthestakeholderrequirements.

6.2.2.7AdditionalConstraints

Inadditiontotheconstraintsalreadymentioned,thereareadditionalaspectsthat
shouldbeconsidered.Perhapsthemostimportantarethoseconcernedwithsafetyand
certifiability.Intheseareasadditionalrequirementscanbeintroducedandthesewill
certainlyhaveastronginfluenceonthemeansadoptedforqualification.Therelevant
authoritieswillhavetobeconvincedthatasystemissafetouseortobedeployed,or,
inthecaseofanaircraft,thatitcanbegivenacertificateofairworthiness.
Afurthersetofadditionalconstraintsareintroducedbytheneedtomanufacture
thesystem.Itmaybenecessarytouseanexistingfacilityorthedesignmayhave
tobechangedinordertoreducethecostofmanufacturing.

6.2.3BankingExample

Inthisexampleofamanagementinformationsystem,theprimaryconcernwillbe
tomodeltheinformationthatmustbehandled,butitisquiteclearthatthereare
manyotherareasthatshouldbeaddressed.Severalsystemmodelsaretherefore

https://translate.googleusercontent.com/translate_f 132/211
2017520 RequirementsEngineering

Page144
124 6RequirementsEngineeringintheSolutionDomain

OtherBanks Interbank
services

Teller Cheque
Machines clearing

RetailOutlets Services
Provided
BranchOffice
CreditCard
Manage
PointofSale PCs/Terminals
Accounts
Machines
Manage
Investments Teller
Teller Manage Machines
Machines
Loans

Teller
Machines

Fig.6.6Anabstractmodelforthebankexample

likelytobeused,onefocussingontheinformation,othersfocussingontheflow
andsecurityofinformation.
Figure6.6showsamodelthatprovidesanalternativeabstractionforthebank
example.Itidentifiesthetypesoflocationswhereequipmentmightbesitedand
thusfromwheretransactionsmaybeinitiated.

6.2.3.1InternalFunctionality

Theprimaryinternalfunctionalityisconcernedwithsupportingtheservices
providedbythebanksuchascurrentaccounts,depositaccounts,loansandinvest
mentportfolios.Tosupporttheseservicesthesystemmustbeabletocollect,update
andretaininformation.Ofvitalimportanceherearethetypes(orclasses)ofinfor
mation(e.g.accounts,customers,etc.),therelationshipsthatexistbetweenthem
(e.g.howmanyaccountsisacustomerallowedtohave?)andthelongevity,fresh
nessandvolumeofeachtype.
Itisimportanttodeterminehowinformationiscollected,disseminatedand
manipulated.
Afurtherimportantaspectofabankingsystemisthenumberandlocationof
sourcesofinformationand/ortransactions.Thesewillincludebranches,automatic
tellermachinesandcreditcardpointofsalemachines.

Page145
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 125

https://translate.googleusercontent.com/translate_f 133/211
2017520 RequirementsEngineering

Fromaperformancepointofviewitisimportanttounderstandthelikelyloading
thatthesystemmustbeabletocopewith,suchasthenumberandmixoftransaction
types.Thiswillclearlyvaryfromdaytodayandfromhourtohourwithineachday.
Theremaybeconstraintsimposedbyexistinginfrastructuresuchaslandlinesor
othercommunicationmechanisms.

6.2.3.2InterfaceFunctionality

Theprimaryinterfacesforthistypeofsystemaretootherbanksforfundstransfers
anduseoftheirtellermachines.
Banksalsohaveexistingsystemsforclearingcheques,etc.thatarejointly
createdamongstseveralbanks.
Itishighlylikelythatabankingsystemwillmakeuseoftelecommunications
servicesfromexternalproviders.

6.2.3.3HumanInteractionFunctionality

Informationsystemsgenerallyhavetocopewithawidevarietyofusertypes.Fora
bankthefollowinglistcoversmanyofthem:

Generalpublicmustbeabletouseautomatictellermachinesand,increasingly,
onlinefacilitiesviathewebwithoutanypriortrainingi.e.theuserinterfaces
mustbeintuitive.
Counterstaffmustbeabletousethesystemquicklyinordertoprovideafast
andefficientservicetocustomersqueuingup.Thesecounterstaffwillrequire
trainingandthemostimportantaspectofthistypeofinterfaceisthatitshould
beslickwhenthestaffhavebeentrained.
Managersatvariouslevelssomemanagersmaynotbequiteascomputerliter
ateasthecounterstaff(although,ofcourse,somemayhavebeenpromotedafter
becomingproficientascounterclerks).Thefacilitiestobeprovidedforthe
managersmayincludesomeofthecounterstafffacilities,butwillinclude
moresummarytypesofinformationderivedfromlookingatawidersetof
informationthanasingleaccount.Thesemayincludestatementsummaries,
branchorareabusinesssummaries,etc.Notethatthesetypesofinformation
demandthatinformationisretainedoveraperiodoftimesothattrendsand
otherhistoricalinformationcanbededucedand/orpresented.
Policymakersandmarketingstaffrequirequitedifferentcapabilities,perhaps
introducingthecapabilitytostartnewbusinessproducts.
Systemmaintainersmustbeabletoupdatesystemfacilities.Ideallytheyshould
beabletodothiswhilethesystemisfullyoperational,butinpracticetheymay
takedownallorpartofthesystem(usuallyforabriefperiodinthemiddleof
thenight)inordertoguaranteeintegrityofdata.

Page146
126 6RequirementsEngineeringintheSolutionDomain

6.2.3.4SafeguardFunctionality

https://translate.googleusercontent.com/translate_f 134/211
2017520 RequirementsEngineering

Securityinbankingsystemsisofparamountimportance.Thekeyelementisthe
needtoprotecttheintegrityoftheinformationthatisattheheartofthebusiness.
Obviousmechanismsusedincludethepersonalidentificationnumbers(PINs)
oncreditordebitcardsandencryptionfortransfersbetweenbranches,teller
machines,etc.
Otherareasthatmustbeconsideredaretheneedtokeepthesystemsworkingin
thepresenceofcomputerfaults,powerfailuresorcommunicationfailures.These
categoriesoffunctionalityarerelatedtotheperceptionofrisk.Thedegreeof
protectionthatcanbeaffordedtomitigatetherisksdependscriticallyontheexpo
surethatisperceived.
Finallyandmostimportantly,itisnecessarytoconsiderthreatsfromhackers,
embezzlersorotherswithfraudulentintent.Thesoftwaremustprovideadequate
protectiontosafeguardthebankanditscustomersfromthesethreats.

6.2.3.5SystemTransactions

EachtypeofuserislikelytobeaStakeholderinthiscategoryofsystem.Therefore
itislikelythattherewillbeasetofusescenariosforeachtypeofuser.Forthebank
customerstheseincluderegularlyusedfacilitiessuchaswithdrawals,depositsand
transferswhethermadeinpersonordoneautomaticallyasdirectdebits,salary
payments,etc.Therewillalsobeothertransactionsusedlessfrequentlysuchas
negotiatingapersonalloanoramortgage.
Foreachtypeofuseritisworthwhileconsideringtheloadthatwillbeimposed,
sothattheresponsetimecanbeestimated.Ofcoursethiswillnotbeafixedtime,
butwilldependuponthecurrentloadingandthis,inturn,willdependuponthetime
ofdayanddayoftheweek.
Increasinguseofwebbasedfacilitiesmustaddafurtherdimensiontoload
prediction.

6.2.3.6ModesofOperation

Thepredominantmodeofoperationwillbethenormalmode.However,theremay
beadditionalmodestocovertraining,backupandrecoveryoperationsandsystem
evolution.

6.2.4CarExample

Thesecondexampleaddressesamorephysicaltypeofsystem,butitisinteresting
toseethatthesamecategoriesofinformationarestillpresent,althoughinan
entirelydifferentform.

Page147
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 127

Accelerator Engine Alarmsystem

Lights
GearLever Gearbox

https://translate.googleusercontent.com/translate_f 135/211
2017520 RequirementsEngineering
Transmission Body

Wheels Suspension

BrakePedal Brakes
Seats

Incarentertainment Passengers
Driver

Doors
DriverInformation

Fig.6.7Anabstractmodelforacarbasedonphysicalobjects

Thebigissueinthisexampleiswhetherthesystemmodelisaphysicalmodel
andtowhatextentitcanbecomeabstract.Itisunlikelythatanewcarisgoingto
beradicallydifferentinarchitecturefrompreviousmodelsitwillstillhavea
wheelateachcorner,anengine,agearbox,suspension,awindscreen,etc.Forthis
reason,thesystemmodelforacarmaywellmakereferencedirectlytothephysical
objectsofthearchitectureasindicatedinFig.6.7.Thearrowsonthisdiagram
indicatesomeinfluenceinthedirectionofthearrow.Thedriverpressesthebrake
pedalandthebrakepedalactivatesthebrakes.Theconnectionsbetweenthebody
andthepartsfastenedtoitareshownasdoubleendedarrowstoindicatethatthere
isadependencyinbothdirections,e.g.theengineisfastenedtothebodyandthe
bodyhasmountingstotaketheengine.
However,whereaspectsofthenewcararelikelytoberatherdifferentsuchas
inanelectronicvehiclecontrolsystemremainingmoreabstractwillpresentadvan
tagesindeterminingthebestsolution.Totheextentthatthefunctionalityofacaris
quitewellunderstood,whatisrequiredistoquantifythefunctionality.Forexample,
itisclearthatacarmustbeabletomovepeopleandtheirluggageorotheritems
fromoneplacetoanother.Thekeyquestionsthatshouldhavebeenaddressedinthe
StakeholderRequirementsare:

Howmanypeople?
Howmuchluggage?
Howcomfortablewillthecarbe?
Howfastwillthecartravel?
Howquicklywillthecaraccelerate?
Howmuchwillitcost?
Whatinformationwillbeprovidedtothedriver?

Page148
128 6RequirementsEngineeringintheSolutionDomain

Whatincarentertainmentfacilitieswillbeprovided?
Whatsafetyfeatureswillbenecessary?
Wherewillthecarbeused?

6.2.4.1InternalFunctionality

https://translate.googleusercontent.com/translate_f 136/211
2017520 RequirementsEngineering

Thekeyrequirementsthatmustbeaddressedatthefunctionallevelinclude:
TheaccelerationrateofthecarThisrequiresabalancebetweentheenginepower,
theoverallweightofthecar,thewindresistanceofthebodyandthedrag
inducedbythewheels.
TherangeofthecarThisrequiresabalancebetweenthefuelefficiencyofthe
engine,thefuelcapacity,whetheramanualorautomaticgearboxisused,and
thewayinwhichthecarisdriven.
ThecomfortlevelofthecarThiswillinfluencecostandweightofthecarplus
peopleofdifferentstaturemayperceivetheendresultdifferently.

Notethatthesekeyaspectsarenotindependent.Thisistypicalinasystemsengi
neeringsituation.Itistheseinteractionsthattendtomovethemodeltoamore
abstractlevel.Forexample,theabovefactorswillbequitedifferentdepending
uponthetypeofengineandfuelused.Fueltypesinclude:petroleum,dieseland
liquidpropanegas(LPG).Thefuelefficiencyandweightofengine,fuelandfuel
tankarequitedifferentinallthreecases.Consequentlyitisnecessaryto
determine:

Whethertomakeaselectionatallatthispoint,or
Whethertokeepalloptionsopen,or
Whethertoprovideacustomerselectableoptionforone,twoorthreeofthese
types

Thenatureofthedesignwillbesignificantlyaffectedbythedecision(s)thatare
taken.Itmaybethatmultipleoptionsareevaluated,eachmoredetailedthanthe
overallmodel.Alternativelysomeoptions,forexampleLPGfuel,couldbeelimi
natedrightatthestart.

6.2.4.2InterfaceFunctionality

Onemightexpectthatacarisgoingtobeisolatedintermsofitsneedtointerface
withothersystems.Increasinglythisisnotthecase.Onetrivialexampleisthatacar
willusuallyhavearadioreceiverandthisentailsconformingtocertainstandardsof
demodulationinordertodecodethetransmittedsignals.
Assophisticationincreasessotherearewidersetsofstandardsthatmustbe
conformedto.ForexamplecarsthathaveGPSnavigationmustunderstandhowto
receiveanddecodethesatellitesignalsonwhichthissystemdepends.Carsthatcan

Page149
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 129

providetrafficinformationtodriversmustbeabletointerfacewiththerelevant
informationproviders.Infuture,itispossibletoenvisagethatthenavigationsystem
maywellbeinfluencedbythetrafficinformationandhenceafurther(internal)
interfacewillbeintroduced.
Formoderncars,thewayinwhichtheyareservicedisanimportantconsideration.
Frequentlycarsarerequiredtoretaininformationabouteventsduringtheiropera
tionalusesothattheservicetechniciancanaccessittoaidindiagnosingproblems
ortoguidehimtocheckorchangerelevantitemsthatareeitherfaultyornearing
theendoftheirusefullife.Thisisanexampleofatestsystemthatispartlyinstalled
intheoperationalsystem(i.e.thecar)andpartlyinstalledinthegaragewherethe
https://translate.googleusercontent.com/translate_f 137/211
2017520 RequirementsEngineering

maintenanceoperationsareundertaken.

6.2.4.3HumanInteractionFunctionality

Manyaspectsoftheuserinterfaceofthecararesetbyconventionsthathave
evolvedovertheyears.Forexample,therelativepositionsofthefootpedals(accel
eratorontheright,braketotheleftand,ifpresent,clutchtotheleftofthat)are
identicalallovertheworld.
Otheraspectssuchaslefthandorrighthanddriveandpositionofindicatorsand
windscreenwipershavelocalconventionsindifferentgeographicalareas.
Ontheotherhandforentertainmentsystems,navigationsystemsandotherless
commonsystemsthereis,asyet,noagreedconventionsandthereforethedesigners
arefreetoprovideaninterfaceoftheirchoice.Aswithmostelectronicsystems,
thereisaneedtomaketheinterfaceeasytouse(orevenpossibletouse)for
anybodywhoneedstouseit.Thisisquiteachallenge,becausetheonlyexplanation
thatcanbeprovidedisauserguide.Itisnotpossibletosenddriversandpassengers
ontrainingcoursesanditisnotappropriatetomakeanyassumptionsaboutthe
educationallevelorexperienceofthosewhomayneedtouseit.

6.2.4.4SafeguardFunctionality

Theprimarysafeguardfunctionalityincarsistoensurethesafetyofthecarandits
occupants.Afurther,increasinglyimportantareaoffunctionalityistheprevention
oftheft.
Safetyfunctionalitystartswiththebrakingsystem.Itisessentialthateffective
brakingisavailabletothedriveratalltimes.Dualcircuithydraulicbrakesthat
provideredundancysuchthatbrakingisstillprovidedafteranysinglehydraulic
failureisonewayofprovidingthis.Thesystemmodelcouldincludetheimplemen
tationdirectlyalternativelythemodelcouldjustincludetheneedforbraking.Inthe
lattercase,thefactthatbrakingmuststillbeavailableintheeventofasinglehydraulic
failuremustbeaddedoutsideofthemodel.
Notethatthisdiscussionhastacitlyassumedthatbrakingwillbeeffectedusing
hydraulics!Someaspectsofdetaileddesigncanbeincludedespeciallywherethere

Page150
130 6RequirementsEngineeringintheSolutionDomain

isawellestablishedprecedent,orthedecisioncanbetakeninresponsetoabusiness
objectiveintroducedintotheinputrequirementsbythedeveloperorganisation.
OtherareasofsafetyincludeABSbrakingandtheprovisionofairbagstocushion
theimpactofacollision.Againthesecaneitherbeexplicitlyincludedinthemodel,
orthedesignercanbegivenfreedomtoinventalternativesolutions.
Thestartingpointforsecurityistheprovisionoflocksondoors.Thiscanbe
enhancedbytheprovisionofanalarmsystemandengineimmobiliser.Thelimiting
factorhereisthecostofintroducingtheextrafunctionalityandtheamountthata
customerispreparedtopayforit.However,thereareotherfactorssuchasthe
facilitiesprovidedbycompetingcarsandtheattitudeofinsurancecompanies.Both
haveastronginfluencenotonlyonthefunctionalitythatmustbeprovided,butalso
onthewayitsinclusionisjustified.

https://translate.googleusercontent.com/translate_f 138/211
2017520 RequirementsEngineering

6.2.4.5SystemTransactions

Therearemanypossibletransactionsforacar.Allarebasedonjourneysbutwith
specificobjectivesorcharacteristics,forexample:

Driver,shoppingtripintownleaveparkingbay,travel,park,securevehicle,
unlockvehicle,loadvehicle,leaveparkingbay,travel,park,unload,secure
vehicle.
Driver,motorwaytrip.
Driver,airporttrip(withluggage).
Driver,tripwithaccident.
Passengergetin,fitbelt,travel,undobelt,getout.
Garagetechnicianrepeatedlyservice,withmajor/minorintervals.
Ownerbuy,depreciate,sell/dispose.
Salesmanrepeatedlyattempttosell,endedbyselling,warrantyperiod.

Eachofthesemayaddnewrequirementssuchasluggagecapacityormaintenance
facilities.
Thereforeitisimportanttoconsiderthemallandunderstandhowtheimplied
requirementsofeachareaddressed.Ofcoursethisdoesnotmeanthatallofthem
willbesatisfied.Itmaybethatsomearerejectedbecausetheyaretooexpensiveor
arenotconsideredtoberelevantforthemarketbeingconsidered.Alternativelythe
transactionsmaycausedifferentmodelstobecreatedfordifferentmarkets.

6.2.4.6ModesofOperation

Onecouldimagineacarinwhichtheprevailingterraincouldinfluencethewayin
whichthecaroperates.Forexampleinmountainousterrain,thegearboxcould
automaticallyselectlowerratiosandtheenginemanagementsystemwouldtake
intoaccounttheamountofoxygenintheairandconsequentlyalterthemixtureof
petrolandairtotakeaccountofthis.Alternatively,thesecouldbeoptionsthat
couldbeselectedeitheratthetimeofpurchaseorwhendriving.

Page151
6.2EngineeringRequirementsfromStakeholderRequirementstoSystemRequirements 131

Afurtherimportantmodeofoperationisthemaintenancemode,inwhichthe
enginemanagementsystemisdownloadingthecollectedinformationforanalysis
bythemaintenancesystemandtechnician.
Amoreextrememodecouldbetojoinamotorwaytraincomposedofasetof
carsalltravellingatthesamespeedwithminimalspacing.Thecarswouldthenbe
controlledasagroupandlocaldrivingfacilitieswouldbedisabled.

6.2.5DerivingRequirementsfromaSystemModel

6.2.5.1CreateaDocumentStructurefortheRequirements

Asindicatedearlier,thesystemmodelmaybecomposedofmanyindependentand
potentiallyoverlappingmodels.Itispossibletostartderivingrequirementsfrom

https://translate.googleusercontent.com/translate_f 139/211
2017520 RequirementsEngineering

anyofthesemodelsashasalreadybeenalludedtointheprevioussectionscovering
thebankingandcarexamples.However,thechallengeistofindastructureinto
whichallofthesederivedrequirementscanbeplacedsuchthateveryrequirement
hasanobviousplaceinthatstructureandthatanyemptysectionsareemptyby
designratherthanbyaccident.Thestructureisreferredtoasadocumentstructure
inChapter4.
Itisrecommendedthatoneofthemodelsbechosenastheprimarysourcefor
generatingthedocumentstructure.Themodelselectedshouldbetheonewiththe
widestscope,sincethesystemrequirementsmustcoverthecompletesystemand
notonesmallarea.Inpracticethedecisionisusuallyobvious.Fordataoriented
systemssuchasthebankingexample,thedatamodelisoftenthebestfocus,since
everyfunctionisconcerned,tosomeextent,withestablishing,disseminating,
updatingorsafeguardingthedata.Formorephysicalsystemssuchasthecar
example,itisoftenbesttouseamodelderivedfromthephysicalstructureofthe
system(assumingoneexists),becausemostoftherequirementsrefertooneor
moreoftheseelements.

6.2.5.2DeriveorAllocateRequirements

Oncethestructurehasbeenagreeditispossibletocollectalltherequirementsthat
havebeenderivedandtoplacetheminthestructure.Itmaybepossibletoallocate
someinputrequirementsdirectlytothedocumentstructure.Wherethisisthecase,
itfrequentlymeansthattheinputrequirementsaretoodetailedi.e.tooclosetothe
implementation.
AlltherulesforwritinggoodrequirementsoutlinedinChapter4shouldbe
observedwhenformulatingrequirements.Rememberthatthegoldenruleistowrite
eachrequirementasasingletestablestatement.Aseachrequirementisformulated
itisnecessarytoestablishtraceabilitybacktotheoneormoreinputrequirements
thatthenewlyderivedrequirementsatisfieswhollyorpartially.

Page152
132 6RequirementsEngineeringintheSolutionDomain

Whenconsideringtestabilityitmaybeworthwhilethinkingaboutthecriteria
thatwilldeterminewhetheratestisconsideredsuccessfulornot.Theseacceptance
criteriashouldbedocumentedwitheachrequirement.Sometimesthecriteriacan
beembodiedasaperformanceclausewithinthetextoftherequirement.Analterna
tiveistowritethecriteriainaseparateattributealongsidetherequirement.
Astestabilityandperformancearebeingconsidered,itisavitaltoconsiderhow
thetesting,orotherdemonstrationofsuccessfulimplementation,willbeorganised.
Thisleadsnaturallyintotheissueofqualificationstrategyandtheidentification,in
outline,ofthesetoftrialstestsandinspectionsthatwillbenecessary.
Inthiscontextitisalsoessentialtoconsiderthetestharnessesorspecialtest
equipmentthatwillberequired.Thesemayrequireseparatedevelopmentand,in
somecases,canbecomeseparateprojectsintheirownright.Afurtherconsider
ationinthisareaisthenotionofbuiltintestsandtheprovisionofmonitorpoints.
Builtintestsareincreasinglyimportant,especiallyinsafetyrelatedarea.For
example,inthecarexample,mostelectronicsystemswillhaveabuiltintestthat
isperformedwhenthecarengineisstartedup.Monitorpointsareplaceswhere
significantinformationcanbemadeavailablethatwouldotherwisenotbevisible.
Asimpleexampleofthisisanoilpressuregaugeoncars.Aninformationexample
https://translate.googleusercontent.com/translate_f 140/211
2017520 RequirementsEngineering

forthebankingsystemcouldbeadisplayscreenshowingthecurrenttransaction
ratesacrossthewholeofthebankingnetwork.
Thefinalsetofrequirementsthatshouldbeconsideredisthesetofconstraints.
Theseaddnoadditionalfunctionality,butcontrolthewayinwhichthefunctionality
isdelivered.Atthesystemsrequirementslevel,theremaybesomeconstraintsthat
comestraightfromthestakeholderrequirements.Forexamplethespacethatasystem
canoccupymaybelimitedorthestakeholdersmayhaveinsistedthatapreexisting
systemisusedasasubsysteminthenewsystem.
Someothersourcesofconstraintare:

Designdecisionse.g.thedecisiontohavedualhydraulicallyoperatedbraking
system.
Theapplicationitselfe.g.thattheequipmentmustbeabletocopewiththevibra
tiongeneratedbythecarwhenitisinmotion.
Safetye.g.howcanthedevelopersconvincetheauthoritiesthatthecarwillnot
constituteahazardtootherroadusers?
Manufacturinge.g.canthecarbemanufacturedusingtheexistingfacilitiesata
reasonablecost?

6.2.6AgreeingtheSystemRequirementswiththeDesignTeam

Thefinalstepinthecreationofthesystemrequirementsistoagreetherequire
mentswiththeteamwhowillberesponsiblefordevelopingthedesign.Thisuses
theagreementprocessdescribedinChapter2andthereforenofurtherexplanation
isnecessary.

Page153
6.3EngineeringRequirementsfromSystemRequirementstoSubsystems 133

6.3EngineeringRequirementsfromSystemRequirements
toSubsystems

Thelogicalnextsteponfromthecreationofthesystemrequirementsistoproduce
adesignarchitecturewhosecomponentsarethemajorsubsystemsoftheproposed
systemasshowninFig.6.8.Asusualtheprocessstartsoffbyagreeingtheinput
requirementswiththecustomer.Thereviewcriteriaforsystemrequirementsmust
beusedasthebasisfortheagreementprocesstogetherwiththegeneralcriteria
presentedinChapters2and4.Therequirementsshouldbefreefromimplementa
tionbiasunlessthereisaspecificneedtoconstrainthedesign.Inthelattercasethe
requirementmustbeexplicitlystatedasaconstraint.Alltoofrequentlyconstraints
areassumedbecausethatiswhatthecustomeraskedfor.Itisalwaysgoodprac
ticetochallengeanydesignconstraint,especiallyiftheconstraintisimpliedrather
thanexplicit.Sometimesrequirementsareexpressedindesigntermsduetolaziness
andbecauseengineershaveatendencytogointotoomuchdetailtoosoon.
Theanalysisworknecessarytosupporttheagreementprocesshelpstoeducate
thedesignersaboutwhatisintendedandstartsthemthinkingaboutpossible
solutions,

https://translate.googleusercontent.com/translate_f 141/211
2017520 RequirementsEngineering
System Agree
Requirements Qualification
Requirements Strategy

ChangeRequest

System
Analyse Analysis
Architecture & Results
Model Model

Change
Request

Derive
Stakeholder
Requirements
&
Qualification
Strategy

ChangeRequest

Qualification
Subsystem Agree Qualification
Qualification
Strategy
Requirements Strategy
Requirements Strategy

Fig.6.8Instantiationofgenericprocesstocreatesubsystemrequirementsfromsystem
requirements

Page154
134 6RequirementsEngineeringintheSolutionDomain

6.3.1CreatingaSystemArchitectureModel

Anarchitecturemodelidentifiesthecomponentsofthesystemandthewayinwhich
theyinteract.Thedesignermustunderstandhowthecomponentsworktogetherto
developtheemergentpropertiesofthesystem,i.e.toindicatehowtheysatisfythe
inputrequirements.Thedesignersmustalsobeabletopredictwhetherthereareany
emergentpropertiesthataredefinitelynotrequired,suchascatastrophicfailuresor
othersafetyorenvironmentalhazards.Theremay,however,beemergentproperties
thatagivendesigngeneratesthat,althoughnotactuallyrequestedbythecustomer,
maybeperfectlyacceptable.Theseadditionalcapabilitiesmustbediscussedwith
thecustomer.Theymaygiverisetochangesintheinputrequirementstorequest
them,orthecustomermayrequestthattheyareinhibited.Finallythedesignersmay
findthatitisimpossibletosatisfytherequirementsatalloratreasonablecost.
Itisonlywhenadesignarchitecturehasbeengeneratedandexploredthatthese
possibilitiescometolight.Onceadesignexistsitispossibletopredictthecostand
developmenttimeforasystemwithmuchgreateraccuracythanearlier.Thusitis
possibletoenteraroundofnegotiationwiththecustomertohonetheinputrequire
mentsbythecustomermakingconcessionswhereproblemsorcostdictatetheneed.
Inmanycircumstancesitisworthwhileconsideringtwoormorealternative
designsandtheninvestigatingtherelativemeritsofeach.Againthiscanleadto
furthernegotiation(tradeoff)withthecustomertodeterminethemostappropriate
optionsintermsofcostversusbenefit.

https://translate.googleusercontent.com/translate_f 142/211
2017520 RequirementsEngineering

Whenanagreedarchitecturehasbeenestablished,eachcomponentmustbe
describedintermsofitsinternalfunctionsanditsinteractionobligationswithother
componentsandwithexternalsystems.

6.3.2DerivingRequirementsfromanArchitectural
DesignModel

Fromthedescriptionsofthecomponents,requirementscanbederived.Therequire
mentsmustaddressthefunctionalitythatthecomponentmustprovide,theinterfaces
thatitmustuseorprovideandanyconstraintstowhichthecomponentmustconform.
Theseconstraintsmaycomedirectlyfromtheoverallsystemconstraints(e.g.aparticular
electronictechnologymustbeusedforallcomponents),ortheymaybederivedfrom
them(e.g.theoverallweightlimitforthesystemhasbeendividedamongstthe
components).Thecomponent(i.e.subsystem)requirementsareessentiallythesystem
requirementsforthatcomponentwhenitisviewedasasysteminitsownright.
Aseachrequirementisderived,soitshouldbetracedbacktooneormoreofthe
inputrequirementsthatitpartiallyorfullysatisfies.
Thestrategyfortestingeachcomponentmustalsobedetermined.Thiswillnotbe
thefirstoccasionthattestabilityhasbeenconsidered.Testabilityisoneofthemost
importantaspectsofthedesignandmustbeconsideredasthedesignisbeingcreated.

Page155
6.4OtherTransformationsUsingaDesignArchitecture 135

6.4OtherTransformationsUsingaDesignArchitecture

Asthedevelopmentproceedsfromoneleveldowntolowerlevelssoeachlevel
introducesitsownarchitecturaldesignmodel(seeFig.6.1).Ateachlevelthe
processfollowedisasdescribedintheprevioussection.Thusthenextlevel
downfromthecreationofsubsystemsistocreatethecomponentsofeachsub
systemandsoon.
Thereisonespecialcaseinwhichanarchitecturalmodelisusedthatisan
exceptiontothisrule.ThisisindicatedinFig.6.9,whichshowsthatadesign
architectureandsubsequentlysubsystemrequirementsarecreateddirectlyfrom
thestakeholderrequirements.Thisisonlypossiblewherethesystemarchitecture
modelisknowninadvance.Examplesofthisincludesomeofthephysicalsystems
alreadyconsidered,e.g.carsandaeroplanes.Anotherimportantgroupofapplica
tionsarethoseinthetelecommunicationsindustry.Heretheoveralldesignarchi
tectureismandatedinthetelecommunicationsstandardsthatgovernthe
applicationdomains.Itisamootpointwhethertheinputrequirementstosucha
processwhichareoftentakendirectlyfromthestandardarereallystakeholder
requirementsorare,infact,systemrequirements.Whateverinterpretationis
placedupontheserequirements,duringthetransformationitisusualtomakequite

Stakeholder Agree Qualification

Requirements Requirements Strategy

ChangeRequest

https://translate.googleusercontent.com/translate_f 143/211
2017520 RequirementsEngineering

System
Analysis
Architecture Analyse
& Results
Model
Model

Change
Request

Derive
Stakeholder
Requirements
&
Qualification
Strategy

ChangeRequest

Qualification
Agree Qualification
Subsystem Qualification
Strategy
Requirements Strategy
Requirements Strategy

Fig.6.9Transformingstakeholderrequirementsdirectlytosubsystems

Page156
136 6RequirementsEngineeringintheSolutionDomain

directallocationsfromtheinputrequirementstothesubsystemrequirements.
Againthissuggeststhatsuchstandardsareprovidingrequirementsatquitea
detailedlevel.

6.5Summary

Inthischapter,thenatureofthesolutiondomainhasbeendescribed,thewayin
whichrequirementengineeringisappliedtotransformstakeholderrequirementsto
systemrequirementsandthencetosubsystemrequirementsandcomponents
requirementshasbeenexplained.
Twoquitedifferentexampleshavebeenusedtoexplorethetypesoffunctionality
thatmustbeusedtodefinerequirementsinthesolutiondomain.Ithasbeenshown
that,inadditiontotherequiredinternalfunctionality,additionalfunctionalitymust
beaddedtocopewithexternalcooperatingsystems,humaninteractions,tosafe
guardthesystemfromexternalthreateningsystemsmakethesystemsafetouse.
Thelatteraspectmayalsoinvolveadditionalconstraintsonthemeansofqualification
inordertoconvincetherelevantauthorities.

https://translate.googleusercontent.com/translate_f 144/211
2017520 RequirementsEngineering

Page157

Chapter7
AdvancedTraceability

ForstartersIllhaveWho?,What?,When?,Where?,
andthenWither?,Whence?andWherefore?tofollow,
andonebigsideorderofWhy?

ZaphodBeeblebroxinTheHitchHikersGuidetotheGalaxy
DouglasNoelAdams,writer,19522001AD

7.1Introduction

Sooften,therealrationaleforaparticulardesign,andthedeeperunderstandingof
howthecomponentsofasystemworktogethertoachieveanendresult,remainin
themindsoftheengineers.Monthsoryearslater,whentheoriginaldesignershave
longsincemovedon,ortheirmemoryhasdimmed,thelossofthatunderstanding
mayseriouslyimpedetheabilitytoevolve,maintainorreusethesystem.
Thischapterfirstpresentsatechniqueformaintainingthisgreaterunderstanding
ofasystem,throughcapturingtherationaleassociatedwiththerelationships
betweenproblem,solutionanddesign.Christenedrichtraceability,theapproach
https://translate.googleusercontent.com/translate_f 145/211
2017520 RequirementsEngineering

buildsonthebasicconceptsofelementarytraceabilitypresentedinChapter1and
appliedinsubsequentchapters.
WhilerichtraceabilitymayrepresentonebigsideorderofWhy?,the
Wither?,Whence?andWherefore?oftraceabilityareperhapsaddressed
throughanothersubjectofthischapter:metricsinrelationtotraceability.

7.2ElementaryTraceability

Therearemanywaysofrepresentingmanytomanyrelationships.Oneconsultant
visitedadefencecontractorjustpriortoacustomertraceabilityaudittofindtheoffice
alllaidoutready.Alongthelengthofthefloorononesidewasspreadoutthe
requirementsdocument,andontheothersidethecodelisting.Traceabilitywasshown

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_7, 137
SpringerVerlagLondonLimited2011

Page158
138 7AdvancedTraceability

bypiecesofstringtapedbetweenthedocuments.Thisapproachwasspaceconsuming,
timeconsuming,nonmaintainable,andnontransportable,butitdidsomeofthejob.
Manyengineerswillhaveseentraceabilityrepresentedinmatrixformasan
appendixtorelevantdocuments.Thetwodimensionsidentify,forinstance,user
requirementsononeaxisandsystemrequirementsontheother,withmarksinthose
cellswherearelationshipexists.
Thereareanumberofdisadvantagestothisapproach:

Wheretherearealargenumberofstatementstoindexonbothaxes,thepaper
orscreenistoosmalltoshowenoughinformation.
Traceabilityrelationshipstendtobesparse,resultinginmostofthecellsinthe
matrixbeingempty,whichisawasteofspace.
Itisveryhardworkingyourwaythroughmultiplelayersoftraceabilitypre
sentedinanumberofseparatematrices.
Informationabouttraceabilityisseparatedfromthedetailsoftherequirements
themselves.

Anothermethodistousehyperlinkeddocuments,wherestatementscanbehigh
lighted,linkedtootherstatements,andtraversedatwillineitherdirectionifyou
areclever.Nowthetraceabilityinformationisvisibleinthetextofthestatement,
buttherearestillproblems:

Tocarryoutanalysisyoumayhavephysicallytotraversethelinkbeforetextat
theotherendisvisible.
Itishardtospotwhentheitemattheotherendofahyperlinkhasbeendeleted,
leavingadanglinglink,makingtraceabilitydifficulttomaintain.

Whateverapproachyouuse,unlesssupportedbyatool,traceabilitywillbevery
hardtomanage.
Thesimplestformoftraceabilityisachievedbylinkingstatementstogether
usingsomekindofdatabasesupport.Itishelpfuliflinkinginformationisheld
separatelyfromthedocuments.Itisessentialthatstatementsareindependentlyand
uniquelyidentifiable.
Withanalysisinmind,theessentialcapabilitiesforimplementationoftrace
abilityare:

https://translate.googleusercontent.com/translate_f 146/211
2017520 RequirementsEngineering

Abilitytocreatelinksbetweenstatements,thusformingpermittedrelationships.
Abilitytodeletelinksbetweenstatementsinacontrolledmanner.
Abilitytoviewsimultaneouslythetext(orotherattributes)ofstatementsatboth
endsofaselectedrelationship.
Abilitytocarryoutcoverageanalysistoshowthosestatementscoveredornot
coveredbyaselectedrelationship.
Abilitytocarryoutsinglelevelandmultilevelimpactanalysistoshowsetsof
impactedstatements.
Abilitytocarryoutsinglelevelandmultilevelderivationanalysistoshowsets
oforiginatingstatements.
Abilitytocarryoutupwardsanddownwardscoverageanalysistoshowsetsof
statementscoveredandnotcoveredbyselectedrelationships.

Page159
7.3SatisfactionArguments 139

SR15:Thevehicleshalltransmit

powertoallwheels.

UR21:Thedrivershallbeable
SR32:Thevehicleshallhaveground
todeploythevehicleover
clearanceofnotlessthan25cms.
terraintype4A.

SR53:Thevehicleshallweighnot
morethan1.5tonnes.

Fig.7.1Elementarytraceabilityexample:militaryvehicle

SR37:Thecookershallhavea
3kilowatt,15cmdiameter
electricplate.

UR3:Theusershallbeable
SR31:Thecookershallhavea
toboil10litresofwaterin4
10cmdiametergasring.
minutesinaflatbottomedpan.

SR41:Thecookershallbe
suppliedwithgaspressuredat
notlessthan25psi.

Fig.7.2Elementarytraceabilityexample:cooker

Figure7.1showsanexampleofelementarytraceability.Auserrequirementtraces
downtothreerespondingsystemrequirements.Inthispresentation,thetextofthe
userrequirementisvisibletogetherwiththesetofsystemrequirementsthat
respondtoit.Havingthisinformationtogetherallowsthetraceabilitytobereviewed
easily.Figure7.2showsasecondexample.

https://translate.googleusercontent.com/translate_f 147/211
2017520 RequirementsEngineering

7.3SatisfactionArguments

ImplementationofelementarytraceabilityasdiscussedinSection1.2representsa
majorstepforwardformanyorganisations.Indeed,changingthecultureofan
organisationtoembraceeventhissimpleapproachmaybeabigenoughleapin
itself.However,thereis,asalways,morethatcanbedone.
TheintentionintheexampleofFig.7.1isthatthethreesystemrequirementsare
somehowsufficienttosatisfytheuserrequirement.Itisdifficult,however,fora

Page160
140 7AdvancedTraceability

nonexperttoassessthevalidityofthisassertion.Thisisbecausethereasoninghas
notbeenpresented.
Whatisbetteristopresentasatisfactionargumentforeachuserrequirement.
WiththeelementarytraceabilityofFig.7.1,theonlyinformationprovidedisthat
thethreesystemrequirementsplaysomekindofroleinthesatisfactionargument,
butthereisnothingtoindicateexactlywhattheargumentis.
Richtraceabilityisawayofcapturingthesatisfactionargument.Thisappearsas
anotherstatementsittingbetweentheuserrequirementandthecorresponding
systemrequirements,asillustratedinFig.7.3.
Notonlyisthesatisfactionargumentexpressedtextually,butanindicationis
givenaboutthewayinwhichthesystemrequirementscombineintheargument
usingapropositionaloperator:

Byconjunction(&)indicatingthatthecontributionof allthesystemrequire
mentsisnecessaryfortheuserrequirementsatisfactionargumenttohold.
Bydisjunction(or)indicatingthatthecontributionof anyoneofthesystem
requirementsisnecessaryfortheuserrequirementsatisfactionargumenttohold.

AnexampleofdisjunctionisgiveninFig.7.4,wheresatisfactionisachieved
throughprovisionofeitheranelectricringoragasringorboth.Notethetwolevel
propositionalstructureoftheargument.
Muchmoreinformationisnowprovidedabouthowtheuserrequirementsare
beingsatisfied.Evenonewhoisnotadomainexpertmayfeelcapableofassessing
importantaspectsoftheargument.Thetexthelpsinassessingthelogicofthe
argumentforvalidityandcompleteness.Theoperatormakesthestructureofthe
argumentmoreprecise.
Noticeinparticular,itisnotatallclearinFig.7.2thatthesetofsystem
requirementsrepresentalternativesolutions,whereasinFig.7.4thefactis

UR21:Thedrivershallbeable
todeploythevehicleover
terraintype4A.

SR15:Thevehicleshalltransmit
powertoallwheels.

Terraintype4Aspecifies
softwetmud,requiring
SR32:Thevehicleshallhaveground
constraintsonweight, &
clearanceofnotlessthan25cms.
clearanceandpower

https://translate.googleusercontent.com/translate_f 148/211
2017520 RequirementsEngineering
delivery.

SR53:Thevehicleshallweighnot
morethan1.5tonnes.

Fig.7.3Richtraceabilityexample:vehicle

Page161
7.3SatisfactionArguments 141

UR3:Theusershallbeable
toboil10litresofwaterin4
minutesinaflatbottomedpan.
SR37:Thecookershallhavea
3kilowatt,15cmdiameter
electricplate.

Twokindsofflatplates
canachievethis or SR31:Thecookershallhavea
performance: 10cmdiametergasring.

Alargegasring,
withmedium &
pressuregassupply.

SR41:Thecookershallbe
suppliedwithgaspressuredat
notlessthan25psi.

Fig.7.4Richtraceabilityexample:cooker

madeabsolutelyspecific.Ifanelectricringcannotbesupplied,therequirement
canstillbesatisfiedthroughagasring.
TheauthorsfirstcameacrosstheconceptofrichtraceabilityintheNetworkRail
(thenRailtrack)WestCoastRouteModernisationprojectintheUK,whereateam
fromPraxisCriticalSystemshaddevisedarequirementsmanagementprocessand
datamodelthatuseddesignjustifications.Thesameconceptcanbeidentifiedin
avarietyofsimilarapproachesinwhichsatisfactionargumentsarecalledvariously
requirementselaboration,traceabilityrationale,strategy,etc.
Satisfactionargumentsmaydependfortheirvalidityonthingsotherthanlower
levelrequirements.Figure7.5showsanexampleusingdomainknowledgeto
supporttheargument.Domainknowledgeisafactorassumptionaboutthereal
world,andnotsomethingthatconstrainsthesolutioninandofitself.Inthiscase,
thestatementofdomainknowledgeisanessentialpartofthesatisfactionargument,
showninaslantedbox.
Capturingsuchassumptionsisimportant,notleastbecausetheworld,andthe
assumptionsyoucanmakeaboutit,hasahabitofchanging.Oncecaptured,deriva
tionanalysiscanbeusedtounderstandtheimpactofchangingassumptionsonthe
abilityofthesystemtomeetitsrequirements.
AnexampleofthiscomesfromtheNewYorkunderground.Aseriesofacci
dentsinthe1970swereduetoafalseassumptionconcerningthestoppingdistance

https://translate.googleusercontent.com/translate_f 149/211
2017520 RequirementsEngineering

oftrains.Initiallyvalid,theassumptionwasinvalidatedastrainsgotheavierover
theyears,andthestoppingdistanceincreased.Whilsttheperformanceofthe
signallingsoftwarewasoriginallycorrect,anditdidnotevolve,thechanging
assumptionsmeantthatitceasedtomeetrequirementsfromacertaintime.

Page162
142 7AdvancedTraceability

SR35:Thevehicleshall
UR21:Thedrivershallbeable have3axles.
todeploythevehicleover
terraintype4A.

SR15:Thevehicleshalltransmit
Awheeledvehicle powertoallwheels.
requiringconstraints
onweight,clearance
&
andpowerdelivery. SR32:Thevehicleshallhave
groundclearanceofnotless
than25cms.

SR53:Thevehicleshallweighnot
morethan1.5tonnes.

DK5:Terraintype4Acansupport
0.5tonnesperaxle.

Fig.7.5Theroleofdomainknowledge

BR14:Thejourneytime
betweenEustonand
Glasgowshallbenotmore
than250minutes.

VT15:VisionmodelnoV54a.

Thisrequirementissatisfiedby:
ensuringsufficientrunning
&
VISIONtimetabling &
ineachlinesegment, modelshowsfeasability
SR32:Linespeed
ensuringminimumnonrunning ofjourneytimesfor
requirements
time givenlinespeedsand
ensuringfeasabilityofoverall dwelltimes.
timetable.

SR32:Stationsdwelltime
requirements

Fig.7.6Theroleofmodelling

Theabilitytodocumentandtracetheroleofsuchassumptionsispossible
througheffectivetraceability.
Anotherexampleofnonrequirementsinformationplayingaroleinsatisfaction
argumentscomesfrommodellingactivities.Satisfactionargumentsareoften
derivedfromcomplexmodellingactivities,thecompletedetailsofwhicharetoo
detailedtobecapturedinrichtraceability.
Figure7.6showsanexampleabstractedfromarailwayprojectinwhicha
https://translate.googleusercontent.com/translate_f 150/211
2017520 RequirementsEngineering

satisfactionargumentdependsontheresultsofacomplextimetablemodelling

Page163
7.4RequirementsAllocation 143

Stakeholderrequirements Systemrequirements Designrequirements

SR37
SHR3
Xxx xx xxx xx xx x,
xx xx x xx xx xxx xx
& DR73
Xx x x x x x x x x x x x x x
or xx xx xx xxx xx xx xx x.

xx x x x x x x x x x x x xx :

SR31
DR132

Xx x x x x x x x x xx x ,
x x x x x x x x x x x x x x
& Xx xx xx x xx x
x xx xxx xx xx xx xx
or
x x x x x x x x x x x x x x x x .
x xx xxx xx xx x.
DR24

SR41
DR131

Xx xx x xx xx x
xx xx xx xx xx x xx x
& DR42
xx xx xxx xx xx .

DR14

Fig.7.7Multiplelayersofrichtraceability

activityusingspecialisedsoftware.Asetofassumptionsandsubsystemrequire
mentsarederivedfromthemodellingtool,andthesearedocumentedintherich
traceabilitystructure.Themodellingreferenceisshowninaboxwithrounded
ends.
Inthiscase,themodellingactivitiesthatneedrevisitingbecomeapparentunder
impactanalysis.
Richtraceabilitycanofcoursebeusedthroughmultiplelayersofrequirements
orobjectives.Figure7.7depictsthreelayersandthetraceabilitybetweenthem.

7.4RequirementsAllocation

Thesatisfactionargumentisoftentrivial,amountingperhapsonlytotheallocation
ofanidenticalrequirementtooneormoresubsystemsorcomponents.Thisis
sometimesreferredtoasrequirementsallocationorflowdown.
Wherethispureflowdownofrequirementsisused,thechangeprocessmaybe
simplified.Changestohighlevelrequirementsmaybeautomaticallyfloweddown
tolowerlevels.
Asimpleextensionofrichtraceabilityallowssuchcasestobecaptured.Anew
valuerepresentingidentityisaddedtotheandandoroperatorsusedtoanno
tatethearguments.Figure7.8showsanexampleofthis.Thesymbol=isusedto
indicateidentity.

https://translate.googleusercontent.com/translate_f 151/211
2017520 RequirementsEngineering

Page164
144 7AdvancedTraceability

Requirementfloweddownto2subsystems

SHR3 SS173
SR37

=
Xx xx xx xxx xx xx ,

Xxx x x x x x x x x x x x x
x xx xxx xx xx x xx x
x xx xx xx x xx xx xx xx .
SS284
or
x x x x x x x x x x x x x x x :

SR31
SS1132
Xx x x x x x x x x xx x ,
x x x x x x x x x x x x x x

or
Xxx xxx xx xx

&
x x x x x x x x x x x x x x x x .
x xx xx xx xx xxx xx
x xx xx x xx xx x.
SS124

SR41
SS2131

Xx xx xx xx xx
SS142
x xx xx xx x xx xx xx
x xx xxx xx xx x.
&
SS214

Fig.7.8Flowdownofrequirementsusingidentity

7.5ReviewingTraceability

Everytimearequirementisreviewed,itshouldbereviewedalongwithitssatisfaction
argument.Basedonrichtraceability,areviewprocesscanbeestablishedthat
focusesononerequirementatatime,togetherwithitssatisfactionargument,and
therequirementsthatflowfromit.
Figure7.9showsascreenshotofatoolusedinadefenceprojecttoreview
requirementsandsatisfactionarguments.Onthescreenisjusttherightparcelof
informationtoassessarequirementandhowitissatisfied.
Thedarktrianglesarefornavigatingdownwardsthroughthelayersoftraceability,
oracrosstothenextrequirementatthesamelevel.

7.6TheLanguageofSatisfactionArguments

Aswithrequirements,ithelpstohaveauniformapproachtoexpressingsatisfaction
arguments.ThekeyguidelineistostartthesentencewithThisrequirementwill
besatisfiedby,whichfocusesthemindonthekindofstatementbeingmade.
Whilerequirementsshouldbestrictlyatomic(seeChapter4),satisfactionargu
mentsneednotbesolimited.However,ifstatementsbecometoocomplex,astruc
turedargumentshouldbeusedinstead.

https://translate.googleusercontent.com/translate_f 152/211
2017520 RequirementsEngineering

Page165
7.7RichTraceabilityAnalysis 145

Fig.7.9Reviewingtoolforsatisfactionarguments

Repeatedpatternsofsatisfactionargumentsmaybeidentifiable,inwhichcasea
paletteofboilerplatestatementscouldbeusedtogoodeffect.

7.7RichTraceabilityAnalysis

Thepresenceofsatisfactionargumentsinrichtraceabilitydoesnotprecludethe
abilitytocarryoutelementaryimpactandderivationanalysisasdescribedin
Chapter1.Indeed,theargumentsaddimportantcluesastothenatureoftheimpact
bycapturingunderstanding,orraisondtre.
Thepropositionalstructure(andsandors)ofthesatisfactionargumentsoffers
opportunitiesforotherkindsofanalysis.Forinstance,thestructurescanbeanalysedto
showthenumberofdegreesoffreedomthatexistformeetingaparticularobjective.
TaketheexampleofFig.7.4.ThepropositionstructureforUR3canbecaptured
intheexpressionSR37or(SR31andSR41).Usingthelawsofpropositionallogic,
thiscanbeconvertedtoaspecialdisjunctiveforminwhicheachdisjunctshowsone
wayofmeetingtherequirement:

https://translate.googleusercontent.com/translate_f 153/211
2017520 RequirementsEngineering

Page166
146 7AdvancedTraceability

[SR37and(notSR31)and(notSR41)]
or[SR37andSR31and(notSR41)]
or[SR37and(notSR31)andSR41]
or[SR37andSR31andSR41]
or[(notSR37)andSR31andSR41]

Insimplecases,thisanalysismaynotseemthatuseful,butimaginemorecomplex
scenarioswheretherearehundredsofrequirementsinseverallayerswithcomplex
interactions.Onemaywanttoknowwhetherthereisanywayofmeetingtherequire
ments,andifthereisnoway,thenwhatthecauseiswheretheconflictexists.

7.8RichTraceabilityforQualification

Richtraceabilitycanbeusedinanytraceabilityrelationship.Thediscussionsofar
hasbeenbasedonthesatisfactionrelationship,butitisalsoapplicabletoqualifica
tion.Inthiscase,thesatisfactionargumentmaybereferredtoasthequalification
argumentorqualificationrationale.Allthesameadvantagesofusingsatisfaction
argumentsapplytothequalificationstrategy.

7.9ImplementingRichTraceability

Wedescribeheretwoapproachestotheimplementationofrichtraceability:single
layerandmultilayer.

7.9.1SingleLayerRichTraceability

Inthisapproach,illustratedinFig.7.10,eachhighlevelrequirementhasasingle
statementofsatisfactionorstrategyasanattribute,andmultiplelowlevelrequirements

Highlevel
Requirements
satisfaction
requirmt
argument
requirmt

satisfies(n:n)
requirmt
Lowlevel
requirements

Fig.7.10Singlelayerrichtraceability

Page167
7.10DesignDocuments 147

https://translate.googleusercontent.com/translate_f 154/211
2017520 RequirementsEngineering

requirmt
Satisfaction
Highlevel
Arguments
requirements sub
argument
main
sehsilbatse argument
contributesto
sub
argument

requirmt

requirmt
Lowlevel
requirements

Fig.7.11Multilayerrichtraceability

mayflowfromitinamanytomanysatisfactionrelationship.Anotherattribute(not
showninthediagram)isusedtotypetheargumentaseitheraconjunctionora
disjunction.

7.9.2MultiLayerRichTraceability

Heresatisfactionargumentscanbestructuredintomultiplelayers:amainargument
attached(asanattributeorlinkedinanestablishesrelationship)totherequire
menttobeestablished,andahierarchyofsubargumentshangoffofthemain
argument.Lowlevelrequirementsarelinkedtothesubargumentsinacontributes
torelationship.ThisisshowninFig.7.11.
Someimplementationslimitthedepthoftheargumenthierarchytotwo,usinga
mainargumentthesatisfactionargumentandasinglelayerofsubarguments
thatexplainstheroleplayedbythecontributingrequirements.

7.10DesignDocuments

Astutereaderswillhavenoticedthatthelayerofrationaleintroducedbysatisfac
tionargumentsisverylikethefillinginthesystemsengineeringsandwichpre
sentedinFig.1.9.Indeed,thesatisfactionargumentscanbegatheredintoa
document,whichmaybebestcharacterisedasananalysisanddesigndocument.
Itisthisdesigndocumentwhichisthefocalpointoftheintegrationbetween
requirementsandmodelling.Theroleofthedesigndocumentistosummarize
textuallyandvisuallythosepartsofthemodellingactivitythatexplainwhyone
layerofrequirementsissufficientandnecessarytosatisfythelayerabove.The
documentreferencesdatafromthemodellingprocessasevidencefortherationale.
Traceabilitybetweenlayersofrequirementpassesthroughthedesigndocument.

Page168
148 7AdvancedTraceability

Statement
Requirementslayer ofneed
https://translate.googleusercontent.com/translate_f 155/211
2017520 RequirementsEngineering

Analysis Modeling e.gGoal/Usage

Modelinglayer modeling
ofNeed data

Stakeholder
Requirementslayer requirements

Modelinglayer Functional Modeling e.g.Functional

data modeling
Design

System
Requirementslayer requirements

Modelinglayer Architectural Modeling e.g.Performance

Design data modeling

SubSystem
Requirementslayer requirements

Fig.7.12Analysisanddesigndocuments

Inthisway,theresultsofmodellingappearinthetraceabilitychain,andcanengage
inimpactanalysis.
Figure7.12portraysthisapproach.Layersofrequirementsarefilledbydesign
documentsappropriatetothelevelofabstraction.Themodellingactivitiesateach
levelgiverisetodatathatisreferencedbythedesigndocument.Thethinarrows
representtheflowofinformationthethickarrowsrepresenttraceability.
Wenowshowanexampleofthekindofinformationthatmaybecollectedinto
adesigndocument.AsequenceoffiguresshowsextractsfromanAnalysisof
NeeddocumentthatmodelsaBaggageCheckinSystemattheproblemdomain
level.ThemodelsitsbetweentheStatementofNeedandtheStakeholder
Requirementsdocuments,andusesUML2toportraytheanalysisinvisualform.
Thefollowingkindsofinformationaretypical:

ConceptsAUMLclassdiagramisusedtoidentifythedomainconceptsand
therelationshipsbetweenthem.EachconceptisaUMLclass,andeachrelation
shipisaUMLassociation.Bothappearasentriesinthedesigndocumentwhere
atextualdescriptionoftheconceptorrelationshipissupplied.Figure7.13
showsanexamplefortheBaggageCheckinSystem.Thesymbolstotheleftof
eachparagraphindicatethatthatpartofthedocumentcorrespondstoaUML
entityinthemodel.
StakeholdersThissectionliststhestakeholdersthathavebeenidentifiedduring
analysis,andincludesaclassdiagramshowingrelationships.Intheexample
showninFig.7.14,therearetwostakeholderswithasinglerelationship.
StaticContextThepurposeofthissectionistoidentifythecontextinwhich
theBaggageCheckinSystemexists.TheBaggageCheckinSystemitselfis

Page169
7.10DesignDocuments 149

1Concepts
Thissectionwillcontaintextualdescriptionsofthefollowingmodellingentities.Eachone
willcorrespondtoa"Class"intheUMLmodel.

1.1Baggageltem
Theterm'BaggageItem'referstoasingleitemofluggage.
Eachpassengermayhave0ormoreitemsofluggage.

https://translate.googleusercontent.com/translate_f 156/211
2017520 RequirementsEngineering

1.2TrackableBaggageltem
Theterm'TrackableBaggage'referstoaBaggageItemthatcanbeidentifiedwitha
particularpassenger.

1.3BaggageReceipt
Theterm'BaggageReceipt'referstoameansofallowingapassengertoassertownershipof
anitemofbaggage.
1.3.1identifies
ABaggageReceiptservestouniquelyidentifyaBaggageItem.

1.4ConceptRelationships

'BaggageItem'

'BaggageReceipt' 'TrackableBaggageItem'
identifies
1..1 1..1

Fig.7.13Conceptssectionofdesigndocument

3Stakeholders
Thissectionwillcontaintextualdescriptionsofeachkindof
stakeholder.Eachoneshouldcorrespondtoan"Actor"intheUML
model.

3.1Passenger
Apassengerisanypersonwishingtotravelonaflight.

3.2Family
Afamilyisagroupofpassengerstravellingtogether.Theymayshare
luggage,andwishtosittogether.

3.3StakeholderRelationships
Optionalclassdiagramshowingsubtyperelationshipsbetween
stakeholders,ifany.

<<actor>> <<actor>>
Family Passenger
'belongsto'
0..n

Fig.7.14Stakeholderssectionofdesigndocument

Page170
150 7AdvancedTraceability

3Context
Startwithaclassdiagramthatshowsthesignificantcontextofthesystemtobe
developed.
3.1BaggageCheckinSystem
Thissectionidentifiesandintroducesthesystemtobedeveloped.

3.2BaggageHandlingSystem
Thisistheenclosingsystem.(Conceptofsystemofsystems.)
Itmustbeaclass,sothatanarchitexturediagramcanbedrawnforit,butwe

https://translate.googleusercontent.com/translate_f 157/211
2017520 RequirementsEngineering
stereotypeitasanactor.

3.3BaggageTransportSystem
Thisisapeersystem,sowemakeitaclass,butstereotypeitasanactor.

3.4PassengerTransportSystem
Thisisapeersystem,sowemakeitaclass,butstereotypeitasanactor.

3.5BaggageReclaimSystem
Thisisapeersystem,sowemakeitaclass,butstereotypeitasanactor .

3.6BaggageHoldingSystem
Thisisapeersystem,sowemakeitaclass,butstereotypeitasanactor.

3.7Relationshipswithsurroundingsystems
<<actor>> <<actor>>
'BaggageCheckinSystem' 'BaggageHandlingSystem'

Sen d sBag g ag eList Send sBaggag e

<<acto r>>
'BaggageTransportSystem'

<<acto r>>

'BaggageReclaimSystem'

<<acto r>>
'BaggageHoldingSystem'

Fig.7.15Contextsectionofdesigndocument

modeledasaclassinaclassdiagram,alongwithclassesrepresentingallthe
surroundingandenclosingsystems.Relationshipsbetweenthesesystemsare
modeledusingaggregationsandassociations.Again,eachclassandassociation
appearsinthedesigndocumentwithatextualdescription(Fig.7.15).
UsageThissectiondescribesthetoplevelusecasesforthesystem.Thisis
presentedasaseriesofusecasediagrams,eachwithoneormoresequence
diagrams.Figure7.16showsjustoneoftheusecasesanditssequencediagram
showingthenormalcourseofactionforthescenario.Thesequencediagramshows
theinteractionsbetweenthestakeholders(someofwhichareexternalsubsystems)
andthesysteminquestion(theBaggageCheckinSystem),andthushelpsto
definethescope,processcontextandexternalinterfaces.

Page171
7.10DesignDocuments 151

https://translate.googleusercontent.com/translate_f 158/211
2017520 RequirementsEngineering

Fig.7.16Usagesectionofdesigndocument

DesignrationaleThissectionsummarizestheanalysisandmodelingactivity
bygivinganexplanationofhowtheneedisgoingtobesatisfiedbythecapabili
tiesofthesystem.Onewayofpresentingthisinformationisintheformofa
satisfactionargumentforeachstatementintheinputrequirementsdocument.
Itisherethatthetraceabilitytohighlevelrequirementsandfromlowlevel
requirementsisestablished.Thesatisfactionargument,ineffect,explainshow
thestatementofneedhasbeendecomposedintostatementsofcapability.This
isillustratedinFig.7.17.

Page172
152 7AdvancedTraceability

1DesignRationale
1.1Reducecheckintime
[SoN9]Passengers Thisobjectivewillbemetbyensuringthat [PA233]UMLSequencediagram Travel
willbeableto theBaggageCheckinSystemhassufficient WithBaggage:NormalCourseofEvents
checkinbaggageon performanceatthepointofcheckin.A
averagetwiceas separationwillbemadebetweenthecheck. [SHR3]Attheportofdeparture,the
fastasthecurrent inofthepassengerandthecheckinofthat passengershallbeabletocheckinan
averageforgiven passenger'sbaggage.Thetargetcheckinfor itemofbaggagewithin25secondsof
numberofitems. eachitemofbaggageis25seconds.This placingitontheconveyor.
Thecurrent strategyisreflectedinthefollowingways:
averageis80secs passengercheckinandbaggageitem
peritem. checkinareseparateeventsinthemodeled
scenarios
aperformancerequirementisimposedon
thebaggagecheckincapability.
1.2lncreasesecuritystandards BaggageItem
Thisobjectivewillbemetbyissuingunique [PA3]Theterm'BaggageItem'refersto

https://translate.googleusercontent.com/translate_f 159/211
2017520 RequirementsEngineering
[SoN8]Passengers receiptstopassengersforbaggagecheckin asingleitemofluggage.
willonlybeallowed
tocollectbaggage ondeparture,allowingtrackablebaggageto TrackableBaggageItem
thatthey bematchedwiththosereceipts,andobliging [PA6]Theterm'TrackableBaggage'
themselves passengerstopresentthosereceiptstothe referstoaBaggageItemthatcanbe
checkedinon BaggageCollectionSystemonarrival.This identifiedwithaparticularpassenger.
departure. strategyisreflectedinthefollowingways: identifies
adistinctionismadebetweenbaggageand [PA263]ABaggageReceiptservesto
trackablebaggage uniquelyidentifyaBaggageItem.
everyitemoftrackablebaggagehasa [PA233]UMLSequencediagram
uniquereceipt TravelwithBaggage:NormalCourseof
presentationofreceiptsbypassengers Events
occursatbaggagecollection.
[SHR5]Attheportofarrival,the
passengershallbeabletocollectbaggage
he/shecheckedinondeparture.

Fig.7.17Rationalesectionofdesigndocument

Inthisfigure,thefirstcolumnshowsthetextoftheStatementofNeedthatis
addressedbytherationale,themiddlecolumncontainstherationale,andtheright
handcolumnshowsevidencefortherationaleinthemodelandrequirementsthat
arederivedfromit.Thistabularpresentationis,ineffect,thesandwichonitsside:
twolayersofrequirementwiththedesignrationaleinbetween.Witheffectivetool
support,thisviewoftheprojectdatacanbegeneratedfromthepresenceoftracing
betweenthelayers.

7.11MetricsforTraceability

Sincetheconceptoftraceabilityissocentraltorequirementsengineering,itis
interestingtoconsiderwhatprocessmeasurementsmaybeusefulinrelationtothe
flowdownofrequirements.
Focussingonthesatisfactionrelationship,andmovingdownthroughthelayers
ofrequirements,therearethreedimensionsoftraceabilitythatmayinterestus:

Breadth:howwelldoestherelationshipcoverthelayer,upwardsand
downwards?
Depth:howfardown(orup)thelayersdoestherelationshipextend?

Page173
7.11MetricsforTraceability 153

Growth:howmuchdoestherelationshipexpanddownthroughthelayers?
Tohelpindeterminingwhichaspectsofthesedimensionsareusefulintermsof
measuringtherequirementsengineeringprocess,itisnecessarytodistinguish
betweentwotypesofmetrics:
Phasemetrics:measurementsrelatingtoasinglestageofdevelopment,e.g.justto
thesystemsrequirementslayer
Globalmetrics:measurementsspanningseveralstagesofdevelopment.
Thethreedimensions,alongwithadiscussionaboutbalance,arenowaddressed.

7.11.1Breadth

Breadthrelatestocoverage,andassuchisaphasemetric.AsdiscussedinChapter1,
https://translate.googleusercontent.com/translate_f 160/211
2017520 RequirementsEngineering

coveragecanbeusedtomeasureprogressofprocessesthatcreatetraceabilityata
singlestage.Itfocusesonasinglelayer,andmeasurestheextenttowhichrequire
mentsarecoveredbytheadjacentlevelaboveorbelow(orbesidewhenlooking
atqualification.)

7.11.2Depth

Depthlooksatthenumberoflayersthattraceabilityextendsupwardsordown
wardsfromagivenlayer,makingitaglobalmetric.Oneapplicationmayrelateto
determiningtheoriginsofrequirementsofthelowestlevel.Howmanycomponent
requirementshaveactuallyfloweddownallthewayfromthestakeholderrequire
ments,andhowmanyhavetheiroriginsomewhereinthedesign?

7.11.3Growth

Growthismoreinteresting.Itisrelatedtopotentialchangeimpact.Howmany
requirementsatlowerlevelsarerelatedtoasinglerequirementatthetoplevel?
ConsiderFig.7.18,inwhichfoursituationsarecontrasted.
Incase(a),asinglerequirementissatisfiedbyasinglerequirementatthenext
leveldown.Thegrowthfactoris1.In(b)thesinglerequirementismetby6,giving
agrowthfactorof6.Whatdoesthissayaboutthedifferencesbetweenthetwo
requirements?Possibilitiesare:

Requirement(b)maybepoorlyexpressed,andneedsdecomposingintoseveral
Requirement(b)maybeinherentlymorecomplexthan(a),andthereforemayneed
specialattention

Page174
154 7AdvancedTraceability

a b

c d

https://translate.googleusercontent.com/translate_f 161/211
2017520 RequirementsEngineering
Fig.7.18Traceabilitygrowth

Changingrequirement(b)willhavemoreimpactthanchanging(a),andtherefore
needsspecialattention

Ofcourse,anapparentimbalanceatonelevelmaybeaddressedatthenextlevel
down.Thisisillustratedbycases(c)and(d),wherethegrowthfactortwolevels
downisidentical.Whatcouldbededucedfromthis?Possibilitiesare:

Thetoprequirementin(c)wasataleveltoohigh.
Themiddlerequirementsin(d)wereataleveltoolow.

Onlyafterconsiderableexperienceinaparticularorganisationdevelopingpar
ticularkindsofsystemscouldonebegintoascertainwhatgrowthfactorofrequire
mentsbetweenlayersistobeexpected.Morereadilyuseful,however,wouldbeto
examinethebalanceofgrowthbetweenrequirements,asameansofidentifying
potentialroguerequirements,orimbalancesintheapplicationofprocess.

7.11.4Balance

Oneideaforametricistolookatthedistributionofgrowthfactorsforindividual
requirementsbetweentwogivenlayers,andexaminethosethatlieintheouter
quartilesofthedistribution.Thegoalistoidentifyrequirementsthathaveanabnor
mallyhighorlowgrowthfactor,andsubjectthemtospecialscrutiny.
Figure7.19showswhatatypicalgrowthdistributionmaylooklike.Thegraph
plotsthegrowthrateagainstthenumberofrequirementsthatpossessthatgrowth
rate.Mostliebetween2and6,whereasafewhaveonly1ormorethan6.Itisthese
latterrequirementsthatshouldbeidentifiedandgivenspecialattention.

Page175
7.11MetricsforTraceability 155

Focusonreviewingrequirements
inupperandlowerquartiles

No.ofrequirements

0123456789101112

Growthatnextlevel

Fig.7.19Frequencydistributionofrequirementgrowth

https://translate.googleusercontent.com/translate_f 162/211
2017520 RequirementsEngineering

2 3

Fig.7.20Criticalityofrequirements

Thediscussionabovewasaboutdownwardsgrowthexaminingthenumberof
requirementsthatflowoutofanother.Whatabouttheoppositedirection:thenumber
ofrequirementsthatflowintoanother?
Bearinginmindthattraceabilityisamanytomanyrelationship,consider
Fig.7.20.Tworequirementsatthelowerlevelhavemorethanonerequirement
flowingintothem.Whatcanwesayabouttheserequirements?Theyareperhaps
morecriticalthanothers,sincetheysatisfymultiplerequirements,andshould
thereforebegivenspecialattention.
Thedistributionofupwardtraceabilitycanbeusedtosingleouttheserequirements.
Figure7.21showsthetypicalshapeofsuchadistribution.

7.11.5LatentChange

Changemanagementisperhapsthemostcomplexrequirementsengineeringprocess.
abilitytodeterminethepotentialimpactofchange.Whenachangerequestisraised

Page176
156 7AdvancedTraceability

Focusonreviewingrequirements
inupperquartile

No.ofrequirements

0123456789101112

Growthfrompreviouslevel

Fig.7.21Frequencydistributionofrequirementcriticality

againstonerequirement,allthosetracingtoitmovetoasuspectstatusuntilthe

https://translate.googleusercontent.com/translate_f 163/211
2017520 RequirementsEngineering

engineersascertainthetrueimpact.
Theraisingofasinglechangerequest,therefore,cansuddenlyintroducea
cascadeofpotentiallatentchangeintothesystem.Insuchcircumstances,itwould
behighlydesirabletotrackprogressandestimatetheconsequentialwork.
Figure7.22illustratesthecomplexityofchangeimpact.Achangerequestis
raisedononeofthehighestlevelrequirements.Part(a)showsthepotentialimpact
usingdownwardstraceability.Thoseboxesmarkedwithawhitecirclearesubject
tochangeassessment.
Part(b)thenshowspotentialchangeusingupwardsimpact.Thisoccursbecause
ofalowlevelrequirementthatflowsdownfromtwohigherrequirements.Itis
necessarytoaccessupwardsimpactfromthesechanges,becausechangesinalow
levelrequirementmaycauserenegotiationatahigherlevel.Suddenlyeverythingin
thisexampleispotentiallysubjecttochange!
Ofcourse,asengineersassesstherealimpact,itmaybefoundthatinfactsome
oftheserequirementsarenotsubjecttochangeafterall,andthecascadeofpoten
tialchangescanthankfullybepruned,sometimesquitesubstantially.
Thestatusofchangecansimplybemeasuredintermsofthenumberof
requirementsstillinasuspectstate.Whenachangerequestisraised,allother
requirementstraceabledownwardsandupwardsaremarkedassuspect.Thenthe
numberofsuspectrequirementswillsteadilydecreaseasassessmentsaremadeof
each,theirstateisreset,possiblyresultinginacascadeofothersbeingresetaswell.
Theamountofresidualchangeinasystemwillthuspeakeverytimeanewchange
isintroduced,andtailoff,asillustratedinFig.7.23.

Page177
7.11MetricsforTraceability 157

a Achangeproposalis
raisedhere.

Theseneedreviewing
forimpact.

b Maybesodothese
(upwardsimpact)

andthereforethese.
(downwardsimpact)

Fig.7.22Potentialchangeresultingfromachangerequest

Peaksindicateintroduction
ofchangerequests

https://translate.googleusercontent.com/translate_f 164/211
2017520 RequirementsEngineering

No.ofsuspectrequirements

time

Fig.7.23Progressinprocessingchange

Theabovediscussionofthechangeprocesssupposesthatchangeispropagated
fromrequirementtorequirementpurelythroughtheexistingsetoflinks.However,
achangeinarequirementmaynecessitatetheadditionorremovaloftraceability
links.Changesinlinksshouldpropagatechangetotheconnectedrequirementsat
bothends.

Page178
158 7AdvancedTraceability

7.12Summary

OfalltheadvantagesintheuseoftraceabilitycitedinChapter1,Section1.5,itis
theincreaseinconfidenceinmeetingrequirementsthatissoclearlyaddressed
throughrichtraceability.Thedisciplineofcapturingtherationaleassociatedwith
traceabilitybuildsthatconfidence.
Thereisnodoubtthatthereisconsiderableeffortinvolvedinthecreationof
completesatisfactionarguments,especiallyincomplexsystemswithhundredsof
requirements.
IntheNetworkRailproject,therearesome500satisfactionargumentsthatserve
todecomposethehighlevelrequirementsthroughtosubsystemrequirements.
Ateamofbetweentwoandfiverequirementsengineerswasdedicatedtothemain
tenanceofthisinformationoverabout3years.
Experiencesuggests,however,thatthecostisamplyrepaidintheincreased
confidencethatcomesfromthegreaterreflectionrequired.Theabilityforthe
NetworkRailsponsororganisationtotakeahighlevelobjective,anddemonstrate
indetailthroughthelayersofrichtraceabilityexactlyhowthatobjectiveisgoing
tobemet,wasamajorsellingpointfortheconcept.
Itisclear,also,thattraceabilityisarichsourceofmetricsforprocessmeasure
ment.Itistheformalisationofrelationshipsthroughtraceabilityandassociated
processesthatmakesuchmeasurementpossible.

https://translate.googleusercontent.com/translate_f 165/211
2017520 RequirementsEngineering

Page179

Chapter8
ManagementAspectsofRequirements
Engineering

Intheorythereisnodifferencebetweentheoryandpractice.
Inpracticethereis.

YogiBerra,baseballplayer,b.1925AD

8.1IntroductiontoManagement

Themanagementoftherequirementsengineeringprocessissimilartothemanagement
ofanyotherendeavour.Beforestartingoutitisnecessarytounderstandwhatneeds
tobedone.Weneedtoknowthesortsofactivitiesthatmustbeundertaken.We
needtoknowwhetherthereareanydependenciesbetweentheactivities,e.g.whether
oneactivitycanonlycommencewhenanotheronehasbeencompleted.Weneed
toknowwhatkindsofskillsarerequiredtoperformtheactivities.
Itisgoodpracticewhenpreparingaplantoconcentrateontheoutputsthatwill
begeneratedbyeachactivity.Outputscanbeseenandprovidetangibleevidence
thatworkhasbeenorisbeingdone.
Fromallofthisinformationwecangenerateaplaninwhichwehaveidentified

https://translate.googleusercontent.com/translate_f 166/211
2017520 RequirementsEngineering

theactivitiestobeundertaken,thepeoplewhowillperformtheactivitiesandthe
timeitwilltakethemtocompletetheactivities.Wecanthenstartworkfollowing
theplanandthemanagercanmonitorworkagainsttheplan.Inanidealworldthe
planwillbefollowedtotheletter.Nothingwillgowrongandweshallarriveatthe
completiondateoftheplanwithalltheworkdone.
Realitycanbequitedifferent.Firstly,estimatingthetimeandeffortrequiredto
completeataskisverydifficultunlessthemanagerhasextensiveexperienceof
tacklingsimilarjobsinthepast.Secondly,theremaybedifficultiesdiscoveredas
workprogressesthatcouldnothavebeenforeseen.Forexample,theplanmayhave
reliedontheavailabilityofakeypersonataspecifictimeand,foranynumberof
reasons,thatpersonisnotabletobethere.
Theseeventscausedeviationsfromtheplanandleadtotheneedtochangeit.
Onceanewplanhasbeenputinplace,thewholeprocessisrepeated.Afrequent
consequenceofchangingtheplanisthat,almostinevitably,thecostwillincrease
and/orthetimetocompletionwillbelaterthanpreviouslyestimated.Analternative

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_8, 159
SpringerVerlagLondonLimited2011

Page180
160 8ManagementAspectsofRequirementsEngineering

Fig.8.1Capability,costand Product
timeareinterrelated Capability

Better

Decisions

Cheaper Faster

Cost Time

approachistokeepthecostsandcompletiontimeconstantandreducetheamount
ofworktobedone.Thiscanbeaviablestrategyinsomecircumstancesforexample,
itmaybeimperativethatacompanyhasanewproductoutinthemarketplaceata
giventime(toaddressthecompetition)andwithinagivenbudget(becausethatis
allthecompanycanafford)irrespectiveofhowcapabletheproductis(althoughat
leastathresholdlevelisusuallynecessarytoavoidtriviality).Thissituationistypical
ofthewayinwhichcommercialpressurescandriveaproject.
Itisimportanttorecognisethatanyprojectisconstrainedbythethreefactors:

Productcapability
Cost
Timescale

ThesethreefactorsarerelatedasindicatedinthediagramofFig.8.1.Anychange
tooneofthesefactorswillhaveaconsequentialchangetoatleastoneoftheothers.
Figure8.1alsoindicatesthatprojectsmakeprogressbytakingdecisions.Every
decisionpositionstheprojectwithrespecttothesethreefundamentalfactors.Itis
thepipedreamofeveryprojectmanagerthateachdecisionwillimprovetheproduct
capabilitywhilstsimultaneouslyreducingcostandshorteningdevelopmenttime.In
spiteofitsimprobability,thisdreamiswidelyheld.
https://translate.googleusercontent.com/translate_f 167/211
2017520 RequirementsEngineering

8.2RequirementsManagementProblems

Inthissectionintroducesthespecificproblemsthatmakethemanagementof
requirementsmoredifficultthansomeothermanagementactivities.Thefirstproblem
isthatveryfewpeoplehavehadsignificantexperienceofmanagingrequirements.
Thisismainlybecauseveryfeworganisationshaveadefinedrequirementsmanage
mentprocessthatisfollowedacrosstheorganisation.Asaresultpeoplefacedwith
aprojectthatmustaddressrequirements,haveverylittleexperiencetodrawon.
Thismakesestimationverydifficult,becauseoneofthemainingredientstothe

Page181
8.2RequirementsManagementProblems 161

productionofgoodestimatesisextensiverelevantexperience.Thusthestartingpoint
isnotgoodandoneisremindedofthejokeinwhichonepersonasksanotherthe
waytoaspecificplaceandreceivesthereplyIwouldntstartfromhere!
Acorollaryofthisproblemismorefundamental.Ifpeoplehavehadlittleexperi
enceofrequirementsmanagement,theymaynotevenknowwhatactivitiesare
necessarytodeveloprequirements.Earlierchaptersofthisbookhaveaddressed
thisissueandgivedirectguidanceonthesortsofactivitiesnecessarytodevelop
requirementsofvarioustypesandinseveralcontexts.
Thesecondproblemisthatmanypeopledonotproperlydistinguishbetween
userorstakeholderrequirementsandsystemrequirements.Furthertheyoftendo
notdistinguishbetweensystemrequirementsanddesignspecifications.Inother
wordstheygostraightforasolutionratherthandefiningasolutionindependentset
ofrequirements.Againthistopichasbeendealtwithintheprecedingchaptersof
thisbook.
Thethirdmainproblemisthatthewayinwhichrequirementsaremanagedwill
dependuponthetypeoforganisationinwhichtheworkisbeingdone.Inthepre
cedingchapterswehavediscussedthedifferenttypesofrequirementsandindicated
howtheyarerelated.However,thewayinwhichtheseprocessesareappliedwill
dependuponthetypeoforganisationapplyingthem.Therearethreemaintypesof
organisation:

Acquisitionoranisationsthatpurchasesystemsandthenusethemtoprovidean
operationalcapability.Theseorganisationsaremainlyconcernedwithcreating
andmanagingStakeholderrequirements,whichsubsequentlyareusedasthe
basisforacceptanceofthedeliveredsystem.
SupplierorganisationsthatrespondtoacquisitionrequestsfromAcquisition
organisationsorhigherlevelSupplierorganisations.Theseorganisationsreceive
InputRequirementsanddevelopsystemrequirements(andsubsequentlya
designthatismanufactured)inresponsetothem.(Suppliersmayalsobeacquirers
oflowerlevelsubsystemsorcomponents,butthisisaquitedifferentformof
acquisitionbecauseitisbasedonadesignarchitecture.)
Productcompaniesthatdevelopandsellproducts.Theseorganisationscollect
Stakeholderrequirementsbutfromtheirmarketplaceratherthanfromindividuals
orfromoperationsorganisations.Themarketingdepartmentusuallyperformsthe
collectionofrequirements.Productcompaniesdevelopproductsinresponseto
thestakeholder(marketing)requirementsandsellthedevelopedproducts.Ina
https://translate.googleusercontent.com/translate_f 168/211
2017520 RequirementsEngineering
sensethesetypesoforganisationsencompassbothacquisitionandsupply,butthey
tendtohaveadifferentrelationshipbetweenthepartsofthecompanythatperform
theserolescomparedtothestandardacquisitionandsupplierrelationship.

Wewillreturntothesetypesoforganisationlaterinthischapter.
Thefourthproblemthatmakesthemanagementofrequirementsmoredifficult
thansomeothermanagementactivitiesisthatitisquitedifficulttomonitorprog
resswhenrequirementsarebeinggenerated.Onedifficultissueistoknowwhether
therequirementssetiscompleteinordertodecidewhethertheactivityshould
stop.Evenworse,istheproblemofdetermininghowmuchprogresshasbeenmade

Page182
162 8ManagementAspectsofRequirementsEngineering

whentheactivityisnowherenearcompletion.Thisproblemisfurtherexacerbated
bytheneedtoassessthequalityoftherequirementsgenerated.Alonglistof
requirementsmayhavebeengenerated,buthowdoesthemanagerassesswhether
eachrequirementiswellexpressed?Howcanhetellwhethereachrequirementis
uniqueandwhethertheyareallnecessary?
Thefinalproblemistheperennialproblemofchanges.Requirementsmanage
mentshouldbetheprimaryfocusforchangemanagement.Anyproposedchange
willusuallyrelatetooneormorerequirements.Theimpactorknockoneffectsof
proposedchangesarequiteoftendifficulttoassess,yetwithoutthisknowledgeit
isimpossibletoestimatethecostandtimeimpactofintroducingachange.

8.2.1SummaryofRequirementManagementProblems

Specificmanagementissuesforrequirementsdevelopmentariseinconnectionwith:

Planning
Monitoringprogress
Controllingchanges

Theproblemsaresubtlydifferentdependingontheorganisationinvolved.Therefore,
intherestofthischapterweconsidereachoftheseactivitiesinthecontextofthe
threetypesoforganisationsintroducedearlier.Finallywedrawtogethersomecommon
approachesinaconcludingsection.

8.3ManagingRequirementsinanAcquisitionOrganisation

8.3.1Planning

ThestartingpointforaprojectinanAcquisitionOrganisationwillbesomeform
ofconceptdescription.Initsmostbasicformthiswillbejustanidea,butusually
itwillbemoreconcreteandwellfounded.Thereasonforthisissimple:projects
mustbeauthorisedbytheorganisationandtheauthorisationprocesswillrequire
somedocumentedevidencetosupportthecaseforspendingtimeandmoney
(resources).Theevidenceusuallycontainsabriefdescriptionofwhattheusers

https://translate.googleusercontent.com/translate_f 169/211
2017520 RequirementsEngineering

wanttobeabletodo(theconcept)andasupportingargumenttoindicatethe
benefitsthatwillensuetotheoperatingorganisationfromtheprovisionofsucha
capability.
Theinformationintheconceptdefinitionenablestheprojectmanagertobegin
planning.Sincetheconceptdefinitioncontainsadescriptionofwhattheusers
wanttobeabletodoweimmediatelyhaveaninitialsetofStakeholders(users)
forthesystemandanoutlineofoneormoreScenarios(abilitytodosomething).

Page183
8.3ManagingRequirementsinanAcquisitionOrganisation 163

Thefirststepinconstructingaplanconsistsofidentifyingafullersetof
StakeholdertypesandamorecompletesetofScenariosthatcoverthecomplete
rangeofexpectedoperationofthesystemincluding,whereuseful,differentmodes
ofoperation.Oncethenumberofstakeholdertypesisknownitispossibletoplan
indetailhowtosetaboutelicitingrequirements.Actionsthatmaybeinstantiated
intheplaninclude:

(a)Plantointerviewoneormorecandidatesofeachstakeholdertype.Therequire
mentsmanagerisresponsibleforensuringthatauthorisationtoconductthe
interviewsisobtainedfromthecandidatesmanagers.Authorisationmay
dependuponappropriatejobcodesandbudgetsbeingagreed(sothatthecandi
datesinterviewedcanbooktheirtimetothenewprojectandconsequentlytheir
managersarenotpenalisedfortheirstaffsabsencewhilstbeinginterviewed).
Therequirementsmanagershouldalsoensurethataccesstokeyoperationsstaff
isprovided.Oftenthecandidatesmanagerswillbeunwillingtoreleasetheir
mostcompetent(usefulandwellinformed)staffforanactivitythatisnotin
theirshortterminterests.Itisuptotherequirementsmanagertoconvincethem
ofthevalueofdoingso.
(b)Allocatetimetowriteuptheinterviewsasinterviewreportsandagreethem
withcandidatesinterviewed.
(c)Decidetheinterviewstrategyandcommunicatetotheinterviewers(whomay
beinvolvedinthedecisionprocessanyway).Theinterviewstrategywilldeter
minehoweachinterviewisconducted,forexample,whethercandidatesshould
bepromptedtoexpressscenariosthemselves,orbepresentedwithasuggested
scenariothattheycancriticise,etc.
(d)Priortotheinterviewsitcanbeuseful(butnotnecessarilyeasy)togetallthe
candidatestogetherandexplainthepurposeoftheinterviews.Ifsuchameeting
canbearranged,itprovidesanexcellentforuminwhichtodiscuss/develop
userscenariosandtoseekconfirmationthatallstakeholdertypeshavebeen
identified
(e)Agreeanddocumentthesetofuserscenariosthatbestreflectthepurposeand
operationofthesysteminitscontext.Itisessentialtoensurethatthescenarios
arenottooblinkeredintheirscope.
(f)Followingtheinterviews,suggestedstakeholderrequirementscanbeextracted
fromtheinterviewreportsandagreedwiththeinterviewcandidates
(g)Decideonastructureintowhicheachofthestakeholderrequirementscanbe
entered.
(h)Placeeachidentifiedstakeholderrequirementwithintheagreedstructureand
modifythestructureasnecessary.
(i)Identifyandrecordanyconstraints.Someconstraintsareproductrequirements
suchasphysicalsize.Othersareplanconstraintssuchasbudgetedcostand

https://translate.googleusercontent.com/translate_f 170/211
2017520 RequirementsEngineering

completiontime.TheproductconstraintsshouldbeenteredintotheStakeholder
RequirementsSpecification.Theplanningconstraints(suchasbudget,schedule,
resourceorquality)belonginthemanagementplanandwillhaveaninfluence
ontheplanningactivity.

Page184
164 8ManagementAspectsofRequirementsEngineering

(j)Decidewhetheradditionalattributesarerequiredtosupportthetextofthe
requirements.Manyorganisationshavestandardsetsofattributesthatmaybe
requiredoraremerelyadvisory.Examplesare:Priority,Urgency,Status,
Validationmethod,Acceptancecriterion.
(k)Agreethecriteriaforthereviewofeachindividualrequirementandforthe
requirementsetasawhole.Thesecriteriaarebestpresentedasachecklistfor
thereviewers.Ideallythereviewcriteriashouldbecreatedasearlyaspossible
anddistributedtothepeoplewritingtherequirements.Thisenablesthemto
appreciatewhatisrequiredofthembeforetheystarttowrite.
(l)Definethereviewprocessandrelatethistothestatusoftheindividualrequire
ments.Thisprocesscanbesummarisedasastatetransitiondiagramasshown
inFig.8.2.Thisshowsthattheinitialstateofastakeholderrequirementis
Proposed.Whentherequirementsmanagementteamhasreviewedit,itcan
movetotheReviewedstatus.Reviewedrequirementscanthenbesubjectedtoa
furtherreviewbytheSponsorsteamand,whensuccessful,willachieve
Endorsedstatus.Notethat,atanytime,anActiverequirementcanberejected.
Reviewcriteriamustbedeterminedforeachreview.
(m)Performreviewsasrequiredbythereviewproceduredefined.

Thislistofactivitiesimpliestheneedforseveraldecisionstobetaken.Thisisthe
requirementsmanagersresponsibilityincollaborationwithotherinterestedparties
suchastheinterviewcandidates,theirmanagersandtheoverallsponsorforthe
system.
Careshouldbetakentoassessanyplanningconstraintstoensurethattheyare
feasibleandsensible.Stakeholdersmaydemandthatthesystemisputinservicein
averyshortperiodoftimeandatlowcost,butthismaynotbepossible.Aprime
exampleofanunrealistictimeconstraintcomesfromtheLondonAmbulance
SystemdevelopedtocontrolambulancesinLondonintheearly1990s.Themanagers
wantedtohavethesysteminplacesothattheycouldsupplythegovernmentwith
theperformancestatisticstheyweredemanding.Thisveryshortdevelopment
periodandearlyinservicedatewereplacedontheprojectasoverallconstraints,but
wereabsolutelyimpossibletomeet.Manycontractorstriedtopersuadetheambu
lanceservicethatitwasimpossibletomeettheseconstraintsandaskedfortheinservice
datetobeputback.Theserequestswererefusedandsomanycontractorsdidnotbid.
Thisleftlessexperiencedcontractorstoattempttomeettheimpossibleconstraint.

Active

Proposed Reviewed Endorsed Rejected

Requirements Sponsors
Management Team
Team Review
Review

https://translate.googleusercontent.com/translate_f 171/211
2017520 RequirementsEngineering

Fig.8.2Examplestatetransitiondiagramforstakeholderrequirementstatus

Page185
8.3ManagingRequirementsinanAcquisitionOrganisation 165

Historyshowsthattheycompletelyfailedtomeetthedemandeddeadlineandinthe
processcausedseriousharmtomanypeople.
Realisminplanningisessentialforprofessionalintegrity.

8.3.2Monitoring

Monitoringcanstartoncetheplanisinplace.Obviousmonitoringpointsarethe
completionofeachactivityintheplan.Intheearlystagestheactivitieswillmainly
revolvearoundpreparingfortheinterviews,conductingthemandreportingon
them.Thesearequiteeasytoassess.
Threemajormilestoneshelptodefinethemonitoringfortherestoftheprocess:

1.Thedefinitionofthestructurefortherequirementsspecification
2.Thedefinitionoftheattributesrequiredforeachrequirement
3.Thedefinitionofthereviewprocess(es)withassociatedchecklists

Oncethestructureisinplaceitispossibletodeterminewhetherthereareanyareas
wherethereshouldberequirementsbutnoneexist.Theseholescanbeaddressed
byspecificactions.
Oncetheattributeshavebeendecided,progressinfillingthemcanbemonitored.
Finally,theprogressagainstsatisfyingthereviewchecklistcriteriacanbe
checkedbymeasuringthenumberofrequirementsthathaveaspecificstatus.

8.3.3Changes

Duringthedevelopmentofstakeholderrequirementstherewillbeaperiodofrapid
andintensechange.Atthisstageitisnotsensibletohaveaformalchangecontrol
processinplace,becausethesituationistoodynamicandwouldjustgetintheway.
However,atsomepointstabilitywillbegintoemergeandtherequirements
managercandeterminewhentherequirementsaresufficientlystabletosubject
furtherchangestoamoreformalprocess.Oftenthisstageonlyoccursonceallthe
requirementshavebeenreviewedandreachtheEndorsedstate(seeFig.8.2).
Managingchangeisavitalactivityinrequirementsdevelopment.Theformality
withwhichtheprocessmustbeapplieddependsuponthedevelopmentstateofthe
project.Importantstagesincludethefollowing:

StakeholderRequirementsusedasthebasisforacompetitivebiddingprocess.
Contractinplaceforthedevelopmentofasystem.
Designcompleteandmanufacturingabouttostart.
Acceptancetrialsarebeingundertaken.
Thesystemisinservice.

https://translate.googleusercontent.com/translate_f 172/211
2017520 RequirementsEngineering

Page186
166 8ManagementAspectsofRequirementsEngineering

Thislistdefinesasetofpointsinasequenceofincreasingcommitment.Hencethe
furtherdownthislistaprojectis,themoreformalityisrequiredinthechangecon
trolprocessandthehigherthelikelycostimpactofanychange.
Whateverstageaprojectisat,thefollowingstepsarerequiredinachange
controlprocess:

1.Recordthesuggestedchange
2.Identifytheimpactofthesuggestedchange
3.Decidewhethertoacceptthechange
4.Decidewhentoimplementthechange

Thesuggestedchangeshouldindicatethereasonforthechangeandidentifythe
stakeholderrequirementsthatmustbechanged,addedordeleted.Thepersonor
organisationrequestingthechangemustalsoberecorded.
Atstep2theimpactwilldependuponthestageatwhichthechangeissuggested
andthiswillrequireinformationabouthowtheimpactedrequirementswillinflu
encethedownstreaminformationsuchassystemrequirements,design,manufac
turingandinserviceoperations.
AChangeControlBoardwilltakestep3.Theconstitutionofthisboardwill
dependupontheorganisation,thescaleofthesystem,andthestageofdevelopment
oroperationaluseofthesystem.Ifachangeisaccepted,thenstep4isrequired.It
maybethatthechangemustbeincorporatedimmediatelyirrespectiveofcost.
Alternativelythechangemaybedeferreduntilalaterreleaseofthesystem.Any
numberofintermediatepointsmaybeappropriateandthisclearlydependson
circumstances.
Itisalwaysusefultohaveasetofstatesforachangeandtorepresentthisusing
astatetransitiondiagramorstatechart.Figure8.3containsanexample.
Itisalsoimportanttodecidewhetherthestatusofrequirementsthatarethe
subjectofachangeproposalshouldbechangedtoindicatethis.Thereareatleast
twoschoolsofthoughtonthispoint.Onegrouptakestheviewthatthedependency

Proposed Rejected

Agreed Deferred

Planned

Fig.8.3Statetransition
Incorporated
diagramforchangecontrol

https://translate.googleusercontent.com/translate_f 173/211
2017520 RequirementsEngineering

Page187
8.4SupplierOrganisations 167

betweenthechangeandtherequirementsisheldinthechangeproposalandhence
itisnotnecessarytomodifytherequirementsstatus.Anothergrouptakestheview
thatwhenithasbeendecidedthatachangeproposalwillbeincorporated,this
meansthattherequirementissubjecttochangeandthisindicatesthatitsreview
statushaschanged.(ThisistheviewtakeninChapter2.)Whateverpositionis
adopted,itisnecessarytodecideonthestatusvaluesforchangeproposalsand
whetherthesehaveanyimpactonthereviewstatusoftheaffectedrequirements.
Insummary,Acquisitionorganisationsaremainlyconcernedwiththecreation
ofstakeholderrequirements.Thisisacreativeprocessthatisdifficulttoscope
initially.However,astheworkprogressesandthenumbersofstakeholdersand
scenariosareagreed,itispossibletoplanmoreaccurately.
Changecontrolstartsoffwithlittleformality,butthisevolvesastheproject
maturesthroughdevelopment,manufactureandinserviceoperation.

8.4SupplierOrganisations

Supplierorganisationsrespondtorequestsfromcustomerstobuildsystemsor
componentsforsystems.Priortoobtainingacontracttobuildasystem,theymust
prepareaproposaltoindicatehowtheyintendtogoaboutthejobandcontaining
estimatesofcostandtimetocompletethework.Oftenproposalsarerequested
fromanumberofsupplierorganisationsthatcompetetogetthebusiness.Itis
thereforeusefultoconsidersupplierorganisationsfromtwopointsofview:bidding
forworkandexecutingacontractoncetheworkhasbeenwon.

8.4.1BidManagement

Thissectionlooksatthemanagementaspectsoftheprocesstocreateaproposalin
responsetoacustomerssetofrequirements

8.4.1.1Planning

Oftenthestartingpointforrequirementsmanagementwithinasupplierorganisa
tionwillbethereceiptofanInvitationtoTender(ITT),alsoknownasaRequest
forProposal(RFP).Suchaninvitationorrequestwillcontainasetofrequirements
thatmustbesatisfiedbythesystemtobedelivered.
Thenatureoftherequirementsreceivedwilldependupontheorganisationtype
ofthecustomer(i.e.theorganisationthatissuedtheinvitation).Ifthecustomeris
anacquisitionorganisationitislikelythattherequirementsmaybestakeholder
requirements.Alternatively,thecustomermaybeanothersupplierorganisationthatis
planningtosubcontractoneormoresubsystemsinahigherlevelsystem.Inthiscase

https://translate.googleusercontent.com/translate_f 174/211
2017520 RequirementsEngineering

Page188

168 8ManagementAspectsofRequirementsEngineering

therequirementsarelikelytobesystemrequirementswithimposeddesignconstraints.
Tomakethenarrativeclearerweshallrefertotherequirementsreceivedbyasupplier
asInputRequirementsirrespectiveofwhattheyreallyare.
Whateverthenatureoftheinputrequirementsreceived,thefirsttaskistoassess
themtodeterminewhethertheyare:

Clearlyidentifiedanddistinguishedfrompurelydescriptiveinformation
Unambiguous
Consistent
Freefromunduedesignconstraints

Inshort,itistodeterminewhethertheyformasoundbasisuponwhichtobid.
Fromaplanningpointofview,itisimportanttoidentifythenumberofrequire
mentsthatmustbesatisfied.Thisprovidesametricthatcanbeusedtogetanidea
ofthescopeoftheworktobedone.
Duringthereviewoftheinputrequirements,anyproblemsmustbehighlighted
byidentifyingspecificproblemsandproposingapotentialsolutionforthem.Such
solutionsmayinvolvesuggestingalternativewordingfortherequirements,oreven
alternativerequirementsthatcanbesatisfiedperhapswithofftheshelf
components.
Oncethereviewhasbeenundertaken,theproblemsitidentifiesmustbe
addressed.Thiswillusuallyinvolveenteringadialoguewiththecustomertoobtain
clarificationorauthorisationforaproposedchange.Theextentofthisdialoguewill
dependupontheconditionsattachedtotheinvitation.Iftheinvitationistoasingle
supplierthedialoguecanbeenteredintoimmediately.
However,iftheinvitationcomesaspartofacompetitivebiditmaybenecessary
tobemorecircumspect.Thereasonforthisisthat,usuallythecompetitionrules
insistthatanyqueriesfromonepotentialsupplierarecopied(togetherwiththe
customersresponse)toalltheotherpotentialsuppliers.Hence,itispossiblethat,
byaskingquestions,onesuppliercangiveinformationtotheothercompetingsuppliers.
Inthissituation,itmaybemoreappropriatetoflagtheproblemsandobservations,
butratherthangoingbacktothecustomerwiththem,discusstheminternallyand
decidehowtohandlethem.Possibleoptionsforeachprobleminclude:

Ignoreit.
Makeanassumptionanddocumentit.
Decidethatitisessentialtoaskthecustomerwhatevertheconsequences.

Thelastactionmayleadtoafurtheractiontoformulatetherequesttothecustomer
insuchawaythatthecompetitorsarehelpedleast.
InparallelwithsortingouttheInputRequirements,workmustproceedoncreating
aproposedsolution.Obviouslytheprimaryoutputfromthisworkistheproposal
readytobesubmittedtothecustomer.Therearemanydifferentapproachestothe
creationofaproposal,buttheyallinvolveensuringthateachinputrequirementis
properlyaddressed.Thebidmanagermustallocateeachrequirementtoanindi
vidualorteamwhowillberesponsibleforcreatingaresponse.

Page189

https://translate.googleusercontent.com/translate_f 175/211
2017520 RequirementsEngineering
8.4SupplierOrganisations 169

Itisvitalthatalltheseresponsesbecoherent,otherwisetheproposalcouldend
upproposingarandomanddisconnectedsetofbitsandpieces.Thebestwayof
achievingthisistocreateamodelthatcanformthebasisforthesolution.
Dependingonthenatureoftheproposal,thiscouldbeeitheranabstractmodelthat
canformthebasisforbuildingasetofsystemrequirements,oritcanbeanoutline
designarchitecture.Eachresponsetoaninputrequirementcanthenberelatedtothe
model.Thisprovidestraceabilityfromtheinputrequirementsanditprovidesthecoher
encesothatinconsistenciescanbeidentified.Theproblemisalwaysthatthepeople
workingonthesolutionmustworkwithincompleteinformationbasedondocu
mentedassumptionsandpotentiallybestguessesatwhatthecustomerreallymeant.
However,thisislife!
Attheendofthebidphase,whentheproposalhasbeensubmitted,itisimpor
tantthatthebidteamrecordalltheinformationtheyhaveaccumulatedduringthe
bidpreparation.Thebidteamwillquiteoftenbeunderextremepressuretofinalise
andsubmitthebidbytherequiredsubmissiondate.Often,theywillbereadyto
takeabreakandmayforgettoproperlyrecordalltheinformationinaformthatcan
beusedbythedevelopmentteamlater.Forlargeproposalstheamountofinforma
tioncanbesignificantandalsothedelaybetweensubmittingtheproposaland
startingdevelopmentcanbelong(e.g.68months).Inthesecircumstancesitis
evenmoreimportantthatinformationisrecorded,becausethedevelopmentteam
maynothaveanypeoplewhowereinvolvedinthebidpreparation,andevenifit
does,afterasignificantperiodoftime,theyarelikelytohaveforgottensomeofthe
keyassumptionsandrationales.
Afurtherimportantactivityduringthebidphaseisthesettingupofagreements
withsuppliers.Thesewillusuallybemadeconditionalonthebidbeingsuccessful,
buttheywillhaveanimpactonthelevelofdetailtowhichthesolutionisdeveloped.
Thebasisofanagreementbetweenasupplierorganisationanditssuppliersmustbe
foundedonasetofrequirementsforthecomponentstobesupplied.Thelevelof
detailthatisrequiredduringthebidphasewillbesetbyagreementbetweenthe
organisationsinvolved.Thiswilldependuponthenatureoftheworkingrelationship
thatexistsbetweentheorganisationsandthedegreeofexperienceandtrustthat
exists.(SeeAgreementProcessintheGenericProcessintroducedinChapter2.)

8.4.1.2Monitoring

Measuringprogressduringthecreationofaproposalisvital,becausetimescales
areusuallyquiteconstrainedandthesubmissiondateisnotnegotiable.Theend
pointmustbethattheproposalclearlyindicateshoweachinputrequirementwill
bemet.However,merelyassertinghowarequirementwillbemetisnotsufficient.
Itisalsonecessarytocheckthatalltheassertionsarevalid.Thisisanaspectofthe
reviewprocess,butanindicationofprogresscanbeobtainedbycomparingthe
percentageofinputrequirementsthathavebeentracedtothesolutionmodel(and
hencetoeithersystemrequirementsordesigncomponents).

Page190
170 8ManagementAspectsofRequirementsEngineering

Ameasureoftheamountofoutstandingworktobedonecanbeobtainedby
https://translate.googleusercontent.com/translate_f 176/211
2017520 RequirementsEngineering

assessingthenumberofinputrequirementsthatstillhaveoutstandingproblems
loggedagainstthemtogetherwiththenumberofinputrequirementsthatstillhave
noproposedsolution.
Anotherimportantmilestoneinthedevelopmentofasolutionisthecreationof
amodelthattheteamarecontentwith.Ensuringthatsuchamodelisproduced
quicklyandthatthereisbuyinisacrucialtaskforthemanager.
Inadditiontoallofthesemonitoringdevices,ameasureofthequalityofthe
systemrequirementsmustalsobemade.Thiscanbedoneinasimilarmannerto
thatdescribedaboveforacquisitionorganisationsmonitoringthecreationofstake
holderrequirements,bydefiningstatesandlinkingtheprogressionthroughthose
statestoreviewcriteria.

8.4.1.3Changes

Duringthepreparationofaproposaltherearethreepotentialsourcesofchange:

Customer
Suppliers
Internal

Onemightthinkthattherewouldbenocustomerchangesduringthepreparationof
aproposal,andideallythiswouldbetrue.However,itissafestnottoassumethis.
Typicallytheprobabilityofchangeisroughlyproportionaltothesizeofthesystem
(orcomponent)tobedeveloped.Forverylargesystems,suppliersoftencommence
theirbiddingactivitieswithanearlydraftofanRFPinordertogetthebidteam
runningandthinkingalongtherightlines.Laterversionsareissuedatintervalsand
maycontainsignificantchanges.
ThefirsttaskonreceiptofanewversionoftheRFP(oritsrequirements)isto
determinethenatureandextentofthechanges.Dependingonthecustomerand
themediumusedtoissuetheRFP,thelocationofthechangesmaybehighlighted
orcompletelyunknown.Oncefound,thechangesmustberelatedtothework
alreadydoneandanassessmentmadeofthenewworkandreworkthatisnow
necessary.
Changesfromcustomerscanalsocomeviaresponsestoqueriesfrombidders.
Theseareusuallywellfocussedandcanbeassessedquitereadily.
Changesinstigatedbysuppliersaremorelikely.Thesemaybeinresponse
toaninitialrequestforaproposaltoindicatethattheycannotmeettherequire
mentsasdefined,orthechangesmaycomelaterintheprocesswhenthe
supplierdiscoversthatwhatwasoriginallythoughttobepossibleturnsoutnot
tobe.
Internalchangesariseformuchthesamereasonsasthesupplierschanges.
Initialassumptionsturnouttobeinvalidandthereforeanalternativeapproachmust
betaken.

Page191
8.4SupplierOrganisations 171

Whateverthesourceofthechange,itisessentialthatthevariousrequirements
baselinesarekeptuptodate,i.e.:

Inputrequirements
https://translate.googleusercontent.com/translate_f 177/211
2017520 RequirementsEngineering
Requirementsplacedonsuppliers
Assumptionsandinterpretationsmadewithinthebidteam

8.4.2Development

8.4.2.1Planning

Thedevelopmentstageofaprojectcommenceswithanagreedcontractbasedon
theproposalsubmittedtothecustomerandmodifiedduringcontractnegotiations.
Inadditiontothistherewillbeotherinformationgeneratedduringthebidding
process,butnotnecessarilyincorporatedintotheproposal.Thismayinclude
detailedrequirements,assumptions,outlineordetaileddesigninformationandan
initialassessmentoftherisksinvolvedinundertakingthedevelopment.Thisinfor
mationwillhavebeenusedtoarriveattheestimatedtimeandcostofthework.
Theactivitiesinvolvedinthedevelopmentstagehavetobemoreconsideredand
inmuchmoredetailthanthoseattheproposalpreparationorbiddingstage.One
importantdifferenceisthatinsteadofproducingaproposal,theproposalpreviously
submittedmaynowbepartoftheinputrequirements.
Theinformationgeneratedduringdevelopmentactivitieswilldependuponthe
natureofthedevelopmentbutwillinevitablyincludethecreationofasolution
model.Thismaybedoneintwostages,firstlyproducinganabstractmodeland
secondlyproducingoneormorepotentialdesignsolutions.Ifmorethanonesolution
iscreated,thenitwillbenecessarytodefinethecriteriaformakingacomparative
assessmentofthesolutionsandthendecidingwhichonetotakeforward.Thiscom
parativeassessmentleadstothecreationofoptionsandthepossibilityoftradingoff
somerequirementsagainstothers.Thistradeoffmaybedoneentirelyinternaltothe
supplierorganisationoritmayinvolvethecustomerand/orthesuppliers.
Activitiesarenecessarytoensurethatalltheinputrequirementsinthecontrac
tualspecificationareaddressed,thattheproposedsolutionembodiedinthesystem
requirementsanddesignisadequate.Thelevelofdetailwillusuallyhavetobe
improvedtoensurethat,atthemostdetailedlevel,nothingislefttochance.
Duringthedevelopmentstageitisimportanttoensurethatthemeansoftesting(oroth
erwisedemonstratingthesatisfactionof)eachrequirementisunderstoodanddocumented.
Thefirststepistoundertakeanauditoftheavailableinformationtodetermineits
extentandquality.Ideallyalltheinformationcreatedbythebidteamshouldhavebeen
collectedtogetherandarchivedreadyforuseinthedevelopmentprocess.Alltoo
frequentlythisisnotthecaseandsignificantinformationcanbelost.Thiscancausea
majordiscontinuitybetweentheintentionsofthebidteamandwhatisactuallydone
bythedevelopmentteam.This,inturn,canputtheorganisationsbusinessatrisk.
Followingtheaudittheprojectmanagermustdetermine,bycomparingtheproposal
submittedwiththecontract,whathaschangedsincetheproposalwassubmitted.

Page192
172 8ManagementAspectsofRequirementsEngineering

Thenextstepistodeterminewhattheimpactofthesechangeswillbeandtoplan
activitiestomakeanyconsequentialchangestothesystemrequirements,design
andcomponentspecifications.
Anyoutstandingassumptionsandcommentsmustbereferredbacktothe
customer,althoughideallythesewillhavebeenaddressedduringthenegotiationof
thecontract.
https://translate.googleusercontent.com/translate_f 178/211
2017520 RequirementsEngineering

Afurtherissuethatoftenariseswhenplanningadevelopmentiswhetherthe
systemwillbedeliveredwithfullfunctionalityatonce,orwhethertherewillbea
seriesofreleaseswithincreasingfunctionalityculminatingwiththefinalcomplete
release.Supplyingaseriesofreleasesprovidesthecustomerwithaninitialcapability
early.Thisapproachisverypopularinsoftwaredevelopmentwheretheremaybe
somedoubtsabouttheusabilityofthesystem.
Fromarequirementsmanagementpointofview,releasesmustbeplannedonthe
basisofthesetofrequirementsthatwillbeimplementedineachrelease.These
decisionscanberecordedbyaddingareleaseattributetoeachrequirement.Such
attributescaneitherbeenumeratedlistsorBoolean.Asetofpossiblevaluesforan
enumerationlistwouldbe:

{TBD,Release1,Release2,Release3}

(WhereTBDstandsforToBeDecidedandwillusuallybethedefaultvalue).
WhenusingBooleanattributeseachhasthevalueTrueorFalseandoneis
createdforeachrelease.

8.4.2.2Monitoring

Monitoringprogressduringthedevelopmentshouldbefocussedonassessingthe
currentextentandqualityoftheoutputinformationtobegenerated.Itisalsovital
toknowhowmuchtimeandefforthasbeenconsumed.Fromthisknowledgeitis
possibletoestimatewhethertheoutputswillbecompletewithintheeffortandtime
allowedintheplan.Thisestimatemusttakeintoaccountthemanagersknowledge
ofwhenoratwhatratetheinformationoutputsareexpectedtobeachieved.
Ifthemanagerdiscoversthatprogressislaggingbehindtheplan,thenappropriate
correctiveactionscanbetaken.Thesewillinevitablyleadtoachangeintheplan,such
asadjustingthedurationorresourcesofexistingactivities,oraddingextraactivities.
Themonitoringactivitiesmustensurethatprojectinformationisuptodate.
Itisespeciallyimportantthatinputrequirementsandsupplierrequirementsare
modifiedinlinewithagreedchangesandthattraceabilitylinksexistfrominput
requirementsthroughtosupplierrequirementsviatheproposedsolution.

8.4.2.3Changes

Thesamethreesourcesofchangesariseinthedevelopmentasalreadyidentifiedin
thebiddingstage.Theextentofcustomerchangesislikelytobefarlessduring

Page193
8.5ProductOrganisations 173

developmentthanduringbidding.Internalandsupplierchangesarejustaslikely.
Theprocedureforidentifyingthenatureandconsequenceofanychangeisjustthe
same.However,theconsequenceofachangeatthispointisfarmoreserious.Small
changescanbeaccommodatedwithinthecustomercontractorsupplieragreement.
However,moreseriouschangesmayrequireachangetothetermsandconditions
ofeither.Changesintroducedduringdevelopmentwillusuallyhaveanimpacton
boththetimescale(schedule)ofthedevelopmentandthecost.Oncetheconse
quenceshavebeendetermined,itisthenacommercialdecisionwhethertoabsorb
anycostandtimepenaltiesorwhethertonegotiatewiththecustomerand/or
https://translate.googleusercontent.com/translate_f 179/211
2017520 RequirementsEngineering

suppliers.
Whenachangeisproposedforadevelopmentwithseveralreleases,itisa
functionofchangemanagementtodecidewhichreleasethechangewillbeimple
mentedin.
Insummary,Supplierorganisationsrespondtocustomerrequestsbypreparing
aproposalandifsuccessfultheygoontodevelopasystem.Makingsurethatthe
requirementsissuedbythecustomerareasoundbasisforthedevelopmentisof
primeimportance.Keepingtheinputrequirementsuptodateaschangesareintro
ducedensuresthattheprojectissoundlybased.Traceabilityfromtheinputrequire
mentstotheproposedsolution,totheirsuppliersrequirementsandtotesting
informationensuresthattheimpactofchangecanbeassessedandthattheorgani
sationatalltimesknowsthestatusofthedevelopment.

8.5ProductOrganisations

Productorganisationsdefinestakeholderrequirementsanddevelopaproductto
satisfythem.ThustheyhavemanyofthecharacteristicsofAcquisitionand
Supplierorganisations.Themaindifferenceisthatthecustomersupplieragree
mentatthetoplevelofthesupplychainiswithintheoverallorganisation,although
differentdepartmentsusuallyundertaketherolesofdefiningstakeholderrequire
mentsanddevelopingproductstosatisfythem.

8.5.1Planning

8.5.1.1SingleProductVersion

Planningforasingleversionofasingleproductinvolvesthesameactivitiesasfor
theacquisitionandthesupplierorganisations.Thedifferencebetweenthebidding
andthedevelopmentstagesmaystillbethere.Forexample,whenstartinganew
product,thecompanymaywanttohaveaninitialideaofwhatisinvolvedinbuilding
it.Toachievethisitisnecessarytoelicitthestakeholderrequirementsandto
produceanoutlinesolution.

Page194
174 8ManagementAspectsofRequirementsEngineering

Producingthestakeholderrequirementsisverysimilartothewayinwhichacquisi
tionorganisationsdoit.Thereisaneedtoidentifystakeholdersanduserscenarios.
However,ratherthaninterviewingrealstakeholders,whatusuallyhappensisthat
peoplevolunteer(orarevolunteered)toactassurrogatestakeholders.Thismeans
thattheyadopttheroleofadefinedstakeholderanddefine,fromthatpointofview,
whatthestakeholderrequirementsare.Fromaplanningpointofviewthereislittle
difference.Peoplemuststillbeidentifiedandinterviewed.Requirementsmustbe
extracted,properlyformulatedandembodiedinanagreedstructure.Finallythe
requirementsmustbereviewedandtheirqualityestablished.
Producinganoutlinesolutionisverysimilartotheworkdonewhencreating
aproposal.Themaindifferenceisthatthereisdirectaccesstothepeoplewho

https://translate.googleusercontent.com/translate_f 180/211
2017520 RequirementsEngineering
areformulatingtherequirementsandhencethereisthepossibilityofamuch
moreinteractivedevelopmentwherethestakeholderrequirementscanbemodi
fiedtomakeimplementationeasier,toreducetimetomarketandtoreducecost.
Itisevenpossiblethatthecapabilityofaproposedproductcanbeenhanced
withinthegivenbudgetbyfeedingbacktechnicalpossibilitiestotheownersof
thestakeholderrequirements.Itisclearlymucheasiertogainclarificationwhere
requirementsarevagueorconfusing,etc.Thismaysoundveryinformal,andin
somecases,itcanbe.However,thedegreeofformalitymustbeagreedpriorto
startingthework.
Whenanagreedsetofstakeholderrequirementsandanoutlinesolutionhave
beenproducedandreviewedbytheproductorganisation,itmaydecidenottoproceed
withthedevelopmentoritmaydecidetoinvestfurtherfundsandgotoamore
detaileddesignoreventoproduceanearlyprototype.Thusitcanbeseenthata
productcanproceedbymeansofasetofstageswhereeachstagebuildsuponprevious
work.Eachstagehasagivenbudgetandasetofobjectives.Attheendofeachstage
thereisareviewatwhichprogressagainstthebudgetandtheobjectivesisassessed.
Thisprocedurecanbedescribedusingthestagegateconceptasindicatedin
Fig.8.4.
Attheinitialgate(StageGate0),asetofobjectives,budgetandtimescaleare
defined.Thesefeedintoaplanningprocesswhichdeterminestheinformation
whichmustbegeneratedinordertoachievethestagesobjectivesandaworkplan
whichwillachievetherequiredstatewithinthebudget.Theinitialobjectivemay
bemerelyanexplorationoftheconceptandsomepreliminaryestimationofmarket
size,etc.Attheendofthestagetheworkdoneisreviewedagainsttheobjectives
todeterminewhethertheprojectshouldcontinueorwhetheritshouldstop.This
reviewshouldalsotakeintoaccountthecurrentbusinessobjectives,whichmay
havechangedorevolvedduringthestage.
Iftheprojectisallowedtocontinuethenafurtherbudget,timescaleandobjec
tiveswillbeagreed.Forthesecondstageitmaybedecidedtogoforacosted
proposalasdiscussedaboveandamoredetailedexplorationofmarketconditions.
Thestagegatereviewwillthencheckwhethertheestimatedcostisinlinewiththe
expectedrevenuethatcanbeearned.Thisleadsnaturallyintoadecisiontocancel
orcommitfurtherfunds.Ifthelatter,thenadecisionhastobetakenabouthowfar
thedevelopmentshouldbetaken,e.g.

Page195
8.5ProductOrganisations 175

EnterpriseGoals

InitialGate StageGate1 StageGate2 StageGate3

Stage1 Stage2 Stage3

Objectives Objectives Objectives

Stage1 Stage2 Stage3

Planning Planning Planning

Stage1 Stage2 Stage3

Information Information Information
State State State
Required Required Required

Stage Stage Stage

https://translate.googleusercontent.com/translate_f 181/211
2017520 RequirementsEngineering
1 2 3
Work Work Work

ProjectInformationBase

Fig.8.4Stagegatesandprojectwork

Domoreinvestigationintothedevelopmentandproductioncosts.
Developaprototype.
Produceasmallbatchandtrythemoutwithrealcustomers.
Gointofullproduction.
Etc.

Thusthestagegateprocesscancontinueonestageatatimewithgradualcommit
mentoffundsandresources.Thisenablestheorganisationtocontrolitsinvestment
strategyandkeepaneyeonitslikelyreturnoninvestment.

8.5.1.2MultipleProductsandVersions

Productorganisationsmayhaveseveralversionsofthesameproductatdifferent
stagesintheirevolution.Typicallytheywillhavesomeproductversionsinuseby
peoplewhohavepurchasedthem,someindevelopmentandsomebeingdefined.
Fromaplanningpointofview,eachversioncanbetreatedasaseparateproject
goingthroughitsownsetofstagesandgates.However,thereisanadditionalneed
toplanforthedifferentversionsoftheproductsinthepipeline.Itisimportantto
planwheneachversionincurrentusewillbephasedoutandreplacedbyalater
model.Theseaspectscanalsobebroughtunderthestagegateprocess,sothataset
ofstagegatereviewscanbeheldatthesametimetodeterminethebestinvestment
strategytokeeporincreasemarketshare.

Page196
176 8ManagementAspectsofRequirementsEngineering

Afurtherfactorinthisareaisthattheremaywellbedifferentversionsfor
differentmarkets.Forexample,itmaybenecessarytohaveuserinterfacesthat
supportdifferentnaturallanguagesforsaleindifferentcountries.
TocopewiththistypeofdifferenceweintroducethenotionofaVariant
meaningdifferinginformordetailsfromthemainone.Thuswecanhavethe
mainone(perhapsbetterexpressedasthecoreproduct)beingaproductwith
theuserinterfaceinEnglishandvariantsfortheFrench,GermanandSpanishmarkets.
Eachvariantcanhaveitsownversionssuchthateachversionisanimprovement
overthepreviousone.
Figure8.5indicateshowtherecanbeparallelversionsandvariantsofasingle
producteachatadifferentstageofitsevolution.ThelettersS,DandUindicate
whetheraproductisbeingspecified,beingdevelopedorbeingused.Eachofthese
statescorrespondstooneormorestagesinthestagegatelifecycle.
Fromarequirementsmanagementpointofview,eachvariantwillhavemany
requirementsincommonwiththecoreproduct,butitwillhavesomerequirements
thatarespecifictothatvariantandthereforedifferentiateitfromothervariants.On

https://translate.googleusercontent.com/translate_f 182/211
2017520 RequirementsEngineering

theotherhand,theremaybenodifferentrequirementsforeachversionofavariant,
becauseeachversionisanattempttosatisfythesamesetofrequirements(hope
fullyimprovingasthesequencegoeson).

Main

v1 S D U

v2 S D U

v3 S D U

v4 S D U

VariantA

v1 S D U

v2 S D U

v3 S D U

v4 S D U

VariantB

v1 S D U

v2 S D U

v3 S D U

v4 S D U

Fig.8.5Versionsandvariants

Page197
8.5ProductOrganisations 177

Intheprevioussectionweusedthetermreleaseandreadersmaybeconfused
betweenareleaseandaversion.Thedifferenceisthatareleaseisaversionthatis
deliveredtothecustomer,whereasnotallversionswillbe.
Planningtheevolutionofthevariantsandtheirversionsforeachproductisa
furtherorganisationaltaskthatcanalsobecontrolledusingthestagegatemecha
nism.Thedevelopmentforthesemayoverlapintimeandtherewillbeaneedto
supportatleastoneversionofeachvariantwhilstitisinoperationaluse.
Theactivitiesinvolvedindoingthespecificationanddevelopmentareverysimilar
tothoseintroducedearlierfortheacquisitionandsupplierorganisations.Themajor
differenceisthat,wheredifferentversionsandvariantsofthesameproductexist,
thereiscommoninformationbeingusedinseveralcontexts.Thiscomplicatesthe
managementoftherequirementsandmakesitessentialtounderstandhowthe
requirementsbaselinesforeachversionandvariantoverlap.
Therearetwoapproachescommonlyused.Inthefirst,requirementsaremarked
usinganattribute,toindicatewhethertherequirementisacommonrequirementor
onlyvalidforoneormorevariants.Inthesecondapproachacopyofalltherequire
mentsismadeandchangesmadetothecopyforaspecificproductvariant.
Analternativeapproachthatisgainingpopularityinsomeorganisationsisto
introduceanadditionallayerofabstractionreferredtoasaFeatureVariability

https://translate.googleusercontent.com/translate_f 183/211
2017520 RequirementsEngineering
Model.Featurescanbeusedinseveralproductsandtendtobequitestable.
Requirementsaremarkedaseithercommonorrelatedtooneormorespecificfeatures.
Theadvantageofthisapproachisthat,onceanewfeaturehashaditsrequirements
introducedandmarked,thatfeaturecanbeusedinanynumberofnewproducts.
Thusdevelopmenteffortisonlyrequiredwhenanewfeatureisaddedtotheproduct
set,ratherthanworkbeingnecessaryforeverynewproduct.
Fromaplanningandorganisationalpointofview,theintroductionofafeature
variabilitymodelprovidesalevelofabstractionthatproductplannersandmarketing
peoplecanrelateto.Thishelpsfocustheorganisationsseniormanagementand
makethemmoreawareoftheextentandcapabilitiesoftheirproductportfolio.
Whicheverapproachisadopted,thefactthattherearecommonrequirements
andvariantrequirementsleadstoextracomplicationsinthemanagementofchange
(seebelow).

8.5.2Monitoring

Monitoringprogressinaproductorganisationusesexactlythesamemechanisms
asfortheotherorganisations.Whenstagegatesareusedasthebasisfororganisa
tionaldecisions,theprocessofplanningwillinvolvetheidentificationofthedata
statethatmustexistattheendofthestage.Progresscanthenbemeasuredbased
ontheextenttowhichthedesiredstatehasbeenreached.Asageneralrulesuch
statescanbemeasuredinthefollowingterms:

Whethernewobjectsexistthatwillbecometargetsfortraceabilitylinks(e.g.
solutionobjectsinresponsetostakeholderrequirements,ordesignobjectsin
responsetosystemrequirements)

Page198
178 8ManagementAspectsofRequirementsEngineering

Whetherattributevaluesexist
Whethertherequiredreviewstatusexists
Whethertraceabilitylinksexistfromonedatasettoothers(e.g.fromstake
holderrequirementstosystemrequirements,fromsystemrequirementsto
designandfromallofthesetotestingstrategiesandpossiblytestresults)

Measuresexpressedasapercentageofrequireddataqualitycurrentlyachieved
provideusefulmetricsforbothqualityofdataandprogresswithinastage.

8.5.3Changes

Asmentionedearlierthemajoradditionalfactorforchangemanagementinaprod
uctorganisationiswhereseveralvariantsofaproducthavecommonrequirements,
andachangeproposalisraisedagainstoneormoreofthem.Thequestionsthat
mustbeansweredare:

Willallthevariantswanttoincorporatethechange?
Whenwilltheywanttoincorporateit?

Quiteoftentheanswerwillbethatallvariantswillwanttoincorporatethechange,
butnotatthesametime!Thisintroducesanextrastateintothechangehandling

https://translate.googleusercontent.com/translate_f 184/211
2017520 RequirementsEngineering

statetransitiondiagram(seeFig.8.6)becauseeachvariantmustincorporatethe
changebeforethechangecanbecompleted.
Figure8.6alsoindicatesthatitisnecessarythattherearePlanned,Deferredand
Incorporatedstatesforeachvariant.Thechangecanonlyachievethestatusof
completewhenallthevariantshavereachedtheirindividualIncorporatedstate.

Proposed Rejected

Agreed

Planned Deferred
Repeatedfor
eachvariant

Incorporated

Complete

Fig.8.6ModifiedSTDforchangemanagementwithvariants

Page199
8.6Summary 179

Insummary,ProductorganisationsperformsimilartaskstobothAcquisitionand
Supplierorganisations.Inadditiontheymusttakecaretocontroltheirproduct
portfoliosothatanappropriatedegreeofcommitmentismadeandtheoverallcom
mercialexposureisacceptable.

8.6Summary

Thesummaryisgroupedundertheheadingsofplanning,monitoringandchanges
inlinewiththepresentationofthemainbodyofthetext.

8.6.1Planning

Planningshouldbedrivenbytheoutputsthatmustbecreated.Activitiestocreate
therequiredoutputscanthenbeintroduced.Outputscanbecategorisedasfollows:

Typesofinformationobjects(e.g.stakeholders,stakeholderrequirements,system
requirements,designorsolutionobjects,etc.).
Attributesassociatedwithaninformationobject.
Linksbetweeninformationobjectstoestablishtraceability,testingstrategy,
etc.
Reviewcriteriatodeterminetherequiredqualityofinformationandassociated
https://translate.googleusercontent.com/translate_f 185/211
2017520 RequirementsEngineering

attributes.
Achievementofaparticularstatepossiblyviaprogressionthroughaseriesof
states(e.g.byreviews).

Beforeanyworkcanbestarted,theworkmustbeauthorisedbytheorganisationin
whichitwillbeundertaken.Amechanismsuchasstagegatesisappropriatefor
AcquisitionandProductorganisationstocontrolthelevelofcommitmentand
consequentfinancialand/orcommercialexposuretheyarewillingtotolerate.In
Supplierorganisationstheremustbeanauthorisationtoprepareaproposalandthis
isusuallyaccompaniedbyanallowedbudget.Permissiontoprogresstodevelop
mentwillusuallybeembodiedinthesigningofacontractwiththecustomer.
Evolutionarydevelopmentshouldbeconsideredtobethenormespeciallyfor
unprecedentedsystems.Thisleadsnaturallyintotheconceptsofreleases,versions
andvariants.

8.6.2Monitoring

Itisvitalthatprogressismeasuredbyinvestigatingthecurrentstateoftherequired
outputs.Progressmeasuredinthiswaytogetherwiththeamountofeffortandtime

Page200
180 8ManagementAspectsofRequirementsEngineering

usedcomparedtotheplanenablestheviabilityoftheplantobeestablished.
Ignoringtheoutputsandjustmeasuringtimeandeffortconsumedgivesadistorted
viewthatisnotrealistic.

8.6.3Changes

Themostcriticalaspectofachangeistheimpactthatitwillhaveonthesystemto
bedevelopedandhenceonthedevelopmentplan.Understandingtheimpactcan
onlybeachievedprovidedthatthecurrentstatesofthe(project)outputsareavail
ableanduptodate.Ofparticularimportanceherearethelinksthatexisttoprovide
traceabilityfrominputinformationtoderivedinformation.
Decidingwhenachangecanorshouldbeincorporatedwillusuallyimpactthe
planandmaycauseseriousreplanningdependingonthescopeofthechange.
Changescanalsoleadtotheintroductionofadditionalreleases,versionorvariants.

https://translate.googleusercontent.com/translate_f 186/211
2017520 RequirementsEngineering

Page201

Chapter9
DOORS:ATooltoManageRequirements

Theresnothingremarkableaboutit.
Allonehastodoishittherightkeysattherighttime
andtheinstrumentplaysitself.

JohannSebastianBach,composer,16851750AD

9.1Introduction

Systemsengineersandmanagersneedtherightinstrumentstoassistthemwiththe
requirementsmanagementprocess.Avarietyoftoolscurrentlyexist.Thischapter
presentsanoverviewofoneofthesetoolsIBMRational DOORS (Version9.2).
DOORS(DynamicObjectOrientedRequirementsSystem)isaleadingrequire
mentsmanagementtoolusedbytensofthousandsofengineersaroundtheworld.
ThetoolwasoriginallycreatedbyQSSLtd,Oxfordandisnowdevelopedand
marketedbyIBM.

https://translate.googleusercontent.com/translate_f 187/211
2017520 RequirementsEngineering

DOORSisamultiplatform,enterprisewiderequirementsmanagementtool
designedtocapture,link,trace,analyseandmanageawiderangeofinformation
toensureaprojectscompliancetospecifiedrequirementsandstandards.DOORS
providesforthecommunicationofbusinessneeds,allowscrossfunctionalteams
tocollaborateondevelopmentprojectstomeettheseneeds,andenablesyouto
validatethattherightsystemisbeingbuilt,andisbeingbuiltright.Theviews
providedbyDOORSonthescreenprovideapowerfulfamiliarnavigation
mechanism.
AlsobrieflycoveredinthischapterisaDOORSextensioncalledDOORS/
Analyst,whichintegratesDOORSwiththeIBMRational Tau modellingtool,
allowingUMLmodelstobeembeddedandtracedwithinDOORS.
Throughoutthischapterreferencewillbemadetoacasestudyforafamilysailing
boat.TheDOORS/Analystdiscussionusespartofacasestudyforanairportbaggage
handlingsystem.

E.Hulletal.,RequirementsEngineering,DOI10.1007/9781849964050_9, 181
SpringerVerlagLondonLimited2011

Page202
182 9DOORS:ATooltoManageRequirements

9.2TheCaseforRequirementsManagement

Today,systemsengineersrequireeffectiverequirementsmanagementinorderto
providesolutions.Requirementsmanagementistheprocessthatcaptures,tracesand
managesstakeholderneedsandthechangesthatoccurthroughoutaprojectslifecycle.
Products,too,arebecomingmorecomplextothepointwherenoindividualhasthe
abilitytocomprehendthewhole,norunderstandallofitsconstituentparts.Structuring
isbyfarthebestwayoforganisingrequirements,thusmakingthemmoremanageable
intermsofomissionsorduplicateinformation.Hencerequirementsmanagementis
alsoaboutcommunication.Forthatreasonitisimportantthatrequirementsarecom
municatedcorrectly,thusensuringthatteamcollaborationisenhanced,projectriskis
reducedandtheprojectmeetsitsbusinessobjectives.Ifrequirementsarewellmanaged,
therightproductwillgettomarketontime,onbudgetandtospecification.

9.3DOORSArchitecture

Foranyapplication,therequirementsandrelatedinformationcanbestoredina
centraldatabaseinDOORS.Thisdatabasecanbeaccessedinavarietyofwaysand
existsthroughoutthelifetimeoftheapplication.TheinformationinaDOORS
databaseisstoredinmodules.Modulescanbeorganisedwithinthedatabaseby
usingfoldersandprojects.Aprojectisaspecialkindoffolderthatcontainsallthe
dataforaparticularproject(Fig.9.1).

https://translate.googleusercontent.com/translate_f 188/211
2017520 RequirementsEngineering

=Folder

=Project

=Module

Fig.9.1DOORSdatabasestructure

Page203
9.4Projects,ModulesandObjects 183

DOORSfoldersareusedtoorganisedataandarejustlikefoldersinacomputer
filestore.Foldersmaycontainotherfolders,projectsormodules.Foldersaregiven
anameanddescriptionandtheabilityforuserstoseeormanipulatethedataina
foldermaybeconstrainedusingaccesscontrols.
DOORSprojectsareusedbyateamofpeopletomanageacollectionofdata
relatingtothatteamsworkeffort.Theprojectshouldcontainallofthedatarelated
totherequirements,design,development,test,productionandmaintenanceforan
application.Theprojectprovidesthecapabilitytomanageusersandtheiraccesstothe
dataintheproject,tobackupthedataandtodistributeportionsofthedatatoother
DOORSdatabases.
DOORSmodulesarecontainersfordatasets.Threeclassesofmoduleexist:

Formalthemostfrequentlyusedtypeofmoduleforstructuredsetsoflike
information.
Descriptiveunstructuredsourceinformation(lettersorinterviewnotes).
Linkcontainrelationshipsbetweenotherdataelements.

TheuserinterfaceworksverymuchlikeWindowsExplorerandletstheusernavigate
throughthedatabase.

9.4Projects,ModulesandObjects

9.4.1DOORSDatabaseWindow

TheDOORSDatabasewindowallowstheusertoseeandmanagetheorganisation
ofDOORSdata.Figure9.2showsthedatabasewindow,withthedatabaseexplorer
totheleft,andthelistofcontentsoftheselectedfolderontheright.
DOORSprovidesthecapabilitytochangethenameordescriptionofexistingfolders
andprojects.Foldersandprojectscanalsobemovedifthereisaneedtoreorganiseor
changethestructureofthedatabase.Foldersandprojectscanalsobecut,copiedor
pastedwithinthedatabasetoreorganiseorduplicateportionsofthedatabase.

https://translate.googleusercontent.com/translate_f 189/211
2017520 RequirementsEngineering

9.4.2FormalModules

UsingtheDOORSDatabasewindow,anewformalmodulecanbecreatedusing
themenuFileNewFormalModuleasshowninFig.9.3.
Intheformalmodulecreationwindow,theuserprovidesthenameofthenew
moduleanditsdescription.Theusercanalsodeterminethestartingpointforthe
uniqueidentifiersgeneratedfortheobjectsinthemodule.Aprefixcanbeprovided
forthisnumberthatreflectsthecontentsofthemodule,suchasPRforProduct
Requirements.Bydefiningauniqueprefixforeachmodule,aprojectwideunique

Page204
184 9DOORS:ATooltoManageRequirements

Fig.9.2Databasewindow

https://translate.googleusercontent.com/translate_f 190/211
2017520 RequirementsEngineering

Fig.9.3Createnewformalmodule

Page205
9.4Projects,ModulesandObjects 185

identifierforallinformationintheDOORSprojectisestablished.Thisprovidesa
convenientreference.
Whenaformalmoduleisopened,thedefaultdisplayshowsthemoduleexplorer
ontheleft,andthemoduledataontherightasshowninFig.9.4.
Themoduleexplorermakesiteasytomovetoaspecificplaceinthedocument,
andalsoshowsthestructureoftheinformationinthemodule.Sectionscanbe
expandedorcollapsedinthesamewayascanbedonewithWindowsExplorer.
Therighthandpaneshowsthedataforthemodule.Thedefaultdisplayshows
twocolumns,theIDcolumnandthetextcolumn,whosetitleisthemodule
description.TheIDisauniqueidentifierassignedbyDOORSwhenanobjectis
created.DOORSusesthisidentifiertokeeptrackoftheobjectandanyotherinfor
mationthatisassociatedwithit,e.g.attributesandlinks.Thetextcolumndisplays
thedatalikeadocument,showingacombinationoftheheadingnumber,theheading
itselfandthetextassociatedwitheachtherequirement.
DOORSprovidesanumberofdisplayoptionsforformalmodulesasshownin
Fig.9.5.IntheStandardView,alllevelsofobjectsaredisplayedinadocument
format.Userscanrestrictthedisplaylevel,e.g.Outlinedisplaysonlyheadings,
hidingallotherobjectdetails.Thisresultissimilartoatypicaldocumenttableof
contents.AsstatedearliertheExplorerViewisusefulforseeingthestructureofthe
moduleandfornavigatingtoaspecificobjectinthemodule.

https://translate.googleusercontent.com/translate_f 191/211
2017520 RequirementsEngineering

Fig.9.4Formalmoduledefaultdisplay

Page206
186 9DOORS:ATooltoManageRequirements

Fig.9.5Formalmoduledisplaymodes

Graphicsmodeontheotherhandrepresentsthedisplayasatree.Thisaidsnavi
gationthroughlargedatasets.Thetitlesoftheobjectsingraphicsmodearebased
ontheObjectHeadingandashortenedversionoftheObjectText(seeFig.9.6).

9.4.3Objects

Aswehaveseenintheprevioussection,withinformalmodules,dataisstoredin
objects.Anobjectmaybeablockoftext,agraphicimageorevenaspreadsheet
createdusinganotherpackage.Thestandardviewofaformalmoduledisplay
includestwocolumnsandanumberofvisualindicatorsasdescribedbelow.
AsshowninFig.9.7thefirstcolumndisplaystheObjectIdentifierassignedby
DOORS.TheObjectIdentifierismadeupoftwoparts:

Aprefix(typicallyanabbreviationfortherequirementset).
Theabsolutenumber,suppliedbyDOORS.

Theabsolutenumberisanintegerassignedsequentially(1,2,3etc.)thatservesas

https://translate.googleusercontent.com/translate_f 192/211
2017520 RequirementsEngineering

akeyforeachobject,uniquewithinthemodule.
ThesecondcolumnisknownastheMainorTextcolumn.Itincludesacomposite
threeattributes,dependingoncontents:

Page207
9.4Projects,ModulesandObjects 187

Produ ctpersp ectiv e

In tro d u ctio n
Gen eralcap ab ilities

Gen eralco nstraints

Gen eral
Descrip tio n
Userch aracteristics

Operatio nalen viro nmen t

Assump tio nsan dd ep en den cies

BoatLoad ed

Boatmo vedto sailin garea BoatTran sp orted

BoatUnlo ad ed

Boatrigg edforsailin g
Boatready tosail
User
Ready tosail
Req u iremen ts
BoatLau nched
fo rsailb oat

BoatCon tro lled

Cap ab ilities
BoatNav igated

Sailedn ormally Cap sizerigh ted

Ash oreu sin gwin d

Ash oreWh enbecalmed

Surviv ed in bo at

Acciden tsu rv ived

Surviv ed in Water

Boatretu rn ed ho me

MarketCon strain ts

Co n strain ts SafetyCon strain ts

Ship pin gReg ulatio ns

Fig.9.6Graphicsmode

Sectionnumber(e.g.1,2.1,3.2.3)indicatingtheobjectspositioninthemodule
structure.
Objectheadingprovidingatitlefortheobject.
Objecttextgivingthefulldescriptionoftheobject.

Objectnumbersareonlydisplayedforobjectsthathavebeenassignedanobject
heading.
BlacklinesaboveandbelowtheobjectindicatetheCurrentObject.Manyfunc
tionsrelatingtoobjectsinDOORSmodules,e.g.insertinganewobject,pastingan
objectandmovinganobjectareperformedrelativetothecurrentobject.
Blue,yellowandredchangebarsappearattheleftedgeofthetextcolumn.Blue
denotesanobjectthathasnotbeenchangedsincethelastmodulebaseline.Yellow
showsthatchangeshavebeensavedsincethebaselineandredindicatesunsaved
changesmadeinthecurrentsession.
Maroonandorangelinkindicatorsaredisplayedontherighthandsideof
objects,whichhaverelationshipstootherobjects.Theorangetrianglepointingto
theleftindicatesanincominglink,andamaroontrianglepointingtotherightindicates
anoutgoinglink(onlyincomingindicatorsarepresentinFig.9.7).

https://translate.googleusercontent.com/translate_f 193/211
2017520 RequirementsEngineering

Page208
188 9DOORS:ATooltoManageRequirements

Fig.9.7Displayedinformation

ADOORSformalmoduletreestructureprovidesasimple,yetpowerfulmethod
ofwritingrequirements.Requirementsareoftenorganisedintoahierarchy,andso
thegraphicsmodeisausefulview.
CreatingnewobjectsinDOORSissimplenewobjectsareplacedinoneoftwo
positionsrelativetothecurrentobject.Either:

Anewobjectiscreatedasthenextsiblingofthecurrentobjectwith
InsertObject,or
Anobjectiscreatedasthefirstchildbelowthecurrentobjectwith
InsertObjectBelow.

ThisisshowninFig.9.8.
InDOORS,facilitiesareprovidedforeditingobjects.Forexample,aDOORS
treecanbemodifiedbyusingthecutandpastefunctions.TheCutoperation
removesthecurrentobjectandallitschildrenfromthemoduledisplay.This
causestherearrangementoftheobjecthierarchy,collapsingthetreeintothe
holevacatedbytheobjectsthathavebeencut.Thisproducesarenumberingof
theremainingsuccessorobjects.Theinsertionpointcanthenbeidentifiedforthe
objectsthathavebeencut.Becauseofthenatureofanobjecthierarchythereare
onlytwopossibilities.Objectsareplacedafterasthenextsiblingtothecurrent
objectoroneleveldownasthefirstchildofthecurrentobject.Theformeris
showninFig.9.9.

https://translate.googleusercontent.com/translate_f 194/211
2017520 RequirementsEngineering

Page209
9.4Projects,ModulesandObjects 189

Current
Object Insert,Object Insert,ObjectBelow

Section1 Section1 Section1

Section1.1 Section1.1 NewSection1.1

Section1.2 Section1.2 Section1.2

Section1.3 Section1.3 Section1.3

Renumbered
Section1.4 Section1.4 Section1.4

Section2 NewSection2 Section1.5

Section3 Section3 Section2

Renumbered
Section4 Section3

Fig.9.8Creatingobjects

Current
Object
Cut Paste

Section1 Section1
Section2
Section1.1
Section1.2 Section1 Section2.1
Section2 Section2.2
Section1.3
Section2.3
Section1.4
Renumbered Section2.4
Section2
Section3
Section3
RenumberedAgain

Fig.9.9Cutandpasteobjects

9.4.4GraphicalObjects

GraphicalobjectsintheformofembeddedOLEscanbeinsertedintoanytext
attributeinDOORS,inmuchthesamewayasOLEsarehandledinWord,for
instance.Thisallowspictures,diagrams,charts,documents,spreadsheets,and
manyotherkindsofinformationtobeinsertedintotherequirementsdocumentin
supportofrequirementsstatements.

9.4.5Tables

Inmanycases,requirementsorinformationassociatedwithrequirementsispre
sentedintabularform.Tablescanbecreatedafterorbelowanexistingobject,orat
leveloneinanemptymodule.Thisisachievedbyspecifyingthenumberofrows
andcolumnsrequired.Thenewtablecanthenbeinsertedintotheformalmodule
asshowninFig.9.10.Tablescanbedeletedaslongastherearenolinkstoanyof
thecellobjectsortothetableobject.

https://translate.googleusercontent.com/translate_f 195/211
2017520 RequirementsEngineering

Page210
190 9DOORS:ATooltoManageRequirements

Fig.9.10Creatingatable

9.5HistoryandVersionControl

9.5.1History

DOORSmaintainsanhistoricallogofallmoduleandobjectlevelactionsthat
modifythecontentsofamodule,itsobjectsandattributes.
Everychangethatisrecordedincludeswhomadethechange,whenthechangewas
madeandwhatwerethebefore/afterstatesoftheobjectanditsattributes.Themodule
historycanbeusedtotrackeveryeventinthelifeofagivenmodule.Theobjecthistory
canbeaccessedviathechangebarintheformalmodulewindoworitcanbelaunched
fromthemainmenu.AnexamplehistorywindowisshowninFig.9.11.

9.5.2Baselining

Abaselineisafrozencopyofamodule.Theyaretypicallycreatedatsignificant
stagesofaproject,e.g.asetofrequirementsisnormallybaselinedimmediatelyprior
toareview,andthenimmediatelyaftertheresultingchangesfromthereviewhave
beenincorporated.Thisallowsthevariousstatesoftherequirementsdocumenttobe
easilyreproducedatanytime.BaselinescanbenumberedandlabelledinDOORS.

Page211
https://translate.googleusercontent.com/translate_f 196/211
2017520 RequirementsEngineering

9.6AttributesandViews 191

Fig.9.11Historywindow

Baselinesarereadonlycopiesofaformalmoduleandcannotbeedited.When
amoduleisbaselined,allhistorysincethepreviousbaselineisstoredwiththe
newlycreatedbaseline,andthehistoryforthecurrentversioniscleared.Thelife
historyofamoduleisthereforestoredacrossaseriesofbaselines.

9.6AttributesandViews

9.6.1Attributes

Attributesprovideameanstoannotatemodulesandobjectswithrelatedinformation.
Moduleattributesareusedtocaptureinformationaboutthemoduleitself,suchas
itsowner,documentcontrolnumber,reviewstatesetc.Objectattributesareusedto
captureinformationaboutindividualobjects.Attributesmaybeeithersystemoruser
defined.Systemattributesautomaticallymaintaincriticalinformationabouta
moduleorobject,suchaswhenitwascreatedandbywhom,whileuserdefined
attributesmaybeusedtocaptureanyinformationrequiredtosupporttheusers
requirementsmanagementprocess.

Page212
192 9DOORS:ATooltoManageRequirements

https://translate.googleusercontent.com/translate_f 197/211
2017520 RequirementsEngineering

DOORSprovidesavarietyofstandardattributetypes,knownasbasetypes,
fromwhichattributesmaybedefined,e.g.integer,real,date,string,text,username.
Itisalsopossibletohaveuserdefinedattributetypes.
Attributeinformationcanbereadilyviewedandeditedbycreatingcolumns.
Inthisway,onscreenaswellasprintablereportscanbereadilygenerated.While
anobjectmaycontainmanyattributes,auseristypicallyinterestedinviewinga
subsetoftheseattributesatonetime.Columnsmaybecreatedtoshowjustthe
desiredsubsetsothattheuserisnotoverwhelmedwithinformation.Simplydrag
ginganddroppingthecolumnheadercanrepositioncolumns.

9.6.2Views

DOORSprovidesafacilitycalledviewsforlookingatthesameinformationin
manydifferentways.Viewsarestoredwithmodulesanditispossibletocreate
manyviewsfromaprojectsdata.Whencreatingviewstheobjectandattributes
whicharetobedisplayedarespecified.Forexample,youmightwishtocreatea
viewthatletsyouseeonlythoseobjectsinthemodulewhosePriorityattribute
hasavalueHigh.Aviewthenappearsasatable,whereeachrowcontainsone
objectandtheobjectattributesthathavebeenselected.

9.7Traceability

TraceabilityismanagedinDOORSthroughtheuseoflinksbetweenobjects.

9.7.1Links

ADOORSlinkisaconnectionbetweentwoobjects.Onepropertyofalinkisdirec
tionalityalllinkshaveadirection,fromsourcetotarget.Torepresentdatarelation
shipsalinkiscreated,thusenablingtheusertovisualizeinformationasanetwork
ratherthanjustatree.Althoughlinkshavedirectionality,DOORSprovidesthecapa
bilitytonavigateineitherdirectionthroughthepaththatalinkcreatesbetweentwo
objects.Henceitispossibletotracetheimpactofchangesinonedocumentonanother
document,ortracebackwardstoindicatetheoriginalthinkingbehindadecision.
DOORSprovidesavarietyofmethodsforcreatingandmaintaininglinks.Individual
linkscanbecreatedusingdraganddropbetweentwoobjects(usuallyindifferent
modules).Wholesetsoflinkscanbecreatedinotherways.Forinstance,theCopyand
linkfunctioncancopyawholesetofobjects,andlinkeachcopytoitsoriginal.
Linksareindicatedalongtherighthandsideofthemaincolumninthestandard
viewofaformalmodulebytriangularlinkicons.Aniconthatpointstotheleft
representsincominglinkstheoppositeforoutgoinglinks.

Page213
9.7Traceability 193

9.7.2TraceabilityReports

https://translate.googleusercontent.com/translate_f 198/211
2017520 RequirementsEngineering

ThereareanumberofwaysinDOORSofcreatingtraceabilityreports,on
screenandonpaper.Thesimplestonscreentraceabilitytoolisthroughusing
AnalysisTraceabilityExplorer,whichusesaWindowsstyleinterfacetoallow
theusertoexploretraceabilityacrossmultipledocumentsinasinglewindow.This
isillustratedinFig.9.12.
Anotherwayofconstructinganonscreenreport(whichcansubsequentlybe
printed)isbyaddingtraceabilitycolumnstoaview.Thesecolumnscandisplay
dataaboutlinkedobjectsfromotherdocuments.Theyarecreatedusing
AnalysisWizard,whichguidestheusertoselectwhichlinksandwhichattri
butesoflinkedobjectsaretobedisplayed.Traceabilitycolumnsarecompletely
dynamic,andareupdatedasnewlinksarecreated,orasthedistantdataischanged.
Throughthismeans,datafromseveraldocumentscanbebroughttogetherintoa
singlereport,onscreenorprintedontopaper.
Figure9.13showsanexampleofaviewthatcontainsatraceabilitycolumn.The
viewlivesinthecurrentmodule,whichistheStakeholderRequirements,andthe

Fig.9.12Traceabilityexplorer

Page214
194 9DOORS:ATooltoManageRequirements

https://translate.googleusercontent.com/translate_f 199/211
2017520 RequirementsEngineering

Fig.9.13Traceabilitycolumnsshowingrequirmentssatisfaction

columnshowsdatafromtheSystemRequirementsmodulebyfollowingtheincoming
links.Richtraceabilityisusedintheexample,andthecolumnsareasfollows:

TheStakeholderrequirementidentifier(fromcurrentmodule).
ThemaincolumnshowingtheStakeholderrequirementheading/text(fromcurrent
module).
Therichtraceabilitycombinator(anattributeoftheStakeholderrequirementin
thecurrentmodule).
Thesatisfactionargument(anattributeoftheStakeholderrequirementinthecur
rentmodule).
AtraceabilitycolumnentitledContributingRequirementsshowingseveral
attributesofsystemrequirementslinkedtothestakeholderrequirement.The
objectidentifierofthesystemrequirementisshownboldinsquarebrackets,fol
lowedbythetext.Inaddition,thesectionheadingsofeachsystemrequirement
areshowntogiveessentialcontextwithintheSystemRequirementsdocument.

Figure9.14showsatraceabilitycolumnfromtheotherendofthesamelinks,i.e.from
theSystemRequirementsdocumentbacktotheStakeholderRequirements.Inthiscase,
theoutgoinglinksaretraversed,andinformationisdisplayedinthecolumnentitle
originatingRequirements.Thereisnocolumnforthesatisfactionarguments.
Itiscommonforrequirementsdocumentationtoincludetraceabilitymatrices
showingtherelationshipsbetweendocuments.Throughtheuseoftraceabilitycolumns
inviews,DOORSavoidstheneedtocreateandmaintainsuchmatricesmanually.

Page215
9.8ImportandExport 195

https://translate.googleusercontent.com/translate_f 200/211
2017520 RequirementsEngineering

Fig.9.14Traceabilitycolumnonoutgoinglinks

9.8ImportandExport

ThecapabilityofexchanginginformationbetweenDOORSandothertoolsis
highlydesirable.ThiscanrangefromimportinglegacyinformationintoDOORS
andforexportingDOORSinformationtoexternaltoolsforpublishingandother
purposes.
Inprojectdevelopmenttheabilitytoefficientlyandreliablyimportandorganise
largequantitiesofinformationisoftenanecessarytask.Howeverthevarietyof
storageformatsandplatformsandtheinconsistenciesindatastructurescanmake
thisarealchallenge.DOORSprovidesawiderangeofimporttoolstosupportthis
activityandinparticularinrelationtodocuments,tablesanddatabases.Forexample,
Fig.9.15showshowtoinputfromWordintoDOORS.Thisisachievedbyopen
ingaWorddocumentandexportingittoDOORS,usingtheExporttoDOORS
buttonamodulenameanddescriptionneedstobesuppliedbeforethefileis
exportedfromWordandimportedintoDOORS.
ThedocumentisimportedintoDOORSwiththesamestructureastheWord
Outlineview,soHeading1textbecomesanobjectatthelevel1inDOORS.
Paragraphbreaksareusedfordelimitingthecontentofeachobject.
Similarly,DOORSsupportsmanyexportformatstoprovideaconvenient
methodoftransferringDOORSdatatootherdesktoptools.Asanexampleconsider
exportingfromDOORStoWordasshowninFig.9.16.

Page216
196 9DOORS:ATooltoManageRequirements

https://translate.googleusercontent.com/translate_f 201/211
2017520 RequirementsEngineering

Fig.9.15ExportfromWordtoDOORS

Fig.9.16ExportfromDOORStoWord

Page217
9.9UMLModellingwithDOORS/Analyst 197

Thisisthereverseofthepreviousoperation.TheWorddocumentwillhavethe
samestructureastheformalmodule,i.e.ObjectHeading1becomesLevel1Headings
becomeWordstyleHeading1,andsoon.TextisdisplayedinNormalstyle.
DOORSprovidesthesetypesofimportandexportcapabilitiesforarangeof
toolsandformatsincluding:RTF,Word,WordPerfect,Excel,Lotus,Access,Plain
Text,HTML,PowerPoint,MSProject,Outlookandmanyothers.

9.9UMLModellingwithDOORS/Analyst

DOORS/AnalystisanintegrationofDOORSwiththeUMLmodellingtool,IBM
Rational Tau .ItpermitsUMLmodelstobecreatedanddiagramstobepresented
withinaDOORSmodule.
https://translate.googleusercontent.com/translate_f 202/211
2017520 RequirementsEngineering

Asrequirementsareanalysed,objectsinaDOORSmodulecanbelabelledasUML
elements,suchasactors,classesandstates.WhenadiagramisinsertedintotheDOORS
modulebyactivatingtheUMLmodellingtool,theDOORSobjectssolabelledare
synchronisedwithelementsthatappearinthediagrams.Theeffectofthisistoallow
traceabilityofrequirementsintoelementsthatappearindiagramsinUML.
Figure9.17showsascreenshotofaDOORSmoduleinwhichDOORS/Analyst
hasbeenusedtolabelobjects,andinsertaclassdiagram.Labelledobjectsare
indicatedbyiconsinthenarrowcolumntotheleftofthemaincolumn,andthetype
ofUMLentityisalsoshownintheObjectTypecolumntotheright.

Fig.9.17UMLmodellinginDOORS/Analyst

Page218
198 9DOORS:ATooltoManageRequirements

https://translate.googleusercontent.com/translate_f 203/211
2017520 RequirementsEngineering

Fig.9.18UMLdiagrameditorinDOORS/Analyst

DoubleclickingonadiagramstartsuptheDOORS/Analystdiagrameditor,
showninFig.9.18.Savingchangestothemodelcausesinformationtoberesyn
chronisedintotheDOORSmodule.

9.10Summary

Abriefoverviewofarequirementsmanagementtool,DOORS,hasbeengiveninthis
chapter.Theexampleusedshowstheapplicationofsomeoftheprinciplesusedinthe
book,e.g.instantiationsofthegenericprocessinlayers,richtraceability,etc.
DOORS/Analystisalsointroducedasanexampleofhowmodellingtoolscan
complimentrequirementsmanagementtools.
Thesameprinciplescanbeappliedandimplementedinotherrequirements
managementtools.Evenifoneisjustusingawordprocessor,thedisciplines
describedwithinthecoversofthisbookwillbebeneficial.

Page219

Bibliography

AldersonA,HullMEC,JacksonKandGriffithsLE(1998)MethodEngineeringforIndustrial
RealTimeandEmbeddedSystems.InformationandSoftwareTechnology,40:443454.
AndrioleSJ(1996)ManagingSystemsRequirements:Methods,ToolsandCases.NewYork,
McGrawHill.
BabichW(1986)SoftwareConfigurationManagementCoordinationforTeamProductivity.
Boston,MA,AddisonWesley.
BernsteinP(1996)AgainsttheGodstheRemarkableStoryofRisk.NewYork,Wiley.
BoehmB(1981)SoftwareEngineeringEconomics.NewYork,PrenticeHall.
https://translate.googleusercontent.com/translate_f 204/211
2017520 RequirementsEngineering

BoochG(1994)ObjectorientedDesignwithApplications.RedwoodCity,California,Benjamin
Cummins.
BrownAW,EarlANetal.(1992)SoftwareEngineeringEnvironments.London,McGrawHill.
BudgenD(1994)SoftwareDesign.Boston,MA,AddisonWesley.
CarnegieMellon(2006)SoftwareEngineeringInstitute,CMMIforDevelopment,Version1.2,
CMMIDEV,Pitsburg,PA152133890
ChaochenZ,HoareCAR,RavnAP(1991)ACalculusofDurations.InformationProcessing
Letter,40(5):269276.
Chen,Peter(1976)TheEntityRelationshipModelTowardaUnifiedViewofData.In:ACM
TransactionsonDatabaseSystems1/1/1976.ACMPress,ISSN03625915,S.936
ClarkKBandFujimotoT(1991)ProductDevelopmentPerformance.HarvardBusinessSchool.
CoadPandYourdonE(1991a)ObjectOrientedAnalysis.EnglewoodCliffs,NJ,PrenticeHall.
CoadPandYourdonE(1991b)ObjectOrientedDesign.EnglewoodCliffs,NJ,PrenticeHall.
CooperRG(1993)WinningatNewProducts.Reading,MA,AddisonWesley.
CrosbyPB(1979)QualityIsFree.NewYork,McGrawHill.
CrosbyPB(1984)QualityWithoutTears.NewYork,NewAmericanLibrary.
DarkeP,ShanksGG(1947)UserViewpointModelling:UnderstandingandRepresentingUser
ViewpointsDuringRequirementsDefinition.InformationSystemsJournal7(3):213240.
DavisAM(1993)SoftwareRequirements:Objects,FunctionsandStates.EnglewoodCliffs,NJ,
PrenticeHall.
DeGraceP(1993)TheOlduvaiImperative:CASEandtheStateofSoftwareEngineeringPractice.
EnglewoodCliffs,NJ,PrenticeHall.
DeMarcoT(1978)StructuredAnalysisandSystemSpecification.NewYork,Yourdon.
DeMarcoT(1982)ControllingSoftwareProjects.EnglewoodCliffs,NJ,YourdonPress.
DeMarcoTandListerT(1987)PeoplewareProductiveProjectsandTeams.NewYork,Dorset
House.
EasterbrookSandNuseibehB(1996)UsingViewpointsforInconsistencyManagement.Software
EngineeringJournal,11(1):3143.
FinkelsteinA,KramerJ,NuseibehBandGoedickeM(1992)Viewpoints:AFrameworkfor
IntegratingMultiplePerspectivesinSystemsDevelopment.InternationalJournalofSoftware
EngineeringandKnowledgeEngineering,2(10):3158.

199

Page220
200 Bibliography

FowlerMandScottK(1997)UMLDistilled:ApplyingtheStandardObjectModelingLanguage.
Reading,MA,AddisonWesley.
GilbT(1988)PrinciplesofSoftwareEngineeringManagement.Reading,MA,AddisonWesley.
GilbT(2005)CompetitiveEngineering:AHandbookforSystemsEngineering,Requirements
EngineeringandSoftwareEngineeringManagementUsingPlanguage.Oxford,Elsevier
ButterworthHeinemann
GorchelsL(1997)TheProductManagersHandbook.Lincolnwood,IL,NTCBusinessBooks.
GotelOCZandFinkelsteinACW(1995)ContributionStructures.ProceedingsRE95.York,UK,
IEEEPress.
HarelD(1987)Statecharts:AVisualFormalismforComplexSystems.ScienceofComputer
Programming,8:231274.
HullMEC,TaylorPS,HannaJRPandMillarRJ(2002)SoftwareDevelopmentProcessesAn
Assessment.InformationandSoftwareTechnology,44(1):112.
HumphreyWM(1989)ManagingtheSoftwareProcess.Boston,MA,AddisonWesley.
IEEESTD12201998(1998)StandardforApplicationandManagementoftheSystems
EngineeringProcess.NewYork,NY,IEEE.
JacksonM(1995)SoftwareRequirements&Specifications:aLexiconofPractice,Principlesand
Prejudices.NewYork,NY,AddisonWesley.
JacobsenIandChristersonMetal(1993)ObjectOrientedSoftwareEngineering.Wokingham,
AddisonWesley.
KotonyaGandSommervilleI(1996)RequirementsEngineeringwithViewpoints.Software
EngineeringJournal,11(1):511.
KotonyaGandSommervilleI(1998)RequirementsEngineering:ProcessesandTechniques.
Chichester,Wiley.
LeiteJCPandFreemanPA(1991)RequirementsValidationThroughViewpointResolution.

https://translate.googleusercontent.com/translate_f 205/211
2017520 RequirementsEngineering
TransactionsofSoftwareEngineering,12(2):12531269.
LoucopulosPandKarakostasV(1995)SystemsRequirementsEngineering.NewYork,NY,
McGrawHill.
MazzaCetal(1994)ESASoftwareEngineeringStandards.PrenticeHall.
MonroeRT,KompanekA,MetlonR,andGarlanD(1997)ArchitecturalStyles,DesignPatterns,
andObjects.IEEESoftware.
MumfordE(1989)UserParticipationinaChangingEnvironmentWhyWeNeedIT.In:
ParticipationinSystemsDevelopment.Ed.KKnight.London,KoganPage.
NuseibehB,KramerJandFinkelsteinA(1994)AFrameworkforExpressingtheRelationships
BetweenMultipleViewsinRequirementsSpecification.TransactionsofSoftwareEngineering,
20(10):760773.
OliverDW,KelliherTPandKeeganJG(1997)EngineeringComplexSystemswithModelsand
Objects.NewYork,McGrawHill.
OMG(2003)TheUnifiedModellingLanguageVersion2,www.omg.org
PageJonesM(1980ThePracticalGuidetoStructuredSystems.NewYork,YourdonPress.
PerrowC(1984)NormalAccidents.BasicBooks.
PetroskiH(1982)ToEngineerisHumantheRoleofFailureinSuccessfulDesign.NewYork,
StMartinsPress.
PetroskiH(1996)InventionbyDesign:HowEngineersGetfromThoughttoThing.Harvard
UniversityPress.
PootsC,TakahashiKetal(1994)InquirybasedRequirementsAnalysis.IEEESoftware,11(2):
2132.
PressmanRS(1997)SoftwareEngineering:APractitionersApproach.NewYork,NY,McGraw
Hill.
RossDT(1977)StructuredAnalysis(SA):ALanguageforCommunicatingIdeas.IEEE
TransactionsonSoftwareEngineering,3(1):1634.
RossDT(1985)ApplicationsandExtensionsofSADT.IEEEComputer,18(4):2534.
RossDTandSchomanKE(1977)StructuredAnalysisforRequirementsDefinition.IEEE
TransactionsonSoftwareEngineering,3(1):615.

Page221
Bibliography 201

RumbaughJandBlahaMetal(1991)ObjectModelingandDesign.EnglewoodCliffs,NJ,
PrenticeHall.
RumbaughJ,BlahaM,PremerlaniW,EddyFandLorenzenW(1991)ObjectOrientedModeling
andDesign.PrenticeHall.
ShlaerSandMellorSJ(1991)ObjectLifeCyclesModelingtheWorldinStates.Yourdon
Press.
ShlaerSandMellorSJ(1998)ObjectOrientedSystemsAnalysis.EnglewoodCliffsNJ,Prentice
Hall.
SoftwareEngineeringInstitute(CarnegieMellon)(1991)CapabilityMaturityModelforSoftware.
Tech.ReportCMU/SEI91TR24.
SommervileI(1996)SoftwareEngineering.Wokingham,AddisonWesley.
SommervileIandSawyerP(1997)RequirementsEngineering:AGoodPracticeGuide.
Chichester,Wileyons.
SpiveyJM(1989)TheZNotation:AReferenceManual.EnglewoodCliffs,NJ,PrenticeHall.
StevensR,BrookP,JacksonKandArnoldS(1998)SystemsEngineering:Copingwith
Complexity.PrenticeHallEurope.
YourdonEN(1990)ModernStructuredAnalysis.EnglewoodCliffs,NJ,PrenticeHall.
ZaveP(1997)ClassificationofResearchEffortsinRequirementsEngineering.ACMComputing
Surveys,29(4):315321.

https://translate.googleusercontent.com/translate_f 206/211
2017520 RequirementsEngineering

Page223
Page222

Index

A Classification
Abstraction,17,20,80,89
Abstractmodel,54
Acceptancecriteria,3031,112113
Acquisition,161,162167
Analysis
coverage,16,138
derivation,15,138,141
impact,15,138,148
richtraceability,145146
Assessment,80,8283
Assumptions.SeeDomainknowledge
Atomicity,89
Attributes,8082
categories,8182
primary,79,83
secondary,79,83
Communication,9,13,18
Completeness,89
Complexity,1
Confidentialinformation,86
Conflicts,79,8283
Consistency,8283,90
Constraints,8487,123
Contextualinformation,7778
COTS(Offtheshelfcomponents),1
Coverageanalysis,1416,138
Cup,56

https://translate.googleusercontent.com/translate_f 207/211
2017520 RequirementsEngineering
B Dataflow,33,4853
Backgroundinformation,7980 Dataflowdiagrams(DFD),
Bidmanagement,167171 4853,79
BMethod,75 Datastore,48
Boilerplates,8588 Datatransformation,48
Brainstorming,59,91,97 DeMarco,T.,58
Businessobjectives,13 Derivationanalysis,15,138,141,145
Designfreedom,21,83
Designjustifications.SeeSatisfaction
C argument
Capability,8485 Development
Capacity,85,87 change,3031
Change ideal,31
complexity,156 process,26
estimation,156 systems,2528
impact,156 DFD.SeeDataflowdiagrams
latent,155156 Diagram
management,13,14,155,159160,162, class,5657
165166,172173,177 dataflow,4853
request,156 entityrelationship,54
Clarity,13,39,77 statetransition,69
Classdiagram,5657 Domainknowledge,80,141,142

203

Page224
204 Index

DynamicObjectOrientedRequirements F
System(DOORS),181198 Feasibility,89
architecture,182183 Feedback,90
attributes,186,191192 Filtering,86
baselines,190191 Formalmethod,7576
basetypes,191 Functionality
changebars,187 humaninteraction,119,121123,125,129
columns,187 interface,119,121,123,125,128129
explorerview,185 internal,118121,124125,128
export,195197 safeguard,118119,122123,126,129131
folders,182183 Functionalrequirements,88
graphicalobjects,189
graphicsmode,186188
history,190191 G
import,195197 Genericprocess,3338
linkindicators,187 instantiation,94,116117,133
links,187
maincolumn,192
modules,183 H
objectheading,186187 Hierarchies,79
objectidentifier,186 Humaninteraction,121122,123,125,129
objecttext,186187
outlineview,185
projects,181 I
richtraceability,194 Impactanalysis,1213,15,138,143,148
satisfactionargument,194 Impactassessment,156
standardview,185 INCOSE,81
tables,189190 Informationmodel,3338
traceability,192195 Interfaces,46
traceabilityexplorer,193 Invitationtotender(ITT),167
views,192

K
E Keyrequirements,80
Elementarytraceability,137140
https://translate.googleusercontent.com/translate_f 208/211
2017520 RequirementsEngineering
Emergentproperties,46,1819
Entityrelationshipdiagram(ERD),54 L
Environment,6 Language,8485
Estimation,160161 Languageoftemporalorderingspecification
Examples (LOTOS),75
aircraftengine,90 Legality,89
banking,123126 Letoutclauses,90
car,126131 Lifecycle,1013
cooker,139141 LOTOS.SeeLanguageoftemporalordering
cup,56 specification
militaryvehicle,139
NewYorkunderground,141
nightmare,89 M
RACrally,9 Management,155,159160
sailingboat,100,181 ofchange,155157,162,170,
timetables,142143 172173,177
vehicle,139141 experience,159161
Externalentity,4850 orbids,164

Page225
Index 205

planning,162165,167169,173177 plan,159
problems,160162 success,3
Method,5776 Propositionallogic,145
Metrics,152157 Prototypes
global,153 requirementsfrom,110
imbalance,154
phase,153
Models Q
abstract,54 Qualification,1920,95
system,55 Qualificationargument,146
Modesofoperation,123,126,130131 Qualificationrationale.SeeQualification
Modularity,89 argument
Monitoringprogress,161162,165,170, Qualificationstrategy,19,3031,112114
172,177 Quality,910
factors,81

O
Operability,87 R
Operationalmodes,90 Reality,159
Operators,140,143 Redundancy,89
Organisations RequestforProposals(RFP),167
acquisition,161,162167 Requirements
productdevelopers,161,173 abstraction,89
suppliers,161,167173 agreement,3437,40,9596,132133
types,161162 allocation,131132,143144
atomicity,89
attributes,79,8082
P boilerplates,8588
Paragraphnumbers,77 capabilities,8488
Performance,18,8587 capture,102103,106112
Performanceattribute,85 clarity,77
Periodicity,85,87 classification,7880
Praxiscriticalsystems,141 completeness,89
Precision,89 conflicting,79,8283
Problem consistency,8283,90
domain,2023,84,93114 constraints,8485,8788,111
vs.solution,2021,161 criticality,155156
Process decomposition,5354,151

https://translate.googleusercontent.com/translate_f 209/211
2017520
analysis,4041
derivation,4243
generic,2545
modelling,4041
qualification,40,4244
requirementsagreement,36
Processspecification,42
Productdevelopers,161,173
Productdistribution,1
Productfamilies,11,173176
Programmemanagement,11
Progressmeasurement,16
Project
decisionfactors,160
failure,23
Page226
206
Requirements(cont.)
legality,89
management,155,159180
modularity,89
nightmare,8990
nonfunctional,18
performance,8285
precision,89
qualification,35,95
redundancy,89
refinement,112
reuse,79
reviewing,7791
satisfaction,3435,3738,
9596
stakeholder,1823,8485
stakeholdervs.system,2122
structure,79,8990,131
structuring,7980,103
system,1623,8286
tradeoff,83
uniqueness,89
valueof,8384
verifiability,89
workshops,108110
writing,7791
Requirementsengineering
definition,69
Reuse,11,86
Reviewprocess
criteria,78
requirements,144
traceability,144
RFP.SeeRequestforProposals
Richtraceability,139147,194
analysis,145146
implementation,146147
multilayer,147
operators,140,143
singlelayer,146147
Riskmanagement,2
https://translate.googleusercontent.com/translate_f
RequirementsEngineering
definition,67
derivation,118,131135
derived,2930
documents,7780
elaboration(SeeSatisfactionargument)
expressing,86
feasibility,89
flowdown,143144
functional,18,8588
identification,107108
identifying,7779,84
identity,138,141,143144
imbalance,154
input,2930
language,8485,86,89,91
Index
Solution
domain,2023,8485,115136
vs.problem,2021,161
Sorting,86
Specification
process,42
Speculation,90
Stagegate,174
Stakeholders,7880,8485
constraints,107,111
definition,7
identification,94,9698
interviewing,106107
requirements,21,23,26,84,85
Statecharts,18,79
Statecharts,5556
Statetransitiondiagram,69
Strategy.Seesatisfactionargument
Structure,89
Subsystems,132134
Suppliers,161,167173
Systems
architecture,133134
definition,67
development,2528
engineering,46
model,117118
modelling,1718,22,4776
requirements,2123,8485
scope,101102
transactions,122123,126,130
Systemsofsystems,5
T
Tenderassessment.SeeAssessment
Testplanning,16
Timeliness,87
Timetomarket,1
Traceability,12,14,15,2223,
192195
210/211
2017520 RequirementsEngineering
Rumbaugh,J.,5859,69,70 analysis,1415
benefits,158
breadth,152,153
S depth,152,153
Satisfaction,95 downwards,156
Satisfactionargument,139147,151, effort,158
158,194 elementary,137139,140
disjunction,140 growth,153,154
language,144145 imbalance,154
Scenarios,18,79 matrix,138
ShlaerMellor,68 metrics,152157
Software,1 multilayer,146147

Page227
Index 207

overhead,16 ViennaDefinitionLanguage
rationale(SeeSatisfactionargument) (VDM),75
rich,137,140144 VISION,142
upwards,156 VModel,1011

U W
UnifiedModellingLanguage(UML) WestCoastMainline,45,141
classdiagrams,18 Wordprocessor,77
messagesequencecharts,18
Uniqueness,89
Usescenarios Y
characteristics,100101 Yourdon,E.,58,68
creation,98101

Z
V
Valuefunction,8384
Variants,176,177180
Verifiability,89 Z
Versions,173177 asformalnotation,75

https://translate.googleusercontent.com/translate_f 211/211