Quality of Service (QoS) Requirements: An Agile Introduction
A quality of service (QoS) requirement pertains to the technical constraints that your solution must fulfill, such as performance-related issues, reliability issues, and availability issues. These types of requirements are often called technical requirements, service-level requirements or non-functional requirements (I don’t like that term as it makes them sound like requirements that won’t work). Examples of QoS requirements are presented in Figure 1. As you can see, QoS requirements are summarized in a similar manner as business rules: they have a name and a unique identifier (my convention is to use the format QoS#). You document QoS requirements in the same manner as business rules, including a description, an example, a source, references to related technical requirements, and a revision history.Figure 1. Technical requirements (summary form).
QoS34 The system shall be available 99.99% of the time for any 24-hour period.
QoS78 A seminar search will occur within less than three seconds 95 percent of the time.
QoS79 A seminar search will occur within no more than ten seconds 99 percent of the time.
Types of QoS Requirements
Potential types of QoS requirements include:
Access control
Accessibility
Accuracy
Concurrency
Consumability/usability
Customization points
Environment/green
Internationalization
Latency
Maintenance
Operations
Performance
Privacy
Reliability
Reuse
Resiliency
Scalability
Security
Serviceability
Supportability
Throughput
Timeliness
QoS Requirements in Practice
I’m a firm believer that you should minimize the number of purely technology-focused QoS requirements. Technology changes quickly and often requirements based on technology change just as quickly. Whenever you have a requirement based purely on technology, try to determine the real underlying business needs being expressed. To do this, keeping asking why your application must meet a requirement. For example, when asked why your application must be written in Java, the reply was it has to run on the Internet. When asked why it must run on the Internet, the reply was your organization wants to take orders for its products and services on the Internet. The real requirement is to sell things to consumers at their convenience; one technical solution to this need (and a good one) is to write that component in Java that can be accessed via the Internet. A big difference exists between having to write the entire application in Java and having to support the sales of some products and services to consumers over the Internet.
QoS requirements are often thought of as constraints, and in fact constraints can apply to either technical or business issues.
