Quality Attributes (QA) A QA is a measureable or testable property of - - PowerPoint PPT Presentation

• J. Scott Hawker/R. Kuehl
• p. 1

R I T

Software Engineering

Some material in these slides is adapted from Software Architecture in Practice, 3rd edition by Bass, Clements and Kazman.

Quality Attributes (QA)

“A QA is a measureable or testable property

• f a system that is used to indicate how well

the system satisfies the needs of its stakeholders.” (SAiP p.63)

• J. Scott Hawker/R. Kuehl
• p. 2

R I T

Software Engineering

Types of Requirements

Business Requirements User Requirements System Requirements Business Rules Quality Attributes External Interfaces Constraints Functional Requirements Vision and Scope Document User Requirements Document Software Requirements Specification

Solid arrow – stored in Dotted arrow – origin of or influence

• J. Scott Hawker/R. Kuehl
• p. 3

R I T

Software Engineering

• Operational categories

– Availability – Interoperability – Reliability – Usability – Performance – Deployability – Scalability – Monitorability – Mobility – Compatibility – Security – Safety

• Developmental categories

– Modifiability – Variability – Supportability – Testability – Maintainability – Portability – Localizability – Development distributability – Buildability

Quality Attributes – Master List

• J. Scott Hawker/R. Kuehl
• p. 4

R I T

Software Engineering

Quality Attribute Scenarios

 Start with QA requirement statements  Elaborate all quality attribute requirements as scenarios

 General – system independent  Concrete – system specific

 As simple informal story-like descriptions …  Or in a semiformal quality attribute scenario representation:

1. Stimulus 2. Stimulus source 3. Artifact 4. Environment 5. Response 6. Response measure

• J. Scott Hawker/R. Kuehl
• p. 5

R I T

Software Engineering

Quality Scenario – Descriptive Table

1.

• Stimulus. The stimulus is a condition that requires a

response when it arrives at a system. 2. Source of stimulus. This is some entity (a human, a computer system, or any other actuator) that generated the stimulus. 3.

• Environment. The stimulus occurs under certain
• conditions. The system may be in an overload condition or

in normal operation, or some other relevant state. For many systems, “normal” operation can refer to one of a number of modes. 4.

• Artifact. Some artifact is stimulated. This may be a

collection of systems, the whole system, or some piece or pieces of it. 5.

• Response. The response is the activity undertaken as the

result of the arrival of the stimulus. 6. Response measure. When the response occurs, it should be measurable in some fashion so that the requirement can be tested.

• J. Scott Hawker/R. Kuehl
• p. 6

R I T

Software Engineering

Quality Scenario – General Availability

• J. Scott Hawker/R. Kuehl
• p. 7

R I T

Software Engineering

Quality Scenario – Concrete Availability

• J. Scott Hawker/R. Kuehl
• p. 8

R I T

Software Engineering

Performance QA Scenario

 The stock market trading system shall be able to process sell orders initiated by trading bots within 1 msec.  QA Scenario:

 Source:  Source stimulus:  Artifact:  Environment:  Response:  Response measure:

• J. Scott Hawker/R. Kuehl
• p. 9

R I T

Software Engineering

Nonfunctional Requirements

 System requirements

 Associated hardware, inputs and outputs, major software components  System architecture is not necessarily the software architecture

 External interfaces

 Interfaces to devices and systems across the system boundary  E.g, legacy systems, services, peripheral devices

 Constraints – limiting factors

 E.g., technology choices, standards, business rules, laws, etc.

• J. Scott Hawker/R. Kuehl
• p. 10

R I T

Software Engineering

Requirements Assumptions and Dependencies

 Business and technology  Assumptions – stuff you expect to happen (versus known facts)

 Project impacts if incorrect or they change

 Dependencies – stuff that is needed from external sources  Examples of “stuff” – schedules, budget, contracts, intellectual property, people resources, equipment resources, licenses, standards, regulations, open source software, external APIs, cloud services, development tools, …