Post on 09-Sep-2018
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
AnálisedeSistemasdeInformação(ASI)
AnoLecFvo2012/2013*1ºSemestre
MestradoemEngenhariaInformáFca
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
Aula6
1
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
Previously...
Contentadaptedfrom
SystemsAnalysisandDesignwithUML,4thEdiFonInternaFonalStudentVersion
AlanDennis,BarbaraHaleyWixomandDavidTegarden,
Wiley,2012
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
2
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
3
SystemsDevelopmentLifeCycle(SDLC)
Planning
Analysis
Design
ImplementaFon
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
4
SDLC:TheAnalysisPhase
QuesFonstobeAnsweredWhowilluseit?
Whatshouldthesystemdoforus?
Where&whenwillitbeused?
ThelineseparaFngAnalysisandDesignisblurry:deliverablesoftheanalysisphaseareactuallythefirststepofthedesignphase
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
5
SDLC:TheAnalysisPhase
ThesystemsdevelopmentprocesstransformstheexisFng(asis)systemintotheproposed(tobe)system
Oneoutputofplanningisasystemrequest,whichprovidesgeneralideasfortheto‐besystem,definesthe
projectscopeandprovidesaniniFalworkplan
Analysistakesthegeneralideasinthesystemrequestandrefinesthemintoadetailedrequirementsdefini6on,
funcFonalmodels,structuralmodelsandbehavioralmodelsthattogetherformthesystemproposal
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
TheAnalysisPhase:RequirementsDeterminaFon
Contentadaptedfrom
SystemsAnalysisandDesignwithUML,4thEdiFonInternaFonalStudentVersion
AlanDennis,BarbaraHaleyWixomandDavidTegarden,
Wiley,2012
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
6
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
7
RequirementsDeterminaFon
Turnhigh‐levelbusinessrequirementsintopreciserequirementsthatcanbeusedasinputstotherestofanalysis
ThesinglemostcriFcalstepoftheenFreSDLC
Changescanbemadeeasilyinthisstage
Most(>50%)systemfailuresareduetoproblemswithrequirements
TheiteraFveprocessofOOSADiseffecFvebecause:SmallbatchesofrequirementscanbeidenFfiedandimplementedincrementallyThesystemwillevolveoverFme
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
8
Theblindmenandtheelephant
Themostdifficultaspectofdeterminingtheactualrequirementsisanalogoustothestoryoftheblindmenandtheelephant
Moral:
Soo1enintheologicwars,
Thedisputants,Iween,
Railonu<erignorance
Ofwhateachothermean,
AnprateaboutanElephant
Notoneofthemhasseen!
‐JohnGodfreySaxe
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
9
RequirementsDeterminaFon
Purpose:toconverthighlevelbusinessrequirements(fromthesystemrequest)intodetailedrequirementsthatcanbeusedasinputsforcreaFngmodels
Whatisarequirement?AstatementofwhatthesystemmustdooracharacterisFcitmusthaveWilllaterevolveintoatechnicaldescripFonofhowthesystemwillbeimplemented
Types:FuncFonal:relatestoaprocessordataNon‐funcFonal:relatestoperformanceorusability
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
10
NonfuncFonalRequirements
Requirementtype Example
OperaFonal • Thesystemshouldbeabletofitinapocketorpurse• ThesystemshouldbeabletointegratewiththeexisFnginventorysystem.
Performance • AnyinteracFonbetweentheuserandthesystemshouldnotexceed2seconds.
• ThesystemshouldreceiveupdatedinventoryinformaFonevery15minutes.
Security • Onlydirectmanagerscanseepersonnelrecordsofstaff• Customerscanseetheirorderhistoryonlyduringbusinesshours.
Cultural&PoliFcal • ThesystemshouldbeabletodisFnguishbetweenUnitedStatesandEuropeancurrency
• Thesystemshallcomplywithinsuranceindustrystandards.
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
11
IgnoringNon‐funcFonalrequirementsIonceworkedonaconsulHngprojectinwhichmymanagercreatedarequirementsdefiniHonwithoutlisHngnon‐funcHonalrequirements.TheprojectwasthenesHmatedbasedontherequirementsdefiniHonandsold to the client for $5,000.Inmymanager’smind,thesystemthatwewouldbuildfortheclientwouldbeaverysimplestand‐alonesystemrunningoncurrenttechnology.It shouldn’t take more than a week to analyze, design, and build. Unfortunately,theclientshadotherideas.Theywantedthesystemtobeusedbymanypeopleinthreedifferentdepartments,andtheywantedtheabilityforanynumberofpeopletoworkonthesystemconcurrently.ThetechnologytheyhadinplacewasanHquated;nonetheless,theywantedthesystemtoruneffecHvelyontheexisHngequipment.Becausewedidn’tsettheprojectscopeproperlybyincludingourassumpHonsaboutnon‐funcHonalrequirementsintherequirementsdefiniHon,webasicallyhadtodowhatevertheywanted.ThecapabiliHtestheywantedtookweekstodesignandprogram. The project ended up taking four monthsandthe final project cost was $250,000.Ourcompanyhadtopickupthetabforeverythingexcepttheagreed‐upon$5,000.ThiswasbyfarthemostfrustaHngprojectsituaHonIeverexperienced.
‐BarbaraWixom
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
12
IdenFfyingRequirementsOneofthemostcommonmistakesbynewanalystsistoconfusefuncFonalandnon‐funcFonalrequirements.Pretendthatyoureceivethefollowinglistofrequirementsforasalessystem.Thesystemshould: 1.beaccessibletowebusers 2.includethecompanystandardlogoandcolorscheme 3.restrictaccesstoprofitabilityinformaFon 4.includeactualandbudgetedcostinformaFon 5.providemanagementreports 6.includesalesinformaFonthatisupdatedatleastdaily 7.havetwo‐secondmaximumresponseFmeforpredefinedqueries 8.includeinformaFonfromallcompanysubsidiaries 9.printsubsidiaryreportsintheprimarylanguageofthesubsidiary 10.providemonthlyrankingsofsalespersonperformance
A.WhichrequirementsarefuncFonal? B.Whichrequirementsarenon‐funcFonal,andofwhatkind?
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
13
RequirementsDefiniFonNon‐func6onal,Thesystem: Func6onal,Thesystemmust:
1.Opera6onalRequirements1.1willoperateinMSWindows1.2shouldconnecttoprinterswirelessly1.3shouldautomaFcallybackupattheend
ofeachday2.PerformanceRequirements2.1willstoreanewappointmentin2seconds2.2willretrievetheschedulesin2seconds3.SecurityRequirements3.1onlydoctorscansettheiravailability3.2onlyamanagercanproduceaschedule4.Culturalandpoli6calRequirements4.1NonehasbeenanFcipated
1.ManageAppointments1.1PaFentmakesnewappointment1.2PaFentchangesappointment1.3PaFentcancelsappointment2.ProduceSchedule2.1OfficeManagerchecksdaily
schedule2.2OfficeManagerprintsdailyschedule3.RecordDoctoravailability3.1Doctorupdatesschedule
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
14
RequirementsDefiniFon
FuncFonal&non‐funcFonalrequirementslistedinoutlineformat
MaybeprioriFzed
ProvidesinformaFonneededinsubsequentworkflows
Definesthescopeofthesystem
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
15
DeterminingRequirements
Requirementsarebestdeterminedbysystemsanalystsandbusinesspeopletogether
StrategiesforanalyzingtherequirementsBusinessProcessAnalysis(BPA)BusinessProcessImprovement(BPI)BusinessProcessReengineering(BPR)
TechniquesforidenFfyingrequirementsInterviews,quesFonnairesand/orobservaFonJointapplicaFondevelopment(JAD)Documentanalysis
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
16
CreaFngaRequirementsDefiniFon
DeterminethetypesoffuncFonalandnon‐funcFonalrequirementsapplicabletotheproject
Userequirements‐gatheringtechniquestocollectdetailsAnalystsworkwithuserstoverify,changeandprioriFzeeachrequirement
ConFnuethisprocessthroughanalysisworkflow,butbecarefulofscopecreep
Requirementsthatmeetaneedbutarenotwithinthecurrentscopecanbeaddedtoalistoffutureenhancements
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
17
ProblemsinRequirementsDeterminaFon
Analystmaynothaveaccesstothecorrectusers
RequirementsspecificaFonsmaybeinadequate
Somerequirementsmaynotbeknowninthebeginning
VerifyingandvalidaFngrequirementscanbedifficult
JoãoPauloFernandes,jpf@di.ubi.ptNunoM.Garcia,ngarcia@di.ubi.pt
Summary
UNIVERSIDADEDABEIRAINTERIORFaculdadedeEngenhariaDepartamentodeInformáFca JoãoPauloFernandes,jpf@di.ubi.pt
18
SDLC,Theanalysisphase:
‐RequirementsDeterminaFon:
• definingarequirement
• requirementsdefiniFon
• determiningrequirements
• creaFngarequirementsdefiniFon
• real‐worldproblemswithrequirementsdeterminaFon