A use case is the mother of all scenarios. Said this, let's explain (it's a bit long):
A scenario is a single instance of an operations sequence, for example "Mary reaches the ATM, passes her card, does not remember the PIN and leaves enraged". In another scenario Mary remembers the PIN but the ATM has no $20 bills so she leaves enraged again. These are failure scenarios of the implicit goal "get cash". In a success scenario Mary reches to the gas station ATM, passes the card, enters the PIN, selects her savings account, enters a $40 amount and leaves with the cash in her hand. A scenario is a description of an operation narrated by a user. With one or more scenarios, and some background knowledge, a use case can be developed. It always contains a "main success scenario", in the case of the ATM it would be the sequence of operations devoid of all specifics like "gas station", "Mary" and $40". The main success scenario describes the steps as if nothing could fail: 1. user: pass the card 2. ATM: ask for PIN 3. user: enter PIN 4. ATM: check card and pin 5. ATM: display account options 6. user: choose account 7. ATM: ask for amount 8. user: enter amount 9. ATM: check balance 10. ATM: dispense cash 11. ATM: show continue options 12. user: .. etc ... Step 4 can fail: the card can be void, or the PIN be wrong, etc. Here is where the differences between a scenario and a use case are more evident: for the thing to ba a use case it must contain the alternate sequences of operation that makes the system ask for the PIN 3 times and if the user fails then swallow the card or refuse any newer interaction. In step 9, another that has an obvious failure possibility, if the balance is not enough the use case must describe the modified path, for example giving the user to return to step 7 or quit. And so on, all possible alternative paths some of them ending in success and some ending in failure. That's how a use case encompasses all possible scenarios. The driving force behind use cases is that are documents understandable both by the users and by the IT developers, its value is that they can be signed off by both parts and be used after the development to check if the outcome is compliant. The detail level is variable, depending on the environment, and does not change the use-case-ness of a document. For a device like, say, a dishwasher, you would like to go into minute detail because after the circuits are burned and the appliance sold it's not possible to make changes as if it were a beta web site. On the other hand if the team is working in a very well known domain then it's possible to safely leave out many details as implicit. For the use cases to be useful they must comply with a set of guidelines, the most important are: 1. The UCs must be named after their goal, like "get cash" (an active verb is required), 2. The "actors" must be identified (i.e.: "ATM", "user"), 3. The users must participate in the development of the UCs, and 4. The UCs must not have references to the UI nor the technology. The "users" that must participate are not Mary and her siblings but, in this case, as in the case of a web site, there must be a user proxy incarnated maybe in a set of personas (synthetic users). Notice that in the example above there are no "press button" references, the only explicit technological nugget it the reference to the card, which can still be considered "environment" as of today. The UCs fall into the "requirements" category. Next step is design. -- Juan Lanus (sorry for the length) http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases http://www.amazon.com/Writing-Effective-Cases-Software-Development/dp/0201702258 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
