OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/examples/uc_model_evolve.xmi - epf/org.eclipse.epf.nl-libraries - Git at Google

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