requirements engineering - recap

Requirements Engineering Recap for the final

CECS 542

Pleaselookata

lltheslide

sfromth

esecond

halfo

fthe

semester;

thisisjustasu

mmaryofth

emoreim

portantp

ointsa

ndcon

cepts.

Photocredit:AndrewPreble,Unsplash

Dr.BirgitPenzenstadler

UsageModels

•  DefiniDon•  Usecases•  Scenarios•  RelaDon•  Cockburntemplate•  ElaboraDon

Dr.BirgitPenzenstadler 2

UsageModel•  Def.:Ausagemodeldescribesthesystembehaviorfromthepointofviewoftheuser(„Blackbox“)bymodelinginteracDonsequences.

•  Itspecifiestheusecases(fromthesystemvision)

•  Why?Understandingofintendedusesbymeansofthesystem.

•  NotaDons:–  Usecaseoverviewdiagram–  Structuredtext(templates)–  UMLacDvitydiagrams– MessageSequenceCharts


Context Layer

System Layer

Requirements Layer

Stakeholder Model Objectives & Goals

Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision

Functional Hierarchy

Architecture Overview

System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case

Deployment Requirements

System Constraints

Domain Model

Service ModelUsage Model

Quality Requirements

Risk List

Project Scope

Process Requirements

Glossary

Glossary

Glossary

Usecases&Scenarios

•  Def.:Ausecaseisaseriesofsystemeventstriggeredbyanactorthatleadstoresultsfortheactor.

•  Def.:AscenarioisanorderedsetofinteracDonsbetweenpartners,usuallyasystemandagroupofactors.

•  AUsageModelinAMDiREhasthreeparts:– UseCaseOverviewDiagram(„bubble“diagram)– UseCaseTemplates(oneper„bubble“)–  Scenariodiagrams(oneperusecasetemplate)


UseCaseOverviewDiagram


[uml-diagrams.org2010]

Usecases&Scenarios:Cockburntemplate


•  Use:Usecasesandscenarioscomplementeachother.

•  Techniques:Structuredtextand/orsequence/interacDondiagrams

•  Elicita/on:iteraDve;combinescenariostotasks,„playout“task-specificscenariosandanalyse

RelaDon:UseCasesandScenarios


Use Case

Scenario

(1) (2)

•  Foreach„bubble“intheoverviewdiagram:•  UseCasessummarizeasetofscenariostoa

specificusageofthesystem.–  UseCase:

Task,objecDve,causalrelaDon(pre-andpost-condiDons)

–  Scenario:SequenceofEvents(steps,events,interacDon)

Itera/veElabora/on(comparetorefinementandabstracDonofgoalsintheearlierlecture)

(1)Clusterscenariostotasks(2)Elicittask-specificscenarios,

analyseandwalkthroughthem

DifferenDaDon•  SequencediagramsdescribeinteracDonsamongclassesintermsofan

exchangeofmessagesoverDme.Sequencediagramsshowadetailedflowforaspecificusecaseorevenjustpartofaspecificusecase.Theyarealmostselfexplanatory;theyshowthecallsbetweenthedifferentobjectsintheirsequenceandcanshow,atadetailedlevel,differentcallstodifferentobjects.

•  Ac/vitydiagramsillustratethedynamicnatureofasystembymodelingtheflowofcontrolfromacDvitytoacDvity.AnacDvityrepresentsanoperaDononsomeclassinthesystemthatresultsinachangeinthestateofthesystem.Typically,acDvitydiagramsareusedtomodelworkfloworbusinessprocessesandinternaloperaDon.

•  SequencediagrammodelsthesequenDallogic,orderingofmessageswithrespecttoDme.

•  Ac/vitydiagramhigh-levelbusinessprocesses,includingdataflow,ortomodelthelogicofcomplexlogicwithinasystem.


ScalingRE&Refinement

•  TailoringRE– Small– Medium– Large

•  Howtodefineforaproject•  ConsolidaDon,RefinementandDecomposiDon•  Systemmodels•  TraceabilityandTwinPeaks


MainFactorsforTailoringRE•  Projectsejng:Projectsize,budgetsize,Dmeconstraints,numberofpeople,

overallsokwaredevelopmentprocess•  Knowledge

–  Levelofunderstandingoftheproblemdomain–  LevelofunderstandingoftheapplicaDondomain–  Skillsofthedevelopers–  NewteamversuswellacquaintedandpracDced

•  Stakeholders–  Availabilityofstakeholders–  RelaDonshiptostakeholders–  Typesofstakeholders(especiallymoDvaDon)

•  Typeofsystem–  BusinessinformaDonsystem,embeddedsystem,cyber-physicalsystem,webservice–  Newproductversuswellestablishedproduct–  Viabilityandtechnicalfeasibility–  Maturityofunderlyingtechnology

•  SystemcharacterisDcs,e.g.:Relevanceofsafety,security,robustness,dependability,etc.

•  Business&legalconcerns:Legality,ethicalconcerns,patents,licenses,standards

BirgitPenzenstadler

Howtodefineitforaproject(=howtomakeuseofeverythingyoulearnedinthiscourseforlaterprojectmanagementandset-up)

1.  AnalyzethecharacterisDcsofyourproject(slide2“MainFactors”)

2.  LookattheAMDiREmodel(slideset4)

3.  Prunethingsyoudon’tneed4.  Adaptitemsyouneedaccordingly

(e.g.extrapieceofinfoneeded)5.  Make/usetemplates(forindividual

arDfactsandmaybeoverallspec)6.  Definethetools(RE&design)7.  Defineroles&milestoneswithand

foryourteam8.  Definethechangeprocess(see

RequirementsMngmt.)

BirgitPenzenstadler

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

Process Task

Next Process

A This has anassociated...Note or

suggestion

Concepts:DecomposiDon&refinement

•  DecomposiDon:Howtodistributeitontosubsystems?

•  Refinement:HowtoenrichwithmoreinformaDon?

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

TwinPeaksModel

1.  Requirements2.  Architecture

decision3.  Decompose

requirementsintosub-requirementsandrefineagain

4.  Sub-systemarchitecturedecisions

RETools

•  WhattodowhenhavingtoselecttoolsforRE?

•  TypesofREtools•  IEEESokwarearDcleoftoolsurvey

– HowtoreadsuchanarDcle– Howtoassestoolsthatweren’tinthere

Typesoftools

•  Generalpurposetools– Office(naturallanguagedocuments,spreadsheets)

– Drawingprograms(draw.io,cacoo)•  SpecificREtools

– Requirementsdatabasetools– Computer-aidedsokwareengineering(CASE)tools

– SeeIEEESWarDcleforsurvey

IEEESWarDcle:RequirementsEngineeringTools

•  ConciseversionofresearchjournalarDcle•  Ourgoalistolearn

– Howtodigestsuchinfo– Howtounderstandhowitwascreated– Howtomakeuseofthecontent– Howtoexpandonthecontent(byassessingaddiDonaltools)

ClassificaDonofnon-funcDonalrequirements

•  Qualityofaproduct•  DimensionsfortheclassificaDonofrequirements

•  Examples•  ChallengeswithNFRs


ClassificaDonofrequirements:Dimensions1.  FormalisaDon2.  Degree

ofabstracDon3.  QualitaDveandquanDtaDve4.  FuncDonal,non-funcDonal

à  Choiceofdegreeofprecision–  Formaking

qualitaDve/quanDtaDvestatements

–  ForclassifyingrequirementsintofuncDonal/non-funcDonal.

Example•  Thesystemiseasytouse!

–  FuncDonal/qualitaDveimplementaDon:Thesystemshallhaveahelpfunc4onthatprovidestheuserwithsupportatany4me.

–  Non-funcDonal/quanDtaDve:Thetypicaluserunderstandsthesystema9er10minutesoftraining.

18

QualitaDve

QuanDtaDve

informal formalabstract

concrete

Abstractrequirements

Formal,abstractrequirements

Concreterequirements

Formal,concreterequirements

important

Summary:3challenges

1.  CrosscujngConcerns:qualitaDve/quanDtaDvestatements–  ParDallyw.r.t.funcDonality(e.g.performance)–  ParDallyacrossfuncDonality(e.g.maintainability)

2.  ElicitaDon,assessmentandevaluaDon–  Okengeneralwishw.r.t.characterisDcs,butnotconcrete–  NostatementtowhichextentthecharacterisDcmustbepresent–  Requirements(andimplementaDon)possibleondifferentlevelsof

abstracDonwithdifferentconcepts(andexpressivity)–  AbstracDonlevelsinfluencemodelingconceptsandcharacterisDcs(as

wellasinterdependencies),andthereforealsotheclassificaDon3.  ClassificaDonofnon-funcDonalrequirements

–  Dependsontheunderlyingqualitymodel–  Dependsontheunderlyingsystemmodelandmodelingconcepts

19

important

Philosophy•  AMDiREconceptmodelbasedon

systemmodelandqualitymodel•  Behaviormodelsareinthecenterfor

funcDonalrequirementsandqualityrequirements

Classifica/onofNFRs•  ProcessRequirements•  DeploymentRequirements•  SystemConstraints•  QualityRequirementsStructuredelicita/onofqualityrequirements•  Fromsystemgoals•  Toscenarios•  Toqualityrequirements

20

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

important

OverviewofrelevantContentItems

1.  ProcessRequirements:RequiredcharacterisDcsoftheprocess/projecte.g.:UseRUPasprocessmodel

2. DeploymentRequirements:Demandsfordeploymente.g.:strategytobefollowedfordatamigraDon

3.  SystemConstraints:System-relatedrestricDonsthatdon‘tnecessarilyresultfromfuncDonalgoals.E.g.:usageofspecifictechnologies

4. QualityRequirements:desiredqualitycharacterisDcsofthesystemexamplesfollowing

21

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

1

2

3

4

4

important

TemplateforAssignment

22

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

1

2

3 4

important

•  3requirementsofeachtype•  DescripDonofchallenges

QualitymodelsanddealingwithNFRs

•  UsageofQualitymodelsinRE•  Exemplaryqualitymodels•  DealingwithNFRsinAMDiRE



FuncDonalRequirementsandTheirPoorCousins:TheTruthAboutNFRs

•  NFRsarenecessarytocompleDngthestoryoftheapplicaDon.Whileyoumightconsider2or3importantNFRsforaproject(likeperformanceandsecurity),you’llprobablynotcovertheothersextensivelyenough,oryoumightmissoutonthemalltogether.

•  AndifyoudoallocateDmetodealwiththemall,whentheprojectscheduleslips,theNFRsmaybethefirstthingyou’lldrop…becausenoonereallyseesthem,andyourteamwillbelookingatthefuncDonalrequirementsinstead.

•  So,whetheryouplanforNFRsornot,chancesarehighyouwon’tcoverthem100%oftheDmeinyourdevelopmentproject.You’llcompromiseandnotthinkofthewholestory–thewholeapplicaDon.

•  Butyoushouldtry.Youshouldtrytoavoidaddingtechnicaldebtandmaintenancenightmarestoyourfutureporyoliowheneverpossible.Thecostofchangeisreal,andthemomentyoudeployyourapp,you’llhavetoaddressitsproblems.

•  FromyourexperiencewhataretheNFRsyouconstantlyseedevelopersandprojectteamsdroppingmostoken?

UsageofqualitymodelsinRE

25

Whatarequalitymodels?à ConceptualmodelsforthedescripDonofquality.

UsageofqualitymodelsinRE•  DefiniDonandassessmentofsokwarequality–beginninginRE

•  Qualityassurance,forexampleofartefactsinRE•  Also:ClassificaDonofrequirementsaccordingtocharacterisDcs

UsageofqualitymodelsinRE

26

Classifica/ononthebasisofqualitymodels•  ClassificaDonofnon-funcDonrequirementsaccordingto

characterisDcs.–  Whichdifferentclassesofrequirementsexist?–  Whichaspectsareimportanttoconsider?–  Whichmodelingconceptsandinterdependenciesareimportanttoconsider?

Delimita/on:Artefactmodels•  Ideallybuildonqualitymodels

(comparetosystemmodels)à Conceptmodel(ContentModel)à Structureoftheconceptmodel

(StructureModel)

Artefact-based RE Approach for Business Information Systems (Basic Components)

StructureModel

Artefact Model

ContentModel

Role Model

Process Model

Tool SupportCustomisation Approach

Met

a M

odel

RE

Ref

eren

ce M

odel

Structure Content

Proj

ect-s

peci

fic

Exem

plar

s

inst

ance

of

inst

ance

of

!

PRODUKT.PROJEKTBEZEICHNUNG - PRODUKT.NAME

Zuletzt geändert: 27.10.2010 13:28 3/20

Content

1! Introduction .......................................................................................................................... 6!

1.1! Overview ....................................................................................................................... 6!

1.2! Purpose .......................................................................................................................... 6!

1.3! References ..................................................................................................................... 7!

1.4! Scope ............................................................................................................................. 8!

2! System Vision ...................................................................................................................... 8!

2.1! Summary of Business Specification.............................................................................. 8!

2.2! Scope of Information System under Consideration ...................................................... 8!

2.2.1! System Overview ................................................................................................... 8!

2.2.2! External Systems .................................................................................................. 10!

2.2.3! Use Case Overview .............................................................................................. 10!

2.2.4! Information System Service Overview ................................................................ 10!

3! Information System Requirements..................................................................................... 11!

3.1! Actors .......................................................................................................................... 11!

3.2! Generic Scenarios........................................................................................................ 11!

3.3! Domain-specific Application Capabilities .................................................................. 12!

3.3.1! <<Business Domain>> <Name>.......................................................................... 12!

3.4! Information System Objects........................................................................................ 14!

3.5! System Quality Requirements..................................................................................... 16!

3.6! Architectural Constraints............................................................................................. 16!

3.6.1! Logical Restrictions.............................................................................................. 17!

3.6.2! Technical Restrictions .......................................................................................... 17!

4! Integrational Requirements ................................................................................................ 18!

4.1! Deployment Requirements.......................................................................................... 18!

4.2! Migration Requirements.............................................................................................. 18!

5! Organisational Requirements ............................................................................................. 19!

5.1! Project Requirements .................................................................................................. 19!

5.2! Obligations .................................................................................................................. 19!

5.3! Glossary....................................................................................................................... 19!

6! Abbreviations ..................................................................................................................... 20!

7! References .......................................................................................................................... 20!

Travel Ordering System

Requirements Specification

Version: 0.1

Project Name <Name>

Project Lead <Name>

Responsible <Name>

Created on <Date>

Last changed

X In process

Submitted

State

Completed

Document File

V-Modell XT Version VMRELEASE 1.3with BISA Extension

illustrative

Met

a M

odel

RE

Ref

eren

ce M

odel

Structure Content

Proj

ect-s

peci

fic

Exem

plar

s

inst

ance

of

inst

ance

of

!



Content

1! Introduction .......................................................................................................................... 6!

1.1! Overview ....................................................................................................................... 6!

1.2! Purpose .......................................................................................................................... 6!

1.3! References ..................................................................................................................... 7!

1.4! Scope ............................................................................................................................. 8!

2! System Vision ...................................................................................................................... 8!



2.2.1! System Overview ................................................................................................... 8!





3.1! Actors .......................................................................................................................... 11!














5.2! Obligations .................................................................................................................. 19!

5.3! Glossary....................................................................................................................... 19!

6! Abbreviations ..................................................................................................................... 20!

7! References .......................................................................................................................... 20!



Version: 0.1

Project Name <Name>

Project Lead <Name>

Responsible <Name>

Created on <Date>

Last changed

X In process

Submitted

State

Completed

Document File


illustrative

Met

a M

odel

RE

Ref

eren

ce M

odel

Structure Content

Proj

ect-s

peci

fic

Exem

plar

s

inst

ance

of

inst

ance

of

!



Content

1! Introduction .......................................................................................................................... 6!

1.1! Overview ....................................................................................................................... 6!

1.2! Purpose .......................................................................................................................... 6!

1.3! References ..................................................................................................................... 7!

1.4! Scope ............................................................................................................................. 8!

2! System Vision ...................................................................................................................... 8!



2.2.1! System Overview ................................................................................................... 8!





3.1! Actors .......................................................................................................................... 11!














5.2! Obligations .................................................................................................................. 19!

5.3! Glossary....................................................................................................................... 19!

6! Abbreviations ..................................................................................................................... 20!

7! References .......................................................................................................................... 20!



Version: 0.1

Project Name <Name>

Project Lead <Name>

Responsible <Name>

Created on <Date>

Last changed

X In process

Submitted

State

Completed

Document File


illustrative

Organisational LevelProcess Integration

Project LevelStatic Tailoring

Dynamic Tailoring

...

Project Scope defined

System Specificationaccepted

...

Business Analyst...

Requirements Engineer

Context Specification


System Specification

Excursion:QualitymodelsQualitymodels•  Determinewhichqualityaspectsandconceptsexistandhowtheseare

related•  SupportthestructuredelicitaDonandmodelingofqualityrequirementsà  E.g.viaataxonomyofqualityazributesExamples:•  ClassificaDonacc.toBoehm(1978)•  IEEE29148SokwareRequirements

DocumentaDonStandard(2011)•  ISO/IEC9126(1993,revised2001)•  TUMS&SEQualityModel•  ISO25010Challenges:

–  ManydifferentqualityaspectsandrelaDonsbetweenthem

–  SystemaDcsintheirapplicaDoninRE(aswellasapplicaDoninassessment)

27

[ISOStd.](Excerpt)

Assessmentofqualitymodels•  Exemplaryqualitymodelsdeterminethetaxonomyofqualitycriteriaandazributes

Cri/calaspects•  Themodelsokenstayontheabstractlevelof„-iliDes“à Nostatementaboutmeasurabilityandassessmentofqualitycriteria

•  NodirectapplicabilitytoRE–  NocluesforexplicitdeducDonofrequiredsystemcharacterisDcsExample:ThedemandformulD-languagedocumentaDonsupportsmaintainability,butalsousability.

–  Othernon-funcDonalaspectsareokennotcovered

28But:qualitymodelsarethebasisfortheclassifica/onofNFRs.

ISO25010

•  Internalquality:mainlyvisibleinthecode,e.g.reusabilityofthecodewithinmaintainability

•  Externalquality:mainlycharacterisDcsthatcanbeseenfromoutsidethesystembutnotnecessarilybytheuser

•  Qualityinuse:perceivedbytheuserofthesystemduringrunDme


ISO25010

Overview:QualityAssurance

•  MoDvaDonandTerminology•  QualityofRequirementsDocuments•  PrinciplesofQualityAssurance•  TechniquesforconstrucDveQA•  TechniquesforanalyDcalQA


KRayker,stock.xchng

TerminologyinthecontextofqualityassuranceinREQualitydefect•  Incorrect(invalid)requirement:Requirementthatdoesnotreflectthe

intenDonofthestakeholder(inthesenseof„validity“)•  Qualitydefect:Requirementthatcanbevalid,buthasqualitaDvedefects,

e.g.missingmeasurability,lowunderstandability,contradictory,...•  InterrelaDonofthosetwo:

–  Incorrectrequirementsareokenhiddenduetoqualitydefects–  Correctnessofrequirementsokenviewedasqualitycriterium

Valida/onandVerifica/on•  ValidaDon:Checkofrequirementw.r.t.correctness(it‘savalid

requirement,meaningitrepresentstheintenDonofthestakeholder)•  VerificaDon:Checkofsystemw.r.t.fulfillmentofrequirements•  BotharepartofQA


QualityAssuranceinRequirementsEngineering

•  Def.QAinRE:ApplicaDonofsystemaDcmeasuresforidenDfyingqualitydefectsandassuringthequalityoftherequirementsspecificaDons.

à Checkofqualitycriteria,e.g.:§  Correctness§  Completeness§  Consistency§  Traceability§  ...(seefollowingslides)

à TheexaminaDoncanbeconductedconstrucDveoranalyDcalusingaformalprocedure.

34

Focus of quality assurance in RE

PerspecDvesinQAinRE•  WedisDnguishthequalityof

–  Requirementsdocuments/artefacts–  Setsofrequirements/statements–  Individualrequirements–  Systems

35

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

Analytical QS

Dependingonthequalitycriteria,responsibleforcheckingare:•  ProjectteammemberswithdomainknowledgeduringelaboraDonofthe

requirements,e.g.„correctness“àthisiscalledconstrucDveQA•  External/neutralqualityresponsibleswhoperformchecks,e.g.

„traceability“and„understandability“àthisiscalledanalyDcalQAàWhichmeasurescanyouthinkofforperformingeitherofthese?

Constructive QS

PrincipleofconstrucDveandanalyDcalQA

36

Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

Projectteam

Qualityresponsible

ClassificaDonofQA

QA

ConstrucDve

Processstandards

Qualitycriteria

LinguisDcrules

Programmingguidelines

NamingconvenDons

StructuringconvenDons

AnalyDcal

Analyzing

Metrics

Anomalyanalysis

Graphics

TesDng

Dynamictests

Review/inspecDon

Autom.staDcanalysis

Verifying

FormalverificaDon

ModelcheckingDr.BirgitPenzenstadler 37

Note:thisisageneralclassificaDonofQA,andnotallofitappliestoQAwithinRE.

ReferenceModels

•  AMDiRE•  IEEE830•  Cockburntemplate•  UML2standard


Checklist:QuesDonsandCriteriaforaspreadsheetwithrequirements

•  Completeness:Readthrough,aretheresDllopenquesDons?Leadengineer,stakeholder,customer

•  Consistency:Checkforrequirementsconflicts•  Unambiguity:languagecheck,letsomeoneelsereaditwhetheritcouldbe

misunderstood•  Correctness:checkwithstakeholder•  Structuredness:adherestotemplate/outline,hasabreakdownthat

makessense•  Traceability:linksbetweenrequirementsinspreadsheet,acrossversions

ofspreadsheet•  Changeability:checkdependenciesbetweenrequirements(highdegreeof

dependenciesmeanslowchangeability)•  Understandability:letsomeoneelsereaditwhetherit‘seasyto

understand•  Agreedupon:checkwithstakeholder

39

LinguisDcsinRE•  ClassificaDonoflinguisDcqualitydefects

–  Lexical/ontological(whatdoes„green“mean?)–  SyntacDc(“Isawthemanonthehillwithatelescope”)–  SemanDc(“AllpersonshaveauniquenaDonalinsurancenumber“)

–  PragmaDc(“Thetrucksshalltreattheroadsbeforetheyfreeze“)–  Weakphrases:(“assoonaspossible“)–  OmissionorgeneralizaDon

•  Syntaxpazerns–  [when?][underwhatcondiDons?]THESYSTEMSHALL|SHOULD|WILL<process><thingtobeprocessed>[<processdetail>*]

40

IEEE730–2014:IEEEStandardforSokwareQualityAssuranceProcesses


Overview:Change&RiskManagement

•  Recap:RequirementsManagement•  ChangeManagement•  RiskManagement


Recap:REintheprocess


ValidaDonTraceabilityMatrix

Plan,decide,managerisks,managechanges

Risk&StatusReport

RequirementsEngineering

ProjectmanagementRequirementsManagement

RequirementsEngineering

AnalysisElicitaDon

DocumentaDon

RequirementsManagement:Tasks

44

•  RaDonaleManagementandTraceability–  RaDonaleforrequirements–  RelaDonbetweencontentitems

•  Managementoftherequirements–  Structuring,documentaDonandarchiving–  AzribuDon

•  Interdependencywithothermanagementtasks–  ValidaDonandVerificaDon–  ChangemanagementandImpactAnalysis–  Versionmanagement–  ConfiguraDonmanagement–  Claimmanagement–  SupportfordistributedRE–  ToolsupportforRM

Recap:Azributesforrequirements•  ID•  DescripDon•  Owner•  Stakeholder•  Source•  RaDonale•  State•  AccceptanceCriterion•  TimeConstraint•  PriorityàMakesurealloftheseareupdatedinthechangeprocess

45

Managingrequirements

•  Bigprojectsmayhavethousandsofrequirements•  Formanagement,thestandardprocessis

1.  Allaresubmizedtoadatabase2.  Andmanagedviatheirazributes3.  FortherespecDvemilestone,requirementsare

decidedupon(„Freeze“/„Baseline“)4.  Andokengatheredinadocumentforofficial

approvalà Akerthisofficialapproval,furtherchangeshavetoadheretoastandardizedchangeprocess

46

ChangeManagement–how?Foursteps•  SystemaDcelicitaDonofChangeRequests•  Decisiononpriorityandcosts•  DecisiononimplementaDon•  ImplementaDonofchangesImportantrelatedtasks:•  Impactanalysis:Whatconsequencesdochangeshave?•  Versionmanagement:Whichversionsofrequirementsexist?•  ConfiguraDonmanagement:Whichrequirementsformconsistent

baselines?•  Defectmanagement:Howtodealwithdefectsandtheir

correcDon?

47

ChangeManagement–how?StatusofRequirement


KRayker,stock.xchng

Proposed

Assumption

Validated

Applied

Tested

Denied

ReleasedAccepted

Designed Implemented[Information System

Requirements]

[Other]

New Req

RiskManagement

Dr.BirgitPenzenstadler 49www.pharmadirecDons.com

SWOTanalysis

Dr.BirgitPenzenstadler 50CSULBspring2015

Root-causeanalysis

•  (Strengths,weaknesses,opportuniDes,threats)

•  Root-causeanalysis

Dr.BirgitPenzenstadler 51CSULBspring2015

Projectplan:Whattodefine?Infrastructureplusprojectcontent.


Process Task

Next Process

A This has anassociated...Note or

suggestionProcess model

AcDviDes/M

etho

ds

ArDfacts

Tools

Roles

Mileston

es

Soundsfamiliar?Guesswhat…arDfacts!


Context Layer

System Layer

Requirements Layer


Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision



System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case


System Constraints

Domain Model



Risk List

Project Scope


Glossary

Glossary

Glossary

Let’sdoit:Budget

It’sspreadsheeto’clock!!1.  (EsDmaDonofrequiredhardware)2.  (EsDmaDonofrequiredsokware)3.  EsDmaDonofdevelopmentwork


Sokwarepricing

•  EsDmatesaremadetodiscoverthecost,tothedeveloper,ofproducingasokwaresystem.–  Youtakeintoaccount,hardware,sokware,travel,trainingandeffortcosts.

•  ThereisnotasimplerelaDonshipbetweenthedevelopmentcostandthepricechargedtothecustomer.

•  BroaderorganisaDonal,economic,poliDcalandbusinessconsideraDonsinfluencethepricecharged.

55

IanSommerville,SokwareEngineering,9thEdiDon

Then:DefineforProjectManagement

•  ChangeManagement•  RiskManagement• ValidaDon&verificaDon• Version&configuraDonmanagement• Claimmanagement• SupportfordistributedRE


RequirementsRaDonale

HotresearchtopicsinRE•  PaperbyNuseibehandEasterbrook,2000

•  UpdatepaperbyChengandAtleein2007


Nuseibeh&Easterbrook:Decade1990-2000(beforepublicaDon)

During1990-2000,wecandiscerntheemergenceofthreeradicalnewideasthatchallengedandoverturnedtheorthodoxviewsofRE.Thesethreeideasarecloselyinterconnected:•  TheideathatmodellingandanalysiscannotbeperformedadequatelyinisolaDon

fromtheorganisaDonalandsocialcontextinwhichanynewsystemwillhavetooperate.Thisviewemphasisedtheuseofcontextualisedenquirytechniques,includingethnomethodologyandparDcipantobservaDon[29;63].

•  ThenoDonthatREshouldnotfocusonspecifyingthefuncDonalityofanewsystem,butinsteadshouldconcentrateonmodellingindicaDveandoptaDveproperDesoftheenvironment2[84].Onlybydescribingtheenvironment,andexpressingwhatthenewsystemmustachieveinthatenvironment,wecancapturethesystem’spurpose,andreasonaboutwhetheragivendesignwillmeetthatpurpose.ThisnoDonhasbeenaccompaniedbyashikinemphasisawayfrommodellinginformaDonflowandsystemstate,andtowardsmodellingstakeholders’goals[15]andscenariosthatillustratehowgoalsare(orcanbe)achieved[51].

•  TheideathattheazempttobuildconsistentandcompleterequirementsmodelsisfuDle,andthatREhastotakeseriouslytheneedtoanalyseandresolveconflicDngrequirements,tosupportstakeholdernegoDaDon,andtoreasonwithmodelsthatcontaininconsistencies[28].


N&E’sPredicDonfor2000-2010•  DevelopmentofnewtechniquesforformallymodellingandanalysingproperDesoftheenvironment

•  BridgingthegapbetweenrequirementselicitaDonapproachesbasedoncontextualenquiryandmoreformalspecificaDonandanalysistechniques.

•  Richermodelsforcapturingandanalysingnon-funcDonalrequirements.

•  BezerunderstandingoftheimpactofsokwarearchitecturalchoicesontheprioriDsaDonandevoluDonofrequirements.

•  Reuseofrequirementsmodels.•  MulDdisciplinarytrainingforrequirementspracDDoners.


Cheng&Atlee:Hottopics

•  Scale•  Security•  Tolerance•  IncreasedRelianceonEnvironment•  Self-Management•  GlobalizaDon•  Methodologies,pazerns,andtools•  RequirementsReuse•  EffecDvenessofREtechnologies


Misusecases(Sindre&Opdahl)

Cheng&Atlee:FiverecommendaDons

…thattheREcommunitycouldtakeimmediateacDonon,tostartimprovingthematurityofcurrentrequirementstechnologies:•  ResearchersshouldworkwithpracDDoners.•  REresearchersshouldworkwithotherSEresearchersand

pracDDoners,toestablishstrongerlinksbetweentheirrespecDvearDfacts.

•  REresearchersshouldnotneglectevaluaDonandempiricalresearch.

•  IndustrialorganizaDonsshouldprovide(saniDzed)industrial-strengthprojectdatatoresearchers.

•  REresearchersandpracDDoners,together,shouldestablishrepositoriesofREarDfacts.


requirements engineering - recap

Software