Founda'onsofSo,wareEngineering

Lecture6–Requirements(3/3)ClaireLeGoues

1

REFLECTIONSONREFLECTIONS

ExamplesadaptedarbitrarilyfromprioryearswithoutidenCfyinginformaCon!

Reflec'ondocuments

Shallow•  Recitefactsaboutwhat

happenedwithoutaddinganything.

•  RecitestatementsfromclasswithoutconnecCngtoexperience.

•  Statelessonslearnedwithoutanyreasonwhy.

Good•  Extrapolatefromthefactstoaddinsight.

•  Meaningfullyconnectpriorexperienceorclassmaterialtoassignmentexperience.

•  Supportlessonslearnedwithevidence.

Also

•  Thehomeworkdocumentincludesbulletedlistsandproseoutliningwhata“goodsoluCon”lookslike.•  Considercheckingyoursubmissionagainstit,attheveryleastbeforesubmiOng,ifnotsooner.

Learninggoals•  DifferenCatebetweenverificaConandvalidaCon.

•  ExplainthepurposeofrequirementsdecomposiCon,allocaCon,andflowdown.

•  IdenCfystrategiesfordealingwithconflicts.•  Understandriskanditsroleinrequirements,specificallyhowitcanbemodeled,analyzed,andthenmiCgated/handledinsystemdesign.

Verifica'onvs.Valida'on•  VerificaCon–isthesoXwarecorrect?– DoesthesoXwaresaCsfythespecificaCon?– IsthespecificaConcorrectwithrespecttotherequirements,assumingthedomainproperCeshold?

•  Valida'on–aretherequirementscorrect?– Aretherequirementscomplete?Dotheyaccuratelyreflecttheclient’sproblem?– Aretherequirementsconsistent?

Valida'on walkthroughsReadingInterviewsReviewsChecklistsModelstocheckfuncConsandrelaConshipsScenariosPrototypesSimulaConFormalinspecCon

Verifica'on Cross-referencingSimulaConConsistencychecksCompletenesschecksChecksforunreachablestatesortransiCons(cf.Modelchecking)MathemaCcalproofs

Requirementsshouldbe1.  Correct2.  Consistent3.  Unambiguous4.  Complete5.  Feasible6.  Relevant7.  Testable8.  Traceable

8

Accordingtoboththeengineerandthecustomer

InthattherearenoconflicCngrequirements.Qualityrequirements

areparCcularlydangerous.Ambiguous:mulCplereaderscanwalkawaywithdifferentbutvalid

interpretaCons.Coversallrequiredbehaviorandoutputforallinputsunderall

constraints.Canitbedoneatall?Again,quality/non-funcConalreqsareparCcularly

vulnerable.

Acceptancetestsandmetricsarepossible/obvious.

Organized,uniquelylabeled.

ManagingInconsistency

•  Informal–recognizingwhentworequirementsarenotmutuallysaCsfiable

•  HeurisCc–employingsystemaCc,manualtechniquestosurfaceconflicts

•  Formal–usingformalmodelstoexpressandreasonaboutpotenCalconflicts

Gainingcoherence•  IdenCfyactors:users,othersystems

–  Primaryusers,support,administraCon–  Externalhardware,soXwaresystems

•  IdenCfyscenarios–  DetailednarraCvescenariosoftypicalfuncConality–  Concreteexamples

•  Canbethebasisfortestcases•  CanbeabasisforcommunicaConwithstakeholders/users

•  IdenCfyusecases–  Representmorecompletepicturesofthesystemincontext–  AbstracConofallcases,derivedfromparCcularscenarios

•  Analyzeandrefineusecases–  ConsiderexcepCons,errors,securityissues–  Addressothernon-funcConalrequirements

•  Relateusecases–  Createaconsolidateduse-casemodel

10

Decomposi'on

Stakeholderrequirements

System

System

SubsystemA SubsystemB SubsystemC

Ini'aldecomposi'on

High-levelplan

Why?

•  DecomposiConintoahierarchyhelpsestablishtraceability,whichidenCfiesrelaConshipsbetweenrequirements.•  Defini&on?•  Traceabilityisimportantforwhenrequirementschange.•  DecomposiConalsohelpsbothvalidateandverifytherequirements.

Alloca'onandflowdown

•  Grouping(e.g.,bybusinessfuncCon)enablesanalysis

•  AllocaConistheassignmentofrequirementstosubordinatesystems

•  FlowdownisthediscoveryofaddiConalrequirementsfromtheallocatedrequirements

Groupbybusinessfunc'onBusinessfuncConsprovidelogicalgroupsforusecases

•  MarkeCng

•  HumanResources

•  ProducCon•  Sales•  DistribuCon

HiringandRecruitmentBenefitsPerformanceReviewsPromoConReCrement

ShippingReceivingInventory

Groupbysuperordinatesystem•  Superordinatesystemscutacrosssubordinatesystems,suchasbusinessfuncCons

AdverCseproduct

Buildsystem

Receiveorder

Scheduledelivery

MarkeCng ProducCon Sales DistribuCon

AsuperordinatesystemthattracesaproductfrommarkeCngtodistribuCon.Theanalystcannowfocusondevelopingtheinterfaces

betweentheseusecases

Alloca'onandflowdown

Superordinateusecase Subordinatesystems

AllocateusecasestosubordinatesystemsFlowdowndiscovers“derivedrequirements”tofulfillthe

allocatedrequirements

Superordinateusecases

candriveflowdown

Alloca'onandflowdown

Receiveorder

Sales

Checkinventory

Processpayment

DistribuCon

Processorder

Superordinateusecase Subordinatesystems

AllocateusecasestosubordinatesystemsFlowdowndiscovers“derivedrequirements”tofulfillthe

allocatedrequirements

Scheduledelivery

Beforeweprocessapayment,weshould…

Pre-andpost-condi'ons•  Pre-condiCons:truebeforetheusecasebegins•  Post-condiCons:trueattheendoftheusecase•  Shouldbewrijenatthesame“levelofdetail”astheusecase

•  Applytothestateofthesystem,nottheenvironmentoutsidethesystem[Armour&Miller]– Thebookhasastatusofborrowed– Thepatronisfreetoleavethelibrarywiththebook

18

DependencyStreams

•  Dependencystreamsdescribeusecasesthatdependoneachother

– Matchingpre-andpost-condiCons

– PerformingacConsinparallel

– HighlightinterfacesbetweenbusinessfuncCons

Matching pre- and post-conditions

20

Selectproduct

Purchaseorder

Post-condition: Customer has selected products

Pre-condition: Customer is ready to check out

Tracingscenariosthroughcases

Receiveorder

Processpayment

Scheduledelivery

Placeorder

Assump'on:deliveryoccursovertheweekend

Assump'on:productsareallinstock

Assump'on:orderingisautomatedintheevening

Stuplaceshisorder…

Thisscenariocutsacrossbusinessfunc&onstotest

theinterfacesbetweenusecases

Checkinventory

Thisisaderivedrequirement

Modifyingusecasesforscenarios

Scheduledelivery

Assump'on:deliveryoccursovertheweekend

Placeorder

Stuplaceshisorder…

Receiveorder

Processpayment

Confirmorder

NoCfydelay

Assump'on:productsareallinstock

Checkinventory

<<extends>>

Logicalconflicts

• Whenshouldthetraindoorsbeopen?– ThetraindoorsremainclosedbetweenstaCons

– Thetraindoorsremainopenduringemergencies

– Thetraindoorsremainclosedwhilethetrainismoving

Terminologyconflicts•  StudentsshallhaveaccesstolibraryfaciliCes

•  Whatisastudent?– Astudentisenrolledinacoursepastthedropdate– Astudentisenrolledinadegreeprogram– Analumnusoralumnashouldhavelibraryaccess

•  Howdowereconcilethesedifferences?

Whydoconflictsarise?•  Differentactorsformulategoals–  Limitedborrowingperiods(staff)– Borrowingforaslongasneeded(patrons)

•  Goalboundariesarevague– DoorsremainclosedbetweenstaCons– DoorsopenwhentrainstopsandevacuaConalarm

•  TwosoXgoalsprescribeanincreaseanddecreaseinthesamequanCty

Strongversusweakconflicts•  Strongconflictscannotbereconciled– RetaincreditcarddataforeasierfuturetransacCons– DonotretaincreditcarddataaXercompleCngatransacCon

•  Weakconflictscanbereconciled– ThetraindoorsremainclosedbetweenstaCons– Thetraindoorsremainopenduringemergencies– Thetraindoorsremainclosedwhilethetrainismoving

Goalconflicts

•  Conflictsarisebetweengoalsatdifferentlevelsinthegoalhierarchy

“Lightningbolt”Indicatesaconflict

AvoidVoterIDCapture

RegisteredVoterVerified

MaintainSecretBallots

MaintainTrustedElecCons

VoterIDCaptured

Weakeninggoalstoresolveconflicts

AvoidVoterIDCapture

VoterIDCaptured

AvoidVoterIDLinking

AvoidVoterIDTransfer

MaintainSecretBallots

RegisteredVoterVerified

Transfertheconflictoutside

AvoidVoterIDCapture

RegisteredVoterVerified

VoterIDCaptured

VoCngMachine StaConAjendant

VoterIDVerified

MaintainSecretBallots

Priori'zingUseCases•  AssigningaprioritytoausecasetoincreaseordecreasetheacCvity’simportance.

•  WhataresomeopCons?– Customerpriority– Risk– Complexity– Dependencies– CorefuncConality– User-facingacCviCes– Uncertainty(sameasrisk?)

30

Prioritize by risk •  AriskisanuncertainfactorthatmayresultinalossofsaCsfacConofacorrespondingobjecCve

Forexample…

–  SystemdeliversaradiaConoverdosetopaCents(Therac-25,Theratron-780)

– MedicaConadministraConrecord(MAR)knockout

– PremierElecConSoluConsvote-dropping“glitch”

31

Riskanalysisinsafety-cri'calsystems•  Safetyrequirementsarenotderivedfromstakeholders.• Whynot?

TheSwisscheesemodelRegulatorynarrowness

Incompleteprocedures

Mixedmessages

ProducConpressures

ResponsibilityshiXing

Inadequatetraining

AjenCondistracCons

Deferredmaintenance

Clumsytechnology

InsCtuConalOrganizaCon

Profession&Team

Individual Technical

ModifiedfromReason,1999,byR.I.Crook

Howtoassessthelevelofrisk?

•  RisksconsistofmulCpleparts:– Likelihoodoffailure– NegaCveconsequencesorimpactoffailure– Causalagentandweakness(inadvancedmodels)

•  Risk=LikelihoodxImpact

Likelihoodvs.ImpactSeverity

50%

20%

70%

4

9

3

012345678910

0%

10%

20%

30%

40%

50%

60%

70%

80%

Risk#1 Risk#2 Risk#3

Severityoffa

ilure

Likelih

oodoffa

ilure

Likelihood Impact

CVSSV2.10ScoringTheCommonVulnerabilityScoringSystemconsistsof:

–  6basemetrics(accessvector,complexity,confidenCalityimpact,…)–  3temporalmetrics(exploitability,remediaCon,…)–  5environmentalmetrics;allqualitaCveraCngs(collateraldamage,…)

BaseScore=round_to_1_decimal(((0.6*Impact)+(0.4*Exploitability)–1.5)*f(Impact))

Impact=10.41*(1-(1-ConfImpact)*(1-IntegImpact)*(1-AvailImpact))

Exploitability=20*AccessVector*AccessComplexity*AuthenCcaCon

f(impact)=0ifImpact=0,1.176otherwise

Avia'onfailureimpactcategories•  Noeffect–failurehasnoimpactonsafety,aircraXoperaCon,orcrew

workload

•  Minor–failureisnoCceable,causingpassengerinconvenienceorflightplanchange

•  Major–failureissignificant,causingpassengerdiscomfortandslightworkloadincrease

•  Hazardous–highworkload,seriousorfatalinjuries

•  Catastrophic–lossofcriCcalfuncContosafelyflyandland

DO-178b,SoXwareConsideraConsinAirborneSystemsandEquipmentCerCficaCon,RTCA,1992

Faulttreeanalysis

•  Top-downanalysistechniquetomodel,reasonabout,andanalyzerisk.•  DecomposeaparCculartypeoffailureintoconsCtuentpotenCalcausesandprobabiliCes.•  DefinescopeofsystemresponsibiliCes,idenCfyunacceptableriskcondiConsthatshouldbemiCgated.

Top-levelorintermediateevent

Undevelopedevent

Basicevent

Orgate

Andgate

Transfergate

Faulttreestoquan'fyriskDooropenswhiletrainmoving

SoXwarecontrollerfails

Dooractuatorfails

Speedometerfails

Passengerforcesdoors

open

Wrongrequirements

WrongassumpCon

WrongspecificaCon

WrongimplementaCon

Trainismoving OR

OR

AND

Riskmi'ga'on/responsestrategies

•  Accepttherisk–forlowlikelihoodorlowimpactrisks,orwherecostofmiCgaConprecludessystem

•  Transfertherisk–pushtheriskoutsidethesystemboundary

•  MiCgatetherisk–introduceacCvecountermeasures–  Reducelikelihoodoffailure–  Reduceseverityofimpact–  Changeorstoands!

•  Avoidtherisk–redesignsothatriskcannotoccur

Exercise!

•  Unacceptablesystemfailure:agivenCMUstudentfailsamidterm.

Top-levelorintermediateevent

Undevelopedevent

Basicevent

Orgate

Andgate

Transfergate

Wrap-up:day1•  ExplainwithexamplestheimportanceofrequirementsinsoXwareengineering.

•  ExplainhowandwhyrequirementsarCculatetherelaConshipbetweenadesiredsystemanditsenvironment.

•  DisCnguishbetweenandgiveexamplesof:funcConalandnon-funcConalrequirements;informalstatementsandverifiablerequirements.

•  IdenCfysystemstakeholdersanddevelopapproachesonhowtointerviewthem.

44

Wrap-up:day2

•  Developusecases.•  UnderstandthechallengesofinternaConalizaConinthecontextofthechallengesofrequirementselicitaCon.

45

Wrap-up:day3•  DifferenCatebetweenverificaConandvalidaCon.

•  ExplainthepurposeofrequirementsdecomposiCon,allocaCon,andflowdown.

•  IdenCfystrategiesfordealingwithconflicts.•  Understandriskanditsroleinrequirements,specificallyhowitcanbemodeled,analyzed,andthenmiCgated/handledinsystemdesign.