System Quality Attributes

Quality Attributes

Quality of a system can be divided into 3 broad categories:

  1. System quality attributes: Testability, performance, etc. We call these quality attributes for short.
  2. Business quality attributes: Things such as time to market, cost, market value, etc. They need to specifically be defined and mapped into system quality attributes in order to influence the design process.
  3. Architecture quality: These are the qualities directly related to the architecture itself: buildability, conceptual integrity, correctness and completeness, etc

How to Meet Quality

  • Quality attributes by themselves help to understand requirement but do not help on achieving them.
  • We use tactics to meet quality attributes. A tactic is a design decision that influences the response of a quality attribute.
  • An architectural pattern is a ( usually a collection of) tactic(s)

System Quality Attributes

Quality attributes should be specified accurately by the Architect.

Performance Is usually describes in the following measures: 1- Throughput: the amount of work application must do per unit of time i.e. 300 transaction/second 2- Response Time (Latency): This method's response time should be no more than five seconds 3- Deadline: A (batch) jobs should finish in time
Scalability Application should be able to handle more requirements, load, data, connections, user, etc. When load increases one solution is to scale up (add more CPU or RAM) or scale out (replicate application on different machines)
Modifiability 1- For each change scenario the impact MUST be assessed first. 2- Is about the cost of change so these are the "response measures" in any related quality attribute scenario. This can also be called scalability of function.
Security 1- Authentication 2- Authorization 3- Encryption 4-Integrity: making sure a message is not altered on the way 5- Non-repudiation: The sender has proof of delivery and the receiver is assured of the sender's identity
Availability In most cases can be achieved by replication. Recovery from or repair of a fault is a aspect of availability.
Recoverability Is partly related to availability
Integrability Is the ease with which separately or distributively developed system elements can be made to work together. Best achieved by using an API layer on top of the application. Less favorable method is direct database access by other parties for data integration. Other tactics are: keeping interfaces small, simple and stable; adhere to defined protocols, loose coupling and minimal dependency between elements, using versioned interfaces, using intermediary, etc.
Portability The ability to change platforms.
Testability The goal is to test system easier
Usability How easy it is for the use to do a task using the system. Not all usability issues are architectural. Some problems comes from a bad detailed design. Separating UI from the rest of the application makes UI changes easier and can facilitate implementing usability-related changes.


  • Not all quality attributes can work together. For example a highly secure system may not be portable enough or could lag in performance. Architect should trade off between these attributes and design a sensible architecture. This is a tough part.
  • These attributes are not always identified properly by the requirements team and that is the reason an architect is needed there.
  • Functionality and quality attributes are orthogonal
  • Most quality attributes have negative effect on performance
  • Quality attributes can target any stage of a system: design time, development/deployment and/or runtime, etc.

Quality Attribute Scenarios

Quality attribute scenario is a type of requirement for the system. It is an expectation that should be fulfilled by the architectural tactics/patterns. They are created based on architectural drives/requirements. See architecture-design

It was briefly explained in the "3 step architecture process" but a detailed quality attribute scenario has 6 parts:

  1. source of stimulus: human, computer, system, developer, user,…
  2. stimulus: the condition that arrives at the system (add/del/modify something, etc)
  3. environment: the condition that the system is at when the stimulus happens
  4. artifact: part of the system that is stimulated (code, UI, hardware, environment, etc)
  5. response: the system response after the arrival of the stimulus
  6. response measure: a way to measure the response to test the requirement (time, cost, etc)


  • Most quality attributes have generic scenarios that can be mapped to a system-specific scenario.
  • For every important quality attributes in system, the architecture should capture and explain the important scenarios.
  • Quality attribute scenarios make different stakeholders to talk!

Availability Tactics

It has 3 aspects:

Fault detection

ping-pong or ping-echo, heart beat (can carry data too), exceptions

Fault Recovery

  • voting: All redundant processors each take equivalent input and compute a simple output value that is sent to a voter. If voter detect a deviant behaviour if will fail the process. Voter algorithm can be based on "majority" or "preferred" components logic.
  • Active Redundancy: all redundant processes respond to requests in parallel and usually response from the first one is accepted and rest are discarded. All processes are in the same state.
  • Passive Redundancy: the main process responds to request and informs redundant processes of any state update required. synchronisation is the responsibility of the primary process. When a secondary process should take over is the responsibility of a secondary process or a third party process. Forcing switch over periodically insures availability. Notice that both the main and secondary machines (processes) should use the same code. This code might not be fault tolerant aware except in higher architectural point of view.
  • Spare: A standby spare is used to replace many failed processes. It can be initialised to the current state using different methods such as checkpoints, logging, persisting state, etc.

Tactics for Repair from Faults

  • Shadow Operation: A previously failed component may be run in shadow mode to make sure if it is capable of running properly before it is fully restored.
  • State resynchronisation: Passive and active redundancy tactics require the component to be restored to a correct state before it returns to service. Restoration and re-sync is best to be done with the least amount of messages (only one is the best).
  • Rollback: We can record system status (using check points) and it be restored using these saved statuses.

Fault prevention

  • Removal from service: This can be automatic (or be predicted) to prevent from failure.
  • Transactions: Atomic feature is useful
  • Monitor: A monitor component can detect a faulty process and reinitialise it.

Modifiability Tactics

Modifiability tactics are categorised based on their goals.

Localise modifications

Reduce the number of components directly affected. There are many techniques for example:
# Generalising modules as much as possible.
# Abstracting common services. This also help preventing the ripple effect and also code reuse.

Prevent ripple effect

Reduce the need to change modules not directly affected by the change, i.e changing A needs a change on B because B depends on A. B might depend on A in terms of : Location of A, quality of service A provides, Existence of A, Format/sequence/quality/syntax/semantics of data that A provides, etc.
Related tactics are:

  1. Maintain an existing interface (1- Use an interface if you are not using already 2- Wrap A with an adapter 3- If A is being removed provide a stub for A so B has no need to change)
  2. Use an intermediary (between A and B)
  3. Restrict communication (i.e lower layer can not call upper layer)

Defer binding time

Defer the change to deployment or execution time and make the system configurable (using config files, runtime registration, polymorphism, etc). A configurable system can help non-developers to make changes.

Performance Tactics

Performance issues are usually undesirable response time and for that the latency should be addressed. Items contribute to latency are:

  1. Contention and blocked time
  2. Dependency to other components
  3. Availability of other components

In general performance tactics can be divided into addressing resource demand/management/arbitration.

Tactics to improve latency could include:

  1. Reducing computational overhead
  2. Impose execution rules (timeout, etc)
  3. Introduce concurrency (load balancing, threads, etc)
  4. Increase availability (replication, more memory, cache, etc)
  5. Scheduling (Whenever there is a contention for a resource, the resource access should be scheduled (for example CPU). Tactics include FIFO, static and dynamic algorithms of scheduling, fixed priority, etc)

Security Tactics

  1. Resisting attack
    1. Authorisation
    2. Authentication
    3. Encryption (confidentiality): VPN, SSL, symmetric keys (same key), asymmetric keys (public/private key)
    4. Limit access/exposure: DMZ, firewall
    5. Maintain data integrity: add checksum/hash
  2. Detecting attack (checking logs or tools that check logs, analyzing traffic patterns, checking audits/transactions, etc)
  3. Attack Recovery (restoring the states similar to availability tactics)

Testability Tactics

  1. Use record/playback to get sample data to test. This can also be used to review the system execution mechanisms. In a flight simulator this can be used to review the performance of the pilot.
  2. Separate implementation from interface to use stubs
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License