Quality Attributes – Introduction

“quality Attributes” is the third and last of the set-up steps of 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.

Architecture, just like any other software artifact, is derived or constructed from requirements. I guess the main difference between architecture and design is that architecture is focused on the non-functional requirements (i.e. Quality Attributes) whereas the focus of the design is 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 pertain 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 life time
• etc.

Developers concerns are probably a little different for example:

• Maintainability
• Portability
• Reusability
• Testabilty

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 the quality of software, happens to have a hefty list of quality attributes to draw from:

[Note: The list below is a partial one (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 level of performance of the software 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 chose from – but specifying that our solution need 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 doesn’t 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 better understand them, 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 this it help anchor everything to  the real needs of the system also it 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 a SEI Architecture Evaluation method called ATAM, a similar approach, is also used in the LAAAM as part of MSF 4 for CMMI Improvment, again, for evaluating the architecture. (I will talk more about ATAM, LAAAM (and other evaluation options) in future posts where I’ll address the E(valuation) of SAF).

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