blob: d50e0fdc2063fafc682d9ded87e684c2d60194aa [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" xmi:id="-EytH4BCNGiHF6pZrp8ISCw" name="new_concept,_eFElAOK2EdqHEo0wLIc5jg" guid="-EytH4BCNGiHF6pZrp8ISCw" authors="Mark Dickson" changeDate="2006-07-07T04:53:04.786-0700" changeDescription="First Draft" version="1.0">
<mainDescription>&lt;p&gt; Not all requirements have equal significance in the architecture.&amp;nbsp;Some
play an important role in determining the architecture of the
system, but others do not. &lt;/p&gt;
&lt;p&gt; Deciding whether a specific requirement is architecturally significant is
often a matter of judgment. Typically, these are requirements that are
technically challenging, technically constraining, or central to the
system's purpose. &lt;/p&gt;
&lt;p&gt; These are good examples of Architecturally Significant Requirements:&lt;/p&gt;
&lt;li&gt; The system must record every modification to customer records for audit
&lt;li&gt; The system must respond within 5 seconds.&lt;/li&gt;
&lt;li&gt; The system must&amp;nbsp;deploy on Microsoft Windows XP and Linux. &lt;/li&gt;
&lt;li&gt; The system must encrypt all network traffic.&lt;/li&gt;
&lt;li&gt; The ATM system must dispense cash on&amp;nbsp;demand&amp;nbsp;to validated account
holders with sufficient cleared funds.&lt;/li&gt;
&lt;br /&gt;</mainDescription>