| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:GuidanceDescription 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="-JviMIao63C7w9C8W6iPJrw" |
| name="new_example,_t4QdAMNqEdu2IdAIaWZyAw" guid="-JviMIao63C7w9C8W6iPJrw" authors="Chris Sibbald" |
| changeDate="2008-09-03T17:28:43.928-0700" version="7.2.0"> |
| <mainDescription><h1>
 |
| Introduction
 |
| </h1>
 |
| <p>
 |
| This example illustrates how the use-case model and associated use-case specification will evolve during the lifecycle.
 |
| It shows the state of the use case model at two points in the lifecycle: early inception and towards the end of
 |
| elaboration. The purpose is to illustrate how one would identify, outline and detail requirements so as to maximize
 |
| stakeholder value and minimize risk early in the project, as well as to minimize re-work later.&nbsp;
 |
| </p>
 |
| <p>
 |
| The example uses an Automated Teller Machine as the example system, because it is familiar to most people. This
 |
| familiarity simplifies understanding the principles without getting lost in domain specific terminology.
 |
| </p>
 |
| <h2>
 |
| Early inception
 |
| </h2>
 |
| <p>
 |
| Assume you have just started on the project as the Analyst. You have identified the key stakeholders and met with them
 |
| to discuss their needs. During your meetings, you identified a number of key actors, use cases, and supporting
 |
| requirements for the ATM system. You captured the use cases and actors, with names and brief descriptions only, in the
 |
| use-case model. An example of this work is given in the document <strong>ATM UC Model Inception</strong>.
 |
| </p>
 |
| <p>
 |
| Prior to committing significant time to detailing these use cases now, you recognize that a "breadth before depth"
 |
| approach can save you valuable time and permit you to identify the highest value and highest risk items so that you can
 |
| concentrate on those first.
 |
| </p>
 |
| <p>
 |
| You hold a brainstorming session with the stakeholders and outline the basic flow of each of the main use cases. As you
 |
| are working through, you may identify some additional alternative flows. Fight the urge to "dive-in" to the details on
 |
| these alternative flows at this point, simply list them and come back later when you have a better understanding of the
 |
| "big picture".
 |
| </p>
 |
| <p>
 |
| Examples of the notes you took during this exercise are attached (<strong>Withdraw Cash Outline</strong>,
 |
| <strong>Deposit Funds Outline</strong> and <strong>Transfer</strong> <strong>Funds Outline</strong>).<br />
 |
| <b>Note:</b> the choice of font is intentional to illustrate that these are notes, not formal documents.
 |
| </p>
 |
| <p>
 |
| Reviewing your notes, you recognize that there is some behavior that is common to most of the use cases, namely the
 |
| steps required to validate the Bank Customer. Factoring this behavior out into an &lt;&lt;included&gt;&gt; use case
 |
| will simplify communications, iteration planning, and maintenance.
 |
| </p>
 |
| <p>
 |
| You update the use case model accordingly: <strong>ATM UC Model Elaboration</strong>.
 |
| </p>
 |
| <h2>
 |
| Elaboration
 |
| </h2>
 |
| <p>
 |
| With a better understanding of the system, you can now prioritize your effort to maximize value and minimize risk. You
 |
| start by detailing the common behavior captured in the use case: Validate User. This use case captures key
 |
| architectural requirements that will exercise a significant portion of the system (communications with the Bank, card
 |
| reader interface, and so on). Implementing this one key scenario will go a long way to reducing risk.
 |
| </p>
 |
| <p>
 |
| An example of the Validate User use-case specification is attached: <strong>Use Case Spec - Validate User.</strong>
 |
| </p>
 |
| <p>
 |
| Note that there may still be some un-answered questions, but that's OK. Capture these directly in the use-case
 |
| specification and get them answered (see Section 5.6 of the <strong>Validate User UC Specification</strong>, for an
 |
| example).
 |
| </p>
 |
| <p>
 |
| Continuing with another architecturally significant thread, you detail the basic flow and some key alternative flows of
 |
| the use case: Withdraw Cash. You know that if the team can implement this, much of the other functionality will be low
 |
| risk.
 |
| </p>
 |
| <p>
 |
| An example of the Withdraw Cash use-case specification is attached:&nbsp;<strong>Use Case Spec - Withdraw
 |
| Cash</strong>.
 |
| </p>
 |
| <h1>
 |
| Summary
 |
| </h1>
 |
| <p>
 |
| By following a breadth before depth approach to outlining and detailing use cases, you can make better decisions on
 |
| priorities. Start by identifying actors. Then for each actor, ask "What is the main purpose this actor would like to
 |
| use the system?". This will lead to the identification of the use cases. Capture the actors and use cases in the
 |
| use-case model along with a brief description.
 |
| </p>
 |
| <p>
 |
| Prioritize the use cases, and then draft the main scenario or basic flow. As you are working through this you may
 |
| identify alternate flows (what can go wrong, what options are available, and so on). Capture these, along with a brief
 |
| description.
 |
| </p>
 |
| <p>
 |
| Review the use-case model and reprioritize and assess risk. For the high priority (based on value to the stakeholders)
 |
| or high risk use cases,&nbsp;detail the main scenario and the critical alternate flows.
 |
| </p>
 |
| <p>
 |
| If you follow this approach, you will increase the likelihood of delivering value early, minimizing risk, and
 |
| minimizing re-work.<br />
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:GuidanceDescription> |
