In a previous tip we introduced the need for Anti-Patterns that specifically deal with requirement-related issues. The Pattern community is very specific about the language (contents) of any anti-pattern. At SBDi, we agree with the need for standardization and approve the format discussed at the pattern home page (http://hillside.net/patterns/patterns.htm).

This tip discusses the format for use of the anti-pattern. This format is from one of our recommended books by William Brown, Raphael Malveau, Skip Hays and Tom Mowbray, "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis," John Wiley & Sons, Inc. 2001. Some minor adjustments have been added that specifically focus on the Requirements Set Framework™.

If you are new to SBDi's Tip of the Month, we recommend that you begin this thread with January 2002 available in the SBDi Tips Archive before continuing with this month's tip.

Each anti-pattern must be in the proper format and contain the following information. As with every requirement, each anti-pattern must have an "identifier" section. The identifier provides a means to trace the usage and is associated with specific cells in the Requirements Set Framework™. As with all identifiers, they should be unique across ALL projects (many anti-patterns are reusable even if they require just minor tweaking). Remember, do not add intelligence to any identifier! Internal meanings are only meaningful to some people and usually for a short period of time.

The "name" section of each anti-pattern describes a topic. If the anti-pattern is basically the same as another, but only with minor adjustments, (i.e. supporting a different type of Quality of Service Requirement) then use the same name as the other pattern. Add a "qualifier" to the name, as you would with an associative requirement. For example:

• Identifying All Critical (Network) Performance Points
• Identifying All Critical (Cache) Performance Points
• Identifying All Critical (Record-Locking) Performance Points

The section "also known as" provides the more commonly known "slang" term for the anti-pattern. For example, an anti-pattern pertaining to security could also be known as the "hacker" or "predator" anti-pattern.

The section "based upon" for the purpose of the anti-patterns being discussed are ALL based on the Requirement Set Pattern and Framework™ developed by SBDi.

"Cell applicability" is a section that was added because of the Requirements Set Framework™. This section lists the specific cell, association or group of cells that are affected by this anti-pattern. In this section, you would identify the community, perspective, and focus that is the anti-pattern targets.

The "problem" section simply covers what the anti-pattern is meant to address. It describes what problem you are trying to avoid by using this anti-pattern. No discussion of the solution should be mentioned in this section. Instead the problem needs to discuss the risk in terms of the root cause of the problem.

The "refactored solution type" section identifies what kind of problem the anti-pattern addresses. For requirement related anti-patterns, we categorize the anti-patterns as a gap in one of the following areas: knowledge, participation, or process.

The "context" section describes the scenario in which the risk could occur. It is similar to the preconditions of the use case. The purpose is to extend the problem description by stating the specifics of how the problem could occur as well as providing a warning sign that the problem will probably occur.

The "forces" section describes specific problem must be avoided and needs this anti-pattern. The "context" states the risk. "Forces" expands each of the itemized issues (risks) to further explain the problem.

The "solution" section describes the countermeasure to the risk. It is the activity description of the use case.

The "resulting context" section describes how you will know that the risk was avoided. Similar to the postcondition of a use case. It is a means of validating the success of the anti-pattern.

The "rationale" section describes the requirements engineer's reasoning why this anti-pattern should be incorporated into the process.

The anti-pattern must be written in the same manner as the pattern on which it is based. Therefore, the "syntax" section must adhere to the syntax rules described by the Requirements Meta Pattern™.

"Suggested patterns and anti-patterns" is a section that is primarily for generic patterns/anti-patterns such as the performance example described above.

Additional optional sections to the pattern could include:

• Probability of risk - to define the chances of occurrence.
• Reference to past examples - to provide reviewers and users of the anti-pattern additional examples of the risk, or how the solution avoided the risk.
• Referenced projects - to identify specific projects that are currently using the anti-pattern.

This may seem like a lot of text to write. However, providing the information for each section will enable the user of the anti-pattern to fully comprehend how to use, when to use, and the need to use this anti-pattern.

We will begin to discuss different anti-patterns that fall under the category of gap in knowledge in April's tip. Next month, we will discuss a tool that can be used in conjunction with anti-patterns. This tool will be helpful with many issues dealing with non-believers of requirements engineering.

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.

The Requirements Set Framework, Pattern, and Anti-Patterns are the basis of the book, A Requirements Pattern: Succeeding in the Internet Economy (AWL, 11/01). You can order your own copy at Amazon.com.

SBDi is available to assist your organization in understanding the detail, customizing and implementing the Framework, Pattern and Anti-Patterns.

Pat Ferdinandi