AbouttheAuthors

KlausPohl holds a full professorship for Software Systems Engineering at the Institute for ComputerScienceandBusinessInformationSystems(ICB)atUniversityofDuisburg-Essen,Germany.Hewas thescientific funding director of Lero, the Irish Software Engineering Research Centre. Currently he is theacting director of paluno—TheRuhr Institute for Software Technology—at theUniversity of Duisburg-Essen.HereceivedhisPh.D.andhishabilitationincomputersciencefromRWTHAachen,Germany.

Klaus is (co-)author ofmore than 250 peer-reviewed publications and several text books. He served asProgramandGeneralChairformanyinternationalandnationalconferencesincludingthe35thACM/IEEEConferenceonSoftwareEngineering (ICSE2013).Asconsultant, assessor, andexperthe supports smallandmulti-nationalcompanies,researchinstitutes,andpublicfundedresearchprograms.Klausisco-founderof the IREB e.V. (International Requirements Engineering Board). You can find more information onhttps://sse.uni-due.de.

ChrisRupp—SOPHIST-in-chief(formally:founderandexecutivepartneroftheSOPHISTGmbH),chiefconsultant,coachandtrainer.Lookingbackover25yearsofprofessionalexperience,alothascomeup:a

company . . .6books . . .55employees . . . countlessarticlesandpresentations . . . andawhole lotofexperience.Mypassionforprojectconsultationmightaccountforthefactthat,untilnow,Idonot“only”manage,butIamstilldirectlyinvolvedinprojectsandclosetocustomers.Whatdrivesmeisthevisiontoimplementgoodideassothatdevelopers,contractualpartnersandusers—bothdirectandindirect—faceanintelligent, sophisticated and beneficial product. In doing so, I work with a range of methods andapproachesinagileandnon-agileenvironments.

Inordertostandardizequalificationforrequirementsengineers/businessanalysts,IfoundedtheIREBe.V.(InternationalRequirementsEngineeringBoard).Youcanfindfurtherinformationonwww.sophist.de.

KlausPohl·ChrisRupp

RequirementsEngineeringFundamentalsAStudyGuidefortheCertifiedProfessionalforRequirementsEngineeringExam

FoundationLevel–IREBcompliant

2ndEdition

KlausPohl(klaus.pohl@sse.uni-due.de)ChrisRupp(chris.rupp@sophist.de)TranslatedfromGermanbyThorstenWeyer,BastianTenbergen,andMartaTayeh.Editor:MichaelBarabasProjectManager:MatthiasRossmanithCopyeditor:JudyFlynnProofreader:JamesJohnsonLayoutandType:JosefHegeleCoverdesign:HelmutKraus,www.exclam.dePrinter:CourierPrintedinUSAISBN978-1-937538-77-4

2ndEdition2015©2015byKlausPohlandChrisRuppRockyNookInc.802EastCotaSt.,3rdFloorSantaBarbara,CA93103

www.rockynook.com

LibraryofCongressCataloging-in-PublicationDataPohl,Klaus.Requirements engineering fundamentals : a study guide for the certified professional for requirementsengineeringexam,foundationlevel,IREBcompliant/KlausPohl,ChrisRupp.--2ndedition.pagescmISBN978-1-937538-77-4(softcover:alk.paper)1.Softwareengineering--Examinations--Studyguides.2.Systemdesign--Examinations--Studyguides.3.Requirementsengineering--Examinations--Studyguides.4.Electronicdataprocessingdocumentation--Examinations--Studyguides.I.Rupp,Chris.II.Title.QA76.758.P64132015

005.1076--dc23

2015009245

Manyof thedesignations in thisbookusedbymanufacturersandsellers todistinguish theirproductsareclaimed as trademarks of their respective companies.Where those designations appear in this book, andRockyNookwasawareofa trademarkclaim, thedesignationshavebeenprinted incapsor initial caps.They are used in editorial fashion only and for the benefit of such companies, they are not intended toconveyendorsementorotheraffiliationwiththisbook.

No part of the material protected by this copyright notice may be reproduced or utilized in any form,electronicormechanical, includingphotocopying, recording, or by any information storage and retrievalsystem,withoutwrittenpermissionofthecopyrightowner.Whilereasonablecarehasbeenexercisedinthepreparationofthisbook,thepublisherandauthorassumenoresponsibilityforerrorsoromissions,orfordamagesresultingfromtheuseoftheinformationcontainedherein.

Thisbookisprintedonacid-freepaper.

Foreword

Dearreader,

WithRequirementsEngineeringFundamentals,youareholdingtheofficialtextbook of the Certified Professional for Requirements Engineering (CPRE) –FoundationLevelcertificationinyourhands.

The2ndeditionofthisbookisalignedwiththecurriculum(version2.2)ofthe International Requirements Engineering Board e.V. (IREB) and the IREBglossary.Inaddition,someminordefectsofthe1steditionhavebeencorrected.AshortintroductiontotheIREBandthecertificationprocesscanbefoundintheprevious section “The Certified Professional for Requirements Engineering(CPRE)Exam”.

Theaimof thisbook is toaidyou inyourpreparation for thecertificationexamination of the Certified Professional for Requirements Engineering. Thebookissuitedforyourindividualpreparationfortheexaminationaswellasforcompanionliteraturetotrainingcoursesofferedbytrainingproviders.

In addition to the book, you should consider the information about thepreparation for the certification examination published on the IREB website(http://www.ireb.org/en). That additional information reflects updates of thecurriculum(afterversion2.2)andpotentiallyamends thisbookwithrespect tosomeareasofinterest.ErratatothisbookarepublishedontheIREBwebsite.

Our decision to author this book collaboratively was not unjustified. Thebook at hand is meant to integrate long-lasting practical experiences witheducational and research knowledge concerning the topic of requirementsengineering,inparticularfortheFoundationLeveloftheCertifiedProfessionalforRequirementsEngineering.Asaconsequence,thisbookisbasedonthetwobest-selling books in theGerman language about requirements engineering bythetwomainauthors:

Klaus Pohl: Requirements Engineering – Grundlagen, Prinzipien,

Techniken.Publishedatdpunkt.verlag,Heidelberg,2008.Thisbookwaswritten from a perspective of research and education and offers astructured discussion of the fundamentals, principles, and techniques ofrequirements engineering. (Also available in English: RequirementsEngineering–Fundamentals,Principles,andTechniques.Springer,NewYork,2010)

Chris Rupp: Requirements-Engineering und -Management – Aus derPraxis von klassisch bis agil. Published at Hanser Fachbuchverlag,Munich,2014.Thisbookcontainsapplication-orientedknowledgeaboutrequirementsengineering,whichsupportstherequirementsengineerinhisorherdailypractice.(IndividualchaptersalsoavailableinEnglishontheSOPHISTwebsite:http://www.sophist.de)

Wehave chosen not to reference the two books listed above in the individualchaptersofthisbook.Youcanfinddetailedadditionalinformationonthetopicsofthisbookinbothofthebooksmentionedabove.

This book was made possible with the help of a number of people. Ourspecial thanks go to Dirk Schüpferling and Thorsten Weyer for theircontributionstothisbookandtheiroutstandingcommitment,withoutwhichthisbookwould not have been possible.Many reviews and consistent support byotherboardmembersincreasedthequalityofthisbook.WeparticularlythankallboardmembersoftheIREBfortheiractivesupport.Inaddition,UrtePautzoftheSiemensAG;ChristianPikalekandRainerJoppichoftheSOPHISTGmbH(www.sophist.de); and Dr. Kim Lauenroth and Nelufar Ulfat-Bunyadi from“paluno – The Ruhr Institute for Software Technology” at the University ofDuisburg-Essen(www.paluno.de)havecontributedtoindividualsectionsofthebook. Furthermore, wewant to thank ThorstenWeyer and Bastian Tenbergen(paluno) as well as Marta Tayeh (SOPHIST GmbH) for their commitmenttowardstranslatingthisbookfromGermanintoEnglish.ThanksalsotoPhilippSchmidt and Dirk Schüpferling for their support in aligning this book to theIREBsyllabusversion2.2.

Wealsowant to thankChristaPreisendanz,Dr.MichaelBarabas,andJudyFlynnfortheirsupportinpublishingthisbook.

KlausPohlandChrisRuppEssenandNuremberg,February2015

WithContributionsfrom

KarolFrühaufINFOGEMAG,SAQ

KarolFrühaufstudiedinBratislavaandatRWTHAachen,gaininghisdegreeincomputerengineeringin1975.Hethenspent12yearsatBrown,Boveri&Cieworkingasaprogrammer,headofqualityandfinallyas a manager in network control technology. In 1987, Frühauf founded INFOGEM AG with HelmutSandmayr, and the company has since gained a reputation as one of the leading system engineeringconsultingandtrainingaddressesinSwitzerland.HeisanhonorarymemberofSAQ,theSwissAssociationforQuality andwas instrumental in the launchof the “Brückenwächter” (“BridgeGuard”) residence forartistsandscientistsinŠtúrovo,Slovakia.

EmmerichFuchs

FUCHS-INFORMATIKAG

Emmerich Fuchs has over 30 years of experience in application development. Since 1985, he has beenworkingasa lectureratschoolsofhighereducationandasaseminar instructoraswellasaco-authorofmanybooksandanexaminationexpert.In1989,hefoundedtheFUCHS-INFORMATIKAGandisnowworking as a consulting business manager for renowned companies in the areas of business processmodeling,requirementsengineering,andqualityassurance.

Prof.Dr.MartinGlinzUniversityofZurich

MartinGlinzisafullprofessorofcomputerscienceandleadstheresearchunitRequirementsEngineeringat the University of Zurich. He is mainly interested in methods, languages and tools for requirementmodeling.Hisadditionalfieldsofinterestincludesoftwareengineering,softwarequality,andmodeling.Heobtained his doctoral degree from RWTH Aachen in computer science. Before he accepted the call toZurich,heworkedforover10yearsintheindustryasaresearcher,developer,consultant,andlecturerinthefieldofsoftwareengineering.HeisamemberoftheboardofpublishersofRequirementsEngineeringandamember of the InternationalRequirements EngineeringBoard (IREB).Hewas chairman of the steeringcommitteefortheInternationalRequirementsEngineeringConferencefrom2007–2009.

RainerGrau

DigitecGalaxus

RainerGrau isHeadofBusinessDevelopment atDigitec/Galaxus,oneofSwitzerland’s topeCommercecompanies. He and his team are responsible for innovation and portfolio management as well as theimplementationof all the company’s strategicprojects.Before joiningDigitec/Galaxushewasadirectorand partner at Zühlke Engineering, where he was in charge of agility, lean management, requirementsengineeringandproductmanagement.

RainerGrau holds various teaching posts at Swiss universities and is actively involved in SAQ, theSwissAssociationforQuality.HeisafoundermemberoftheSwissAgileLeadersCirclewherehesupportscommunitymembersintheirrequirementsengineering,enterpriseagilityandleanmanagementactivities.

RainerGraulikestospendhisfreetimewithhisfamily,onhisbicycle,windsurfing,rockclimbingorreadingthelatestnovelsbyT.C.BoyleandHarukiMurakami.

ColinHoodColinHoodSystemsEngineeringLtd.

Startingoutin1977,ColinHoodhasaccompaniedtheevolutionofcontrolsystemsfromtheirbeginningsinrelay-basedsystemsthroughprogrammablelogiccontrollers(PLCs)tomodernsoftware-controlledsafety-critical systems.Hisvarious jobshave includedanalysis,design, implementation, testinganddeliveryofcomplex software systems. Requirements engineering has always been the foundation of his success atcompaniessuchasAlcatel,BMW,DaimlerChrysler,HellaandMiele.Aswellascontinuallyimprovingtheprocessesinvolved,hespecializesinintroducingnewmethodsandtoolsthatsupporttheprocessofchange.

Dr.FrankHoudekDaimlerAG

FrankHoudekgraduatedinComputerScienceat theUniversityofUlmandjoinedtheDaimlerResearchCentrein1995.AftercompletinghisPhDinempiricalsoftwareengineeringin1999hebeganworkinginrequirements engineering and has headed various research and technology transfer projects within theDaimler passenger car and commercial vehicles business units. Since 2013 he has been responsible forcoordinating the requirements engineering activities for all electric/electronic specifications inMercedes-Benzpassengercardevelopment.

Dr. Houdek is a member of GI (German Interest Group on Computer Science) and IEEE CS, andbelongstothesteeringcommitteeoftheGIGroup2.1.6(RequirementsEngineering).HeisalsoinvolvedintheorganizationalandprogramcommitteesforrequirementsengineeringeventssuchasRE,REFSQ,andICSE.

HeisresponsiblefortheRequirementsEngineeringmoduleoftheSoftwareEngineeringforEmbeddedSystemscourseattheTechnicalUniversityatKaiserslautern.

Dr.PeterHruschkaAtlanticSystemsGuild

PeterHruschkahasbeenworkingasanindependentITandmanagementconsultantsince1994.Hismissionis thepractical implementationofnew ideas insoftwareengineering.Thiscomprises theentirespectrumfrom analysis of the initial situation via the creation of strategic plans to introductory training for every(structuredorobject-oriented)methodandprocess toguarantee success.Dr.Hruschka isprincipalof theAtlanticSystemsGuild,aninternationallyrenownedgroupofexpertsonsoftwaretechnology,andfounderoftheGermannetworkofagiledevelopers.

Prof.Dr.BarbaraPaechUniversityofHeidelberg

BarbaraPaechisaprofessorwiththeInstituteforComputerScienceoftheUniversityofHeidelberg.UntilOctober 2003, she was a department leader with the Fraunhofer Institute for Experimental SoftwareEngineering.Herareaofresearchissoftwareengineering,especiallythemethodsandprocessesnecessarytoimprovequalitywithappropriateeffort.Formanyyears,shehasbeenactiveintheareaofrequirementsengineeringandusabilityengineering.Paechandhergrouphaveimplementedmanynational,internationalandindustrialresearchandtechnologytransferprojects.SheisamemberoftheInternationalRequirementsEngineeringBoard(IREB).

DirkSchüpferlingSOPHISTGmbH

I am a SOPHIST since 2001 and the past years have led me to the conclusion that, in most cases,communicationis thekeyto(customer)satisfaction.Whatsurprisedmewasthatfeatureslikelazinessorbeingaknow-it-allcan—appliedcorrectly—leadtosomethingpositive.Thespecialistcallsthis“reuse”or“identifyingpotentialforimprovement”.ItransmitthisknowledgeasaclassicRequirements-Engineer,aswellasinagilecontexts(e.g.,asProductOwner)invariousprojects.Myjobistosupporttheprojectteamintheconceptionorapplicationofnewmethods.

ThorstenWeyerUniversityofDuisburg-Essen

ThorstenWeyerisaresearchgroupleaderattheUniversityofDuisburg-EssenandHeadofRequirementsEngineering and Conceptual Design at “paluno – The Ruhr Institute for Software Technology” at theUniversity ofDuisburg-Essen.He hasworked formore than a decade as a researcher and consultant inrequirements engineering, systems analysis, variability management, and model-based softwareengineering. He is a member of the organizational and program committees for various scientificconferences and also contributes his expertise to research funding projects and international tradepublications.ThorstenWeyerisamemberoftheInternationalRequirementsEngineeringBoard(IREB)andco-publisheroftheRequirementsEngineeringMagazine.

Contents

Foreword

WithContributionsfrom

1IntroductionandFoundations

1.1Introduction

1.1.1FiguresandFactsfromOrdinaryProjects

1.1.2RequirementsEngineering–WhatIsIt?

1.1.3EmbeddingRequirementsEngineeringintoProcessModels

1.2FundamentalsofCommunicationTheory

1.3CharacteristicsofaRequirementsEngineer

1.4RequirementTypes

1.5ImportanceandCategorizationofQualityRequirements

1.6Summary

2SystemandContextBoundaries

2.1SystemContext

2.2DefiningSystemandContextBoundaries

2.2.1DefiningtheSystemBoundary

2.2.2DefiningtheContextBoundary

2.3DocumentingtheSystemContext

2.4Summary

3ElicitingRequirements

3.1RequirementsSources

3.1.1StakeholdersandTheirSignificance

3.1.2HandlingStakeholdersintheProject

3.2RequirementsCategorizationAccordingtotheKanoModel

3.3ElicitationTechniques

3.3.1TypesofElicitationTechniques

3.3.2SurveyTechniques

3.3.3CreativityTechniques

3.3.4Document-centricTechniques

3.3.5ObservationTechniques

3.3.6SupportTechniques

3.4Summary

4DocumentingRequirements

4.1DocumentDesign

4.2TypesofDocumentation

4.2.1TheThreePerspectivesofRequirements

4.2.2RequirementsDocumentationusingNaturalLanguage

4.2.3RequirementsDocumentationusingConceptualModels

4.2.4HybridRequirementsDocuments

4.3DocumentStructures

4.3.1StandardizedDocumentStructures

4.3.2CustomizedStandardContents

4.4UsingRequirementsDocuments

4.5QualityCriteriaforRequirementsDocuments

4.5.1UnambiguityandConsistency

4.5.2ClearStructure

4.5.3ModifiabilityandExtendibility

4.5.4Completeness

4.5.5Traceability

4.6QualityCriteriaforRequirements

4.7Glossary

4.8Summary

5DocumentingRequirementsinNaturalLanguage

5.1EffectsofNaturalLanguage

5.1.1Nominalization

5.1.2NounswithoutReferenceIndex

5.1.3UniversalQuantifiers

5.1.4IncompletelySpecifiedConditions

5.1.5IncompletelySpecifiedProcessVerbs

5.2RequirementConstructionusingTemplates

5.3Summary

6Model-BasedRequirementsDocumentation

6.1TheTermModel

6.1.1PropertiesofModels

6.1.2ModelingLanguages

6.1.3RequirementsModels

6.1.4AdvantagesofRequirementsModels

6.1.5CombinedUseofModelsandNaturalLanguage

6.2GoalModels

6.2.1GoalDocumentationUsingAND/ORTrees

6.2.2ExampleofAND/ORTrees

6.3UseCases

6.3.1UMLUseCaseDiagrams

6.3.2UseCaseSpecifications

6.4ThreePerspectivesontheRequirements

6.5RequirementsModelingintheDataPerspective

6.5.1Entity-RelationshipDiagrams

6.5.2UMLClassDiagrams

6.6RequirementsModelingintheFunctionalPerspective

6.6.1DataFlowDiagrams

6.6.2ModelsoftheFunctionalPerspectiveandControlFlow

6.6.3UMLActivityDiagrams

6.7RequirementsModelingintheBehavioralPerspective

6.7.1Statecharts

6.7.2UMLStateDiagrams

6.8Summary

7RequirementsValidationandNegotiation

7.1FundamentalsofRequirementsValidation

7.2FundamentalsofRequirementsNegotiation

7.3QualityAspectsofRequirements

7.3.1QualityAspect“Content”

7.3.2QualityAspect“Documentation”

7.3.3QualityAspect“Agreement”

7.4PrinciplesofRequirementsValidation

7.4.1Principle1:InvolvementoftheCorrectStakeholders

7.4.2Principle2:SeparatingtheIdentificationandtheCorrectionof

Errors

7.4.3Principle3:ValidationfromDifferentViews

7.4.4Principle4:AdequateChangeofDocumentationType

7.4.5Principle5:ConstructionofDevelopmentArtifacts

7.4.6Principle6:RepeatedValidation

7.5RequirementsValidationTechniques

7.5.1Commenting

7.5.2Inspection

7.5.3Walk-Through

7.5.4Perspective-BasedReading

7.5.5ValidationthroughPrototypes

7.5.6UsingChecklistsforValidation

7.6RequirementsNegotiation

7.6.1ConflictIdentification

7.6.2ConflictAnalysis

7.6.3ConflictResolution

7.6.4DocumentationoftheConflictResolution

7.7Summary

8RequirementsManagement

8.1AssigningAttributestoRequirements

8.1.1AttributesforNaturalLanguageRequirementsandModels

8.1.2AttributeScheme

8.1.3AttributeTypesofRequirements

8.2ViewsonRequirements

8.2.1SelectiveViewsontheRequirements

8.2.2CondensedViewsontheRequirements

8.3PrioritizingRequirements

8.3.1MethodforRequirementsPrioritization

8.3.2TechniquesforRequirementsPrioritization

8.4TraceabilityofRequirements

8.4.1AdvantagesofTraceableRequirements

8.4.2Purpose-DrivenDefinitionofTraceability

8.4.3ClassificationofTraceabilityRelations

8.4.4RepresentationofRequirementsTraceability

8.5VersioningofRequirements

8.5.1RequirementsVersions

8.5.2RequirementsConfigurations

8.5.3RequirementsBaselines

8.6ManagementofRequirementsChanges

8.6.1RequirementsChanges

8.6.2TheChangeControlBoard

8.6.3TheChangeRequest

8.6.4ClassificationofIncomingChangeRequests

8.6.5BasicMethodforCorrectiveandAdaptiveChanges

8.7MeasurementofRequirements

8.7.1Productvs.ProcessMetric

8.7.2ExamplesofProductandProcessMetrics

8.8Summary

9ToolSupport

9.1GeneralToolSupport

9.2ModelingTools

9.3RequirementsManagementTools

9.3.1SpecializedToolsforRequirementsManagement

9.3.2StandardOfficeApplications

9.4IntroducingTools

9.5EvaluatingTools

9.5.1ProjectView

9.5.2UserView

9.5.3ProductView

9.5.4ProcessView

9.5.5ProviderView

9.5.6TechnicalView

9.5.7EconomicView

9.6Summary

References

The glossary of those terms used in this book (IREB-Glossary) can be found on the website of the“InternationalRequiremensEngineeringBoarde.V.”

www.ireb.org/en

1IntroductionandFoundations

The impact of requirements engineering (RE) on successful and customer-orientedsystemsdevelopmentcannolongerbeignored.Ithasbecomecommonpracticetoprovideresourcesforrequirementsengineering.Inaddition,thereisagrowingunderstanding that the roleof the requirementsengineer isessentiallyself-containedandcomprisesaseriesofdemandingactivities.

1.1Introduction

Whyperformrequirementsengineering?

AccordingtothefiguresreportedintheStandishGroup’sChaosReportof2006,much has improved in the execution of software projects in the twelve yearsbetween 1994 and 2006. While about 30 percent of the software projectsinvestigated in 1994 failed, itwas amere 20 percent in 2006.The number ofprojects that exceeded time or budget constraints significantly and/or did notmeetcustomersatisfactiondroppedfrom53percentto46percent[Chaos2006].Jim Johnson, chairperson of the Standish Group, names three reasons for thepositivedevelopmentof thefiguressince1994.Oneis that thecommunicationof requirements hasmuch improved since ten years ago. These figures are ofimportancesincehowtherequirementsofasystemarehandledisasignificantcauseforprojectfailuresand/ortimeandbudgetoverruns.

1.1.1FiguresandFactsfromOrdinaryProjects

Requirementsengineeringasacauseoferrors

According to past studies, approximately 60 percent of all errors in systemdevelopment projects originate during the phase of requirements engineering[Boehm1981].Theseerrors,however,areoftendiscoveredonlyinlaterprojectphases or once the systemhas been deployed because incorrect or incompleterequirements can be interpreted by developers in such a fashion that they aresubjectively sound or (subconsciously) complete. Missing requirements oftenremain undetected during design and realization because developers trust therequirements engineers to deliver high-quality work. Developers implementwhatever therequirementsdocumentsaysorwhat theybelieve it tobesaying.Unclear,incomplete,orwrongrequirementsinevitablyleadtothedevelopmentofasystemthatdoesnotpossesscriticalpropertiesorpossessespropertiesthatwerenotrequested.

Costsoferrorsduringrequirementsengineering

The later in the development project a defect in the requirements iscorrected, the higher are the costs associated with fixing it. For instance, theeffort to fix a requirementsdefect is up to20 timeshigher if the correction isdone during programming as opposed to fixing the same defect duringrequirements engineering. If the defect is fixed during acceptance testing, theeffortinvolvedmaybeuptoa100timeshigher[Boehm1981].

Symptomsandcausesofdeficientrequirementsengineering

Symptomsforinadequaterequirementsengineeringareasnumerousastheircauses. Frequently, requirements are missing or not clearly formulated. Forinstance, if the requirementsdonot reflect customerwishespreciselyor if therequirements are described in an imprecise way and thus allow for severalinterpretations,theresultisoftenasystemthatdoesnotmeettheexpectationsoftheclientortheusers.

Themostcommonreasonfordeficientrequirementsisthemisconceptionofthe stakeholders that much is self-evident and does not need to be statedexplicitly.Thisresultsinproblemsincommunicationamongtheinvolvedpartiesthatarisefromdifferencesinexperienceandknowledge.Tomakemattersworse,itisoftenthecasethatespeciallytheclientwishesforquickintegrationofrecentresultsintoaproductivesystem.

Thesignificanceofgoodrequirementsengineering

The increasing importance of software-intensive systems in industrialprojectsaswellastheneedtobringmoreinnovative,moreindividual,andmorecomprehensivesystemstomarketandtheneedtodosoquicker,better,andwithahigher levelofqualitycalls forefficient requirementsengineering.Completerequirementsfreefromdefectsarethebasisforsuccessfulsystemdevelopment.Potential riskshave tobe identifiedduring requirements engineeringandmustbe reducedasearlyaspossible toallowfor successfulprojectprogress.Faultsandgapsinrequirementdocumentsmustbediscoveredearlyontoavoidtediouschangeprocesses.

1.1.2RequirementsEngineering–WhatIsIt?

In order to make a development project succeed, it is necessary to know therequirementsforthesystemandtodocumenttheminasuitablemanner.

Definition1-1:Requirement

(1) A condition or capability needed by a user to solve a problem orachieveanobjective.

(2)Aconditionorcapabilitythatmustbemetorpossessedbyasystemorsystemcomponenttosatisfyacontract,standard,specification,orotherformallyimposeddocuments.

(3)Adocumentedrepresentationofaconditionorcapabilityasin(1)or(2).

[IEEE610.12-1990]

Stakeholders

The term stakeholder is essential in requirements engineering. Among otherthings, stakeholders are the most important sources of requirements. Notconsideringastakeholderoftenresultsinfragmentallyelicitedrequirements,i.e.,incomplete requirements [Macaulay 1993]. Stakeholders are those people ororganizationsthathavesomeimpactontherequirements.Thiscouldbepeoplethataregoingtointeractwiththesystem(e.g.,usersoradministrators),peoplethat have a mere interest in the system but are not likely to use it (e.g., the

management,ahackerfromwhichthesystemmustbeprotected,stakeholdersofcompeting systems), but also legal entities, institutions, etc., because these areembodied by living people who may choose to influence or define therequirementsofthesystem.

Definition1-2:StakeholderAstakeholderofasystemisapersonoranorganizationthathasan(directorindirect)influenceontherequirementsofthesystem.

Goalofrequirementsengineering

During the development process, requirements engineering must elicit thestakeholders’ requirements, document the requirements in a suitable manner,validate and verify the requirements, and manage the requirements over thecourseoftheentirelifecycleofthesystem[Pohl1996].

Definition1-3:RequirementsEngineering

(1)Requirementsengineeringisasystematicanddisciplinedapproachtothe specification and management of requirements with thefollowinggoals:

(1.1) Knowing the relevant requirements, achieving a consensusamong the stakeholders about these requirements,documenting them according to given standards, andmanagingthemsystematically

(1.2)Understanding anddocumenting the stakeholders’ desires andneeds, they specifying and managing requirements tominimizetheriskofdeliveringasystemthatdoesnotmeetthestakeholders’desiresandneeds

Fourcoreactivitiesofrequirementsengineering

Thefourcoreactivitiestomeettheseendsareasfollows:

Elicitation:Duringrequirementselicitation,differenttechniquesareusedto

obtain requirements fromstakeholdersandothersourcesand to refine therequirementsingreaterdetail.Documentation: During documentation, the elicited requirements aredescribed adequately. Different techniques are used to document therequirementsbyusingnaturallanguageorconceptualmodels(seechapters4,5,and6).Validationandnegotiation:Inordertoguaranteethatthepredefinedqualitycriteriaaremet,documentedrequirementsmustbevalidatedandnegotiatedearlyon(seechapter7).Management: Requirements management is orthogonal to all otheractivities and comprises any measures that are necessary to structurerequirements,topreparethemsothattheycanbeusedbydifferentroles,tomaintainconsistencyafterchanges,andtoensuretheirimplementation(seechapter8).

These core activities can be applied for different levels of requirementsabstraction, like stakeholder requirements, system requirements, and softwarerequirements. Their execution can follow different processes, such as theprocessesrecommendedin[ISO/IEC/IEEE29148:2011].

Constraints

Different project constraints influence requirements engineering. Forinstance, people, domain factors, or organizational constraints (e.g., spatialdistributionortemporalavailabilityofprojectmembers)havealargeimpactonthechoiceofsuitabletechniques.

1.1.3EmbeddingRequirementsEngineeringintoProcessModels

Requirementsengineeringasaself-containedphase

Ponderous process models (e.g., theWaterfall model [Royce 1987] or the V-Model [V-Modell 2004]) aim at completely eliciting and documenting allrequirementsinanearlyprojectphasebeforeanydesignorrealizationdecisionsaremade.Thegoalofsuchmodelsistoelicitallrequirementspriortotheactualdevelopment.Asaresult, in theseprocessmodels, requirementsengineering isunderstoodtobeafinite,time-restrictedinitialphaseofsystemdevelopment.

Requirementsengineeringasacontinuous,collateralprocess

Lightweightprocessmodels (e.g., eXtremeProgramming [Beck1999]), ontheotherhand,onlyelicitnecessaryrequirementsoncetheyaresupposedtobeimplementedas“foretelling”futurefunctionalities isdifficultandrequirementschange over the course of the project. In these process models, requirementsengineering is treated as a continuous, comprehensive process that comprisesandintegratesallphasesofsystemdevelopment.

1.2FundamentalsofCommunicationTheory

Languageasamediumforrequirementcommunication

Requirements must be communicated. In most cases, one uses a rule-drivenmediumthatisaccessibletothecommunicationpartner—naturallanguage.

Forthetransmissionofinformationfromoneindividualtoanothertoworkproperly, a common code is needed.The sender encodes hermessage and thereceiverhastodecodeit.Suchacommoncodeisintrinsictoanytwopeoplethatspeakthesamelanguage(e.g.,German),havethesameculturalbackground,andhave similar experiences. The more similar the cultural and educationalbackground, the area of expertise, and the everyday work life, the better theexchangeof informationworks.However, such ideal conditionsmostoftendonotexistbetweenstakeholders.Itisthereforesensibletoagreeuponacommonlanguageandhowthiscommonlanguageistobeused.Thiscan,forinstance,beachievedbymeansofglossaries(seechapter4),inwhichallimportanttermsareexplained.Alternatively,thiscanbedonebyagreeinguponaformaldescriptivelanguage,e.g.,OMG’sUnifiedModelingLanguage,UML(seechapter6).

Typeofcommunicationmedium

Another important factor is the type of communicationmedium. In verbalcommunication,thesuccessofthecommunicationreliesheavilyonredundancy(e.g.,languageandgesturesorlanguageandintonation)andfeedback.Inwrittentechnical communication, for example, information is transmitted with aminimumofredundancyandfeedback.

Languagecomfort

Inaddition to theproblemsarisingfromdifferingdomainvocabulariesanddifferentcommunicationmedia,itcanoftenbeobservedthatinformationisnotadequately transmitted or not transmitted at all. This can be traced back tonatural transformations that occur during human perception. Thesetransformational effects are, in particular, focusing and simplification and canimpactthecommunicationmoreorlessharshly.

Implicitbackgroundknowledge

Communication—i.e., the language-based expression of knowledge—isnecessarily simplifying in nature. The author expects the reader to have somekindofimplicitbackgroundknowledge.Itisthesimplificationsthatarisefromlanguage-based knowledge expression that become problematicwith regard torequirements, as requirements can become interpretable in different ways. Inchapter 5, natural language-based requirement documentation is discussed infurtherdetail.

1.3CharacteristicsofaRequirementsEngineer

Centralrole

The requirements engineer as a project role is often at the center of attention.Sheisusuallytheonlyonewhohasdirectcontactwiththestakeholdersandhasboththeabilityandtheresponsibilitytobecomeasfamiliaraspossiblewiththedomainandtounderstanditaswellaspossible.Sheistheonethatidentifiestheneeds underlying the stakeholders’ statements and amends them in away thatarchitects and developers—usually laymen where the domain in question isconcerned—canunderstandandimplementthem.Therequirementsengineeris,inamannerofspeaking,atranslatorthatunderstandsthedomainaswellasitsparticularlanguagewellenoughandalsopossessesenoughITknow-howtobeawareoftheproblemsthedevelopersfaceandtobeabletocommunicatewiththemonthesamelevel.Therequirementsengineerthereforehasacentralroleintheproject.

Sevennecessarycapabilitiesofarequirementsengineer

Tobeable to fulfillallofher tasks, therequirementsengineerneedsmuch

morethanprocessknowledge.Manyofthecapabilitiesrequiredmustbebasedonpracticalexperience.

Analytic thinking: The requirements engineer must be able to becomefamiliar with domains that are unknown to her andmust understand andanalyze complicated problems and relationships. Since stakeholders oftendiscuss problematic requirements by means of concrete examples and(suboptimal) solutions, the requirementsengineermustbeable toabstractfromtheconcretestatementsofthestakeholder.Empathy:Therequirementsengineerhasthechallengingtaskofidentifyingtheactualneedsofastakeholder.Acorerequirementtobeabletoachievethisistohavegoodintuitionandempathyforpeople.Inaddition,shemustidentify problems that might arise in a group of stakeholders and actaccordingly.Communicationskills:Toelicit therequirementsfromstakeholdersandtointerpret them correctly and communicate them in a suitable manner, arequirementsengineermusthavegoodcommunicationskills.Shemustbeable to listen, ask the right questions at the right time, notice when astatement does not contain the desired information, and make furtherinquirieswhennecessary.Conflict resolution skills:Different opinions of different stakeholders canbethecauseofconflictsduringrequirementsengineering.Therequirementsengineermustidentifyconflicts,mediatebetweenthepartiesinvolved,andapplytechniquessuitabletoresolvingtheconflict.Moderation skills: The requirements engineer must be able to mediatebetween different opinions and lead discussions. This holds true forindividualconversationsaswellasgroupconversationsandworkshops.Self-confidence:Sincetherequirementsengineerisfrequentlyatthecenterof attention, sheoccasionally is exposed to criticismaswell.As a result,sheneedsahigh levelofself-confidenceand theability todefendherselfshould strong objections to her opinions arise. She should never takecriticismpersonally.Persuasiveness: Among other things, the requirements engineer is, in amatter of speaking, a kind of attorney for the requirements of thestakeholders. She must be able to represent the requirements in teammeetings and presentations. In addition, she must consolidate differingopinions, facilitate a decision in case of a disagreement, and createconsensusamongthestakeholders.

1.4RequirementTypes

Generally,onecandistinguishbetweenthreetypesofrequirements:

Functional requirements define the functionality that the system to bedeveloped offers. Usually, these requirements are divided into functionalrequirements,behavioral requirements,anddata requirements (seechapter4).

Definition1-4:FunctionalRequirementAfunctionalrequirement isarequirementconcerningaresultofbehavior thatshallbeprovidedbyafunctionofthesystem.

Qualityrequirementsdefinedesiredqualitiesofthesystemtobedevelopedand often influence the system architecture more than functionalrequirementsdo.Typically,qualityrequirementsareabouttheperformance,availability, dependability, scalability, or portability of a system.Requirements of this type are frequently classified as non-functionalrequirements.

Definition1-5:QualityRequirementA quality requirement is a requirement that pertains to a quality concern that is not covered byfunctionalrequirements.

Constraints cannot be influenced by the teammembers.Requirements ofthis type can constrain the system itself (e.g., “The system shall beimplemented using web services”) or the development process (“Thesystemshallbeavailableonthemarketnolaterthanthesecondquarterof2012”). In contrast to functional andquality requirements, constraints arenotimplemented,theyareadheredtobecausetheymerelylimitthesolutionspaceavailableduringthedevelopmentprocess.

Definition1-6:ConstraintAconstraint isa requirement that limits thesolutionspacebeyondwhat isnecessary formeeting thegivenfunctionalrequirementsandqualityrequirements.

In addition to the classification into functional requirements, qualityrequirements, and constraints, a number of different classifications ofrequirements are used in practice. For example, there are a number ofclassificationssuggestedbyseveralstandards,e.g.,CMMI[SEI2006]orSPICE[ISO/IEC 15504-5]. Other classification schemes describe requirementattributes,suchasthelevelofdetailofarequirement,thepriority,orthedegreeoflegalobligationofrequirements(seechapters4and8).

1.5ImportanceandCategorizationofQualityRequirements

In daily practice, quality requirements of a system are often not documented,inadequately documented, or improperly negotiated. Such circumstances canthreatentheproject’ssuccessorthesubsequentacceptanceofthesystemunderdevelopment. Therefore, the requirements engineer should place specialemphasis on the elicitation, documentation, and negotiation of qualityrequirementsduringthedevelopmentprocess.

Typically, many different kinds of desired qualities of the system areassignedtotherequirementtypequalityrequirement.Inordertobeabletodealwithquality requirements in a structuredmanner,manydifferent classificationschemesforqualityrequirementshavebeenproposed.TheISO/IEC25010:2011standard [ISO/IEC25010:2011], for example, suggests a classification schemefor quality requirements that can also be used as a standard structure forrequirementsdocumentationandasachecklist for requirementselicitationandvalidation. Among others, the following categories are typical for qualityrequirements(see[ISO/IEC25010:2011]):

Requirements that define the performance of the system, in particularresponsetimebehaviorandresourceutilizationRequirements that define the security of the system, in particular withregardtoaccountability,authenticity,confidentiality,andintegrityRequirementsthatdefinethereliabilityoffunctionalities,inparticularwithregardtoavailability,faulttolerance,andrecoverabilityRequirementsthatdefinetheusabilityofasystem,inparticularwithregardtoaccessibility,learnability,andeaseofuseRequirementsthatdefinethemaintainabilityofasystem,inparticularwithregardtoreusability,analyzability,changeability,andtestabilityRequirements that define the portability of a system, in particular with

regardtoadaptability,installability,andreplaceability

Currently, quality requirements are often specified using natural language.However,numerousapproachestodocumentqualityrequirementsbymeansofmodelshavebeensuggestedoverthepastcoupleofyears.

The requirements engineer is responsible for making sure the qualityrequirements are as objective and verifiable as possible. Typically, thisnecessitatesthatthequalityrequirementsarequantified.Forexample,aqualityrequirementwithregardtosystemperformancecouldspecifythatasystemshallprocess 95 percent of all querieswithin 1.5 seconds and that itmust not takelonger than 4 seconds to process queries at any given time. This can causequality requirements to be refined by means of additional functionalrequirements.Thiscouldbethecaseforaqualityrequirementthatisconcernedwith systemsecurity if a functional requirement specifies the exact encryptionalgorithm to satisfy the need for encryption as demanded by some qualityrequirement.

Quality requirements are often related to different functional requirements.As a result, quality requirements should always be kept separated fromfunctional requirements. In other words, quality requirements should not bemixedwithfunctionalrequirementsandshouldbedocumentedseparately,withexplicitdocumentationoftheirrelationtofunctionalrequirements.

1.6Summary

Requirementsengineeringcanhardlybeavoided,especiallywhensystemsaretobedevelopedthatsatisfycustomersandmeetbudgetconstraintsandschedules.Thegoalofrequirementsengineeringistodocumentcustomerrequirementsascompletelyaspossible ingoodqualityand to identifyandresolveproblems inthe requirements as early as possible. Successful requirements engineering isbased on including the right stakeholders as well as embedding the four coreactivities of requirements engineering (elicitation, documentation, validationandnegotiation,andmanagement)intothesystemdevelopmentprocess.Atthecenterofattentionistherequirementsengineer,whoistheprimarycontactpointin requirements engineering and possesses a great deal of domain knowledgeandprocessknowledgeaswellasamultitudeofsoftskills.

2SystemandContextBoundaries

Therequirementsforasystemtobedevelopeddonotsimplyexist,theyhavetobe elicited. The purpose of defining the system and context boundaries inrequirements engineering is to identify the part of the environment thatinfluencestherequirementsforthesystemtobedeveloped.

2.1SystemContext

Anticipatethesysteminoperation

In the development process, requirements engineering fulfils the task ofidentifyingall thosematerialandimmaterialaspectsthathavearelationshiptothesystem.Inordertodothat,itisanticipatedwhatthesystemwillbelikeonceitbecomesreal.Bydoingso,thosepartsoftherealworldwhichwillpotentiallyinfluencetherequirementsofthesystemcanbeidentified.Tobeabletospecifytherequirementsforasystemcorrectlyandcompletely,itisnecessarytoidentifytherelationshipsbetweenindividualmaterialandimmaterialaspectsaspreciselyaspossible.Thepartofrealitythatisrelevantfortherequirementsofasystemiscalledthesystemcontext.

Definition2-1:SystemContextThesystemcontextisthepartofthesystemenvironmentthatisrelevantforthedefinitionaswellastheunderstandingoftherequirementsofasystemtobedeveloped.

Contextaspectsinthesystemcontext

Amongothers,thefollowingpossibleaspectsofrealityinfluencethecontextof

asystem:

People(stakeholdersorgroupsofstakeholders)Systemsinoperation(othertechnicalsystemsorhardware)Processes(technicalorphysicalprocesses,businessprocesses)Events(technicalorphysical)Documents(e.g.,laws,standards,systemdocumentation)

Consequenceoferroneousorincompletecontextconsideration

If the system context is incorrectly or incompletely considered duringrequirementsengineering,itmayresultinincompleteorerroneousrequirements.This leads to the system operating on the basis of incomplete or erroneousrequirements,whichisoftenthereasonforsystemfailureduringoperation.Sucherrors often remain undetected during the validation procedures, whichdetermineifthesystemmeetsthespecifiedrequirements,andoccuronlyduringoperation,sometimesentailingcatastrophicconsequences.

Systemcontextandrequirementcontext

Theoriginofthesystem’srequirementslieswithinthecontextofthesystemto be developed. For example, stakeholders, pertinent standards, and legalguidelines demand particular functional properties that the system to bedevelopedmustpossessatitsinterfaces.Arequirementisthereforedefinedforaspecificcontextandcanonlybe interpretedcorrectly in regard to this specificcontext.Thebetter thecontextofarequirement isunderstood(e.g.,whyis thetechnicalsystem“X”inthesystemcontexttheoriginofsomerequirement),thelowerthelikelihoodof incorrect interpretationof therequirement.Therefore,apurpose-driven documentation of the system context or information about thesystemcontextisofparticularimportance.

2.2DefiningSystemandContextBoundaries

Itiswithintheresponsibilityoftherequirementsengineertodefinethesystemcontextproperly.Inordertodoso,itisnecessarytoseparatethesystemcontextfrom the system to be developed aswell as from the parts of reality that areirrelevantforthesystem(seefigure2-1):

Defining the system boundary: When defining the system boundary, adecision has to be made: Which aspects pertain to the system to bedevelopedandwhichaspectsbelonginthesystemcontext?Defining the context boundary:When defining the context boundary, thequestion to be answered is:Which aspects pertain to the system context(i.e.,havearelationtothesystemtobedeveloped)andwhichaspectsarepartoftheirrelevantenvironment?

Figure2-1Systemandcontextboundaryofasystem

Systemandcontextboundariesdefinethesystemcontext.

Thus, system and context boundaries define the system context. The systemcontext comprises all aspects that are relevantwith regard to the requirementsforthesystemtobedeveloped.Theseaspectscannotbealteredormodifiedbythesystemdevelopmentprocess.

2.2.1DefiningtheSystemBoundary

Thesystemboundaryseparatestheobjectofconcern(i.e., thesystem)fromitsenvironment. When the system boundary is defined, the scope of thedevelopment(i.e.,theaspectsthatarecoveredbythesystemtobedeveloped)aswellastheaspectsthatarenotpartofthesystemaredetermined.Wethereforedefinethesystemboundaryasfollows:

Definition2-2:SystemBoundaryThesystemboundaryseparatesthesystemtobedevelopedfromitsenvironment;i.e., itseparatesthepart of the reality that can be modified or altered by the development process from aspects of theenvironmentthatcannotbechangedormodifiedbythedevelopmentprocess.

All aspects that are within the system boundary can thus be altered duringsystemdevelopment.Forinstance,anexistingsystemthatconsistsofhardwareandsoftwarecomponentsandissupposedtobereplacedbythenewsystemcanbe within the system boundary. Aspects within the system context can bebusiness processes, technical processes, people and roles, organizationalstructures, and components of the IT infrastructure. Figure 2-2 schematicallyshows the system context of a system. The system context consists of othersystems, groups of stakeholders that in some way use the interfaces of thesystem to be developed, and additional requirements sources and theirinterrelations.

Figure2-2Typesofaspectswithinthesystemcontext

Sourcesandsinksasthestartingpoint

Amongotherthings,sourcesandsinks(see,e.g.,[DeMarco1978])canbeusedto identify the interfaces thesystemhaswith itsenvironment.Sourcesprovideinputs for the system.Sinks receiveoutputs from the system.Possible sourcesandsinksofasystemareasfollows:

(Groupsof)stakeholdersExistingsystems(bothtechnicalandnontechnicalsystems)

Interfaces:interactionbetweensystemandenvironment

Sourcesandsinksinteractwiththesystemtobedevelopedviasysteminterfaces.

Usingtheseinterfaces,thesystemprovidesitsfunctionalitytotheenvironment,monitors the environment, influences parameters of the environment, andcontrolsoperationsoftheenvironment.Dependingonthetypeoftherespectivesourceorsink,thesystemneedsdifferentinterfacetypes(e.g.,human–machineinterface, hardware interface, or software interface).The interface type in turnmay also impose specific constraints or additional sources of requirements onthesystemtobedeveloped.

Grayzonebetweensystemandsystemcontext

Frequently,thesystemboundaryisnotpreciselydefineduntiltheendoftherequirementsengineeringprocess.Beforethat,someorseveralinterfacesaswellas desired functions and qualities of the system to be developed are onlypartiallyknownornotknownatall.Werefertothisinitiallyvagueseparationofthesystemanditscontextasthegrayzonebetweenthesystemandthecontext(see figure 2-3). At the beginning of the requirements engineering process, itmay, forexample,notbeclearwhether thesystemshould implementacertainfunction (e.g., “pay by credit card”) orwhether there is another system in thesystem context providing such a function that should be used (e.g., “paymentprocessing”).

Adjustingthegrayzone

Thesystemboundarymaynotonlyshiftwithinthegrayzone( infigure2-3) but also the gray zone itselfmay shift during the requirements engineeringprocess( infigure2-3).Thiskindofshiftingiscausedbythefactthataspects,pertaining at first to the system context, nowwill bemodified during systemdevelopment. Such a situation occurs during requirements engineering, forexample, if it is not clear in the systemcontextwhether certain activities of abusiness process should be implemented or supported by the system to bedeveloped or not. In this situation, it is not clearwhich aspects belong to thesystem and can thus be changed ormodified andwhich aspects belong to thesystem context. This causes a corresponding shift of the gray zone betweensystemandsystemcontext(seefigure2-3).

Figure2-3Grayzoneofthesystemboundary

Thegrayzoneshifts, for instance,when interfacesareattributed to thesystemboundaryandthegrayzoneisextendedtocompriseaspectsoftheenvironmentthatconcerntheseinterfaces.

2.2.2DefiningtheContextBoundary

Thecontextboundarydistinguishesbetweencontextaspects, i.e., thoseaspectsof the environment that need to be taken into account during requirementsengineering(e.g.,asrequirementssources)andthoseaspectsthatareirrelevantforthesystem.Thecontextboundarycanbedefinedasfollows:

Definition2-3:ContextBoundaryThecontextboundaryseparatestherelevantpartoftheenvironmentofasystemtobedevelopedfromtheirrelevantpart,i.e.,thepartthatdoesnotinfluencethesystemtobedevelopedand,thus,doesnothavetobeconsideredduringrequirementsengineering.

Concretionandshiftofthecontextboundary

Atthebeginningoftherequirementsengineeringprocess,frequentlyonlypartoftheenvironmentaswellassinglespecificrelationshipsbetweentheenvironmentand the system to be developed are known. In the course of requirementsengineering, it isnecessary toconcretize theboundarybetweensystemcontextandirrelevantenvironmentbyanalyzingrelevantaspectswithintheenvironmentwithregardtotheirrelationshipstothesystem.Besidesthesystemboundary,thecontext boundary typically also shifts during requirements engineering. For

instance, it may be possible that a law directive that was considered to berelevant for the system tobedevelopedno longer impacts the systemor isnolongerconsideredrelevant.Thesystemcontextisthereforereduced( infigure2-4). Ifanewlawdirective is identified that influences thesystem, thesystemcontextisextendedaccordingly( infigure2-4).

Figure2-4Grayzonebetweensystemcontextandirrelevantenvironment

Grayzonebetweensystemcontextandirrelevantenvironment

Since the context boundary separates the system context from those parts ofrealitythatareirrelevanttothesystem,acompleteandprecisedefinitionofthecontext boundary for complex systems is virtually impossible. In addition, itmaynotbepossibletoclarifyforsingleaspectsoftheenvironmentwhethertheyinfluencethesystemtobedevelopedorare influencedby itornot.These twoobservationsare the reason for theexistenceofagrayzonewith regard to thecontextboundary(seefigure2-4).

Resolvingandshiftingofthegrayzone

Thisgrayzonethereforecomprisesidentifiedaspectsoftheenvironmentforwhichitisunclearwhethertheyhavearelationtothesystemornot.Incontrastto the gray zone between the system and the system context that must beresolvedinthecourseofrequirementsengineering,itisnotnecessarytoresolvethe gray zone between the system context and the irrelevant environmententirely.

2.3DocumentingtheSystemContext

In order to document the system context (especially the system and contextboundaries),“usecase”diagrams[Jacobsonetal.1992](seesections4.2.3and6.3.1) or “data flow” diagrams [DeMarco 1978] (see section 6.6.1) are oftenused.Whenthecontextismodeledwithdataflowdiagrams,sourcesandsinksinthe environment of the system that represent the source or destination of dataflows (or flows of material, energy, money, etc.) are modeled. In use casediagrams, actors (such as people or other systems) in the system environmentand their usage relationships to the system aremodeled.Tomodel the systemcontext,UMLclassdiagrams[OMG2007](seesection6.5.2)mayalsobeused.Inordertodocumentthesystemcontextofasystemasthoroughlyaspossible,typicallyseveraldocumentationformsareused.

2.4Summary

The system context is the part of the reality that influences the system to bedevelopedandthusalsoinfluencestherequirementsforthesystem.Inordertobeabletoelicittherequirementsforthesystemtobedeveloped,itisnecessarytodefinetheboundaryofthesystemtothesystemcontextandtheboundaryofthe system context to the irrelevant environment first. When the systemboundaries are defined, the scope of the system is determined. The scopecomprises those aspects that can be changed and designed during systemdevelopment.At the same time, it is also definedwhich aspects belong to theenvironment and thus cannot be altered during development andmay provideconstraintsforthesystemtobedeveloped.

Thecontextboundaryseparates thepartof theenvironment that influencesthe requirements for the system to be developed from that part that does notinfluence the requirements. Typical aspects within the system context arestakeholders (e.g., theusersof thesystem)anddocuments (e.g., standards thathavetobeconsidered)aswellasothersystemsthat,for instance, interactwiththe system to be developed. Defining the system and context boundariessuccessfullyisthefoundationforasystematicelicitationofrequirementsforthesystemtobedeveloped.

3ElicitingRequirements

Acoreactivityofrequirementsengineeringistheelicitationofrequirementsforthe system to be developed. The basis for requirements elicitation is theknowledge that has been gained during requirements engineering about thesystemcontextofthesystemtobedeveloped,whichcomprisestherequirementssourcesthataretobeanalyzedandqueried.

3.1RequirementsSources

Threetypesofrequirementssources

Therearethreedifferentkindsofrequirementssources:

Stakeholders(seesection1.1.2)arepeopleororganizationsthat(directlyorindirectly) influence the requirements of a system. Examples ofstakeholders are users of the system,operators of the system,developers,architects,customers,andtesters.Documents often contain important information that can providerequirements. Examples of documents are universal documents, such asstandardsandlegaldocuments,aswellasdomain-ororganization-specificdocuments, such as requirements documents and error reports of legacysystems.Systems in operation can be legacy or predecessor systems as well ascompetingsystems.Bygiving thestakeholdersachance to try thesystemout, they can gain an impression of the current system and can requestextensionsorchangesbasedontheirimpressions.

3.1.1StakeholdersandTheirSignificance

Significanceofstakeholders

Identifying the relevant stakeholders is a central task of requirementsengineering [Glinz and Wieringa 2007]. For the requirements engineer,stakeholders are important sourcesof requirements for the system (see section1.1.2). It is the task of the requirements engineer to gather, document, andconsolidate the partially conflicting goals and requirements of differentstakeholders[Pottsetal.1994](seechapter8).

Consequencesofunconsideredstakeholders

If stakeholders are not identified or not considered, it may result insignificantnegativerepercussionsfortheprojectprogressbecauserequirementsmayremainundetected.At the latest, theseoverlookedrequirementswillenterthepictureintheformofchangerequestsduringsystemoperation.Fixingtheseissues retroactively causes high additional costs. Therefore, it is essential toidentifyallstakeholdersandintegratethemintotheelicitationprocedures.

Stakeholderlistsprovideoverview.

An auxiliary technique for stakeholder identification is maintainingchecklists. This allows for systematic and targeted elicitation of relevantstakeholders.Ifthestakeholderlistisupdatedtoolateorincompletely,theresultmaybethatimportantaspectsofthesystemremainundetected,thattheprojectgoal ismissed,or thatsignificantadditionalcostsarisefromfixingissues.Thestarting point for stakeholder elicitation is often suggestions of relevantstakeholdersthataremadebymanagementorbydomainexperts,forexample.Onthebasisofthesesuggestions,relevantstakeholderscanbeidentified.

3.1.2HandlingStakeholdersintheProject

Managingstakeholders

It can often be observed in practice that a lot of stakeholders are involved incomplexand“difficult”projects.Duetolimitedresources,thestakeholdersthat

arethemostsuitableforrequirementselicitationmustbecarefullyselected.Todocument the stakeholders in the development process, it makes sense to usetablesandspreadsheetsthatcontain(atleast)thefollowingdata:name,function(role), additional personal and contact data, temporal and spatial availabilityduring the project progress, relevance of the stakeholder, area and extent ofexpertiseofthestakeholder,andthestakeholder’sgoalsandinterestsregardingtheproject.

Makingcollaboratorsoutoftheaffected

Handling stakeholders also means continuously exchanging information:Periodicstatusupdatesandcontinuousinvolvementofthestakeholdersassisttherequirements engineer in turning people previously simply affected by theproject (i.e., principally affected stakeholders) into collaborators (i.e., well-integrated,jointlyresponsiblestakeholders).

Individual“contracts”withthestakeholders

Stakeholders that are not given enough attention by the requirementsengineer might be overly critical toward the project. In addition, somestakeholders may show a lack of motivation because they are sufficientlysatisfiedwith the legacysystem,areafraidofchange,orarenegativelybiaseddue to previous projects. It’s the requirements engineer’s task to support theprojectmanager inconvincingallstakeholdersof thebenefitof theproject.Toavoid misunderstandings and disputes regarding competence, it is useful toformallyagreeonthetasks,responsibilities,andmanagerialauthorityaswellastodetermineindividualgoals,communicationpaths,andfeedbackloopsthatcanbeusedbythestakeholders.Dependingonthecultureof theorganization, thisagreementanddeterminationcanbedoneverbally(i.e.,by“shakinghands”)or,more formally,bymeansofwrittendocumentation.The individualagreementsshouldbesignedoffbythemanagers.

Obligationsandprivilegesofthestakeholders

Anumberofobligations andprivileges result from the agreementwith thestakeholders.

Therequirementsengineer

speaksthelanguageofthestakeholders,becomesthoroughlyfamiliarwiththeapplicationdomain,createsarequirementsdocument,isabletogetworkresultsacross(e.g.,bymeansofdiagramsandgraphs),maintainsarespectfulrelationshipwithanystakeholder,presentsherideasandalternativesaswellastheirrealizations,allows stakeholders to demand properties that make the system user-friendlyandsimple,ensures that thesystemsatisfies thefunctionalandqualitativedemandsofthestakeholders.

Thestakeholders

introducetherequirementsengineertotheapplicationdomain,supplytherequirementsengineerwithrequirements,documentrequirementsassiduously,maketimelydecisions,respecttherequirementsengineer’sestimatesofcostsandfeasibility,prioritizerequirements,inspecttherequirementsthattherequirementsengineerdocuments,suchasprototypes,etc.,communicatechangesinrequirementsimmediately,adheretothepredeterminedchangeprocess,respecttherequirementsengineeringprocessthathasbeeninstated.

Elicitationtechniquesdeterminecommunicationandprocess.

In addition, the requirements engineer plans and organizes the communicationpaths aswell as drafts a structured schedule for the requirements engineeringactivities that are to be performed in collaborationwith the stakeholders.Thisorganizationandthetypeofcommunicationaresignificantlyinfluencedbytheelicitationtechniquesthatcanbeusedduringrequirementsengineering.

3.2RequirementsCategorizationAccordingtotheKanoModel

Influenceoftherequirementsonsatisfaction

Knowingtheimportanceofarequirementforthesatisfactionofthestakeholdersisveryhelpfulforrequirementselicitation.Alongwiththerespectivepropertiesofaproductthatdeterminethesatisfaction,thesatisfactionisclassifiedintothefollowingthreecategories[Kanoetal.1984]:

Dissatisfiersarepropertiesofthesystemthatareself-evidentandtakenforgranted(subconsciousknowledge).Satisfiers are explicitly demanded system properties (consciousknowledge).Delighters are system properties that the stakeholder does not know orexpect and discovers onlywhile using the system—apleasant and usefulsurprise(unconsciousknowledge).

As time goes by, delighters turn into satisfiers and dissatisfiers as the userbecomes accustomed to the properties of the system. When elicitingrequirements,allthreecategoriesmustbeconsidered.

Figure3-1GraphicalrepresentationoftheKanomodel

Dissatisfiers

Dissatisfiers(subconsciousrequirements)mustbefulfilledbythesysteminanycase.Otherwise,stakeholderswillbedisappointedanddissatisfied.Completelyfulfilled dissatisfiers do not generate a positive disposition butmerely help toavoid massive discontent. Dissatisfiers are dominantly influenced by existingsystems.Therefore,observationanddocument-centrictechniquesareespeciallywellsuitedfortheelicitationofthesefactors.

Satisfiers

Satisfiers(consciousrequirements)arepropertiesthatareconsciouslyknowntothestakeholdersandexplicitlydemanded.Whenthesepropertiesarefulfilled,stakeholders are content and satisfied, which is desirable. If some demandedproperties are missing, the stakeholders probably will not accept the product.Theirsatisfactiondecreaseswitheachmissingsatisfier.Satisfierscanbeelicited

wellusingsurveytechniques.

Delighters

Delighters (unconscious requirements) are properties of a system whosevalueisrecognizedonlywhenthestakeholdercantryoutthesystemforherselfor the requirements engineer proposes them. Creativity techniques are bestsuitedtoelicitdelighters.

3.3ElicitationTechniques

Requirementselicitation:nouniversalmethod

The main goal of all elicitation techniques is in supporting the requirementsengineer in ascertaining the knowledge and requirements of the stakeholders.How and when a technique can be applied depends on the given conditions.Applyingthetechniqueconsciouslyandinafashionappropriatetothesituationathandallowsfortailoringtherequirementselicitationprocesswhichtakesintoaccount project constraints so that requirementsmaybe elicited as completelyandcomprehensiblyaspossible.

3.3.1TypesofElicitationTechniques

Influencingfactorsregardingthechoiceofelicitationtechniques

Elicitation techniques serve the purpose of identifying the conscious,unconscious, and subconscious stakeholder requirements.However, there isnouniversalmethod to elicit these requirements [Hickey andDavis 2003].Everyproject has individual constraints and individual characteristics and is by andlargeunique,buttherearealwayselicitationtechniquesthatarecompatiblewiththe project. The most important influencing factors when choosing theappropriateelicitationtechniquesareasfollows:

the distinction between conscious, unconscious, and subconsciousrequirementsthataretobeelicitedthe time and budget constraints, as well as the availability of the

stakeholdersthe experience of the requirements engineer with a particular elicitationtechniquethechancesandrisksoftheproject

Riskfactors

The first important step when choosing a suitable elicitation technique is toperform an analysis of constraints critical to the project, i.e., identifying so-called risk factors. Mostly, these result from human, organizational, andprofessionalinfluences,asillustratedinthefollowingpassages.

Humaninfluences

Duringtherequirementselicitationphase,whichisheavilyinfluencedbythestakeholders, good communication is essential. In order to assure high-qualitycommunication between the requirements engineer and stakeholders, it isimportant todetermine the typeofrequirement, thedesired levelofdetail,andtheexperienceoftherequirementsengineerandtheintervieweeswithdifferentelicitationtechniques.

Social, group-dynamic, and cognitive capabilities of the stakeholders alsoinfluence the choice of suitable elicitation techniques significantly. Anotherinfluence factor is whether the elicited knowledge is explicit (consciouslyknown) by each individual stakeholder or if it is implicit or unconscious (i.e.,covert).

Organizationalinfluences

Organizationalriskfactorstheprojectfacesneedtobeinvestigatedaswell.Amongotherthings,thiscomprisesthedistinctionbetweenfixedpricecontractsandservicecontracts,whetherthesystemtobebuiltisanewdevelopmentoranextension of a legacy system, and spatial and temporal availability of thestakeholders.

Operationalinfluencesofthecontent

In addition, it is necessary to consider the operational content of therequirements. If the system is very complex, it is advisable to employ a

structuring approach during elicitation in order to deconstruct the operationalcontentsintounderstandableparts.

Combinetechniqueswithregardtoyourparticularsituationtolowerrisks.

Another influencing factor on the choice of elicitation techniques is thedesiredlevelofdetailoftherequirements.Abstractrequirementscanbeelicitedrather well using creativity techniques.With the stakeholders, a vision of thesystem or its important properties can be created or collected. Inquisitive(survey)techniquesorobservationaltechniquescanaidinelicitingrequirementsofamediumlevelofdetail[Robertson2002].Finelydetailedrequirementscanbeelicitedwellbymakinguseofdocument-centric techniques, i.e., techniquesthatuseexistingdocumentsbecauseinformationuptoanarbitrarylevelofdetailcanbeextractedfromthese.

Itisadvisabletocombinedifferenttechniquesbecausethisminimizesmanyof the risks inherent to the project. Weaknesses and pitfalls of a particulartechniquecanbebalancedoutthroughtheuseofanothertechniquewhosestrongpointsliewherethefirsttechniquemayhavedeficits.

3.3.2SurveyTechniques

Elicitingexplicitknowledge

Surveytechniquesaimatelicitingaspreciseandunbiasedstatementsaspossiblefrom stakeholders regarding their requirements. All survey techniques assumethattherespondentiscapableofexplicitlyexpressinghisorherknowledgeandthatheorsheiscommittedtoinvestingtimeandeffortfortheelicitation.Surveytechniquesareusuallydrivenbytherequirementsengineerbecausesheasksthequestions.This,however,might result in thefact thatstakeholderconcernsareforgotten,superseded,ordisregarded.

Interview

During an interview, the requirements engineer asks predeterminedquestions to one or more stakeholders and documents the answers.Questionsthatariseduringtheconversationcanbediscussedimmediately,

and the requirements engineer may uncover subconscious requirementsthrough clever questions. Interviews can be employed during the entiredevelopmentphaseofthesystem.Anexperiencedinterviewerindividuallycontrolsthecourseoftheconversation,completelycommitsherselftoeachstakeholder, inquires about specific aspects, and thus ensures thecompleteness of the answers. The most prominent disadvantage of thiselicitationtechniqueisthatitisverytime-consuming.

Questionnaire

Questionnaire:Makinguseofopenand/orclosedquestions(e.g.,multiplechoice questions) is another way of eliciting requirements fromstakeholders. If there are a large number of participants that must besurveyed, an online questionnaire is a viable option. Questionnaires canelicitamagnitudeofinformationinashortamountoftimeandatlowcosts.Aslongasanswersarepredetermined,evenstakeholders thatarenotableto explicitly express their knowledge can deliver an assessment. Adisadvantage of using a questionnaire is that it can be only employed togather requirements the requirements engineer already knows orconjectures. Creating a proper questionnaire is often tricky and time-consumingandrequiresthoroughknowledgeofthedomaininquestionandthe psychological guidelines for creating questionnaires. In addition, asopposed to interviews, questionnaires donot provide immediate feedbackbetween the surveyor and the surveyed, so it becomes apparent thatquestionswereforgottenorbadlyformulatedonlyoncethequestionnaireshavebeenevaluated.

3.3.3CreativityTechniques

Establishinginnovations

Creativity techniquesserve thepurposeofdevelopinginnovativerequirements,delineating an initial vision of the system, and eliciting excitement factors.Creativity techniques are usually not well suited for establishing fine-grainedrequirementsaboutthesystembehavior.Thefollowingcreativitytechniquesarecommonlyused[MaidenandGizikis2001]:Brainstorming

During brainstorming, ideas are collected within a certain time frame,usually in groups of 5 to 10 people. The ideas are documented by amoderator without discussing, judging, or commenting on them at first.Participantsuseideasofotherparticipantstodevelopneworiginalideasortomodifyexisting ideas.After that, thecollected ideas are subjected to athorough analysis. This technique is especially effective when a largenumberofpeopleofdifferentstakeholdergroupsareinvolved.Amongtheadvantagesofthistechniqueisthatalargenumberofideascanbecollectedin a short amount of time andmultiple people can expandon these ideascollaboratively.Theunbiasedcollectionoftheseideasallowsnewsolutionstopopup.Brainstormingisusuallylesseffectivewhenthedynamicsofthegroup are muddled or when participants with very varied levels ofdominance are involved. For such situations, other creativity techniquesmay be better suited, e.g., the 6-3-5method (six participants, three ideaseach, fivefold hand-off of the ideas) [Rohrbach 1969] or the brainwritingmethod.

Brainstormingparadox

Brainstormingparadox is amodification of regular brainstorming in thatevents that must not occur are collected. Afterward, the group developsmeasures toprevent theeventscollectedearlier fromhappening.Throughthis process, participants often realize which actions may entail negativeresults. With this method, risks can be identified early on andcountermeasures canbedeveloped.Advantages anddisadvantagesof thistechniqueareidenticaltothoseofclassicbrainstorming.

Changeofperspective

Change of perspective: Among the techniques that employ a change ofperspective (adopting different extreme standpoints), the most commontechnique is the so-calledSixThinkingHats [DeBono2006].Eachof thesixhatsrepresentsaparticularperspectivethatisinturnadoptedbyeachofthe participants. The resulting solutions approach the problem fromdifferentstandpoints.Thatway,evenstakeholders thatareveryconvincedof their own opinion are persuaded to adopt a different standpoint. Thistechniqueisextraordinarilybeneficialwhenstakeholderscanonlyexpresstheir knowledge in a biased manner or are harshly constricted to their

opinions. On the other hand, this technique cannot be applied if therequirements require a fine-grained level of detail because this wouldrenderthetechniqueverylaborious.

Analogytechnique

Analogy techniques (bionics/bisociations): In bionics, problems that theprojectfacesaremappedtoananalogoussituationoccurringinnature,andthe solutions nature provides are sought and then mapped back to theproject. In bisociation, the analogies need not originate in nature. Thesetechniques assume that each participant is capable of analogous thinking,that a lot of time is available, and that the participants have an in-depthknowledgeof thedomainwithwhichananalogywillbedrawn.Analogytechniquescanbeappliedcovertlyor in theopen.When this technique isapplied covertly, the participants are only told the analogy. Therequirementsengineer is thenresponsibleformappingtheresultsontothereal problem space. When this technique is applied in the open, thestakeholdersknowtherealproblemspaceaswellastheanalogy.

3.3.4Document-centricTechniques

Document-centrictechniquesreusesolutionsandexperiencesmadewithexistingsystems.Whenalegacysystemisreplaced,thistechniqueensuresthattheentirefunctionality of the legacy system can be identified. Document-centrictechniques should be combined with other elicitation techniques so that thevalidityoftheelicitedrequirementscanbedeterminedandnewrequirementsforthenewsystemcanbeidentified.

Systemarchaeology

System archaeology is a technique that extracts information required tobuildanewsystemfromthedocumentationorimplementation(code)ofalegacy system or a competitor’s system. The technique is often appliedwhenexplicitknowledgeabout thesystemlogichasbeen lostpartiallyorentirely.Byanalyzingexistingcode,therequirementsengineerensuresthatnoneofthefunctionalitiesofthelegacysystemwillbeoverlookedandthesystemlogicofthelegacysystemiselicitedanew.Thismethodleadstoa

largeamountofverydetailedrequirementsandisverylaborious.However,system archaeology is the only technique that can ensure that allfunctionalitiesofthelegacysystemwillbeimplementedinthenewsystem.When it becomes obviously apparent that the legacy system and the newsystem differ in functionality, additional elicitation techniques, e.g.,creativitytechniques,mustbeappliedearlyon.

Perspective-basedreading

Perspective-based reading (see section 7.5.4) is appliedwhen documentsneedtobereadwithaparticularperspectiveinmind,e.g., theperspectiveoftheimplementerorthetester.Aspectsthatarecontainedinthedocumentbutdonotpertaintothecurrentperspectiveareignored.Thisallowsforananalysis that is strictly focused on particular parts of the existingdocumentation.Thisway, detailed, technology-related or implementation-relatedaspectscanbeseparatedfromessentialoperationalaspectsthatarerelevantforthesuccessorsystem.

Reuse

Reuse:Requirementsthathavebeenpreviouslycompiledandbroughtuptoa certain quality standard can be reused. In order to do that, therequirementsarestoredinadatabase,forinstance,andkeptavailableattherequiredlevelofdetailforreuse.Throughreuse,thecostsinvolvedwiththeelicitationprocedurescanbesignificantlyreduced.

3.3.5ObservationTechniques

Questionobservationsandoptimizeprocesses.

When domain specialists are unable to spend the time needed to share theirexpertisewith the requirements engineer, or are unable to express and denotetheir knowledge, observation techniques are helpful. During observation, therequirementsengineerobservesthestakeholderswhiletheygoabouttheirwork.Therequirementsengineerdocumentsallstepsandthuselicitstheprocessesthesystemmustsupportaswellaspotentialmistakes,risks,andopenquestions.Allthosearepotentialrequirementsthatneedtobeformulated.Thestakeholderscan

actively demonstrate their knowledge in using the application or can remainpassive, with the requirements engineer merely observing. The requirementsengineer ought to question the observed processes so that the situation as itshouldbecanbeestablished.Otherwise,sheisatriskofdocumentingoutdatedtechnologicaldecisionsandsuboptimalprocesses(i.e.,thesituationasisandnotas it should be). As the requirements engineer is an external observer, herchancesof identifying inefficientprocesses aregoodand shecan then suggestbettersolutions.Sheisfartherremovedfromtheprocessesthanthestakeholders,who frequently repeat work steps without questioning them critically.Observation techniques are well suited to elicit detailed requirements anddissatisfiers because the requirements engineer can recognize dissatisfiersthoughtofasself-evidentoronlysubconsciouslyknownbythestakeholders.Inaddition, the requirements engineer becomes very familiar with the domainlanguage,whichsimplifiesfurtherelicitation.Satisfierscanonlybeobservediftheyhavebeen implemented in the legacy systemor are actively employed inthe current processes. As a result, this technique is not suited for thedevelopmentofnewprocesses.Duringsystemdevelopment, fieldobservationsandapprenticingareespeciallywellsuitedaselicitationtechniques.

Fieldobservation

Field observation: The requirements engineer is on location with thespecialist or the users of the system and observes and documents theprocesses and operational procedures that they carry out. Using theseobservations, she formulates the requirements. Often, this can be furtheraided by audio and video recordings. This technique is well suited foroperationalproceduresthataredifficulttoexpressverbally,butitcanonlybeappliediftheproceduresarevisiblephysically.

Apprenticing

With apprenticing, the requirements engineer must actively learn andperform the procedures of the stakeholders. Just like an apprentice, therequirements engineer is encouraged to question unclear and complexoperationalproceduressothatshemaygatherdomainexperience.Thereby,shecanexperiencerequirementsthatthestakeholderstakeforgrantedandthereforecannotelucidate.Anotheradvantageisthatthetypicalbalanceofpower between the requirements engineer and the respective specialist is

reversedbecause thestakeholdernowadopts the roleof the“master” thathastheknowledgetheapprenticeisyetlacking.

3.3.6SupportTechniques

Support techniquesserveasanaddition to theelicitation techniquesand try tobalanceouttheweaknessesandpitfallsofthechosenelicitationtechnique.

Mindmapping

Inmindmapping,agraphicalrepresentationoftherefinedrelationshipsandinterdependenciesbetweentermsiscreated.Mindmappingisoftenusedasasupportingtechniqueforbrainstormingorbrainstormingparadox.

Workshops

During a joint meeting, the requirements engineer and the stakeholderselaboratethegoals(ordetailsofacertainfunctionality)ofthesystem.Forexample, thenecessaryuser interfacesof thesystemcanbedesigned inaworkshop[Gottesdiener2002].

CRCcards

With the CRC technique (CRC stands for Class ResponsibilityCollaboration), context aspects and their respective attributes andproperties are denoted on index cards. Requirements are then formulatedusingthesecards.

Audioandvideorecordings

Audioandvideorecordingsareverywellsuitedtoelicitrequirementswhenstakeholders are not always available, when budget is tight, or when thesystem is highly critical. Especially during field observations, audio andvideo recordings canhelp capture fast-pacedprocesses.Thedisadvantageof this technique is that stakeholders often feel supervisedwhen they arebeing recorded and as a result might deliver biased statements or, inextremecases,mightevenrefusetocooperate.

Modelingactionsequences

Usecasemodeling:Usecasesdocumenttheexternalviewofthesystemtobedeveloped.Ause casehas a trigger event,which triggers theuse caseand an expected result, or outcome of the use case. Every use case is afunctionality that must be supported by the system to be developed (seesection6.3).

Prototypesforillustration

Prototypesarewellsuitedtoquestionestablishedrequirementsandtoelicitrequirements in situations where stakeholders have only a vagueunderstandingofwhatistobedeveloped.Potentialconsequencesofneworchangedrequirementscanbeidentifiedeasier.Forexample,userinterfaceprototypes are frequently used in practice to find additional functionalrequirements.

3.4Summary

Requirements elicitation is a core activity in requirements engineering. Asidefrom documents and legacy systems, stakeholders are the main sources forrequirements. It is important to initially agree upon mutual rights andresponsibilities of the stakeholders and the requirements engineer in order tofacilitate communication and cooperation and to successfully integrate thestakeholders into the elicitation process. The choice of the right elicitationtechniquefortherespectiveprojectismadebytherequirementsengineerbasedonthegivencultural,organizational,anddomain-specificconstraints.

4DocumentingRequirements

In requirements engineering, information that has been established or workedoutduringdifferentactivitiesmustbedocumented.Amongthisinformationare,for example, protocols of interviews and reports of validation or agreementactivities,butalsochangerequests.Themainandmostimportantdocumentationtask in requirements engineering, though, is to document the requirements forthesysteminasuitablemanner.

4.1DocumentDesign

A documentation technique is any kind of more or less formal depiction thateases communication between stakeholders and increases the quality of thedocumented requirements. In principle, any kind of documentation techniquecan be used to document the requirements, let it be natural language-baseddocumentationbymeansofprose,morestructurednaturallanguage-basedtext,ormoreformaltechniquessuchasstatediagrams.

Definition4-1:RequirementsDocument/RequirementsSpecificationArequirementsspecificationisasystematicallyrepresentedcollectionofrequirements,typicallyforasystemorcomponent,thatsatisfiesgivencriteria.

Reasonsforthedocumentation

Duringthelifecycleofarequirementsdocument,manypeoplearetrustedwiththe documentation. During communication, the documentation has a goal-oriented and supporting role. Themain reasons for documenting requirementsareasfollows:

Centralroleofrequirements

Requirementsarethebasisofthesystemdevelopment.Requirementsofanykindinfluencetheanalysis,design,implementation,andtestphasesdirectlyandindirectly.Thequalityofarequirementorofarequirementsdocumenthas a strong impact on the progress of the project and therefore on itssuccess.

Legalrelevance

Requirementshavealegalrelevance.Requirementsarelegallybindingforthe contractor and the client, and the client can sue for their fulfillment.Documentingtherequirementscanhelptoquicklyovercomelegalconflictsbetweentwoormoreparties.

Complexity

Requirements documents are complex. Systems that possess thousands ofrequirements that in turn have complex interdependencies on multiplelayers are not unheard of in practice. Without suitable documentation,keepingontopofthingscanbecomeverydifficultforanyoneinvolved.

Accessibility

Requirementsmust beaccessible toall involvedparties. Projects undergocertain“development”astimegoesby—withregardtothesubjectaswellas the staff.When requirementscanbepermanentlyaccessed,uncertaintyandobscuritiescanbeavoidedandstaffthathasrecentlyjoinedtheprojectcanquicklygetuptospeed.

Another argument for a good documentation, supportive of the project, is thatemployees almost never share the same understanding of a subject matter.Therefore, requirements should be documented in a way that they meet thequalitydemandsofallinvolved.

4.2TypesofDocumentation

Requirementsforasystemcanbedocumentedinthreedifferentperspectives.Inpractice,naturallanguageaswellasconceptualmodelsareusedtothisend,oroftentimes,anadvantageouscombinationofbothisemployed.

4.2.1TheThreePerspectivesofRequirements

Requirements for a system can be documented in three different perspectivesontothesystemtobedeveloped:

Dataperspective

Dataperspective:Inthedataperspective,astatic-structuralperspectiveonthe requirements of the system is adopted. For example, the structure ofinput and output data as well as static-structural aspects of usage anddependency relations of the system and the system context can bedocumented(e.g.,theservicesofanexternalsystem).

Functionalperspective

Functional perspective: The functional perspective documents whichinformation(data)isreceivedfromthesystemcontextandmanipulatedbythesystemoroneof itsfunctions.Thisperspectivealsodocumentswhichdata flows back into the system context. The order in which functionsprocessingtheinputdataareexecutedisalsodocumented.

Behavioralperspective:

Behavioral perspective: In the behavioral perspective, information aboutthesystemandhowitisembeddedintothesystemcontextisdocumentedinastate-orientedmanner.Thisisdonebydocumentingthereactionsofthesystem upon events in the system context, the conditions that warrant astatetransition,andtheeffectsthatthesystemshallhaveonitsenvironment(e.g., effects of the system analyzed that represent events in the systemcontextofadifferentsystem).

4.2.2RequirementsDocumentationusingNaturalLanguage

Advantagesofusingnaturallanguage

Natural language, particularly prose, is the most commonly applieddocumentation form for requirements in practice. In contrast to otherdocumentation forms, prose has a striking advantage: No stakeholder has tolearn a new notation. In addition, language can be used for miscellaneouspurposes—the requirements engineer can use natural language to express anykindofrequirement.

Disadvantagesofusingnaturallanguage

Natural-language-based documentation is well suited to documentrequirements in any of the three perspectives. However, natural language canallow requirements to be ambiguous, and requirements of different types andperspectives are in danger of being unintentionally mixed up duringdocumentation. In thatcase, it isdifficult to isolate informationpertaining toacertainperspectiveamidstalloftherequirementsinnaturallanguage.

4.2.3RequirementsDocumentationusingConceptualModels

Incontrasttonaturallanguage,thedifferenttypesofconceptualmodelscannotbe used universally. When documenting requirements by means of models,special modeling languages must be used that pertain to the appropriateperspective.Assumingthemodelinglanguageselectedforadocumentationtaskis applied correctly, its use constructively guarantees that the models createddepict information pertaining to the respective perspective only. The modelsdepict the documented requirementsmuchmore compactly and they thereforeareeasierforatrainedreadertounderstandthanisnaturallanguage.Inaddition,conceptualmodelsofferadecreaseddegreeofambiguity(i.e.,fewerwaystobeinterpreted) than natural language due to their higher degree of formality.However,usingconceptualmodelinglanguagesforrequirementsdocumentationrequires specific knowledge of modeling. The following list includes shortdescriptionsofthemostimportantdiagramsdiscussedinchapter6.

Overviewofsystemfunctions

Usecasediagram:Ausecasediagramallowsyoutogainaquickoverview

of the functionalities of the specified system.Ause case describeswhichfunctions are offered to the user by the system and how these functionsrelate to other external interacting entities. However, use cases do notdescribe the responsibilities that the functions have in detail (see section6.3).

Structuraldatamodelingandstructuringofterms

Class diagram: Among other things, class diagrams are used inrequirements engineering to document requirements with regard to thestaticstructureofdata,todocumentstatic-structuraldependenciesbetweenthesystemandthesystemcontext,ortodocumentcomplexdomaintermsinastructuredmanner(seesection6.5.2).

Sequencemodeling

Activitydiagram:Usingactivitydiagrams,businessprocesses,orsequence-oriented dependencies of the system in regard to processes within thesystemcontextcanbedocumented.Activitydiagramsarealsowellsuitedto model the sequential character of use cases or to model a detailedspecification of the interaction of functions that process data (see section6.6.3).

Event-drivenbehavior

State diagram: State diagrams are used in requirements engineering todocument event-driven behavior of a system. The focus of this type ofmodel is on the individual states the system can be in, events and theirrespectiveconditionsthattriggerastatetransition,andeffectsofthesysteminitsenvironment.

4.2.4HybridRequirementsDocuments

Combineduseofdocumentationtypes

Requirementsdocumentsfirstandforemostcontainrequirements.Inaddition,inmanysituationsitissensibletodocumentdecisions,importantexplanations,and

other relevant information as well. Depending on the target audience of thedocument, the perspective on the system, and the documented knowledge,suitable documentation types are selected. Typically, documents contain acombination of natural language and conceptual models. The combinationallowsthedisadvantagesofbothdocumentationtypestobedecreasedbymeansofthestrengthsoftheotherdocumentationtype,andcombiningdocumentationtypesexploitstheadvantagesofboth.For instance,modelscanbeamendedorcomplementedbynaturallanguagecommentsandnaturallanguagerequirementsandnatural languageglossariescanbesummarizedandtheirdependenciescanbedepictedclearlybymakinguseofmodels.

4.3DocumentStructures

Influenceoftherequirementsonsatisfaction

Requirements documents contain a magnitude of different information. Thesemustbewellstructuredforthereader.Inordertodothat,onecanmakeuseofstandardized document structures or individually define a custom documentstructure.

4.3.1StandardizedDocumentStructures

Adaptationofexistingstandardoutlines

Standard outlines offer a predefined structure, i.e., predefined stereotypesaccordingtowhichtheinformationcanbeclassified.Byusingstandardoutlines,a rough structure along with a short description of the content of the mainsectionsispredetermined.Usingstandardoutlineshasthefollowingadvantages:

Standardoutlinessimplifyincorporatingnewstaffmembers.Standardoutlinesallowforquicklyfindingdesiredcontents.Standardoutlinesallowforselectivereadingandvalidationofrequirementsdocuments.Standard outlines allow for automatic verification of requirementsdocuments(e.g.,withregardtocompleteness).Standardoutlinesallowforsimplifiedreuseofthecontentsofrequirements

documents.

Itmustbenotedthatthesestructuresmustbetailoredwithregardtothespecificprojectpropertiestomeettherespectiveconstraints.Inthefollowingparagraphs,threeofthemostwidelyusedstandardizeddocumentstructuresareintroduced.

RationalUnifiedProcess

The Rational Unified Process (RUP) [Kruchten 2001]is usually used forsoftware systems that are developedusingobject-orientedmethods.The clientcreates a business model that contains different artifacts from the businessenvironment (e.g., business rules, business use cases, business goals), whichserveasthebasisforrequirementsofthesystemoverthecourseofdevelopment.The contractor uses the structures of the software requirements specification(SRS)todocumentallsoftwarerequirements.ThesestructuresarecloselyrelatedtotheISO/IEC/IEEEstandard29148:2011,asdescribednext.

ISO/IEC/IEEEstandard29148:2011

The ISO/IEC/IEEE standard 29148:2011 [ISO/IEC/IEEE 29148:2011]contains an outline designed for the documentation of software requirements(software requirements specification).The standard structure suggests dividingtherequirementsdocumentintofivepartswithregardtotheirsubjectmatter:

A chapter with introductory information (e.g., system goal, systembounding)andageneraldescriptionofthesoftware(e.g.,perspectiveofthesystem,propertiesoffutureusers)A chapter with a listing of all documents that are referenced in thespecificationA chapter for specific requirements (e.g., functional requirements,performance,interfaces)AchapterwithallplannedmeasuresforverificationAppendices(e.g.,informationaboutassumptionsthatweremade,identifieddependencies)

V-Model

TheV-Model [V-Modell 2004] of theGermanFederalMinistry of the Interior

(BMI)definesdifferentstructures,dependingonthecreatoroftherequirementsdocument:

TheCustomerRequirements Specification, known in theGerman originalasLastenheft,iscreatedbythecustomeranddescribesallofthedemandsto the contractor regarding the subject of the contract, i.e., deliveries andservices. In addition, in many cases, demands of the users, including allconstraints to the system and the development process, are documented.Therefore,theCustomerRequirementsSpecificationusuallydescribeswhatismadeforwhat.TheSystemRequirements Specification, known in theGermanoriginal asPflichtenheft, is based on the Customer Requirements Specification andcontainstheimplementationsuggestionsthatthecontractorhaselaborated.Therefore, the System Requirements Specification is a refinement of therequirementsandconstraintsoftheCustomerRequirementsSpecification.

4.3.2CustomizedStandardContents

Theminimumcontent

Asdescribedinsection4.3.1,standardizeddocumentstructuresareadaptedwithregard to the specific project conditions. The following issues should beaddressedbyanychosenstructure.

Introduction

The introduction contains information about the entire document. Thisinformationallowsgainingaquickoverviewofthesystem.

Purpose:Thissectiondiscusseswhythedocumentwascreatedandwhothetargetaudiencefortherequirementsdocumentis.System coverage: This part consists of the system to be developed. Itindicates system name and the principle goals and advantages that arisefromintroducingthesystem.Stakeholder:Thissectioncontainsa listofstakeholdersandtheir relevantinformation(seesection3.1.1).

Definitions,Acronyms,andAbbreviations:1 In thissection, the termsusedin the document are defined so that they can be used consistentlythroughoutthedocument.References:2 All documents that are referenced by the requirementsdocumentarelistedherein.Overview:Attheendoftheintroductorychapter,thecontentandstructureofthefollowingsectionsoftherequirementsdocumentshouldbeexplainedbriefly.

GeneralOverview

In this section, additional information is documented that increases theunderstandability of the requirements. In contrast to the introduction, this ismerely operational information that does not pertain to administration,management,ororganizationalaspectsoftherequirementsdocument.

Systemenvironment:Theembeddingofthesystemintotheenvironmentisof key concern in this paragraph. The results of your definition of thesystemboundaryandcontextboundarycanbefoundherein.Architecture description: In this section, the operational interfaces of thesystem (e.g., user interfaces, hardware and software interfaces, andcommunication interfaces) are documented. In addition, furtherinformation,e.g.,regardingstoragelimitations,isalsodiscussed.System functionality: This section contains the coarse functionalities andtasksofthesystem.Thiscanbedocumented,forexample,usingausecasediagram.Userand targetaudience:Thedifferentusersof thesystemthatmakeupthetargetaudiencearelisted.Constraints: In thissection,allconditionsought tobe listed thathavenotbeendocumentedthusfarandmighthindertherequirementsengineering.Assumptions: Decisions, such as not implementing certain aspects of thesystem due to budgeting reasons, or other general assumptions about thesystemcontextthattherequirementsarebaseduponaredocumentedhere.

Requirements

Thispartcontainsfunctionalrequirementsaswellasqualityrequirements.

Appendices

In the appendices, additional information that completes the document can bedocumented. For example, the appendices can include additional documentsregarding the user characteristics, standards, conventions, or backgroundinformationregardingtherequirementsdocument.

Index

Theindextypicallycontainsatableofcontents(i.e.,astructureofthechapters)andanindexdirectory.Inhighlydynamicrequirementsdocuments,thismaybeahighlycriticalsectionthatmustbekeptup-to-date.

4.4UsingRequirementsDocuments

Requirementsdocumentsasthebasisfordevelopment

Over the course of the project, requirements documents serve as the basis fordifferenttasks:

Planning: Based on the requirements document, concrete work packagesandmilestonesfortheimplementationofthesystemcanbedefined.Architectural design: The detailed documented requirements (along withconstraints)serveasthebasisforthedesignofthesystemarchitecture.Implementation: Based on the architectural design, the system isimplementedbymakinguseoftherequirements.Test: On the basis of requirements that have been documented in therequirements document, test cases can be developed that can be used forsystemvalidationlateron.Change management: When requirements change, the requirementsdocumentcanserveasthebasistoanalyzetheextenttowhichotherpartsofthesystemareinfluenced.Thechangeeffortcanthusbeestimated.Systemusageandsystemmaintenance:After thesystemisdeveloped, therequirementsdocumentisusedformaintenanceandsupport.Thisway,the

requirements document can be used to analyze concrete defects andshortcomingsthatsurfaceduringsystemuse.Forexample,onecandeductifadefectisaresultofusingthesystemincorrectly,aresultofanerrorinrequirements,oraresultofanerrorinimplementation.Contractmanagement:Therequirementsdocumentistheprimesubjectofacontractbetweenaclientandacontractorinmanycases.

4.5QualityCriteriaforRequirementsDocuments

To become a basis for the subsequent processes, the requirements documentmust meet certain quality criteria. According to the ISO/IEC/IEEE standard29148:2011 [ISO/IEC/IEEE 29148:2011], a requirements document shall becomplete and consistent. Moreover, a requirements document shall supportreadability by offering a clear structure, reasonable scope, and traceability.Overall,arequirementsdocumentshallfulfilthefollowingqualitycriteria:

UnambiguityandconsistencyClearstructureModifiabilityandextendibilityCompletenessTraceability

4.5.1UnambiguityandConsistency

Qualityofindividualrequirementsisaprerequisite.

Requirements documents can be consistent and unambiguous only when theindividualrequirementsareconsistentandunambiguous.Inaddition,itmustbeguaranteed that individual requirements do not contradict one another. Toachieve this, it is advisable tomakeuseof conceptualmodels (see chapter6).Another aspect of unambiguity pertains to the unique identification of arequirements document or a requirement among the set of all requirementsdocumentsorrequirementsinadevelopmentproject(seesection8.5).

4.5.2ClearStructure

Allowsforselectivereading

In order to guarantee that the requirements document is readable by anystakeholder, it should be appropriately comprehensive and clearly structured.Unfortunately, no clear-cut suggestions can bemade regarding the appropriatecomprehensiveness of a requirements document. A very comprehensiverequirementsdocumentwithagoodstructurecanbejustasappropriateasalesscomprehensivedocumentbecauseaclearstructurewillallowthereadertoskipparts that are not relevant to him. An unstructured or badly structuredrequirementsdocumentofthesamehighlevelofcomprehensivenesswouldnotbeappropriatebecausethedocumentmustbereadin itsentirety inorderforastakeholder tobeable to identifyparts thatarerelevant toher.Agoodstartingpointisthestandardstructuresdescribedinsection4.3.1.

4.5.3ModifiabilityandExtendibility

Contentandstructureshouldsupportchangeability.

Requirementsdocumentsmustbeeasytoextend.Therearealwaysrequirementsthatarechanged,altered,added,orremovedasaprojectprogresses.Asaresult,the structureof requirementsdocuments shouldbeeasy tomodifyandextend.The requirements documents of a project should be subject to the project’sversioncontrolmanagement.

4.5.4Completeness

Twotypesofcompletenessinrequirementsdocuments

Requirementsdocumentsmustbecomplete, i.e., theymustcontainall relevantrequirements (andrequiredadditional information),andeachrequirementmustbedocumentedcompletely.3Allpossibleinputs,influentialfactors,andrequiredreactionsofthesystemmustbedescribedforeachdesiredsystemfunction.Thiscomprises describing error and exception cases in particular. Also, qualityrequirements, such as requirements pertaining to reaction times or availability

andusabilityofthesystem,mustbenoted.

Evidence,reference,andsourcesareformalnecessities.

Formalfactorsalsocontributetocompleteness.Graphs,diagrams,andtablesshould be appropriately labeled. Another important aspect is that consistentreferenceandindexdirectoriesmustexist.Also,definitionsandnormreferencethatdenotespecifictermsmustbeincludedinanyrequirementsdocument.Thecomprehensiveness of a requirements document is a challenge duringrequirementsengineering.Often,acompromisemustbefoundbetweenthetimeresourcesavailableandthecompletenessoftherequirementsdocuments.

4.5.5Traceability

Relationshiptootherdevelopmentdocuments

An important quality criterion is traceability of relationships betweenrequirementsdocumentsandotherdocuments(e.g.,businessprocessmodel,testplans, or designplans).These documents could havebeen created in previousdevelopment phases, in subsequent development phases, or concurrently withthe requirements documents.Amongother things, traceability supports changemanagement(seesection8.4).

4.6QualityCriteriaforRequirements

Qualitycriteriaforsingledocumentrequirements

Eachdocumentedrequirementshouldfulfilthefollowingqualitycriteria:

Agreed:Arequirement isagreedupon if it iscorrectandnecessary in theopinionofallstakeholders.Unambiguous: [ISO/IEC/IEEE 29148:2011] A requirement that isunambiguouslydocumentedcanbeunderstoodinonlyoneway.Itmustnotbepossibletointerprettherequirementinadifferentway.Allreadersoftherequirementmustarriveatthesameunderstandingoftherequirement.Necessary: [ISO/IEC/IEEE 29148:2011]A documented requirementmust

representthefactsandconditionsofthesystemcontextinawaythatitisvalidwithregardtotheactualitiesofthesystemcontext.Theseactualitiesmaybethedifferentstakeholders’ideas,relevantstandards,orinterfacestoexternalsystems.Consistent: [ISO/IEC/IEEE29148:2011]Requirementsmustbe consistentwith regard to all other requirements, i.e., the requirements must notcontradictoneanother,regardlessoftheirlevelofdetailordocumentationtype.Inaddition,arequirementmustbeformulatedinawaythatallowsforconsistencywithitself,i.e.,therequirementmaynotcontradictitself.Verifiable: [ISO/IEC/IEEE 29148:2011]A requirementmust be describedinawaythatallowsforverification.Thatmeansthattestsormeasurementscanbecarriedoutthatprovideevidenceofthefunctionalitydemandedbytherequirement.Feasible: [ISO/IEC/IEEE 29148:2011] It must be possible to implementeach requirement given the organizational, legal, technical, or financialconstraints.Thismeansthatamemberofthedevelopmentteamoughttobeinvolved in rating the goals and requirements so that he can show thetechnical limits of the implementation of a particular requirement. Inaddition, the costs for the implementation must be incorporated into therating.Occasionally,stakeholderswithdrawarequirementifthecostsforitsrealizationbecomeapparent.Traceable: [ISO/IEC/IEEE 29148:2011] A requirement is traceable if itsoriginaswellas its realizationand its relation tootherdocumentscanberetraced. This can be done by means of unique requirement identifiers.Using these unique identifiers, requirements that are derived from otherrequirementsonadifferentlevelofthespecificationcanbeconnected.Forexample,asystemgoalcanbetracedthroughalllevelsofabstraction,fromdesigntoimplementationandtest.Detailscanbefoundinsection8.4.Complete: [ISO/IEC/IEEE29148:2011]Each individual requirementmustcompletelydescribethefunctionalityitspecifies.Requirementsthatareyetincompletemustbe speciallymarked, forexampleby inserting“tbd” (“tobedetermined”)intotherespectivetextfieldorbysettingacorrespondingstatus.Thesemarkingscanthenbesystematicallysearchedforandmissinginformationcanbeamendedaccordingly.Understandable: Requirements must be comprehensible to eachstakeholder.Therefore,thetypeofrequirementsdocumentation(seesection4.2) can vary significantly, depending on the development phase (andtherefore,dependingontheinvolvedstaff).Inrequirementsengineering,it

isimportanttostrictlydefinethetermsused.

Fundamentalprinciplesofunderstandability

Alongwithqualitycriteriaforrequirements,therearetwofundamentalrulesthatenhancethereadabilityofrequirements:

Short sentences and short paragraphs: As human short-term memory isverylimited,circumstancesthatbelongtogethershouldbedescribedinnomorethansevensentences.Formulate only one requirement per sentence: Formulate requirementsusing active voice and use only one process verb. Long, complicatedinterlacedsentencesmustbeavoided.

4.7Glossary

Afrequentcauseforconflictsinrequirementsengineeringisthatthepeoplethatareinvolvedinthedevelopmentprocesshavedifferentinterpretationsofterms.Inordertoavoidtheseconflicts,itisnecessarythateveryonewhoisinvolvedinthedevelopmentprocesssharesthesameunderstandingoftheterminologyused.Therefore,allrelevanttermsmustbedefinedinacommonglossary.Aglossaryisacollectionoftermdefinitionsandcontainsthefollowingelements:

Context-specifictechnicaltermsAbbreviationsandacronymsEverydayconceptsthathaveaspecialmeaninginthegivencontextSynonyms,i.e.,differenttermswiththesamemeaningHomonyms,i.e.,identicaltermswithdifferentmeanings

Consistentdefinitions

By defining the meaning of terms, you can increase the understandability ofrequirements considerably. Misunderstandings and different interpretations oftermsthatmightleadtoconflictscanbeavoidedfromthebeginning.

Reuseofglossaryentries

Often,indifferentprojects,termsareusedthataresimilartooneanotherorin fact identical. This may be the case, for example, when one system isdeveloped for different customers but within the same domain. In this case,already existing glossary entries should be reused. Itmay even be feasible todefinesuchtermsinauniversal, inter-projectglossary.Theadditionaleffortofcreating such a glossary will pay off in future projects. For certain domains,collectionsof termdefinitions already exist and are publicly accessible.Thesemay serve as the foundation for the definition of specific glossaries. Forexample, in [IEEE 610.12-1990], typical terms of software engineering aredefined.

RulesforUsingaGlossary

Basicrulesforusingaglossary

Sincecreatingaglossaryisabsolutelymandatory,thefollowingmustbenoted:

Theglossarymustbecentrallymanaged:Atanytime,theremustbeonlyonevalidglossary,whichmustalsobecentrallyaccessible.Theremustnotbemultiplevalidglossaries.Responsibilitymustbeassigned:Oneparticularindividualmustbeassignedwiththetaskofmaintainingtheglossaryandensuringconsistencyandup-to-dateness. The necessary resources to accomplish this task must beincludedintheprojectplan.Theglossarymustbemaintainedoverthecourseoftheproject:Inordertoensurethattheglossaryisconsistentandup-to-date,itmustbemaintainedover the course of the entire project by the person thatwas assigned thisresponsibility.Theglossarymustbecommonlyaccessible:The termdefinitionsmustbeavailable for all involved personnel. This is the only way a commonunderstandingofthetermscanbeensured.Using the glossary must be obligatory: All involved personnel must beobligedtoexclusivelyusethetermsandtermdefinitionsastheyhavebeendefinedintheglossary.Theglossaryshouldcontainthesourcesoftheterms:Inordertobeabletoresolvequestionsandproblemsatanytimeduringthecourseoftheproject,itmustbepossibletodeterminethesourceofaterm.

The stakeholders should agree upon the glossary: Only stakeholders canreliably validate the operational definitions for their respective projectcontext. Each definition should be validated by the stakeholders or theirrepresentatives. Inaddition, the individual termdefinitions in theglossaryshould be explicitly approved. This approval signals that the respectivetermiscorrectanditsuseisobligatory.Theentriesintheglossaryshouldhaveaconsistentstructure:Allentriesinthe glossary must be structured in the same way. In order to support aconsistent documentation, it is advisable to use a template for glossarydefinitions. In addition to the definition and the meaning of a term, thetemplateshouldspecifypossiblesynonymsandhomonyms.

To reduce theeffortof aligning termswithoneanother, it is advisable to startwiththecreationoftheglossaryearlyonintheproject.

4.8Summary

The documentation of requirements plays a central role in requirementsengineering.Astheamountofrequirementsisoftenvast,itisveryimportanttoclearlystructuretherequirementssothatpersonnelnotinvolvedwiththeprojectalsounderstandthem.Also,lookingupandchangingrequirementsissimplifiedand accelerated in this way. This makes meeting the quality criteria forrequirements documents much easier. Using customized documentationstructures has proven to be suitable for that purpose. These are completed byinsertingproject-specificrequirementswritteninnaturallanguageinconjunctionwithconceptualrequirementsmodels.

1.Thissectioncanalsobetreatedasanappendixtothedocument.2.Thissectioncanalsobetreatedasanappendixtothedocument.3.Strictlyspeaking,thisstatementholdstrueonlyfortherequirementsdocumentofthenextsystemrelease

(seesection8.5.3).

5DocumentingRequirementsinNaturalLanguage

Elicitedrequirementsforthesystemtobedevelopedarefrequentlydocumentedusing natural language. Natural language has the advantage that it (allegedly)does not require preparation time in order to be read and understood bystakeholders [Robertson andRobertson 2006]. In addition, natural language isuniversal in the sense that it can be used to describe any circumstances.However, therearesomeproblemsassociatedwith theuseofnatural languageforrequirementsdocumentation.

5.1EffectsofNaturalLanguage

Subjectiveperception

Asnaturallanguageisinherentlyambiguousandstatementsinnaturallanguagecan often be interpreted in multiple ways, it is necessary to place specialemphasisonpotentialambiguities in suchstatements to satisfy thecriterionofunambiguousness.Requirements aredefinedand readbypeoplewithdifferentknowledge, different social backgrounds, and different experiences. Thediversityamongthepeopleinvolvedinthedevelopmentprocessesmayleadtomisunderstanding as humans interpret information differently (they form a so-called “deep structure” in their mind) and thus construe it differently as well(e.g., as a requirement). During such a process (i.e., perception andrepresentation of information), so-called “transformational effects” occur thatshow different characteristicswith every human butmay occur in all humans[BandlerandGrinder1975,Bandler1994].

Figure5-1Transformationaleffectsinperceptionandrepresentationofknowledge

Transformationaleffects

Thefactthattransformationaleffectsadheretocertainrulescanbeexploitedbytherequirementsengineertoelicit thedeepstructure(i.e.,whattheauthorofarequirementreallymeant)fromitssurfacestructure(i.e.,therequirements).Thefollowinglistincludesthefivetransformationalprocessesthataremostrelevantforrequirementsengineering:

NominalizationNounswithoutreferenceindexUniversalquantifiersIncompletelyspecifiedconditionsIncompletelyspecifiedprocessverbs

5.1.1Nominalization

Reductionofprocesses

By means of nominalization, a (sometimes long-lasting) process is convertedinto a (singular) event. All information necessary to accurately describe theprocess is thereby lost. The process word transmit turns into the nountransmission. Other typical examples of nominalization are the terms input,booking,andacceptance.

Example5-1:Nominalization“Incaseofasystemcrash,arestartofthesystemshallbeperformed.”Thetermssystemcrashandrestarteachdescribeaprocessthatoughttobeanalyzedmoreprecisely.

Defineprocessescompletely.

Perse,therearenoargumentsagainsttheuseofnominalizedtermstodescribecomplex processes. However, the process should be explicitly defined by thetermused.Thedefinitionofanominalizedtermmustnotallowforanyleewayin the interpretation of the processes and must precisely depict the process,including any exceptions that may occur as well as all input and outputparameters. It is therefore not necessary to avoid nominalizations, but theyshouldonlybeusediftheunderlyingprocessiscompletelydefined.Duringthelinguistic analysis of a text, all nominalizations ought to be examined todeterminewhethertheyhavebeendefinedinsufficientdetailinanotherpartoftherequirementsdocumentandwhethertheyareclearforallstakeholders.Ifthisisnotthecase,anotherrequirementoraglossaryentrymustbecreated.

5.1.2NounswithoutReferenceIndex

Nounswithmissingreference

Aswith process verbs, nouns are frequently incompletely specified. Linguistscall this a missing or inadequate index of reference. Examples of terms thatcontainincompletelyspecifiednounsaretheuser,thecontroller,thesystem,themessage,thedata,orthefunction.

Example5-2:NounswithoutreferenceindicesThedatashallbedisplayedtotheuserontheterminal.

The followingquestionsarise:Whatdataexactly?Whichuserexactly?Whichterminal exactly? If this information is amended, the requirement might thusreadasfollows:

Example5-3:NounswithaddedreferenceindicesThesystemshalldisplaythebillingdatatotheregistereduserontheterminalsheisloggedinto.

5.1.3UniversalQuantifiers

Specifyamountsandfrequencies.

Universalquantifiersspecifyamountsorfrequencies.Theygroupasetofobjectsand make a statement about the behavior of this set. When using universalquantifiers, there is the risk that the specified behavior or property does notapplytoallobjectswithinthespecifiedset.Stakeholders tendtogroupobjectstogether,eventhoughsomeoftheseobjectsmightbespecialcasesorexceptions,wherethebehaviorspecifieddoesnotapplytoalltheobjectsofagroup.

Identifyuniversalquantifiers.

Itmustbeverifiedwhetherthespecifiedbehaviorreallyappliestoallobjectssummarized through the quantifiers. Universal quantifiers can be easilyidentified through trigger words such as never, always, no, none, every, all,some,ornothing.

Example5-4:UniversalquantifiersThesystemshallshowalldatasetsineverysubmenu.

In this case, the following questionmust be asked:Really in every submenu?Reallyalldatasets?

5.1.4IncompletelySpecifiedConditions

Identifyandclarifyconditionstructures.

Incompletely specified conditions are another indicator of a potential loss ofinformation.Requirementsthatcontainconditionsspecifythebehaviorthatmustoccurwhen thecondition ismet. Inaddition, theymust specifywhatbehavior

mustoccuriftheconditionisnotmet(thepartthatisoftenmissing).Especiallyincomplexconditionalstructures,decisiontablescanbeinvaluabletoolstofindunspecified variants of conditions or actions. Trigger words are, for instance,if...then,incase,whether,anddependingon.

Example5-5:IncompletelyspecifiedconditionTherestaurantsystemshallofferallbeveragestoaregisteredguestovertheageof20years.

Atleastoneaspectremainsunspecifiedintheexampleabove:Whichbeveragesshallbeofferedtoaguestthatis20yearsoryounger?Clarifyingthisquestionmayleadtoextendingtherequirementasfollows:

Example5-6:MorecompletelyspecifiedconditionTherestaurantsystemshalloffer

Allalcohol-freebeveragestoanyregistereduseryoungerthan21yearsAllbeveragesincludingallalcoholicbeveragestoanyuserovertheageof20

5.1.5IncompletelySpecifiedProcessVerbs

Completingprocesswords

Some process verbs requiremore than one noun to be considered completelyspecified.Theverbtransmit,forinstance,requiresatleastthreesupplementstobe considered complete: what is being transmitted, from where it is beingtransmitted, and to where it is being transmitted. The feel for language (alsoreferred to as “Sprachgefühl”) is a valuable tool to help gaugewhich processword must be supplemented in order to be considered complete. Similarly,adjectivesandadverbsmayneedtobesupplementedaswell.Whiletheeffectismuchlessfrequentwiththesetypesofwordsthanwithverbs,itisoftenhardtorecognize.

Avoidpassivevoice.

Theuseof incompletely specifiedprocesswordscanmostlybeavoidedor

kepttoaminimumifrequirementsareformulatedusingtheactivevoiceratherthanthepassivevoice.

Example5-7:RequirementusingthepassivevoiceTologauserin,thelogindataisentered.

Useactivevoice.

Inthisrequirementusingpassivevoice,itisunclearwhoentersthelogindata.Itisalsounclearwhereandhowthis isdone. If this requirement is reformulatedusingtheactivevoice,atleasttheagentorpersonresponsiblemustbeincluded.

Thesamerequirementusingactivevoicemightbeasfollows:

Example5-8:RequirementusingactivevoiceThesystemmustallowtheusertoenterhisusernameandpasswordusingthekeyboardoftheterminal.

5.2RequirementConstructionusingTemplates

Qualitybymeansofrequirementstemplatesandglossaries

Requirementstemplatesprovideasimpleandeasilyunderstandableapproachtoreducelanguageeffectswhendocumentingrequirements.Templatessupporttheauthorinachievinghighqualityandsyntacticunambiguousnessinoptimaltimeandatlowcosts.

Definition5-1:RequirementsTemplateArequirementstemplateisablueprintforthesyntacticstructureofindividualrequirements.

Inorder toachievelexicalclearness in thedocumentationaswell, it iswise touse requirements templates in conjunctionwith project glossaries (see section4.7).

The following is a step-by-step description of the correct application ofrequirementstemplates.

Step1:DeterminetheLegalObligation

Howlegallybindingisarequirement?

In the beginning, you should determine the degree of legal obligation for arequirement.Usually,onedistinguishesbetweenlegallyobligatoryrequirements,urgently recommended requirements, future requirements, and desirablerequirements.Toachievethiswithinarequirement,youcanusethemodalverbsshall,should,will,andmay.Alternatively,thelegalobligationofarequirementcanbedocumentedbyaspecificrequirementsattribute.

Step2:TheRequirementCore

Determinetherequiredprocess.

The core of each requirement is the functionality that it specifies (e.g., print,save, paste, or calculate). This functionality is referred to as the process.Processesareactivitiesandmayonlybedescribedusingverbs.Theprocessthatdepictsthesystembehaviorbymeansofarequirementistobedescribedinstep2.

Sinceprocesswordsdeterminesemantics,theymustbedefinedasclearlyaspossibleandbeusedasconsistentlyaspossible(seesection4.7).

Step3:CharacterizetheActivityofaSystem

Forfunctionalrequirements,thesystemactivitycanbeclassifiedasoneofthreerelevanttypes:

Autonomous system activity: The system performs the processautonomously.Userinteraction:Thesystemprovidestheprocessasaservicefortheuser.Interfacerequirement:Thesystemperformsaprocessdependingonathirdparty(e.g.,anothersystem).Thesystemispassiveandwaitsforanexternalevent.

Instep3,anykindof systemactivity that is specifiedbya requirementof thesystemisdocumentedusingexactlyoneofthreerequirementstemplates.These

requirementstemplatesaredescribedinmoredetailinthefollowingsections.Afterperformingsteps1through3,thestructureoftherequirementhasbeen

developed(seefigure5-2).Thewordsthatarewritteninanglebracketsmustbereplacedaccordingly.

Figure5-2Thecoreofarequirementanditslegalobligation

Type1:Autonomoussystemactivity

The first template type is usedwhen requirements are constructed that depictsystem activities that are performed autonomously. The user does not interactwiththeactivity.Wedefinethefollowingrequirementstemplate:

THESYSTEMSHALL/SHOULD/WILL/MAY<processverb>

<Processverb>depictsaprocessverbasdescribedinstep2,e.g.,printforprintfunctionalityorcalculateforsomecalculationthatisperformedbythesystem.

Type2:Userinteraction

Ifthesystemprovidesafunctionalitytoauser(forexample,bymeansofaninput interface), or the system directly interacts with a user, requirements areconstructedusingtemplatetype2:

THESYSTEMSHALL/SHOULD/WILL/MAYprovide<whom?>withtheabilityto<processverb>

Theuserthatinteractswiththesystemisintegratedintotherequirementthrough<whom?>.

Type3:Interfacerequirement

Ifthesystemperformsanactivityandisdependentonneighboringsystems,the third template type is tobeused.Whenevermessagesordata are receivedfrom a neighboring system, the system must react by executing specificbehavior.Thefollowingtemplatehasprovenitselfaswellsuited:

THESYSTEMSHALL/SHOULD/WILL/MAYbeableto<processverb>

Step4:InsertObjects

Completeprocessverbs.

Some process verbs require one or more additional objects to be consideredcomplete (see section 5.1.5). In step 4, potentially missing objects andsupplementsofobjects(adverbials)areidentifiedandaddedtotherequirement.Forinstance,therequirementstemplatefortheprocessverbprintisamendedbytheinformationofwhatisbeingprintedandwhereitisprinted.Theamendmentcanbeseeninfigure5-3.

Figure5-3Principleofacompleterequirementstemplatewithoutconditions

Step5:DetermineLogicalandTemporalConditions

Addconditions.

Typically, requirements do not document continuous functionalities, butfunctionalities that are performed or provided only under certain logical ortemporal constraints. In order to easily differentiate between logical andtemporal conditions, we choose the temporal conjunction as soon as fortemporal conditions and the conditional conjunction if for logical conditions.Theconjunctionwhenmakesnotclearwhetheratemporaloralogicalconditionisdescribedandshouldthereforebeavoided.Instep5,qualityrequirementsthatdescribe theconditionsunderwhicha requirement is fulfilledareadded to thebeginningofarequirementasasubordinateclause.

Figure5-4Thecompleterequirementstemplatewithconditions

Requirementstemplatesshouldbeusedwhenprojectmembersshowinterestinaformal development process. Style and creativity are harshly limited whenrequirementstemplatesareused.Experienceshowsitisbestnottomaketheuseof requirements templatescompulsory,but tooffer trainingon themethodandtreatitasasupplementaltool.

5.3Summary

Systemrequirementsarefrequentlydocumentedusingnaturallanguage.Typicaladvantagesthatarisefromnaturallanguagerequirementsaregoodreadabilityofrequirements, the fact that natural language can be universally applied todocumentanycircumstance, and the fact thatnopriorknowledge isnecessaryregardingthenotation.Ontheotherhand,thereareanumberofdisadvantagesthat arise from the fact that natural language requirements are not formalized,e.g.,ambiguity.Sinceprojectmembersinterpretrequirementsdifferentlyduetodifferences in their respective knowledge, social background, and experiences,using natural language for requirements documentation often leads to

misunderstanding in practice. These disadvantages can be minimized duringrequirements documentation—for example, by making use of requirementstemplatesandbycheckingtherequirementsagainstlinguisticeffects.

6Model-BasedRequirementsDocumentation

During model-based documentation of requirements in requirementsengineering,threetypesofrequirementsaredocumentedindependentlyandusedinconjunction:

Goalsdescribeintentionsofstakeholdersorgroupsofstakeholders.Goalscanpotentiallyconflictwithoneanother.Usecasesandscenariosdocumentexemplarysequencesofsystemusage.Scenariosaregroupedtogetherinusecases.System requirements (generally referred to as requirements) describedetailed functions and qualities that the system to be developed shallimplement or possess. In addition, system requirements provide completeandpreciseinformationtoserveasinputforsubsequentdevelopmentsteps.

In practice, requirements are often documented using natural language.However, it can be observed that requirements are increasingly oftendocumentedusingmodels.Requirementmodelsareused inaddition tonaturallanguage requirements documentation and partly replace requirements thatwouldhavebeendocumentedusingnaturallanguage.

6.1TheTermModel

Modelsasabstractingimagesfromreality

Amodel is an image that abstracts from reality or that serves as a abstractedrepresentation of reality that is to be created. Modeling may be applied to

materialorimmaterialobjectsofanexistingrealityorarealitytobedeveloped.Similarlyto[Stachowiak1973],wedefinethetermmodelasfollows:

Definition6-1:ModelAmodelisanabstractrepresentationofanexistingrealityorarealitytobecreated.

6.1.1PropertiesofModels

Every model possesses three important properties that are also the prevalentadvantagesofmodels:

Mapping of reality: Every model maps certain aspects of the observedrealityonto itsmodelingelements.Model creationcanbedescriptiveandprescriptive in nature. In the case of descriptive model construction, theresultingmodeldocuments the existing reality. In the caseofprescriptivemodelconstruction,theresultingmodelservesasaprototypeforafictitiousreality. Depending on the perspective, models themselves can be bothdescriptive and prescriptive at the same time. For example, a model isdescriptive with regard to the conception of the stakeholder who isconstructingitandprescriptivewithregardtothesystemtobedeveloped.Reduction of reality:Models reduce themapped reality. It is common todifferentiate between selection and compression. During selection, onlyparticularaspectsthatarepartoftheuniverseofdiscourseofthesystemaremodeled. In contrast, aspects of the subject-matter of the system aresummarizedduringcompression.Pragmaticproperty:Amodel is always constructed for a special purposeand within a special context. The purpose of the model may affect theconstructionandthepurpose-drivenreductionofrealitywithinthemodels.Ideally,amodelcontainsonlytheinformationnecessaryfortherespectivepurpose.

Typically, graphical models are used in requirements engineering. Theirmodelingelements are conceptualizationsofmaterialor immaterialobjects, orpeople,inreality.

6.1.2ModelingLanguages

Syntaxandsemantics

Inordertoconstructconceptualmodels,specificmodelinglanguagesareused.Amodelinglanguageisdefinedbyitssyntaxandsemantics:

Syntax:Thesyntaxofamodelinglanguagedefinesthemodelingelementstobeusedandspecifiesthevalidcombinationsthereof.Semantics:Thesemanticsdefines themeaningof the individualmodelingelementsandserves thereforeasa foundation for the interpretationof themodelsoftherespectivemodelinglanguage.

Differentdegreesofformalization

Conceptual modeling languages can be classified as formal, informal, andsemiformal, depending on the degree of formalization. The degree offormalization of a modeling language depends on the magnitude of formaldefinitions(e.g.,mathematicalcalculus)thatdefinethesyntaxandsemantics.

6.1.3RequirementsModels

Conceptual models that document the requirements of a system are calledrequirements models. The Unified Modeling Language (UML) is frequentlyused toconstruct requirementsmodels [OMG2007].UMLhasdeveloped intothequasi-standardformodel-basedconstructionofsoftwaresystems.Itconsistsofasetofpartiallycomplementarymodelinglanguagesthatareparticularlyusedin requirements engineering to model the requirements of a system fromdifferentperspectives.ExtensiveexamplesofmodelingusingUMLcanbefoundin[Ruppetal.2007],forinstance.

Requirementsmodelsvs.designmodels

A considerable difference between the conventional use of conceptualmodelsinsystemdevelopmentandmodelusageforrequirementsdocumentationis that conventional models document solutions chosen during systemdevelopment.Requirementsmodels,ontheotherhand,depictspecificaspectsof

theunderlyingproblem.

6.1.4AdvantagesofRequirementsModels

Increasedunderstandability

Researchonhumancognitionhasshownthatinformationcanbeperceivedandmemorized faster and better when depicted graphically as opposed tomakinguseofnatural language. (e.g., [GlassandHolyoak1986], [Kosslyn1988], and[Mietzel1998].Thesefindingscanbeappliedtotheuseofrequirementsmodelsinparticular.

Supportperspectivesofdocumentation.

Anadditionaladvantagewhenusingrequirementsmodelsisthatincontrasttonatural language,themodelinglanguagesusedhaveastrictlydefinedfocus.An example is the different kinds of maps that can be drawn for a city.Dependingonwhataspectofthecityisbeingmapped(modeled),differenttypesofabstractioncanbeusedtoconstructthemap.Forinstance,asubwaymapwillshow underground subway stations and subway lines. However, the length ofeachconnectiononthemapmaynotaccuratelydepictthedistancebetweenthestationsbutmayestimatethetransittimeinstead.Incontrasttoasubwaymapofacity,aroadmapofacityaccuratelydepictsthestreets,paths,andlocationsofsights. Both models depict the same reality, but with a different focus thatdefinespurpose-drivenabstractions.

Requirements models also have the advantage that the different types ofmodeling elements within the samemodeling language dictate the method ofabstractionaswellaswhatisbeingabstractedandwhatisnot.

6.1.5CombinedUseofModelsandNaturalLanguage

Usingbothnaturallanguageandrequirementsmodelsincombinationallowstheadvantagesofbothdocumentationtechniquestobeexploitedwhileminimizingtheir disadvantages. For example, natural language requirements can besummarizedand their interrelationsdepictedusingmodels.On theotherhand,natural language can help enrich requirementsmodels andmodeling elements

withadditionalinformation.

6.2GoalModels

Many methods in requirements engineering are based on the explicitconsideration of stakeholders’ intentions by means of goals (e.g., [vanLamsweerde et al. 1991] and [Yu 1997]). Ordinarily, the effort required toexplicitlyconsidergoalsduringrequirementsengineeringisminimal.However,thepositiveimpactonrequirementsengineering—ifgoalsaremodeled—andonthequalityandcomprehensivenessoftherequirementsisveryhigh.Goalsareastakeholder’s(e.g.,aperson’soranorganization’s)descriptionofacharacteristicpropertyofthesystemtobedevelopedorthedevelopmentproject.

Natural-language-basedandmodel-baseddocumentation

Goalsareverywellsuitedtorefinethevisionofthesystem.Refiningagoalis known as goal decomposition. Goals can be documented using naturallanguage (e.g., by means of predesigned templates) or using goal models. AwidelyknownandverycommongoalmodelingtechniqueistheuseofAND/ORtrees. By means of AND/OR trees, hierarchical decompositions can bedocumented. The type of refinement relation is depicted by graphicrepresentationsof thebranches.Thedirectionof thegoaldecomposition isnotrepresentedthroughbranchesbutthroughthetop-downstructureofthetree.

6.2.1GoalDocumentationUsingAND/ORTrees

Using AND/OR trees, two types of decomposition relationships can bedistinguished.Figure6-1 schematically shows these typesofdecompositionaswellastheirmodelingelements.

Figure6-1ModelingofgoaldecompositionusingAND/ORtrees

AND-decompositionvs.OR-decomposition

With regard to decomposition relations, one can differentiate between AND-decomposition and OR-decomposition. In case of AND-decomposition, everysub-goalmustbefulfilledsothatthesuper-goal(theroot)isfulfilled.Incontrast,inOR-decomposition, it suffices ifat leastonesub-goal is fulfilledso that thesuper-goalismet.

6.2.2ExampleofAND/ORTrees

Figure 6-2 shows an AND/OR tree that documents the hierarchicaldecompositionofthegoal“Comfortablenavigationtodestination”.

Figure6-2GoalmodelintheformofanAND/ORtree

ModelinggoalswithAND/ORtrees

As the goal model in figure 6-2 shows, the goal “comfortable navigation todestination” is refinedinto the threesub-goals“dynamicroutecalculationwithrespecttotrafficcongestion”,“comfortabledestinationinput”,and“comfortableroute guidance” viaAND-decomposition. This depicts that all three sub-goalsmust bemet to consider the super-goal fulfilled.The sub-goal “dynamic routecalculationwithrespecttotrafficcongestion”inturnisrefinedbythetwosub-goals“manualinputoftrafficconditions”and“automaticupdateoftrafficdata”.The typeof decomposition relationdepicts that onlyoneof the two sub-goalsmustbemettoconsiderthesuper-goalmet.

6.3UseCases

Usecaseswerefirstproposedin[Jacobsonetal.1992]asamethodtodocumentthefunctionalitiesofaplannedorexistingsystemonthebasisofsimplemodels.The use case approach is based on two concepts that are used in conjunctionwithoneanother:

UsecasediagramsUsecasespecifications

6.3.1UMLUseCaseDiagrams

Relationsbetweenusecases

Use case diagrams in the UML [OMG 2007] (see section 4.2.3) are simplemodels to schematically document the functions of a system from a user’sperspectiveandtodocumenttheinterrelationsofthefunctionsofasystemandtherelationsbetweenthesefunctionsandtheirenvironment.

ModelingElementsofUMLUseCaseDiagrams

Figure6-3showsthemostessentialmodelingelementsofusecasediagrams,asdefinedintheUnifiedModelingLanguage(UML)[OMG2007].

Figure6-3Essentialmodelingelementsofusecasediagrams

1. Usecases:Uses cases that are defined for the system are depicted usingovalshapes.Theseshapescontainthenameoftheusecase.Alternatively,thenamecanbewrittenbeneaththeusecase.

2. Actors: Actors are outside the system boundary and represent people orsystems that interact with the systemmodeled. Actors are depicted by arectangle that receives the name of the actor and is tagged with thestereotype“actor”.Iftheactorisaperson,astickfiguremaybeused.Iftheactor is a system, either a rectangle or a stick figure may be used inconjunctionwiththestereotype“system”.

3. Systemboundaries:Systemboundarieswithinausecasediagramseparatethepartsoftheusecasethatarepartofthesystemfromtheparts(peopleorsystems)thatareoutsidethesystemboundary.Optionally,thenameofthesystemmaybedenotedatthesystemboundaryinthediagram.

4. Extendrelation:AnextendrelationdepictsthataninteractionsequencethatbelongstousecaseAextendssomeinteractionsequenceinusecaseBataspecified point. This is known as the extension point. The extension istriggeredbytheconditiondefined.

5. Includerelation:Anincluderelationfromoneusecasetoanotherusecasedepicts that the interaction sequence of the first use case includes theinteractionsequenceoftheotherusecase.

6. Relation between actors and use cases: If communication between a usecase and one ormore actors takes place during the execution of the usecase,thecommunicationmustbeannotatedbymeansofacommunicationrelationbetweentherespectiveactorsandtheusecase.

ExampleofUMLUseCaseDiagrams

Figure6-4showsanexampleofausecasediagram.

Figure6-4Anexampleusingmodelingelementsofusecasediagrams

The model comprises the use cases “download traffic information”, “retrievecurrentposition”,and“inputnavigatetodestination”elements.Therelationsinfigure6-4thatarelabeledbynumbersareexplainedinfurtherdetailbelow:

Include

1. The use case “navigate to destination” is related to the use cases “inputdestination” and “retrieve current position” via an include relation. Therelationshipdepictsthattheinteractionstepsdefinedintheusecases“inputdestination” and “retrieve current position” are contained in the use case“navigatetodestination”.

Extend

2. Theextend relationbetween theusecases“download traffic information”and “navigate to destination” defines that the interaction steps defined intheusecase“downloadtrafficinformation”areincludedintheinteractionstepsoftheusecase“navigatetodestination”ifacertaincondition,suchas“avoidcongestion”,ismet.Theextensionpoint“avoidcongestion”depictsthe step in the use case “navigate to destination” atwhich the additionalinteractionstepsarebeingexecuted.

Generalization

UMLalsoprovidesageneralizationrelationbetweenusecasesoractors.Inthiscase,thespecializingusecasesoractorsinheritthepropertiesofthegeneralizingusecaseoractor(e.g.,[Rumbaughetal.2005]).Forinstance,theactors“servicemechanic”and“customerservicerepresentative”canbegeneralizedastheactor“employee”. The generalizing actor would carry all aspects that the actors“servicemechanic”and“customerservicerepresentative”haveincommon(e.g.,employeeID).

6.3.2UseCaseSpecifications

Use case diagrams show the system’s relevant functions from a user’sperspective and specific relationships between the functions of the system orbetween functionsof the systemandaspects in the system’s context.With theexceptionofausecase’snameanditsrelationships,usecasesdiagramsdonotdocumentanyinformationabouttheindividualusecasessuchasthesystematicinteraction between a use case and an actor. This information is documentedtextuallybymeansofadequatetemplatesinconjunctionwithusecasediagrams.

Referencetemplatesforthedocumentationofusecases

Pertinent literature proposes different templates for textual specification ofusecases(e.g., [Cockburn2001]).These templatesdefine typesof informationthat shouldbedocumented for ausecaseand suggest anappropriate structurefor the information. The template references therefore document experience-based knowledge regarding structured textual documentation of use cases. Inordertotextuallyspecifyusecases,thetemplateintable6-1issuitable.

Table6-1Templatefortextualusecasedocumentation

Rowsofausecasetemplate

Thetemplateforthespecificationofusecasescontainsthefollowingattributes:

Attributesforuniqueidentificationofusecases(rows1and2)Managementattributes(rows3through7)

Attributeforthedescriptionoftheusecase(row8)Specificusecaseattributes,e.g.,thetriggerevent(row9),actors(row10),pre-andpost-conditions (rows11 and12), the result of the use case (row13),themainscenario(row14),alternativeandexceptionscenarios(rows15and16),andcrossreferencestoqualityrequirements(row17)

Table6-2 shows the specification of the use case “navigate to destination” bymeansofthereferencetemplatesuggestedintable6-1.

Table6-2Exampleoftemplate-baseddocumentationofausecase

6.4ThreePerspectivesontheRequirements

Separatelydocumentingtheperspectives

When documenting requirements on the basis of models, one typicallydistinguishes three types of perspectives: data, function, and behavior (seesection 4.2.1). Each perspective is documented separately, using suitableconceptualmodelinglanguages[Davis1993],[Pohletal.2005]:

Dataperspective:Inthisperspective,thestructuresofinputandoutputdataas well as static-structural aspects of the usage and dependencyrelationshipsofthesysteminthesystemcontextaredocumented.Functionalperspective:Thisperspectivedocumentswhich informationofthesystemcontextisbeingmanipulatedbythesystemtobedevelopedandwhichdataisbeingtransmittedtothesystemcontextbythesystem.Behavioralperspective:Theembeddingofthesysteminthesystemcontext

isdocumentedon thebasisof states in thisperspective.This is done, forinstance, by documenting the reaction of the system to eventswithin thesystemcontext,documenting theconditions that triggerastatechange,ordocumentingtheeffectsthatthesystemhasonitsenvironment.

Examplesofthethreeperspectives

Figure6-5illustratesthethreeperspectivesonfunctionalrequirementsandgivesan example of a suitable modeling language for each perspective that can beusedtodocumenttherequirements.Thisway,requirementsaspectsthatpertainto thestaticstructurecanbemodeledusingUMLclassdiagrams, for instance.RequirementsinthefunctionalperspectivecanbemodeledusingUMLactivitydiagramsandrequirements in thebehavioralperspectivecanbemodeledusingstatecharts(seesections6.6and6.7).

Perspectivesarenotdisjoint.

Certainaspectsofthemodelsofaparticularperspectivecanalsobefoundinother perspectives. The three perspectives are therefore not disjoint. Forexample,thedata,whosestaticstructureisdefinedinaUMLclassdiagramcanpotentially also be found in the functional perspective because it depicts theinputs and outputs of actions in a UML activity diagram. As the threeperspectives are not disjoint, the models can be reciprocally checked forcompletenessandconsistencywithregardtotheinformationthatismodeledattheintersections.

Figure6-5Threeperspectivesonrequirements

6.5RequirementsModelingintheDataPerspective

Several different modeling languages are well suited to modeling structuralaspects of requirements in the data perspective.Commonly, entity-relationshipmodels,extensionsofthetraditionalentity-relationshipmodelaccordingtoChen[Chen1976.],and,increasingly,classdiagramsoftheUML(e.g.,[Rumbaughetal.2005])areusedasrequirementsmodelsofthedataperspective.

6.5.1Entity-RelationshipDiagrams

Thetraditionalentity-relationshipmodel

Traditionally, entity-relationship diagrams are used for modeling the dataperspective because they display the structure of an object of an universe ofdiscoursebymeansofentitytypesandrelationtypes[Chen1976].

Extensionsoftheentity-relationshipmodel

A number of extensions for the entity-relationship model have been

suggested. These extensions mainly concern the generalization/specializationrelations,inheritancemechanisms,androlesofentitiesandextendthemodelbya(min,max)-notationforcardinalitiesofrelations.

ModelingElementsofEntity-RelationshipDiagrams

According to [Chen 1976], the modeling language used to construct entity-relationshipdiagramsincludesthemodelingelementsdepictedinfigure6-6.

Figure6-6Importantmodelingelementsofentity-relationshipdiagramsaccordingtoChen

Classification:abstractionfromconcreteobjects

Entity types define a set of entities within the universe of discourse (that is,objectswiththesameproperties,suchaspeopleoritems).Anentitytype(oftenmistakenlyreferredtoasanentity)abstractsfromtheconcretecharacteristicsofthese entities and therefore classifies a set in the sense of the classification ofuniformentities.Forinstance,theentitytype“pilot”classifiesallpeoplewithinthe universe of discourse that have the characteristic of holding a pilotinglicense.

Abstractionfromconcreterelationships

Arelationtypeabstractsfromaconcretecharacteristicofarelationshipandofentitiesthatareinrelationtooneanother.Arelationtypeclassifiesthesetofuniform relations between entity types within the universe of discourse. Forexampletherelationtype“executes”canbedefinedbetweenthetwoentitytypes“pilot”and“flight”torepresentconcrete“executes”-relationsbetweenconcretepilots and concrete flights. If a concrete “is_passenger” relation is definedbetweenaconcretepassenger“JohnLocke”4andaconcreteflightwiththeflightnumber“OA815”5,thenthisrelationdepictsthat“JohnLocke”isapassengeroftheflightwiththeflightnumber“OA815”.

Propertiesofentitytypesandrelationtypes

An attribute can be defined for entity types as well as relation types. Anattribute defines the properties of an entity type or a relation type. Possibleattributesfortheentitytype“passenger”couldbe“familyname”,“givenname”,“passportnumber”,and“reservedseat”,forinstance.

Sketchlevelvs.instancelevel

An entity-relationship model documents the structure of a universe ofdiscoursebymeansofentitytypes(i.e.,classesofuniformentities)andrelations(i.e., classes of uniform relationships).An entity-relationshipmodel is definedon themodeling levelanddefines thesetofallvalid instanceson the instancelevel.

Numberofrelationinstances

Thecardinalityofa(binary)relationdefinesthenumberofrelationinstancesthatanentitymayparticipatein[ElmasriandNavathe2006].Ifnocardinalitiesareannotatedforaspecificrelationtype,itisassumedthatanarbitrarynumberof entities (in other words, at least zero entities) may participate in such arelation.Usingcardinalitiesforrelationsthereforelimitsthenumberofinstancesthatareprincipallypossibleinanentity-relationshipdiagram.

ExampleofanEntity-RelationshipDiagram

Theentity-relationshipmodelshowninfigure6-7showsfourentitytypes(i.e.,classes of entities) and three relation types (i.e., classes of relationships). Theindividualentitytypespossessattributesthatdescribespecificpropertiesoftheassociatedentities.Forexample,theentitytype“trafficjaminformation”hastheattributes“road”,“start”,and“length”,whichdepicttheroadonwhichatrafficjamiscurrentlypresent,theGPScoordinatesofthestartingpointofthejam,andthe length of the jam. The relation type “queries” between the entity types“navigation device” and “traffic jam information” means that on the instancelevel,arelationshipbetweenaconcretenavigationdeviceandtheinformationonzero ormore concrete traffic jams exists. The cardinalities of the entity typeswith regard to the relation type “queries” means that a concrete navigationdevicecanqueryinformationonanarbitraryamount(“N”)oftrafficjams.Inthe

other direction, any traffic jam information can be queried by an arbitrarynumber(“M”)ofnavigationdevices.

Figure6-7Entity-relationshipdiagram(datamodel)accordingtoChen

6.5.2UMLClassDiagrams

Staticperspective:data/structure

Class diagrams of the UML can be used to model the data perspective ofrequirementsofasystemtobedevelopedaswell.Aclassdiagramconsistsofasetofclassesandassociationsbetweenclasses.ClassesandassociationsinUMLclassdiagramsaresimilartoentitytypesandrelationtypesinentity-relationshipdiagrams.Classmodels possess additionalmodeling elements (e.g., that allowforthespecificationofvalidoperationsontheinstancesofaclass)andthushaveagreaterpowerofdescription.6

Figure6-8ImportantmodelingelementsofclassdiagramsofUML

ModelingElementsofClassDiagrams

Figure6-8showsimportantmodelingelementsofclassdiagramsoftheUMLaswellasanumberofmodelingexamples.

Classes

Aclassisdepictedbyarectanglethatisseparatedintosections(alsocalledcompartments).Intheuppersection,attributesaredepictedthataredescribedinmoredetailbytheinstancesoftheclass.Inthelowersections,alloperationsthatcan be performed on the instances of the class are listed. Depending on themodelinggoal, i.e., dependingon thepurposeof themodel, thecompartmentsforattributesand/ormethodscanalsobehiddenorleftoutentirely.

Associations,multiplicities,androles

Associations between classes are depicted by edges. Associations canoptionallybegivenaname.Inaddition,multiplicitiescanbeannotatedateachendofanassociation.Multiplicitiesarestatementsabouttheinstancelevelofa

classanddepicthowmanyinstancesofaclassmaybeassociatedinaparticularwaywithadefinednumberofinstancesofanotherclass.Byannotatingoptionalroles at one or both ends of an association, themeaning of the instances of aclasswithregardtotheassociationcanthefurtherrefined.

Aggregationandcomposition

Aggregations and compositions are specific types of associations. Bothdescribe a relationship between a whole and its constituents. A compositiondocuments a stronger binding than an aggregation in that a constituent in acomposition cannot exist without its whole. In class models of the UML, anaggregationisdepictedasanemptydiamondandacompositionisdepictedasafilleddiamond.

Generalization

Moreover, in class diagrams, generalizations between classes can bedocumented. A generalization between classes of the UML is a relationshipbetweenamorespecificclass(thesub-type)andamoregeneralclass(thesuper-type). The sub-type in a generalization relation inherits all properties of thesuper-typeandcanadaptand/orextendthese.

ExampleofaUMLClassDiagram

The class diagram in figure 6-9 comprises six classes that all have respectiveattributes.Theassociationsbetweentheclassesaredepictedbymeansofedges.Forexample,anassociationwiththename“calculates”existsbetweentheclass“navigationdevice”andtheclass“route”.Takingintoaccountthemultiplicities,this association depicts that a navigation system can calculate an arbitraryamount(atleastzero,asdepictedbyanasterisk)ofroutes.Inreturn,everyroutecanbecalculatedbyanarbitraryamount()ofnavigationdevices.Arouteisanaggregationofatleastone,butarbitrarilymany(1..*)roadsegments,andeveryroad segment belongs to an arbitrary amount (*) of routes.A road segment isdefinedbya roadnameaswellas startandendpoints.Figure6-9alsoshowsthat“navigationdevicew/congestionavoiding”isaspecializationofthegenerictype “navigation device”. The sub-type “navigation device w/ congestionavoiding”inheritstheproperties(inthiscase,theattribute“identification”)fromits super-type “navigation device” and extends the set of attributes by an

attributethatspecifiesthethresholdlengthofatrafficcongestion,whichtriggersarouterecalculation.

Figure6-9ClassdiagraminUMLnotation

6.6RequirementsModelingintheFunctionalPerspective

The functional perspective of requirements deals with the transformation ofinput data received from the environment into output data released into theenvironment of the system. There are a number of different model-basedapproachesthatcanbeusedtomodelthefunctionalperspectiveofrequirements.The majority of these techniques is based on the structured system analysisapproaches of the 1970s and 1980s, such as the structured analysis [DeMarco1978,Weinberg1978]ortheessentialsystemanalysis[McMenaminandPalmer1988.].

6.6.1DataFlowDiagrams

At the center of attention of modeling requirements from a functionalperspectivearediagramsthatmodelthefunctionalityoftherespectivesystembymeans of processes (functions), data stores, sources, and sinks in the systemenvironmentaswellasdataflow.Acommonlyusedtypeoffunctionalmodelsare data flow diagrams, as suggested in the structured analysis according to[DeMarco 1978]. Data flow models allow modeling the system on differentlevelsofabstraction.

ModelingElementsofDataFlowDiagrams

Figure6-10showsthemodelingelementsindataflowdiagramsinthenotationsuggestedby[DeMarco1978].

Figure6-10ImportantmodelingelementsofdataflowdiagramsaccordingtoDeMarco

Datamanipulation

Processesdepictthefunctionsofaparticularsystemnecessarytotransformthedata that flows into the system (information flow).7 A process consumes theinput data, processes this data, and outputs the result of the processing in theformof output data.How the data is transformed is not depicted in data flowdiagrams.

Restingdata

Data stores are abstract concepts designed to depict persistent data.Processescanaccessdatainadatastoreinareadandwritemannersothattheprocessesmayaccessnecessaryinputdataorpersistentlystoreoutputdata.

Objectsinthesystemenvironment

Sources/sinks describe objects (like people, groups of people, departments,organizations,orsystems)intheenvironmentofthesystemthatexchangedatawiththesystem.Sources/sinksareaspectsofthesystemenvironmentandcannotbealteredduringsystemdevelopment (seesection2.1).Sourcesareaspectsofthesystemenvironmentthatdeliverdatatothesystem,whilesinksreceivedatafromthesystem.

Flowingdata

Adataflowdescribesdatathatistransportedbetweenprocesses,datastores,and sources/sinks [Yourdon 1989]. In requirements models, a data flow can

model both the transport ofmaterial and immaterial objects, e.g., informationflowormaterialflow.Typically,onlythemostimportantdataflowsaremodeledindata flowdiagrams.Data flows thatarenot relevant for therequirementsofthesystemcanbeneglected.

ExampleofaDataFlowDiagram

Systeminterfaces

Figure6-11showsasimplifieddataflowdiagramofanavigationsysteminthenotationsuggestedbyDeMarco.Theinterfacesofthesystemtothecontextaredefined by the data flows to the sources “GPS satellite system” and “trafficinformationserver”aswellastothesink“driver”.

Process“calculateroute”

The functionality of the navigation system is separated into three distinctprocesses. Process one, named “calculate route”, receives up-to-date trafficinformationviaitsinterfacetothesource“trafficinformationserver”aswellasdata about the current location via its interface to the source “GPS satellitesystem”. Inaddition, theprocess“calculate route” isprovidedwith thedesireddestinationbythedriverofthevehicle.Thecalculatedrouteisstoredinthedatastore“routedata”.

Process“determinenextwaypoint”

Process two—“determine next waypoint”—accesses the data store andretrieves data concerning the current route. The process determines the nextwaypointandoutputsthisinformation.

Process“recalculateroute”

Processthree—“recalculateroute”—plotsanewcoursetothedestination.Inordertodoso,itgatherstrafficinformationfromthesource“trafficinformationserver” and, potentially, information about the current location. The newlycalculatedcourseisstoredinthedatastore“routedata”.

Figure6-11DataflowdiagraminthenotationsuggestedbyDeMarco

6.6.2ModelsoftheFunctionalPerspectiveandControlFlow

In data flow diagrams, it cannot be seen which conditions trigger whichprocesses.Dataflowdiagramsmerelydepictdatadependenciesoftheprocessesin a system and document necessary input and generated output data.Approaches used in structured system analysis, however, often offercomplementary behavioral descriptions and control flow descriptions. This isachieved either by using distinct documentation forms, such as mini-specificationsinstructuredanalysis,orbymeansofimplicitlanguageextensionsofdata flowmodels.Languageextensionsoffer theability tomodeladditionalaspects,e.g., thecontrol flowbetweenfunctions,asdone inSA/RT[WardandMellor1985,HatleyandPirbhai1988].

6.6.3UMLActivityDiagrams

UMLactivitydiagramsarewellsuitedtomodelactionsequences[OMG2007].AlongwithactivitydiagramsinUML,event-drivenprocesschains(EPC)canbeused to model sequences of activities [Keller et al. 1992], especially ininformationsystemdevelopment.UMLactivitydiagramsdepictthecontrolflowbetween activities or actions. In case of a sequential progression of actions, asubsequentactionisexecutedonceeveryprecedentactionterminates.Figure6-

12 shows important modeling elements of activity diagrams in UML [OMG2007].

Figure6-12ModelingelementsofactivitydiagramsoftheUML

Actionnodes

Activitydiagramsare control flowgraphs that consist of actionnodes and thecontrol flow between these action nodes (i.e., the arrows in the control flowgraphdepicting transitions).Actionnodesexecuteanaction.Thestartandendnodesinactivitydiagramshavedefinedsemantics.Thestartnoderepresentsaneventthat initiatestheexecutionoftheactivitydiagram.Endnodesarespecialnodesthatrepresenttheterminationoftheactivitydiagram.

Controlflows,objectflows,responsibilities

Depicting alternative control flows in activity diagrams can be achievedthrough the use of decision nodes. At decision nodes, conditions that triggeralternativecontrol flowsareannotated. Inaddition, synchronizationbarsallowfor concurrent execution of control flows.A special type of control flows areobject flows. By making use of activity partitions (swimlanes), differentactivitiescanbedocumentedastheresponsibilityofspecificactors.

SequenceModelingusingUMLActivityDiagrams

The activity diagram in figure 6-13 documents the process “navigate todestination”. Input andoutputdata canbedocumentedbymodelingadditional

object flows along the edges. The data and object flows are special types ofcontrol flows of the activity diagram. Every action is executed if and only ifprevious actions have been carried out and all incoming object flows areavailable. The action diagram in figure 6-13 also shows object flows that aredocumentedinadditiontotheactionsandcontrolflows.

Figure6-13ActivitydiagraminUMLnotation

Theactivitydiagramabovedocuments thesequenceofactionsnecessary foranavigation device to calculate a route. Themodel documents that initially thedesireddestinationisaskedforandthatthecurrentlocationisdetermined.Thesetwo actions happen concurrently, independent from one another. The inputdestination(objectflow:object destination;state input)andthedeterminedlocation(objectflow:object location;state determined)arerelayed.Ifthedriver has opted to automatically circumvent traffic congestions, the systemqueriesforup-to-datetrafficinformation.Oncetheupdatedtrafficinformationis

receivedorif thedriverhasnotselectedtocircumventtrafficjams, thesystemcalculatesaroutetothedestination.Thecalculatedrouteisoutputtothedriver.

Modelingsequencesofausecase

Activity diagrams are well suited to document the relationships andexecution conditions of main, alternative, and exception scenarios. Decisionnodes represent branches in the control flow between the main scenario andalternativeandexceptionscenarios.

ControlFlowofMainandAlternativeScenarios

The activity diagram in figure 6-14 shows the control flow of the main andalternativescenarioof theusecase“navigate todestination”asdocumented intable 6-2. Alternative control flow branches begin at the decision nodes thatdocumenttherespectivealternative-andexceptionscenariostoaparticularmainscenario.

Mainandalternativescenarios

The activity diagram shows that initially, the action “start navigation” isexecuted. After that, the actions “input destination” and “determine GPScoordinates”areexecutedconcurrentlyandindependentfromoneanother.Onceboth actions have been executed, the system asks the driver if he wishes theroutetobecalculateddynamically(action“askfordesiretocalculatetheroutedynamically”). If the driver does not request the route to be calculateddynamically (selection “do not avoid congestions”), no specific action isexecuted (see table 6-1 main scenario). If the driver selects dynamic routecalculation (selection “avoid congestions”), updated traffic information isdetermined (action “query traffic info”, see table 6-1 alternative scenario).After that, the route is calculated (action “calculate route”) and output to thedriver(action“outputroute”).

Figure6-14DocumentationofthecontrolflowofscenariosusingUMLactivitydiagrams

6.7RequirementsModelingintheBehavioralPerspective

Finite-stateautomata

To model the dynamic behavior of a system, modeling approaches based onautomata theory are typically employed. The definition of a finite-stateautomatoncomprisesasetofstatesandasetoftransitionsthat,dependentonthecurrentstateoftheautomaton,areperformedgivensomeevent.

MealyandMooreautomata

In the scope of system modeling, extensions of finite-state automata arefrequentlyusedthatarebasedontheconceptsofso-calledMealy[Mealy1955]andMooreautomata[Moore1956],respectively.InMealyautomata,theoutputofanautomatondependsonthecurrentstateoftheautomatonaswellasontheinput.Incontrast,inMooreautomata,theoutputmerelydependsonthecurrentstate.

6.7.1Statecharts

Statecharts=statemachines+hierarchization+conditions+concurrency

Duetochallengesthatarisewhenusingfinitestateautomatainpractice(suchasmissingsupportforabstraction),theautomataconcepthasbeendevelopedintoatechnique of modeling the reactive behavior of a system. A widely appliedtechnique to model the behavior of a system is the use of statecharts [Harel1987].Statechartsarea typeofautomata that isbasedon finite-stateautomatabutareextended tosupporthierarchizationofstates todocumentconditionsofstate transitions and to model concurrent behavior. Figure 6-15 shows themodeling elements of statecharts in the notation suggested by Harel [Harel1987].

Figure6-15Modelingelementsofstatecharts

State

Astatedefinesaperiodoftimeinwhichthesystemshowsaspecificbehaviorandwaitsforaparticulareventtooccurinordertoperformadefinedtransition.

Transitionwithconditionandactivity

A transition is triggered by a particular event once it occurs in a specific

state.Atransitiondescribesthechangefromonestatetothenext.Thechangeofstatescanadditionallybedependentonsomecondition.Thesystemcanperformparticularactivitiesifitisinaparticularstate(typicalforMooreautomata)orifit performs a transition to another state (typical for Mealy automata). Theseactivities can be directed toward the system itself or the environment of thesystem.

Hierarchizationandabstraction

Statecharts allow for the hierarchical refinement of states that in turnrepresentautomata.Theinitialstateisreferredtoassuperstateandisdefinedbya number of refining states. Hierarchization allows abstracting from theirrelevantdetailsof a stateby—dependingon thepurposeof themodel—onlyregardingand/ormodeling the super state rather than theentire subautomatonthatdefinesthesuperstate.Thedetailedbehaviorofthesystemcan,ifnecessary,berefinedbydefiningtherespectivepartialautomata.

Concurrency

Alongwith hierarchical decomposition of a state into refining automata, astate can be decomposed into several concurrent automata. The concurrentautomata can be synchronized by means of transition conditions (e.g., “ifautomatonAisinstate4”).Figure6-16showsabehaviormodelforanavigationdeviceofavehiclebymeansofastatechart.Thenavigationdeviceisinitiallyinthestate“navigationdeviceinactive”.

Figure6-16Simplifiedstatechartofavehicularnavigationdevice

Transitionintosuperstate

Byturningonthenavigationdevice(event:“navigationdeviceactivated”), thesystemtransitionsintothesuperstate“navigationdeviceactive”(moreprecisely,the system transitions into the initial state “noGPS signal” of the super state“navigationdeviceactive”).Thesuperstate“navigationdeviceactive”isrefinedbyapartialautomatonthatconsistsoftwostates.Forexample,ifaGPSsignalisreceived in the state “navigation device active: no GPS signal”8. the systemtransitions into the state “navigation device active: GPS signal” and issues anotification. If the device is deactivated while in the state “navigation deviceactive”(event:“navigationdevicedeactivated”), thesystemtransitions into thestate“navigationdeviceinactive”.

6.7.2UMLStateDiagrams

ModelingreactivebehaviorofasystemusingUML

Inordertomodelreactivesystembehavior,UnifiedModelingLanguage(UML)[OMG 2007] offers so-called state machines that are essentially based onstatecharts.Figure6-17 shows themost importantmodelingelementsofUMLstatediagrams.Thenotationof themodelingelementsofUMLstatediagramshas largely been adopted from statecharts. However, UML 2 extends themodelingelementsofstatecharts,e.g.,bytheabilitytodefineexplicitentryandexitpointsofhierarchicalstates[OMG2007].

Figure6-17ModelingelementsofstatemachinesasdefinedbytheUML2

Statesandtransitions

Justasinstatecharts,astatedefinesaperiodoftimeinwhichasystemshowsaparticular behavior and waits for a particular event to occur. A transition is

triggeredbyanevent thatoccurs inaparticularstateanddescribes thechangefrom one state to the next. A transition can be dependent on a condition. Inaddition,thesystemcanperformactionsthataredirectedtowardthesystemoritsenvironment.

Hierarchizationandconcurrency

Dependingonthepurposeofthemodel,statemachinesallowhierarchicallycombiningstatesintosuperstates,therebyabstractingfromthepotentiallyverycomplexbehaviorofthesestates.Asidefromhierarchicallydecomposingstatesbymeansofpartialautomata,astatecanbedecomposedintoseveralconcurrentstate machines. Just as in statecharts, synchronization of concurrent statemachinescanbeachievedusingconditions.

Encapsulationofinternalstatesusingentryandexitpoints

UML2definesentrypointsandexitpointsasanextensionofstatechartsthatallow for additional hierarchization of states. An exit point is an externallyvisiblepseudo-statethatisimmediatelyassociatedwithaninternalstate.Anexitpointisanexternallyvisiblepseudo-statethathasitsorigininaninternalstate.A super statewithin a statemachine can have arbitrarilymany entry and exitpointsthatcanbeidentifiedbyaname[Rumbaughetal.2005].

Figure 6-18 shows a state diagram of UML that possesses two explicitlydefinedentrypoints (“enternewdestination”and“lastdestination”)aswellasone exit point (“navigation successful”) along with the modeling elementsintroducedinsection6.7.1.

Figure6-18StatediagraminUML2notation

Thestatediagraminfigure6-18documentsthereactivebehaviorofanavigationdevice.Initially,thesystemisinthestate“deviceready”.Byselecting“navigateto...”,thesystemchangesintothesuperstate“navigationactive”and,withinthesuperstate, intothesubstate“enterdestinationdata”bymakinguseoftheentrypoint“enternewdestination”.Alternatively,thesystemchangesfromthestate“deviceready”intotheinternalstate“routecalculation”ofthesuperstate“navigationactive”bymakinguseoftheentrypoint“lastdestination”assoonasthe event “navigate to last destination”occurs.Once the system is in the state“navigationactive: enterdestinationdata”, the system transitions into the state“navigationactive:routecalculation”iftheconditionthatthedestinationdataisvalidhasbeenmet.

Once the route is calculated in the state “navigation active: routecalculation”, the system transitions into the state “navigation active: outputroute”. If a deviation from the route is detected (event: “deviation fromcalculatedroute”)inthestate“navigationactive:routecalculation”,thedriverisnotified(activity:“notifydriver”).Fromthestate“navigationactive”,thesystemtransitions into the state “device ready” once the event “cancel” occurs. If thesystemisinthestate“navigationactive:routecalculation”andthedestinationisreached, the system exits the super state “navigation active” via the exit point“navigationsuccessful”totransitionintothestate“deviceready”.

6.8Summary

Alongwithusingnaturallanguagetodocumentrequirements,requirementscanbe documented bymeans ofmodels. Typically, natural language requirementsand requirements models are frequently employed in conjunction so that theadvantagesofbothformsofdocumentationcanbeexploited.

Model-based documentation of requirements has, among other things, theadvantage that graphical (imagelike) descriptions of circumstances can beunderstood faster and better than natural-language descriptions. Among themodels that are frequently used in requirements engineering are goal models(e.g.,intheformofAND/ORtrees)andusecasediagramsaswellasconceptualmodelstodocumentrequirementsfromthreeperspectives:data,functional,andbehavioral. For each of these three perspectives, there are suitable conceptualmodeling languages that provide purpose-specific means to document the

informationdepictedineachrespectiveperspective.

4.Moreprecisely,thereisanentitythatisaninstanceoftheentitytype“passenger”thatpossessesauniqueidentityandhastheattributevalue“JohnLocke”fortheattribute“name”.

5.Moreprecisely, there isanentity that isan instanceof theentity type“flight” thatpossessesauniqueidentityandhastheattributevalue“OA815”fortheattribute“flightnumber”.

6.AcomprehensiveoverviewofthedifferentmodellingelementsoftheUMLcanbefounde.g.,in[OMG2007].

7.Inthestructuredanalysis,theflowofdata,information,documents,ormaterialisconsideredadataflow.8.Foruniqueidentification,astatethatispartofasuperstateisreferencedby“superstate:state”.Thestate

“noGPS signal” in the super state “navigation device active” is therefore referenced as “navigationdeviceactive:noGPSsignal”.

7RequirementsValidationandNegotiation

Validation andnegotiationduring requirements engineering ismeant to ensurethat thedocumentedrequirementsmeetthepredeterminedqualitycriteria,suchas correctness and agreement (see section 4.6). The introduced principles andtechniques can be used to validate and negotiate individual requirements orentirerequirementsdocuments.

7.1FundamentalsofRequirementsValidation

During the requirements engineering activity, it is necessary to review thequality of the requirements developed. Among others, the requirements arepresented to the stakeholderswith the goal to identify deviations between therequirementsdefinedandthestakeholders’actualwishesandneeds.

Approvingrequirements

During requirements validation, the decision of whether a requirementpossessesthenecessarylevelofqualityismade(seechapter4)andwhethertherequirementcanbeapprovedtobeusedforfurtherdevelopmentactivities(suchas design, implementation, and testing). This decision should bemade on thebasisofpredefinedacceptancecriteria.

Goalofvalidation

The goal of requirements validation is therefore to discover errors in thedocumented requirements. Typical examples of errors in requirements are

ambiguity,incompleteness,andcontradictions(seesection7.3).

Errorproliferation

Requirements documents are reference documents for all furtherdevelopment activities. Therefore, errors negatively affect all furtherdevelopmentactivities.Arequirementserrorthatisdiscoveredwhenthesystemisalreadydeployedandoperatingrequiresallartifactsaffectedbytheerrortoberevised, such as source code, test artifacts, and architectural descriptions.Correcting errors in requirements once the system is in operation thereforeentailssignificantcosts.

Legalrisks

A contract between client and contractor is often based on requirementsdocuments.Critical errors in requirements can lead to the fact that contractualagreementscannotbemet,e.g.,scopeofsupplyandservices,expectedquality,orcompletiondeadlines.

7.2FundamentalsofRequirementsNegotiation

Contradictoryrequirementscauseconflicts.

If there is no consent among the stakeholders regarding the requirements andthus the requirements cannot be implemented collectively in the system, aconflict arises between the contradictory requirements as well as between thestakeholders that demand contradictory requirements. For example, onestakeholdercoulddemandthesystemtoshutdownincaseofafailure,whereasanotherstakeholdercouldrequirethesystemtorestart.

Risksandopportunitiesofconflicts

The acceptance of a system is threatened by unresolved conflicts becauseunresolvedconflictscausetherequirementsofatleastonegroupofstakeholderstonotbeimplemented.Intheworstcase,aconflictcausesstakeholdersupporttocease, causing the development project to fail (cf. [Easterbrook 1994]). Otherthan posing risks, conflicts can also be an opportunity for requirements

engineering because conflicts between stakeholders require a solution that canpotentiallyhelpdiscovernewideasfordevelopmentandcanillustratedifferentoptions (cf. [Gause and Weinberg 1989]). Therefore, treating and resolvingconflictsopenlyduringrequirementsengineeringcanincreaseacceptance.

Goalofrequirementsnegotiation

Thegoalofnegotiationistogainacommonandagreed-uponunderstandingof the requirements of the system to be developed among all relevantstakeholders.

Reducingcostsandrisksinlatephases

Requirements validation and negotiation is an activity that must beperformed (to a varying degree of intensity) throughout the entirety ofrequirements engineering. The validation and negotiation of requirementstherefore causes additional effort and therefore additional costs. However, theadvantages gained by performing requirements validation and negotiation asdescribed in the previous sections (reduction of overall cost, increase inacceptance,supportingcreativityandinnovations)isusuallysignificantlyhigherthanthecoststhatariseduetotheincreasedeffort.

7.3QualityAspectsofRequirements

A major aim of using quality criteria (e.g., completeness, understandability,agreement) in requirements validation is to be able to check requirementssystematically(seesection1.1.2).Inordertoassureanobjectiveandconsistentvalidation,itisnecessarythateachqualitycriterionisconcretizedandrefined.Incorrespondencewith theoverallgoalsof therequirementsengineeringprocess,thevalidationiscarriedoutwiththefollowinggoals:

Content:Haveallrelevantrequirementsbeenelicitedanddocumentedwiththeappropriatelevelofdetail?Documentation: Are all requirements documented with respect to thepredeterminedguidelinesfordocumentationandspecification?Agreement:Doallstakeholdersconcurwith thedocumentedrequirementsandhaveallknownconflictsbeenresolved?

Threequalityaspects

Eachof the threegoals impliesanindividualapproachthatfocusesonspecificaspectsofthequalityoftherequirements.Therefore,thefollowingthreequalityaspectshavebeendefined:

Qualityaspect“content”Qualityaspect“documentation”Qualityaspect“agreement”

Arequirementshouldbeapprovedforfurtherdevelopmentactivitiesonlyifallthree quality aspects have been checked. The quality aspects are described indetailinthefollowingsectionsandmadeconcretethroughdifferentfine-grainedqualitycriteria(withnoclaimofcompleteness).

7.3.1QualityAspect“Content”

Thequalityaspect“content”referstothevalidationofrequirementswithrespecttoerrorsinthecontent.Errorsinrequirementswithregardtocontentnegativelyinfluencethesubsequentdevelopmentactivitiesandcausetheseactivitiestobebaseduponerroneousinformation.

Testcriteriaofthequalityaspect“content”

Errors in requirements with regard to content are present when specificqualitycriteriaforrequirements(seesection4.6)orforrequirementsdocuments(seesection4.5)areviolated.Thevalidationofrequirementswithregardtothequality aspect “content” is successful once requirements validation has beenappliedtothefollowingerror typesandnosignificantshortcomingshavebeendetected:

Completeness(setofallrequirements):Haveallrelevantrequirementsforthesystemtobedeveloped(forthenextsystemrelease)beendocumented?Completeness(individualrequirements):Doeseachrequirementcontainallnecessaryinformation?Traceability:Have all relevant traceability relationsbeendefined (e.g., torelevantrequirementssources)?

Correctness/adequacy: Do the requirements accurately reflect the wishesandneedsofthestakeholders?Consistency: Is it possible to implement all defined requirements for thesystemtobedevelopedjointly?Aretherenocontradictions?Noprematuredesigndecisions:Arethereanyforestalleddesigndecisionspresentintherequirementsnotinducedbyconstraints(e.g.,constraintsthatspecifiyaspecificclient-serverarchitecturetobeused)?Verifiability:Isitpossibletodefineacceptanceandtestcriteriabasedontherequirements?Havethecriteriabeendefined?Necessity:Doeseveryrequirementcontributetothefulfillmentofthegoalsdefined?

7.3.2QualityAspect“Documentation”

The quality aspect “documentation” deals with checking requirements withrespect to flaws in their documentation or violations of the documentationguidelines that are in effect, such as understandability of the documentationformats and the consideration of organizational or project-specific guidelinesregarding the documentation of requirements but also the structure of therequirementsdocuments.

Implicationsoftheviolationofdocumentationguidelines

Ignoring thedocumentationguidelinescan,amongother things, lead to thefollowingrisks:

Impairment of development activities: It may be impossible to carry outdevelopmentactivitiesthatarebaseduponaspecificdocumentationformat.Misunderstandings: Requirements may not be understandable or may bemisunderstoodbythepeoplethatneedtocomprehendthem.Asaresult,therequirementmaybeunusable.Incompleteness: Relevant information is not documented in therequirements.Overlooking requirements: If requirements are not documented at theposition that they are supposed to in the requirements document, theserequirementsmaybeoverlookedinsubsequentactivities.

Testcriteriaofthequalityaspect“documentation”

Requirements validation with regard to the quality aspect “documentation” issuccessfulwhenrequirementsvalidationhasbeenappliedtothefollowingerrortypesandnosignificantshortcomingshavebeendetected:

Fourtestcriteriaofthequalityaspect“documentation”

Conformitytodocumentationformatandtodocumentationstructures:Aretherequirementsdocumentedinthepredetermineddocumentationformat?For instance, has a specific requirements template or a specificmodelinglanguagebeenusedtodocumenttherequirements?Hasthestructureoftherequirements document been maintained? For instance, have allrequirements been documented at the position defined by the documentstructure?Understandability:Canalldocumentedrequirementsbeunderstoodin thecontextgiven?Forinstance,havealltermsusedbeendefinedinaglossary(seesection4.7)?Unambiguity:Does thedocumentationof the requirementsallow foronlyone interpretation or are multiple different interpretations possible? Forinstance,doesatext-basedrequirementnotpossessanykindofambiguity?Conformitytodocumentationrules:Havethepredetermineddocumentationrulesanddocumentationguidelinesbeenmet?Forinstance,hasthesyntaxofthemodelinglanguagebeenusedproperly?

7.3.3QualityAspect“Agreement”

The quality aspect “agreement” dealswith checking requirements for flaws intheagreementofrequirementsbetweenstakeholders.

Lastopportunityforchanges

During the course of requirements engineering, stakeholders gain novelknowledgeaboutthesystemtobedeveloped.Duetothisadditionalknowledge,the opinion of the stakeholders regarding a requirement that has already beenagreeduponcanchange.Duringrequirementsvalidation,stakeholdershavetheopportunity torequestschangeswithout impairingthesubsequentdevelopment

activities.Requirements validation with regard to the quality aspect “agreement” is

successfulwhenrequirementsvalidationhasbeenappliedtothefollowingerrortypesandnosignificantshortcomingshavebeendetected:

Threetestcriteriaofthequalityaspect“agreement”

Agreed:Iseveryrequirementagreeduponwithallrelevantstakeholders?Agreedafterchanges: Is every requirement agreeduponwith all relevantstakeholdersafterithasbeenchanged?Conflicts resolved: Have all known conflicts with regard to therequirementsbeenresolved?

7.4PrinciplesofRequirementsValidation

Consideringthefollowingsixprinciplesofrequirementsvalidationincreasesthequalityofthevalidationresults:

Principle1:InvolvementofthecorrectstakeholdersPrinciple2:SeparatingtheidentificationandthecorrectionoferrorsPrinciple3:ValidationfromdifferentviewsPrinciple4:AdequatechangeofdocumentationtypePrinciple5:ConstructionofdevelopmentartifactsPrinciple6:Repeatedvalidation

Theindividualprinciplesareexplainedinthefollowingsections.

7.4.1Principle1:InvolvementoftheCorrectStakeholders

Thechoiceofstakeholdersforrequirementsvalidationdependsonthegoalsofthevalidationaswellastherequirementsthataretobeaudited.

Whenassemblingtheauditingteam,atleastthefollowingtwoaspectsoughttobeconsidered.

Independenceoftheauditor

Generally, it shouldbeavoided that theauthorofa requirement isalso theperson to validate it. The authorwillmake use of his or her prior knowledgewhenreadingorreviewingtherequirement.Thispriorknowledgecannegativelyinfluencetheidentificationoferrorsbecausepotentialerroneouspassagesoftherequirements documentation or the requirements are implicitly andsubconsciouslyamendedbytheauthor’sownknowledgeandcanthuseasilybeoverlooked.

Internalvs.externalauditors

Suitable auditors can be identified within or outside of the developingorganization.Internalauditsareperformedbystakeholdersthataremembersofthedevelopingorganizationandcanbeused tovalidate intermediate resultsorpreliminary requirements. An internal validation is easy to coordinate andorganizebecausethestakeholdersareavailablefromwithintheorganization.Anexternalauditrequiresahigherdegreeofeffortbecauseitidentifiesauditorsand(potentially) hires them for payment. In addition, external auditors have tobecomefamiliarwiththecontextofthesystemtobedeveloped.Duetothehigheffort,anexternalauditshouldbeperformedonlyonrequirementsthatexhibitahighlevelofquality.

7.4.2Principle2:SeparatingtheIdentificationandtheCorrectionofErrors

Basicprinciple

Separationbetweenidentifyingerrorsandactuallyfixingthemhasprovenitselfinthedomainofsoftwarequalityassurance.Thesameprinciplecanbeappliedto requirements validation. During validation, the flaws identified aredocumented immediately.After that, each flaw identified is double-checked todeterminewhetheritreallyisanerror.

Concentratingonerroridentification

Separating error identification and error correction allows auditors toconcentrateon the identification.Measures tocorrect theerrorsare takenonlyafteridentificationmeasureshavebeencompleted.Thishastheadvantagesthat

the resources available for error correction can be used purposefully, thatpremature error identification does not create additional errors, and that noallegederrorisfixedthatdidnotneedfixingbecausefurtherinvestigationoftheerrormay result in the fact that anallegederror is in factnoerrorat all.Thatway, potentially present significant errors are less likely to be overlookedbecause the auditor is concentrating on fixing a previous error instead ofidentifyingnewones.

7.4.3Principle3:ValidationfromDifferentViews

Perspective-basedvalidation

Validatingrequirementsfromdifferentviewsisanotherprinciplethathasprovenitself inpractice. In thisprinciple, requirementsarevalidatedandagreeduponfrom different perspectives (e.g., by different people, see section 7.5.4).Comparable methods are used in other disciplines as well. For instance, in alegal trial, circumstances are often reported from the perspective of differentpeoplesothatasoundoverallpicturecanbegained.

7.4.4Principle4:AdequateChangeofDocumentationType

Strengthsandweaknessesofdocumentationtypes

Changing the documentation type during requirements validation uses thestrengths of one documentation type to balance out the weaknesses of otherdocumentation types. For instance, good understandability and expressivenessare strengths of natural language texts. However, their weakness is potentialambiguityanddifficulty inexpressingcomplexcircumstances.Graphicmodelsare able to depict complex circumstances rather well, but the individualmodelingconstructsarerestrictedinexpressiveness.

Simpleridentificationoferrors

Transcribing a requirement that is already documented in another form ofdocumentation simplifies finding errors. For instance, ambiguities in naturallanguagerequirementscanbeidentifiedmucheasierbytranscribingthemintoa

model-basedrepresentation.

7.4.5Principle5:ConstructionofDevelopmentArtifacts

Suitabilityoftherequirementsfordesign,test,andmanualcreation

Constructingdevelopmentartifactsaimsatvalidatingthequalityofrequirementsthat aremeant to be the basis of creating design artifacts, test artifacts, or theusermanual.During the course of the validation, the activities usually carriedout during subsequent phases to construct respective development artifacts arecarriedoutforsmallsamples.Forinstance,theauditorintensivelydealswitharequirement by creating a test case. This way, errors (e.g., ambiguity) can beidentifiedintherequirement.Thiskindofvalidation,however,demandsalotofresourcesbecausesubsequentdevelopmentactivitiesmustbeexecutedatleastinpart.

7.4.6Principle6:RepeatedValidation

Validationoccursatadistinctpointintimeduringthedevelopmentprocessandrelies on the level of knowledge of the auditors at that point in time. Duringrequirementsengineering,thestakeholdersgainadditionalknowledgeabouttheplanned system. Therefore, a positive validation of requirements does notguaranteethatrequirementsarestillvalidatalaterpointintime.Requirementsvalidationshouldoccurmultipletimesinthefollowingcases(amongothers):

LotsofinnovativeideasandtechnologyusedinthesystemSignificantgainofknowledgeduringrequirementsengineeringLong-lastingprojectsVeryearlyrequirementsvalidationUnknowndomainRequirementsthataretobereused

7.5RequirementsValidationTechniques

Inthefollowingsections,techniquesforrequirementsvalidationareintroduced.Often,manualvalidationtechniques,whicharealsoknownbythegeneraltermreview,areusedforrequirementsvalidation.Threemajor typesofreviewscanbedifferentiated:

CommentingInspectionsWalk-throughs

Alongwith reviews, the following three techniqueshaveproven themselves tobeusefulforrequirementsvalidation:

Perspective-basedreadingValidationthroughprototypesUsingchecklistsforvalidation

In the following, these six techniques are described. Prior to applying any ofthese techniques, preparatory steps need to be taken as needed, such asidentifyingandinvitingtherightstakeholdersororganizingsuitableroomsandsupplies.

7.5.1Commenting

Individualvalidationofrequirements

During commenting, the author hands his or her requirements over to anotherperson(e.g.,aco-worker).Thegoalistoreceivetheco-worker’sexpertopinionwith regard to the quality of a requirement. The co-worker reviews therequirementwiththegoaltoidentifyissuesthatimpairrequirementquality(e.g.,ambiguityorerrors)withrespecttopredeterminedqualitycriteria.Theidentifiedflawsaremarkedintherequirementsdocumentandbrieflyexplained.

7.5.2Inspection

Typicalphasesofaninspection

Inspectionsofsoftwareoranyothertypeofproductaredonetosystematicallycheckdevelopmentartifactsforerrorsbyapplyingastrictprocess[LaitenbergerandDeBaud2000].

An inspection is typically separated intovariousphases [Gilb andGraham1993]: planning, overview, defect detection, defect correction, follow-up, andreflection.For requirementsvalidation, theplanning,overview,errordetection,and error collection phases are relevant (see principle 2, separating theidentificationandcorrectionoferrorsinsection7.4.2).Individualpreparationisan obligatory part of inspections. An inspection session usually serves thepurposeofcollectingandevaluatingerrorindications.Occasionally,performingdedicatedinspectionsessionsisomittedwhenperforminginspections.

Planning

Amongotherthings,thegoaloftheinspection,theworkresultsthataretobeinspected, and the roles and participants are determined during the planningphase.

Overview

Intheoverviewphase,theauthorexplainstherequirementstobeinspectedto all team members so that there is a common understanding about therequirementamongallinspectors.

Errordetection

In the error detection phase, the inspectors search through the requirementfor errors. Error detection can be performed individually by each inspector orcollaboratively in a team. Individual inspection has the advantage that eachinspector can concentrate on the requirements. On the other hand, teaminspections have the advantage that communication between the inspectorscreates synergy effects during error detection. During the course of errordetection,anyerrorsthatarefoundarepurposivelydocumented.

Errorcollectionandconsolidation

Intheerrorcollectionphase,allidentifiederrorsarecollected,consolidated,anddocumented.Duringconsolidation,errorsthathavebeenidentifiedmultiple

timesorerrorsthataren’treallyerrorsareidentified.Thelattercanbethecaseif, for instance,an inspectormakeswrongassumptionsabouta requirementorinterprets some constraint the wrong way. Along with consolidation, theidentified errors and correcting measures are documented in an error list.Inspectionsarealsoknownastechnicalreviews.

Rolesduringinspection

Foraninspectiontobeperformed,thefollowingrolesmustbestaffedwithsuitablepersonnel:

Organizer:Theorganizerplansandsupervisestheinspectionprocess.Moderator: The moderator leads the session and ensures that thepredetermined inspection process is followed. It is advisable to select aneutral moderator because the moderator could potentially balance outopposingopinionsofauthorsandinspectors.Author: The author explains the requirements that he created to theinspectors in theoverviewphaseandlateronisresponsibleforcorrectingtheerrorsidentified.Reader: The reader introduces the requirements to be inspectedsuccessivelyandguidestheinspectorsthroughthem.Theroleofthereadershould be given to a neutral stakeholder so that the inspectors can centertheir attention on the requirements instead of on the interpretation of theauthor.Often,themoderatorisalsothereader.Inspectors: The inspectors are responsible for finding errors andcommunicatingtheirfindingstotheothermembersoftheprojectteam.Minute-taker:Thispersontakesminutesoftheresultsoftheinspection.

7.5.3Walk-Through

Lightweightinspection

In requirements validation, a walk-through is a lightweight version of aninspection.Awalk-throughislessstrictthananinspectionandtheinvolvedrolesaredifferentiatedtoalesserdegree.Duringawalk-through,atleasttherolesofthe reviewer (comparable to the inspector), author, and minute-taker, andpotentiallythemoderator,arestaffed.

Discussionoftheidentifiedflawsinqualityduringagroupsession

The goal of a walk-through of requirements is to identify quality flawswithin requirements by means of a shared process and to gain a sharedunderstandingof the requirementsbetweenall thepeople involved.Topreparefor a walk-through, the requirements to be validated are handed out to allparticipants and inspected. During the walk-through session, the participantsdiscuss the requirements to be validated step-by-step, under guidance of themoderator/reader.Usually,theauthorofarequirementistheonewhointroducesthe requirement to all other participants. This way, the authors have theopportunity to give additional information to the group along with the actualrequirement (e.g., alternative requirements, decisions, and rationale fordecisions). A minute-taker documents the flaws in quality that have beenidentifiedduringthesession.

7.5.4Perspective-BasedReading

Checkrequirementsfromadefinedperspective.

Perspective-based reading is a technique for requirements validation inwhichrequirementsarecheckedbyadoptingdifferentperspectives[Basilietal.1996].Typically,perspective-basedreadingisappliedinconjunctionwithotherreviewtechniques (e.g., during inspections or walk-throughs). Focusing on particularperspectives when reading a document verifiably leads to improved resultsduringrequirementsvalidation.Possibleperspectivesforvalidation,forinstance,emergefromthedifferentaddresseesofarequirement[Shulletal.2000]:

User/customer perspective: The requirements are checked from theperspectiveofthecustomerortheusertodeterminewhethertheydescribethedesiredfunctionsandqualitiesofthesystem.Software architect perspective: The requirements are checked from theperspective of the software architect to ascertain if they contain allnecessary information for architectural design (e.g., if all relevantperformancepropertieshavebeendescribed).Testerperspective:The requirements are checked from theperspectiveofthe tester to establish whether they contain the information necessary to

derivetestcasesfromtherequirements.

Perspectivequalityaspects

The three quality aspects (see section 7.3) also describe three possibleperspectivesforrequirementsvalidation:

Contentperspective:With thecontentperspective, theauditorverifies thecontent of requirements and focuses on the quality of the content of thedocumentedrequirement.Documentation perspective: With the documentation perspective, theauditor ensures that all documentation guidelines for requirements andrequirementsdocumentshavebeenmet.Agreementperspective:Withtheagreementperspective,theauditorchecksif all stakeholders agree on a requirement, i.e., if the requirements areagreeduponandconflictshavebeenresolved.

Inaddition, furtherperspectives thatemergefromthe individualcontextof thedevelopmentprojectcanbecreatedasneedbe.

Definevalidationdirectivesforeachperspective.

Duringperspective-basedvalidation, eachauditor is assignedaperspective(attheproperpointintime)fromwhichshereadsandvalidatestherequirement.Foreachperspectivedefined,detailedinstructionsforperformingthevalidationshouldbelaiddownbecausetheauditormightnotbefamiliarwithallrelevantdetails of her assigned perspective. It is advisable to associate questions witheach validation instruction that must be answered by the content of therequirementsorbytheauditoraftershehasreadtherequirement,respectively.Inaddition, validation instructions can be amended with a checklist thatsummarizesthemostimportantcontentaspectsthatoughttobeaddressedbyarequirementwithregardtotheappropriateperspective.

Follow-up

During the course of the follow-up to a perspective-based reading session,theresultsofthechosenperspectiveareanalyzedandconsolidated.Ontheonehand, the results of the perspective-based reading contain answers to the

predefinedquestions,andontheotherhand,openissuesthattheauditorsnoticedwhilereadingmaybepresent.Theconsolidationcanbedoneasagroupeffort,similarlytoareview.

Supportofothertechniques

Perspective-based reading can be both an independent technique forrequirementsvalidationandasupporttechniqueforothervalidationtechniques,such as inspections or reviews of requirements documents by means ofperspective-basedreading.

7.5.5ValidationthroughPrototypes

Requirements validation bymeans of prototypes allows auditors to experiencethe requirements and to try them out. Experiencing requirements directlythroughprototypes[Jones1998]is themosteffectivemethodtoidentifyerrorsinrequirements.Stakeholderscan tryout theprototypeandcompare theirownideaofhowthesystemoughttobeimplementedwiththeprototypeathandandtherebyfinddiscrepanciesbetweentheirideasandthecurrentimplementation.

Evolutionaryvs.throw-awayprototypes

Dependingonthefurtheruseoftheprototype,onecandistinguishbetweenthrow-away prototypes and evolutionary prototypes [Sommerville 2007].Throw-away prototypes are not maintained once they have been used.Evolutionaryprototypesaredevelopedwiththegoaltobedevelopedfurtherandimproved in later steps. In contrast to throw-away prototypes, implementationplays a much more significant role here. Therefore, the effort to createevolutionaryprototypesismuchhigher.

Selectionofrelevantrequirements

Before a prototype can be implemented, the requirements that shall bevalidatedthroughtheprototypemustbeselected.Thesetofrequirementstobevalidated is limitedbydevelopmentresources(e.g., time,money,etc.) thatcanbe allocated for validation. For example, a selection criterion can be thecriticalityofarequirement.

Preparationofthevalidation

Thefollowingpreparationshavetobemadeinordertovalidaterequirementsbymeansofprototypes:

Manual/instructions:Theusersoftheprototypemustbesuppliedwiththenecessaryinformationsothattheycanuseorapplytheprototype.Thiscanbedonebymeansofamanualorbymeansofproperinstruction.Validation scenarios: Validation scenarios that the users of the prototypecanperformwith theprototype shouldbeprepared.Avalidation scenariodefines,forexample,allrelevantdatasetsoruserinteractions.Checklistwithvalidationcriteria:For requirementsvalidation,achecklistof validation criteria should be created according to which the prototype(andbyproxy,therequirements)canbevalidated.

Performingthevalidation

The auditor should validate the prototype without being influenced; i.e., theauditor should execute the validation scenarios independently and by herself.Thisensuresthatthevalidationresultsarecreatedwithoutbias.

During validation, the auditors can and ought to execute alternative anddeviantscenariosandshouldusetheprototypeexplorativelyandexperimentallyonce the required validation scenarios have been covered. For example, errorcases thathave remainedhiddenuntil thencanbe identified.Forexperimentalvalidationoftheprototype,theauditorneedstoknowthescopeoftheprototype,i.e., thesetof requirements thathavebeenconsideredwhen theprototypewascreated.Withoutknowledgeoftheimplementedrequirements,anauditorcannotdecidewhetheranidentifiederrorcanbetracedbacktoamissingrequirementoriftherequirementhasbeenconsciouslyomittedintheprototype.

Documentationofthevalidationresults

Requirements validation through prototypes therefore permits two types ofresultdocumentation:

Protocoloftheauditor:Theauditordocumentstheresultsandexperiencesmade during the validation of the prototype, e.g., bymeans of validationscenariosaswellasachecklistthathehasbeensuppliedwith.

Observationprotocol:Theauditorcanbeobservedbyasecondperson.Thesecond person creates a so-called observation protocol.This protocol candisclose additional important symptoms for errors in requirements. Forexample, when the auditor hesitates at a certain step in the validationscenariowhileusingtheprototypeandtheobserverdocumentsthis,itmaybe an indication for missing apparentness and as such an indication forimpairedunderstandabilityoftheprototype.Undercertaincircumstances,itmaybeadvisable to record thevalidationonvideobecause thevalidationsituation can be analyzed in detail during the follow-up. For example, avideo recording can show the realization of requirements pertaining toanthropometricproperties(suchasergonomics)orintuitiveuseandcanbeinvestigatedindetail.

Analysis

The resultsof thevalidationare analyzedaftervalidation is complete.Changesuggestions for the requirementsareconsolidated. If significantchanges to therequirements are necessary, it may be advisable to revise the prototype andvalidateanew.

7.5.6UsingChecklistsforValidation

A checklist comprises a set of questions and/or statements about a certaincircumstance. Checklists can be applied whenever many aspects must beconsideredinacomplexenvironmentandnoaspectmustbeomitted.Achecklistfor requirementsvalidation containsquestions that ease thedetectionof errors[Boehm1984].Usingchecklistsforrequirementsvalidationisverycommoninpractice. Checklists can be used in all previously introduced techniques forrequirementsvalidation.

Creatingchecklists

Beforeachecklistcanbeused,everysinglequestionor statementmustbedefined. The sources for questions and statements in the following list can beusedtocreatecheckliststosupportrequirementsvalidation:

Thethreequalityaspectsofrequirements(seesection7.3)

Principlesofrequirementsvalidation(seesection7.4)Qualitycriteriaforrequirementsdocuments(seesection4.5)Qualitycriteriaforindividualrequirements(seesection4.6)ExperiencesoftheauditorsfrompriorprojectsErrorstatistics[Chernak1996]

Improvingchecklists

Checklists are not necessarily complete. When using a checklist, one shouldalways look for opportunities to improve the checklist for future use. Forexample,ifaquestionwasforgotten,thechecklistshouldbeamendedtocontaintheextraquestion.Ambiguousquestionsorquestionsthatarenotunderstandablemust bemarked and revised.Outdated or no longer valid questions should beremoved.

Checklistsasaguideline

Checklistscansupport requirementsvalidation indifferentways.Theycanserve as a guideline for the auditor,who can follow the checklists at her owndiscretion(e.g.,duringareview).

Checklistsasameansofstructuring

Thechecklistcandefinealistofquestionsthatmustbestrictlyadheredto.Thesequestionsmustbeansweredbytheauditortovalidatetherequirements.Inthis case, the checklist serves as a measure to approach the validation in astructuredmanner.Forexample, thechecklistmaydetail theexactprocessthattheauditorsareaskedtoapply,whichguaranteesthateveryauditorvalidatestherequirementsinthesameway.Thismakestheresultsmorecomparable.

Hybrid forms of checklist application are also possible. For example, achecklistcancontainobligatoryquestionsforperspective-basedreadingandcancontainsuggestionsthattheauditormayormaynotfollow.

Successfullyapplyingchecklists

Applyingchecklistsforrequirementsvalidationsuccessfullydependsonthemanageabilityandcomplexityofthechecklist.Alargeamountofquestionscan

make itmoredifficult touse thechecklistbecause theauditordoesnothaveasteady overview of the questions and is thus forced to consult the checklistfrequently.Itisthereforeadvisabletodesignthechecklisttonotbelongerthanasinglepage[GilbandGraham1993].Inaddition,questionsthatareformulatedaltogether too generically or abstractly can make it more difficult to use thechecklist. For example, the question “Is the requirement formulatedappropriately?”canleadtoamultitudeofdifferentanswers,dependingonwhatthe auditor considers an appropriately formulated requirement. The questionsthereforeoughttobeaspreciseaspossible.

7.6RequirementsNegotiation

To negotiate the requirements of a system to be developed, it is necessary toidentify conflicts and to resolve those conflicts. This is done by means ofsystematic conflict management. The conflict management in requirementsengineeringcomprisesthefollowingfourtasks:

Fourtasksofconflictmanagement

ConflictidentificationConflictanalysisConflictresolutionDocumentationoftheconflictresolution

Thesefourtasksareexplainedinthefollowingsections.

7.6.1ConflictIdentification

Conflictscanariseduringall requirementsengineeringactivities.Forexample,differentstakeholderscanuttercontradictingrequirementsduringelicitation.

Conflictidentificationinallrequirementsengineeringactivities

Conflictsbetweenrequirementsandconflictsbetweenstakeholdersareoftennotobviousduetodifferentreasons.Duringtheentirerequirementsengineeringprocess,therequirementsengineershouldpayattentiontopotentialconflictsso

thattheycanbeidentified,analyzed,andresolvedearlyon.

7.6.2ConflictAnalysis

Determiningtheconflicttype

During conflict analysis, the reason for an identified conflict must bedetermined.Accordingto[Moore2003],differenttypesofconflictsexist.

Dataconflict

A data conflict between two or more stakeholders is characterized by adeficit of information, by false information, or by different interpretations ofsome information. For example, take the following requirement: “R131: Thereactiontimeoftheplannedsystemshallnotexceedonesecond”.Adataconflictbetweentwostakeholderswithregardtothisrequirementcanarisefromthefactthatonestakeholderconsidersareactiontimeof1secondtobetooslowwhileanotherstakeholderdoesnotbelievethatareactiontimeof1secondisfeasiblyimplementable(i.e.,itistooshort).

Conflictofinterest

Aconflictof interestbetween twoormorestakeholders ischaracterizedbysubjectivelyorobjectivelydifferentinterestsorgoalsofstakeholders.Aconflictof interestbetweentwoormorestakeholderscanarise, for instance,whenonestakeholder primarily focuses on keeping the costs of the planned system at aminimumwhileanotherstakeholderprimarilydesiresahighlevelofquality.Aconflict of interest between these two stakeholders arises when the firststakeholder rejects a requirement due to estimated costs and the secondstakeholderinsistsonimplementingitduetoqualityreasons.

Conflictofvalue

A conflict of value is characterized by differing underlying valuesstakeholders have regarding some circumstance (e.g., cultural differences,personal ideals). For instance, a conflict of value ariseswhen one stakeholderfavorsopensourcetechnologieswhileanotherstakeholderfavorsclosedsources

technologies.

Relationshipconflict

A relationship conflict is characterized by strong emotions, stereotypicalrelationship concepts, deficient communication, or negative interpersonalbehavior between stakeholders (e.g., insults, disrespect). For instance, arelationshipconflictariseswhentwostakeholdersofequalrankorposition(e.g.,department leaders) reject each other’s requirements and try to distinguishthemselvesbyforcingtheirrequirementsontotheproject.

Structuralconflict

Astructuralconflictischaracterizedbyunequallevelsofauthorityorpower.For instance, a structural conflict can arise between an employee and hissuperior if the superior invariably rejects requirements that the employee hasdefinedbecausehedoesnotrecognize theemployee’scompetence todelineaterequirements.

Mixedreasonsforconflicts

Often, it is difficult to unambiguously classify emerging conflicts. Forexample, a conflict can be a relationship conflict with clear structuralcomponents.Similarly,aconflictofinterestcanbeaconflictofvaluesaswell.Therefore, it is advisable to analyze an identified conflict with respect to alltypessothatallpossiblereasonsfortheconflictcanbedeterminedandsuitableresolutionstrategiescanbeselected.

7.6.3ConflictResolution

Goodconflictresolutionisasuccessfactor.

Conflict resolution is very important for requirements negotiation because thestrategy of conflict resolution has a big influence on the willingness of thepeople involved (e.g., customers, consultants, or developers) to continueworkingtogether.Forexample,aconflictresolutionconsideredunfairbyatleastonepartyoftheconflictcanleadtoadecreasedengagementandwillingnessto

collaborateintheproject.Ontheotherhand,aresolutionthatisconsideredfairbyallpartiescanincreasethewillingnesstocooperatebecausethissignalsthateveryone’sideasabouttheplannedsystemarebeingconsidered.

Involvementoftherelevantstakeholders

Independentlyfromtheselectedresolutionstrategy,itisessentialtoinvolveall relevant stakeholders. If not all relevant stakeholders are considered, someopinions and viewpointswill remain unconsidered. The conflictwill thereforeonlyberesolvedinpartor incompletely. In thefollowingparagraphs,differentconflictresolutiontechniquesareintroduced.

Agreement

With the conflict resolution technique agreement, all conflict partiesnegotiateasolutiontotheconflict.Thepartiesexchangeinformation,arguments,andopinionsandtrytoconvinceoneanotherofeachother’sviewpointsinordertocometoanagreeablesolution.

Compromise

Withtheconflictresolutiontechniquecompromise,allconflictpartiestrytofindacompromisebetweenalternativesolutions.Incontrasttoanagreement,acompromise consists of an amalgamation of different parts of the alternativesolutions. Also, a compromise can mean that all alternative solutions asproposed thus far are discarded and entirely new solutions are creativelydeveloped.

Voting

In the conflict resolution technique voting, all conflict parties vote onsolutionalternatives.Thealternativesthatareupforvotingarepresentedtoallrelevantstakeholders.Eachstakeholdercastshervoteforanalternativeandthealternativewiththemostvotesisacceptedastheresolutionfortheconflict.

Definitionofvariants

In the conflict resolution technique definition of variants, the system is

developedinawaythatpermits thedefinitionofvariantsbyderivingvariants,by selecting parameters that define system variants, or by selecting variablesystemproperties.Thisway,thesystemcansatisfythedifferentinterestsofthestakeholders.

Overruling

In the conflict resolution technique overruling, a conflict is resolved bymeans of the hierarchical organization. This means that a conflict party withhigherorganizationalrankorpositionwinstheconflictbyoverrulingobjectionsof organizationally lower parties. If both parties have the same organizationalrank, the conflict is resolved by a superior stakeholder or some third-partydecider.This conflict resolution technique is only advisable if other resolutiontechniques have failed (e.g., no compromise could be found) or are notapplicableduetolimitationsofresources(e.g.,time).

Consider-all-facts

Intheconflictresolutiontechniqueconsider-all-facts(CAF),all influencingfactorsofaconflictarebeinginvestigatedsothatasmuchinformationabouttheconflictcanbecollectedaspossible.Thisinformationisusedduringresolution.Byprioritizing the influencefactors, therelevance isdetermined.Basedon theresultsofthistechnique,theplus-minus-interestingconflictresolutiontechniquecanbeapplied.

Plus-minus-interesting

Intheconflictresolutiontechniqueplus-minus-interesting(PMI),allpositiveand negative repercussions of a solution alternative are investigated so thatpositiveandnegativerepercussionscanbeevaluated.Positiverepercussionsareplaced in the category “plus” and negative repercussions are placed in thecategory “minus”. Repercussions that are neither positive nor negative areplacedinthecategory“interesting”.Repercussionsinthecategory“interesting”cannot be evaluated yet andmust be investigated further to determine if theirinfluenceispositiveornegative.

Decisionmatrix

In the conflict resolution techniquedecisionmatrix, a table is created thatcontainssolutionalternativesinthecolumnsandallrelevantdecisioncriteriainthe rows. The decision criteria can be identified by means of the technique“consider-all-facts”.Foreachcombinationofcriterionandsolutionalternative,an assessment is made, for instance by means of a pointscale ranging fromirrelevant(0points)torelevant(10points).Table7-1showsadecisionmatrix.

Table7-1Decisionmatrix

In order to find a solution, the sums of the columns are calculated; i.e., theassessments of the criteria of each solution alternative are summed up. Thesolution alternative with the highest score is accepted as the decision. In theexampleshownintable7-1,thiswouldbesolutionalternative1.

7.6.4DocumentationoftheConflictResolution

Risksofmissingconflictdocumentation

Conflictscannotbeavoidedduringrequirementsengineering.Aresolutiontoaconflict must always be traceably documented. If a conflict resolution is notproperly documented, the following threats (among others) to the projectmayarise:

Handling conflicts repeatedly: A certain conflict can arise a second timeduring the requirements engineering process. Without properdocumentationoftheconflictresolution,theconflictmustbeanalyzedandresolved anew. This causes additional effort and can potentially lead toadditionalconflictsorabrogatepreviousresolutions.Inappropriate conflict resolution: During the requirements engineeringprocess,theresolutionofaconflictcanturnouttobewrongorunsuitable.

In thiscase, theconflictmustbe investigatedand resolvedanew.Withoutproperdocumentation,relevantinformationthathasbeenconsideredduringthe initial analysis and resolutioncanbeoverlookedand thenewconflictresolutioncanonceagainleadtofalseresults.

Inboth cases, properdocumentationof the conflict and its resolution supportsthe requirements engineering process and ensures that relevant informationalreadyknowncanbeconsidered.

7.7Summary

Thequalityoftheelicitedanddocumentedrequirementsmustbeassuredduringrequirementsengineeringsothatitcanbeguaranteedthattherequirementsmeetthedesiresandideasofthestakeholdersadequately.Therefore,itisnecessarytovalidate the requirements with regard to the quality of their content, theirdocumentation, and their agreementwith respect to the different stakeholders.Therearedifferenttechniquesthatcanbeselectedandpurposivelycombinedforrequirementsvalidation,dependingontheprojectpeculiaritiesandprojectgoals.Among the most common validation techniques for requirements are thedifferent types of requirements reviews (e.g., commenting, inspection, walk-through)aswellasperspective-basedreadingandvalidationthroughprototypesandchecklists.

For requirements negotiation, it is necessary to identify conflicts betweenstakeholders,analyzethem,andresolvetheminasuitablemanner.Asystematicconflictmanagementsupportsanalysisandresolutionof theconflicts thathavebeenidentifiedoverthecourseofrequirementsvalidationorotherrequirementsengineeringactivities.

8RequirementsManagement

Requirements management comprises purposefully assigning attributes torequirements, defining views on requirements, prioritizing requirements, andtracingrequirementsaswellasversioningrequirements,managingrequirementschanges, andmeasuring requirements.Requirementsmanagement includes themanagement of individual requirements as well as the management ofrequirementsdocuments.

8.1AssigningAttributestoRequirements

Information about the requirementsmust be documented throughout the entirelife cycle of a system. This includes, for example, unique identifiers of arequirement, the name of the requirement, the author and sources of therequirement,andthepersonresponsiblefortherequirement.

8.1.1AttributesforNaturalLanguageRequirementsandModels

Todocument informationabout requirements, ithasprovenuseful todelineatethisinformationinastructuredmanner:asattributes.Attributesofarequirementaredefinedbyauniquename,ashortdescriptionofthecontents,andthesetofpossiblevaluesthatcanbeassignedtotheattribute.

Template-basedassignmentofattributestorequirements

The simplest way to define requirement attributes is by means of a tablestructure(template).Thetemplatedefinestherelevantinformationthatis tobedocumented.Thisinformation,i.e.,thedefinedattributes(attributetypes),canbe

differentforeachtypeofrequirement.Forexample,thetemplateforfunctionalrequirements can be different from the template for quality requirementswithrespecttothedefinedattributetypesand/ortheallowedattributevalues.

8.1.2AttributeScheme

The set of all defined attributes for a class of requirements (e.g., functionalrequirements, quality requirements) is called an attribute scheme. Attributeschemesareusuallytailoredtomeettheindividualproject’sneeds.

Assignmentofrequirementattributes

During the course of the project, the attributes of the requirements areassignedwithfittingattributevalues.Figure8-1showsanexemplaryassignmentofattributesforarequirementincludingtheattributes“identifier”,“name”,and“requirement description” aswell as attributes that allow for documenting thestabilityoftherequirementsanditssourceaswellasitsauthor.

Figure8-1Exampleofrequirementattributeassignment

Therequirementthatisdocumentedonthebasisofthesimpletemplateshowninfigure 8-1 has the code “Req-10” as its unique identifier. It bears the name“Dynamic Traffic Congestion Avoidance” and a description that specifies thesubject of this requirement. The stability of this requirement is classified as“fixed”, “J. Locke” is the person responsible for this requirement, and therequirementstemsfromthesource“ProductManagement”.“B.Wagner”isthe

author.The reader of the requirement (e.g., the contractor, product manager,

developer, project manager) has a significant advantage when template-baseddocumentationisused,namelythatinformationofthesametypecanalwaysbefound in the same position (e.g., the requirement stability is always in thetemplatesection“stability”).Inaddition,template-basedassignmentofattributeshas the advantage for the requirements engineer that it is harder for her tooverlook important information and that this information, supported by thestructure of the template and the predetermined attribute values, can bedocumentedpurposefullyandcorrectly.

8.1.3AttributeTypesofRequirements

Frequentlyusedattributetypes

Thevariousstandardsinrequirementsengineeringandthemostpertinent toolsforrequirementsdocumentationandmanagementoftenofferasetofpredefinedattributes. Table 8-1 lists attribute types that are frequently used in practiceduringrequirementsmanagement.

Table8-1Frequentlyusedattributetypes

Additionalattributetypesforrequirements

Along with the requirements attributes listed in table 8-1, many additionalattributetypesexisttodocumentimportantinformationofarequirement.Table8-2showsaselectionofadditionalattributetypesforrequirements.

Table8-2Additionaltypesofrequirementsattribute

Project-specifictailoringoftheattributescheme

Theattributetypessuggestedarethebasisfordefininganattributeschemeinthedevelopment project. To define an attribute scheme, at least the followingspecificaspectsmustbeconsidered:

Specific properties of the project, e.g., project size, local or distributeddevelopment,orprojectriskConstraints of the organization, e.g., organizational standards andregulationsPropertiesandregulationsoftheapplicationdomain,e.g.,referencemodels,

modelingguidelines,standardsConstraintsandrestrictionsof thedevelopmentprocess,e.g., liability law,processstandards

Definitionofattributesbymeansofinformationmodels

When employing tools for requirements management, defining the attributestructure of requirements is often not done by means of tables, but is modelbased,bymeansofinformationmodels.Amodel-baseddefinitionofanattributeschemedetermines theattribute typesaswellas limitations inattributevalues,similartotemplate-baseddefinitions.Inaddition,model-basedattributeschemedefinition allows for determining relations between attribute types of differentattributeschemes.

Advantagesofmodel-basedattributing

Along with the advantages of table-based definition, model-basedassignment of requirement attributes additionally allows consideration ofrequirement dependencies when selectively accessing the requirements. Thisaids in maintaining consistency in the attributes of the requirements.Furthermore,theinformationmodelofamodel-basedassignmentofrequirementattributescanserveasthefoundationforthedefinitionofanattributestructuretobeusedinarequirementsmanagementtool.(seesection9.3).Also,templatesfortheassignmentofrequirementattributescanbegeneratedonthebasisoftheinformationmodel.

8.2ViewsonRequirements

Structuringrequirementsbymeansofinformationmodelsallowsforgeneratingspecific views on requirements. It can be seen in practice that the amount ofrequirementsandtheamountofdependenciesamongrequirementsareevermoreincreasing.Inordertokeepthecomplexityoftherequirementsmanageableforthe project staff, it is necessary to selectively access and thereby filter therequirementsdependingonthecurrenttask.

Role-specificdefinitionofviews

Views on requirements are often defined for different roles in thedevelopmentprocess.Examplesincludeviewsforthearchitect,theprogrammer,theprojectmanager,andthetester.Itiscommontodefinemultipleviewsforaroleinordertosupport thesub-activitiesofeachrole.Oneparticularviewcanalsobeappliedtomultipleroles.

8.2.1SelectiveViewsontheRequirements

Aviewcontainsapartofallavailablerequirementinformation.Aviewcandothefollowing:

Selectparticularrequirements;i.e.,noteveryrequirementiscontainedinaview.Mask certain attributes of requirements; i.e., not every attribute of arequirementiscontainedinaview.Arbitrarilycombineboththeseselectionprinciples;i.e.,onlyasubsetofallavailable requirements and only a subset of all available attributes arecontainedinaview.

Generatingselectiveviews

Figure8-2illustratesthegenerationofthreeviews,representedbyatablethatisdefinedonthebasisofthestructureoftheattributes.Inallthreecases,theviewsarecreatedbyselectingattribute typesaswellasbydetermining theattributesthat must be available. The definition of the first view ( ), for example,determines that only those requirements are selected that “J. Locke” isresponsibleforandthathaveastabilityof“fixed”.Ofallselectedrequirements,only the attributes “identifier”, “name”, “description”, and “author” are beingconsidered.

Figure8-2Selectiveviewsontherequirements

8.2.2CondensedViewsontheRequirements

Along with selecting existing information from the requirements basis, viewscancontaingeneratedorcondenseddatathatisnotimmediatelycontainedintherequirements. Views that contain only generated or condensed data are calledcondensedviews.

Generatingcondensedviews

Condensed views can be defined by aggregating the data contained in therequirementsbasis.Acondensedviewcan,forexample,containinformationonthepercentageofrequirementsthatstemfromaparticularsource.

Combinationofselectingandcondensing

Asingle viewmay also consist of a combinationof generated, condensed,andselecteddata.

Figure8-3Condensedviewgeneratedfromarequirementsbasis

Figure 8-3 shows two condensed views of the requirements. The view“Validation status of the Requirements Basis” ( ) groups requirementsaccordingtothecurrentstatusofvalidationandcalculatesthepercentagevalueof the requirements with regard to the status “unvalidated”, “in validation”,“validated”, “in correction”, and “erroneous”. The result is depicted as a barchartinthefigureabove.Inview( ),“ImplementationeffortbyRelease”,theestimatedandactualeffortinvolvedwiththeimplementationoftherequirementsofaparticularreleaseisdepicted.Inordertocalculatethisaggregateddata,therequirements are grouped by their respective release and their implementationeffortissummedup.Theresultisdepictedasapiechartinfigure8-3.

8.3PrioritizingRequirements

Requirements are prioritized during requirements engineering using differentprioritization criteria in all sub-activities. Requirements can be prioritized bytheirorderofimplementation,forexample.Duetothedifferentprioritizationsinthevarioussub-activities,thepriorityofarequirementcanbedeterminedbyoneor more attributes (e.g., priority of the contractor, priority due to urgency ofimplementation).

8.3.1MethodforRequirementsPrioritization

Determininggoalandconstraintsofprioritization

Inordertoprioritizeasetofrequirements,agoal(i.e.,purpose)ofprioritizationmust be defined first. In addition, the constraints of prioritization aredocumented,suchastheavailabilityofdifferentstakeholdersandgroupsthereofortheresourcesavailableforprioritization.

Determiningprioritizationcriteria

Depending on the goal of prioritization, the criterion for prioritizing therequirements (or the combination of two or more criteria) is chosen. Thefollowingaretypicalexamplesofprioritizationcriteria:

CostofimplementationRiskDamageduetounsuccessfulimplementationVolatilityImportanceDurationofimplementation(i.e.,howlongittakestobeimplemented)

DeterminingStakeholders

Dependingonthegoalofprioritizationandtheselectedprioritizationcriteria,itis usually necessary to involve different stakeholders in the prioritizationprocess. By choosing appropriate stakeholders, it can be guaranteed that therequired expert knowledge is available during the prioritization process. Thestakeholders that ought to be involved are, depending on the goal andprioritization criteria, developers, project managers, customers, or users, forexample.

Selectionofartifacts

In addition, the requirements to be prioritized must be selected. Whenselectingrequirements,onemustmakesurethattheselectedrequirementsstemfromthesamelevelofabstraction.Prioritizingrequirementsfromconsiderably

differinglevelsofdetailwill leadtoinconsistentanderroneousresultsbecausestakeholderstendtoassignahigherprioritytorequirementsathigherlevelsofabstractionthantomorerefinedandconcreterequirements.

Selectionofprioritizationtechniques

On the basis of the determined properties of the prioritization (e.g.,constraints,criteriaofprioritization,etc.),asuitableprioritizationtechniqueoracombinationofmultipletechniquesisselected.

8.3.2TechniquesforRequirementsPrioritization

Forprioritization,multiple techniquesexist.The techniquesmainlydifferwithregardtothetimeandeffortneededbutalsowithregardtothesuitabilityofthedifferentprioritizationcriteriaandprojectproperties.

Adhoctechniquesandanalyticaltechniques

Thespectrumofprioritizationtechniquesspansfromsimple,single-criterionclassification to elaborate analytic prioritization approaches, such as AHP(AnalyticalHierarchyProcess)[Saaty1980],Cost-Value-Analysis[KarlssonandRyan1997],orQFD(QualityFunctionDeployment)[Akao1990].

Inmanyprojects,simpleadhocprioritizationtechniquessuchasrankingorrequirements classification are well suited. Especially with regard to theresourcesavailable,usingadhoctechniquesisoftenadvisable.

If thedecisionprocess isconsidered too incomprehensible,or if the resultsare too erroneous, analytical approaches for prioritization should be used(additionally). In practice, multiple prioritization techniques are used incombination in order to prioritize the requirements [Lehtola and Kauppinen2006].

RankingandTop-TenTechnique

Twowell-establishedtechniquesforrequirementprioritizationare,forexample,thefollowing[Lauesen2002]:

Ranking: In this technique, anumberof selected stakeholders arrange the

requirementstobeprioritizedwithrespecttoaspecificcriterion.Top-TenTechnique:Inthistechnique,thenmostimportantrequirementsforadefinedcriterionareselected.For theserequirements,arankingorder isdeterminedafterward.This rankingorder represents the importanceof theselectedrequirementswithregardtothedefinedcriterion.

Single-CriterionClassification

Another prioritization technique that is often used in practice is based on theclassificationofrequirementswithrespecttotheimportanceoftherealizationoftherequirementsforthesystem’ssuccess.Thistypeofprioritizationisbasedonassigningeachrequirement tooneof thefollowingpriorityclasses[IEEE830-1998]:

Mandatory: A mandatory requirement is a requirement that must beimplementedatallcostsorelsethesuccessofthesystemisthreatened.Optional: An optional requirement is a requirement that does notnecessarilyneedtobeimplemented.Neglectingafewrequirementsofthisclassdoesnotthreatenthesuccessofthesystem.Nice-to-have: Nice-to-have requirements are requirements that do notinfluencethesystem’ssuccessiftheyarenotimplemented.

Inpractice,differentiatingbetween“optional”and“nice-to-have” requirementscan be very difficult. Therefore, requirements classification demandsclassificationcriteriathatareasobjectivelyverifiableaspossible.

KanoClassification

TheKanoapproachintroducedinsection3.2alsosupportstheprioritizationofrequirements. By making use of the Kano approach, one can classify andprioritizerequirementswithrespecttotheiracceptanceonthemarket.Inordertodoso,thefollowingthreepropertyclasses(seealsofigure3-1)areclassified:

ThethreepropertiesintheKanoapproach

Dissatisfiers:Arequirementspecifiesadissatisfierthesystemmustpossessinordertobesuccessfullyintroducedtothemarket.

Satisfiers:A requirementspecifiesasatisfier if thecustomersconsciouslydemandtheassociatedproperty.Satisfiersofthesystemspecifythedegreeof satisfaction of the customer. An increase in the number of satisfiersusuallyleadstoincreasedcustomersatisfaction.Delighters: A requirement specifies a delighter if the customers do notconsciously demand the defined systemproperty or the customers do notexpect the implementation of the property. The customer satisfactionincreasesexponentiallybyimplementingdelighters.

OnthebasisofrequirementsclassifiedaccordingtoKano,aprioritizationoftherequirementscanbeperformedinordertoplanthesystemreleases,forexample.

PrioritizationMatrixAccordingtoWiegers

Computingrequirementpriorities

Theprioritizationmatrixaccording toWiegers [Wiegers1999] is ananalyticalprioritization approach for requirements. The core of the approach is aprioritization matrix according to which the priorities of the regardedrequirementscanbedeterminedsystematically.Figure8-4showsthestructureofaprioritizationmatrixaccordingtoWiegersaswellasthemethodaccordingtowhichprioritiesarecalculated.

Figure8-4CalculationofprioritiesinaprioritizationmatrixaccordingtoWiegers

Systematicmethodtodeterminetherequirementpriorities

Inthefollowing,thecalculationofprioritiesinaprioritizationmatrixaccordingtoWiegersisonlybrieflysketched.Moredetailedinformationcanbefoundin[Wiegers1999].

Thecalculationofpriorities inaprioritizationmatrixaccording toWiegerscanbedoneasfollows:

1. Determinetherelativeweightsforbenefit,detriment,cost,andrisk.2. Determinetherequirementstobeprioritized.3. Estimatetherelativebenefit.4. Estimatetherelativedetriment.5. Calculatethetotalvaluesandpercentagevaluesforeachrequirement:

Value%(Ri)=Benefit(Ri)xWeightBenefit+Detriment(Ri)xWeightDetriment

6. Estimate the relative cost and calculate the cost percentage for eachrequirement.

7. Estimate the relative risks and calculate the risk percentage for eachrequirement.

8. Calculatetheindividualrequirementpriorities:

Priority(Ri)=Value%(Ri)/(Cost%(Ri)xWeightCost+Risk%(Ri)xWeightRisk)

9. Asserttherankoftheindividualrequirements.

Itbecameapparent inpractice that analyticalprioritizationapproaches suchasthe prioritization matrix according to Wiegers as sketched above demandconsiderably more time and effort than ad hoc approaches, so these ad hocapproaches are to be favored in many cases. However, analytical approacheshavetheadvantagethatthedegreeofsubjectivityintheprioritizationresultscanbesignificantlyreducedsothattheyleadtomoreobjectiveandcomprehensibleresultsincomplexandcriticalprioritizationsituations.

8.4TraceabilityofRequirements

Animportantaspectofrequirementsmanagementisensuringthetraceabilityofrequirements. The traceability of a requirement is the ability to trace the

requirementsover thecourseof theentire lifecycleof thesystem(seesection4.5.5).

8.4.1AdvantagesofTraceableRequirements

Advantagesofrequirementstraceability

The use of traceability information supports system development in manyaspects and is often the precondition for establishing and using certaintechniquesduringthedevelopmentalprocess[Pohl1996;Ramesh1998]:

Verifiability: Traceability of requirements allows verifying whether arequirement has been implemented in the system, i.e., if the requirementhasbeenimplementedthroughasystemproperty.Identification of gold-plated solutions in the system: Traceability ofrequirementsallowsfortheidentificationofso-calledgold-platedsolutionsof the developed system and thereby allows identifying unneededproperties. In order to do that, for each system property (functional orqualitative),acheckisperformedtodeterminewhetheritcontributestotheimplementationofarequirementofthesystem.Identification of gold-plated solutions in the requirements: Tracingrequirements back to their origin allows identifying requirements that donotcontribute toanysystemgoalandarenotassociatedwithanysource.Usually,thereisnoreasonfortheserequirementstoexistandhencetheserequirementsdonothavetobeimplemented.Impact analysis: Traceability of requirements allows for the analysis ofeffects during change management. For example, traceability ofrequirements allows identifying the requirements artifacts that must bechangedwhentheirunderlyingrequirementsundergoachange.Reuse: Traceability of requirements allows for the reuse of requirementsartifacts in other projects. By comparing the requirements of a previousproject to the requirements of a new project by means of trace links,development artifacts (e.g., components, test cases) can be identified thatmaybeadaptedand/orreusedinthenewdevelopmentproject.Accountability: Traceability of requirements allows for retroactiveassignmentofdevelopmenteffortstoarequirement.Aftertherequirementis implemented, for example, all partial efforts for the associated

development artifact can be summed up and associated with therequirement.Maintenance: Traceability of requirements allows for simplified systemmaintenance.Forexample,thecauseandeffectoffailurescanbeidentified,thesystemcomponents thatareaffectedby thefailurecanbedetermined,andtheeffortforremovingtheunderlyingerrorcanbeestimated.

8.4.2Purpose-DrivenDefinitionofTraceability

As resources are usually severely restricted during development projects,capturing all conceivable information that supports the traceability ofrequirementsoverthecourseofthesystemlifecycleisalmostneverpossible.

Purposeoftraceabilityinformation

Inordertoestablishrequirementstraceabilityeffectivelyandefficiently,theinformationtoberecordedshouldbechosenwithrespecttothepurposethatitwill serve. Inotherwords,only the informationwhichhasa clearpurpose forsystemdevelopmentorsystemevolution[DömgesandPohl1998;RameshandJarke2001]ought tobe recorded.Recordingof traceability information that isnotpurposedrivenoftenresultsinthefactthattherecordedinformationcannotbe profitably used in the development project. Traceability information that isrecorded in this fashion is often sketchy and incomplete, unstructured, anderroneouswithregardtoitsfurtheruse.

8.4.3ClassificationofTraceabilityRelations

Pre-RStraceabilityandpost-RStraceability

The pertinent literature on the topic of requirements traceability suggestsdifferent kinds of traceability of requirements. A common differentiation isdistinguishingbetweenpre-requirements-specification (pre-RS) traceabilityandpost-requirements-specification (post-RS) traceability of requirements [GotelandFinkelstein1994].Wethusdistinguishbetweenthreekindsoftraceability:

Pre-RS traceability: Pre-RS traceability are traceability links between

requirementsandthoseartifactsthatarethebasisfortherequirements,e.g.,artifactslikethesourceororiginofarequirement(previousartifacts).Post-RS traceability: Post-RS traceability comprises traceabilityinformationbetweenrequirementsandartifactsofsubsequentdevelopmentactivities. For example, such artifacts could be components,implementation, or test cases that belong to a requirement (posteriorartifacts).Traceability between requirements:The traceability between requirementsisaboutmappingdependenciesbetweenrequirements.Anexampleofthiskind of traceability is the information that a requirement refines anotherrequirement,generalizesit,orreplacesit.

Figure8-5showsthethreetypesoftraceabilityofrequirementsinrequirementsengineering.

Figure8-5Typesofrequirementstraceability

Figure 8-6 shows the three types of requirements traceability by means ofrequirement “R-14” in an example. The pre-RS traceability comprises therelationsofrequirement“R-14”toitsorigin.Theoriginofthisrequirementarethe artifacts in the systemcontext that influence the requirement.Thepost-RStraceabilityofrequirement“R-14”consistsoftherelationstothecomponentsintheroughdesign,therefineddesign,andtherespectiveimplementationaswellastestcasesthatareusedduringsystemtestingandverifytheimplementationoftherequirementinthedevelopedsystem.

Figure8-6Exampleofthethreetypesofrequirementstraceability

In addition, figure 8-6 shows the traceability between requirements. Thetraceability link between requirement “R-14” and “R-11” documents thatrequirement“R-14”wasderivedfromrequirement“R-11”.

8.4.4RepresentationofRequirementsTraceability

Requirementstraceabilityinformationcanberepresentedindifferentways.Themost common approaches to representing traceability are simple textualreferences,hyperlinks,andtracematricesandtracegraphs.

Text-BasedReferencesandHyperlinks

Thissimplewaytorepresent traceability informationofarequirementconsistsofannotatingthetargetartifactasatextualreferenceintherequirement(initialartifact) or to establish a hyperlink between the initial artifact and the targetartifact.When linkingartifacts, different typesofhyperlinkswith specific linksemanticscanbeused.

TraceMatrices

Another common technique for representing and documenting traceabilityinformationbetweenrequirementsaswellasbetweenrequirementsandpreviousandposteriorartifactsinthedevelopmentprocessaretracematrices.Therowsina trace matrix contain the initial artifacts (requirements). In the columns, thetarget artifacts (e.g., sources of requirements, development artifacts,requirements)arerepresented.Ifatracelinkexistsbetweenaninitialartifactinrownandatargetartifactincolumnm,cell(n,m)ismarkedinthetracematrix.

Interpretationofatracematrix

Figure8-7showsasimple tracematrixfor the tracerelation“derived” thatexists between two requirements.An entry in thematrix specifies that a tracelinkoftype“derived”existsfromarequirement“Req-n”toanotherrequirement“Req-m”suchthat“Req-n”wasderivedfrom“Req-m”.

Figure8-7Representationoftraceabilityinformationinatracematrix

Maintainabilityoftracematrices

Inpractice,itbecameapparentthattracematricesaredifficulttomaintainasthenumberofrequirementsincreases.Atracematrixthat,forexample,documentstherefinement relationsbetweenmerely2,000requirementscontainsover fourmillioncells.Inaddition,manytracematricesmustbecreatedinordertobeabletorepresenttheavailableinformationcleanly(e.g.,withregardtodifferenttypesoftraceabilitylinks).

TraceGraphs

A trace graph is a graph in which all nodes represent artifacts and all edgesrepresent relationships between artifacts. The distinction between differentartifactsandtypesoftraceabilitycanberealizedbymeansofassigningdifferentattributestothenodesandedgesofthegraph.

Tracegraphoverdifferentdevelopmentartifacts.

Figure8-8 shows the representationof traceability information in a simpleexample. In the trace graph, a node type is defined for each type of artifact(context information “C”, requirements “Req-n”, components “Comp-n”). Inaddition,threetypesofedgesaredefinedtorepresentthreetypesoftraceabilityrelations(“realizedthrough”,“isorigin”,“refines”).

Figure8-8Representationoftraceabilityinatracegraph(extract)

Traceabilitychains

If traceability information about previous artifacts (e.g., stakeholders andinterview protocols) as well as posterior artifacts (e.g., test cases andcomponents)mustbemanaged,traceabilitychainsfortherespectiverequirementcanbecreatedatdifferentlevels,uptoatraceoftherequirementovertheentirelifecycleof thesystem.Commontools tomaintainrequirementsallowfor thedefinition of representation levels when creating traceability chains so that,depending on the selected level, only immediate relations of a requirement orentire traceability chains for the requirement can be generated and displayed.The traceabilitychainsare thefoundationforacomprehensive impactanalysisduringrequirementschangemanagement.

8.5VersioningofRequirements

Duringthelifecycleofasystem,therequirementsofthesystemchangeasnewrequirements are added and existing requirements are removedor altered.Thereasons for changes in requirements are diverse. One possible reason is, forinstance, the fact that stakeholders learn more and more about the system asrequirementsengineeringprogresses.Asaresult,newandalteredrequirementscometotheirmind.Duetothesechanges,asuitableversioningofrequirementsisstronglyadvisable.

Subjectofversioncontrol

Versioningof requirementsaimsatprovidingaccess to the specificchangestatesofindividualrequirementsoverthecourseofthelifecycleofthesystem.Theversionofarequirementisdefinedbyitsspecificcontentofthechangestateand ismarked by a unique version number.The information that is subject toversionmanagementcanbesingle text-based requirements, sentences, sectionsof requirements documents, or entire requirements documents, but alsorequirementsmodelsandpartialrequirementsmodels.

8.5.1RequirementsVersions

Whenversioningrequirements,onecandistinguishbetweentheversionandtheincrement of the version number. For example, the version number 1.2referencesarequirementwithversion1andtheincrement2.

Figure8-9illustratesthemethodofassigningversionnumbers.Asshowninthefigure,withsmallerchangesregardingthecontent,theincrementisincreasedbyone. If largerchangesareperformed, theversionnumber is incremented. Iftheversionnumberisincreased,theincrementissettotheinitialvalue(0).Avcanbeaddedinfrontoftheversionnumbertomakeitmoreunderstandableandeasiertoidentifyassuch.

Figure8-9Requirementsversions

Alongwiththerathersimplestructuringbymeansofversionnumbers,andtheproposedmethodofversioningrequirements,othermethodsofassigningversionnumbersarewidelyused.Forexample,itispossibletodistinguishbetweentheversion identifier, the increment identifier, and the sub-increment identifier(v1.2.12).

8.5.2RequirementsConfigurations

A requirements configuration consists of a set of requirements with theadditionalconditionthateachselectedrequirementispresentintherequirementsconfigurationwithexactlyoneversion,identifiedbytheversionnumber.

Dimensionsofconfigurationmanagementofrequirements

Managing configurations of requirements can be described in twodimensions [Conradi and Westfechtel 1998]: In the product dimension,configuration management deals with individual requirements within therequirements base (foundation). In the version dimension, configurationmanagementconsidersthevariouschangestatesaspartofversionmanagementwithin the product dimension. Figure 8-10 illustrates both dimensions ofconfiguration management of requirements. On the requirements axis,requirementsare represented.On theversionaxis, thedifferentversionsof therequirementsaredepicted.

Figure8-10Dimensionsofconfigurationmanagementofrequirements(basedon[ConradiandWestfechtel1998])

Propertiesofrequirementsconfigurations

Aconfigurationof requirementssubsumesadefinedsetof logicallyconnectedrequirements(moreprecisely,versionsofrequirements),whereeachrequirementof the requirements base may occur at most once in the requirementsconfiguration.Arequirementsconfigurationdoesnotneedtocontainaversionofeveryrequirementthat isconsideredintheproductdimension(seefigure8-10, requirements configuration 1). A configuration of requirements has thefollowingproperties:

Logical connection: The requirements contained in a configuration aredirectlylogicallyconnectedtooneanother,i.e.,agoal-orientedgroupingoftherequirementstoacommonconfigurationhasbeenperformed.Consistency: The requirements contained in a configuration do notcontradictoneanother,i.e.,theconfigurationcontainsrequirementsthatarecontradictionfreeintheirrespectiveversion.Unique identification:A configuration has a unique identifier (ID)whichcanbeusedtouniquelyidentifytheconfiguration.Immutable: A configuration defines a certain, immutable state of thespecification.Ifrequirementsofaconfigurationarechanged,anewversion

oftherequirementsandpotentiallyoftheconfigurationistheresult.Basis for rollbacks: If changes of requirements must be undone,configurations offer the ability to roll back requirements to a specificversion within a configuration. Therefore, a consistent state of thespecificationcanbemaintained.

8.5.3RequirementsBaselines

Configurationvs.baseline

Requirementsbaselinesarespecificconfigurationsofrequirementsthattypicallycomprise stable versionsof requirements and, also, oftendefine a releaseof asystem. Due to that property, requirements baselines are usually visibleexternally (e.g., to the contractor). When requirements baselines are used, anumberofimportantactivitiesinthedevelopmentprocessaresupported:

Basis for release planning: Requirements baselines are configurations of“stable” requirements, specially marked for the contractor. Baselinestherefore serve as the basis of communication for the planningof systemreleasesaswellastheirdefinition.Estimation of the effort involved with implementation: As baselines ofrequirementscanbeusedforthedefinitionofsystemreleases,theycanalsobeusedtoestimatetheeffortneededtorealizeasystemrelease.Thiscanbedone by estimating the partial effort involved with implementing arequirement of the baseline and summing up the total effort for theremainingbaseline.Comparisontocompetingproducts:Requirementsbaselinescanbeusedtocomparetheplannedsystemtocompetingsystems.

8.6ManagementofRequirementsChanges

Requirementschangeoverthecourseoftheentiredevelopmentandlifecycleofasystem.Thismeansthatnewrequirementsareaddedandexistingrequirementsarechangedorremoved.

8.6.1RequirementsChanges

Reasonsforchanges

The reasons for changes in requirements can be multifarious. Along withchanges that stem immediately from errors or incomplete requirements, theevolutionofthecontextcanmakeitnecessarytochangetherequirements.Forexample, changes in the stakeholders’ desired application of the system,amendmentstoalaw,newtechnologies,oradditionalcompetitioninthemarketcan influence the requirements and make changes necessary. Changes inrequirements,however,canalsostemfromsystemfailureafter thesystemwasdeployedifanerrorintherequirementscanbeheldresponsibleforthefailure.

Changespersearenotnegative.

Changes in requirements per se are not negative. They are merely anindication that stakeholders deal closely with the system and learn more andmoreaboutitsfunctions,qualities,andrestrictions.Ifchangerequestsonlyoccurinfrequently during development of the system, it may be a sign of lowstakeholderinterestinthesystemtobedeveloped.

Changefrequencyasanindicatorofprocessquality

However,ifrequirementschangesoccurveryfrequently,thedevelopmentofa system that is in agreement with all involved stakeholders becomes nearlyimpossible. A high change frequency is, among other things, an indicator forinadequately performed requirements engineering activities, such as elicitationandnegotiationtechniques.Inaddition,ahighchangefrequencytakesupalotofresourcesinthedevelopmentproject.

8.6.2TheChangeControlBoard

Over the course of the system life cycle, it is necessary to channel changerequests for requirements and define a structured process that will lead to ajustified decision about whether a change request is approved and how it isapproved. Changes can pertain to individual requirements (e.g., redefining arequirement) or the entire requirements document. The evaluation of

requirements changes, aswell as the decision about performing the change, isusually the responsibilityofachangecontrolboard.Thechangecontrolboard(CCB)typicallyhasthefollowingtasks:

Tasksofthechangecontrolboard

Estimate the effort for performing the change (potentially commission athirdpartywithaneffortanalysis).Evaluatechangerequests,e.g.,withrespecttotheeffort/benefitratio.Define requirement changes or define new requirements on the basis ofchangerequests.Decideaboutacceptanceorrejectionofchangerequests.Classifyincomingchangerequests.Prioritizeacceptedchangerequests.Assignacceptedchangerequeststochangeprojects.

Representativesinthechangecontrolboard

In some cases, the CCB may want to delegate these tasks to another party.Decisions about changes have to be negotiated and agreed upon with thecontractorandall involvedstakeholders in thedevelopmentproject.Therefore,the change control board should consist of, among others, the followingstakeholders,dependingonthepropertiesofthesystemtobedevelopedandthedevelopmentprocess:

ChangemanagerContractorArchitectDeveloperConfigurationmanagerCustomerrepresentativeProductmanagerProjectmanagerQualityassurancerepresentativeRequirementsengineer

Theroleofthechangemanager

Thechairpersonofthechangecontrolboardisthechangemanager.Thechangemanagerhasthetask,amongotherthings,ofmediatingbetweenpartiesincaseofconflictsandtonegotiatedecisionswiththerespectiveparties.Inaddition,thechangemanagerisresponsibleforcommunicatinganddocumentingdecisions.

8.6.3TheChangeRequest

Templateforchangerequests

In order to be able to manage changes of requirements during requirementsengineering, they have to be documented in a purpose-oriented manner. Achange request documents the desired change and contains additionalinformationforthemanagementofthechangerequest.

Achangerequestshouldcontainthefollowinginformation:

Changeinformation

Identifier: The identifier makes it possible to uniquely identify a changerequestatanypointduringthelifecycleofthesystem.Title: The title summarizes the key concern of the change request in onebriefstatement.Description: The description documents the requirement change aspreciselyaspossible.Itcancontaininformationontheeffectofthechangesaswell.Justification:Themostimportantreasonsastowhythechangeisnecessaryarelistedhere.Datefiled:Thedateatwhichthechangerequestwasfiled.Applicant:Thenameofthepersonthatissuedthechangerequest.Priority(intheapplicant’sopinion):Theimportanceofthechangerequestaccordingtotheapplicant’sopinion.

Managementinformationforthechangerequest

Inaddition to theprecedingchange information, the following information forrequirementschangemanagementishelpful:

Change validator: The person that verifies if the change has beenperformedcorrectly.Impactanalysisstatus:Flagswhetheranimpactanalysishasalreadybeenperformedonthechangerequest.CCBdecisionstatus: Flagswhether the change control boardhas alreadydecideduponthechangerequest.CCBpriority:Documentsthepriorityofthechangerequestassignedbythechangecontrolboard.Responsible: Documents the person that is in charge of performing thechangerequest.System release: Documents in which system release the changedrequirementshallbeimplemented.

8.6.4ClassificationofIncomingChangeRequests

Corrective,adaptive,andexceptionalchanges

After ithasbeen filed, thechange request isclassifiedby thechangemanagerand the change control board. Typically, the change manager pre-classifiesincoming change requests that will be introduced, adapted (if necessary), andfinallyapproved(orrejected)during thenextchangecontrolboardmeeting.Achangerequestcanbeclassifiedaccordingtothefollowingthreecategories:

Correctiverequirementchange:Achangerequestisclassifiedthuslyifthereasonforthechangerequestisafailureofthesystemduringitsoperationthatcanbeattributedtoanerrorintherequirements.Adaptive requirement change: A change request is thusly classified if arequestedchangerequiresthesystemtobeamended.Apossiblereasonforanadaptiverequirementchangecanbeachangeinthesystemcontext,e.g.,a new technology is available or the system boundary was altered (seesection2.2).Exceptional change (hotfix): A change request is classified as anexceptional change if the changemust absolutely immediatelybedone at

allcosts.Exceptionalchangescanbeeithercorrectiveoradaptive.

Differentprocessingmethods

Themethodforprocessingrequirementschangesdependsontheirclassification.For example, exceptional changes must be analyzed, evaluated, decided, andpotentiallyimplementedrightaway.Contrastingly,adaptiverequirementchangesareoftenprocessed inbatchesata laterpoint in time, typicallyas soonas thenext (or some subsequent) system release is imminent. On the other hand,correctiverequirementchangesareusuallyanalyzed,evaluated,andifnecessaryimplementedratherpromptlyafterthechangerequesthasbeenfiled.

8.6.5BasicMethodforCorrectiveandAdaptiveChanges

Figure8-11 illustrates the principalmethod of handling change requests. Thismethod can be tailored depending on organizational and project-specificparticularities.

Figure8-11Methodforhandlingchangerequests

Impactanalysis

During impact analysis, the effort for performing the change is estimated. Inordertodoso,allrequirementsaffectedbythechangearesoughtout,includinganynewlydefinedrequirements.Afterward,theposteriordevelopmentartifactsthatpotentiallywillhavetobechangedorredevelopedareidentified(e.g., testcasesorcomponents).Foreachaffectedartifact,theeffortforimplementingthechangeisdeterminedandthetotaleffortforthechangeiscomputedbysummingupallpartialefforts.

The consistent integrationof the changes into the requirements basis oftenonlynegligiblyinfluencethetotaleffort.Themostsignificantportionofthetotaleffort is usually generated by the necessary adaptations of the posteriordevelopmentartifacts.

Usingtraceabilityinformation

Identifying those requirements and posterior development artifacts that areaffected by a requirements change can be automated or at least supported bymeans of traceability information. If no or not all necessary traceabilityinformation is available, domain experts or experts of the development teamshould be questioned with respect to the consequences of the change requestfiled.

Evaluatingachange

After the impact analysis has been completed, the change control boardevaluatesthechangefiled.Inordertodothat,costandbenefitarecomparedandevaluatedwithregardtotheavailableresources.Forexample,thebenefitofthechangecanbetheavoidedlossinprestige,improvedmarketposition,oravoidedcontractpenalties.

Implementingapprovedchanges

In the next step, approved changes are prioritized by the change controlboard.Afterward,therequirementschangesareassignedtoachangeprojectorthenext(oranysubsequent)systemreleaseforimplementation.

Validatingtherequirementchanges

Planning, control of the implementation, andvalidationof the successfullyappliedchangesaretypicallytheresponsibilityofthechangemanagerorofthechangecontrolboardandmaybedelegated,ofcourse.

8.7MeasurementofRequirements

Metricscanbeusedtoassess thequalityofrequirementsandtherequirementsengineeringprocess.Ametriccanbeusedtomeasureoneormorepropertiesofrequirements or of the requirements engineering process. The measurementresults obtained by using metrics are indicators of the product and processquality.

8.7.1Productvs.ProcessMetric

Wethusdifferentiatebetweentwotypesofmetrics:

Productmetrics,usedtoobtaininsightsregardingtheamountandqualityofthedocumentedrequirementsandrequirementsdocumentsProcessmetrics,usedtoobtaininsightsregardingtheprogressandqualityoftherequirementsengineeringprocess

8.7.2ExamplesofProductandProcessMetrics

A typical example of a process metric used in requirements engineering is ametricusedtomeasurethe“requirementschanges”overaperiodoftime(e.g.,alreadyagreed-uponrequirementsthathavebeenchangedwithinonemonthorweek).

Atypicalexampleofaproductmetricusedinrequirementsengineeringisametric used to measure the “number of requirements errors” identified in arequirements specification at a given point in time.Typically, the error rate iscalculatedasarelativevalue,forexample,per100pagesofthespecificationorper1000requirements.

Therateofrequirementserrorsisprimarilyanindicatorofthequalityoftherequirements documents produced. Moreover, it is also an indicator of thequalityoftherequirementsengineeringprocess.

8.8Summary

Requirementsmanagement is a core activity of requirements engineering. It’sthe aim of this activity to maintain persistent availability of the documentedrequirementsaswellasotherrelevantinformationoverthecourseoftheentiresystemorproduct lifecycle, tostructure this information inasensiblemanner(e.g.,bymeansofrequirementsattributes),andtoensureselectiveaccesstothisinformation. The management of requirements comprises techniques of thefollowingcategories:

Assigning attributes to requirements: In order to allow for requirementsmanagement, properties of requirements are documented by means ofrequirementsattributes.Prioritizingrequirements: Requirements are prioritized at different pointsin time, during different activities, and according to different criteria.Depending on the goal of prioritization and the subject of prioritization,differentprioritizationtechniquesaretobeused.Traceability of requirements: During requirements management,traceability information of requirements is recorded, organized, andmaintained so that information about cross references and dependenciesbetween requirements or between requirements and other developmentartifactscanbeused.Versioning of requirements: Versioning and configuring requirementsmakes itpossible tokeep informationabout specificdevelopmental statesof requirements and requirements documents available over the course ofthelifecycleofthesystemortheproduct.Managementofrequirementschanges:Usually,thechangecontrolboardisresponsible for processing change requests. The change control boarddecides if a change request is approvedor rejected andprioritizes it.Theboardalsoperformsanimpactanalysistoestimatetheimpactofthechangeon all requirements and development artifacts as well as the resourcesnecessaryforimplementingthechange.Measurementofrequirements:Productandprocessmetricscanbeusedtomeasure thequalityof the requirementsand the requirementsengineeringprocess.

9ToolSupport

The different activities of requirements engineering should be supported byadequatetoolsthatideallyintegrateandcontinueprocessingthealreadyexistinginformation. This information could have been generated during requirementsengineering(e.g.,naturallanguageormodel-basedrequirements)orcouldhavebeen used as the basis for requirements (e.g., conversation minutes, goaldocuments, listsofstakeholders). Inpractice, themostcommonlyknowntoolsfor requirements engineering are tools that support the management ofrequirements (see chapter 8). This chapter primarily considers requirementsmanagement tools (RM tools, for short).AlongwithRM tools, there are alsotools in requirements engineering that support the elicitation, documentation,negotiation,andvalidationofrequirements.

9.1GeneralToolSupport

Toolsduringsystemdevelopment

Agreatnumberoftoolsthatarebeingusedduringsystemdevelopmentcanalsobe used during requirements engineering. In that sense, testmanagement, bugtracking, or configurationmanagement tools often offer the ability tomanagerequirementsorhavetheabilitytobeextendedtodoso.Oneadvantageofusingsuch tools for requirements management is that requirements can be wellintegratedwiththeartifactsthetoolswereoriginallydesignedtocreate,liketestcasesorchangerequests.Forexample,ifrequirementsaremanagedusingatestmanagementtoolandnotadistinctRMtool,aninterfacebetweentwotoolscanbe omitted and tracing test cases and their respective requirements becomesmuchsimpler.

Supportthroughwikitechnologies

Wiki technologies are nowadays also used to support requirementsengineering.For instance,glossariescanbeauthoredcollaborativelyor systemrequirements can be worked on in cooperation using wiki technologies.Especially in caseof systemswith a largenumberof stakeholders,wikishaveproventhemselvesasexceedinglyusefulinpractice.

Toolstostructure,present,visualize,andsimulate

Tools of other tool categories can help increase the effectiveness andefficiency of requirements engineering.Mind maps that have been developedduring brainstorming sessions can serve as a structuring aid, and presentationtools can help in designing a rough analysis concept. If prototypes are used,simulation toolsor test environmentscanhelp to simulate theoperationof thesystem. Tools to design prototypical user interfaces (GUI prototypes) ordevelopmentenvironmentscanillustrateuserinterfacesandfunctionsandserveasabasisfordiscussion.Flowchartingtoolsandvisualizationprogramscanbeusedtogeneratedifferentdiagramsandgraphics.

Communication,office,andprojectmanagementtools

Also,toolsthatarecommonplaceineverydayworkscenarios,suchasofficesuites, can be used gainfully in requirements engineering. Mail clients, chatsoftware,addressbooks,calendarapplications,andgroup-wareplatformsaswellastoolsforprojectmanagement,planning,andprojectcontrollingareeverydaywork tools that can aid requirements engineering. These tools supportstakeholdersinthecommunication,planning,andcoordinationoftheirtasks.

9.2ModelingTools

Along with natural-language-based information, in requirements engineeringinformationisalsodocumentedbasedonmodels,whichcanbegeneratedusingmodelingtools(seechapter6).Thesetoolsdonotonlyoffertheabilitytocreatethemodels,theyoftenalsoallowanalyzingthemodelsforsyntacticcorrectness.

Whenchoosingmodelingtools,itisimportanttoadheretocriteriasimilartothose for specialized requirements management tools (see section 9.5). The

modeling tool must provide a unique ID to each model element to supporttraceabilitybetweenthedifferentmodelsandallowformulti-usermanipulation.In addition, modeling tools should offer some kind of version controlfunctionalitywithregardtothemodelsandthemodelelements.

Traceabilitybetweenmultipletools

An important aspect related to the application of different tools is theintegration and traceability between artifacts of the different tools (e.g., usecases,behaviormodels,andtestcases).ThechoiceofthemodelingtoolortheRMtooloughttobemadewithregardtotheinterfacebetweenbothtools.Thatmeans that an interface should either be already present or be easy to create.Such an interface should allow for tracing changes in models and/orrequirementsandformanagingthetracesbetweenmodelsandrequirements(seechapter 8). If requirements change, it is indispensable to make the necessarychangesintheassociatedmodelelementsaswell.Similarly,ifamodelchanges,thenecessarychangesmustbeintegratedintothenaturallanguagerequirementsaswell.

9.3RequirementsManagementTools

NecessarypropertiesofRMtools

To support requirements management techniques (as described in chapter 8)mostoptimally,aRMtoolshouldhavethefollowingbasicproperties:

Manage different information (e.g., natural language requirements,conceptualmodels,sketches,testplans,changerequests)Manage logical relationships between information (traceability, e.g.,betweenrequirementsorbetweenrequirementsandtheirimplementation)Allow for unique identification (e.g., a unique ID for every managedartifact)Edit the managed information (multi-user accessibility, access control,configurationandversionmanagement)Allow for different views on themanaged information, depending on thepurposeOrganize the managed information (grouping, hierarchically structuring,

assigningattributes,andannotationofadditionalinformation)Generate reports or summaries regarding the managed information (e.g.,reportsofchangerequestsforrequirements)Generate different kinds of output documents based on the managedinformation (e.g., generate requirements documents for a specific systemrelease)

Depending on the amount of functions and depending on what the basicfunctionscover,requirementsmanagementtoolscanbecategorizedintwoways:

SpecializedtoolsStandardofficeapplications

9.3.1SpecializedToolsforRequirementsManagement

Toolsofthiscategoryhavebeendevelopedspecificallytosupportrequirementsmanagement techniques and govern any tasks associated therewith.Characteristicpropertiesofsuchtoolsareasfollows(seechapter8):

CharacteristicRMtoolproperties

Management of requirements and attributes on the basis of informationmodelsOrganizationofrequirements(bymeansofhierarchylevels)ConfigurationandversionmanagementonrequirementlevelDefinitionofrequirementbaselinesMulti-useraccessibilityandmanagement(e.g.,accesscontrol)TraceabilitymanagementConsolidationofelicitedrequirements(e.g.,generationofviews)Changemanagementsupport(changecontrol)

ArchitectureofRMtools

The different RM tools that are available on the market possess a similarstructure.Themostcommontoolshaveauserinterfacethattheusercanusetoaccessallfunctionsnecessarytocarryout therequirementsmanagementtasks.

Themanageddataisstoredinadatabaseandcanbeeditedusinganintegratededitor.DifferentimportandexportfunctionsfordocumentsensurethatimporteddatafromexternalsystemscanbereadbytheRMtoolandexporteddatacanbereadbyexternalsystems.

SuitabilityofRMtools

Suchrequirementsmanagementtoolsthuscovermostofthebasicfunctions.Theyareverywellsuitedtomanagingtherelevantinformationforrequirementsengineering.Anoverviewoftheproductsthatsupportrequirementsengineeringandthatareavailableonthemarketcanbefound,forexample,onthewebsiteoftheINCOSEandoftheVolereprocess.

9.3.2StandardOfficeApplications

In many projects, standard office applications are still used to managerequirements (e.g., word processors and spreadsheet calculators). The mainreasons for this are that on one hand, such applications are very widelydistributed,andontheotherhand,noadditionaleffortmustbespenttobecomefamiliar with them. In conjunction with using templates – like, for instance,templatesforrequirementsdocumentation(seesection5.2)–theseapplicationsaresuitedfordocumentingand,tosomeextent,formanagingrequirements(e.g.,traceabilityrelationscanbeestablishedbymeansofhyperlinks).

Officeapplicationsgiveonlylittlesupport.

However, such tools support the basic functions of requirementsmanagement only to a limited extent. They do not offer a version controlmechanismon the level of requirements, nordo theyhave supporting featuresfor specific techniques for requirements management (e.g., the ability tomaintain traceability links between individual artifacts in an automated way).Someofthebasicfunctionscanbeemulatedusingothertools.Forinstance,anofficeapplicationthatisusedinconjunctionwithsomeversioncontroltoolmayfulfill the requirement of active version control ormanagedmulti-user access.Nevertheless, the productivity and performance with regard to requirementsmanagement that can be achieved with specialized tools cannot be achievedusingstandardofficeapplications.

9.4IntroducingTools

Assignresponsibility.

Before any effort can be spent on finding a tool that supports requirementsmanagementinthebestpossiblemanner,responsibilitiesregardingrequirementsengineering should already have been delineated in the organization or in theproject.Inadditiontothepartiesresponsible,thetechniquesandprocessesthatarenecessarytoachievethegoalofrequirementsengineeringandrequirementsmanagement (see chapter 8) must be defined. After all, even the mostsophisticated requirementsmanagement tool isbut anaid for the requirementsengineerandrequirementsengineering.

Thetoolfollowsthemethod.

Only when every process and every technique has been defined and allinvolved people are able to follow these constraints can an evaluation of theavailable toolsbeperformed.Thefollowingconsiderationshavetobefactoredinwhenchoosingandintroducingtoolsforrequirementsengineering:

Considernecessaryresources.

Thechoiceandintroductionoftoolstakesupresourcesintheorganization.Thisholdsnotonlyforpersonnelentrustedwiththeintroductionofatool,butalsofor thefutureusersofa tool.Theseeffortshavetobeconsideredduringevaluation.

Pilotproject

In practice, it has proven problematic to introduce a tool while adevelopment project is already in progress. While additional effort forinstructionoftheemployeescanbeestimatedratherwell,therisksthatareassociatedwith introducing a new toolwhile a project is in progress areeasilyunderestimated.Employeeresistanceordeficienciesof the tool thatbecome apparent when the tool is deployed can influence the projectnegatively. Such risks can be avoided by introducing new tools in pilotprojects. In this pilot project, additional resources for tool introduction,employeeinstruction,andprocesstailoringshouldbefactoredin.

Evaluation

A suitable tool should be determined in the context of a tool evaluation.When manufacturers are surveyed and critical “must-have” criteria aredefined, potential candidates for introduction can be selected andinvestigatedinfurtherdetail.Inordertodothat,acatalogueofcriteriamustbe created that describes which requirements a tool for requirementsengineeringmustfulfill.Thetoolsthatremaintobeevaluatedcanthenberatedaccordingtotheserequirements.

Costs

Costs for a tool usually exceed licensing cost alone. Typically, costs foremployee instructionaswell aspotential tool customizationandcosts forsupportmustbetakenintoaccountaswell.

Instructemployees.

Itisnecessaryforthefutureusersofthetooltoknow,activelyshape,andmastertheprocessesandactivitiesthattheyencounterduringrequirementsengineering. The users must be instructed with regard to processes,techniques,andtherespectivetoolsupport.

9.5EvaluatingTools

Duetothemanydifferentkindsoftoolsthatareavailable,evaluatingtoolswithregardtotheiradequacytosupportrequirementsengineeringisverytediousandchallenginginpractice.

Viewsontoolsinrequirementsengineering

Toevaluatethetoolsasobjectivelyaspossible,differentviewsonthetoolsinrequirementsengineeringshouldbeadopted.Bydefiningdifferenttoolviews,itispossibletoanalyzetheadequacyofatoolsystematicallyandtoprioritizethetool requirements individually. Figure 9-1 shows views that could be used toevaluatetooladequacyinrequirementsengineering.

Figure9-1Viewsonarequirementsengineeringtool

Foreachview,criteriashouldbedefinedthataretailoredtowardthecoreaspectsoftherespectiveperspective.

9.5.1ProjectView

Projectsupport

The project view shows the extent to which the tool can support the project.Relevant criteria are support during project preparation, project planning, andprojectexecution.Withregardtoprojectpreparation,criteriacanbeconsideredthat pertain to the definition of project-specific information types anddocuments.Withregardtoprojectplanning,thescopeofdefinedmilestonesaswell as how information and documents that are created bymeans of the toolpertaintothemilestones.Projectexecutioncomprisescriteriathatpertaintothescope of project control and project lead on the basis of information anddocumentsthatarecreatedwiththetool.

9.5.2UserView

Perspectiveofthefutureusers

The user view considers the requirements for the tool that emerge out of theperspective of the users (e.g., multi-user capability). The evaluation from theperspectiveoftheuserisfocusedontoolusage,mappingofroles,andsupportofgroupwork.Indetail,thismeansthatthedifferentstakeholdersthatareinvolvedin a development project must be adequately mapped by appropriate usermanagementandaccess rightsmanagement.Thisenables theusers togain theappropriateaccesstothetoolfunctionsandthestoredinformation,dependingontheirrespectiverole.

9.5.3ProductView

Toolfunctions

The product view contains the functionalities that the tool possesses (e.g.,different documentation types for requirements). Among other things, thesupporteddocument types,views,andreports thatcanbegenerated,aswellastraceabilitybetweentheselectedproducts,areconsideredinthisview.

9.5.4ProcessView

Methodsupportofferedbythetool

The process view focuses on the method support offered by the tool (e.g.,possibleguidance,maintenanceof traceability relations).Considerationsof theprocessviewcomprisetheabilitytodocumentactivitieswithinthetoolaswellas theextent towhich the tooloffersmethodguidance.Withregard tomethodguidance,differentdegreesofobligationcanbedistinguished.Methodguidancecanbe strict and restrictiveoroffermore lenient suggestionsandhints.Alongwiththedegreeofmethodsupportthatisofferedbythetool,thedegreetowhichaproject-specific processmodel canbedefined can alsobe considered in thisview.

9.5.5ProviderView

Marketpositionofthemanufacturerandsupportoffered

Theproviderviewconsidersthemarketpositionaswellasthedifferentservicesthatareofferedbyamanufacturer.Whenchoosingatool,notonlythefunctionalaspectsbutalsoconstraintsthatmustbefulfilledforthetooltobeapplicablearepertinent.Thedegreeofbrandawareness,forinstance,andthereputationoftheproviderarethereforeoftenusedasdecisioncriteria.Duetotherelativelyhighacquisition cost and the long-term subscriptions to support services, a closecommitmenttowardtheproviderismade.

9.5.6TechnicalView

Thetool’sabilitytoperformandtointegrate

The technical view involves technical context conditions that the system isexpected tomeet. Importantaspects in the technicalvieware, for instance, theabilitytointegratethetool,theperformanceoftheusedrepository,thenecessaryhardware and software, and scalability of the tool. The ability of the tool tointegrate can be determined, for instance, by investigating towhat extend thefunctionalities of the tool are accessible via an API and to what degree theprocess,data,andcontrolintegrationispossible.Thescalabilityofthetoolcanbedetermined,forinstance,bydeterminingthemaximumnumberofusersthatcanbemaintainedorthemaximumnumberofobjects(e.g.,contentpackagesordocuments). The performance of the repository used can be measured bydetermining the degree towhich importing and exporting data can be done aswellasbydeterminingtheperformanceofthequeryinterfacesortheavailablesecurityconcepts.

9.5.7EconomicView

Introductionandfollow-upcosts

Theeconomicviewregards thepossiblecosts thatarisedue to theacquisition,introduction, and maintenance of a tool (e.g., licensing costs, employee

instruction costs, and support costs). The amount of the relevant costs canconsist of the integration costs, costs of operation, maintenance andinfrastructure,costsformethodtailoring,andacquisitioncosts.

9.6Summary

Whenmanagingrequirementsduringrequirementsengineering,itisnecessarytostore the information in a way that the quality criteria for requirementsmanagementaremet.Toolssupporttherequirementsengineerindoingso.Thesetools can be differentiated into professional RM tools, modeling tools, andstandard office applications and differ from one another in the functionalitiesthat are offered to the requirements engineer. This is the reason an evaluationmust be done before a tool is selected, so as to not inhibit the introductionprocessunnecessarily.

References

[Akao 1990]Y.Akao:Quality FunctionDeployment – IntegratingCustomerRequirements into ProductDesign.ProductivityPress,Portland,1990.

[Bandler 1994] R. Bandler: Metasprache und Psychotherapie: Die Struktur der Magie I. Junfermann,Paderborn,1994.

[Bandler and Grinder 1975] R. Bandler, J. Grinder: The Structure ofMagic II. Science and BehaviourBooks,PaloAltoCA,1975.

[Basilietal.1996]V.Basili,S.Green,O.Laitenberger,F.Lanubile,F.Shull,S.Sörumsgard,M.Zelkowitz:TheEmpiricalInvestigationofPerspective-BasedReading.EmpiricalSoftwareEngineering,Vol.1,No.12,Springer-Verlag,Berlin,Heidelberg,1996,pp.133–144.

[Beck 1999]K. Beck: Extreme Programming Explained – Embrace Change. Addision-Wesley, ReadingMA,1999.

[Boehm1981]B.Boehm:SoftwareEngineeringEconomics.PrenticeHall,EnglewoodCliffs,1981.

[Boehm 1984] B. Boehm: Verifying and Validating Software Requirements and Design Specifications.IEEESoftware,Vol.1,No.1,IEEEPress,LosAlamitos,1984,pp.75–88.

[Chaos2006]StandishGroup:ChaosReport,2006.

[Chen 1976] P. Chen: The Entity-Relationship Specification – Toward a Unified View of Data. ACMTransactionsonDatabaseSystems,Vol.1,No.1,1976,pp.9–38.

[Chernak 1996] Y. Chernak: A Statistical Approach to the Inspection Checklist Formal Synthesis andImprovement.IEEETransactionsonSoftwareEngineering,Vol.22,No.12,1996,pp.866-874.

[Cockburn2001]A.Cockburn:WritingEffectiveUseCases.Addison-Wesley,Reading,MA,2001.

[Conradi andWestfechtel 1998]R.Conradi,B.Westfechtel:VersionModels forSoftwareConfigurationManagement.ACMComputingSurveys,Vol.30,No.2,1998,pp.232–282.

[Davis 1993] A. M. Davis: Software Requirements – Objects, Functions, and States. Prentice Hall,EnglewoodCliffs,1993.

[DeBono 2006] E. DeBono: Edward DeBono’s Thinking Course: Powerful Tools to Transform YourThinking.BBCActive,Harlow,2006.

[DeMarco1978]T.DeMarco:StructuredAnalysis andSystemSpecification.YourdonPress,NewYork,

1978.

[Dömges and Pohl 1998] R. Dömges, K. Pohl: Adapting Traceability Environments to Project-SpecificNeeds.CommunicationsoftheACM,Vol.41,No.12,1998,pp.55–62.

[Easterbrook 1994] S. Easterbrook: Resolving Requirements Conflicts with Computer-SupportedNegotiation.In:M.Jirotka,J.Goguen(eds.):RequirementsEngineering–SocialandTechnicalIssues,AcademicPress,London,1994,pp.41–65.

[ElmasriandNavathe2006]R.Elmasri,S.B.Navathe:FundamentalsofDatabaseSystems.5thEdition,Addison-Wesley,ReadingMA,2006.

[GauseandWeinberg1989]D.C.Gause,M.Weinberg:ExploringRequirements–QualitybeforeDesign.DorsetHouse,NewYork,1989.

[GilbandGraham1993]T.Gilb,D.Graham:SoftwareInspection.Addison-Wesley,ReadingMA,1993.

[GlassandHolyoak1986]A.L.Glass,K.J.Holyoak:Cognition.RandomHouse,NewYork,1986.

[Glinz and Wieringa 2007] M. Glinz, R. Wieringa: Stakeholders in Requirements Engineering. IEEESoftware24,2,2007,pp.18–20.

[Gotel and Finkelstein 1994] O. Gotel, A. Finkelstein: An Analysis of the Requirements TraceabilityProblem. In: Proceedings of the IEEE International Conference on Requirements Engineering(ICRE’94),1994,pp.94–102.

[Gottesdiener 2002] E. Gottesdiener: Requirements by Collaboration: Workshops for Defining Needs.Addison-WesleyLongman,Amsterdam,2002.

[Harel 1987] D. Harel: Statecharts – A Visual Formalism for Complex Systems. Science of ComputerProgramming,Vol.8,No.3,1987,pp.231–274.

[HatleyandPirbhai1988]D.J.Hatley,I.A.Pirbhai:StrategiesforRealTimeSystemSpecification.DorsetHouse,NewYork,1988.

[HickeyandDavis2003]A.M.Hickey,A.M.Davis:ElicitationTechniqueSelection:HowDoExpertsDoIt? Proceedings of the 11th IEEE International Requirements Engineering Conference (RE’03),MontereyBay,USA,2003,pp.169–178.

[IEEE610.12-1990]InstituteofElectricalandElectronicsEngineers:IEEEStandardGlossaryofSoftwareEngineeringTerminology(IEEEStd.610.12-1990).IEEEComputerSociety,NewYork,1990.

[IEEE 830-1998] Institute of Electrical and Electronics Engineers: IEEE Recommended Practice forSoftwareRequirementsSpecifications(IEEEStd.830-1998).IEEEComputerSociety,NewYork,1998.

[ISO/IEC9126]InternationalOrganisationforStandardization:SoftwareEngineering–ProductQuality–Part1:QualityModel.Geneva,2001.

[ISO/IEC 15504-5] International Organisation for Standardization: An Exemplar Process AssessmentModel.Geneva,2007.

[ISO/IEC25010:2011]InternationalOrganizationforStandardization:Systemsandsoftwareengineering–SystemsandsoftwareQualityRequirementsandEvaluation(SQuaRE)–Systemandsoftwarequalitymodels,Geneva2011.

[ISO/IEC/IEEE 29148:2011] International Organization for Standardization: Systems and softwareengineering–Lifecycleprocesses–Requirementsengineering,Geneva,2011.

[Jacobsonetal.1992] I. Jacobson,M.Christerson,P. Jonsson,G.Oevergaard:ObjectOrientedSoftwareEngineering–AUseCaseDrivenApproach.Addison-Wesley,ReadingMA,1992.

[Jones1998]T.C.Jones:EstimatingSoftwareCosts.McGraw-Hill,NewYork,1998.

[Kano et al. 1984]N.Kano, S. Tsuji,N. Seraku, F. Takahashi:AttractiveQuality andMust-beQuality.Quality–TheJournaloftheJapaneseSocietyforQualityControl,Vol.14,No.2,1984,pp.39–44.

[Karlsson andRyan 1997] J.Karlsson,K. Ryan:ACost-ValueApproach for PrioritizingRequirements.IEEESoftware,Vol.14,No.5,IEEEPress,LosAlamitos,1997,pp.67–74.

[Keller et al. 1992] G. Keller, M. Nüttgens, A.-W. Scheer: Semantische Prozeßmodellierung auf derGrundlage »Ereignisgesteuerter Prozessketten (EPK)«. Publications of the institute for businessinformatics(IWi),SaarlandUniversity,Issue89,Saarbrücken,1992.

[Kosslyn 1988] S. M. Kosslyn: Imagery in Learning. In: M. Gazzaniga (ed.): Perspectives inMemoryResearch,TheMITPress,Cambridge,1988.

[Kruchten2001]P.Kruchten:TheRationalUnifiedProcess:AnIntroduction,Addison-Wesley,2001.

[Laitenberger andDeBaud 2000]O. Laitenberger, J.-M.DeBaud:An Encompassing Life Cycle CentricSurveyofSoftwareInspection.JournalofSystemsandSoftware,Vol.50,No.1,2000,pp.5–31.

[Lauesen 2002] S. Lauesen: SoftwareRequirements – Styles andTechniques,Addison-Wesley, London,2002.

[Lehtola and Kauppinen 2006] L. Lehtola, M. Kauppinen: Suitability of Requirements PrioritizationMethods for Market-driven Software Product Development. Software Process – Improvement andPractice,Vol.11,No.1,2006,pp.7–19.

[Macaulay1993]L.Macaulay:RequirementsCaptureasaCooperativeActivity.In:Proceedingsofthe1stIEEEInternationalSymposiumonRequirementsEngineering,1993,pp.174–181.

[MaidenandGizikis2001]N.Maiden,A.Gizikis:WhereDoRequirementsComeFrom?IEEESoftware18,5,2001,pp.10–12.

[McMenamin and Palmer 1988] S.M.McMenamin, J. F. Palmer: Essential Systems Analysis. PrenticeHall,London,1984.

[Mealy1955]G.H.Mealy:AMethodforSynthesizingSequentialCircuits.BellSystemTechnicalJournal,Vol.34,No.5,1955,pp.1045–1079.

[Mietzel 1998] G. Mietzel: Pädagogische Psychologie des Lernens und Lehrens. 5th Edition, Hogrefe-Verlag,Göttingen,1998.

[Moore1956]E.F.Moore:Gedanken-ExperimentsonSequentialMachines.In:C.Shannon,J.McCarthy(eds.):AutomataStudies,PrincetonUniversityPress,Princeton,1956,pp.129–153.

[Moore2003]C.Moore:TheMediationProcess–PracticalStrategiesforResolvingConflicts.3rdEdition,Jossey-Bass,SanFrancisco,2003.

[OMG 2007] OMG: Unified Modeling Language: Superstructure, Version 2.1.1. OMG documentformal/2007-02-05.

[Pohl 1996] K. Pohl: Process-Centered Requirements Engineering. Research Study Press, AdvancedSoftwareDevelopment,Taunton,Somerset,1996.

[Pohl 2008] K. Pohl: Requirements Engineering – Grundlagen, Prinzipien, Techniken. dpunkt.verlag,Heidelberg,2008.

[Pohl 2010] K. Pohl: Requirements Engineering – Fundamentals, Principles, and Techniques. Springer,NewYork,2010.

[Pohletal.2005]K.Pohl,G.Böckle,F.vanderLinden:SoftwareProductLineEngineering–Foundations,Principles,andTechniques.Springer-Verlag,Berlin,Heidelberg,NewYork,2005.

[Pottsetal.1994]C.Potts,K.Takahashi,A.Antón:Inquiry-BasedRequirementsAnalysis.IEEESoftware11,2,1994,pp.21–32.

[Ramesh1998]B.Ramesh:FactorsInfluencingRequirementsTraceabilityPractice.CommunicationsoftheACM,Vol.41,No.12,ACMPress,1998,pp.37–44.

[RameshandJarke2001]B.Ramesh,M.Jarke:TowardReferenceModelsforRequirementsTraceability.IEEETransactionsonSoftwareEngineering27,1,2001,pp.58-92.

[Robertson2002]J.Robertson:Eureka!WhyAnalystsShouldInventRequirements.IEEESoftware19,4,2002,pp.20–22.

[Robertson and Robertson 2006] S. Robertson, J. Robertson:Mastering the Requirements Process. 2ndEdition,Addison-Wesley,UpperSaddleRiver,2006.

[Rohrbach1969]B.Rohrbach:Kreativ nachRegeln –Methode 635, eine neueTechnik zumLösenvonProblemen.Absatzwirtschaft12,Issue19,1969,pp.73–75.

[Royce1987]W.W.Royce:ManagingtheDevelopmentofLargeSoftwareSystems.In:Proceedingsofthe9th InternationalConferenceonSoftwareEngineering (ICSE’87), IEEEComputerSocietyPress,LosAlamitos,1987,pp.328–338.

[Rumbaughetal.2005]J.Rumbaugh,I.Jacobson,G.Booch:TheUnifiedModelingLanguageReferenceManual.2ndEdition,Addison-Wesley,Boston,2005.

[Rupp 2014]C.Rupp:Requirements-Engineering und -Management –Aus der Praxis von klassisch bisagil. Hanser-Verlag, Munich, 2014. (Individual chapters also available in English on the SOPHISTwebsite:http://www.sophist.de)[Ruppetal.2007]C.Rupp,S.Queins,B.Zengler:UML2glasklar–PraxiswissenfürdieUML-Modellierung.Hanser-Verlag,Munich,2007.

[Saaty1980]T.L.Saaty:TheAnalyticalHierarchyProcess.McGraw-Hill,NewYork,1980.

[SEI2006]SoftwareEngineeringInstitute:CMMIforDevelopment(CMMI-Dev),V1.2,TechnicalReportCMU/SEI-2006-TR-008 – ESC-TR-2006-008. Carnegie Mellon, Software Engineering Institute,Pittsburgh,PA2006.

[Shulletal.2000]F.Shull,I.Rus,V.Basili:HowPerspective-BasedReadingCanImproveRequirementsInspections.IEEEComputer,Vol.33,No.7,2000,pp.73–79.

[Sommerville2007]I.Sommerville:SoftwareEngineering.8thEdition,PearsonStudium,Boston,2007.

[Stachowiak1973]H.Stachowiak:AllgemeineModelltheorie.Springer-Verlag,Vienna,1973.

[van Lamsweerde et al. 1991] A. van Lamsweerde, A. Dardenne, B. Delcourt, F. Dubisy: The KAOSProject –KnowledgeAcquisition inAutomated Specification of Software. In: Proceedings ofAAAISpringSymposiumSeries,StanfordUniversity,AmericanAssociationforArtificialIntelligence,1991,pp.69–82.

[V-Modell 2004] V-Modell: V-Modell® XT, 2004, Entwicklungsstandard für IT-Systeme des Bundes,BundesrepublikDeutschland,Vorgehensmodell.www.kbst.bund.de

[WardandMellor1985]P.Ward,S.Mellor:StructuredDevelopmentofReal-TimeSystems–IntroductionandTools.Vol.1.PrenticeHall,UpperSaddleRiver,1985.

[Weinberg1978]V.Weinberg:StructuredAnalysis.YourdonPress,NewYork,1978.

[Wiegers1999]K.E.Wiegers:SoftwareRequirements.MicrosoftPress,Redmond,1999.

[Yourdon1989]E.Yourdon:ModernStructuredAnalysis.PrenticeHall,EnglewoodCliffs,1989.

[Yu1997]E.Yu:TowardsModellingandReasoningSupportforEarly-PhaseRequirementsEngineering.In:Proceedingsofthe3rdIEEEInternationalSymposiumonRequirementsEngineering(RE’97),IEEEComputerSociety,LosAlamitos,1997,pp.226–235.

KlausPohl

RequirementsEngineeringFundamentals,Principles,andTechniquesSpringer-Verlag2010Hardcover814pagesISBN978-3-642-12577-5www.requirements-book.com

In this textbook, Klaus Pohl provides a comprehensive and well-structured introduction to thefundamentals, principles, and techniques of requirements engineering. He presents approvedtechniques for eliciting, negotiating and documenting as well as validating, and managingrequirementsforsoftware-intensivesystems.Thevariousaspectsof theprocessandthetechniquesareillustratedusingnumerousexamples.

The book aims at professionals, students, and lecturers in systems and software engineering orbusiness applications development. Professionals such as project managers, software architects,systemsanalysts,andsoftwareengineerswillbenefitintheirdailyworkfromthedidacticallywell-presentedcombinationofvalidatedproceduresandindustrialexperience.

Students and lecturers will appreciate the comprehensive description of sound fundamentals,principles, and techniques, complemented by a commented list of references for further reading.

Lecturerswillfindadditionalteachingmaterialonwww.requirements-book.com.

www.paluno.uni-due.de/en