| <?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-18T01:14:14.000-0800" |
| changeDescription="Review comments:|1. Conflicts with other GBS practices and work products|-. Removed "Define the system boundaries" - 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 "Identify constraints on the system"||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 "basic vision", 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 "optional things to do if you don't have a separate practice".||I like the first option best.||2. Removed "Update the vision" 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 "principles for collaborative development". Makes sense, but we need to make sure this convention is followed elsewhere." |
| version="1.0.0"> |
| <keyConsiderations><p> |
| Use-case modeling&nbsp;is one technique that can prove useful in defining the system boundaries and system behavior. |
| </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
 |
| other interested parties. Briefly describe what stakeholders do and what their responsibilities are with regard to the
 |
| system being developed.</sectionDescription> |
| </sections> |
| <sections xmi:id="_h7AacED2EdyoefaQkqWN_Q" name="Gain agreement on the problem to be solved " |
| guid="_h7AacED2EdyoefaQkqWN_Q"> |
| <sectionDescription><p>
 |
| Avoid rushing into defining the solution. First, gain agreement on the definition of the problem by asking the
 |
| stakeholders what they see as the problem. Then search for root causes, or the "problem behind the problem".
 |
| Use&nbsp;appropriate requirements gathering techniques. Formulate the problem statement. The purpose of this is to help
 |
| you distinguish solutions and answers from problems and questions.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_vbkccED2EdyoefaQkqWN_Q" name="Gather stakeholder requests " guid="_vbkccED2EdyoefaQkqWN_Q"> |
| <sectionDescription><p>
 |
| Use the most appropriate technique to help you on requirements gathering.&nbsp;Each technique is applicable in a
 |
| particular situation or to a certain type of stakeholder.
 |
| </p>
 |
| <p>
 |
| If you can meet stakeholders in person, then you can conduct an interview or a brainstorming session. This face-to-face
 |
| collaboration is extremely valuable and reduces the chances of the project team misunderstanding the needs of the
 |
| stakeholders.
 |
| </p>
 |
| <p>
 |
| Some requirements&nbsp;might already be documented in other work products (such as in change requests or work
 |
| items).&nbsp; This can often be used as a solid starting position from which a full set of requirements can be created.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_yeVC0ED2EdyoefaQkqWN_Q" name="Define the scope of the solution" |
| guid="_yeVC0ED2EdyoefaQkqWN_Q"> |
| <sectionDescription><p>
 |
| Analyze the scope in terms of processes, organizations, and systems.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_6uIV0ED2EdyoefaQkqWN_Q" name="Define features of the system " |
| guid="_6uIV0ED2EdyoefaQkqWN_Q"> |
| <sectionDescription><p>
 |
| Work with stakeholders to capture&nbsp;a list&nbsp;of&nbsp;<a class="elementlinkwithusertext" href="./../../practice.tech.shared_vision.base/guidances/termdefinitions/feature_4ED64AEE.html" guid="_PgYREAeYEduWycDgioo5rg">features</a> that stakeholders want in the system, briefly describing them and giving <a class="elementLinkWithUserText" href="./../../core.tech.common.extend_supp/guidances/concepts/requirement_attributes_4AC73153.html" guid="_VQ268O0KEdqHTdbLTmC5IQ">attributes</a> to help define their general status and priority in the project.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="__nDMkED2EdyoefaQkqWN_Q" name="Achieve concurrence " guid="__nDMkED2EdyoefaQkqWN_Q"> |
| <sectionDescription>Conduct an effective requirements&nbsp;review&nbsp;with stakeholders and the development team&nbsp;to ensure agreement on
 |
| 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
 |
| with stakeholders.&nbsp; Work with stakeholders to create a glossary that defines acronyms, abbreviations, and relevant
 |
| business and technical terms.&nbsp; Work with stakeholders to continually expand and refine the glossary throughout the
 |
| project lifecycle.</sectionDescription> |
| </sections> |
| <purpose>The solution is proposed for a problem that everybody agrees on. Stakeholders collaborate with the development team to |
| express and document their problems, needs, and potential features for the system to be, so the project team can better |
| understand what has to be done.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
