The Completed Process Orders Use-Case Template
Now that we have completed most of the framework for the use-cases, a sample of a completed template is in order. What follows is the use-case template for Process Orders.
Use-Case Description Information
1.1 Name
Process Orders.
1.2 Goal
This use-case satisfies all of the goals of setting up a new order. This applies for both new and existing customers. All aspects of the order entry process are covered, from initial entry to ultimate pricing.
1.3 Use-Case Team Leader/Members
Rene Becnel (team lead), Stan Young, Todd, Klock, Jose Aponte.
1.4 Precondition
Order clerk has logged onto the system.
1.5 Postcondition
Order is placed, inventory is reduced.
1.6 Constraints/Issues/Risks
The new system might not be ready in time for the summer product promotions.
1.7 Trigger Event(s)
All events dealing with new and existing customers calling and placing orders.
1.8 Primary Actor
Order clerk.
1.9 Secondary Actor(s)
Customer.
Use-Case Pathway Names
2.1 Primary Pathway (Happy Path)
Customer calls and orders a guitar and supplies, and pays with a credit card.
2.2 Alternate Pathway(s)
Customer calls and orders a guitar and supplies, and uses a purchase order.
Customer calls and orders a guitar and supplies, and uses the Remulak easy finance plan.
Customer calls and orders an organ, and pays with a credit card.
Customer calls and orders an organ, and pays with a purchase order.
2.3 Exception Pathway(s)
Customer calls to place an order using a credit card, and the card is invalid.
Customer calls with a purchase order but has not been approved to use the purchase order method.
Customer calls to place an order, and the desired items are not in stock.
Use-Case Detail
A Section 3 will exist for all use-case pathways that are detailed enough to warrant their own unique set of steps. In this case only the happy path and the payment variation are shown.
3.1 Pathway Name
Customer calls and orders a guitar and supplies, and pays with a credit card.
3.2 Trigger Event(s)
All events dealing with new and existing customers calling and placing an order.
3.3 Main Sequence of Steps
Step Description 1 Customer supplies customer number. 2 Customer is acknowledged as current. 3 For each product the customer desires: 3.1 - Product ID or description is requested.
3.2 - Product description is resolved with its ID if necessary.
3.3 - Quantity is requested.
3.4 - Item price is calculated.
4 Extended order total is calculated. 5 Tax is applied. 6 Shipping charges are applied. 7 Extended price is quoted to the customer. 8 Customer supplies credit card number. 9 Customer's credit card is validated. 10 Inventory is reduced. 11 Sale is finalized. 3.4 Variations
Step Description 8.1 Customer may pay with purchase order or easy-finance plan. 3.5 Extensions (optional)
None.
3.6 Business Rules (optional)
Customers may not order more than ten products at one time.
Any sale over $50,000 requires supervisor approval.
Any sale over $20,000 receives a five-percent discount.
3.7 Constraints/Issues/Risks (optional)
Timeliness of the product is key to the next sales promotion.
Use-Case Tactical Information
4.1 Priority
Highest (#1).
4.2 Performance Target(s)
None indicated.
4.3 Frequency
Customer calls and orders a guitar and supplies, and pays with a credit card (800/day).
Customer calls and orders a guitar and supplies, and uses a purchase order (120/day).
Customer calls and orders a guitar and supplies, and uses the Remulak easy finance plan (25/day).
Customer calls and orders an organ, and pays with a credit card (40/day).
Customer calls and orders an organ, and pays with a purchase order (15/day).
4.4 User Interface
This portion of the application will not use the Web as a form of entry because of the need for clerk assistance.
4.5 Location of Source
Newport Hills, Washington.
Portland, Maine (in the future).
The detailed use-case pathways are then specified for all of the individual pathways in each category (primary, alternate, and exception). Each section can be documented at different times. Actually, each section can be done as a mini-iteration. I think one of the most important sections is Use-Case Pathway Names (Section 3) because it gives the analyst and user a succinct look at what the pathways are anticipated to be without documenting all details of each pathway up front. Doing this for all use-cases is crucial for producing an overall estimate for the project. Some practitioners collapse Sections 2 and 3 together; this approach is fine as long as you can first identify the pathway names, and then just fill in the body detail as the use-case evolves.
The use-case detail is reflected in the Unified Process via the Software Requirements Specification (SRS). The nonfunctional elements are captured in the Supplementary Specification. As I pointed out earlier, I prefer to put the nonfunctional elements that relate directly to the use-case in Section 4 of the use-case template. Nonfunctional elements such as the database that will be used I place in the Supplementary Specification.