Understanding Use Case Model and Specifications
Use case modeling involves creating detailed descriptions to capture system requirements and interactions with actors. This includes defining actors, use cases, requirements, and specifications at different levels of detail. The description complements use case diagrams, illustrating the breakdown and logic of individual use cases. Three levels of use case descriptions offer varying degrees of detail, from brief summaries to full scenarios. Understanding the basics of use cases, such as naming conventions, descriptions, actors, and event flows, is essential for effective system design.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Use Case Model Use case description
RelevantRequirementsArtifacts Use-Case Model Glossary Actors Use Cases ... Supplementary Specification Use-Case Specifications 3
Use Case Description Complements Use Case Diagram A breakdown of a single use case (e.g., sequence of steps included in the function Look up item availability ); process logic included In contrast to Use Case Diagram, Use Case Description captures variations of a Use Case Example: Create new order can be done via phone+clerk and via Internet ordering 2 scenarios 4
Level of Use Case Description Three levels of details: UC* Brief description Summary of what system does in response to actor s actions UC Intermediate description Shows steps in use case, if-then UC Full description Includes Brief description, expands intermediate description, shows scenarios * UC=Use Case 5
Brief Description of Use Case Same description that is usually captured in initial Use Case Diagrams 6
Intermediate Use Case Description Telephone Order Scenario for Create New Order Use Case 7
Full Use Case Description Shows steps ( Flow of Events ) broken down to the actor and the system side useful! 8
Use Cases Basics A use case has four mandatory elements: 1.Name: Each use case has a unique name describing what is achieved by the interaction with the actor. EX: "Turn Light On/Off" and "Print Document" are good examples. 2.Brief description: The purpose of the use case should be described in one or two sentences. EX: "This use case controls the selected light bank when instructed by the actor Homeowner. 3.Actor(s) List each actor that participates in the use case. 4.Flow of events: The heart of the use case is the event flow, usually a textual description of the interactions between the actor and the system. The main (basic) flow of events The alternate flows of events 9
Use Cases Basics Optional elements in a Use case: Pre-conditions: Must be present in order for a use case to start. Represent some system state that must be present before the use case can be used. EX: A pre-condition of the "Print Author's Manuscript Draft" use case is that a document must be open. Post-conditions: Describe the state of the system after a use case has run. Represent persistent data that is saved by the system as a result of executing the use case. EX: Post-condition of Register" use case is that the new data is added in the profile of the student. 10
Use Cases Basics Other stakeholders: Other key stakeholders who may be affected by the use case. EX: A manager may use a report built by the system, and may not personally interact with the appear as an actor on the system. yet the manager system in any way and therefore would not 11
A Recommended Template: Use Case Description System: Use Case name: Primary actor: Other actors: Stakeholders: Description: Relationships Includes: Extends: Input: Pre-conditions: Steps: Actor System 2. System does. 1. Actor does. 3. 4. Alternative and exceptional flows: 4.1 . Post-conditions: 12
Full Use Case Description Telephone Order Scenario for Create New Order Use Case 13
Full Use Case Description Telephone Order Scenario for Create New Order Use Case 14
Full Use Case Description Telephone Order Scenario for Create New Order Use Case 15
Use-Cases Common Mistakes Complex diagram No system No actor Too many user interface details User types ID and password, clicks OK or hits Enter Very low goal details User provides name User provides address User provides telephone number 16
Writing Use Case Descriptions 1. Select a use case 2. Write abbreviated full description (Use case name, Scenario (if any), Business Event, Actors, Flow of steps, Exception conditions) 3. For figuring Flow of steps, - Keep in mind general system model: Input-Processing-Output - Steps should be at nearly the same level of abstraction (each makes nearly same progress toward use case completion) 4. For figuring exception conditions, focus on if-then logic. 17
Combining Processes Number Limit: The diagram should have between 3 to 10 base use-case. No more than 15 use cases (base + included + extending). Abstraction: All use-cases should be in similar abstraction levels. Size: Use cases should be described in half a page or more. Interaction: Use-cases which are carried out as part of the same interaction. 18
More Guidelines Factor out common usages that are required by multiple use cases If the usage is required use <<include>> If the base use case is complete and the usage may be optional, consider use <<extend>> A use case diagram should: contain only use cases at the same level of abstraction include only actors who are required 19
Glossary Course Registration System Glossary Introduction 1. This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. 2. Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. Course: A class offered by the university. 1. Course Offering: A specific delivery of the course for a specific 2. semester you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered. Glossary Course Catalog: The unabridged catalog of all courses offered by 2.3 the university. 20
