| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" name="vision,_0WVxcMlgEdmt3adZL5Dmdw" guid="_zHTQUKYSEdmvhNXG0Oc2uA" changeDate="2007-10-24T09:47:27.000-0700" version="1.0.0"> |
| <keyConsiderations><p>
 |
| It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make
 |
| the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important
 |
| features and avoiding details of requirements.
 |
| </p>
 |
| <p>
 |
| Projects that focus on product development might extend the marketing section and include a more detailed product
 |
| position statement that is based on their needs and research.
 |
| </p></keyConsiderations> |
| <purpose><p>
 |
| This artifact provides a high-level basis for more detailed technical requirements. It captures the technical solution
 |
| by describing the high-level stakeholder requests and constraints that give an overview of the reasoning, background,
 |
| and context for detailed requirements. The vision serves as input for communicating the fundamental "what and why" for
 |
| the project and provides a strategy against which all future decisions can be validated.
 |
| </p>
 |
| <p>
 |
| The vision should rally team members behind an idea and give them the context for decision-making in the requirements
 |
| area. The vision must be visible to everyone on the team.<br />
 |
| </p></purpose> |
| <impactOfNotHaving>If you do not state a vision, stakeholders and the development team might have different expectations of the project. This
 |
| can lead to cancellation of the project. Misunderstandings and miscommunication about the strategy can cause the project to
 |
| move from the original vision and create discrepancies in stakeholder expectations.</impactOfNotHaving> |
| <reasonsForNotNeeding>Use this artifact for all but trivial projects.</reasonsForNotNeeding> |
| <representationOptions><p>
 |
| Typically, the vision is represented in a document. If key stakeholder needs are captured in a requirements management
 |
| tool, this part of the document can be generated by using reporting capabilities.
 |
| </p>
 |
| <p>
 |
| If the vision serves a set of projects or an entire program, the overall vision might be divided into several vision
 |
| work products. In this case, the vision of the program brings the visions together by providing program-specific
 |
| content and referencing the subordinate visions.<br />
 |
| </p></representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |
