The requirements set captures both functional requirements (such as data and process) as well as non-functional requirements (such as product and project related requirements). Under the category of non-functional requirements, these are not typically captured by CASE tools or by following a popular technique or methodology. It is important to capture the non-functional requirements to determine the impact they will have on the functional requirements and ultimately the affect they may have on your final product.

The Quality of Service Anti-Pattern concentrates on the subset of product constraints that pertain to Quality of Service (QoS) requirements. A QoS requirement is a type of non-functional requirement. The QoS Anti-Pattern is designed to ensure that the requirement supplier's expectations are understood. Expectations are requirements that will constrain the designer's choices for the product.

Defining a list of QoS requirements without an association with the functional requirements does not specifically identify the impact of the requirement. Without the association, the expectations will be vague and probably not satisfied.

A similar anti-pattern can be tailored to support other product and project constraints. The reason for segregating the quality of service requirements from the other types of constraints is because of the direct impact they have on the system product.

Specifically, this anti-pattern covers the following three constraints:

• Performance. The product must perform within the time frame as specific for each functional requirement.
• Usability. The product must be easy to use as specified by each functional requirement. Associating this usability requirement to functional requirements will qualify by supplying a means to quantify the ease of use.
• Privacy. To protect the identity of the customer and business partners from unauthorized users, both inside and outside the corporation. Their information (e.g., email addresses) cannot be sold to any individual or organization without permission. They must not be spammed with a flood of emails, newsletters, or announcements.

The preceding three Quality of Service requirements were selected as a sample. The same technique described in the anti-pattern should be used for all of the QoS indicators. A more complete list of QoS examples can be found in the IEEE System Requirement Specification Standard (STD 1233: SyRS). The list identifies an assortment of non-functional product constraint type requirements.

These sample QoS requirements are specified in an ambiguous manner. The reason is that the value, the means of identifying that the requirement is satisfied, will vary by the relationship to functional requirements.

The first step in using this Anti-Pattern is to identify the list of QoS requirements that you want to include. We have seen some clients implement a separate anti-pattern for each type of QoS requirement. This is only recommended if different people support each type of QoS requirement. The downside is the maintainability of all the anti-patterns.

The second step is to describe what is meant by each of the quality of service topics. For example, what does usability, performance, and privacy mean in general? All reviewers of both the requirements and the process must agree on the definition during the planner perspective. It is important to define the need for such QoS requirements and that the definition be clear, concise, and correct. The QoS requirements will be further defined when associated with specific individual requirements.

The owner perspective is the key to understanding the impact that each quality of service requirements has on the proposed system. Each functional requirement needs to be identified and the impact quantified. This means that there is an understanding of the expectation the requirement supplier has with respect to usability, performance, and privacy to each functional requirement.

A table can be created, or a separate list of functional requirements can be prepared to lay out expectations for specific quality of service requirements. The first column would contain the functional requirement identifier and name. The following columns would list the type of Quality of Service requirements, in this case, usability, performance, and privacy. This can be done in a spreadsheet program or with a requirements management tool. A requirements management tool should allow you to hyperlink to see requirement detail, if needed.

The cross-section between the QoS and the individual functional requirement would identify the "qualifier." Here are some examples.

• The trade-matching event (when) must perform (QoS) within 3 seconds (qualifier) of receiving a trade instruction.
• The password (what/data) must be re-supplied and verified (privacy) when displaying (event) any data about an individual (who/actor; why/business rule).
• Placing an order (when/event) must be a maximum of three-clicks (usability) to complete (how/process).

Each of the correlations between the individual functional requirement and the quality of service requirements are to be considered separate derived requirements. They associate the general QoS requirement with the functional cells.

Listing all of the QoS requirements in the product constraint cell illustrates that product expectations were elicited from the requirement supplier. They can be reviewed individually for feasibility, by technology as well as cost, during the review sessions.

The requirements reviewers also need to review the association section under the product constraints and the functional requirement cell (who, what, where, when, why and how). Under the functional requirement cell, the QoS expectation for the individual requirement should be clear. This cell will also illustrate if there are multiple QoS effects on individual requirements, enabling reviewers to see if any conflicts exist between the different QoS and the requirements. Under the QoS association section, the requirements users will see how a single expectation affects multiple individual functional requirements. A pattern can be seen that will facilitate the selection of technical options.

The Quality of Service Anti-Pattern PDF contains the language for this anti-pattern.

For your project, make a list of product constraints that would be considered Quality of Service needs. Then take a look at the Requirements Set Framework™ and a look at past projects, as well. Select three requirements and identify the potential impact from at least three quality of service type requirements. Ask yourself if those requirement associations where qualified in the requirement specification. Are they a current need that was not satisfied? Think about how this anti-pattern could be implemented to avoid any problems previously seen on those projects.

If you have difficulty trying to define an Anti-Pattern for your project, please feel free to contact SBDi. We can give you ideas of common requirement-related mishaps, which can be avoided with properly developed and implemented anti-patterns. Or if you have an interesting scenario, SBDi may choose your project as an example and develop the anti-pattern in a future tip.

SBDi is available to work with your organization on Requirement related or Project/Program Management Anti-Patterns.

Our services include:

• Education of the management and development team on the value of the development, implementation and use of anti-patterns.
• Teaching how to identify, develop, validate, and implement anti-patterns.
• Developing project specific anti-patterns.
• Developing a divisional or corporate process for the development and implementation of anti-patterns.
• Review of existing anti-patterns for quality.

Pat Ferdinandi