OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/examples/uc_model_evolve.html - gerrit/epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\examples\uc_model_evolve.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: uc_model_evolve.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_t4QdAMNqEdu2IdAIaWZyAw CRC: 3589190891 -->Evolution of the Use-Case Model<!-- END:presentationName,_t4QdAMNqEdu2IdAIaWZyAw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_t4QdAMNqEdu2IdAIaWZyAw CRC: 3494959854 -->This example illustrates how the use-case model evolves over time when using a &amp;quot;breadth before depth&amp;quot; approach to maximize value and minimize risk early in the lifecycle and to minimize re-work later.<!-- END:briefDescription,_t4QdAMNqEdu2IdAIaWZyAw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-JviMIao63C7w9C8W6iPJrw CRC: 17925949 --><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><!-- END:mainDescription,-JviMIao63C7w9C8W6iPJrw -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\examples\uc_model_evolve.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: uc_model_evolve.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_t4QdAMNqEdu2IdAIaWZyAw CRC: 3589190891 -->Evolution of the Use-Case Model<!-- END:presentationName,_t4QdAMNqEdu2IdAIaWZyAw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_t4QdAMNqEdu2IdAIaWZyAw CRC: 3494959854 -->This example illustrates how the use-case model evolves over time when using a &quot;breadth before depth&quot; approach to maximize value and minimize risk early in the lifecycle and to minimize re-work later.<!-- END:briefDescription,_t4QdAMNqEdu2IdAIaWZyAw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-JviMIao63C7w9C8W6iPJrw CRC: 17925949 --><h3>
	Introduction
	</h3>
	<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 <a class="elementLink"
	href="./../../../openup_basic/tasks/find_and_outline_requirements,_P9cMUPV_EdmdHa9MmVPgqQ.html"
	guid="_P9cMUPV_EdmdHa9MmVPgqQ">Find and Outline Requirements</a> and <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.  This
	familiarity simplifies understanding the principles without getting lost in domain specific terminology.
	</p>
	<h4>
	Early Inception
	</h4>
	<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 <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.
	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 below. (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.  Factoring this behavior out into an <<included>> use
	case will simplify communications, iteration planning, 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.  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, etc.).  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.  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.  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.  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, etc.).  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) 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 />

	</p><!-- END:mainDescription,-JviMIao63C7w9C8W6iPJrw -->
	</body>
	</html>