Understanding Quality Attributes


1. Functionality and Architecture

·       Functionality and quality attributes are orthogonal.

·       What is functionality? It is the ability of the system to do the work for which it was intended. A task requires that many or most of the system's elements work in a coordinated manner to complete the job. If the elements have not been assigned the correct responsibilities or have not been endowed with the correct facilities for coordinating with other elements

·       Functionality may be achieved through the use of any of a number of possible structures. In fact, if functionality were the only requirement, the system could exist as a single monolithic module with no internal structure at all. Instead, it is decomposed into modules to make it understandable and to support a variety of other purposes. In this way, functionality is largely independent of structure. Software architecture constrains its allocation to structure when other quality attributes are important.

2. Architecture and Quality Attributes

·       Achieving quality attributes must be considered throughout design, implementation, and deployment.

·       Architecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural level.

·       Architecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the details.

·       Types of quality attributes:

1.     Qualities of the system

2.     Business qualities

3.     Qualities that are about the architecture itself

3. System Quality Attributes


A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts.

·        Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that generated the stimulus.

·        Stimulus. The stimulus is a condition that needs to be considered when it arrives at a system.

·        Environment. The stimulus occurs within certain conditions. The system may be in an overload condition or may be running when the stimulus occurs, or some other condition may be true.

·        Artifact. Some artifact is stimulated. This may be the whole system or some pieces of it.

·        Response. The response is the activity undertaken after the arrival of the stimulus.

·        Response measure. When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

Quality attribute parts

4. Quality Attribute Scenarios in Practice


·       Availability is concerned with system failure and its associated consequences.

·       A system failure occurs when the system no longer delivers a service consistent with its specification.

·       Such a failure is observable by the system's users—either humans or other systems.

Availability General Scenarios

Sample availability scenario


Modifiability is about the cost of change.

 Modifiability General Scenario Generation

Portion of Scenario

Possible Values


End user, developer, system administrator


Wishes to add/delete/modify/vary functionality, quality attribute, capacity


System user interface, platform, environment; system that interoperates with target system


At runtime, compile time, build time, design time


Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification

Response Measure

Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes


Sample modifiability scenario



·       Performance is about timing. Events (interrupts, messages, requests from users, or the passage of time) occur, and the system must respond to them.

·       One of the things that make performance complicated is the number of event sources and arrival patterns.

·       A performance scenario begins with a request for some service arriving at the system. Satisfying the request requires resources to be consumed. While this is happening the system may be simultaneously servicing other requests.

·       An arrival pattern for events may be characterized as either periodic or stochastic.

 Performance General Scenario Generation

Portion of Scenario

Possible Values


One of a number of independent sources, possibly from within system


Periodic events arrive; sporadic events arrive; stochastic events arrive




Normal mode; overload mode


Processes stimuli; changes level of service

Response Measure

Latency, deadline, throughput, jitter, miss rate, data loss


Sample performance scenario




·       Security is a measure of the system's ability to resist unauthorized usage while still providing its services to legitimate users.

·       Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance, availability, and auditing.

1.     Nonrepudiation is the property that a transaction (access to or modification of data or services) cannot be denied by any of the parties to it.

2.     Confidentiality is the property that data or services are protected from unauthorized access.

3.     Integrity is the property that data or services are being delivered as intended.

4.     Assurance is the property that the parties to a transaction are who they purport to be.

5.     Availability is the property that the system will be available for legitimate use.

6.     Auditing is the property that the system tracks activities within it at levels sufficient to reconstruct them.

 Security General Scenario Generation

Portion of Scenario

Possible Values


Individual or system that is correctly identified, identified incorrectly, of unknown identity who is internal/external, authorized/not authorized with access to limited resources, vast resources


Tries to display data, change/delete data, access system services, reduce availability to system services


System services; data within system


Either online or offline, connected or disconnected, firewalled or open


Authenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services

Response Measure

Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied

Sample security scenario


·       Software testability refers to the ease with which software can be made to demonstrate its faults through testing.

·       Testability refers to the probability that it will fail on its next test execution.

·       For a system to be properly testable, it must be possible to control each component's internal state and inputs and then to observe its outputs.

 Testability General Scenario Generation

Portion of Scenario

Possible Values


Unit developer, Increment integrator, System verifier, Client acceptance tester, System user


Analysis, architecture, design, class, subsystem integration completed; system delivered


Piece of design, piece of code, complete application


At design time, at development time, at compile time, at deployment time


Provides access to state values; provides computed values; prepares test environment

Response Measure

Percent executable statements executed

Probability of failure if fault exists

Time to perform tests

Length of longest dependency chain in a test

Length of time to prepare test environment

Sample testability scenario



Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. It can be broken down into the following areas:

·        Learning system features. If the user is unfamiliar with a particular system or a particular aspect of it, what can the system do to make the task of learning easier?

·        Using a system efficiently. What can the system do to make the user more efficient in its operation?

·        Minimizing the impact of errors. What can the system do so that a user error has minimal impact?

·        Adapting the system to user needs. How can the user (or the system itself) adapt to make the user's task easier?

·        Increasing confidence and satisfaction. What does the system do to give the user confidence that the correct action is being taken?

Usability General Scenario Generation

Portion of Scenario

Possible Values


End user


Wants to learn system features; use system efficiently; minimize impact of errors; adapt system; feel comfortable




At runtime or configure time


System provides one or more of the following responses:

to support "learn system features": help system is sensitive to context; interface is familiar to user; interface is usable in an unfamiliar context

to support "use system efficiently": aggregation of data and/or commands; re-use of already entered data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities

to "minimize impact of errors": undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources

to "adapt system": customizability; internationalization

to "feel comfortable": display system state; work at the user's pace

Response Measure

Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ratio of successful operations to total operations, amount of time/data lost


Sample usability scenario




Quality Attribute Stimuli

Quality Attribute



Unexpected event, nonoccurrence of expected event


Request to add/delete/change/vary functionality, platform, quality attribute, or capacity


Periodic, stochastic, or sporadic


Tries to display, modify, change/delete information, access, or reduce availability to system services


Completion of phase of system development


Wants to learn system features, use a system efficiently, minimize the impact of errors, adapt the system, feel comfortable


5. Other System Quality Attributes

·       Scalability

·       Portability

·       Interoperability

6. Business Qualities

·        Time to market.

·        Cost and benefit.

·        Projected lifetime of the system.

·        Targeted market.

·        Rollout schedule.

·        Integration with legacy systems.

7. Architecture Qualities

·       Conceptual integrity is the underlying theme or vision that unifies the design of the system at all levels. The architecture should do similar things in similar ways. Conceptual integrity is the most important consideration in system design.

·       Correctness and completeness are essential for the architecture to allow for all of the system's requirements and runtime resource constraints to be met. A formal evaluation is the architect's best hope for a correct and complete architecture.

·       Buildability allows the system to be completed by the available team in a timely manner and to be open to certain changes as development progresses.