1. Defining non-func rq by Planguage
1.1. To address the problem of ambiguous and incomplete nonfunctional requirements, consultant Tom Gilb (1988; 1997) has developed Planguage
1.2. a planning language with a rich set of keywords that permits precise statements of quality attributes and other project goals (Simmons 2001).
1.3. tag
1.3.1. Each requirement receives a unique tag
1.4. ambition
1.4.1. The ambition states the purpose or objective of the system that leads to this requirement
1.5. Scale
1.5.1. Scale defines the units of measurement
1.6. meter
1.6.1. describes precisely how to make the measurements
1.7. specify several target values for the quantity being measured
1.7.1. The must criterion is the minimum acceptable achievement level
2. Atts trade-off
2.1. Certain attribute combinations have inescapable trade-offs
2.2. Users and developers must decide which attributes are more important than others
2.3. matrix of QA
3. Implement non-func rq
3.1. Translating Quality Attributes into Technical Specifications
3.2. Functional requirement
3.2.1. Integrity, interoperability, robustness, usability, safety
3.3. System architecture
3.3.1. Availability, efficiency, flexibility, performance, reliability
3.4. Design constraint
3.4.1. Interoperability, usability
3.5. Design guideline
3.5.1. Flexibility, maintainability, portability, reliability, reusability, testability, usability
3.6. Implementation constraint
3.6.1. Portability
4. Quality Attributes
4.1. Several dozen product characteristics
4.2. Important Primarily to Users
4.2.1. Availability
4.2.2. Efficiency
4.2.3. Flexibility
4.2.4. Integrity
4.2.5. Interoperability
4.2.6. Reliability
4.2.7. Robustness
4.2.8. Usability
4.3. Important Primarily to Developers
4.3.1. Maintainability
4.3.2. Portability
4.3.3. Reusability
4.3.4. Testability
5. Defining QA
5.1. Consider asking users what would constitute unacceptable performance, usability, integrity, or reliability
5.2. Planguage
5.3. Attributes Important to Users
5.3.1. Availability is a measure of the planned up time during which the system is actually available for use and fully operational
5.3.2. Efficiency is a measure of how well the system utilizes processor capacity, disk space, memory, or communication bandwidth
5.3.3. Flexibility Also known as extensibility, augmentability, extendability, and expandability, flexibility measures how easy it is to add new capabilities to the product
5.3.4. Integrity—which encompasses security
5.3.5. Interoperability indicates how easily the system can exchange data or services with other systems
5.3.6. The probability of the software executing without failure for a specific period of time is known as reliability
5.3.7. Robustness A customer once told a company that builds measurement devices that its next product should be "built like a tank."
5.3.8. Usability Also referred to as ease of use and human engineering, usability addresses the myriad factors that constitute what users often describe as user-friendliness
5.4. Attributes Important to Developers
5.4.1. Maintainability indicates how easy it is to correct a defect or modify the software
5.4.2. The effort required to migrate a piece of software from one operating environment to another is a measure of portability
5.4.3. A long-sought goal of software development, reusability indicates the relative effort involved to convert a software component for use in other applications
5.4.4. Also known as verifiability, testability refers to the ease with which software components or the integrated product can be tested to look for defects
5.5. Performance requirements define how well or how rapidly the system must perform specific functions
5.5.1. examples: PE-1. The temperature control cycle must execute completely in 80 milliseconds.