use cases for requirementsualr.edu/jdberleant/courses/ifsc7310/usecasemodeling1.pdf · use cases...
TRANSCRIPT
Use Cases for Requirements
� Today’s material: Arlow and Neustadtch. 4 and 5 Larman: part of chapter 6
� What are requirements?
Use Cases for Requirements
� Today’s material: Arlow and Neustadt ch. 4 Larman: part of chapter 6
� What are requirements? � Requirements (or specifications, or requirements specifications)
� “…are capabilities…to which the system…must conform”� – Larman p. 41 (2nd), p. 54 (3rd)
� “Requirements” also names a UP discipline� See Fig. next (or L. sect. 2.4 in 2nd ed., and 2.7 in 3rd ed.)
� …it is done throughout the project� Unlike in non-iterative life cycle models
� (e.g. waterfall model, fountain model)
Disciplines in the RUP
Modified from: http://dn.codegear.com/article/images/33319/RUP.JPG
Domain diagrams
Use cases
Sequence & Design class diagrams
Use Cases - Background
� A use case is a “case of use”� …that is, (generalized) example of usage
� Precise translation from the Swedish is “usage case”
� Invented by Ivar Jacobson in 1986
� Major advance in the book:
Writing Effective Use Cases,
Alistair Cockburn (“Coburn”), 2000
What is a Use Case?
� A use case is a story about using the system
� A use case is a set of related system use scenarios
� A use case is a set of related system use instances
� As a way to communicate among humans…
� Stories are
flexible and human-friendly
Use Cases for System Needs
� Because use cases are human friendly…� …they are a good way to capture needs
� They are stories about how a system can
meet needs
� Example for POS system (what’s another?)� Customer brings items to checkout counter. Cashier records each item. System displays each item & price, and current total. Customer provides
payment somehow. System validates it, logs it, and updates inventory data. System prints receipt and customer waves a cheery goodbye.
� the “somehow” can be expanded into multiple scenarios� E.g. L. p. 46 2nd ed., p. 63 3rd ed.
Stories Can Have Titles…
� The title of that use case could be
� “Process a customer with items to buy”
� Consider a course registration system
� A title of a use case might be
� “Process a student with courses to sign up for”
� Consider a project planning, or general UML editor system, or _______ system
� Write down a title for one use case…
� (We’ll have more to say about these in the future)
Use Case – What Is It?
� Set of related scenarios� (i.e. set of related use case instances)…� …in which actor(s) use the system…� …to meet some need
� Actor: something that behaves in some way� E.g. a cashier, a computer(?), a retail store, a customer…
� Not the system itself though
� What actors exist in a _____ or UML editing system?
� Need: a goal that the system can support � Buying things� Returning things� Determining what to order to restock inventory
Use Cases are Appropriately General
� Too specific: Joe Schmoe goes to the grocery store at 11:00 a.m. on Thursday to buy stuff for breakfast. In his basket he puts beer, chips, and the book “All About Healthy Breakfasts.” Then he…
� A use case instance (specific but not too specific): � one path through a use case.
� Example: someone goes to the store, puts items into a cart, proceeds to the cash only express line…
� Another example: . . .
� (scenario: same as a use case instance)
� A use case: set of “related…scenarios”
� Use case title: Handle Returns
� There is a main use case instance (scenario)
� Main success scenario
� Customer has items to return, cashier scans in each, gets total, gives refund
� Credit card expired use case instance
� Customer paid with credit card, but now can’t refund to the credit card account, so give cash
� Bar code missing scenario
� …
The Use Case as a
Set of Use Case Instances/Scenarios
Use Case Instances in the Use Case
� Write down a use case instance (scenario) for a project planning system use case, UML editor use case, or ____ use case
� …then…we’ll put a few on the board…
A Couple of Scenarios…
� Make new SSD or use case diagram
� E.g. Create, drag, drop a stick figure
� (User, mouse, computer have behaviors)
� Load and modify previously created diagram
� Use file browser to search the right .uml file, click to bring it up, ….
� (Monitor, file system have behaviors)
Recall ‘Actor’: something that behaves in some way
� What is the actor for each of these?
� Make SSD or use case diagram
� Create, drag, drop a stick figure
� User, mouse, computer
� Load and modify previously created diagram
� Use file browser to search for diagram in a .uml file, click to bring it up, ….
� Monitor, file system
� How about some other examples?
Use Cases – One Requirements Tool
� In the FURPS+ model, use cases…
� …are primarily oriented toward one letter
� Which letter? (See next slide to figure out)
FURPS+ Model for Requirements
� F is for Functionality� Things it does: features, etc.
� U is for Usability� Things that help people use it: help, documentation, ergonomics
� R is for Reliability� MTBF, availability, fail softness, etc.
� P is for Performance� Speed, resource consumption, accuracy, response delay, etc.
� S is for Supportability� Maintenance friendly, configuration support, international issues
� + is for other stuff� Like what?
Functionality: features vs. valuable features
� “…the software industry is littered with failed projects that did not deliver what people really needed” – Larman p. 48 (2nd ed.)� “Lack of user involvement …is near the top of the list of reasons for project failure” – p. 65 (3rd ed.)
� Requirements (hence, use cases) should� …focus on reaching goals and adding value� (…not on laundry lists of features)
� Otherwise, the system could end up with:� features that don’t add much value; and� important goals that aren’t actually met
Types of Use Cases I
� What-based (“black box”) use cases� Describe what system does� Do not describe how system does it� Example of a step:
� “system records the sale”
� How-based (“glass box”) use cases� Describe mechanism – how the system does it� Example of a step:
� “system records sale to database”
� Example 2: � “system issues SQL INSERT command”
� Which is better?
Types of Use Cases II:Essential Vs. Concrete Style
� Essential: “user is authenticated”
� Concrete: “user types name and password”
� Which captures intent?
� Which impacts UI?
� Which is good to do first?
� Which is good to do later?
Use Cases:Concrete Vs. Essential
versusWhat-Based Vs. How-Based
� Which pairs of terms are more-or-less synonymous?
Types of Use Cases III
� Brief – 1 paragraph of main use case instance� Casual – Multiple paragraphs
� each is a different use case instance (scenario)
� Fully dressed – Full details � …of each step� …of each variation� …with preconditions and postconditions
� (what are those?)� What is a precondition/postcondition for the UML editor?
� See: Arlow and Neustadt Figs. 4.9-4.11, 4.13-4.15, 5,5-5.6, 5.8-5.9, 5.11-5.13, etc.; Larman table on pp. 50-53 (2nd ed.), 68-72 (3rd ed.)
� A&N examples are short; reality can be over 1 or 2 pages
� Which might one write first? Second? Third?
Example of Use Case –brief format
� Customer brings items to checkout counter. Cashier records each item. System displays each item & price, and current total. Customer provides payment somehow. System validates it, logs it, and updates inventory data. System prints receipt and customer waves a cheery goodbye. (e.g. L. p. 46 (2nd), 63 (3rd))
� This “brief format” use case actually contains several use case instances…
Casual Format for Use Cases
� Like brief format, except:
� Multiple paragraphs instead of one
� Each paragraph covers a different scenario
� One paragraph is the main success scenario
� Other alternatives are in other paragraphs
Fully Dressed Use Case
http://api.ning.com/files/iaBxrA602vVRg-cJuQTS1k*p088*NcQhp87iZ6VY1VFILwHPGN*9ub*xBTW2VLoGSMcsTjf82l9-4E9JIaPA3MPR7rEEeG*h/dog.jpg
� Has multiple scenarios
� (Like casual format)
� Has numbered steps
� (Formal, not casual)
� Has extra sections
� Is fully detailed
Examples
See several figures in Arlow and Neustadt
- Note: you can have alternate subsections
- Step 6, alternate step 6a, and 6b
- Steps can have substeps
In Larman see Fig. p. 50 ff., 2nd ed.; p. 68 ff., 3rd ed.
Types of Use Cases IV:1-Column Vs. 2-Column
� Used for “fully dressed” use cases
� 2-Column (see e.g. L. p. 53, 2nd; p. 79, 3rd):� Left column is for things outside actors do
� Right column is for things the system does
� Makes the interaction with the system clear
� 1-Column:� More compact
� Various other format options exist
More Parts of the Use Case
� Main Success Scenario� “Happy path” typically with no branches
� It’s what you hope will happen
� Extension (to alternative paths)� All the (“not-so-happy”) branches off the main success scenario
� Can be several of them� steps numerically keyed to Basic Flow
� (5a instead of 5, etc.)
� longer than Basic Flow
The Fully Dressed Use Case
� Primary actor – the main system user
� Stakeholders and their interests –
� A use case should describe all behaviors needed to serve the stakeholder(s)
� …that is what should be in a use case
More Use Case Sections…
� Precondition –� something that must hold
� …before a use case begins
� Postcondition –� something that must hold
� …after a use case ends
� (Postcondition is also called
success guarantee)
Example?
More Parts of the Use Case
� Special Requirements
� Constraints that aren’t things the system does
� Technology and Data Variations List
� Requirements that are almost design-like in flavor
� We’re not designing yet
� but when we can’t avoid it entirely…
� …this is where these aspects go