<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI 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">
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-EO6unNzlXK9tjJQJBKQ2bA" name="Identify Requirements,_AoC9UbjgEe2ItPaV9bHRfA" guid="-EO6unNzlXK9tjJQJBKQ2bA"/>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-QUsUi991ImmwGWcFE7XJ5A" name="vision,_ODXWIbjkEe2ItPaV9bHRfA" guid="-QUsUi991ImmwGWcFE7XJ5A">
    <refinedDescription>&lt;p>&#xD;
    This artifact&amp;nbsp;provides a complete vision for the software system under development and supports the contract&#xD;
    between the customer and the development organization. Every project needs a source for capturing all Stakeholders'&#xD;
    expectations.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This artifact&amp;nbsp;is written from the customers' perspective, focusing on the essential features of the system and&#xD;
    acceptable levels of quality. The artifact should include a description of what &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup/guidances/termdefinitions/feature_4ED64AEE.html&quot; guid=&quot;_PgYREAeYEduWycDgioo5rg&quot;>features&lt;/a>&amp;nbsp;will be included, as well as those considered but not included.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-0hveH6Lnzjk2wYFzpqcNTQ" name="supporting_requirements_spec,_ODXWJLjkEe2ItPaV9bHRfA" guid="-0hveH6Lnzjk2wYFzpqcNTQ">
    <refinedDescription>&lt;p>&#xD;
    Supporting Requirements and Use Cases, together, define the system requirements. Use Cases describe the behavioral&#xD;
    requirements for the system, and Supporting Requirements describe system-wide requirements that are not captured within&#xD;
    the Use-Case Specifications. Making this distinction simplifies maintenance.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,&#xD;
    Performance, Supportability + Constraints). For more information on this classification, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/concepts/supporting_requirements_B2C4D610.html&quot; guid=&quot;_VXZ5wO0IEdqHTdbLTmC5IQ&quot;>Concept: Supporting Requirements&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The figure that follows illustrates the relationship among the Supporting Requirements, Use-Case Specifications, and&#xD;
    Actors.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;400&quot; alt=&quot;&quot; src=&quot;./../../openup/workproducts/./resources/supporting_reguirements2.gif&quot; width=&quot;600&quot; />&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-yVwNIxfbtYQjlJdBQ4Y6gg" name="glossary,_ODXWJ7jkEe2ItPaV9bHRfA" guid="-yVwNIxfbtYQjlJdBQ4Y6gg">
    <keyConsiderations>&lt;p>&#xD;
    In some projects that do not involve business or domain modeling, the Glossary is the primary artifact for capturing&#xD;
    information about the project's business domain.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Although listed as an output from, and an input to tasks associated with the requirements discipline, this artifact can&#xD;
    be updated at any time, by any role, as new terms are identified.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The Glossary helps you avoid miscommunication by providing two essential resources:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        A central location to look for terms and abbreviations that are new to development team members&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Definitions of terms that are used in specific ways within the domain&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Definitions for the Glossary terms come from several sources, such as requirements documents, specifications, and&#xD;
    discussions with Stakeholders and domain experts.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-oAFrdXC539Sh02kUXgHTjQ" name="vision,_mp6117o8Ee2ItPaV9bHRfA" guid="-oAFrdXC539Sh02kUXgHTjQ">
    <keyConsiderations>&lt;p>&#xD;
    It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make&#xD;
    the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important&#xD;
    features and avoiding details of requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Projects that focus on product development might extend the marketing section and include a more detailed product&#xD;
    position statement that is based on their needs and research.&#xD;
&lt;/p></keyConsiderations>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-jpyi1uh-66Yb1u_w-ia5hg" name="work_item_pool,_mqdBUbo8Ee2ItPaV9bHRfA" guid="-jpyi1uh-66Yb1u_w-ia5hg">
    <refinedDescription>The pool of Requirements, Bugs, Tutorials, Support, Fixed Delivery Date and Intangilble items.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-GjnFEO1B_f5CA2ZMEf4hFA" name="task_board,_mqdoYbo8Ee2ItPaV9bHRfA" guid="-GjnFEO1B_f5CA2ZMEf4hFA">
    <refinedDescription>&lt;p>&#xD;
    The task board shows all the work the team is&amp;nbsp;doing during a sprint or daily work. It is updated&amp;nbsp;continuously&#xD;
    throughout the sprint–if someone thinks of a new task they&amp;nbsp;write a new card and puts it on the board. Either&#xD;
    during or before Daily Meeting, estimates are changed (up or down) and cards are moved around the board.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task board might look like this:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;img style=&quot;HEIGHT: 336px; WIDTH: 461px&quot; alt=&quot;&quot; src=&quot;./../../waad/workproducts/./resources/MockedTaskBoard.jpg&quot;&#xD;
    width=&quot;600&quot; height=&quot;447&quot; />&lt;a&#xD; 
    href=&quot;http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg&quot; >&lt;u>&lt;font&#xD;
    color=&quot;#0000ff&quot;>&amp;nbsp;&lt;/font>&lt;/u>&lt;/a>&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;br />&#xD;
    &amp;nbsp;&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each row on the task board is a product backlog item (in this&amp;nbsp; particular example stories). During&#xD;
    the&amp;nbsp;planning meeting the team selects thework items they can complete during the coming sprint or day.&#xD;
    Each&amp;nbsp;work item is turned into multiple backlog&amp;nbsp;items. Each of these is represented by one task card that is&#xD;
    placed on the task board. Each task card starts on the task board in the “To Do” column. The columns are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Story&lt;/b>–The story description (“As a user I want to…”) shown on that row.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Do&lt;/b>–This holds all the cards that are not done or in process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Work In Process&lt;/b>–Any card being worked on goes here. The programmer who chooses to work on it moves it over&#xD;
        when she’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work&#xD;
        on the boojum today.”&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Verify&lt;/b>–A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card&#xD;
        there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the&#xD;
        boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards&#xD;
        (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Done&lt;/b>–Cards pile up over here when they’re done. They’re removed at the end of the sprint.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
</xmi:XMI>
