How to Write Meaningful Quality Attributes for Software Development

A quality attribute (QA) is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders.

In other words, a quality attribute (aka as Non-Functional Requirements) is what makes a system good with respect to a specific stakeholder. An example of a QA is how fast the function must be performed or how resilient it must be to an erroneous input, the time to deploy the product, or a limitation on operational costs. A list of some QA:

1. Performance

2. Security

3. Modifiability

4. Reliability

5. Usability

6. Calibrateability

7. Availability

8. Webifyability

9. Throughput

10. Configurability

11. Subsetability

12. Reusability

Quality attributes, most of the time, are not written. They're only verbally said alongside functional requirements. Most of the time they are implicit or said without much thought behind them.

A real-world example is if you’re in charge of developing certain features and you ask your boss about the time that the system should take to complete a task. He would probably say, “the minimum time possible.”

The same happens with security. Everyone is going to say it must be secure — whatever that means.

But those situations can be avoided with some work and preparation. First of all, all quality attributes must be measurable in some way. This allows teams responsible to implement certain tasks to know when they did a good job, according to some stakeholders, to complete that requirement.

To define a tangible quality attribute, a good starting point is to write a quality attribute scenario. A quality attribute scenario is an unambiguous way to specify a testable quality attribute. A quality attribute scenario is composed of six elements (as the following Figure illustrates):

Source of Stimulus: An entity capable of creating stimulus (internal or external people, a computer system, etc)
Stimulus: The stimulus is a condition that requires a response when it arrives at a system.
Environment: The environment where the stimulus occurs. For instance, the system may be running in normal conditions, under heavy traffic, or with a high latency or any relevant state.
Artifact: The artifact that receives the stimulus. This can be a component of the system, the whole system, or several systems.
Response: The is the response of the artifact according to the received stimulus.
Response Measure: This is the measure that should be tested for the response to test if the requirement is well implemented.

Example of a quality attribute scenario

Source of Stimulus: external to the system
Stimulus: unanticipated message
Artifact: process
Environment: normal operation
Response: inform operator, continue to operate
Response Measure: no downtime

This can be read as:

An unanticipated external message is received by a process during normal operation. The process informs the operator of the message’s receipt, and the system continues to operate with no downtime.

Getting started writing Quality Attribute Scenarios

Starting to write may sound difficult because you may not know some measures and characteristics related to quality attributes.

The good news is for the most generic quality attributes (availability, interoperability, modifiability, performance, security, testability, usability) you have generic quality attribute scenarios with the most common aspects to take into account.

General scenarios are system independent scenarios with typical stimuli, responses, and response measures for certain quality attributes.

Some quality general scenarios can be found here. Also, the reference for this information is in the footnote of this article.

This technique can also be extended to domain-specific systems particular to their business context.

Using a general quality attribute scenario can be done in the following way:

1. Choosing a general scenario for a specific QA.
2. Choosing the determinant factors according to the stakeholders' needs.
3. Writing quality attribute scenarios that everyone agrees on.

Example

Choosing a general scenario: Availability

Source: Internal/external: people, hardware, software, physical infrastructure or environment
Stimulus: Fault: omission, crash, incorrect timing, incorrect response
Artifact(s): Processors, communications channels, persistent storage, processes
Environment: Normal operation, startup, shutdown, repair mode, degraded operation, overloaded operation
Response: Prevent the fault from becoming a failure.

1. Detect the fault:
   1. Log the fault.
   2. Notify the appropriate entities (people or systems).
2. Recover from the fault:
   1. Disable source of events causing the fault.
   2. Be temporarily unavailable while repair is being effected.
   3. Fix or mask the fault/failure or contain the damage it causes.
   4. Operate in a degraded mode while repair is being effected.

Response Measure:

1. Time or time interval when the system must be available.
2. Availability percentage (e.g. 99.999%).
3. Time to detect the fault/time to repair the fault.
4. Time or time interval in which the system can be in degraded mode.
5. Proportion (e.g. 99%) or rate (e.g. up to 100 per second) of a class of faults that the system prevents or handles without failing.

Choosing the determinant factors

Source: Internal/external: people, hardware, software, physical infrastructure or environment
Stimulus: Fault: omission, crash, incorrect timing, incorrect response Artifact(s): Processors, communications channels, persistent storage, processes
Environment: Normal operation, startup, shutdown, repair mode, degraded operation, overloaded operation
Response: Prevent the fault from becoming a failure.

1. Detect the fault:
   1. Log the fault.
   2. Notify the appropriate entities (people or systems).
2. Recover from the fault:
   1. Disable source of events causing the fault.
   2. Be temporarily unavailable while repair is being effected.
   3. Fix or mask the fault/failure or contain the damage it causes.
   4. Operate in a degraded mode while repair is being effected.

Response Measure:

1. Time or time interval when the system must be available.
2. Availability percentage (e.g. 99.999%).
3. Time to detect the fault/time to repair the fault.
4. Time or time interval in which system can be in degraded mode.
5. Proportion (e.g. 99%) or rate (e.g. up to 100 per second) of a class of faults that the system prevents or handles without failing.

Resulting Quality Attribute Scenario for Availability

Source: Internal hardware
Stimulus: crash
Artifact(s): communications channels
Environment: normal operation

Response:

1. Log the fault.
2. Notify the appropriate entities (people or systems).
3. Fix or mask the fault/failure or contain the damage it causes.

Response Measure:

1. Time to detect the fault and repair it must be under 10 minutes.

Summary

By using this approach, any software development team has testable requirements for quality attributes relevant to multiple stakeholders.

This template can also be used to capture specific domain quality attributes besides the one stated here. Just remember that a quality attribute must be measured in some way to make sure that a team satisfies it along the development process.

This is a starting point on how to document relevant quality attribute requirements of a software system being built. Also, this method enables different kinds of stakeholders to engage in a conversation to agree upon a specific quality attribute.

To agree upon a set of quality attributes a system should achieve, there’s a method called Quality Attribute Workshop (QAW) that will be in the next post.

Most of this material was taken from:

1. SEI training course for “Software Architecture Principles and Practices”
2. And the book “Bass, Len. Software Architecture in Practice (SEI Series in Software Engineering). Pearson Education. Kindle Edition.”