This sample use case is provided as a template for projects looking to capture requirements on a set of related web pages. The acceptance test cases are described as part of this html page, but the complete details have to be elsewhere so that these tests can be run automatically. My current practice is to implement these acceptance test cases inside the JUnit testing framework (or an appropriate language port of the testing framework).

Customer: Buy goods

(Sketch, done as part of requirements prioritization)

Customer places order for goods, an invoice is generated and sent out with the ordered items.

(Optional) Complexity, Technical/Business risk, Business Priority

Success Guarantee

All detail below here is part of Capturing Requirements for Implementation.

Minimal Guarantee

An explicit quality check here is to consider the possible outcomes of the Use Case. The Minimum guarantee ALWAYS applies, if it is not met then the system is operating incorrectly. The Success guarantee is true if and only if the Actor is successful in achieving their goal. Any other end state is the result of an implementation error and the system does not meet the stated requirements. [So for example if the customer cancels part way through but we still send a picking list to distribution, the implementation is wrong and needs to be fixed.]

Main Success Scenario

(link is to acceptance test case for the main success scenario)

  1. Customer: Select items and quantities
  2. System: Allocate required quantities to customer
  3. System: Obtain authenticated invoicing authorization
  4. Customer: Specify shipping destination
  5. System: Send picking instructions to distribution

The success scenario is the simplest, most direct sequence of sub-goals that lead to the actor getting goal success while the system still protects all of the stakeholders interests (as expressed by the various business rules). The extensions shown below are alternate paths, some leading to success and some to failure.

I call the reasons for taking the alternate paths exception conditions, to highlight the fact that the path being taken is an exception. As a group the Use Case community prefers to call the set of alternate scenarios Extensions. Right now I use these words practically interchangeably, but your mileage may vary. The key item to capture for the Extensions is how any of the sub-goals in the Main Success Scenario may fail and record the condition that causes the failure. Then the extra steps needed in the scenario can be captured below that condition.

Extensions

2a Insufficient stock to meet required quantity for item
2a1 Customer: confirm reduced quantity

2b out of stock on item
2b1 System: determine shipping date
2b2 Customer: Accept delayed delivery

3a Customer is bad credit risk (link is to acceptance test case for this exception condition)

4a invalid shipping destination

Acceptance test cases

Note. At least 1 test case is needed for every exception listed above. For complete coverage you will need more test cases. This might seem like a lot of work, but look on the bright side, you only have to test the things that you want to work correctly, for all of the other requirements you do not have to worry about specifying tests, since it does not matter if the system correctly implements these requirements. (With apologies to Ron Jeffries for rewording his thoughts on testing)

The Main Success Scenario test case should come first since it is nice to show how the system works in the high volume case. Often this test case can be generated before all of the exception conditions and recovery paths are known (or investigated in detail with the business or user community).

Main Success Scenario

Initial system state/inputs

Customer Fred (Good Credit risk) orders 1 of item#1 price $10.00
quantity on hand for item#1 is 10

Expected system state/outputs

Quantity on hand for item#1 is 9
Delivery instructions generated
Invoice generated for Customer Pete for 1 of Item#1 price $10.00

Bad Credit risk

Initial system state/inputs

Customer Joe (Bad Credit risk) orders 1 of item#1 price $10.00
quantity on hand for item#1 is 10

Expected system state/outputs

Quantity on hand for item#1 is 9
Delivery instructions specify Cash on Delivery

(C) 1999 McBreen.Consulting, all rights reserved.

Pete McBreen, petemcbreen@acm.org