SASSY – Analysis Part 2

Quality Attributes

A fundamental driver to modern software architecture development are the quality attributes that the system is required to have. Factors such as performance, security, safety, usability and maintainability are often much more important in the design process than the functional requirements.

It is so important to have these quality requirements that we should provide some support in SASSY for their acquisition.

The core ontology for SASSY will be the software architecture knowledge base. An important part of that ontology will be a collection of quality attributes. The system should allow its user to assign an importance to each attribute for the specific project and thus include the quality requirements in the project's ontology.

Quality Frameworks

Several researchers in this field have developed classifications of the quality attributes according to how they see the relationships between them. One such classification has been promoted to being an ISO standard.

FURPS

A model developed by Hewlett-Packard that partitions the quality attributes into Functionality, Usability, Reliability, Performance, and Supportability.

Boehm

A model that partitions the quality attributes into Utility, Portability, and Maintainability. Utility is further divided into Reliability, Usability, and Efficiency.

McCall

Another model that partitions the quality attributes in a manner similar to the Boehm model, dividing them into operations, transitions, and revisions.

Dromey

This model partitions the quality attributes into Correctness (Functionality and Reliability), Internal (Maintainability and Performance), Context (Portability and Reusability) and Descriptive.

ISO-9126

This model partitions the quality attributes into Functionality, Reliability, Maintainability, Usability, Portability and Efficiency.

We should allow the user to select whichever classification they need, or use what might be called the Ontological classification of all known terms.

Quality Attribute Scenarios

It is all very well to specify that the system must achieve some quality requirement, but it is of no real use if there is no way to determine if the requirement is being met. In their book, Software Architecture in Practice, Bass, Clements and Kazman describe a set of Quality Attribute Scenarios that can be used to test the quality of a system.

Each scenario consists of six parts:

• The source of a stimulus which is some entity that generates a stimulating event.
• The stimulus which is some event that must be considered when it arrives at the system.
• The environment in which the stimulus is processed, such as a running instance of the system, or a system under some stress.
• The artefact that is stimulated, which may be the entire system or some part of it.
• The response that the system makes after the arrival of the stimulus; and
• Some measurement that can determine how the system responded.

While some these are quite obvious, such as how long the system takes to respond to an incoming event, others are a bit more problematic. For example it is quite reasonable to have a quality requirement that states that the system must be easy to maintain. However, the system itself is unlikely to include facilities for self modification. This sort of requirement forces us to expand the scope of what we mean by “the system” to include not only a set of running executables, but also the infrastructure required to maintain it – the maintenance team becomes part of the system.

SASSY will need to include the ability to set up these scenarios for all the important quality requirements.


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.