As a part of the Analysis process, the Architect develops an initial Locality diagram. The Locality view is a synthesis
of the non-functional considerations and provides a context for addressing how the non-functional requirements such as
reliability and capacity are addressed.
Standard engineering practice allows for the budgeting of capacity, permitted failure rates, and so forth. This effort
results in a set of derived supplementary requirements for each locality element. The locality characteristics are
determined from these requirements. The derived requirements and characteristics are revisited as the partitioning of
subsystems (across localities) is determined and refined.
The system-level Supplementary Requirements also have an impact on the subsystems (hardware, software, people)
themselves, with the subsystem characteristics, in combination with locality characteristics, combining to yield the
desired system characteristics.
Quality of service measures
Quality of service (QoS) is a notion that includes aspects of non-functional requirements. The list of such
characteristics is potentially large, including many "abilities," such as reliability, maintainability and usability,
and possibly complete engineering specialties such as safety, human factors, and so on. Significant engineering
specialty problems are typically addressed by experts in those disciplines. The issues that often fall to the system
and software engineer are those to do with:
Performance - how well, against time, does the system perform its functions, that is, responsiveness, throughput,
Reliability/Fault Tolerance - how long can the system continue to perform its required functions before a failure,
and how well (gracefully) does it cope with partial failures. The system Mean Time Between Failure (MTBF) is a
measure of reliability.
Maintainability - how easy is it to keep the system running, and diagnose and fix problems in the system. The
system Mean Time To Repair (MTTR) is a measure of maintainability.
Before system construction, the system engineer must often rely on models of the system as a way of defining
alternative solutions, and assignment and budgeting of non-functional requirements. These models are analyzed to see
how well they meet the desired quality of service levels, and a solution can then be selected (usually with cost as a
factor). Such trade studies are important in system design at all levels of refinement. The synthesis of
candidate solutions depends very much on the ability and experience of the Architect. The analysis of these solutions
(through mathematical modeling, simulation, and so on) should be relatively mechanical. Even so, the reliability of
these analyses will vary considerably with the goodness of the input data and the fidelity of the models.
A body of techniques is available to make tractable the analysis of models with respect to the QoS measures listed
above - for example, Rate Monotonic Analysis for the examination of the performance of real-time embedded
software systems [see Klein, M. H., et al. A Practitioners' Handbook for Real-Time Analysis: Guide to Rate Monotonic
Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993], and Failure Mode Effects and Criticality
Analysis (FMECA), for hardware failure and safety risk identification and characterization [see Kececioglu, Dimitri,
Reliability Engineering Handbook, Vol. 2, PTR Prentice Hall, 1991].
Support for these kinds of analyses is being added to the UML through the provision of profiles, notably the "UML
Profile for Schedulability, Performance, and Time Specification" and the "UML Profile for Modeling Quality of
Service and Fault Tolerance Characteristics and Mechanisms." These profiles (available from www.omg.org) define annotations for UML models that allow them to be
analyzed for the characteristics defined in the profile, and quantitative predictions made regarding these
characteristics, using various existing and future model analysis techniques and tools.