blob: 49819621a15f7de12d69bfc0538de568d4248f8f [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" epf:version="1.0.0" xmi:id="_zHTQUKYSEdmvhNXG0Oc2uA" name="vision,_0WVxcMlgEdmt3adZL5Dmdw" guid="_zHTQUKYSEdmvhNXG0Oc2uA" changeDate="2007-02-28T08:55:39.149-0500" version="1.0.0">
This artifact&amp;nbsp;provides a complete vision for the software system under development and supports the contract
between the customer and the development organization. Every project needs a source for capturing all Stakeholders'
This artifact&amp;nbsp;is written from the customers' perspective, focusing on the essential features of the system and
acceptable levels of quality. The artifact should include a description of what &lt;a class=&quot;elementLinkWithUserText&quot;
guid=&quot;_PgYREAeYEduWycDgioo5rg&quot;&gt;features&lt;/a&gt;&amp;nbsp;will be included, as well as those considered but not included.
<purpose>&lt;p&gt; This artifact&amp;nbsp;provides a high-level, sometimes contractual, basis for
the more detailed technical requirements that are visible to the Stakeholders.
It captures the essence of the system by describing high-level
requirements and design constraints that give the reader an overview of the
system from a behavioral requirements perspective. It serves
as input for the project-approval process,
communicates the fundamental &quot;what and why&quot; for the project, and provides
a plan against which all future decisions should be validated. &lt;/p&gt;</purpose>
<impactOfNotHaving>If this artifact is not used, there is a high risk that Stakeholders and the development
team will have different expectations.&amp;nbsp;This could lead to cancellation of
the project.</impactOfNotHaving>
<representationOptions>Tailor this artifact as necessary for your project's needs. It is generally good
practice to keep this artifact brief so you can release
it to Stakeholders as soon as possible, and to make it easy for Stakeholders to
read and understand. You can
accomplish this by including only the most important Stakeholder requests
and features and avoiding details of requirements.
You can describe details in the other requirement