| <?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.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="_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> |
