SW Architecture | Quality Attributes


  • The software architecture of any system is mainly influenced by extra-functional, or non functional, qualities
  • How to express the qualities we want our architecture to provide?
  • What does it mean to say that a system is modifiable or reliable or secure

Functionality vs Quality Attributes

Functionality and architectural qualities are orthogonal

Some important qualities

  • Usability
  • Modifiability
  • Performance
  • Security
  • Testability
  • Availability
  • Time to market
  • Cost and benefit
  • Projected System lifetime
  • Targeted Market
  • Rollout Schedule
  • Integration / Legacy

Some qualities are architectural

  • Conceptual Integrity the design is coherent
  • Correctness the design is correct wrt to the requirements
  • Completeness the design covers all the requirements
  • Flexibility the design supports future changes to its requirements
  • Reusability the design uses existing assets
  • Buildability the design is realistic and suitable for its context

Qualities and trade-offs

  • The qualities are all good
  • The value of a quality is project specific
  • The qualities are not independent

Quality Attribute Scenario

  • Source of stimulus
  • Stimulus
  • Environment
  • Artifact
  • Response
  • Response measure

In the environment, the source throws the stimulus and hits the system in the artifact


  • One stimulus per scenario
  • One environment per scenario
  • One artifact per scenario
  • Multiple response measures are OK

Qualities must be testable

To be effective, quality attribute scenarios must be testable (just like any other requirement)
Therefore, the following items must be clear and specific

  • Stimulus
  • Artifact
  • Environment
  • Response measure(s)

Different quality attributes

  • Modifiability is about the cost of change, both in time and money. Performance is about timeliness. Events occur and the system must respond in a timely fashion.
  • Testability refers to the ease with which the software can be made to demonstrate its faults or lack thereof. To be testable the system must control inputs and be able to observe outputs
  • Maintainability is the ease with which a product can be maintained in order to isolate and correct defects, prevent unexpected breakdowns, meet new requirements
  • Usability is how easy it is for the user to accomplish tasks and what support the
  • system provides for the user to accomplish this. Dimensions: Learning system features
    • Using the system efficiently
    • Minimizing the impact of errors
    • Adapting the system to the user’s needs
    • Increasing confidence and satisfaction
  • Availability is concerned with system failure and duration of system failures. System failure means un-readiness for correct service, when the system does not provide the service for which it was intended
  • Reliability: the ability of a system or component to function under stated conditions for a specified period of time (=continuity of correct service)
  • Dependability: availability + reliability + maintainability Safety absence of catastrophic consequences on the users or the environment
  • Security is the ability of the system to prevent or resist unauthorized access while providing access to legitimate users. An attack is an attempt to breach security

Quality Attributes Types

  • System Qualities
  • Business Qualities
  • Architecture Qualities

System Qualities

System Quality Scenarios

  1. Availability Scenario
  2. Modifiability Scenario
  3. Performance Scenario
  4. Security Scenario
  5. Testability Scenario
  6. Usability Scenario
  7. Scalability Scenario
  8. Portability Scenario


  • “What’s the probability that the system works when I need it?”
  • Concerns: mean time to failure
    • fault detection
    • repair time
    • fault masking
    • ..
availability =  mean time to failure / (mean time to failure + mean time to repair)

General Availability Scenario

Sample Availability Scenario

 Source Stimulus Environment Response Measure
  Fault:  detect failure and do one or more of: 
 Internal to system Crash Normal operation Prevent the failure Time interval available
 External to system Omission Startup Log the failure Availability %
  Timing Shutdown Notify users/operators Detection time
  No response Repair mode Disable source of failure Repair time
  Incorrect response Degraded (failsafe) mode Temporarily unavailable Degraded mode time interval
   Overload protection Continue (normal/degraded) Unavailability time interval


  • What can change?
    • platforms
    • environment
    • requirements:
      • performance
      • reliability
      • capacity
  • When is the change made?

Reinstallation, plug-in, configuration, platform change.

General Modifiability Scenario

Sample Modifiability Scenario

Source Stimulus Environment Response Measure
  Add/delete/modify:   costs
End user Functionality Runtime Make modification Cost in effort
Developer Quality attribute Compile time Test modification Cost in money
 System administrator Capacity or technology Build time Deploy modification Cost in time
   Initiation time  Cost in number, size, complexity of affected artifacts
   Design time  Extent affects other system functions or qualities
     New defects introduced


  • Timing in the system
  • Response time

General Modifiability Scenario

Sample Modifiability Scenario

Source Stimulus Environment Response Measure
  arrival of   
 Internal to the system Periodic events Normal mode Process events Latency
 External to the system Sprodaic events Overload mode Change levels of service Deadline
  Bursty events Reduced capacity mode  Throughput
  Stochatics events Emergency mode  Jitter
   Peak mode  Miss rate
     Data loss


To resist unauthorized usage:
• access to data
• access to system service
• hinder normal system operation

General Security Scenario

Sample Security Scenario

Source Stimulus Environment Response Measure
 Identified user or system Attempt to display data Normal mode Process events Latency
 Unknown user or system Attempt to delete data Overlaod mode Change level of service Deadline
 Hacker from outside the organization Attempt to modify data Reduced capacity mode authenticates the user Throughput
 Hacker from inside the organization Access system services Emergency mode hides identity of the user Jitter
 authorized – not authorized Change system’s behavior Peak mode blocks access to data/services Miss rate
 access to
– limited resources
– vast resources
 Reduce system availability online – offline  Data loss
   connected – disconnected  effort to circumvent security
   firewall or open  probability of attack detection


  • How easy will it be to test the system “40% of system cost use to be testing”
  • How likely to find and eliminate errors

General Testability Scenario

Sample Testability Scenario

Source Stimulus Environment Response Measure
 Unit tester Execution of tests due to completion code increment Design time Execute test suite & capture results Effort to find fault
 System tester  Development time Capture causes of fault Effort to achieve coverage %
 Integration tester  Compile time Control & monitor state of the system Probability to fault being revealed in next test
 Acceptance tester  Integration time  Time to perform tests
 End user  Deployment time  Efforts to detect faults
 Automated testing tools  Runtime  Length of longest dependency chain
     Time to prepare test environment
     Reduction in risk exposure


  • How to learn to use the system
  • How to use the system efficiently
  • Minimize the impact of user error
  • System adaptability to user needs.
  • User confidence

General Usability Scenario

Sample Usability Scenario

 Source Stimulus Environment Response Measure
  wants to   
 End user (possibly special role) Use the system efficiently Runtime Provide features needed Task time
  Learn to use the system Configuration time Anticipate the user’s needs Number of errors
  Minimize impact of errors  to support learning help system .. Number of task accomplished
  Adapt the system  to support efficient use
– aggregation of commands/data
– reuse of entered data/command
 User satisfaction
  Configure the system  to minimize impacts of errors
-undo /cancel /recovery / recognition of user error
 Gain of user knowledge
  User feels comfortable  to adapt system
– customizability
 Ratio of successful operation to total operations
    to feel comfortable
– display system state
 Amount of time/data lost when error occurs



Business Qualities

  • Time to market
  • Cost and benefit
  • Projected system lifetime
  • Targeted market
  • Rollout schedule
  • Integration with legacy systems

Architectural Qualities

  • Conceptual integrity
  • Correctness and completeness
  • Buildability