Quality Attributes – Introduction

“Quality Attributes” is the third and last of the set-up steps of the SPAMMED Architecture Framework (SAF) (the former ones being mapping stakeholders and their concerns and preparing a list of principles and goals). It is, however, a very important step.

Like any other software artifact, architecture is derived or constructed from requirements. I guess the main difference between architecture and design is that architecture is focused on non-functional requirements (i.e., quality attributes), whereas design is focused on functional requirements.

Two notes on the last statement:

1. The boundary is far from being distinct in this respect. i.e., Architecture also has to deal with functional requirements, and design sometimes has to deal with non-functionals – the difference is, as I’ve stated, in the focus
2. There are additional characteristics that help differentiate between the two. For example, architectural specifications tend to be non-local, i.e., relate to all aspects of the system, whereas design pertains to specific parts.

Quality attributes are derived from stakeholders’ needs; thus (probably)the most common quality attributes used as input for architectural design are those seen from the end-users’ perspective

• Performance
• Availability
• Usability
• Modifiability
• Security

Business stakeholders will probably be more interested in things like

• Time to market
• Cost vs. Benefit
• Interoperability (e.g. with legacy systems)
• Projected lifetime
• etc.

Developers’ concerns are probably a little different, for example:

• Maintainability

• Portability

• Reusability

• Testability

Since there are many stakeholders to the project – we will have to balance all these (sometimes conflicting) attributes, but before we get to that  – ISO/IEC 9126-1:2001, which, in fact, is a standard for the evaluation of the quality of software, happens to have a hefty list of quality attributes to draw from:

[Note: The list below is partial (most of the qualities appear) and doesn’t have descriptions for the sub-categories. It is a copy of the list in Wikipedia (http://en.wikipedia.org/wiki/ISO_9126) – Unfortunately, I am not sure I can copy the full list from the standard without violating copyright laws]

• Functionality – A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
  • Suitability
  • Accuracy
  • Interoperability
  • Compliance
  • Security
• Reliability – A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.
  • Maturity
  • Recoverability
  • Fault Tolerance
• Usability – A set of attributes that bear on the effort needed for use and on the individual assessment of such use by a stated or implied set of users.
  • Learnability
  • Understandability
  • Operability
• Efficiency – A set of attributes that bear on the relationship between the software’s performance level and the amount of resources used under stated conditions.
  • Time Behavior
  • Resource Behavior
• Maintainability – A set of attributes that bear on the effort needed to make specified modifications.
  • Stability
  • Analysability
  • Changeability
  • Testability
• Portability – A set of attributes that bear on the ability of software to be transferred from one environment to another.
  • Installability
  • Conformance
  • Replaceability
  • Adaptability

That’s all very nice –  we now have a ton of “quality attributes” to choose from – but specifying that our solution needs performance or that we like it to be Recoverable doesn’t really say much about the project – anyway, wouldn’t we want all of them in our solution? Also, does architecture really not have anything to do with functional requirements?

The answer to all these lies in something called a “Utility Tree” -where Utility means the overall “goodness” of the system. The point of the utility tree is to decompose and refine the business goals and quality attributes of the system so that we will be able to understand them better, prioritize them, and use them as the requirements for designing the architecture.

The root of the tree is the utility (level 0).

The quality attributes (as mentioned above)  are level 1 in this tree.

The next level refines the attributes into sub-categories. For example, the Performance quality attribute can be refined to Latency, Throughput, Deadline, Data loss, Jitter, or Miss rate.

Lastly, the leaves of the tree are scenarios (A (simplified) example for Performance->deadline can be – upon initializing the system, have it in active mode within 10 seconds or less). The scenarios are very important for several reasons. The most important is that it helps anchor everything to the real needs of the system It also helps prioritize the quality attributes, and they can serve as a basis for evaluating the architecture later on.
Indeed, the source of the utility tree approach is in an SEI Architecture Evaluation method called ATAM,

In the next posts on quality attributes, I’ll talk about constructing a utility tree, formulating scenarios, generic scenarios, etc. (and I’ll include some samples from past projects).

Related posts:

SPAMMED State chart Stakeholders Everywhere SAF – Mapping -Don’t forget the Technology