1 / 29

Quality requirements

Quality requirements. A quality goal (requirement) is a specified achievement level of a quality attribute e.g., security Since quality attributes can conflict, e.g., security and usability, tradeoffs may be necessary. Quality models are embedded in requirements models

hoffp
Download Presentation

Quality requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quality requirements A quality goal (requirement) is a specified achievement level of a quality attribute e.g., security Since quality attributes can conflict,e.g., security and usability, tradeoffs may be necessary Quality models are embedded in requirements models Quality goals (requirements) should be derived from useful quality models

  2. An essentially-complex requirements model Not all types are necessary in every set of requirements Note major role played by developers

  3. Crosscutting requirements Some requirements (e.g., supplier attributes or project deadlines) impact no code. Local requirements(such as the CRUD functions for domain objects e.g., reservations) only impact a few components. Crosscutting requirements(such as most quality support functions e.g., safeguards) impact code in many components. 3

  4. Types of crosscuts Universal crosscuts (e.g., coding standards) impact all code. Homogeneous crosscuts (e.g., logging functions) do the same thing wherever they appear. Heterogeneous crosscuts (e.g., security guards) do different things wherever they appear, because they are context-sensitive. 4

  5. Domain functionality is just the beginning A component To minimize quality debt, crosscutting requirements should be identified early 5

  6. Developing quality-support strategies - 1 • Developers must: • Selectrelevant qualities. • Identify their supporting qualities and potential conflicts. • Specifygoals for each selected quality along with levels and priorities. • Identifyup to three candidate architectures based on the software’s core functionality as well as its contextual elements, constraints, and qualities. • For each architectural candidate, outline achievement, monitoring, and verification strategies for the high-priority qualities until a single architecture emerges. 6

  7. Developing quality-support strategies - 2 • For the selected architecture, designan achievement, monitoring, and • verification strategy for each selected quality and estimate their effort. • Reference stringent design and coding standards, promoting software understandability, whose compliance will be verified. • When appropriate, develop a glossary of precise definitionsfor domain concepts, verifiable quality measures, and terminology in the achievement and verification strategies. • For critical qualities and their supports, use assurance casesto verifying the adequacy of the achievement and verification strategies. • Carry outthe strategies to achieve, monitor, and verify each selected quality on each development increment. 7

  8. Quality Requirements UpFront (QRUF) QRUF development means doing as much of the first six tasks as possible at the beginning of a project so the last task can be carried out on each developmental increment. This tactic mitigates the pervasive risk of significant quality debt. A tailored version of the LiteRM quality model helps with strategy development tasks 1, 2, 3, 5, and 6. If a team is NOT using a tailored version of this model,they are working too hard ornot hard enough. 8

  9. What makes a quality model useful? Significant support for4quality requirement development tasks: • Selectrelevant qualities. • Identify their supporting qualities and potential conflicts. • Specifygoals for each selected quality along with levels and priorities. • For the selected architecture, designan achievement, monitoring, and verification strategy for each quality and estimate their effort.

  10. BABOK quality model • Availability • Compatibility • Functionality • Maintainability • Performance Efficiency • Portability • Reliability • Scalability • Security • Usability • Certification • Compliance • Localization • Service Level Agreements • Extensibility (Almost) alphabetical list of 15 qualities

  11. ISO 25010 2-Dquality model • Internal qualities (which support all others) are tucked under Maintainability • understandability – missing • reviewability – missing • verifiability - missing

  12. Quality models for certification IIBA – CBAP based on list 9000 CBAP certified QAI– CSQA based on list 22000 to 25000 CSQA certified world-wide IREB – CPRE based on list, but references ISO model 56700 in 84 countries have passed the CPRE Foundation Level ASQ – CSQE based on list, but references ISO model 1500 CSQE certified world-wide 90,000 professionals certified based on simplistic quality models

  13. SEI 2-D quality model PART TWO QUALITY ATTRIBUTES CHAPTER 4Understanding Quality Attributes (19) CHAPTER 5Availability (25) CHAPTER 6Interoperability (15) CHAPTER 7Modifiability (15) CHAPTER 8Performance (17) CHAPTER 9Security (13) CHAPTER 10Testability (17) CHAPTER 11Usability (11) CHAPTER 12Other Quality Attributes (19)

  14. Wiegers & Beatty 3-D quality model

  15. LiteRM 3-D quality model a internal qualities directly visible only to developers external qualities fully visible to users mixed qualities partially visible to users [think icebergs] a a

  16. Basic internal qualities support all others Runtime self-checking Mainly verified by reviews, analysis, and measurement 3 pillars of internal quality

  17. Some external & mixed qualities Primarily verified during system test Needs full range of verification tactics

  18. Support relationships between types Basic internalssupportall other qualities including themselves Some externalssupport some mixed

  19. Common characteristics and values [1 of 4] • DefinitionSafety: A system’s ability to do little or no harm to valuable assets • Software subfield Safety engineering • Assumptions/Rationale • Safety is a fragile quality because it depends on many other qualities and the accurate identification of safety hazards. • Leading indicators– provide preoperational evidence of quality goal achievement • Ratio of hazards added during HA technical review to hazard count after HA technical review • Ratio of safeguard defects found during a technical review to number of safeguards • Ratio of safeguard defects found during testing to number of safeguards • Operational measures • Number of “dangerous” failures or defects detected per time interval • Greatest harm from a harmful event • Ratio of actual loss to acceptable loss in a duration

  20. Common characteristics and values [2 of 4] • Supported bydependability, ease of learning • Conflicts withefficiency, interoperability, adaptability qualities • Threats [identify using hazard analysis] • Mitigations [identify after identifying hazards] • Other achievement tactics • identify safety-critical users • identify valuable assets and hazards • identify safety-critical and safety-related functions and constraints • isolate and protect safety-critical functions • guard safety-critical functions with explicit conditions • alert users to dangerous actions with rotating warning messages • precede each dangerous action with a delay so users can change their minds and cancel • design interfaces that prevent and detect user errors

  21. Common characteristics and values [3 of 4] • Verification tactics • verify all supporting qualities • conduct a safety audit to review hazards and mitigations for completeness and effectiveness • thoroughly test each safeguard • track time since last “dangerous” failure or defect • track number of “dangerous” failures or defects • monitor for misbehavior e.g., unanticipated acceleration • monitor system state to make sure safety-critical and safety-related functions are active • Elicitation questions • Associated tools • Resources[pointers] • Risk factors • a. Developer understanding = [superficial, limited, deep] • b. Cost of implementation, verification, & maintenance = [high, medium, low] • c. Feasibility (technical, cost, understanding) = [low, medium, high]

  22. Resourcesfor qualities with large “bodies of knowledge”

  23. Common characteristics and values [4 of 4] Other features a. Sources/Enterprise goals: b. Type = mixed behavior quality c. Associated scope = [system, <specific partitions>] d. Design scope = het cc [het cc, hom cc, universal, local] e. Consensus priority = [critical, important, desirable] f. Architecture-relevant = yes [yes, maybe, no] Past quality goal specs Past achievement, verification, and monitoring strategies Current quality goal spec Current achievement, verification, and monitoring strategies

  24. Features of the LiteRM quality model • 3-dimensional • dynamic • tailorable • improvable • embedded quality goals & strategies • essentially complex • mildly defective • incomplete,but provides a rich template • and many examples of characteristics • supporting the quality achievement tasks

  25. Fun is big business Video game industry earns over $100B USD per year A target market ? $90B USD lifetime 65% of American adults play video games

  26. Example of Planguage Quality Measure

  27. Comparing usefulness of quality models

  28. Resources http://www.quality-aware.com/software-quality-KB.php 1. Downloadable LiteRM quality model (pdf) with > 60 qualities > 30 characteristics per quality 2. Downloadable chapter on quality goals (pdf)

  29. Thanks For Listening Contact Dave with questions, defects, and comments E-mail: david@clearspecs.com Phone: +1 480-296-3559

More Related