1 dilbert scott adams. 2 3 4 writing effective use cases, alistair cockburn use cases: requirements...
TRANSCRIPT
1DilbertScott Adams
2DilbertScott Adams
3DilbertScott Adams
4
Writing Effective Use Cases,
Alistair Cockburn
Use Cases: Requirements in Context,
Daryl Kulak
Applying Use Cases: A Practical Guide,
Geri Schneider; Jason P. Winters
References
5
Representing the System Requirements
RECAP
• Use cases represent the features that are seen by the system’s users.
• Users are the “actors” and the requirements are the “use cases” specifications.
6
Actors and Use Case Examples
Order-Processing Actors:– Customer
– Customer Rep
– Shipping Company
– Clerk
– Inventory System
– Accounting System
Defines system boundary… what is outside the system? The Actors.
7
Use Cases
Use Cases that “serve” the Customer:– Place order– Send order– Get status on order– Return product– Cancel order– Register Complaint
8
The Complete Use Case
The “Use Case” specs:– What must be done to deliver the “use” to the
“user”.– Specify:
• Basic functionality• Alternatives• Error conditions• Any and all preconditions• Postconditions
(Refer to Appendix B in the SRS)
9
Example: Place Order Use Case
Precondition: valid user logged into system.
Basic path:1. Begin with customer selecting Place Order
2. Enters name and address
3. If zip is entered, system supplies city & state
…
10. When payment is confirmed, mark order confirmed, return order ID to customer, and use case ends
Postcondition: the order is saved and marked confirmed.
10
Specifying a Use Case
• The Basic path example is one approach.
• Everything in one place…
• Continue refining adding branching or alternative flows… to show:
1. Other alternatives
2. Error handling
11
Alternative Paths
Examples:1. At any time before selecting Submit,
Customer can select Cancel. If Cancel is selected, the order is not saved and the Use Case ends.
2. In Step 7, if any information is incorrect, system is to prompt user to correct information
12
Branching - Example
Find Order Use Case1. User enters order ID, customer ID, or name.
2. User selects Find.
3. If user entered order IDa) Display that order
4. If user entered customer name or IDa) Return list of all orders for that customer
b) User will select one order from the list
c) Display that order
13
Repetition Examples
Place Order Use Case:4. For each product code entered:
a) Supply product description and price
b) Add price to the total
OR4. While customer enters product codes:
a) Supply product description and price
b) Add price to the total
14
Expanded, complex Use Cases
• Think of the “actor” as representing a class… with objects being specific instances of the class.
• Each instance may interact differently… does your Use Case specify how each instance will be responded to?
• The Basic path represents the response to the most common instance… and is called the primary scenario.
15
Secondary Scenarios
• Add alternatives to the Basic case• Write separate flows of events to
represent an alternate scenario• Place Order –scenarios for each case:
1. Order arrives that is complete, with correct payment
2. Order arrives missing payment3. Order arrives missing shipping address
16
Finding Secondary Scenarios
Walkthrough primary scenario and ask:
• Can more than one action be taken at this step?
• Can something go wrong at this step?
• Can something happen at any time?
Give each a secondary scenario name.
17
Adding “easy to understand” detail
Techniques:– Extends (or Uses)
• use case X is optionally extended by the functionality of use case Y
– Includes • use case X always includes use case Y
– Interfaces– Inheritance
<<includes>>X Y
<<extend>>X Y
18
Optionally Extends or Uses
Place Order
<<extends>> <<extends>>
SeasonalSale Price
FrequentCustomer Discount
Extension Points:Seasonal Sale Price, before Step 5Frequent Customer Discount, before Step 6
<<extends>> may never take place!!! … it depends.
19
Always Includes
Find Order Cancel Order<<includes>>
Factor out common behavior … can be re-used in other use cases
20
<< extend >>
• The “extending use case” defines logic that may be required during a given set of steps in the parent use case.
• Continues the behavior of the parent use case by conceptually inserting additional action sequences
• Used when an alternate course of action is complex
Note: The parent use case could include this behavior
21
<< include >>
• Represents one use case “invoking” another– Example: use case that encapsulates common
logic required by several use cases.
• Represent dependencies between use cases– Dashed line is used
22
Inheritance
NOT between use cases…
but between actors!! Customer
Customer Rep
Here, Customer Rep inheritsthe same role as the Customer.
23
Interface
• Describes how to interact with the actor or the use case.
• The interface specs are a set of operations.
• Specify for each operation:– What is passed– What is returned
Actor or Use Case supporting the interface
Actor or Use Case using the interface
24
Example of Interfaces
Place Order
User interface
Place order interface
Customer Rep
Customer
25
Place Order Interface - example
Supported by Place Order use case - and used by the Customer.
1. Get Product Description and Price (Product ID)
return Description, Price
2. Add Price to Total (Price) return Total
3. Submit Order ( ) return Order ID,
Where Description, Price, Total, and Order ID used by Customer
26
User Interface - example
Supported by Customer and used by Place Order use case.
1. Enter Name_and_Address ( )return Name, Address
2. Enter Product_Code ( ) return Product Code
3. Enter Credit_Card_Info ( )return Credit Card, Expiration Date
Name, Address, Product Code, Credit Card, and Expiration Date used by Place Order.
27
Diagramming Use Cases
• Activity Diagrams (Flow Charts)– Documents the steps in a Use Case
• Storyboarding to show the sequence of events from the user interface perspective
28
Storyboarding
• Designed to show the user interface.• Not what it will look like, but the user’s
“steps” in supporting the use case. • Objectives:
1. Clarify what is happening from the user’s point of view.
2. Get early acceptance from user of interface design.
3. Ensure that all required data attributes are identified and specified.
29
What information is needed?
Place Order
Place order interface
Customer
?
?
30
Collecting your data specs…
Reference for transparencies
Computer
Information
Systems Development:
Analysis and DesignMichael Powers
David Adams
Harlan Mills
31
Order Status
Storyboard - PrototypeShipping Name
Order ID Status
Product Description Quantity Item Status
OK
You are not asking for feedback on the GUI Design!
32
Know How To Uncover Reality
“… if I was designing and building an application used to track sales trends for the Sales department in my company, my first instinct, if I decided to research my users, would be to hunt down Molly from Sales and ask her what she would like the application to do…
Molly has no idea what your software might be able to do, and she almost certainly doesn’t have the technical chops to explain it.
33
She likely doesn’t realize that your product could make the task of creating a client birthday list for mailing out discount coupons a matter of two clicks, and therefore, she would never mention that this task is particularly gruesome and ask if your software could do it for her.
Thus, you need to look a little deeper to find out what Molly needs.
34
If you want to know what Molly wants the software to do, don’t ask her directly.
Instead, find out what she does, how she does it, and what she will want to do later.
Eventually, you’ll figure out how all that translates into a Web application.
For now, don’t think about Web applications. Think about users.
35
Developers tend to want to put up dialog boxes and error messages and all sorts of intrusive widgets that explain what’s going on behind the scenes, but users don’t care.
They only want to know the thing is working so they can accomplish their goals.
36
A user’s goals live outside the application.
The goals are personal.
Very few users have a goal of understanding how PeopleSoft works.
That goal is usually encapsulated by a larger goal.
Perhaps Molly wants to earn a promotion at work and thinks that understanding PeoplsSoft better will enable her to be more productive.
The application itself is not a goal at all – it’s an obstacle between Molly and her goal.
37
Acknowledging that the user’s goals have nothing to do with your Web application allows you to design something that pays more attention to the user’s real goals…
Goal-directed design means listening to users, getting to the truth of what they want, and creating applications from a more informed perspective.”
Designing the Obvious
Robert Hoekman, Jr.
Recommended!