Quality Attributes (QA) “A QA is a measureable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders.” (SAiP p.63) Some material in these slides is adapted from Software Architecture in Practice, 3rd edition by Bass, Clements and Kazman. J. Scott Hawker/R. Kuehl p. 1 R I T Software Engineering
Types of Requirements Business Requirements Business Rules Vision and Scope Document Quality Attributes User Requirements User Requirements Document External Interfaces System Functional Constraints Requirements Requirements Software Requirements Specification Solid arrow – stored in Dotted arrow – origin of or influence J. Scott Hawker/R. Kuehl p. 2 R I T Software Engineering
Quality Attributes – Master List • Operational categories • Developmental categories – Availability – Modifiability – Interoperability – Variability – Reliability – Supportability – Usability – Testability – Performance – Maintainability – Deployability – Portability – Scalability – Localizability – Monitorability – Development distributability – Mobility – Buildability – Compatibility – Security – Safety J. Scott Hawker/R. Kuehl p. 3 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. 4 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. 5 R I T Software Engineering
Quality Scenario – General Availability J. Scott Hawker/R. Kuehl p. 6 R I T Software Engineering
Quality Scenario – Concrete Availability J. Scott Hawker/R. Kuehl p. 7 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. 8 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. 9 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, … J. Scott Hawker/R. Kuehl p. 10 R I T Software Engineering
Recommend
More recommend
