| <?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.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" xmi:id="-EytH4BCNGiHF6pZrp8ISCw" name="new_concept,_eFElAOK2EdqHEo0wLIc5jg" guid="-EytH4BCNGiHF6pZrp8ISCw" authors="Mark Dickson" changeDate="2008-10-15T08:24:39.000-0700" changeDescription="First Draft" version="1.0"> |
| <mainDescription><p>
 |
| Architecturally significant requirements are those requirements that play an important role in determining the
 |
| architecture of the system.&nbsp; Such requirements require special attention. Not all requirements have equal
 |
| significance with regards to the architecture.
 |
| </p>
 |
| <p>
 |
| Architecturally significant requirements&nbsp;are a subset of the requirements that need to be satisfied before the
 |
| architecture can be considered "stable". Typically, these are requirements that are technically challenging,
 |
| technically constraining, or central to the system's purpose. Furthermore, the system will generally be more sensitive
 |
| to changes&nbsp;against architecturally significant requirements, so identifying and communicating this subset will
 |
| help others understand the potential implications of change.
 |
| </p>
 |
| <p>
 |
| Requirements can be explicitly or implicitly architecturally significant. Explicitly significant requirements are often
 |
| overtly technical in nature, such as performance targets; the need to interface to other systems; the number of users
 |
| that must be supported; or security requirements. Implicitly significant requirements may define the essence of the
 |
| functional behaviour of the system (for example, making a purchase from an on-line store).
 |
| </p>
 |
| <p>
 |
| Deciding whether a specific requirement is architecturally significant is often a matter of judgment. 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 order the requirements are realized, and should be re-evaluated when the order changes, as
 |
| well as when the requirements themselves change.
 |
| </p>
 |
| <p>
 |
| The following are good examples of Architecturally Significant Requirements:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The system must record every modification to customer records for audit purposes.
 |
| </li>
 |
| <li>
 |
| The system must respond within 5 seconds.
 |
| </li>
 |
| <li>
 |
| The system must&nbsp;deploy on Microsoft Windows XP and Linux.
 |
| </li>
 |
| <li>
 |
| The system must encrypt all network traffic.
 |
| </li>
 |
| <li>
 |
| The ATM system must dispense cash on&nbsp;demand&nbsp;to validated account holders with sufficient cleared funds.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Architecturally significant requirements also describe key behaviors that the system needs to perform.&nbsp; Such
 |
| scenarios represent the important interactions between key abstractions.and should be identified as architecturally
 |
| significant requirements. For example, for an on-line book store describing the way the software handles the scenarios
 |
| for ordering a book and checking out the shopping cart are often enough to communicate the essence of the architecture.
 |
| </p><br />
 |
| <br />
 |
| <br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
