| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-Rcm_MlViENAvFFyIe9V3dQ" name="find_and_outline_actors_and_ucs,_eyL0wCu-EdqSxKAVa9kmvA" guid="-Rcm_MlViENAvFFyIe9V3dQ" changeDate="2006-10-23T13:31:13.565-0700" version="1.0.0"> |
| <mainDescription><h4> |
| Finding actors |
| </h4> |
| <p> |
| Find the external entities with which the system under development must interact. Candidates include groups of users |
| who will require help from the system to perform their tasks and execute the system's primary or secondary functions, |
| as well as external hardware, software, and other systems. |
| </p> |
| <p> |
| Define each candidate actor by naming it and writing a brief description. Includes the actor's area of responsibility |
| and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not |
| have any goals. |
| </p> |
| <p> |
| These questions are useful in identifying actors: |
| </p> |
| <ul> |
| <li> |
| Who will supply, use, or remove information from the system? |
| </li> |
| <li> |
| Who will use the system? |
| </li> |
| <li> |
| Who is interested in a certain feature or service provided by the system? |
| </li> |
| <li> |
| Who will support and maintain the system? |
| </li> |
| <li> |
| What are the system's external resources? |
| </li> |
| <li> |
| What other systems will need to interact with the system under development? |
| </li> |
| </ul> |
| <p> |
| Review the list of stakeholders that you captured in the Vision statement. Not all stakeholders will be actors |
| (meaning, they will not all interact directly with the system under development), but this list of stakeholders is |
| useful for identifying candidates for actors. |
| </p> |
| <h4> |
| Finding use cases |
| </h4> |
| <p> |
| The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not, |
| ask: |
| </p> |
| <ul> |
| <li> |
| What are the goals that the actor will attempt to accomplish with the system? |
| </li> |
| <li> |
| What are the primary tasks that the actor wants the system to perform? |
| </li> |
| <li> |
| Will the actor create, store, change, remove, or read data in the system? |
| </li> |
| <li> |
| Will the actor need to inform the system about sudden external changes? |
| </li> |
| <li> |
| Does the actor need to be informed about certain occurrences, such as unavailability of a network resource,&nbsp;in |
| the system? |
| </li> |
| <li> |
| Will the actor perform a system startup or shutdown? |
| </li> |
| </ul> |
| <p> |
| Understanding how&nbsp;the target&nbsp;organization works and how this information system might be incorporated into |
| existing operations gives an idea of system's surroundings. That information may reveal other use case candidates. |
| </p> |
| <p> |
| Give a unique name and brief description that clearly describes the goals for each use case. If the candidate use case |
| does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case. |
| </p> |
| <h4> |
| Outlining Use Cases |
| </h4> |
| <p> |
| Without going into details, write a first draft of the flow of events of the use cases identified as being of high |
| priority. Initially, write a simple step-by-step description of the basic flow of the use case. The step-by-step |
| description is a simple ordered list of interactions between the actor and the system. For example, the description of |
| the basic flow of the Withdraw Cash use case of an automated teller machine (ATM) would be something like this: |
| </p> |
| <ol> |
| <li> |
| The&nbsp;customer inserts a bank card. |
| </li> |
| <li> |
| The system validates the card and prompts the person to enter a personal identification number (PIN). |
| </li> |
| <li> |
| The customer&nbsp;enters a PIN. |
| </li> |
| <li> |
| The system validates the PIN and prompts the customer to select an action. |
| </li> |
| <li> |
| The customer selects Withdraw Cash. |
| </li> |
| <li> |
| The system prompts the customer to choose which account. |
| </li> |
| <li> |
| The customer selects the checking account. |
| </li> |
| <li> |
| The system prompts for an amount. |
| </li> |
| <li> |
| The customer enters the amount to withdraw. |
| </li> |
| <li> |
| The system validates the amount (assuming sufficient funds), and then issues cash and receipt. |
| </li> |
| <li> |
| The customer takes the cash and receipt, and then retrieves the bank card. |
| </li> |
| <li> |
| The use case ends. |
| </li> |
| </ol> |
| <p> |
| As you create this step-by-step description of the basic flow of events, you may discover alternative and exceptional |
| flows. For example, what happens if the customer enters an invalid PIN? Record the name and a brief description of each |
| alternate flow that you identified. |
| </p> |
| <h4> |
| Representing relationships between actors and use cases |
| </h4> |
| <p> |
| The relationship between actors and use cases should be captured, or documented&nbsp; There are several ways to do |
| this. If you are using a use-case model on the project, you can create use-case diagrams to show how&nbsp;actors and |
| use cases&nbsp;relate to each other.&nbsp; Refer to&nbsp;<a class="" href="./../../../openup_basic/guidances/guidelines/uc_model,_0VAUsMlgEdmt3adZL5Dmdw.html" guid="_0VAUsMlgEdmt3adZL5Dmdw">Guideline: Use-Case Model</a>&nbsp;for more information. |
| </p> |
| <p> |
| If you are not using a use-case model for the project, make sure that each use case identifies the associated primary |
| and secondary actors. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |