| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-wv4JAmTQ0R_KjP76LgDITg" |
| name="new_concept,_ryuL0LsbEdyfAY9BXNFkDg" guid="-wv4JAmTQ0R_KjP76LgDITg" changeDate="2008-10-13T21:31:33.891-0700" |
| version="7.2.0"> |
| <mainDescription><h3>
 |
| Specifying Use Cases
 |
| </h3>
 |
| <h4>
 |
| <a id="How to Find Use Cases" name="How to Find Use Cases">How to Find Use Cases</a>
 |
| </h4>
 |
| <p>
 |
| See the&nbsp;<a class="elementLinkWithType"
 |
| href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs_BB5516A9.html"
 |
| guid="_eyL0wCu-EdqSxKAVa9kmvA">Guideline: Identify and Outline Actors and Use Cases</a>&nbsp;for guidance on finding
 |
| Actors and Use Cases.
 |
| </p>
 |
| <h4>
 |
| <a id="How a Use Case Evolves" name="How a Use Case Evolves">How a Use Case Evolves</a>
 |
| </h4>
 |
| <p>
 |
| See the <a class="elementLinkWithType"
 |
| href="./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html"
 |
| guid="_4BJ_YCxSEdqjsdw1QLH_6Q">Guideline: Detail Use Cases and Scenarios</a>&nbsp;for guidance on evolving use cases.
 |
| </p>
 |
| <h4>
 |
| Level of detail necessary in use cases&nbsp;
 |
| </h4>
 |
| <p>
 |
| There will often be use cases in your model that are so simple that they do not need a detailed description of the flow
 |
| of events, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
 |
| disagreement among user kind of readers on what the use case means, and that designers and testers are comfortable with
 |
| the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
 |
| of some data from the system.
 |
| </p>
 |
| <h4>
 |
| <a id="The Scope of a Use Case" name="The Scope of a Use Case">The Scope of a Use Case</a>
 |
| </h4>
 |
| <p>
 |
| It is often hard to decide if a set of user-system interactions, or dialog, is one or several use cases. Consider the
 |
| use of a recycling machine. The customer inserts deposit items, such as cans, bottles, and crates, into the recycling
 |
| machine. When she has inserted all her deposit items, she presses a button, and a receipt is printed. She can then
 |
| exchange this receipt for money.
 |
| </p>
 |
| <p>
 |
| Is it one use case to insert a deposit item, and another use case to require the receipt? Or is it all one use case?
 |
| There are two actions, but one without the other is of little value to the customer. Rather, it is the complete dialog
 |
| with all the insertions, and getting the receipt, that is of value for the customer (and makes sense to her). Thus, the
 |
| complete dialog, from inserting the first deposit item, to pressing the button and getting the receipt, is a complete
 |
| case of use, a use case.
 |
| </p>
 |
| <p>
 |
| Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them
 |
| together, test them together, write manuals for them and in general manage them as a unit. This becomes very obvious in
 |
| larger systems.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
