We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byMegan Grosvenor
Modified about 1 year ago
© 2010 Bennett, McRobb and Farmer1 Use Case Description Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4th Edition), McGraw Hill, 2010.
2© 2010 Bennett, McRobb and Farmer In This Presentation You Will Learn: What is a Use Case Description The difference between essential and real use cases How to describe Use Cases informally as a step-by-step sequence of actions How to apply Cockburn’s template for formal Use Case Descriptions
3© 2010 Bennett, McRobb and Farmer What is a Use Case Description? A Use Case Diagram gives an overall view: –Of a system’s functionality (use cases) –How functions relate to each other at run-time («extends» and «includes» relationships) –How user roles (actors) interact with functions Use Case Diagrams do not show: –Sequence or iteration of inputs and outputs while a use case executes –Alternative courses of action dependent on conditions –Pre-conditions for a use case to commence execution –Other meta-data about the use case
4© 2010 Bennett, McRobb and Farmer What is a Use Case Description? A Use Case Description addresses these limitations of the diagram There are several ways to document a Use Case Description, ranging from very informal to very formal Most organizations will have their own style and standard, often based on Cockburn’s (2001) template
5© 2010 Bennett, McRobb and Farmer Essential and Real Use Cases Some authors distinguish between essential and real use cases An essential use case is quite abstract, and makes no reference to design or technology aspects A real use case is implementation- oriented, referring to specific technologies (e.g. interface widgets, hardware devices, etc) For this presentation, we will focus mainly on essential use case descriptions
6© 2010 Bennett, McRobb and Farmer Informal Step by Step Descriptions It is often useful to describe a use case simply as a sequence of I/O: –User inputs something –System outputs something –User inputs something else –System outputs something else Very easy to confirm with users Also gives developers lots of clues about data, processing and screen content
7© 2010 Bennett, McRobb and Farmer Example #1: ‘Buy product’ Customer Buy product online (this example is adapted from Fowler, 2003)
8© 2010 Bennett, McRobb and Farmer Imagine the Scenario If you buy something from a website, you probably: –Browse through several products –Choose one –Go to the checkout –Fill in some information –Get confirmation of the sale
9© 2010 Bennett, McRobb and Farmer Main Scenario: ‘Buy product’ Informal description: Buy product online 1. Customer browses catalogue 2. System displays product details 3. Customer selects item to buy, goes to check-out 4. System displays shopping cart page 5. Customer fills in delivery information 6. System shows full pricing, including shipping 7. Customer fills in credit card details 8. System authorizes card, confirms sale on screen and sends to customer (Note that ‘Shopping cart’ and ‘ ’ are real aspects of this use case, while the rest of the description is essential)
10© 2010 Bennett, McRobb and Farmer Optional Steps Description also covers any alternative courses, and the triggers that initiate their execution: Alternative course: Card fails to authorize At step 8, system fails to authorize credit purchase. Return to step 7, allow customer to re-enter credit card information, retry authorization.
11© 2010 Bennett, McRobb and Farmer What the Description tells us: Even an informal description gives a lot of information that is useful to the developer: –Sequence and any iteration of steps – what order things should happen –I/O – fields, text boxes, buttons, etc needed on the screen –Data – what must be stored or retrieved –Process – calculations, other steps that will need coding –Alternatives – branch points in the sequence
12© 2010 Bennett, McRobb and Farmer Example #2: Training Administration System Admin clerk Book course place (this example is adapted from Skidmore and Eva, 2004)
13© 2010 Bennett, McRobb and Farmer Main scenario: ‘Book course place’ Book course place 1. Admin clerk retrieves scheduled course details 2. System displays number of places free 3. Admin clerk chooses ‘add delegate to a course’ 4. System requests delegate details 5. Admin clerk enters delegate details 6. System stores details and confirms
14© 2010 Bennett, McRobb and Farmer Alternate course: no free places 1. Admin clerk retrieves scheduled course details 2a. System displays ‘no places free’ 2a1. Admin clerk selects ‘search for dates with free places’ 2a2. Systems displays dates with free places 2a3. Admin clerk selects date (back to main course, step 4)
15© 2010 Bennett, McRobb and Farmer Alternate course: details missing 4. System requests delegate details 5a. Admin clerk enters details that are known 5a1. Systems displays ‘reservation is conditional on full details – OK?’ 5a2. Admin clerk clicks OK (back to main course, step 6)
16© 2010 Bennett, McRobb and Farmer Formal Descriptions: Cockburn’s Template The usual basis for formal use case descriptions, this is divided into five main sections: –Characteristic Information: a summary of the purpose and context of the use case –Description: Main Success Scenario, Extensions and ‘Technology and Data Variations List’ –(Optional) Related Information: non-functional aspects, links to other use cases, etc. –(Optional) Open Issues: unresolved issues still to be addressed –Schedule (for development)
17© 2010 Bennett, McRobb and Farmer Characteristic Information in detail Goal in Context: what is this use case for? Scope: the system (or systems) within which this use case applies Level: is this use case primary - called directly by the actor? Preconditions: what should be true for the use case to execute? Success End Condition: what should have changed after it has executed? Minimal Guarantee: what should minimally occur even if the use case fails to achieve its main goal Primary Actor: self explanatory Trigger: what event causes execution to begin?
18© 2010 Bennett, McRobb and Farmer Description in detail Main Success Scenario: the steps of the scenario from trigger to success, including any final closing down (e.g. interfaces or database connections) Extensions: alternate courses are described here, also any calls to other «includes» or «extends» use cases Technology and Data Variations List: describes alternative ways that the use case might be implemented, e.g. to allow for different UI devices (say, touch screen vs keyboard and mouse interface)
19© 2010 Bennett, McRobb and Farmer Related Information (optional) Priority: how important is this use case to the project? Performance Target: how quickly must the system respond to input or complete execution? Frequency: how often will it need to execute? Subordinate Use Cases: other use cases on which this one depends for its success Channel to primary actor: how will the actor communicate with the use case? Secondary Actors: other actors who can initiate and execute the use case Channel to Secondary Actors: as above
20© 2010 Bennett, McRobb and Farmer Open Issues and Schedule Any unresolved questions should be described in enough detail for another developer to work on them later If the development schedule for this use case has been decided, it should be documented
21© 2010 Bennett, McRobb and Farmer Summary In this presentation you have learned : What a Use Case Description is What is the difference between essential and real use cases How to describe Use Cases informally as a step-by-step sequence of actions How to apply Cockburn’s template for formal Use Case Descriptions
22© 2010 Bennett, McRobb and Farmer References Fowler (2003) Skidmore and Eva (2004) Cockburn (2001) (For full bibliographic details, see Bennett, McRobb and Farmer)
Requirements analysis and specification CSE432 Object-Oriented Software Engineering.
Testing the Workflows of a System Vasil Chimev Junior QA Engineer Centaur Team Centaur Team Telerik QA Academy Telerik QA Academy.
An Introduction to Object Modeling An Introduction to Object Modeling The approach of using object modeling during systems analysis and design is called.
Requirements Elicitation and Use Case Diagrams Prof. Hany Ammar, CSEE Dept., WVU.
Use Cases 1. Question 1 Each waiter is assigned a group of tables, after taking orders for a table the waiters enter the orders (a list of dishes and.
Chapter 6 Use Cases. What is a Use Case? A Use Case is a text story of some actor using a system to meet one or more goals (or not).
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
Microsoft ® Access ® 2010 Training Create queries for a new database.
Jump to Contents Instructor Tutorial essignments.com Paperless assignment submission system.
USE CASE MODELLING A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. An actor is a user playing a.
Chapter 11 Designing the User Interface Chapter 14 Systems Analysis and Design in a Changing World, 3 rd Edition.
Microsoft ® Office Outlook ® 2007 Training Get out of your Inbox Sweetwater ISD presents:
CPSC 333: Foundations of Software EngineeringJ. Denzinger 2.2. Use Cases: Scenario based requirements modeling Recommended: Booch, Rumbaugh, Jacobson:
Users Guide. You can create requisitions with multiple suppliers. There is automatic Purchase Order dispatch to multiple suppliers. It allows you to search.
Methods for Software Specification Jan Kožusznik. Dept. of Computer Science Technical University of Ostrava
Requirement [A&N 3-5]. Requirement Obviously, we need to somehow capture what are the requirements of the software to build. A&N categorize them to: –
Service Framework Reference Models Bill Olivier Director, CETIS.
Welcome to SuperFleet Manager Taking your fleet fueling to the next level.
Copyright © 2006 S trategies T oward A nnual R eductions System Training Guide for Suppliers Polaris Industries presents: Published: September 2006 Updated:
Day 2: Hands-on UML Using UML to put MITA to work to solve the immediate process improvement needs of states.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
.Net Software Architects UG Meeting Methodology for Use case development Arnon Rotem-Gal-Oz Product Line Architect
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java L6 (Adapted For ISE 2005/6 By Ananda Amatya, University.
תהליך הפיתוח האחוד (The Unified Process) 1. Motivation: Analysis and Design Should Be Done Iteratively! Presented 1981, this is one of the most famous.
March 2011 P00801: E-Business Information Systems 1 Lecture 6 E-Business Modelling with UML Prof. Hong Zhu Department of Computing and Electronics Module.
© 2010 Bennett, McRobb and Farmer1 Data Flow Diagrams Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
SCENARIO EXPLORER Introduction Basic Design Scenario Graphic Navigation Pane Content Area The Scenario Explorer provides you with comprehensive information.
MS Word BasicTraining. Section One: Word Basics Section Objectives Know how to open MS Word. Be able to identify the Toolbar. Know which Tabs on.
Welcome to informaworld TM. The following demo will show you just a few of the features on informaworld TM. Please select where you would like start. ePublication.
Chapter 7 – Design and Implementation 1Chapter 7 Design and implementation Note: These are a modified version of Ch 7 slides available from the authors.
© 2016 SlidePlayer.com Inc. All rights reserved.