Qualities of Service

Qualities of Service Scenarios are extremely valuable, but they are not the only type of requirement. Scenarios need to be understood in the context of qualities of service (QoS). (Once upon a time, QoS were called "nonfunctional requirements," but because that term is nondescriptive, I won't use it here. Sometimes they're called 'ilities, which is a useful shorthand.) Most dissatisfiers can be eliminated by appropriately defining qualities of service. QoS might define global attributes of your system, or they might define specific constraints on particular scenarios. For example, the security requirement that "unauthorized users should not be able to access the system or any of its data" is a global security QoS. The performance requirement that "for 95% of orders placed, confirmation must appear within three seconds at 1,000user load" is a specific performance QoS about a scenario of placing an order. Not all qualities of service apply to all systems, but you should know which ones apply to yours. Often QoS imply large architectural requirements or risk, so they should be negotiated with stakeholders early in a project. There is no definitive list of all the qualities of service that you need to consider. There have been several standards,[16] but they tend to become obsolete as technology evolves. For example, security and privacy issues are not covered in the major standards, even though they are the most important ones in many modern systems. The following four sections list some of the most common QoS to consider on a project. Security and Privacy Unfortunately, the spread of the Internet has made security and privacy every computer user's concern. These two QoS are important for both application development and operations, and customers are now sophisticated enough to demand to know what measures you are taking to protect them. Increasingly, they are becoming the subject of government regulation. Security: The ability of the software to prevent access and disruption by unauthorized users, viruses, worms, spyware, and other agents. Privacy: The ability of the software to prevent unauthorized access or viewing of Personally Identifiable Information. Performance Performance is most often noticed when it is poor. In designing, developing, and testing for performance, it is important to differentiate the QoS that influence the end experience of overall performance. Responsiveness: The absence of delay when the software responds to an action, call, or event. Concurrency: The capability of the software to perform well when operated concurrently with other software. Efficiency: The capability of the software to provide appropriate performance relative to the resources used under stated conditions.[17] Fault Tolerance: The capability of the software to maintain a specified level of performance in cases of software faults or of infringement of its specified interface. [18] Scalability: The ability of the software to handle simultaneous operational loads. User Experience While "easy to use" has become a cliché, a significant body of knowledge has grown around design for user experience. Accessibility: The extent to which individuals with disabilities have access to and use of information and data that is comparable to the access to and use by individuals without disabilities.[19] Attractiveness: The capability of the software to be attractive to the user.[20] Compatibility: The conformance of the software to conventions and expectations. Discoverability: The ability of the user to find and learn features of the software. Ease of Use: The cognitive efficiency with which a target user can perform desired tasks with the software. Localizability: The extent to which the software can be adapted to conform to the linguistic, cultural, and conventional needs and expectations of a specific group of users. Manageability Most modern solutions are multitier, distributed, serviceoriented or clientserver applications. The cost of operating these applications often exceeds the cost of developing them by a large factor, yet few development teams know how to design for operations. Appropriate QoS to consider are as follows: Availability: The degree to which a system or component is operational and accessible when required for use. Often expressed as a probability.[21] This is frequently cited as "nines," as in "three nines," meaning 99.9% availability. Reliability: The capability . . . to maintain a specified level of performance when used under specified conditions.[22] Frequently stated as Mean Time Between Failures (MTBF). Installability and Uninstallability: The capability . . . to be installed in a specific environment[23] and uninstalled without altering the environment's initial state. Maintainability: The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.[24] Monitorability: The extent to which health and operational data can be automatically collected from the software in operation. Operability: The extent to which the software can be controlled automatically in operation. Portability: The capability of the software to be transferred from one environment to another.[25] Recoverability: The capability of the software to reestablish a specified level of performance and recover the data directly affected in the case of a failure.[26] Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.[27] Supportability: The extent to which operational problems can be corrected in the software. Conformance to Standards: The extent to which the software adheres to applicable rules. Interoperability: The capability of the software to interact with one or more specified systems.[28] What makes a good QoS requirement? As with scenarios, QoS requirements need to be explicitly understandable to their stakeholder audiences, defined early, and when planned for an iteration, they need to be testable. You may start with a general statement about performance, for example, but in an iteration set specific targets on specific transactions at specific load. If you cannot state how to test satisfaction of the requirement when it becomes time to assess it, then you can't measure the completion.