| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0"> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="-OC3td1csl7lqV15vimYOaw" guid="-OC3td1csl7lqV15vimYOaw"/> |
| <org.eclipse.epf.uma:ActivityDescription xmi:id="-C3RmtvThtego5U5cOk8uCA" guid="-C3RmtvThtego5U5cOk8uCA"/> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-239OBD2wagT2qp8fuPWcHQ" guid="-239OBD2wagT2qp8fuPWcHQ"> |
| <mainDescription><p>
 |
| The <a href="./../../openup/workproducts/architecture_notebook_9BB92433.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">architecture</a> 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 <a class="elementlinkwithusertext" href="./../../openup/roles/project_manager_E657F936.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">project
 |
| manager</a> to focus on team efficiency and cost reduction.
 |
| </p>
 |
| <p>
 |
| Functionality is continuously implemented, tested, and integrated, resulting in <a class="elementLinkWithUserText" href="./../../openup/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">builds</a>
 |
| 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>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-Xfm5yDx3AVScrP1ZdLT-Sw" guid="-Xfm5yDx3AVScrP1ZdLT-Sw"> |
| <mainDescription><p>
 |
| This activity describes the tasks you perform to gather, specify, analyze, and validate a subset of the system's
 |
| requirements prior to implementation and verification. This does not imply that all requirements are detailed prior to
 |
| commencing implementation. Rather, this activity is performed throughout the lifecycle with <a class="elementLink" href="./../../openup/roles/stakeholder_9FFD4106.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s 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 Inception, the focus is on gaining agreement regarding the problem to be solved, gathering stakeholder needs,
 |
| and capturing high-level system features (see activity <a class="elementLink" href="./../../openup/capabilitypatterns/initiate_project_D9C03857.html" guid="_0pWNA8lgEdmt3adZL5Dmdw">Initiate Project</a>).
 |
| </p>
 |
| <p>
 |
| During Elaboration, the focus shifts to defining the solution. This consists of finding those requirements that have
 |
| most value to stakeholders, that are particularly challenging or risky, or that are architecturally significant (See <a class="elementLinkWithType" href="./../../openup/tasks/find_and_outline_requirements_90D272B9.html" guid="_P9cMUPV_EdmdHa9MmVPgqQ">Task: Find and Outline Requirements</a>). Requirements that were prioritized for
 |
| implementation in the early iterations (via the <a class="elementLink" href="./../../openup/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>) are then
 |
| described in sufficient detail to:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Validate the development team's understanding of the requirements
 |
| </li>
 |
| <li>
 |
| Ensure concurrence with stakeholders
 |
| </li>
 |
| <li>
 |
| Permit software development to begin
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| (See <a class="elementLinkWithType" href="./../../openup/tasks/detail_requirements_9747F71E.html" guid="_0e1mIMlgEdmt3adZL5Dmdw">Task: Detail Requirements</a>). 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 (see <a class="elementLinkWithType" href="./../../openup/tasks/create_test_cases_D39E98A1.html" guid="_0iwc0clgEdmt3adZL5Dmdw">Task: Create Test Cases</a>).
 |
| </p>
 |
| <p>
 |
| During Construction, the focus shifts to refining the system definition. This consists of detailing the remaining
 |
| requirements and associated test cases as needed to drive implementation and verification, and managing requirements
 |
| change (see activity <a class="elementLink" href="./../../openup/capabilitypatterns/ongoing_tasks_91569239.html" guid="_0pJ_xslgEdmt3adZL5Dmdw">Ongoing Tasks</a>).
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ProcessDescription> |
| </xmi:XMI> |