| <?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" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1"> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-2VY1Jl_Sw2Mmk8IfX0ONNw" name="identify_and_refine_requirements,_xxcpgdOEEdyqlogshP8l4g" guid="-2VY1Jl_Sw2Mmk8IfX0ONNw" version="7.2.0"/> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-pszgT2UQY1AzlzJLFM1S5g" name="construction_phase_iteration,_RQi0AdONEdyqlogshP8l4g" guid="-pszgT2UQY1AzlzJLFM1S5g" version="7.2.0"> |
| <mainDescription><p> |
| The architecture should be stable when the Construction phase starts, allowing the remaining requirements to be |
| implemented on top of it. Another advantage of validating the architecture and eliminating as many risks as possible |
| during Elaboration is that it provides more predictability in Construction, which allows the project manager to focus |
| on team efficiency and cost reduction. |
| </p> |
| <p> |
| Functionality is continuously implemented, tested, and integrated, resulting in builds that are more and more complete |
| and stable. You may deploy a beta or prerelease to a sampling of the intended audience at the end of Construction. |
| Delivery of the actual release is the main focus of the next phase. |
| </p> |
| <p> |
| The following table summarizes the&nbsp;Construction phase objectives and&nbsp;what activities address each objective: |
| </p> |
| <p align="center"> |
| <strong>Construction phase objectives and activities</strong> |
| </p> |
| <table cellspacing="0" cellpadding="0" width="648" align="center" border="1"> |
| <tbody> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| <p style="TEXT-ALIGN: justify"> |
| <b>Phase objectives</b> |
| </p> |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <b>Activities that address objectives</b> |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| Iteratively develop a complete product that is ready to transition to the user community<br /> |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/identify_and_refine_requirements_7FA6CB14.html" guid="_xxcpgdOEEdyqlogshP8l4g">Identify and Refine Requirements</a> |
| </p> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/develop_solution_4FBB0E6E.html" guid="_RXGoodOFEdyqlogshP8l4g">Develop Solution Increment</a> |
| </p> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/test_solution_D16D88FC.html" guid="_buG4sdOFEdyqlogshP8l4g">Test Solution</a> |
| </p> |
| </td> |
| </tr> |
| <tr> |
| <td class="Normal" valign="top" width="300"> |
| Minimize development costs and achieve some degree of parallelism<br /> |
| </td> |
| <td class="Normal" valign="top" width="348"> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/plan_manage_iteration_F9713A62.html" guid="_oZgCsdOEEdyqlogshP8l4g">Plan and Manage Iteration</a><br /> |
| </p> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/develop_solution_4FBB0E6E.html" guid="_RXGoodOFEdyqlogshP8l4g">Develop Solution Increment</a> |
| </p> |
| <p style="TEXT-ALIGN: justify"> |
| <a class="elementLink" href="./../../process.openup.base/capabilitypatterns/test_solution_D16D88FC.html" guid="_buG4sdOFEdyqlogshP8l4g">Test Solution</a> |
| </p> |
| </td> |
| </tr> |
| </tbody> |
| </table></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-ZgdHcIUeC0fczWjxdRhZmQ" name="system_wide_requirements,_AQJYp9OOEdyqlogshP8l4g" guid="-ZgdHcIUeC0fczWjxdRhZmQ"> |
| <keyConsiderations><ul>
 |
| <li>
 |
| When you document system-wide requirements, ensure that the needs of all of the stakeholders are represented. In
 |
| particular, include the needs of those who are responsible for maintaining or supporting the system after it is
 |
| delivered.
 |
| </li>
 |
| <li>
 |
| Typically, there are some overlaps and gray areas between system-wide requirements and other requirements work
 |
| products. For example, the authorization behavior of a system can be specified as use cases or as statements within
 |
| system-wide requirements. The overall driving need is that no important requirements are missed or duplicated, and
 |
| that there is an agreed upon approach for capturing and processing every type of requirement.
 |
| </li>
 |
| <li>
 |
| System-wide requirements originate from many places. Documenting the source of the requirement is particularly
 |
| important when you separate externally mandated requirements.
 |
| </li>
 |
| <li>
 |
| Requirements are often thought of as "Qualitative" (specifying a quality or desirable characteristic) versus
 |
| "Quantitative" (specifying a quantity). Qualitative requirements can sometimes be elaborated into quantitative
 |
| requirements.
 |
| </li>
 |
| <li>
 |
| A good quality requirement is one that you can verify, either through testing or some other objective evaluation.
 |
| </li>
 |
| <li>
 |
| You must evaluate system-wide requirements for cost, schedule impact, and level of contribution to business goals.
 |
| Based on your evaluation, the system-wide requirements should be iteratively challenged, defended, and amended.
 |
| </li>
 |
| </ul></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-LXsJtWauw8OXFBPA5LtlUw" name="glossary,_AQJYqdOOEdyqlogshP8l4g" guid="-LXsJtWauw8OXFBPA5LtlUw"> |
| <keyConsiderations><p>
 |
| Although listed as an <i>output from</i> and an <i>input to</i> tasks associated with the requirements discipline, this
 |
| artifact can be updated at any time and by any role as new terms are identified. The terms defined should be used
 |
| according to the recorded definitions in all project documentation so that all stakeholders can clearly see that terms
 |
| are being used consistently.
 |
| </p>
 |
| <p>
 |
| One of the primary decisions when developing&nbsp;this artifact&nbsp;is whether to have all terms in a single glossary
 |
| or to maintain terms in several glossaries, business terms artifacts, or models.&nbsp;If terms are defined in multiple
 |
| places, you need to communicate all of those sources to the team and decide which take precedence.
 |
| </p>
 |
| <p>
 |
| It may be important, even in small projects, to reference and use existing broader glossaries, business terms
 |
| artifacts, or data models, where they exist.
 |
| </p>
 |
| <p>
 |
| Industry- and organization-wide glossaries may be referenced, and compliance with such specific chosen standards may be
 |
| required.
 |
| </p></keyConsiderations> |
| <refinedDescription><p>
 |
| This artifact&nbsp;helps you avoid miscommunication by providing two essential resources:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| A central location to look for terms and abbreviations that are new to development team members
 |
| </li>
 |
| <li>
 |
| Definitions of terms that are used in specific ways within the domain
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Definitions for the glossary terms come from several sources, such as requirements documents, specifications, and
 |
| discussions with stakeholders and domain experts.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-M0XmBkehezZMI-pmbjQ9SA" name="detail_use_case_scenarios,_AVhA0NOOEdyqlogshP8l4g" guid="-M0XmBkehezZMI-pmbjQ9SA"> |
| <keyConsiderations><p>
 |
| To avoid unnecessary rework, only those use-case scenarios that are scheduled for implementation in the near term (in
 |
| the next iteration or two)&nbsp;must be detailed.&nbsp;
 |
| </p>
 |
| <p>
 |
| Not all use-case scenarios require detailing.
 |
| </p></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-p2uRMHIOQI2c6fLh6CUIbw" name="detail_system_wide_requirements,_AVhA0dOOEdyqlogshP8l4g" guid="-p2uRMHIOQI2c6fLh6CUIbw"> |
| <keyConsiderations>To avoid unnecessary rework, only those requirements that are scheduled for implementation in the near term (in the next
 |
| iteration or two)&nbsp;must be detailed.</keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-nIF2UE5rqiDXuJIzOZcQuA" name="create_test_cases,_AVhA0tOOEdyqlogshP8l4g" guid="-nIF2UE5rqiDXuJIzOZcQuA"> |
| <keyConsiderations><p>
 |
| Develop test cases in parallel with requirements so that Analysts and Stakeholders can agree with the specific
 |
| conditions of satisfaction for each requirement. The test cases act as acceptance criteria by expanding on the intent
 |
| of the system&nbsp;through actual scenarios of use.&nbsp;This allows team members to measure progress in terms of
 |
| passing test cases.&nbsp;
 |
| </p></keyConsiderations> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-vyRUbVNrluvyfjsHPKp2fw" name="test_case,_AVhA1NOOEdyqlogshP8l4g" guid="-vyRUbVNrluvyfjsHPKp2fw"> |
| <refinedDescription><p>
 |
| A test case specifies the conditions that must be validated to enable an assessment of aspects of the system under
 |
| test. A test case is more formal than a test idea; typically, a test case takes the form of a specification. In less
 |
| formal environments, you can create test cases by identifying a unique ID, name, associated test data, and expected
 |
| results.
 |
| </p>
 |
| <p>
 |
| Test cases can be derived from many sources, and typically include a subset of the requirements (such as use cases,
 |
| performance characteristics, and reliability concerns) and other types of quality attributes. For more information on
 |
| types of tests and their relationships to quality test attributes, see <a class="elementLinkWithType"
 |
| href="./../../core.tech.common.extend_supp/guidances/concepts/testing_qualitative_rqmts_CAE80710.html"
 |
| guid="_0aJ6cMlgEdmt3adZL5Dmdw">Concept: Testing Qualitative Requirements</a>.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| </xmi:XMI> |
