Quality Attributes
Software Quality Attributes are the benchmarks that describe a systems behavior within an environment. 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.
Architecture is critical to the realization of many qualities of interest in a system, and these qualities should be designed in and can be evaluated at the architectural level. Architecture, by itself, is unable to achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if attention is not paid to the details.
Typical Qualities
Typical quality attributes include:
-
System qualities: availability, modifiability, performance, security, testability and usability.
-
Business qualities: e.g. time to market.
-
Architectural qualities: e.g. conceptual integrity
Other qualities not covered here include scalability, portability and interoperability.
Quality Attribute Scenarios
These scenarios address a specific attribute for a requirement. They include:
-
Source of stimulus - the entity (human, computer system, etc.) that generated the stimulus.
-
Stimulus - a condition that needs to be considered when it arrives at a system.
-
Environment - Condition of the system, e.g. running.
-
Artifact - The part of the system that is stimulated.
-
Response - Activity undertaken after the arrival of the stimulus.
-
Response measure - How to measure the response so that the requirement can be tested.
Availability
Availability addresses system failure and the subsequent consequences. This may involve how the system failure is detected, the frequency of failure, failure symptoms, system downtime, when failures may occur safely, failure prevention and failure notifications.
System availability is the probability a system is operational, defined by:
mean time to failure / (mean time to failure + mean repair time)
Consider an availability general scenario:
-
Stimulus source. Differentiate between internal and external symptoms
-
Stimulus
-
omission - A component fails to respond.
-
crash - The component repeatedly suffers omission faults
-
timing - A component responds early or late.
-
response - Responds with incorrect value.
-
-
Artifact - The resource required to be highly available, e.g. processor, process, disk, etc.
-
Environment - The state of the system may affect the system response, e.g. after repeated faults, shutdown system
-
Response - Reactions to stimulus, e.g. logging, notification, switch to degraded mode, etc.
-
Response measure - How to measure the response, e.g. time to repair, availability percentage, etc.
General Availability Scenario Generation
| Scenario Part | Possible Values |
|---|---|
Source |
internal or external |
Stimulus |
omission, crash, timing, response |
Artifact |
System processors, communications channels, storage, processes |
Environment |
Normal, degraded |
Response |
Detect event then one or more of:
|
Response Measure |
|
Modifiability
The cost of a change, specifically:
-
What can change? Functions, platform, environment, system qualities, capacity
-
Who makes the change and when? This is commonly done to source code during implementation, but an end user or system admin could make a change. Time phases could be: implementation, compile time, build, configuration, execution.
| Scenario Part | Possible Values |
|---|---|
Source |
End user, developer, system admin |
Stimulus |
Add/delete/modify/vary functionality, quality attribute or capacity |
Artifact |
User interface, platform, environment, other system |
Environment |
Runtime, compile time, build time, design time, setup, configuration |
Response |
Places to be modified without other effect, test change, deployment |
Response Measure |
Cost in number of elements, effort, duration, money. Extent the change affects other functionality or quality attributes |
Performance
The timing of events, interrupts, messages, user requests or the passage of time and the system response. How long does this take?
| Scenario Part | Possible Values |
|---|---|
Source |
One of multitude independent sources or within system |
Stimulus |
Perdioc event, sporadic events, non-deterministic (stochastic) events |
Artifact |
System |
Environment |
Normal or overloaded mode |
Response |
Processes stimuli, changes to level of service |
Response Measure |
Latency, deadline, throughput, jitter, miss rate, data loss |
For much of the history of software engineering, performance has been the dominant factor in system architecture, often at the expense of other qualities. The commoditisation of hardware has meant other qualities are now serious competitors.
Security
The ability to resist unauthorised usage. Characterised by:
-
Non repudiation - The property that a transaction cannot be denied by any parties (e.g. disputing internet purchase you did make).
-
Confidentiality - Data or services are protected from unauthorised access.
-
Integrity - Data or services delivered as intended (e.g. hacker has changed billing amount)
-
Assurance - Transaction parties are who they claim (e.g. the email from the bank is actually from the back, not a fraudster)
-
Availability - The system is available for genuine use (e.g. denial of service brings down website)
-
Auditing - tracking of activities to later reconstruct them.
| Scenario Part | Possible Values |
|---|---|
Source |
Individual or system that is:
|
Stimulus |
Display data, change/delete data, access service, reduce availability |
Artifact |
System services, data |
Environment |
Online or offline, connected or disconnected, firewalled or open |
Response |
Authenticate user, hide identity, block access, allow access, grant/withdraw permission, record access, store data in format, unexplainable high demand, informs user or system, restricts availability |
Response Measure |
Time, effort or resources to circumvent with probability, probability of detecting attack, probability of identifying responsible party, services available in DOS attack, extent of damage, percentage of legitimate access denied |
Testability
The extent of the ease the software faults can be demonstrated.
| Scenario Part | Possible Values |
|---|---|
Source |
Unit tester, integration tester, system tester, client acceptance tester, user |
Stimulus |
Analysis, architecture, design, class, integration, delivery |
Artifact |
Design, code, application |
Environment |
Development time, design time, compile time, deploy time |
Response |
Access state values, computes values, prepare test environment |
Response Measure |
|
Usability
The ease to perform a task and user support:
-
Time to learn
-
Time to perform task efficiently
-
Impact of errors
-
User customisation
-
Confidence that correct action was taken
| Scenario Part | Possible Values |
|---|---|
Source |
End user |
Stimulus |
Learn system features, use system efficiently, minimise error impact, adapt system, feel comfortable |
Artifact |
System |
Environment |
Runtime or configuration time |
Response |
|
Response Measure |
Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ratio of successful operations, amount of time/data lost |
Business qualities
Often business qualities goals can affect a system architecture:
-
Time to market
-
Cost and benefit
-
System lifetime
-
Target market
-
Rollout schedule - base functionality of first release, enhancements
-
Integration with other systems
Architectural Qualities
Qualities that related directly to the architecture:
-
Conceptual integrity - the architecture should do similar things in similar ways
-
Correctness and completeness
-
Buildability - can be made by the team in a timely manner
Summary
The system quality attributes described are those commonly addressed by software architecture. By using attribute scenarios one can understand the way these attributes can affect the architecture.
