OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/concepts/use_case.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>openup&amp;#92;guidances&amp;#92;concepts&amp;#92;&amp;#92;use_case.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: use_case.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_KudM0NcJEdqz_d2XWoVt6Q CRC: 3319967926 -->Use Case<!-- END:presentationName,_KudM0NcJEdqz_d2XWoVt6Q -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_KudM0NcJEdqz_d2XWoVt6Q CRC: 4148269292 -->A use case describes what the system must do to provide value to the stakeholders.<!-- END:briefDescription,_KudM0NcJEdqz_d2XWoVt6Q -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-BQLZ5GRUNrMdU6XeZAfe9Q CRC: 2505222101 --><h3>
     Explanation
 </h3>
 <p>
     A use case describes the interactions between one of more <a class="elementLink" href="./../../../openup/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actor</a>s and the system in order to provide an observable result of value for the
     initiating actor.
 </p>
 <p>
     The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain
     the observable result of value) for a particular actor.
 </p>
 <p>
     In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer
     funds between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using
     the system.
 </p>
 <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
     <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
         <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
             <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
                 <p class="picturetext">
                     Figure 1: ATM use case example.
                 </p>
             </blockquote>
         </blockquote>
     </blockquote>
 </blockquote>


 <p class="picturecenter" align="center">
      <img height="321" alt="automated teller machine and actors" src="./resources/im_uc.gif" width="456" />
 </p>
 <p>
     Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible
     ways of using the system. You should be able to determine the goal of a use case simply by observing its name.
 </p>
 <p>
     A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s)
     and the system, structured as follows:
 </p>
 <ol>
     <li>
         The actor &lt;&lt;does something&gt;&gt;
     </li>
     <li>
         The system &lt;&lt;does something in response&gt;&gt;
     </li>
     <li>
         The actor &lt;&lt;does something else&gt;&gt;
     </li>
     <li>
         The system…<br />
     </li>
 </ol>
 <p>
     Each dialog of this form is called a “Flow of Events”.
 </p>
 <p>
     Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon
     specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required
     network connection is currently unavailable), each use case will contain several flows, including one “Basic Flow of
     Events” and several “Alternative Flows”.
 </p>
 <p>
     The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where
     everything goes as planned, and the actor’s goal (the observable result of value) is met.  The basic flow
     represents the main capability provided by the system for this use case.
 </p>
 <p>
     As the name implies, Alternative Flows specify alternative interactions associated with the same goal.
 </p>
 <p>
     Closely related to use cases is the concept of a scenario.  A scenario is a <b>specific</b> flow of
     events, for a <b>specific</b> set of inputs to the system, states of the system, and states of the system’s
     environment.  Scenarios are closely related to test cases.
 </p>
 <h3>
     Properties of Use Cases
 </h3>
 <h4>
     <a id="Name" name="Name">Name</a>
 </h4>
 <p>
     Each use case should have a name that clearly describes the main goal of the use case. The name may have to be several
     words long to be understood. Typically the name is a verb phrase, for example: Withdraw Cash. <br/>
 	<b>Note:</b> No two use cases can
     have the same name.
 </p>
 <h4>
     <a id="Brief Description" name="Brief Description">Brief Description</a>
 </h4>
 <p>
     The brief description of the use case should reflect its purpose.
 </p>
 <h4>
     <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of
     Events -- Contents</a>
 </h4>
 <p>
     The <b>flow of events</b> should describe the interactions between the actor(s) and the system clearly enough for an
     outsider to easily understand. The flow of events should represent <i>what</i> the system does, not <i>how</i> the
     system is design to perform the required behavior.
 </p>
 <p>
     Follow these guidelines for the contents of the flow of events:
 </p>
 <ul>
     <li>
         Describe how the use case starts and ends.
     </li>
     <li>
         Describe what data is exchanged between the actor and the use case.
     </li>
     <li>
         Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system.
         Specifying user interface details too early will limit design options.
     </li>
     <li>
         Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
         ... ".
     </li>
     <li>
         Avoid vague terminology.
     </li>
     <li>
         Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
         test cases.
     </li>
 </ul>
 <p>
     If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
     that the meaning of the terms is consistent. To manage common terms, put them in a <a class="elementLink" href="./../../../openup/workproducts/glossary_5D300778.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a>.
 </p>
 <h4>
     <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events -- Structure</a>
 </h4>
 <p>
     The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><b>alternative flows of
     events</b>. The basic flow of events should cover what "normally" happens when the use case is performed. The
     alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and
     also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow
     of events, some of which will return to the basic flow of events and some of which will end the execution of the use
     case.
 </p>
 <p>
     The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
     relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use
     case.
 </p>

 <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
     <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
         <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
             <p class="picturetext">
                 Figure 2: Typical structure of a use case flow of events
             </p>
         </blockquote>
     </blockquote>
 </blockquote>


 <p align="center">
     <img height="212" alt="Arrows representing flow of events" src="./resources/ucstrct.gif" width="231" />
 </p>

 <p>
     To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
     detour to the basic flow of events:
 </p>
 <ul>
     <li>
         Where the alternative flow can be inserted in the basic flow of events
     </li>
     <li>
         The condition that needs to be fulfilled for the alternative behavior to start
     </li>
     <li>
         How and where the basic flow of events is resumed, or how the use case ends
     </li>
 </ul>
 <p>
     It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
     section (using some informal "if-then-else" construct). This should be avoided. Too many alternatives will make the
     normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
     text more pseudo-code like and harder to read.
 </p>
 <p>
     Both the basic and alternative flows may be further structured into subflows. In doing this, your main goal should be
     readability of the text. A guideline is that a subflow should be a segment of behavior within the use case that has a
     clear purpose, and is "atomic" in the sense that you do either all or none of the actions described.
 </p>
 <h4>
     <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Special Requirements" name="Special Requirements">Special
     Requirements</a>
 </h4>
 <p>
     In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by
     the flow of events. These are typically non-functional requirements that will influence the design model. See also the
     discussion on non-functional requirements in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/requirements_8006414F.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>.
 </p>
 <h4>
     <a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
 </h4>
 <p>
     A precondition is the state of the system and its surroundings that is required before the use case can be
     started. Post-Conditions are the states the system can be in after the use case has ended. It can
     be helpful to use the concepts of precondition and post-condition to clarify how the flow of events starts
     and ends. However, only use them if the audience for the description of the use case agrees that it is helpful.
 	Figure 3 shows an example.
 </p>
 <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
     <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
         <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
             <p>
                 Figure 3: Illustration of preconditions and resulting post-conditions
             </p>
         </blockquote>
     </blockquote>
 </blockquote>
 <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 <p align="center">
     <img height="278" alt="examples marked with circles on arrow diagram" src="./resources/ucprepst.gif" width="344" />
 </p><br class="picturetext" />
 <br />
     <p class="exampleheading">
         Examples
     </p>
     <p class="example">
         <b>A precondition for the use case Cash Withdrawal in the ATM machine:</b> The customer has a personally
         issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
     </p>
     <p class="example">
         <b>A post-condition for the use case Cash Withdrawal in the ATM machine:</b> At the end of the use case,
         all account and transaction logs are balanced, communication with the banking system is reinitialized, and the card
         is returned to the customer.
     </p>
 </blockquote>
 <h3>
     Level of detail necessary in use cases
 </h3>
 <p>
     There will often be use cases in your model that are so simple that they do not need a detailed structured description
     of the use case (that is, a step-by-step outline is quite enough). The criteria for making this decision is that you don't see
     disagreement among different 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 data entry or retrieval
     in your system.
 </p>
 <p>
     For more information on possible formats and the level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/use_case_formats_FF4AE425.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
 </p>
 <h3>
     Example <a id="The Scope of a Use Case" name="The Scope of a Use Case">Use Case</a>
 </h3>
 <p>
     For an example of a completed use-case specification see <a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_specification_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a>.
 </p><!-- END:mainDescription,-BQLZ5GRUNrMdU6XeZAfe9Q -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>openup&#92;guidances&#92;concepts&#92;&#92;use_case.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: use_case.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_KudM0NcJEdqz_d2XWoVt6Q CRC: 3319967926 -->Use Case<!-- END:presentationName,_KudM0NcJEdqz_d2XWoVt6Q -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_KudM0NcJEdqz_d2XWoVt6Q CRC: 4148269292 -->A use case describes what the system must do to provide value to the stakeholders.<!-- END:briefDescription,_KudM0NcJEdqz_d2XWoVt6Q -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-BQLZ5GRUNrMdU6XeZAfe9Q CRC: 2505222101 --><h3>
	Explanation
	</h3>
	<p>
	A use case describes the interactions between one of more <a class="elementLink" href="./../../../openup/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actor</a>s and the system in order to provide an observable result of value for the
	initiating actor.
	</p>
	<p>
	The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain
	the observable result of value) for a particular actor.
	</p>
	<p>
	In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer
	funds between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using
	the system.
	</p>
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<p class="picturetext">
	Figure 1: ATM use case example.
	</p>
	</blockquote>
	</blockquote>
	</blockquote>
	</blockquote>


	<p class="picturecenter" align="center">
	<img height="321" alt="automated teller machine and actors" src="./resources/im_uc.gif" width="456" />
	</p>
	<p>
	Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible
	ways of using the system. You should be able to determine the goal of a use case simply by observing its name.
	</p>
	<p>
	A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s)
	and the system, structured as follows:
	</p>
	<ol>
	<li>
	The actor <<does something>>
	</li>
	<li>
	The system <<does something in response>>
	</li>
	<li>
	The actor <<does something else>>
	</li>
	<li>
	The system…<br />
	</li>
	</ol>
	<p>
	Each dialog of this form is called a “Flow of Events”.
	</p>
	<p>
	Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon
	specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required
	network connection is currently unavailable), each use case will contain several flows, including one “Basic Flow of
	Events” and several “Alternative Flows”.
	</p>
	<p>
	The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where
	everything goes as planned, and the actor’s goal (the observable result of value) is met. The basic flow
	represents the main capability provided by the system for this use case.
	</p>
	<p>
	As the name implies, Alternative Flows specify alternative interactions associated with the same goal.
	</p>
	<p>
	Closely related to use cases is the concept of a scenario. A scenario is a <b>specific</b> flow of
	events, for a <b>specific</b> set of inputs to the system, states of the system, and states of the system’s
	environment. Scenarios are closely related to test cases.
	</p>
	<h3>
	Properties of Use Cases
	</h3>
	<h4>
	<a id="Name" name="Name">Name</a>
	</h4>
	<p>
	Each use case should have a name that clearly describes the main goal of the use case. The name may have to be several
	words long to be understood. Typically the name is a verb phrase, for example: Withdraw Cash. <br/>
	<b>Note:</b> No two use cases can
	have the same name.
	</p>
	<h4>
	<a id="Brief Description" name="Brief Description">Brief Description</a>
	</h4>
	<p>
	The brief description of the use case should reflect its purpose.
	</p>
	<h4>
	<a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of
	Events -- Contents</a>
	</h4>
	<p>
	The <b>flow of events</b> should describe the interactions between the actor(s) and the system clearly enough for an
	outsider to easily understand. The flow of events should represent <i>what</i> the system does, not <i>how</i> the
	system is design to perform the required behavior.
	</p>
	<p>
	Follow these guidelines for the contents of the flow of events:
	</p>
	<ul>
	<li>
	Describe how the use case starts and ends.
	</li>
	<li>
	Describe what data is exchanged between the actor and the use case.
	</li>
	<li>
	Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system.
	Specifying user interface details too early will limit design options.
	</li>
	<li>
	Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor
	... ".
	</li>
	<li>
	Avoid vague terminology.
	</li>
	<li>
	Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify
	test cases.
	</li>
	</ul>
	<p>
	If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and
	that the meaning of the terms is consistent. To manage common terms, put them in a <a class="elementLink" href="./../../../openup/workproducts/glossary_5D300778.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a>.
	</p>
	<h4>
	<a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events -- Structure</a>
	</h4>
	<p>
	The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><b>alternative flows of
	events</b>. The basic flow of events should cover what "normally" happens when the use case is performed. The
	alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and
	also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow
	of events, some of which will return to the basic flow of events and some of which will end the execution of the use
	case.
	</p>
	<p>
	The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in
	relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use
	case.
	</p>

	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<p class="picturetext">
	Figure 2: Typical structure of a use case flow of events
	</p>
	</blockquote>
	</blockquote>
	</blockquote>


	<p align="center">
	<img height="212" alt="Arrows representing flow of events" src="./resources/ucstrct.gif" width="231" />
	</p>

	<p>
	To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
	detour to the basic flow of events:
	</p>
	<ul>
	<li>
	Where the alternative flow can be inserted in the basic flow of events
	</li>
	<li>
	The condition that needs to be fulfilled for the alternative behavior to start
	</li>
	<li>
	How and where the basic flow of events is resumed, or how the use case ends
	</li>
	</ul>
	<p>
	It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
	section (using some informal "if-then-else" construct). This should be avoided. Too many alternatives will make the
	normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
	text more pseudo-code like and harder to read.
	</p>
	<p>
	Both the basic and alternative flows may be further structured into subflows. In doing this, your main goal should be
	readability of the text. A guideline is that a subflow should be a segment of behavior within the use case that has a
	clear purpose, and is "atomic" in the sense that you do either all or none of the actions described.
	</p>
	<h4>
	<a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Special Requirements" name="Special Requirements">Special
	Requirements</a>
	</h4>
	<p>
	In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by
	the flow of events. These are typically non-functional requirements that will influence the design model. See also the
	discussion on non-functional requirements in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/requirements_8006414F.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>.
	</p>
	<h4>
	<a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
	</h4>
	<p>
	A precondition is the state of the system and its surroundings that is required before the use case can be
	started. Post-Conditions are the states the system can be in after the use case has ended. It can
	be helpful to use the concepts of precondition and post-condition to clarify how the flow of events starts
	and ends. However, only use them if the audience for the description of the use case agrees that it is helpful.
	Figure 3 shows an example.
	</p>
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<p>
	Figure 3: Illustration of preconditions and resulting post-conditions
	</p>
	</blockquote>
	</blockquote>
	</blockquote>
	<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
	<p align="center">
	<img height="278" alt="examples marked with circles on arrow diagram" src="./resources/ucprepst.gif" width="344" />
	</p><br class="picturetext" />
	<br />
	<p class="exampleheading">
	Examples
	</p>
	<p class="example">
	<b>A precondition for the use case Cash Withdrawal in the ATM machine:</b> The customer has a personally
	issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.
	</p>
	<p class="example">
	<b>A post-condition for the use case Cash Withdrawal in the ATM machine:</b> At the end of the use case,
	all account and transaction logs are balanced, communication with the banking system is reinitialized, and the card
	is returned to the customer.
	</p>
	</blockquote>
	<h3>
	Level of detail necessary in use cases
	</h3>
	<p>
	There will often be use cases in your model that are so simple that they do not need a detailed structured description
	of the use case (that is, a step-by-step outline is quite enough). The criteria for making this decision is that you don't see
	disagreement among different 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 data entry or retrieval
	in your system.
	</p>
	<p>
	For more information on possible formats and the level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/use_case_formats_FF4AE425.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
	</p>
	<h3>
	Example <a id="The Scope of a Use Case" name="The Scope of a Use Case">Use Case</a>
	</h3>
	<p>
	For an example of a completed use-case specification see <a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_specification_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a>.
	</p><!-- END:mainDescription,-BQLZ5GRUNrMdU6XeZAfe9Q -->
	</body>
	</html>