Chapters 5‐6‐7 - Emory University Biology Department · Hill, 2009). Slides copyright 2009 by...

Chapters5‐6‐7

RequirementsEngineeringHighlights

1CS‐584/Fall2009/EmoryU

Chapter05:QualityFuncGonDeployment

•  FuncGondeploymentdeterminesthe“value”(asperceivedbythecustomer)ofeachfuncGonrequiredofthesystem

•  InformaGondeploymentidenGfiesdataobjectsandevents•  Taskdeploymentexaminesthebehaviorofthesystem

•  ValueanalysisdeterminestherelaGvepriorityofrequirements

CS‐584/Fall2009/EmoryU 2

3

PlanningPrinciples(fromChapter04)

•  Principle #1. Understand the scope of the project. It’s impossible to use a roadmap if you don’t know where you’re going. Scope provides the software team with a destination.

•  Principle #2. Involve the customer in the planning activity. The customer defines priorities and establishes project constraints.

•  Principle #3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it very likely that things will change.

•  Principle #4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done.

TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009)Slidescopyright2009byRogerPressman.

TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009)Slidescopyright2009byRogerPressman. 4

PlanningPrinciples(fromChapter04)

•  Principle #5. Consider risk as you define the plan. If you have identified risks that have high impact and high probability, contingency planning is necessary.

•  Principle #6. Be realistic. People don’t work 100 percent of every day. •  Principle #7. Adjust granularity as you define the plan. Granularity

refers to the level of detail that is introduced as a project plan is developed.

•  Principle #8. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality.

•  Principle #9. Describe how you intend to accommodate change. Even the best planning can be obviated by uncontrolled change.

•  Principle #10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time.

RequirementsvsExpectaGons

•  Customers“expect”theproducttodocertainthings–  SomeareclearlystatedexpectaGons–  Othersareassumedbutnotstated–  FiguringouttheassumpGonsiswheretherealchallengelies

•  ExpectaGonsleadtorequirementsspecificaGon–  Inputs+acGononinputsoutputs–  Eachhasconsequencesfordesign&implementaGon–  Somerequirementsmayneedtobere‐thought,re‐defined,orpostponed

•  Thisfirst“negoGaGon”withthecustomermustbemanagedwithaneyetowardrealisGcproducGon–  Gettherequirements–  UnderstandtheimplicaGons–  Assessfeasibility–  Thenreturnwithaproposal(releaseplan)–  Validateplan


TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.

6

Chapter05:UML&Use‐Cases

•  UML(UnifiedModelingLanguage)usedtomodelmanykindsofsystems•  BasedonconceptofuserinteracGngwithsystem–hardwareandsofware•  UseCase:AcollecGonofuserscenariosthatdescribethethreadofusageofasystem•  Eachscenarioisdescribedfromthepoint‐of‐viewofan“actor”—apersonordevicethat

interactswiththesofwareinsomeway•  EachscenarioanswersthefollowingquesGons:

–  Whoistheprimaryactor,thesecondaryactor(s)?–  Whataretheactor’sgoals?–  WhatprecondiGonsshouldexistbeforethestorybegins?–  WhatmaintasksorfuncGonsareperformedbytheactor?–  Whatextensionsmightbeconsideredasthestoryisdescribed?–  WhatvariaGonsintheactor’sinteracGonarepossible?–  WhatsysteminformaGonwilltheactoracquire,produce,orchange?–  Willtheactorhavetoinformthesystemaboutchangesintheexternalenvironment?–  WhatinformaGondoestheactordesirefromthesystem?–  Doestheactorwishtobeinformedaboutunexpectedchanges?

7

Chapter05:UMLUse‐CaseDiagram

homeowner

Arms/disarmssystem

Accesses systemvia Internet

Reconfigures sensorsand related

system features

Responds toalarm event

Encounters anerror condition

systemadministrator

sensors


8

Chapter05:UMLClassDiagram

Sensor

name/idtypelocationareacharacteristics

identify()enable()disable()reconfigure()

From the SafeHome system …


9

Chapter05:UMLStateDiagramReading

Commands

Systemstatus=“ready”Displaymsg=“entercmd”Displaystatus=steady

Entry/subsystemsreadyDo:polluserinputpanelDo:readuserinputDo:interpretuserinput

Statename

Statevariables

StateacGviGes


Chapter06:ModelingtheRequirements

•  Scenario‐basedmodels

•  Datamodels•  Class‐orientedmodels

•  Flow‐orientedmodels•  Behavioralmodels


DFD:DataFlowDiagram

Chapter06:UMLAcGvity&SwimlaneDiagrams

SwimlaneDiagram


enter passwordand user ID

select major function

valid passwords/ID

prompt for reentry

invalid passwords/ID

input tries remain

no inputtries remain

select surveillance

other functionsmay also be

selected

thumbnail views select a specific camera

select camera icon

prompt foranother view

select specificcamera - thumbnails

exit this function see another camera

view camera outputin labelled window

enter passwordand user ID

select major function

valid passwords/ID

prompt for reentry

invalidpasswords/ID

input triesremain

no inputtries remain

select surveillance

other functionsmay also be

selected

thumbnail views select a specific camera

select camera icon

generate videooutput

select specificcamera - thumbnails

exit thisfunction

seeanothercamera

h om e own e r c a m e ra i n t e rf a c e

prompt foranother view

view camera outputin labelled window

AcGvityDiagram

12

Chapter06:DataModeling

•  examinesdataobjectsindependentlyofprocessing

•  focusesalenGononthedatadomain•  createsamodelatthecustomer’slevelofabstracGon

•  indicateshowdataobjectsrelatetooneanother

13

Chapter06:WhatisaDataObject?

•  a representation of almost any composite information that must be understood by software. –  composite information—something that has a number of different

properties or attributes •  can be an external entity (e.g., anything that produces or

consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file).

•  The description of the data object incorporates the data object and all of its attributes.

•  A data object encapsulates data only—there is no reference within a data object to operations that act on the data.

14

Chapter06:DataObjectsandAlributes

object:automobilea.ributes:makemodelbodytypepriceop5onscode

15

Chapter06:WhatisaRelaGonship?

•  Data objects are connected to one another in different ways. –  A connection is established between person and car because

the two objects are related. •  A person owns a car •  A person is insured to drive a car

•  The relationships owns and insured to drive define the relevant connections between person and car.

•  Several instances of a relationship can exist •  Objects can be related in many different ways

16

Chapter06:ERDNotaGon(EnGty‐RelaGonshipDiagram)

(0,m) (1,1)


17

Chapter06:BuildinganERD

•  Level1—modelalldataobjects(enGGes)andtheir“connecGons”tooneanother

•  Level2—modelallenGGesandrelaGonships•  Level3—modelallenGGes,relaGonships,andthe

alributesthatprovidefurtherdepth


18

Chapter06:AnERDExample

(1,1) (1,m)placesCustomer

requestforservice

generates(1,n)

(1,1)

workorder

worktasks

materials

consistsof

lists

(1,1)(1,w)

(1,1)

(1,i)

selectedfrom

standardtasktable

(1,w)

(1,1)


19

Chapter06:Class‐BasedModeling

•  Class-based modeling represents: –  objects that the system will manipulate –  operations (also called methods or services) that will be applied

to the objects to effect the manipulation –  relationships (some hierarchical) between the objects –  collaborations that occur between the classes that are defined.

•  The elements of a class-based model include classes and objects, attributes, operations, CRC models, collaboration diagrams and packages.


Chapter06:Class‐Responsibility‐CollaboratorModeling(CRC)

•  Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way:

–  A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.


Class:Description:

Responsibility: Collaborator:

Class:Description:


Class:Description:


Class: FloorPlanDescription:


incorporates walls, doors and windowsshows position of video cameras

defines floor plan name/typemanages floor plan positioningscales floor plan for displayscales floor plan for display

WallCamera


OtherclassescollaboraGng

Chapter07:ModelingStrategies


22

Chapter07:FlowModelingNotaGon


Chapter07:DataFlowDiagramExample

CS‐584/Fall2009/EmoryU 23TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.

Chapter07:RequirementsModelingforWebApps

ContentAnalysis.ThefullspectrumofcontenttobeprovidedbytheWebAppisidenGfied,includingtext,graphicsandimages,video,andaudiodata.DatamodelingcanbeusedtoidenGfyanddescribeeachofthedataobjects.

InteracGonAnalysis.ThemannerinwhichtheuserinteractswiththeWebAppisdescribedindetail.Use‐casescanbedevelopedtoprovidedetaileddescripGonsofthisinteracGon.

FuncGonalAnalysis.Theusagescenarios(use‐cases)createdaspartofinteracGonanalysisdefinetheoperaGonsthatwillbeappliedtoWebAppcontentandimplyotherprocessingfuncGons.AlloperaGonsandfuncGonsaredescribedindetail.

ConfiguraGonAnalysis.TheenvironmentandinfrastructureinwhichtheWebAppresidesaredescribedindetail.

CS‐584/Fall2009/EmoryU 24TheseslidesaredesignedtoaccompanySo#wareEngineering:APrac11oner’sApproach,7/e(McGraw‐Hill,2009).Slidescopyright2009byRogerPressman.

25

TheConfiguraGonModel

•  Server‐side–  ServerhardwareandoperaGngsystemenvironmentmustbespecified

–  InteroperabilityconsideraGonsontheserver‐sidemustbeconsidered–  Appropriateinterfaces,communicaGonprotocolsandrelated

collaboraGveinformaGonmustbespecified

•  Client‐side–  BrowserconfiguraGonissuesmustbeidenGfied

–  TesGngrequirementsshouldbedefined


26

NavigaGonModeling‐I

•  Shouldcertainelementsbeeasiertoreach(requirefewernavigaGonsteps)thanothers?WhatisthepriorityforpresentaGon?

•  ShouldcertainelementsbeemphasizedtoforceuserstonavigateintheirdirecGon?

•  HowshouldnavigaGonerrorsbehandled?•  ShouldnavigaGontorelatedgroupsofelementsbegivenpriorityover

navigaGontoaspecificelement.•  ShouldnavigaGonbeaccomplishedvialinks,viasearch‐basedaccess,orby

someothermeans?•  Shouldcertainelementsbepresentedtousersbasedonthecontextof

previousnavigaGonacGons?•  ShouldanavigaGonlogbemaintainedforusers?


27

NavigaGonModeling‐II

•  ShouldafullnavigaGonmapormenu(asopposedtoasingle“back”linkordirectedpointer)beavailableateverypointinauser’sinteracGon?

•  ShouldnavigaGondesignbedrivenbythemostcommonlyexpecteduserbehaviorsorbytheperceivedimportanceofthedefinedWebAppelements?

•  Canauser“store”hispreviousnavigaGonthroughtheWebApptoexpeditefutureusage?

•  ForwhichusercategoryshouldopGmalnavigaGonbedesigned?

•  HowshouldlinksexternaltotheWebAppbehandled?overlayingtheexisGngbrowserwindow?asanewbrowserwindow?asaseparateframe?


Fact/FallacyTidbit

•  Fact26Thelistof“derivedrequirements”canbe50xlongerthanthelistoforiginalrequirements

•  Discussion–  Requirementsinformthedesign;thedesigninformsthesoluGon;thesoluGoncreates

newrequirements–  Complexitymayincreaseaswell–  Requirementstraceabilityisaffected

•  Traceabilityinvolvesmappingacustomerrequirementtoeachpartofthedesign/code/test/documentaGon

•  SomeGmesusedforcodeanalysis–idenGfyingdanglingcode,forexample(i.e.,codethatnolongermeetsarequirement)

•  Design“consequences”(implicitrequirements)aren’tGeddirectlytoanoriginalcustomerrequirement,somappingisunclearatbest

•  EachphaseoftheprojectandaddiGonoffurtherimplicitrequirementsaddstothetraceabilityproblem;nojustasimplelinked‐listproblembutlinked‐listsoflinked‐lists–extremelycomplex

FromRobertGlass,“Facts&FallaciesofSofwareEngineering”


Chapters 5‐6‐7 - Emory University Biology Department · Hill, 2009). Slides copyright 2009 by...

Documents

Transcript of Chapters 5‐6‐7 - Emory University Biology Department · Hill, 2009). Slides copyright 2009 by...