Founda’ons of Soware Engineering
53
Founda’ons of So,ware Engineering Lecture 5 – Requirements (1/3) Claire Le Goues 1
Transcript of Founda’ons of Soware Engineering
Founda'onsofSo,wareEngineering
Lecture5–Requirements(1/3)ClaireLeGoues
1
Administrivia
• CanvasOK?– VsPiazza?
2
Learninggoals• ExplainwithexamplestheimportanceofrequirementsinsoHwareengineering.
• ExplainhowandwhyrequirementsarMculatetherelaMonshipbetweenadesiredsystemanditsenvironment.
• DisMnguishbetweenandgiveexamplesof:funcMonalandnon-funcMonalrequirements;informalstatementsandverifiablerequirements.
• IdenMfysystemstakeholdersanddevelopapproachesonhowtointerviewthem.
3
Healthcare.gov
4
FredBrooks,onrequirements.• Thehardestsinglepartofbuildingaso3waresystemisdecidingpreciselywhattobuild.
• Nootherpartoftheconceptualworkisasdifficultasestablishingthedetailedtechnicalrequirements...
• Nootherpartoftheworksocripplestheresul=ngsystemifdonewrong.
• Nootherpartisasdifficulttorec=fylater. —FredBrooks
5
Aproblemthatstandsthetestof'me…A1994surveyof8000projectsat350companiesfound:31%ofprojectscanceledbeforecompleted;9%ofprojectsdeliveredonMme,withinbudgetinlargecompanies,16%insmallcompanies.
– Similarresultsreportedsince.Causes:
1. Incompleterequirements(13.1%)2. Lackofuserinvolvement(12.4%)3. Lackofresources(10.6%)4. UnrealisMcexpectaMons(9.9%)5. LackofexecuMvesupport(9.3%)6. ChangingrequirementsandspecificaMons(8.7%)7. Lackofplanning(8.1%)8. Systemnolongerneeded(7.5%).
6
Overlysimplifieddefini'on.
Requirementssaywhatthesystemwilldo(andnothowitwilldoit).
7
WHYISTHISHARD?
8
Communica'onproblem
Goal:figureoutwhatshouldbebuilt.Expressthoseideassothatthecorrectthingisbuilt.
9
FourKindsofDenial• Denialbypriorknowledge–wehavedonethisbefore,soweknowwhatisrequired
• Denialbyhacking–ourfascinaMonwithmachinesdominatesourfocusonthehow
• DenialbyabstracMon–wepursueelegantmodelswhichobscure,removeordownplaytherealworld
• Denialbyvagueness–imply(vaguely)thatmachinedescripMonsareactuallythoseoftheworld
MichaelJackson,“TheWorldandtheMachine,”Interna=onalConferenceonSo3wareEngineering,pp.283-292,1995.
Lesssimplifieddefini'on.• Stories:ScenariosandUseCases
“AHerthecustomersubmitsthepurchaseinformaMonandthepaymenthasbeenreceived,theorderisfulfilledandshippedtothecustomer’sshippingaddress.”
• OptaMvestatementsThesystemshallnoMfyclientsabouttheirshippingstatus
• DomainProperMesandAssumpMonsEveryproducthasauniqueproductcodePaymentswillbereceivedaHerauthorizaMon
11
Whatisrequirementsengineering?
• Knowledgeacquisi'on–howtocapturerelevantdetailaboutasystem?– Istheknowledgecompleteandconsistent?
• Knowledgerepresenta'on–oncecaptured,howdoweexpressitmosteffecMvely?– Expressitforwhom?– Isitreceivedconsistentlybydifferentpeople?
• YoumaysomeMmesseeadisMncMonbetweentherequirementsdefini=onandtherequirementsspecifica=on.
12
Func'onalRequirements• Whatthemachineshoulddo– Input– Output– Interface– Responsetoevents
• Criteria– Completeness:Allrequirementsaredocumented– Consistency:Noconflictsbetweenrequirements– Precision:Noambiguityinrequirements
13
Quality/Non-func'onalrequirements• SpecifynotthefuncMonalityofthesystem,butthequalitywithwhichitdeliversthatfuncMonality.• CanbemorecriMcalthanfuncMonalrequirements– CanworkaroundmissingfuncMonality– Low-qualitysystemmaybeunusable
• Examples?
14
Here’sthething…• Whoisgoingtoaskforaslow,inefficient,unmaintainablesystem?
• Abeqerwaytothinkaboutqualityrequirementsisasdesigncriteriatohelpchoosebetweenalterna=veimplementa=ons.
• QuesMonbecomes:towhatextentmustaproductsaMsfytheserequirementstobeacceptable?
15
Func'onalrequirementsandimplementa'onbias
Requirementssaywhatthesystemwilldo(andnothowitwilldoit).
16
EnvironmentandtheMachine
• Thepilotshalldecreaseairspeedandlowerthelandinggearpriortodecisionheight
• Theplaneshalllowerthewingflapsto30°forlanding
MachineDomainEnvironmentalDomain
RequirementsDomainKnowledge
ComputersSoHwarePrograms
SpecificaMons
PamelaZave&MichaelJackson,“FourDarkCornersofRequirementsEngineering,”ACMTransac=onsonSo3wareEngineeringandMethodology,6(1):1-30,1997.
17
18
Avoidingimplementa'onbias• Requirementsdescribewhatisobservableatthe
environment-machineinterface.• Indica=vemooddescribestheenvironment(as-is)• Opta=vemoodtodescribetheenvironmentwiththe
machine(to-be).
Whatothermodelsoftheworlddomachinesmaintain?
Ac'onsofanATMcustomer:withdrawal-request(a,m)Proper'esoftheenvironment:balance(b,p)
Ac'onsofanATMmachine:withdrawal-payout(a,m)Proper'esofthemachine:
expected-balance(b,p)
19
Domainknowledge• RefinementistheactoftranslaMngrequirementsintospecifica=ons(bridgingthegap!)
• Requirements:desiredbehavior(effectontheenvironment)toberealizedbytheproposedsystem.
• AssumpMonsordomainknowledge:exisMngbehaviorthatisunchangedbytheproposedsystem.– CondiMonsunderwhichthesystemisguaranteedtooperatecorrectly.
– Howtheenvironmentwillbehaveinresponsetothesystem’soutputs.
20
Assump'ons?
21
Assump'ons?
22
Grounding,or:Reality• Able:Twoimportantbasictypesarestudentandcourse.ThereisalsoabinaryrelaMonenrolled.
• Baker:Doonlystudentsenrollincourses?Idon’tthinkthat’strue.
• Able:Butthat’swhatImeanbystudent!• DesignaMon:themeaningofaprimiMve.– Willbeexplainedinformally,butshouldsMllbeprecise,recorded,andmaintained.
23
Designa'onsgroundformalspecifica'ons.• SpecificaMonsarelogicalexpressionsofsharedacMonsattheinterfaceofthemachine
• ThisincludeslinkingdomainproperMesandagentacMonsaspre-andpost-condiMons
∀s∀c(enrolled(s,c)⇒student(s)∧course(c))
Somegapsmustremain…• UnsharedacMonscannotbeaccuratelyexpressedinthemachine– Peoplecanjumpovergates(enterwithoutunlocking)– Peoplecanstealormisplaceinventory
• Futurerequirementsarealsonotdirectlyimplementable– Phonesystem:“AHeralldigitshavebeendialed,doring-back,busy-toneorerror-tone.”– …howdoyouknowtheuserisdonedialing?
25
Lu,hansaFlight2904-1• TheAirbusA320-200airplane
hasasoHware-basedbrakingsystemthatconsistsof:– Groundspoilers(wing
platesextendedtoreduceliH)
– Reversethrusters– Wheelbrakesonthemain
landinggear• Toengagethebrakingsystem,
thewheelsoftheplanemustbeontheground.
26
IsthisasharedoranunsharedacMon/condiMon?
Lu,hansaFlight2904-2Therearetwo“onground”condiMons:1. Eithershockabsorberbearsaloadof6300kgs2. Bothwheelsturnat72knots(83mph)orfaster
• GroundspoilersacMvateforcondiMons1or2• ReversethrustacMvatesforcondiMon1onbothmainlandinggears
• WheelbrakeacMvaMondependsupontherotaMongainandcondiMon2
27
Expressingqualityrequirements
• Requirementsserveascontracts:theyshouldbetestable/falsifiable.
• Informalgoal:ageneralintenMon,suchaseaseofuse.– MaysMllbehelpfultodevelopersastheyconveytheintenMonsofthesystemusers.
• Verifiablenon-funcMonalrequirement:AstatementusingsomemeasurethatcanbeobjecMvelytested.
28
Examples• Informalgoal:“thesystemshouldbeeasytousebyexperiencedcontrollers,andshouldbeorganizedsuchthatusererrorsareminimized.”
• Verifiablenon-func'onalrequirement:“ExperiencedcontrollersshallbeabletouseallthesystemfuncMonsaHeratotaloftwohourstraining.AHerthistraining,theaveragenumberoferrorsmadebyexperiencedusersshallnotexceedtwoperday,onaverage.”
29
Webvideoscenario• Youworkforacustom
soHwaredeveloperasarequirementsengineer.
• Client’sstatedrequirement:“Wewanttosellvideosontheweb.”
• Youmustnowengagetheclienttoelaboratethestatedrequirement– Howwillyouproceed?– Howshallweexpresswhatwelearn?
30
RequirementsmetricsProperty Measure
31
Webvideoscenario• Youworkforacustom
soHwaredeveloperasarequirementsengineer.
• Client’sstatedrequirement:“Wewanttosellvideosontheweb.”
• Youmustnowengagetheclienttoelaboratethestatedrequirement– Howwillyouproceed?– Howshallweexpresswhat
welearn?• Step1:talktotherelevant
stakeholders
32
Ques'on
• Whoisthesystemfor?• Stakeholders:– Endusers– Systemadministrators– Engineersmaintainingthesystem– Businessmanagers– …whoelse?
33
Stakeholder
• Anypersonorgroupwhowillbeaffectedbythesystem,directlyorindirectly.• Stakeholdersmaydisagree.• RequirementsprocessshouldtriggernegoMaMontoresolveconflicts.– (Wewillreturntoconflicts).
34
Definingactors/agents
• AnactorisanenMtythatinteractswiththesystemforthepurposeofcompleMnganevent[Jacobson,1992].– Notasbroadasstakeholders.
• Actorscanbeauser,anorganizaMon,adevice,oranexternalsystem.
35
SalesSpecialist
MarkeMng GPSReceiver
InventorySystem
Stakeholderanalysis:criteriaforiden'fyingrelevantstakeholders• RelevantposiMonsintheorganizaMon• EffecMveroleinmakingdecisionsaboutthesystem
• LevelofdomainexperMse
• Exposuretoperceivedproblems
• Influenceinsystemacceptance
• PersonalobjecMvesandconflictsofinterest36
CHALLENGES?
37
Stakeholders,aNASAexample
From HSI NAP 11893
Interviews• Goal:understandfuncMonal
requirements,idenMfyandlearndomain-specificconcepts,prioriMzequalityaqributes.
• EffecMveinterviewers:– BeginconcretelywithspecificquesMons,
proposals,orworkingthroughaprototype.– Areopen-mindedandwillingtoexplore
addiMonalissuesthatarisenaturally,butstayfocusedonthesystem.
• Stories,scenarios,usecases(informal),hypothe'cals,examples.
• Understand/contrastwithcurrentsystem(ifapplicable).
39
Interviewbenefitsvsdrawbacks
• Strengths– Whatstakeholdersdo– Howtheyinteractwiththesystem– Challengeswithcurrentsystems
• Weaknesses– Capturingdomainknowledge– Familiarity– Technicalsubtlety– OrganizaMonalissues,suchaspoliMcs– Completeness
40
• Yai:non-profit;mostemployeesinsocialworkfield• CurrentlysellstrainingDVDsforcompaniesonissuesrelatedtoindividualswithdevelopmentaldisabiliMes.• “Doyouknowhowwecansellcoursematerialsonline?”
41
• Humans:beqeratrecognizingwhetherasoluMoniscorrectthansolvingtheproblemfromablankpage.
• Mock-ups/prototypeshelpexploreuncertaintyintherequirements.– Validatethatwehavetherightrequirements.– Elicitrequirementsatthe“borders”ofthesystem.– AssertfeasibilityofsoluMonspace.– GetfeedbackonacandidatesoluMon.– AlsogoodforquesMonsaboutUI.
• “I’llknowitwhenIseeit”ßscary.
42
High-vslow-fidelitymockups
43
Rapidprototyping
• Throw-away:developedtolearnmoreaboutaproblem,notintendedforactualuse.
• EvoluMonary:intendedtobeincorporatedintothefinalproduct.
44
Storyboardingandscenarios
45
Story
• Whotheplayersare• Whathappenstothem• Howithappensthroughspecificepisode• Whythishappens• Whatifsuchandsuchaneventoccurs• Whatcouldgowrongasaconsequence
46
• Storyboardsillustratescenarios:atypicalsequenceofinteracMonamongsystemcomponentsthatmeetsanimplicitobjecMve.– Storyboardsexplicitlycoveratleastwho,what,andhow.
• Differenttypes:– PosiMvevsnegaMve(shouldandshouldnothappen)– Normalvsabnormal
• AspartofelicitaMon:– Learnaboutcurrentorproposedsystembywalkingthroughreal-lifeorhypotheMcalsequences
– CanaskspecificquesMons– ElicittheunderlyingobjecMves,generalizeintomodelsofdesiredbehaviors.
– IdenMfyandresolveconflicts• Pluses:Concrete,supportnarraMvedescripMon• Minuses:inherentlyparMal.
47
48
Scenarios• QuesMonstoconsider
– Whattasksdoestheactorperform?– WhatinformaMonisaccessedandmodified,andwheredoesitcomefrom?
– WhatareobligaMonsontheactortoinformthesystem?– WhatareobligaMonsofthesystemtoinformtheactor?
• HeurisMcs– VerMcal–oneworked-outspecificscenario,tounderstandhowtoengagetheuser/stakeholder
– Horizontal–mulMple,less-detailedscenarios,toassessscopeandcontext
– Mock-ups– AlternaMves– Canbepassiveorac've.
Testcases
49
Wheredowefindscenarios?
• ReflecMve– Elicitscenariosfromstakeholders– Analyzereportsandcasestudiesofsimilarsystems
• ProspecMve–InstanMatetheusecase
Don’tonlyfocusontheposiMve–includefailures,too
50
Usecases• Wetalkaboutmanytypes,atdifferentgranulariMes:– Fullusecasemodel(whole-system,higher-level)– “Agile”usecase:small,concretepiecesofsystemfuncMonalitytobeimplemented(someMmesconflatedwith“userstories”)
• UsedatmulMplestages:– RequirementselicitaMon(illustrated,validate,requirements;highlightconflicts,prioriMzerequirements,etc).
– RequirementsdocumentaMon.– Concretedesign:UMLdiagrams.
51
Usecases
• Textstoriesofanactorusingasystemtomeetgoals.• Usecasesarenotdiagrams,theyaretext.• PrimarilyserveasfuncMonalrequirements(bycontrast/inconjuncMonwith“thesystemshall”statements.)
52
Learninggoals• ExplainwithexamplestheimportanceofrequirementsinsoHwareengineering.
• ExplainhowandwhyrequirementsarMculatetherelaMonshipbetweenadesiredsystemanditsenvironment.
• DisMnguishbetweenandgiveexamplesof:funcMonalandnon-funcMonalrequirements;informalstatementsandverifiablerequirements.
• IdenMfysystemstakeholdersanddevelopapproachesonhowtointerviewthem.
53
