Architecture Quality Attributes

From Wiki
Jump to navigationJump to search


  • Qualities that must be accommodated in a systems architecture over and above basic functionality.
  • Functionality and quality attributes are mostly independent.
  • Functionality can be achieved in any number of ways. It is mostly independent of structure.
  • We need to choose the right way/structure so that quality attributes are met.
  • Categories of quality attributes:
    • Observable attributes. e.g:
      • Performance
      • Usability
      • Functionality
      • Security
      • Availability
    • Unobservable attributes. e.g:
      • Modifiability
      • Reusability
      • Testability
      • Portability
      • Certifiability
    • Business attributes.e.g:
      • Time to market
      • Overall cost
      • Longevity
      • Backward compatibility

Quality Attribute Scenarios

  • Meaningless to say System is modifiable, reusable etc. How do we justify it ?
  • Quality Attributes are best characterised via scenarios.
  • SEI format for QA scenarios:
    • Source of stimulus: The entity (human, computer system) that has generated the stimulus.
    • Stimulus: The stimulus is a condition that needs to be considered when it arrives at a system.
    • Environment: The prevailing condition when the stimulus occurs (e.g. system may be overloaded when stimulus occurs or maybe the system is in normal operating conditions)
    • Artifact: Some piece of the system is stimulated. This may be the whole system or some pieces of it.
    • Response: The response is the activity undertaken after the arrival of the stimulus.
    • Response Measure: When the response occurs, it should be measurable so that the requirement can be tested.
  • General QA scenarios: These scenarios are system independent and can be applied to any system.
  • Specific QA scenarios: These scenarios are derived from the general scenario by instantiating each part. They are specific to the particular system under consideration.
  • For e.g. there is a general availability scenario with a range of values that each part (source, stimulus, env etc) can take. From this we can derive concrete, system specific scenarios.

Observable Quality Attributes


  • Availability is concerned with system failure and its associated consequences.
  • A fault may become a failure if not corrected or masked.
  • Availability of a system is the probability that it will be operational when it is needed.
  • Defined as (MTTF)/(MTTF + MTTR). Where MTTF = Mean Time to Failure and MTTR = Mean Time to Repair.

General Scenario

  • Source: Internal or external to the system.
  • Stimulus: The stimulus is a fault. The fault can be omission (fails to respond), crash (repeatedly suffers omission faults), timing (late or early response), response itself (incorrect)
  • Artifact: The part of the system that is required to be highly available (processor, communication channel, storage etc)
  • Environment: Normal/Degraded.
  • Response: One or more of : Logging, Notifying, Disable source of events, become unavailable, continue to operate in normal or degraded mode.
  • Response Measure: Time interval when the system must be available or a repair time.


  • Is all about timing. Basically concerned with how long it takes the system to respond when an event occurs.

General Scenario

  • Source: Internal or external to the system.
  • Stimulus: Periodic/Sporadic/Stochastic events arrive.
  • Artifact: System
  • Environment: Normal mode; Overload mode
  • Response: Stimuli must be processed (events handled); change in level of service (normal to degraded)
  • Response Measure: Latency - DL by which the event must be processed, Jitter, Throughput, Miss rate, Data loss.


  • Security is a measure of the system's ability to resist unauthorized usage while still providing services to legitimate users.
  • Security can be characterized by a system providing:
    • Non-repudiation : One cannot deny that an action took place.
    • Confidentiality: Data is protected from unauthorized access.
    • Integrity: Data is delivered as intended, no modification in between.
    • Assurance: Parties are who they claim they are.
    • Availability: System will be available for legitimate use e.g. DoS will not prevent.
    • Auditing: System tracks activities.

General Scenario

  • Source: Human or system who can be correctly/incorrectly identified, who is internal/external with access to some resources.
  • Stimulus: View data, Change Data, access system services, reduce availability to system services.
  • Artifact: System services, System data
  • Environment: Online/offline, connected/disconnect, behind firewall, open to network.
  • Response: Authenticates user, allows access, blocks access, grants/withdraws permissions, records access, informs a user or another system.
  • Response measure: Time/effort/resources required by an attacker to bypass security measures, probability of detecting attack, probability of identifying individual responsible, extent to which data/services are damaged, restoring data/services after attack.


  • Concerned with how easy it is for the user to accomplish a desired task and kind of support the system provides.
  • Things like: (Basically usability principles)
    • Learning system features, Using a system efficiently, minimize impact of errors, adapt system to user needs, increase confidence and satisfaction.

General scenario

  • Source: Always the end user.
  • Stimulus: Wants to use system efficiently, learn system features, minimize impact of errors, adapt system, feel comfortable.
  • Artifact: Is always the system.
  • Environment: At runtime or at system configuration time.
  • Response: Provides user with one or more:
    • Support learn system: - Context sensitive help, familiar interface
    • Support use system efficiently: - Provide shortcuts, search, reuse of commands etc.
    • Minimize impact of errors: Support cancel, undo, abort, recover password etc
    • Adapt System: I18N, Customizability.
    • Feel comfortable: Display system state, work at the user's pace.
  • Response Measure: Task time, number of errors, user satisfaction, gain of user knowledge etc.

Unobservable Quality Attributes


  • Modifiability is about the cost of change. Two aspects:
  • Which artifact can change ? : functions, platforms, capacity, UI etc..
  • When is the change made and who makes it ? Source code by Developer, UI by end user, Compile time changes, Run time flags, settings etc, Configuration parameters.

General Scenario

  • Source: The person making the changes - Developer, Sys Admin, End User
  • Stimulus: Desire to add/edit/delete functionality, quality attribute, capacity.
  • Artifact: System UI, functionality, platform, environment
  • Environment: At runtime, compile time, build time, design time.
  • Response: Locates place where change can be made, makes modification independently, tests modification, deploys modification.
  • Response Measure: Cost in terms of no. of elements, quality attributes effected, effort, money etc.


  • Ease through which software can be made to demonstrate its faults through testing.
  • For a system to be testable, it must be possible to control each components internal state and inputs and then to observe its outputs.

General Scenario

  • Source: Unit developer, Integration/System/client acceptance tester, System user.
  • Stimulus: Completion of Analysis, architecture, design, class, system increment.
  • Artifact: Piece of design, piece of code, complete application.
  • Environment: At design time, compile time, deployment time.
  • Response: Provide access to state values, provides computed values.
  • Response Measure: Percent executable statements executed, time to perform tests, Probability of failure if fault exists.


  • How easily can a system be moved to a different target environment.
  • Usual strategy: decouple provider from user.
  • However interfaces take time to define and add run-time penalty.
  • Who pays ? Current project manager might be reluctant, if benefits are only for future projects.


  • How easily different parts of the system work together ?
  • Common interfaces in terms of data structures and protocols.


  • Linked to portability and integrability.
  • Reuse within the same system as well as across systems.
  • Depends on degree of coupling.

Business Qualities

  • Time to market: Development time, pressure to buy COTS. Will be easier if system is decomposed into elements.
  • Cost and benefit: Architecture that is highly flexible or relies on technology will be more expensive to build.
  • Projected lifetime of the system: Long life systems need to have high modifiability, portability, scalability.
  • Targeted market: If mass market, the platforms on which a system runs determine size. Thus, portability is key. Product line approach should be considered.
  • Rollout schedule: If product introduced in increments, then flexibility, customizability are key.
  • Integration with legacy systems: Integrability is important.

Quality of Architecture

  • Conceptual Integrity: is the underlying theme or vision that unifies the design of the system at all levels. e.g. Built for massive scalability where scalability is the underlying theme.
    • Better to leave out features if they are not central to theme.
  • Correctness and completeness:
    • Essential to allow all system requirements and resource constraints to be met.
  • Buildability: System needs to be completed by available team in a timely manner and be open to changes.
    • Tasks easily split into development teams.