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