<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" name="find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA" guid="-Rcm_MlViENAvFFyIe9V3dQ" changeDate="2007-03-22T16:38:23.977+0330" version="1.0.0">
  <mainDescription>&lt;h1> Finding Actors &lt;/h1>&#xD;
&lt;p> Find the external entities with which the system under development must interact. &#xD;
  Candidates include groups of users who will require help from the system to &#xD;
  perform their tasks and to execute the system's primary or secondary functions, &#xD;
  as well as external hardware, software, and other systems. &lt;/p>&#xD;
&lt;p> Define each candidate Actor by naming it and writing a brief description. &#xD;
  Include the Actor's area of responsibility and the goals that the Actor will &#xD;
  attempt to accomplish when using the system. Eliminate Actor candidates who &#xD;
  do not have any goals. For more information on Actors and their properties, &#xD;
  see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/actor_411726C.html&quot; guid=&quot;_zGqO0MDpEduTGJ8i4u8TMw&quot;>Concept: &#xD;
  Actor&lt;/a>. &lt;/p>&#xD;
&lt;p> These questions are useful for identifying Actors: &lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Who will supply, use, or remove information from the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Who will use the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Who is interested in a certain feature or service provided by the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Who will support and maintain the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What are the system's external resources?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What other systems will need to interact with the system under development?&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p> Review the list of stakeholders that you captured in the Vision Statement. &#xD;
  Not all stakeholders will be Actors (meaning, they will not all interact directly &#xD;
  with the system under development), but this list of stakeholders is useful &#xD;
  for identifying candidates for Actors. &lt;/p>&#xD;
&lt;h1> Finding likely use cases &lt;/h1>&#xD;
&lt;p>&#xD;
    The best way to find use cases is to consider what each Actor requires of the system. For each Actor, human or not,&#xD;
    ask:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &#xD;
  &lt;li> What are the goals that the Actor will attempt to achieve with the system? &#xD;
  &lt;/li>&#xD;
    &lt;li>&#xD;
        What are the primary tasks that the Actor wants the system to perform?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Will the Actor create, store, change, remove, or read data in the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Will the Actor need to inform the system about sudden external changes?&#xD;
    &lt;/li>&#xD;
    &#xD;
  &lt;li> Does the Actor need to be informed about certain occurrences in the system, &#xD;
    such as unavailability of a network? &lt;/li>&#xD;
    &lt;li>&#xD;
        Will the Actor perform a system startup or shutdown?&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Understanding how&amp;nbsp;the target&amp;nbsp;organization works and how this information system might be incorporated into&#xD;
    existing operations gives an idea of system's surroundings. That information may reveal other use case candidates.&#xD;
&lt;/p>&#xD;
&lt;p> Give a unique name and brief description that clearly describes the goals &#xD;
  for each use case. If the candidate use case does not have goals, ask yourself &#xD;
  why it exists, and then either identify a purpose for it or eliminate the use &#xD;
  case. For more information on use cases and their properties, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/use_case_BB199D1B.html&quot; guid=&quot;_KudM0NcJEdqz_d2XWoVt6Q&quot;>Concept: &#xD;
  Use Case&lt;/a>. &lt;/p>&#xD;
&lt;h1> Outlining use cases &lt;/h1>&#xD;
&lt;p> Without going into details, write a first draft of the flow of events of the &#xD;
  use cases identified as high-priority. Initially, write a simple step-by-step &#xD;
  description of the basic flow of the use case. The step-by-step description &#xD;
  is a simple ordered list of interactions between the Actor and the system. For &#xD;
  example, the description of the basic flow of the Withdraw Cash use case of &#xD;
  an automated teller machine (ATM) would be something like this: &lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        The&amp;nbsp;customer inserts a bank card.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system validates the card and prompts the person to enter a personal identification number (PIN).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The customer&amp;nbsp;enters a PIN.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system validates the PIN and prompts the customer to select an action.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The customer selects Withdraw Cash.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system prompts the customer to choose which account.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The customer selects the checking account.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system prompts for an amount.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The customer enters the amount to withdraw.&#xD;
    &lt;/li>&#xD;
    &#xD;
  &lt;li> The system validates the amount (assuming sufficient funds), and then issues &#xD;
    cash and a receipt. &lt;/li>&#xD;
    &lt;li>&#xD;
        The customer takes the cash and receipt, and then retrieves the bank card.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The use case ends.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p> As you create this step-by-step description of the basic flow of events, you &#xD;
  may discover alternative and exceptional flows. For example, what happens if &#xD;
  the customer enters an invalid PIN? Capture each alternative flow that you identified &#xD;
  so that you don't forget them. You can fill in the details later. See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/examples/uc_model_evolve_960F136B.html&quot; guid=&quot;_t4QdAMNqEdu2IdAIaWZyAw&quot;>Example: &#xD;
  Evolution of the Use-Case Model&lt;/a>&amp;nbsp;for more information on how the use &#xD;
  cases evolve. &lt;/p>&#xD;
&lt;h1> Relationships between Actors and use cases &lt;/h1>&#xD;
&lt;p> The relationship between Actors and use cases should be captured, or documented&amp;nbsp; &#xD;
  There are several ways to do this. If you are using a use-case model on the &#xD;
  project, you can create use-case diagrams to show how&amp;nbsp;Actors and use cases&amp;nbsp;relate &#xD;
  to each other. See &lt;a href=&quot;./../../../openup/guidances/guidelines/uc_model_4C64E97D.html&quot; guid=&quot;_0VAUsMlgEdmt3adZL5Dmdw&quot;>Guideline: &#xD;
  Use-Case Model&lt;/a>&amp;nbsp;for more information. &lt;/p>&#xD;
&lt;p>&#xD;
    If you are not using a use-case model for the project, make sure that each use case identifies the associated primary&#xD;
    and secondary Actors.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
