Understanding Quality Attributes

Quality attributes are properties of a system by which a stakeholder will evaluate their quality. In simple words, it is about how good a system performs its functional attributes.

Examples: performance, security, availability, modifiability, usability,.. .
Part of stakeholder concerns can be addressed by, and is translatable to quality attributes.

For example if a stakeholders states that he is looking to increase the market share of their product, it maybe translated to Modifiability, Usability.

Stakeholders of the system are the main source for gathering quality attribute requirements. 

The degree to which a software system meets its quality attribute requirements depends on its architecture. This is when the architect makes decisions during the design to satisfy quality attributes. Usually satisfying one quality attribute affects other ones. Almost all quality attributes stand against achieving performance. As a result an architect has to meet some tradeoffs in design the achieve the optimal quality attribute.

Considering the importance of quality attributes to an architect, we need a tool to gather and express and reach a consensus among stakeholders. There is a specific method for gathering, prioritising and expressing quality attribute called Quality Attribute Workshop which is of great help if you are looking to gather quality attributes.

It is worth mentioning that saying "this system should be modifiable, secure or highly available" is not of much value, we need to say the which area of the system should be modifiable against what changes, in other words, they should be measurable, and hence testable.

Also different people based on their different professional background understand various concepts under a quality attribute name.
A possible(,and proven ) solution to this dilemma is using Quality Attribute Scenarios.

Quality Attribute Scenarios

A quality attribute scenario is a short description of how a system is required to respond to some stimulus. In fact a scenario has six parts:

1. source - an entity that generates the stimulus
2. stimulus - a condition that affects the system
3. artifact - the part of the system that was stimulated by the stimulus
4. environment - the condition under which the stimulus occurred
5. response - the activity that results because of the stimulus
6. response measure - the measure by which the system's response will be evaluated 

Let's have a look at an example for modifiability:

A change request for updating a graph arrives, and it should be done, and deployed with in 4 hours.

Source: A customer
Stimulus: Change request
Artifact: code/ UI 
Environment: (Normal)
response: change code, and deploy
response measure: 4 hours

And here is an example for security:

An employee tries to change pay rate from a remote location within normal system operation status, system will keep an audit trail, and correct data will be restored after one day and tampering source is identified.

Can you try to identify the parts for the upper scenario?

Source: An employee
Stimulus: change the pay rate
Artifact: system data
Environment: Normal
response: audit train
response measure: restoring data, identification of source in a day.

General scenarios vs Concrete scenarios

So far all the scenarios we have seen are concrete, meaning they are pointing to a very specific, known story.

However depending on the domain and organisation or even your own experience you notice that some terms and actions start appearing and recurring in scenario parts.

You can take advantage of this fact and build a table and put those recurring and possible terms in a table for each part and quality attribute. This will help you and stakeholders to produce scenarios quicker and more fluently.

Testability General Scenario Generation

Portion of Scenario	Possible Values
Source	Unit developer Increment integrator System verifier Client acceptance tester System user
Stimulus	Analysis, architecture, design, class, subsystem integration completed; system delivered
Artifact	Piece of design, piece of code, complete application
Environment	At design time, at development time, at compile time, at deployment time
Response	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

I think this a good time for an exercise, try to find out what QA s are important for the software you are developing or working with, and create a few scenarios. 

Other Quality attributes

There quality attributes of different nature that are also important for an architect.

Business Quality Attributes : these are concerned about cost, schedule, market. Time to market, Cost and benefit, expected lifetime and rollout schedule.
Architectural Quality attributes :