A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
8.3. Other applications of ARM<br />
We are now certain that the Alarm Services can be supported by table insertions and<br />
the Top End calls. As such, the OCR and ICR of AR15 can also be reduced. This is<br />
reflected in the adjustments of EB, OCR and ICR in AR15 in Figure 8.2. If the outcome<br />
certainty OCR at AR15 cannot be reduced, it means that we don’t know whether the<br />
design would work or not. If the risk of AR35 is not at an acceptable level, we would<br />
not be certain that this design would need more investigation and design decomposition.<br />
Now that we are fairly certain that the design would work, i.e. the risk is low, then we<br />
do not need to go into further architecture design. The architecture design of this part of<br />
the system can be considered complete.<br />
When architects design a system, OCR and ICR risk values are assigned to the AR<br />
nodes, usually along a top-down fashion. There are usually more uncertainties in the<br />
initial stage when architecture design is at the high-level because details of whether the<br />
decisions are valid are yet to be confirmed. As architecture design progresses, and more<br />
details become available, architects are more confident about the validity of the lower-level<br />
decisions. This confirmation from having more details requires that architects readjust the<br />
OCR and ICR at the higher-level decisions. There<strong>for</strong>e, the risk level of a high-risk decision<br />
can now be updated to a lower risk level. This re-adjustment process serves to confirm<br />
the architecture design.<br />
All requirements which involve high risk decisions, as indicated by OCR and ICR,<br />
should be part of architecture level requirements and need to be a part of the architecture<br />
design. Low risk functional requirements do not require architectural design because they<br />
do not have structural impact on architecture. Non-functional requirements usually have<br />
higher risk factors because (a) Non-functional requirements usually cut-across a large part<br />
of the system; (b) Non-functional requirements are usually competing with other nonfunctional<br />
requirements; (c) the impact of a design to satisfy a non-functional requirement<br />
requires more design attention. There<strong>for</strong>e, all non-functional requirements should be considered<br />
in architecture modelling. This mechanism provides a way to define the scope<br />
of the architecture activities and allow measurement of completeness of the architecture<br />
outcomes.<br />
We have chosen an arbitrary guide to establish a yardstick <strong>for</strong> determining an acceptable<br />
risk. In order to get a common consensus on an acceptable risk level, we undertook<br />
a survey [158]. Architects were asked as to what is an acceptable level of risk. 23.5% said<br />
that a 30% risk level was acceptable, 18.5% said that a 40% risk level was acceptable.<br />
However, 14.8% of respondents said that a 70% risk level was acceptable and 13.6% said<br />
that a 80% risk level was acceptable. It shows that either architects genuinely believe in a<br />
high risk architectrue or they are inexperience with risk assessment in architecture design<br />
and with the impact risk may have on design quality. More research is required in this<br />
147