| <?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="-yNrF2Ac8VgD0WjoUxGOsIQ" name="identify_and_refine_requirements,_xxcpgdOEEdyqlogshP8l4g" guid="-yNrF2Ac8VgD0WjoUxGOsIQ" version="7.2.0"> |
| <mainDescription><p> |
| This activity describes the tasks you perform to gather, specify, analyze, and validate a subset of system's |
| requirements prior to implementation and verification. This does not imply that all requirements are detailed prior to |
| commencing implementation. Rather, you perform this activity throughout the lifecycle with stakeholders and the entire |
| development team collaborating to ensure that a clear, consistent, correct, verifiable, and feasible set of |
| requirements is available, as needed, to drive implementation and verification. |
| </p> |
| <p> |
| During <b>Inception</b>, the focus is on gaining agreement on the problem to be solved, gathering stakeholder needs, |
| and capturing high-level system features. |
| </p> |
| <p> |
| During <b>Elaboration</b>, the focus shifts to defining the solution. This consists of finding those requirements that |
| have the most value to stakeholders, that are particularly challenging or risky, or that are architecturally |
| significant. You then describe requirements (that are prioritized, via the work items list, for implementation in the |
| early iterations) in sufficient detail to validate the development team's understanding of the requirements, to ensure |
| concurrence with stakeholders, and to permit software development to begin. For each of these requirements, define |
| associated test cases to ensure that the requirements are verifiable, and to provide the guidance needed for |
| verification and validation. |
| </p> |
| <p> |
| During Construction, the focus shifts to refining the system definition. This consists of detailing the remaining |
| requirements and associated test cases as necessary to drive implementation and verification, and managing requirements |
| change. |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-x896fGqISERWysfNwjvB7w" name="system_wide_requirements,_EOwqptOLEdyqlogshP8l4g" guid="-x896fGqISERWysfNwjvB7w"> |
| <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="-T_J_cyYgoF4KWAcGQbdjjA" name="glossary,_EOwqqNOLEdyqlogshP8l4g" guid="-T_J_cyYgoF4KWAcGQbdjjA"> |
| <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="-7g1n_R9Eg7zeKCdFrem74A" name="detail_use_case_scenarios,_FX7SINOLEdyqlogshP8l4g" guid="-7g1n_R9Eg7zeKCdFrem74A"> |
| <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="-snrpmf_Kt0OZ2R7QKJufUQ" name="detail_system_wide_requirements,_F68foNOLEdyqlogshP8l4g" guid="-snrpmf_Kt0OZ2R7QKJufUQ"> |
| <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="-Afh79qcpEs6i404AABE0rA" name="create_test_cases,_HDOWUNOLEdyqlogshP8l4g" guid="-Afh79qcpEs6i404AABE0rA"> |
| <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="-bQ7hVBwsq2Dzk11CI9pT_g" name="test_case,_HDOWUtOLEdyqlogshP8l4g" guid="-bQ7hVBwsq2Dzk11CI9pT_g"> |
| <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> |
