Quality Attributes

Quality Attributes

This quality attributes section on SoftwareArchitectures.com is the gateway to resources that address the following areas of the subject:

Introduction

Developing high quality software is hard, especially when the interpretation of term “quality” is patchy based on the environment in which it is used. In order to know if quality has been achieved, or degraded, it has to be measured, but determining what to measure and how is the difficult part.

Software Quality Attributes are the benchmarks that describe system’s intended behavior within the environment for which it was built. The quality attributes provide the means for measuring the fitness and suitability of a product. Software architecture has a profound affect on most qualities in one way or another, and software quality attributes affect architecture.

Identifying desired system qualities before a system is built allows system designer to mold a solution (starting with its architecture) to match the desired needs of the system within the context of constraints (available resources, interface with legacy systems, etc). When a designer understands the desired qualities before a system is built, then the likelihood of selecting or creating the right architecture is improved.

Scenarios

Statements like “a system will have high performance” or “a system will be user friendly” are acceptable in the really early stages of requirements elicitation process (i.e. business concept brainstorming). As more information becomes available, the above statements become useless as they are meaningless for the purpose of actually designing a solution. In each of the two examples above an attempt is made to describe the behavior of a system. Both statements are useless as they provide no tangible way of measuring the behavior of the system.

The quality attributes must be described in terms of scenarios, such as “when 100 users initiate ‘complete payment’ transition, the payment component, under normal circumstances, will process the requests with an average latency of three seconds.” This statement, or scenario, allows an architect to make quantifiable arguments about a system. A scenario defines the source of stimulus (users), the actual stimulus (initiate transaction), the artifact affected (payment component), the environment in which it exists (normal operation), the effect of the action (transaction processed), and the response measure (within three seconds). Writing such detailed statements is only possible when relevant requirements have been identified and an idea of components has been proposed.

Writing effective scenarios takes some time to learn. But it's an important skill, as it's in the scenarios where the desired vague software behaviors are turned into tangible and measurable goals. Measurable goals tells you what architectural approaches and tactis to apply as you design the system. It's easiest to learn by looking at examples. See this resource on how you can download a catalog of over 100 well defined quality attribute scenarios.

Achieving Qualities

Scenarios help describe the qualities of a system, but they don’t describe how they will be achieved. Architectural tactics describe how a given quality can be achieved. For each quality there may be a large set of tactics available to an architect. It is the architect’s job to select the right tactic in light of the needs of the system and the environment. For example, a performance tactics may include options to develop better processing algorithms, develop a system for parallel processing, or revise event scheduling policy. Whatever tactic is chosen, it must be justified and documented.

Taxonomy of Software Qualities

Over the past 10 years software architects have devised a list of common software qualities. It would be naïve to claim that the list below is as a complete taxonomy of all software qualities – but it’s a solid list of general software qualities compiled from respectable sources. Domain specific systems are likely to have an additional set of qualities in addition to the list below.

System qualities can be categorized into four parts: runtime qualities, non-runtime qualities, business qualities, and architecture qualities. Each of the categories and its associated qualities are briefly described below. Other articles on this site provide more information about each of the software quality attributes listed below, their applicable properties, and the conflicts the qualities.

Runtime System Qualities

Runtime System Qualities can be measured as the system executes.


Functionality
Definition: the ability of the system to do the work for which it was intended.
Performance
Definition: the response time, utilization, and throughput behavior of the system. Not to be confused with human performance or system delivery time.
Security
Definition: a measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.
Availability (Reliability quality attributes falls under this category)
Definition: the measure of time that the system is up and running correctly; the length of time between failures and the length of time needed to resume operation after a failure.
Usability
Definition: the ease of use and of training the end users of the system. Sub qualities: learnability, efficiency, affect, helpfulness, control.
Interoperability
Definition: the ability of two or more systems to cooperate at runtime

Non-Runtime System Qualities

Non-Runtime System Qualities cannot be measured as the system executes.


Modifiability
Definition: the ease with which a software system can accommodate changes to its software
Portability
Definition: the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two.
Reusability
Definition: the degree to which existing applications can be reused in new applications.
Integrability
Definition: the ability to make the separately developed components of the system work correctly together.
Testability
Definition: the ease with which software can be made to demonstrate its faults

Business Qualities

Non-Software System Qualities that influence other quality attributes.
Cost and Schedule
Definition: the cost of the system with respect to time to market, expected project lifetime, and utilization of legacy and COTS systems.
Marketability
Definition: the use of the system with respect to market competition.
Appropriateness for Organization
Definition: availability of the human input, allocation of expertise, and alignment of team and software structure. Business process re-engineering

Architecture Qualities

Quality attributes specific to the architecture itself.


Conceptual Integrity
Definition: the integrity of the overall structure that is composed from a number of small architectural structures.
Correctness
Definition: accountability for satisfying all requirements of the system.

Domain Specific Qualities

Quality attributes found in specific business domains.


Sensitivity
Definition: the degree to which a system component can pick up something being measured.
Calibrability
Definition: ability of a system to recalibrate itself to some specific working range.

Closing Notes

Architectural decisions directly impact system qualities, and often a decision in favor of one quality has an impact on another. It is also important to remember that the benefits of the most applicable architecture design can be eliminated by poor implementation. Next step for this article is to categorize the quality attributes into general and domain specific (e.g. calibrability).

Would you like to see how other software architects apply quality attribute scenarios to address real world problems? Have questions about how to apply this on your projects? Join a Firebrand Architect® cohort.


2013 © SoftwareArchitectures.com | Privacy Policy | Terms of Service