Recall The Team SkillsTeam Skill 3: Defining the SystemChapter 14 A Use Case PrimerUse Case BasicsSlide 5ExampleThe Benefits of Use CasesThe Benefits of Use CasesThe Benefits of Use CasesUse Case ModelBuilding a uses case modelBuilding the Use-Case ModelStep 1: Identify and Describe the ActorsStep 2: Identify the Use Cases and Write a Brief DescriptionSlide 15Step 3: Identify the Actor and Use-Case RelationshipsStep 4: Outline the Individual Use CasesSlide 18Step 5: Refine the Use CasesUse Case templateUse Cases and User InterfacesSlide 22Use Cases and StoryboardingSlide 24Storyboard slide for step 1 of a use caseStoryboard slide for step 4 of a use caseReading AssignmentKey Points01/15/191Recall The Team Skills1. Analyzing the Problem (with 5 steps)2. Understanding User and Stakeholder Needs1. Interviews & questionnaires 2. Workshops3. Brainstorming and idea reduction4. Storyboarding3. Defining the System4. Managing Scope5. Refining the System Definition6. Building the Right System01/15/192Team Skill 3: Defining the SystemDefine the system by focusing more on the features and deal with the increased amount of information.Ch 14: A Use Case PrimerCh 15: Organizing Requirements InformationCh 16: The Vision DocumentCh 17: Product Management (skipped)01/15/193Chapter 14A Use Case Primer  Use cases basics Benefits of use cases  Steps of building use case model Use cases, storyboarding, and user interface design01/15/194Use Case Basics A use case describes a sequence of actions the system performs that yield an observable result of value to a particular actor.An actor is someone or something that interacts with the system.Users, other systems, or devicesDocumenting use cases by usinguse case templates: Name, decscriptions, Covered in the labs (UML Notes)01/15/195Use Case Basics Documenting use cases (Covered in the labs)by usinguse case templates: Name DescriptionActor(s)Flow of eventsPre-conditionsPost-conditions Etc ...UML Diagrams01/15/196Example01/15/197The Benefits of Use Cases They are relatively easy to write and easier to read.They force developers to think through the design of a system from the perspective of a user.They engage the users in the requirements process:helping them understand the system that is being proposed.giving them a way to communicate and document their needs.They give context for the requirements of the system: One can understand why a requirement is what it is as well as how the system meets its objectives.01/15/198The Benefits of Use CasesThey provide an ordering mechanism for requirements:one can tell what has to happen before the next thing happens, and so on.In most circumstances, developers write the use cases. That means not only that there actually are understood requirements but also that the developers know they are responsible for determining them.It is a critical tool in the analysis process, helping us understand what the system needs to do and how it might go about doing it.01/15/199The Benefits of Use Cases It is a critical tool in the design and implementation process, reducing the risk of transitioning from an expression of requirements to a differing implementation They carry over directly into the testing process, helping to assure that the system actually does what it was intended to do They serve as inputs to the user documentation, conveniently organized in a step-by-step format.01/15/1910Use Case ModelIndividual use case describes how a particular actor interacts with the system to achieve a result of value to the specific actor.The set of all use cases together describes the complete behavior of the system. The complete set of use cases, actors, and their interactions constitutes the use-case model for the system.01/15/1911Building a uses case modelwrite individual use cases and then add them all .. Not a good idea.Instead, build a context model of the system and successively refine it. That’s better for understanding, communicating, and refining the behavior of the system in an iterative development.01/15/1912Building the Use-Case ModelStep 1: Identify and Describe the ActorsStep 2: Identify the Use Cases and Write a Brief DescriptionStep 3: Identify the Actor and Use-Case RelationshipsStep 4: Outline the Individual Use Cases Step 5: Refine the Use Cases01/15/1913Step 1: Identify and Describe the ActorsWho uses the system?Who gets info from the system?Who provides info to the system?Where in the company is the system used?Who supports the and maintain the system?What other systems use this system?01/15/1914Step 2: Identify the Use Cases and Write a Brief DescriptionTypically, the use-case name is a few words or a short phrase that starts with an action verb and communicates what the actor achieves with the use case. To identify the use cases, ask the following for each actor:01/15/1915Step 2: Identify the Use Cases and Write a Brief DescriptionWhat will the actor use the system for?Will the actor create, store, change, remove, or read data in the system?Will the actor need to inform the system about external events or changes?Will the actor need to be informed about certain occurrences in the system?01/15/1916Step 3: Identify the Actor and Use-Case RelationshipsOnly one actor can initiate a use caseHowever, many actors can be involved in a use case.Each use case is analyzed to see what actors interact with it and Each actor’s behavior is reviewed to make sure that all of the results he needs to see are achieved the system.If this becomes complex, uses diagrams.01/15/1917Step 4: Outline the Individual Use CasesTo understand the system more think about the flow of events (basic and alternatives) for each use case.Basic flow: the most common path from start to finish through the systemAlternative flows: other possible paths based on regular or exceptional circumstances.01/15/1918Step 4: Outline the Individual Use CasesTo do that ask the following questions:Basic flow:What events start the use case?How does the use case end?How does the use case repeat some behavior?Alternative Flows:Are there optional situations in the use case?What odd cases might happen?What variants might happen?What may go wrong? ..etc01/15/1919Step 5: Refine the Use CasesWhen to refine and think