| <?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.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-JviMIao63C7w9C8W6iPJrw" |
| name="new_example,_t4QdAMNqEdu2IdAIaWZyAw" guid="-JviMIao63C7w9C8W6iPJrw" authors="Chris Sibbald" |
| changeDate="2007-02-23T10:23:26.346-0800"> |
| <mainDescription><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| This example illustrates how the use-case model and associated use-case specification will evolve during the
 |
| lifecycle.&nbsp; It shows the state of the use case model at two points in the lifecycle: early inception and towards
 |
| the end of elaboration.&nbsp; The purpose is to illustrate how one would&nbsp;<a class="elementLink" href="./../../../openup/tasks/find_and_outline_requirements_90D272B9.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find and Outline Requirements</a> and&nbsp;<a class="elementLink" href="./../../../openup/tasks/detail_requirements_9747F71E.html" guid="_0e1mIMlgEdmt3adZL5Dmdw">Detail Requirements</a> so as to maximize stakeholder value and minimize risk early in
 |
| the project as well as to minimize re-work later.
 |
| </p>
 |
| <p>
 |
| The example uses an Automated Teller Machine as the example system because it is familiar to most people.&nbsp; This
 |
| familiarity&nbsp;simplifies understanding the principles without&nbsp;getting lost in domain specific terminology.
 |
| </p>
 |
| <h4>
 |
| Early Inception
 |
| </h4>
 |
| <p>
 |
| Assume you have just started on the project as the Analyst.&nbsp; You have identified the key stakeholders and met with
 |
| them to discuss their needs.&nbsp; During your meetings, you identified a number of key actors,&nbsp;use cases and
 |
| supporting requirements for the ATM system.&nbsp; You captured the use cases and actors, with names and brief
 |
| descriptions only, in the use-case model.&nbsp; An example of this work is given in the document <a href="./resources/ATM%20UC%20Model%20Inception.doc" target="_blank">ATM UC Model Inception.doc</a>.
 |
| </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/or highest risk items so 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.&nbsp;
 |
| As you are working through, you may identify some additional alternative flows.&nbsp; 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 below.&nbsp;(Note the choice of font is intentional to
 |
| illustrate that these are notes, not formal documents).
 |
| </p>
 |
| <p>
 |
| <a href="./resources/Withdraw%20Cash%20Outline.doc" target="_blank">Withdraw Cash Outline.doc</a>
 |
| </p>
 |
| <p>
 |
| <a href="./resources/Deposit%20Funds%20Outline.doc" target="_blank">Deposit Funds Outline.doc</a>
 |
| </p>
 |
| <p>
 |
| <a href="./resources/Transfer%20Funds%20Outline.doc" target="_blank">Transfer Funds Outline.doc</a>
 |
| </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.&nbsp; Factoring this behavior out into an &lt;&lt;included&gt;&gt; use
 |
| case will simplify communications, iteration planning,&nbsp;and maintenance.
 |
| </p>
 |
| <p>
 |
| You update the use case model accordingly: <a href="./resources/ATM%20UC%20Model%20Elaboration.doc" target="_blank">ATM
 |
| UC Model Elaboration.doc</a>.
 |
| </p>
 |
| <h4>
 |
| Elaboration
 |
| </h4>
 |
| <p>
 |
| With a better understanding of the system, you can now prioritize your effort to maximize value and minimize
 |
| risk.&nbsp; You start by detailing the common behavior captured in the use case: Validate User.&nbsp; This use case
 |
| captures key architectural requirements that will exercise a significant portion of the system (communications with the
 |
| Bank, card reader interface, etc.).&nbsp; Implementing this one key scenario will go a long way to reducing risk.
 |
| </p>
 |
| <p>
 |
| An example of the Validate User Specification is given below:<br />
 |
| <br />
 |
| <a href="./resources/Use%20Case%20Spec%20-%20Validate%20User.doc" target="_blank">Use Case Spec - Validate
 |
| User.doc</a>
 |
| </p>
 |
| <p>
 |
| Note that there may still be some un-answered questions, but that’s OK.&nbsp; Capture these directly in the use-case
 |
| specification and get them answered (see Section 5.6 of the Validate User UC Specification, above for an example).
 |
| </p>
 |
| <p>
 |
| Continuing with another architecturally significant thread, you detail the basic flow and some key alternate flows of
 |
| the use case: Withdraw Cash.&nbsp; 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 Specification is given below:
 |
| </p>
 |
| <p>
 |
| <a href="./resources/Use%20Case%20Spec%20-%20Withdraw%20Cash.doc" target="_blank">Use Case Spec - Withdraw Cash.doc</a>
 |
| </p>
 |
| <h3>
 |
| Summary
 |
| </h3>
 |
| <p>
 |
| By following a breadth before depth approach to outlining and detailing use cases one can make better decisions on
 |
| priorities.&nbsp; Start by identifying actors.&nbsp; Then for each actor, ask “What is the main purpose this actor
 |
| would like to use the system?”.&nbsp; This will lead to the identification of the use cases.&nbsp; 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.&nbsp; As you are working through this you may
 |
| identify alternate flows (what can go wrong, what options are available, etc.).&nbsp; Capture these, along with a brief
 |
| description.
 |
| </p>
 |
| <p>
 |
| Review the use-case model and reprioritize and assess risk.&nbsp; For the high priority (based on value to the
 |
| stakeholders) and/or high risk use cases 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 />
 |
| &nbsp;
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:GuidanceDescription> |
