<?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" xmlns:rmc="http://www.ibm.com/rmc"
    rmc:version="7.5.0" xmi:id="-EytH4BCNGiHF6pZrp8ISCw"
    name="new_concept,_eFElAOK2EdqHEo0wLIc5jg" guid="-EytH4BCNGiHF6pZrp8ISCw" authors="Mark Dickson"
    changeDate="2008-10-15T08:24:39.298-0700" changeDescription="First Draft" version="1.0">
  <mainDescription>&lt;p>&#xD;
    Architecturally significant requirements are those requirements that play an important role in determining the&#xD;
    architecture of the system.&amp;nbsp; Such requirements require special attention. Not all requirements have equal&#xD;
    significance with regards to the architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Architecturally significant requirements&amp;nbsp;are a subset of the requirements that need to be satisfied before the&#xD;
    architecture can be considered &quot;stable&quot;. Typically, these are requirements that are technically challenging,&#xD;
    technically constraining, or central to the system's purpose. Furthermore, the system will generally be more sensitive&#xD;
    to changes&amp;nbsp;against architecturally significant requirements, so identifying and communicating this subset will&#xD;
    help others understand the potential implications of change.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Requirements can be explicitly or implicitly architecturally significant. Explicitly significant requirements are often&#xD;
    overtly technical in nature, such as performance targets; the need to interface to other systems; the number of users&#xD;
    that must be supported; or security requirements. Implicitly significant requirements may define the essence of the&#xD;
    functional behaviour of the system (for example, making a purchase from an on-line store).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Deciding whether a specific requirement is architecturally significant is often a matter of judgment. The selection of&#xD;
    requirements that are considered &quot;architecturally significant&quot; is driven by several key driving factors:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The benefit of the requirement to stakeholders: critical, &lt;b>important&lt;/b>, or &lt;b>useful&lt;/b>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The architectural impact of the requirement: &lt;b>none&lt;/b>, &lt;b>extends&lt;/b>, or &lt;b>modifies&lt;/b>. There may be critical&#xD;
        requirements that have little or no impact on the architecture and low-benefit requirements that have a big impact.&#xD;
        Low-benefit requirements with big architectural impacts should be reviewed by the project manager for possible&#xD;
        removal from the scope of the project.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The risks to be mitigated: performance, availability of a product, and suitability of a component.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The completion of the coverage of the architecture.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Other tactical objectives or constraints, such as demonstration to the user, and so on.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    There may be two requirements that hit the same components and address similar risks. If you implement A first, then B&#xD;
    is not architecturally significant. If you implement B first, then A is not architecturally significant. Thus these&#xD;
    attributes can depend on the order the requirements are realized, and should be re-evaluated when the order changes, as&#xD;
    well as when the requirements themselves change.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following are good examples of Architecturally Significant Requirements:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The system must record every modification to customer records for audit purposes.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system must respond within 5 seconds.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system must&amp;nbsp;deploy on Microsoft Windows XP and Linux.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system must encrypt all network traffic.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The ATM system must dispense cash on&amp;nbsp;demand&amp;nbsp;to validated account holders with sufficient cleared funds.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Architecturally significant requirements also describe key behaviors that the system needs to perform.&amp;nbsp; Such&#xD;
    scenarios represent the important interactions between key abstractions.and should be identified as architecturally&#xD;
    significant requirements. For example, for an on-line book store describing the way the software handles the scenarios&#xD;
    for ordering a book and checking out the shopping cart are often enough to communicate the essence of the architecture.&#xD;
&lt;/p>&lt;br />&#xD;
&lt;br />&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>