| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription 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" xmi:id="-EUXQjT8DebSClO4YjNuoHw" |
| name="determine_architecturally_significant_requirements,_D3JXMNvKEduv2KOT-Teh6w" |
| guid="-EUXQjT8DebSClO4YjNuoHw" changeDate="2007-05-18T08:34:13.015-0700"> |
| <mainDescription><p> The selection of requirements that are considered "architecturally significant" 
 |
| is driven by several key driving factors:</p>
 |
| <ul>
 |
| 
 |
| <li> The benefit of the requirement to stakeholders: critical, <b>important</b>, 
 |
| or<b> useful</b>. </li>
 |
| <li> The architectural impact of the requirement:<b> none</b>, <b>extends</b>, 
 |
| or <b>modifies</b>. There may be critical requirements that have little or 
 |
| no impact on the architecture and low-benefit requirements that have a big 
 |
| impact. Low-benefit requirements with big architectural impacts should be 
 |
| reviewed by the project manager for possible removal from the scope of the 
 |
| project.</li>
 |
| 
 |
| <li> The risks to be mitigated: performance, availability of a product, and 
 |
| suitability of a component. </li>
 |
| <li>
 |
| The completion of the coverage of the architecture.
 |
| </li>
 |
| 
 |
| <li> Other tactical objectives or constraints, such as demonstration to the 
 |
| user, and so on. </li>
 |
| </ul>
 |
| <p> There may be two requirements that hit the same components and address similar 
 |
| risks. If you implement A first, then B is not architecturally significant. 
 |
| If you implement B first, then A is not architecturally significant. Thus these 
 |
| attributes can depend on the iteration order and should be re-evaluated when 
 |
| the order changes, as well as when the requirements themselves change. </p>
 |
| <p>
 |
| Architecturally significant requirements that are poorly understood or likely to change should be prioritized for
 |
| clarification and stabilization. In some cases, this means further requirements analysis should be done before
 |
| implementing the requirement. In other cases, some form of prototyping may be best.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
