<?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="-VZlclEsm_7EUqLchBTaFjg" name="Epilogue,_OlGYUbbCEe2Dueyuhp6-0w" guid="-VZlclEsm_7EUqLchBTaFjg">
    <mainDescription>The project start by form a team</mainDescription>
  </org.eclipse.epf.uma:ProcessDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-ZobjgJ8j97BqwKXHbONeRg" name="architect,_fylfX7eDEe2Dueyuhp6-0w" guid="-ZobjgJ8j97BqwKXHbONeRg">
    <refinedDescription>&lt;p>&#xD;
    The person in this role leads or coordinates the technical design of the system and has overall responsibility for&#xD;
    facilitating the major technical decisions expressed as software architecture. This typically includes identifying and&#xD;
    documenting the architecturally significant aspects of the system as views that describe requirements, design,&#xD;
    implementation, and deployment.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various&#xD;
    stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and&#xD;
    followed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This role works closely with project managers in staffing and planning the project, because it is recommended&#xD;
    that the team be organized around the architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This role also works closely with analysts and developers to make sure that the architecturally significant&#xD;
    requirements are assigned to the proper components of the system. &#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-NcWdlHfeTC8AHiKgivF3_g" name="tester,_fylfaLeDEe2Dueyuhp6-0w" guid="-NcWdlHfeTC8AHiKgivF3_g">
    <refinedDescription>&lt;p>&#xD;
    The person in this role is primarily responsible for the following tasks:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Identifying the tests that need to be performed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Identifying the most appropriate implementation approach for a given test&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Implementing individual tests&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Setting up and running the tests&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Logging outcomes and verifying that the tests have been run&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Analyzing and guiding the recovery from execution errors&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Communicating test results to the team&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-mWPgqZqZvy5nvRzbhgnB8g" name="vision,_fy5BUreDEe2Dueyuhp6-0w" guid="-mWPgqZqZvy5nvRzbhgnB8g">
    <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="-PNZgP9bllfv4YAJYGexyHA" name="developer_test,_fzL8QbeDEe2Dueyuhp6-0w" guid="-PNZgP9bllfv4YAJYGexyHA">
    <refinedDescription>&lt;p>&#xD;
    This artifact covers all of the steps to validate a specific aspect of an implementation element. For example, a test&#xD;
    could ensure that the parameters of a method properly accept the uppermost and lowermost required values. A developer&#xD;
    test specifies test entries, execution conditions, and expected results. These details are identified to evaluate a&#xD;
    particular aspect of a scenario.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When you collect developer tests for a specific implementation element, you can validate that the element performs as&#xD;
    specified.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The tests be self-documenting so that it is clear upon completion of the test whether the implementation element has&#xD;
    run correctly.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-uDSazt3QwulLX0FS-4tyTQ" name="implementation,_fzL8RLeDEe2Dueyuhp6-0w" guid="-uDSazt3QwulLX0FS-4tyTQ">
    <refinedDescription>&lt;p>&#xD;
    This artifact is the collection of one or more of these elements:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Source code files&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Data files&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Build scripts&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Other files that are transformed into the executable system&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-JV_KDY-3Npsw20D16wCHRQ" name="build,_fzL8R7eDEe2Dueyuhp6-0w" guid="-JV_KDY-3Npsw20D16wCHRQ">
    <refinedDescription>&lt;p>&#xD;
    This working version of the system or part of the system&amp;nbsp;is the result of putting the implementation through a&#xD;
    build process (typically an automated build script) that creates an executable version, or one that runs. This&#xD;
    executable version will typically have a number of supporting files that are also considered part of this artifact.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-2cUtkgrOZeM5b1L9fqA7wQ" name="design,_fzL8SreDEe2Dueyuhp6-0w" guid="-2cUtkgrOZeM5b1L9fqA7wQ">
    <refinedDescription>&lt;p>&#xD;
    This work product describes the elements that will make up the implemented system. It communicates abstractions of&#xD;
    particular portions of the implementation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    While architecture focuses on interfaces, patterns, and key decisions, the design fleshes out the technical details in&#xD;
    readiness for implementation, or as part of implementation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This product can describe multiple static and dynamic views of the system for examination. Although various views may&#xD;
    focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit&#xD;
    together without contradiction.&lt;br />&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-tuIyBvkoD75FiwUBAJKBtQ" name="test_case,_fzbz4beDEe2Dueyuhp6-0w" guid="-tuIyBvkoD75FiwUBAJKBtQ">
    <refinedDescription>&lt;p>&#xD;
    A test case specifies the conditions that must be validated to enable an assessment of aspects of the system under&#xD;
    test. A test case is more formal than a test idea; typically, a test case takes the form of a specification. In less&#xD;
    formal environments, you can create test cases by identifying a unique ID, name, associated test data, and expected&#xD;
    results.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Test cases can be derived from many sources, and typically include a subset of the requirements (such as use cases,&#xD;
    performance characteristics, and reliability concerns) and other types of quality attributes. For more information on&#xD;
    types of tests and their relationships to quality test attributes, see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts_CAE80710.html&quot;&#xD;
    guid=&quot;_0aJ6cMlgEdmt3adZL5Dmdw&quot;>Concept: Testing Qualitative Requirements&lt;/a>.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-R4-TTxCZe0mFBF-FjV-iIQ" name="test_log,_fzbz5LeDEe2Dueyuhp6-0w" guid="-R4-TTxCZe0mFBF-FjV-iIQ">
    <refinedDescription>This artifact provides a detailed, typically time-based record that both verifies that a set of tests were run, and&#xD;
provides information that relates to the success of those tests. The focus is typically on providing an accurate audit&#xD;
trail, which enables you to undertake a post-run diagnosis of failures. This raw data is subsequently analyzed to determine&#xD;
the results of an aspect of the test effort.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-bslS8eEiCSBGhU8-k7PT1Q" name="architecture_notebook,_fzfeRLeDEe2Dueyuhp6-0w" guid="-bslS8eEiCSBGhU8-k7PT1Q">
    <refinedDescription>&lt;p>&#xD;
    This artifact&amp;nbsp;describes the &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html&quot;&#xD;
    guid=&quot;__O7tAMVvEduLYZUGfgZrkQ&quot;>Software Architecture&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It provides a place for maintaining the list of architectural issues, along with the associated architectural&#xD;
    decisions, designs, patterns, code documented (or pointed to), and so forth -- all at appropriate levels to make it&#xD;
    easy to understand what architectural decisions have been made and remain to be made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is helpful for architects to use this artifact to collaborate with other team members in developing the architecture&#xD;
    and to help team members understand the motivation behind architectural decisions so that those decisions can be&#xD;
    robustly implemented. For example, the architect may put constraints on how data is packaged and communicated between&#xD;
    different parts of the system. This may appear to be a burden, but the justification in the Architecture Notebook can&#xD;
    explain that there is a significant performance bottleneck when communicating with a legacy system. The rest of the&#xD;
    system must adapt to this bottleneck by following a specific data packaging scheme.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This artifact should also inform the team members how the system is partitioned or organized so that the team can adapt&#xD;
    to the needs of the system. It also gives a first glimpse of the system and its technical motivations to whoever must&#xD;
    maintain and change the architecture later.&lt;br />&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-DskV-kLAZsO_F1oOolt4lQ" name="dsdm_plan_the_project,_x3WFQLeDEe2Dueyuhp6-0w" guid="-DskV-kLAZsO_F1oOolt4lQ">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
    Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of&#xD;
&#xD;
    the project and make adjustments as&amp;nbsp;necessary.&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>Developing the project plan provides an opportunity for the team to agree on project scope, objectives, initial timeframe,&#xD;
&#xD;
and deliverables. It allows the team to begin demonstrating self-organization by defining success criteria and work&#xD;
&#xD;
practices to be used. Collaboration and consensus by all key project participants is the goal, but the project manager has&#xD;
&#xD;
ultimate responsibility for ensuring that everybody is committed to the plan.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-j9T2agVLTd1ZWHRJ7zvYig" name="project_manager,_x3WFQbeDEe2Dueyuhp6-0w" guid="-j9T2agVLTd1ZWHRJ7zvYig">
    <refinedDescription>&lt;p>&#xD;
    This role:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Coaches the team to drive a succesful outcome of the project and the acceptance of the product by the customer.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Is accountable for the outcome of the project and the acceptance of the product by the customer.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Is responsible for the evaluation of project's risks, and controling these risks through mitigation&#xD;
        strategies.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Applies management knowledge, skills, tools and techniques to a broad range of tasks in order to deliver&amp;nbsp;the&#xD;
        desired&amp;nbsp;result for a particular project in a timely fashion.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-Yf_rQM4Da31PX-0nTvUsxQ" name="visionary,_x3WFQ7eDEe2Dueyuhp6-0w" guid="-Yf_rQM4Da31PX-0nTvUsxQ">
    <keyConsiderations>&lt;p>&#xD;
    The Visionary has the high-level view of the original reasons for initiating the project: this must not be dissipated&#xD;
    during development. Unfortunately, this happens in many projects. It is very easy once development is under way to&#xD;
    involve only those staff who will use the computer system on a day-to-day basis but who, perhaps, do not fully&#xD;
    understand all the business vision. This can result in a dilution of the original goals and a tendency towards simply&#xD;
    re-specifying the system to be replaced. It is imperative that the Visionary is present when important user events&#xD;
    occur or when management decisions about the progress of the project are made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary must commit business staff to the project as &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/ambassador_user.html&quot; guid=&quot;_ctbZ8FkVEdul8L-IGeA7TA&quot;>Ambassador User&lt;/a>(s). These people should be available to the project on a continuous basis throughout the life of the project -&#xD;
    not necessarily full-time but &quot;contracts&quot; for the Ambassador Users time should be agreed with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a> before leaving the Business Study phase, e.g. &quot;Ambassador User X&#xD;
    will work in the project team every Monday, Wednesday and Friday morning&quot;. The &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/advisor_user.html&quot; guid=&quot;_avOA0FkVEdul8L-IGeA7TA&quot;>Advisor User&lt;/a>(s) involvement will be more &lt;em>ad hoc&lt;/em> but should be well planned in advance.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The Visionary is a business role. The Visionary is the one who is usually responsible for getting a project started&#xD;
    through enthusiasm and commitment to the idea and business goals. The Visionary should remain involved throughout the&#xD;
    design and delivery process to ensure the original objectives are being met. If any issues arise during the project,&#xD;
    which must be considered by higher management, the Visionary will either provide the decision or provide higher&#xD;
    management with the business viewpoint.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does&#xD;
    the same from the technical point of view.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Promoting the translation of the vision into working practice&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Taking a wider view of the end-to-end business process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key requirements sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key review sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resolving conflicts across the business areas owned by the Visionary&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user resources are available as needed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Monitoring progress in relation to the original vision&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Commitment and availability throughout the development cycle&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-dh5Uz1CFygWFLl5fa5lbaA" name="ambassador_user,_x3WFRbeDEe2Dueyuhp6-0w" guid="-dh5Uz1CFygWFLl5fa5lbaA">
    <keyConsiderations>&lt;p>&#xD;
    Ambassador Users must be representative of the entire community of users. The whole user community should see them as&#xD;
    such - not just the user management. They must have authority delegated to them to make decisions and to guide the work&#xD;
    of the developers. This is particularly important when considering changes of scope due to time limitations.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This role provides the key focus for design decisions. Working closely with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a>, &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/developer.html&quot; guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;>Developer&lt;/a>(s), &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/tester.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;>Tester&lt;/a>(s) and&#xD;
    the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/architect.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a>, the Ambassador User drives the system's requirements, bringing&amp;nbsp;input&#xD;
    and ideas to the various sessions on behalf of the users; and keeping the other users informed of what is happening.&#xD;
    The holder of the Ambassador User role must have the desire, authority, responsibility and knowledge to be able to&#xD;
    ensure that the right system is built for the business. This does not necessarily imply a senior position within the&#xD;
    organisation, but a level of empowerment during the project to fulfil the role and a clear allocation of time to&#xD;
    participate in the project as required.&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h2>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Providing key input to business requirements and design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Communicating with other users and getting their agreement&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Providing input into prototyping sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reviewing documentation&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reviewing and accepting delivered software&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Providing user documentation&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user training is adequately carried out&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Organising and controlling user testing&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-0hjgh30iYOZJO5EXtNOePQ" name="vision,_x3eBELeDEe2Dueyuhp6-0w" guid="-0hjgh30iYOZJO5EXtNOePQ">
    <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="-0MY4ogCqTD62MJgk5SKKcQ" name="work_items_list,_x3eBEreDEe2Dueyuhp6-0w" guid="-0MY4ogCqTD62MJgk5SKKcQ">
    <refinedDescription>&lt;p>&#xD;
    This artifact provides a focal point for the entire team:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It provides one list containing all requests for additional capabilities or enhancement for that application. Note&#xD;
        that some of these requests may never be implemented, or be implemented in later projects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list&#xD;
        is prioritized separately.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one place to go to for the development team to understand what &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../openup/guidances/concepts/micro_increments.html&quot;&#xD;
        guid=&quot;_S80VwCNbEdyCq8v2ZO4QcA&quot;>Micro-Increments&lt;/a>&amp;nbsp;need to be delivered, get references to material required&#xD;
        to carry out the work, and one place to go to report progress made.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These are the typical work items that go into this list:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Use cases (and references to use-case specifications)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Supporting requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Changes and enhancement requests&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development tasks&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Work items can be very large in scope, especially when capturing requests for enhancements, such as “Support Financial&#xD;
    Planning” for a personal finance application. To allow the application to be developed in micro-increments, work items&#xD;
    are analyzed and broken down into smaller work items so they can be assigned to an iteration, such as a use-case&#xD;
    scenario for&amp;nbsp;“Calculate Net Worth”. Further breakdown may be required to identify suitable tasks to be assigned to&#xD;
    developers, such as “Develop UI for Calculate Net Worth”. This means that work items often have parent/child&#xD;
    relationships, where the lowest level is a specification and tracking device for micro-increments.&#xD;
&lt;/p>&lt;p/>&lt;p>&#xD;
    Work Items should contain estimates, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/work_items_list_32AC6ABD.html&quot; guid=&quot;_7vEXEMA4EdqSgKaj2SZBmg&quot;>Guideline: Managing Work Items&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-c1TbrKMaPTgDwM1hgZ8IFw" name="project_plan,_x3eBFLeDEe2Dueyuhp6-0w" guid="-c1TbrKMaPTgDwM1hgZ8IFw">
    <refinedDescription>&lt;p>&#xD;
    &lt;span style=&quot;FONT-SIZE: 10pt; mso-bidi-font-family: Arial&quot;>This artifact&amp;nbsp;defines the parameters for project&#xD;
    progress tracking and specifies the high-level objectives of the iterations and their milestones. Additionally,&amp;nbsp;it&#xD;
    describes how the project is organized and which roles are played by whom.&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span style=&quot;FONT-SIZE: 10pt; mso-bidi-font-family: Arial&quot;>The project manager is responsible for developing the&#xD;
    project plan, working very closely with the rest of the team. The project plan allows stakeholders and other team&#xD;
    members to understand the big picture and, roughly, when to expect what level of functionality. It it also used for&#xD;
    recording the lessons learned from the project.&lt;/span>&lt;span style=&quot;FONT-SIZE: 10pt; mso-bidi-font-family: Arial&quot;>&lt;br />&#xD;
    &lt;/span>&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-IYeDjU12vkjSTbuGOfEmRw" name="risk_list,_x3eBFreDEe2Dueyuhp6-0w" guid="-IYeDjU12vkjSTbuGOfEmRw">
    <keyConsiderations>&lt;p>&#xD;
    This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider&#xD;
    whether they are really serious risks. Tracking more than 20 risks is an onerous task.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This list identifies, in decreasing order of priority, all the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup/guidances/termdefinitions/risk_33255339.html&quot; guid=&quot;_ii2LUEvGEdunZcj9T5hrMQ&quot;>risks&lt;/a> associated to a project.&amp;nbsp;It serves as a focal point for project&#xD;
    activities and is the basis around which iterations are organized.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/concepts/risk_AF5840DA.html&quot; guid=&quot;_0bsLgMlgEdmt3adZL5Dmdw&quot;>Concept: Risk&lt;/a>&amp;nbsp;for more details.&lt;!--EndFragment-->&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-kkuGChDNWa_QmTUP6khjyA" name="iteration_plan,_x3nyFLeDEe2Dueyuhp6-0w" guid="-kkuGChDNWa_QmTUP6khjyA">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
    Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work&#xD;
&#xD;
    Items List, the iteration plan may end up having work items with different priorities (for example, you assign the&#xD;
&#xD;
    remaining high priority work items, plus a few mid priority ones from the Work Items List). No matter what previous&#xD;
&#xD;
    priorities the work items had, when assigned to an iteration&amp;nbsp;the team has to make sure they are able to develop&#xD;
&#xD;
    what has been&amp;nbsp;assigned to the&amp;nbsp;iteration, and deciding on&amp;nbsp;what to&amp;nbsp;develop first (or&#xD;
&#xD;
    even&amp;nbsp;develop things in parallel) on an iteration will vary from project to project, from iteration to iteration.&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The main objectives of the iteration plan is to provide the team with one central place for information regarding&#xD;
    iteration objectives, detailed plan with task assignments, and evaluation results. This artifact also helps the team to&#xD;
    monitor the progress of the iteration and keeps the results of the iteration assessment that may be usefull for&#xD;
    improving the next one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task assignments for an iteration is a subset of all tasks on the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Artifact: Work Items List&lt;/a>, therefore the iteration plan ideally references those work items.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-BtTf6-ac9diuDqK595cUvg" name="dsdm_vision,_x3w8A7eDEe2Dueyuhp6-0w" guid="-BtTf6-ac9diuDqK595cUvg">
    <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="-YQIYnXAJ8IlppWAu8MNrVQ" name="dsdm_find_and_outline_requirements,_wATrILeDEe2Dueyuhp6-0w" guid="-YQIYnXAJ8IlppWAu8MNrVQ">
    <keyConsiderations>&lt;p>&#xD;
    The &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/ambassador_user.html&quot; guid=&quot;_ctbZ8FkVEdul8L-IGeA7TA&quot;>Ambassador User&lt;/a> should take the lead in this task, deferring to the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/analyst.html&quot; guid=&quot;_0VxJsMlgEdmt3adZL5Dmdw&quot;>Analyst&lt;/a>&amp;nbsp;where specific requirements management techniques and expertise are&#xD;
    required.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Ambassador User has overall responsibility for agreeing the precise scope and priority of the&#xD;
    requirements.&amp;nbsp;The &lt;u>&lt;font color=&quot;#800080&quot;>&lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/advisor_user.html&quot; guid=&quot;_avOA0FkVEdul8L-IGeA7TA&quot;>Advisor User&lt;/a>(&lt;/font>&lt;/u>s) and other stakeholders will provide&amp;nbsp;additional&amp;nbsp;sources of requirements. The Analyst&#xD;
    will render the requirements into a format that enables software to be developed and tested. The &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/visionary.html&quot; guid=&quot;_hQJ-QFkVEdul8L-IGeA7TA&quot;>Visionary&lt;/a>&#xD;
    will verify that the scope of the requirements supports the &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/workproducts/dsdm_vision.html&quot; guid=&quot;_uotsEFkbEdul8L-IGeA7TA&quot;>Vision&lt;/a>.&#xD;
&lt;/p></keyConsiderations>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-pA3S-cw4l8XvYRAivTj_5g" name="advisor_user,_wATrI7eDEe2Dueyuhp6-0w" guid="-pA3S-cw4l8XvYRAivTj_5g">
    <keyConsiderations>&lt;p>&#xD;
    The Advisor User role may be held by a panel of people who attend workshops and workshop-style presentations of&#xD;
    prototypes. In this way the breadth of user experiences can be captured in a dynamic environment.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Outside pre-arranged events, the &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/ambassador_user.html&quot; guid=&quot;_ctbZ8FkVEdul8L-IGeA7TA&quot;>Ambassador User&lt;/a> role provides the two-way channel for information about the project to the Advisor Users.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;ul>&#xD;
    &lt;li>&#xD;
        Providing information on request&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Participation in the prototyping and review processes offering advice and guidance on issues of practical import&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Approval of designs and prototypes as acceptable for use&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Assisting with business and usability testing.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-2h9dGfxV73YGCUn-0Uh3RA" name="visionary,_wATrJbeDEe2Dueyuhp6-0w" guid="-2h9dGfxV73YGCUn-0Uh3RA">
    <keyConsiderations>&lt;p>&#xD;
    The Visionary has the high-level view of the original reasons for initiating the project: this must not be dissipated&#xD;
    during development. Unfortunately, this happens in many projects. It is very easy once development is under way to&#xD;
    involve only those staff who will use the computer system on a day-to-day basis but who, perhaps, do not fully&#xD;
    understand all the business vision. This can result in a dilution of the original goals and a tendency towards simply&#xD;
    re-specifying the system to be replaced. It is imperative that the Visionary is present when important user events&#xD;
    occur or when management decisions about the progress of the project are made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary must commit business staff to the project as &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/ambassador_user.html&quot; guid=&quot;_ctbZ8FkVEdul8L-IGeA7TA&quot;>Ambassador User&lt;/a>(s). These people should be available to the project on a continuous basis throughout the life of the project -&#xD;
    not necessarily full-time but &quot;contracts&quot; for the Ambassador Users time should be agreed with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a> before leaving the Business Study phase, e.g. &quot;Ambassador User X&#xD;
    will work in the project team every Monday, Wednesday and Friday morning&quot;. The &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/advisor_user.html&quot; guid=&quot;_avOA0FkVEdul8L-IGeA7TA&quot;>Advisor User&lt;/a>(s) involvement will be more &lt;em>ad hoc&lt;/em> but should be well planned in advance.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The Visionary is a business role. The Visionary is the one who is usually responsible for getting a project started&#xD;
    through enthusiasm and commitment to the idea and business goals. The Visionary should remain involved throughout the&#xD;
    design and delivery process to ensure the original objectives are being met. If any issues arise during the project,&#xD;
    which must be considered by higher management, the Visionary will either provide the decision or provide higher&#xD;
    management with the business viewpoint.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does&#xD;
    the same from the technical point of view.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Promoting the translation of the vision into working practice&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Taking a wider view of the end-to-end business process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key requirements sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key review sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resolving conflicts across the business areas owned by the Visionary&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user resources are available as needed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Monitoring progress in relation to the original vision&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Commitment and availability throughout the development cycle&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-gn5NPgRl8ZMtCZXfnmNQhw" name="ambassador_user,_wATrJ7eDEe2Dueyuhp6-0w" guid="-gn5NPgRl8ZMtCZXfnmNQhw">
    <keyConsiderations>&lt;p>&#xD;
    Ambassador Users must be representative of the entire community of users. The whole user community should see them as&#xD;
    such - not just the user management. They must have authority delegated to them to make decisions and to guide the work&#xD;
    of the developers. This is particularly important when considering changes of scope due to time limitations.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This role provides the key focus for design decisions. Working closely with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a>, &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/developer.html&quot; guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;>Developer&lt;/a>(s), &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/tester.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;>Tester&lt;/a>(s) and&#xD;
    the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/architect.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a>, the Ambassador User drives the system's requirements, bringing&amp;nbsp;input&#xD;
    and ideas to the various sessions on behalf of the users; and keeping the other users informed of what is happening.&#xD;
    The holder of the Ambassador User role must have the desire, authority, responsibility and knowledge to be able to&#xD;
    ensure that the right system is built for the business. This does not necessarily imply a senior position within the&#xD;
    organisation, but a level of empowerment during the project to fulfil the role and a clear allocation of time to&#xD;
    participate in the project as required.&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h2>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Providing key input to business requirements and design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Communicating with other users and getting their agreement&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Providing input into prototyping sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reviewing documentation&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reviewing and accepting delivered software&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Providing user documentation&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user training is adequately carried out&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Organising and controlling user testing&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-bKhfPi3JmV0WGLbL9OZ06g" name="glossary,_wATrKbeDEe2Dueyuhp6-0w" guid="-bKhfPi3JmV0WGLbL9OZ06g">
    <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="-sNnghg8T0QW-awcxji42Og" name="vision,_wATrK7eDEe2Dueyuhp6-0w" guid="-sNnghg8T0QW-awcxji42Og">
    <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="-7zhYvF1Ii8NnHp9ZplWaIA" name="work_items_list,_wATrLbeDEe2Dueyuhp6-0w" guid="-7zhYvF1Ii8NnHp9ZplWaIA">
    <refinedDescription>&lt;p>&#xD;
    This artifact provides a focal point for the entire team:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It provides one list containing all requests for additional capabilities or enhancement for that application. Note&#xD;
        that some of these requests may never be implemented, or be implemented in later projects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list&#xD;
        is prioritized separately.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one place to go to for the development team to understand what &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../openup/guidances/concepts/micro_increments.html&quot;&#xD;
        guid=&quot;_S80VwCNbEdyCq8v2ZO4QcA&quot;>Micro-Increments&lt;/a>&amp;nbsp;need to be delivered, get references to material required&#xD;
        to carry out the work, and one place to go to report progress made.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These are the typical work items that go into this list:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Use cases (and references to use-case specifications)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Supporting requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Changes and enhancement requests&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development tasks&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Work items can be very large in scope, especially when capturing requests for enhancements, such as “Support Financial&#xD;
    Planning” for a personal finance application. To allow the application to be developed in micro-increments, work items&#xD;
    are analyzed and broken down into smaller work items so they can be assigned to an iteration, such as a use-case&#xD;
    scenario for&amp;nbsp;“Calculate Net Worth”. Further breakdown may be required to identify suitable tasks to be assigned to&#xD;
    developers, such as “Develop UI for Calculate Net Worth”. This means that work items often have parent/child&#xD;
    relationships, where the lowest level is a specification and tracking device for micro-increments.&#xD;
&lt;/p>&lt;p/>&lt;p>&#xD;
    Work Items should contain estimates, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/work_items_list_32AC6ABD.html&quot; guid=&quot;_7vEXEMA4EdqSgKaj2SZBmg&quot;>Guideline: Managing Work Items&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-RsRWgeYg22duCDdyw8Q3OQ" name="supporting_requirements_spec,_wATrL7eDEe2Dueyuhp6-0w" guid="-RsRWgeYg22duCDdyw8Q3OQ">
    <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="-JJ0wuww9tBzi0KyFejNLOw" name="dsdm_vision,_wAwXEbeDEe2Dueyuhp6-0w" guid="-JJ0wuww9tBzi0KyFejNLOw">
    <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="-v4w20vK8wZHuU1Tbeu11kw" name="iteration_plan,_WSsA8beEEe2Dueyuhp6-0w" guid="-v4w20vK8wZHuU1Tbeu11kw">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
    Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work&#xD;
&#xD;
    Items List, the iteration plan may end up having work items with different priorities (for example, you assign the&#xD;
&#xD;
    remaining high priority work items, plus a few mid priority ones from the Work Items List). No matter what previous&#xD;
&#xD;
    priorities the work items had, when assigned to an iteration&amp;nbsp;the team has to make sure they are able to develop&#xD;
&#xD;
    what has been&amp;nbsp;assigned to the&amp;nbsp;iteration, and deciding on&amp;nbsp;what to&amp;nbsp;develop first (or&#xD;
&#xD;
    even&amp;nbsp;develop things in parallel) on an iteration will vary from project to project, from iteration to iteration.&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The main objectives of the iteration plan is to provide the team with one central place for information regarding&#xD;
    iteration objectives, detailed plan with task assignments, and evaluation results. This artifact also helps the team to&#xD;
    monitor the progress of the iteration and keeps the results of the iteration assessment that may be usefull for&#xD;
    improving the next one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task assignments for an iteration is a subset of all tasks on the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Artifact: Work Items List&lt;/a>, therefore the iteration plan ideally references those work items.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-syEdKj5VXSf3JMi_pCymCQ" name="dsdm_vision,_WSsA9beEEe2Dueyuhp6-0w" guid="-syEdKj5VXSf3JMi_pCymCQ">
    <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="-ZT1N4imiJUMQ_bvwLyqCOQ" name="dsdm_vision,_WTIs4beEEe2Dueyuhp6-0w" guid="-ZT1N4imiJUMQ_bvwLyqCOQ">
    <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="-6q8R_ErTNCEKFP4DG08cIQ" name="dsdm_outline_the_architecture,_jWq_MLeFEe2Dueyuhp6-0w" guid="-6q8R_ErTNCEKFP4DG08cIQ">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
&#xD;
&#xD;
    This task&amp;nbsp;is most beneficial when developing new and unprecedented systems. In systems where there is already a&#xD;
&#xD;
&#xD;
&#xD;
    well-defined architecture, this task might be omitted, or performed quickly as a&amp;nbsp;review of the existing&#xD;
&#xD;
&#xD;
&#xD;
    architecture.&#xD;
&#xD;
&#xD;
&#xD;
&lt;/p>&#xD;
&#xD;
&#xD;
&#xD;
&lt;p>&#xD;
&#xD;
&#xD;
&#xD;
    It is critical that this task is performed collaboratively with active involvement of other team members and project&#xD;
&#xD;
&#xD;
&#xD;
    stakeholders so that consensus and common understanding is reached. It is particularly vital for the architect to&#xD;
&#xD;
&#xD;
&#xD;
    involve the developer(s) throughout this task. The architecture effort&amp;nbsp;is about providing leadership and&#xD;
&#xD;
&#xD;
&#xD;
    coordination of the technical work rather than putting in a solo performance.&#xD;
&#xD;
&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
&#xD;
&#xD;
    This task focuses on identifying the architectural goals for an iteration that will guide development and testing. It&#xD;
&#xD;
&#xD;
    relies on gathering experience gained in similar systems or problem domains to constrain and focus the architecture so&#xD;
&#xD;
&#xD;
    that effort is not wasted in re-inventing architecture.&#xD;
&#xD;
&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-IsQlLt_Wq8X5H4BUCdnHNw" name="architect,_jWq_MbeFEe2Dueyuhp6-0w" guid="-IsQlLt_Wq8X5H4BUCdnHNw">
    <keyConsiderations>This role&amp;nbsp;places emphasis on the core principle &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup/guidances/concepts/core_principle_focus_346C6FAF.html&quot; guid=&quot;_9gocwMvoEdqukPpotm3DYg&quot;>Focus on the architecture early to minimize risks and organize development&lt;/a>.</keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This role leads or coordinates the technical design of the system and has overall responsibility for facilitating the&#xD;
    major technical decisions expressed as software architecture. This typically includes identifying and documenting the&#xD;
    architecturally significant aspects of the system as views that describe requirements, design, implementation, and&#xD;
    deployment.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This role is also responsible for providing the rationale for these decisions, balancing the concerns of the various&#xD;
    stakeholders, reducing technical risks, and ensuring that decisions are effectively communicated, validated, and&#xD;
    followed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This role is closely involved in organizing the team around the architecture by working closely with the&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../openup/roles/project_manager_E657F936.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a>&amp;nbsp;in staffing and planning the project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-AxkPa_qKHvrbYbFKd1jU1Q" name="ambassador_user,_jWq_M7eFEe2Dueyuhp6-0w" guid="-AxkPa_qKHvrbYbFKd1jU1Q">
    <keyConsiderations>&lt;p>&#xD;
    Ambassador Users must be representative of the entire community of users. The whole user community should see them as&#xD;
    such - not just the user management. They must have authority delegated to them to make decisions and to guide the work&#xD;
    of the developers. This is particularly important when considering changes of scope due to time limitations.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This role provides the key focus for design decisions. Working closely with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a>, &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/developer.html&quot; guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;>Developer&lt;/a>(s), &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/tester.html&quot; guid=&quot;_0ZM4MclgEdmt3adZL5Dmdw&quot;>Tester&lt;/a>(s) and&#xD;
    the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/architect.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a>, the Ambassador User drives the system's requirements, bringing&amp;nbsp;input&#xD;
    and ideas to the various sessions on behalf of the users; and keeping the other users informed of what is happening.&#xD;
    The holder of the Ambassador User role must have the desire, authority, responsibility and knowledge to be able to&#xD;
    ensure that the right system is built for the business. This does not necessarily imply a senior position within the&#xD;
    organisation, but a level of empowerment during the project to fulfil the role and a clear allocation of time to&#xD;
    participate in the project as required.&#xD;
&lt;/p>&#xD;
&lt;h2>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h2>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Providing key input to business requirements and design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Communicating with other users and getting their agreement&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Providing input into prototyping sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reviewing documentation&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Reviewing and accepting delivered software&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Providing user documentation&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user training is adequately carried out&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Organising and controlling user testing&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-fidC3JCnJCm3eK5eHAo02w" name="visionary,_jWq_NbeFEe2Dueyuhp6-0w" guid="-fidC3JCnJCm3eK5eHAo02w">
    <keyConsiderations>&lt;p>&#xD;
    The Visionary has the high-level view of the original reasons for initiating the project: this must not be dissipated&#xD;
    during development. Unfortunately, this happens in many projects. It is very easy once development is under way to&#xD;
    involve only those staff who will use the computer system on a day-to-day basis but who, perhaps, do not fully&#xD;
    understand all the business vision. This can result in a dilution of the original goals and a tendency towards simply&#xD;
    re-specifying the system to be replaced. It is imperative that the Visionary is present when important user events&#xD;
    occur or when management decisions about the progress of the project are made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary must commit business staff to the project as &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/ambassador_user.html&quot; guid=&quot;_ctbZ8FkVEdul8L-IGeA7TA&quot;>Ambassador User&lt;/a>(s). These people should be available to the project on a continuous basis throughout the life of the project -&#xD;
    not necessarily full-time but &quot;contracts&quot; for the Ambassador Users time should be agreed with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a> before leaving the Business Study phase, e.g. &quot;Ambassador User X&#xD;
    will work in the project team every Monday, Wednesday and Friday morning&quot;. The &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/advisor_user.html&quot; guid=&quot;_avOA0FkVEdul8L-IGeA7TA&quot;>Advisor User&lt;/a>(s) involvement will be more &lt;em>ad hoc&lt;/em> but should be well planned in advance.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The Visionary is a business role. The Visionary is the one who is usually responsible for getting a project started&#xD;
    through enthusiasm and commitment to the idea and business goals. The Visionary should remain involved throughout the&#xD;
    design and delivery process to ensure the original objectives are being met. If any issues arise during the project,&#xD;
    which must be considered by higher management, the Visionary will either provide the decision or provide higher&#xD;
    management with the business viewpoint.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does&#xD;
    the same from the technical point of view.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Promoting the translation of the vision into working practice&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Taking a wider view of the end-to-end business process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key requirements sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key review sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resolving conflicts across the business areas owned by the Visionary&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user resources are available as needed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Monitoring progress in relation to the original vision&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Commitment and availability throughout the development cycle&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-qeC6wCvHpwtKRifk-CrRdQ" name="glossary,_jWq_N7eFEe2Dueyuhp6-0w" guid="-qeC6wCvHpwtKRifk-CrRdQ">
    <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="-DMqnwTCskl2D_gC3Yz8Atw" name="vision,_jWq_ObeFEe2Dueyuhp6-0w" guid="-DMqnwTCskl2D_gC3Yz8Atw">
    <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="-gFSdvNqcLImKGl8ZMypZeQ" name="architecture_notebook,_jWq_O7eFEe2Dueyuhp6-0w" guid="-gFSdvNqcLImKGl8ZMypZeQ">
    <refinedDescription>&lt;p>&#xD;
    This artifact gives context and guidance for developers to construct the system. It's a critical artifact used to help&#xD;
    capture and make architectural decisions, and explain those decisions to developers. It can contain any information and&#xD;
    references that are appropriate in communicating how developers should build the system. It generally doesn't contain&#xD;
    design information, although it will likely reference architecturally significant design elements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At a minimum, this artifact should:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        List guidance, decisions, and constraints the developers must follow in building the system&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Justify those guidelines, decisions and constraints&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Describe the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup/guidances/concepts/arch_mech_2932DFB6.html&quot; guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;>Architectural Mechanism&lt;/a>s and where they should be applied.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Team members who were not involved in those archtiectural decisions need to understand the reasoning behind&#xD;
    the&amp;nbsp;context of the architecture so they can best address the needs of the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Other recommended content is:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        References to architecturally significant requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        References to architecturally significant design elements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Packaging instructions for subsystems and components&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Layers and critical subsystems&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Critical system interfaces&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Key abstractions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Important analysis classes&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Key scenarios that describe critical behavior of the system&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Architects should use this artifact to collaborate with other team members in developing the architecture, and to help&#xD;
    team members understand the motivations behind architectural decisions so those decisions can be robustly implemented.&#xD;
    For example, the architect may place constraints on how data is packaged and communicated between different parts of&#xD;
    the system. This may appear to be a burden, but the justification in the Architecture Notebook can explain that there&#xD;
    is a significant performance bottleneck when communicating with a legacy system. The rest of the system must adapt to&#xD;
    this bottleneck by following a specific data packaging scheme.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This artifact should also inform the Project Manager and other team members how the system is partitioned or organized&#xD;
    so the team can adapt itself to the needs of the system. It also gives whoever must maintain and change the&#xD;
    architecture later their first glimpse of the system and its technical motivations.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This artifact is distinct from the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup/guidances/concepts/executable_architecture_D4E68CBD.html&quot; guid=&quot;_O1kAANvfEduv2KOT-Teh6w&quot;>Executable Architecture&lt;/a>. This artifact describes how the system should be&#xD;
    constructed, while the Executable Architecture is a build that contains part of the validated architecture.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-Fa4VbMeXNEvELVEk7nGKLA" name="supporting_requirements_spec,_jWq_P7eFEe2Dueyuhp6-0w" guid="-Fa4VbMeXNEvELVEk7nGKLA">
    <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="-jMzTkB9tStzMBv-G4WpbuQ" name="dsdm_vision,_jW-hM7eFEe2Dueyuhp6-0w" guid="-jMzTkB9tStzMBv-G4WpbuQ">
    <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="-y4cr8LHUUNsce3Au2lpcjQ" name="Form Team,_SvhxULeGEe2Dueyuhp6-0w" guid="-y4cr8LHUUNsce3Au2lpcjQ"/>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-7Vq8b5Jpnm_GmKVsI-1eKw" name="project_manager,_AgEFULeIEe2ItPaV9bHRfA" guid="-7Vq8b5Jpnm_GmKVsI-1eKw">
    <refinedDescription>&lt;p>&#xD;
    This role:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Coaches the team to drive a succesful outcome of the project and the acceptance of the product by the customer.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Is accountable for the outcome of the project and the acceptance of the product by the customer.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Is responsible for the evaluation of project's risks, and controling these risks through mitigation&#xD;
        strategies.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Applies management knowledge, skills, tools and techniques to a broad range of tasks in order to deliver&amp;nbsp;the&#xD;
        desired&amp;nbsp;result for a particular project in a timely fashion.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-XFqYUBs87Kf6CIZAUPdeVw" name="iteration_plan,_HYBboreIEe2ItPaV9bHRfA" guid="-XFqYUBs87Kf6CIZAUPdeVw">
    <keyConsiderations>&lt;p>&#xD;
&#xD;
    Work items assigned to an iteration do not necessarily have the same priority. When selecting work items from the Work&#xD;
&#xD;
    Items List, the iteration plan may end up having work items with different priorities (for example, you assign the&#xD;
&#xD;
    remaining high priority work items, plus a few mid priority ones from the Work Items List). No matter what previous&#xD;
&#xD;
    priorities the work items had, when assigned to an iteration&amp;nbsp;the team has to make sure they are able to develop&#xD;
&#xD;
    what has been&amp;nbsp;assigned to the&amp;nbsp;iteration, and deciding on&amp;nbsp;what to&amp;nbsp;develop first (or&#xD;
&#xD;
    even&amp;nbsp;develop things in parallel) on an iteration will vary from project to project, from iteration to iteration.&#xD;
&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The main objectives of the iteration plan is to provide the team with one central place for information regarding&#xD;
    iteration objectives, detailed plan with task assignments, and evaluation results. This artifact also helps the team to&#xD;
    monitor the progress of the iteration and keeps the results of the iteration assessment that may be usefull for&#xD;
    improving the next one.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task assignments for an iteration is a subset of all tasks on the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Artifact: Work Items List&lt;/a>, therefore the iteration plan ideally references those work items.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-tmjTNQhkb9KFLAElsdOJuw" name="work_items_list,_HYBbpbeIEe2ItPaV9bHRfA" guid="-tmjTNQhkb9KFLAElsdOJuw">
    <refinedDescription>&lt;p>&#xD;
    This artifact provides a focal point for the entire team:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        It provides one list containing all requests for additional capabilities or enhancement for that application. Note&#xD;
        that some of these requests may never be implemented, or be implemented in later projects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one list of all the work to be prioritized, estimated, and assigned within the project. The risk list&#xD;
        is prioritized separately.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        It provides one place to go to for the development team to understand what &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../openup/guidances/concepts/micro_increments.html&quot;&#xD;
        guid=&quot;_S80VwCNbEdyCq8v2ZO4QcA&quot;>Micro-Increments&lt;/a>&amp;nbsp;need to be delivered, get references to material required&#xD;
        to carry out the work, and one place to go to report progress made.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These are the typical work items that go into this list:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Use cases (and references to use-case specifications)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Supporting requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Changes and enhancement requests&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Defects&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development tasks&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Work items can be very large in scope, especially when capturing requests for enhancements, such as “Support Financial&#xD;
    Planning” for a personal finance application. To allow the application to be developed in micro-increments, work items&#xD;
    are analyzed and broken down into smaller work items so they can be assigned to an iteration, such as a use-case&#xD;
    scenario for&amp;nbsp;“Calculate Net Worth”. Further breakdown may be required to identify suitable tasks to be assigned to&#xD;
    developers, such as “Develop UI for Calculate Net Worth”. This means that work items often have parent/child&#xD;
    relationships, where the lowest level is a specification and tracking device for micro-increments.&#xD;
&lt;/p>&lt;p/>&lt;p>&#xD;
    Work Items should contain estimates, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/work_items_list_32AC6ABD.html&quot; guid=&quot;_7vEXEMA4EdqSgKaj2SZBmg&quot;>Guideline: Managing Work Items&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-DpqVps97sYG_K1nqQKZz8A" name="project_plan,_HYBbqLeIEe2ItPaV9bHRfA" guid="-DpqVps97sYG_K1nqQKZz8A">
    <refinedDescription>&lt;p>&#xD;
    &lt;span style=&quot;FONT-SIZE: 10pt; mso-bidi-font-family: Arial&quot;>This artifact&amp;nbsp;defines the parameters for project&#xD;
    progress tracking and specifies the high-level objectives of the iterations and their milestones. Additionally,&amp;nbsp;it&#xD;
    describes how the project is organized and which roles are played by whom.&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span style=&quot;FONT-SIZE: 10pt; mso-bidi-font-family: Arial&quot;>The project manager is responsible for developing the&#xD;
    project plan, working very closely with the rest of the team. The project plan allows stakeholders and other team&#xD;
    members to understand the big picture and, roughly, when to expect what level of functionality. It it also used for&#xD;
    recording the lessons learned from the project.&lt;/span>&lt;span style=&quot;FONT-SIZE: 10pt; mso-bidi-font-family: Arial&quot;>&lt;br />&#xD;
    &lt;/span>&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="--4FXXf5WaV7yhxxf-puqTw" name="risk_list,_HYBbq7eIEe2ItPaV9bHRfA" guid="--4FXXf5WaV7yhxxf-puqTw">
    <keyConsiderations>&lt;p>&#xD;
    This list should capture the critical and serious risks. If you find this list extending beyond 20, carefully consider&#xD;
    whether they are really serious risks. Tracking more than 20 risks is an onerous task.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This list identifies, in decreasing order of priority, all the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../openup/guidances/termdefinitions/risk_33255339.html&quot; guid=&quot;_ii2LUEvGEdunZcj9T5hrMQ&quot;>risks&lt;/a> associated to a project.&amp;nbsp;It serves as a focal point for project&#xD;
    activities and is the basis around which iterations are organized.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup/guidances/concepts/risk_AF5840DA.html&quot; guid=&quot;_0bsLgMlgEdmt3adZL5Dmdw&quot;>Concept: Risk&lt;/a>&amp;nbsp;for more details.&lt;!--EndFragment-->&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-A7mz2As9WF4b1grJZ4nwQQ" name="visionary,_4kaLcbeJEe2ItPaV9bHRfA" guid="-A7mz2As9WF4b1grJZ4nwQQ">
    <keyConsiderations>&lt;p>&#xD;
    The Visionary has the high-level view of the original reasons for initiating the project: this must not be dissipated&#xD;
    during development. Unfortunately, this happens in many projects. It is very easy once development is under way to&#xD;
    involve only those staff who will use the computer system on a day-to-day basis but who, perhaps, do not fully&#xD;
    understand all the business vision. This can result in a dilution of the original goals and a tendency towards simply&#xD;
    re-specifying the system to be replaced. It is imperative that the Visionary is present when important user events&#xD;
    occur or when management decisions about the progress of the project are made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary must commit business staff to the project as &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/ambassador_user.html&quot; guid=&quot;_ctbZ8FkVEdul8L-IGeA7TA&quot;>Ambassador User&lt;/a>(s). These people should be available to the project on a continuous basis throughout the life of the project -&#xD;
    not necessarily full-time but &quot;contracts&quot; for the Ambassador Users time should be agreed with the &lt;a class=&quot;elementLink&quot; href=&quot;./../../openup_basic/roles/project_manager.html&quot; guid=&quot;_0a0o0MlgEdmt3adZL5Dmdw&quot;>Project Manager&lt;/a> before leaving the Business Study phase, e.g. &quot;Ambassador User X&#xD;
    will work in the project team every Monday, Wednesday and Friday morning&quot;. The &lt;a class=&quot;elementLink&quot; href=&quot;./../../dsdm_openup/roles/advisor_user.html&quot; guid=&quot;_avOA0FkVEdul8L-IGeA7TA&quot;>Advisor User&lt;/a>(s) involvement will be more &lt;em>ad hoc&lt;/em> but should be well planned in advance.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    The Visionary is a business role. The Visionary is the one who is usually responsible for getting a project started&#xD;
    through enthusiasm and commitment to the idea and business goals. The Visionary should remain involved throughout the&#xD;
    design and delivery process to ensure the original objectives are being met. If any issues arise during the project,&#xD;
    which must be considered by higher management, the Visionary will either provide the decision or provide higher&#xD;
    management with the business viewpoint.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Visionary role ensures the project excellence from the business point of view and the Technical Co-ordinator does&#xD;
    the same from the technical point of view.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Promoting the translation of the vision into working practice&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Taking a wider view of the end-to-end business process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key requirements sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key design sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contributing to key review sessions&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resolving conflicts across the business areas owned by the Visionary&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring user resources are available as needed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Monitoring progress in relation to the original vision&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Commitment and availability throughout the development cycle&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-3lwYGKW_hR9aGvWrWFgFgA" name="exec_sponsor,_4kaLc7eJEe2ItPaV9bHRfA" guid="-3lwYGKW_hR9aGvWrWFgFgA">
    <refinedDescription>&lt;p>&#xD;
    This is a high-level business role. The Executive Sponsor is the &quot;project champion&quot; who is committed to the project,&#xD;
    its approach and wants the system. The role ultimately &quot;owns&quot; the system and has responsibility for it. The Executive&#xD;
    Sponsor must hold a sufficiently high position in the organisation to be able to resolve business issues (e.g. to force&#xD;
    open closed doors) and make financial decisions. This role has a crucial responsibility to ensure and enable fast&#xD;
    progress throughout the project, cutting through the bureaucracy and politics that impede development.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    &lt;a id=&quot;Responsibilities&quot; name=&quot;Responsibilities&quot;>Responsibilities&lt;/a>&#xD;
&lt;/h5>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ensuring the decision-making process for escalated project issues is effective and rapid&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Responding to escalated issues&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ensuring that funds and other resources are made available as needed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Monitoring the continued business case for the project&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Commitment and availability throughout the development cycle.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-GaA8pSC4kmDC8k84iV_2Hw" name="vision,_4kaLd7eJEe2ItPaV9bHRfA" guid="-GaA8pSC4kmDC8k84iV_2Hw">
    <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="-p6FeGpc27L3RDJh7V_Aojg" name="glossary,_4kjVYLeJEe2ItPaV9bHRfA" guid="-p6FeGpc27L3RDJh7V_Aojg">
    <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="-SBJbLzKd4G6WfeFGfY8hMg" name="dsdm_vision,_4ni_A7eJEe2ItPaV9bHRfA" guid="-SBJbLzKd4G6WfeFGfY8hMg">
    <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="-Ny3o63XcnWwMMeNRGcZllA" name="supporting_requirements_spec,_4ni_CreJEe2ItPaV9bHRfA" guid="-Ny3o63XcnWwMMeNRGcZllA">
    <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>
</xmi:XMI>
