<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription 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="_5rJ78Lj3Edmy88CC3LfB_w"
    name="develop_vision,_0fOAoMlgEdmt3adZL5Dmdw" guid="_5rJ78Lj3Edmy88CC3LfB_w" changeDate="2007-12-18T13:14:14.500-0800"
    changeDescription="Review comments:|1. Conflicts with other GBS practices and work products|-. Removed &quot;Define the system boundaries&quot; - need to figure out how to get it |back in.|Removed from step 1:|Develop profiles of potential (or actual) users of the system that map to the |roles of human actors of the system that you are developing.|-. Removed &quot;Identify constraints on the system&quot;||Need to determine how to make this work with GS method's practices for these removed steps.|Some options:|- OpenUP could be doing something simpler than the GS Method approach that is ok to do as well (need to convince GBS)|- OpenUP could have a practice for doing these additional things that isn't part of the &quot;basic vision&quot;, but can be added in by contributing steps|- OpenUP could go with a more basic practice for defining a vision, and not do these aspects|- The steps could be written as &quot;optional things to do if you don't have a separate practice&quot;.||I like the first option best.||2. Removed &quot;Update the vision&quot; which occurs throughout the task.||3. Removed all the links to work items - we shoudn't assume it is there.||4. Removed hyperlinks to attached guidance. We need to make sure this convention is followed elsewhere.||5. Removed links to OpenUP-only guidance, such as &quot;principles for collaborative development&quot;. Makes sense, but we need to make sure this convention is followed elsewhere."
    version="1.0.0">
  <keyConsiderations>&lt;p>&#xD;
    Use-case modeling&amp;nbsp;is one technique that can prove useful in defining the system boundaries and system behavior.&#xD;
&lt;/p></keyConsiderations>
  <sections xmi:id="_ceK-UED2EdyoefaQkqWN_Q" name="Identify Stakeholders " guid="_ceK-UED2EdyoefaQkqWN_Q">
    <sectionDescription>Identify the stakeholders: decision-makers, customers, potential users, partners, domain experts, industry analysts and&#xD;
other interested parties. Briefly describe what stakeholders do and what their responsibilities are with regard to the&#xD;
system being developed.</sectionDescription>
  </sections>
  <sections xmi:id="_h7AacED2EdyoefaQkqWN_Q" name="Gain agreement on the problem to be solved "
      guid="_h7AacED2EdyoefaQkqWN_Q">
    <sectionDescription>&lt;p>&#xD;
    Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the&#xD;
    stakeholders what they see as the problem. Then search for root causes, or the &quot;problem behind the problem&quot;.&#xD;
    Use&amp;nbsp;appropriate requirements gathering techniques. Formulate the problem statement. The purpose of this is to help&#xD;
    you distinguish solutions and answers from problems and questions.&#xD;
&lt;/p></sectionDescription>
  </sections>
  <sections xmi:id="_vbkccED2EdyoefaQkqWN_Q" name="Gather stakeholder requests " guid="_vbkccED2EdyoefaQkqWN_Q">
    <sectionDescription>&lt;p>&#xD;
    Use the most appropriate technique to help you on requirements gathering.&amp;nbsp;Each technique is applicable in a&#xD;
    particular situation or to a certain type of stakeholder.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If you can meet stakeholders in person, then you can conduct an interview or a brainstorming session. This face-to-face&#xD;
    collaboration is extremely valuable and reduces the chances of the project team misunderstanding the needs of the&#xD;
    stakeholders.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some requirements may already be documented in other work products (such as in change requests or work items).&amp;nbsp;&#xD;
    This can often be used as a solid starting position from which a full set of requirements can be created.&#xD;
&lt;/p></sectionDescription>
  </sections>
  <sections xmi:id="_yeVC0ED2EdyoefaQkqWN_Q" name="Define the scope of the solution"
      guid="_yeVC0ED2EdyoefaQkqWN_Q">
    <sectionDescription>&lt;p>&#xD;
    Analyze the scope in terms of processes, organizations, and systems.&#xD;
&lt;/p></sectionDescription>
  </sections>
  <sections xmi:id="_6uIV0ED2EdyoefaQkqWN_Q" name="Define features of the system  "
      guid="_6uIV0ED2EdyoefaQkqWN_Q">
    <sectionDescription>&lt;p>&#xD;
    Work with stakeholders to capture&amp;nbsp;a list&amp;nbsp;of&amp;nbsp;&lt;a class=&quot;elementlinkwithusertext&quot; href=&quot;./../../practice.tech.shared_vision.base/guidances/termdefinitions/feature_4ED64AEE.html&quot; guid=&quot;_PgYREAeYEduWycDgioo5rg&quot;>features&lt;/a> that stakeholders want in the system, briefly describing them and giving &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../core.tech.common.extend_supp/guidances/concepts/requirement_attributes_4AC73153.html&quot; guid=&quot;_VQ268O0KEdqHTdbLTmC5IQ&quot;>attributes&lt;/a> to help define their general status and priority in the project.&#xD;
&lt;/p></sectionDescription>
  </sections>
  <sections xmi:id="__nDMkED2EdyoefaQkqWN_Q" name="Achieve concurrence  " guid="__nDMkED2EdyoefaQkqWN_Q">
    <sectionDescription>Conduct an effective requirements&amp;nbsp;review&amp;nbsp;with stakeholders and the development team&amp;nbsp;to ensure agreement on&#xD;
the project vision, assess quality, and identify required changes.</sectionDescription>
  </sections>
  <sections xmi:id="_Af_gUEIMEd2omsDpG-BNng" name="Capture a common vocabulary" guid="_Af_gUEIMEd2omsDpG-BNng">
    <sectionDescription>Every project has its own specialized terminology that everyone on the team must understand well to communicate effectively&#xD;
with stakeholders.&amp;nbsp; Work with stakeholders to create a glossary that defines acronyms, abbreviations, and relevant&#xD;
business and technical terms.&amp;nbsp; Work with stakeholders to continually expand and refine the glossary throughout the&#xD;
project lifecycle.</sectionDescription>
  </sections>
  <purpose>The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to&#xD;
express and document their problems, needs, and potential features for the system to be, so the project team can better&#xD;
understand what has to be done.</purpose>
</org.eclipse.epf.uma:TaskDescription>