Transcription
Use Cases- A use case characterizesht ia way off usingi a systemt- It represents a dialog between a user and thesystem,tfromftheth user’s’ pointi t off viewi- It captures functional requirementsCSE 403, Spring 2008, Alverson
Benefits of doingg use casesyEstablish an understanding betweenthe customer and the systemdevelopers of the requirements(success scenarios)yAlert developers of problematicsituationsit ti((extensionti scenarios)i )yCapture a level of functionality to planaround (list of goals)CSE 403, Spring 2008, Alverson
TerminologygyActor: someone who interacts with the systemPrimary actor: person who initiates the actionGoal: desired outcome of the primary actorLevel:ooosummary goalsuser goalssubfunctionsCSE 403, Spring 2008, Alverson
Do use cases capturepthese?yWhich of these requirements should berepresentedpdirectlyy in a use case?1.2.3.44.5.66.7.Order cost order item costs * 1.06 tax.Promotions may not run longer than 6 months.Customers only become Preferred after 1 yearA customer has one and only one sales contactResponse time is less than 2 secondsUptime requirement is 99.8%Number of simultaneous users will be 200 maxCSE 403, Spring 2008, Alverson
Stylesyof use casesUse case diagram (UML/Visio/Violet)1.o2.3.shows all use cases in systemInformal use caseFormal use caseLet's examine each of these in detail.CSE 403, Spring 2008, Alverson
1. Use case summaryy diagramsgThe overall list of your system's use cases can bedrawn as high-levelhigh level diagramsdiagrams, with:ooooactors as stick-men, with their names (nouns)use cases as ellipses with their names (verbs)line associations, connecting an actor to a use case inwhich that actor participatesuse cases can be connected to other cases that theyuse / rely onCheck out bookCSE 403, Spring 2008, AlversonLibrary patron
Use case summaryy diagramsgIt can be useful to create a list or table of primaryactors and their "goals" (use cases they start).The diagram will then capture this material.ActorLibrary PatronGoalSearch for a bookCheck out a bookReturn a bookLibrarianSearch for a bookCheck availabilityCSE 403, Spring 2008, AlversonRequest a book fromanother library
Use case summaryy diagramg1Library SystemCheck outSearchLibrarianRReserveLibrary PatronRecord newGen catalogCSE 403, Spring 2008, Alverson
Use case summaryy diagramg2CSE 403, Spring 2008, AlversonInvestmentSystem
UML/VisioyQuick demoCSE 403, Spring 2008, Alverson
2. Informal use caseInformal use case is written as a paragraphdescribing the scenario/interactionyEExample:loPatron Loses a BookThe library patron reports to the librarian that she haslost a book. The librarian prints out the library recordand asks patron to speak with the head librarian, whowill arrange for the patron to pay a feefee. The system willbe updated to reflect lost book, and patron's record isupdated as well. The head librarian may authorizepurchase of a replacement tape.CSE 403, Spring 2008, Alverson
3. Formal use caseGoalPatron wishes to reserve a book using the onlinecatalogPrimaryactorPatronScopeLibrary systemLevelUserPPreconditionditiP tPatroniis att theth loginl i screenSuccess end Book is reservedconditionFailure endconditionBook is not reservedTriggerPatron logs into systemCSE 403, Spring 2008, Alverson
Main SuccessScenarioScea o1.22.3.4.5.6.7.Extensions(errorscenarios)Patron enters account and passwordSystem verifies and logs patron inSystem presents catalog with search screenPatron enters book titleSSystemfifindsd matchh andd presents locationlichoices to patronPatron selects location and reserves bookSystem confirms reservation and re-presentscatalog2a. Password is incorrect2a.1 System returns patron to login screen2a.2 Patron backs out or tries again5a System cannot find book5a.5a.1 Variations4. Patron enters author or subject(alternativescenarios)CSE 403, Spring 2008, Alverson
Stepsp in creatingg a use case1 Identify actors and their goals1.What computers, subsystems and people will drive oursystem? (actors)What does each actor need our system to do? (goals)CSE 403, Spring 2008, Alverson
Identifyde t y actors/goalsacto s/goa s exercisee e c seyLet’s identify some major actors and their goalsfor your projectsooooooU-MailNotepadViVisuallRRegistrationi t tiOfCourseFacebookForeseeCSE 403, Spring 2008, Alverson
2. Write the success scenarioyMain success scenario is the preferred "happyhappypath”o easiest to read and understando everythingthi elsel iis a complicationli ti on thithisyCapture each actor'sactor s intent and responsibilityresponsibility,from trigger to goal deliveryo say what information passes between themo number each lineCSE 403, Spring 2008, Alverson
3. List the failure extensionsyUsually, almost every step can failyNote the failure condition separately, after themain success scenarioyLabel with step number and letter:oy5a failure condition 5a.1 use case continued with failure scenario 5a.2 continuedExercise: What happens if a student looks up a course inOfCourse, and it doesn’t exist?CSE 403, Spring 2008, Alverson
4. List the variationsyyMany steps can have alternative behaviors orscenariosLabel with stepp number and alternativeo5’. Alternative 1 for step 5o5’’. Alternative 2 for step 5Exercise: What are some variations that arise inarranging a carpool with Foresee?CSE 403, Spring 2008, Alverson
Qualities of a goodQguse caseyyA good use case:o starts with a request from an actor to the systemo ends with the production of all the answers to the requesto defines the interactions (between system and actors)related to the functiono takes into account the actor's point of view, not thesystem'st 'o focuses on interaction, not internal system activitieso doesndoesn'tt describe the GUI in detailo has 3-9 steps in the main success scenarioo is easy to readA good use case summary fits on a pageCSE 403, Spring 2008, Alverson
Exercise: Projectjuse caseyyyEach project team break into 2 groupsEach group write a use case for your productChoose one per project team to share with theclassYYourSRS ddoc can use ththese use cases!!CSE 403, Spring 2008, Alverson
CSE 403, Spring 2008, Alverson
Pullingg it all togethergHo muchHowm ch is enough?eno gh?You haveYhtto findfi d a bbalancel comprehensible vs. detailed correctness graphicshi vs. explicitli it wordingdi andd tablest bl short and timely vs. complete and lateYour balance may differ with each customerddependingdi on your relationshipl tihi andd flflexibilityibilitCSE 403, Spring 2008, Alverson
Words of Wisdom 5After you create a specification, go over it to:ooooEliminate all requirements not absolutely necessarySimplify those that are more complicated thannecessarySubstitute cheaper options when availableMove non essentials to future releasesCSE 403, Spring 2008, Alverson
Words of Wisdom 5’Agileg Principlep – Simplicityp y is EssentialCSE 403, Spring 2008, Alverson
yCapture a level of functionality to planCapture a level of functionality to plan around (list of goals) CSE 403, Spring 2008, Alverson. Terminology Actor: someone who interacts with the system . UML/Visio yQuick
