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.

general availability scenario

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:

  • record event

  • notify user or other systems

  • disable sources according to rules

  • make unavailable for period

  • continue operation in normal or degraded mode

Response Measure

  • Interval that the system must become available

  • Availability time

  • Degraded mode interval

  • Repair time

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:

  • correctly identified, identified incorrectly, unknown identity who is:

  • internal/external, authorised/unauthorised with access to:

  • limited or vast resources

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

  • Percent of statements executed

  • Probability of failure if a fault exists

  • Time to perform tests

  • Time to prepare test environment

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

  • Learn features - context sensitive help, familiar interface, usable interface in unfamiliar context

  • Use system efficiently - Aggregation of data or commands, reuse of data/commands, interface navigation, distinct views with consistent operations, searching, simultaneous tasks

  • Minimise error impace - undo, cancel, recover, correct user error, retrieve password, verify resources

  • Comfort - Display system state, work at users pace

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.


comments powered by Disqus