Scenario Template


You may, of course, write your business use case scenarios in whatever form you and your stakeholders prefer. The template presented in this section is one we have found useful on many assignments. We suggest it as a fairly good compromise between informality and an overly bureaucratic approach.

Business Event Name: The name of the business event to which the business use case responds.

Business Use Case Name and Number: Give each business use case a unique identifier and a name that communicates the functionalityfor example, Record Library Loan, Register New Student Enrollment, Make Benefit Payment, Produce Sales Report. Ideally, the name should be an active verb plus a specific direct object.

Trigger: The data or request for a service that arrives from an external source and triggers a response from the work. The trigger may be the arrival of data from one of the adjacent systemsthat is, from outside of the work area that you are studying. Alternatively, the trigger may be the arrival of the temporal condition that causes the use case to activate for example, the end of the month.

Preconditions: Sometimes certain conditions must exist before the use case is valid. For example, a customer has to be registered before he can access his frequent-flyer statement. Note that another business use case usually takes care of the precondition. In the preceding example, the customer would have registered using the Register Passenger business use case.

Interested Stakeholders: The people, organizations, and/or representatives of computer systems who have knowledge necessary to specify this use case or who have an interest in this use case.

Active Stakeholders: The people, organizations, and/or computer systems that are doing the work of this use case. Don't think about users just yet; instead, think of the real people who are involved in the work of the business use case.

Normal Case Steps: The steps that this use case goes through to complete the normal course of its work. Write the steps as clear, natural-language statements that are understandable to business people related to the project. There are usually between three and ten steps.

Step 1 ...

Step 2 ...

Step 3 ...

Note that a business use case can make use of the services or functionality of another business use case as part of its own processing. However, be careful not to start programming at this stage.

Alternatives: Alternatives are acceptable variations on the normal case of processing. For example, gold cardholders may be given an invitation to the lounge when they check in. Tell the story in the same way:

Alternative step 1 . . .

Alternative step 2 . . .

Alternative step 3 . . .

If the alternative action is simple, you can make it part of the normal case: Step 4. Attach the frequent-flyer number to the reservation.

Alternative 4.1 Issue a lounge invitation if the passenger holds a gold card.

Exceptions: These are unwanted but necessary variations. For example, a customer may have insufficient funds for a withdrawal at an ATM. In this case, the procedure has to offer a lower amount, or offer a loan, or do whatever the stakeholders decide is appropriate. Tag each exception to the appropriate step:

Exception 2.1 . . .

Exception 2.2 . . .

Exception 2.3 . . .

Outcome: The desired situation at the end of this use case. Think of it as the stake holder's objective at the time when he triggers the use case. For example, the money has been dispensed and taken from the ATM, the customer's account has been debited, and the card has been extracted from the ATM.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net