In a previous tip you were asked to develop at least five questions for each focus cell in the Planner Perspective. Click here to review a question set sample in PDF format.

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

In general, a pattern is any reusable template that is based upon experiences that can be used to guide the solution to a problem or fulfill a need in a specific context. The objective for creating a Pattern for Requirements is to guide the evolution of a FULL Requirements Set towards a solution to a problem or to fulfill a need. The guidance is found within each cell of the Requirements Set Framework.

The term pattern is more commonly used to represent a template for specific technical architectures or programming scenarios. SBDi took the general definition of pattern and applied it to the common problem of poor quality requirements set.

The question set you developed is the beginning of a Requirements Set Pattern™ for your projects. It is a tool to be used with the Requirements Set Framework to assist in eliciting a comprehensive requirements set.

Within each cell of the Requirements Meta Pattern™, the following information must be provided:

• Objective
• Delivered Work Product
• IEEE Reference
• Individual Requirements Contents
• Possible Specification Formats
• Possible Elicitation Questions

Objective
Define the requirement-capturing objective of the requirement cell.

Delivered Work Product
The delivered work product is the specifications issued at the end of each perspective. This section itemizes potential document names used by different organizations. Each focus area may have a specific model or document. These documents are listed under the representative notation and are considered part of the specification listed in this introductory section.

IEEE Reference
The IEEE Reference itemizes IEEE standards from the IEEE Software Engineering Collection to be used as a reference to build the above perspective-level work products. The list provided is an initial set and not a comprehensive list. Many other standards exist (including IEEE Standards). As a generic reference, refer to STD 610: IEEE Standard Glossary of Software Engineering Terminology.

Individual Requirement Contents
The Individual Requirement Contents is a generic list of what is needed to describe the textual requirements. This information will become available as the requirement evolves through the perspectives. The generic list conforms to the quality characteristics for requirements and includes the following:

• Identifier
• Name
• Description
• Volumetric (number of each item / for what time period)
• Volumetric breakdown for minimum, maximum (peak period), and average (if available)
• Point A Name (Master)
• Point B Name (Detail) ­ (if needed)
• Initiating or Derived requirement identifier (association/relationship indicator)
• Qualifier (if applicable)
• Priority
• Cost
• Optionality
• Status
• Audit Trail

Possible Specification Formats

1. Textual Description: All requirements should be documented in a textual format. This section describes the type of information to be captured to meet the requirement-objective for the cell.
2. Representative Notation. These notations identify popular representative models/diagrams to illustrate the textual descriptions above. NO REQUIREMENT SHOULD BE ILLUSTRATED IN DIAGRAM FORM ONLY!

Possible Elicitation Questions
Target: Summarize the concept of the question-set.
Sample: Provide an example of the type of questions that could be asked. THIS IS NOT AN EXHAUSTIVE LIST! Add questions appropriate for the cell based on missed requirements identified during the quality gate reviews, from defects found in previous iterations or feedback from users of the e-commerce application.

The Planner Perspective
For the Planner Perspective, all of the requirements except Point A (Master), Point B (Detail), and the Qualifier should be supplied. Even if this is a new development project, business communities will have an idea of volumes this early in the requirement set development. This information is needed to determine the projected revenue that will be part of the Business Case for the project.

The Owner Perspective
The Owner Perspective begins to evolve the requirement set by eliciting information about relationships. Requirements must be able to be implemented and tested independently. However, many requirements are dependent upon the implementation of another. In addition, many requirements can be dependent on the same requirements. This creates an opportunity to REUSE requirements with associations. This way, the requirements are all documented ONCE (according to the quality characteristics). They are maintained in ONE place. The use of the requirement is qualified with the association requirements. Therefore, the goal is as follows:

1. Concentrate on determining the relationships with the cell first, such as the relationship between entity class customer and entity class product.
2. Concentrate on determining the relationship with other focus areas, such as what information is needed to perform a process.
3. Label and describe the dependencies between requirements. Determine the details of the relationship later.
4. Qualify the relationships. Determine that only a specific region or subset of information is used to perform a specific process.
5. Place the associative requirement under the cell that makes the most sense. For example, the information needed to perform the function would be placed under the "how" focus area. Determining which cell that the cross-cell relationship is stored is not as important as capturing the relationship.

For this month's exercise:

• Review the work of last month.
1. Does your question set elicit all of the information that should be captured for the planner perspective?
2. Are your requirements written to include the above information?

• Develop the Owner Perspective Question Set:
1. Write down questions to help identify requirement relationships within a focus area.
2. Write down questions to help identify requirement relationships between focus areas.
3. Write down questions to help qualify the relationships.
4. Eliminate questions that imply a specific design solution.
5. Eliminate questions that define details about the scope item (such as entity object attributes).
6. Apply these questions to the requirement specification used last month. Highlight questions that do not have answers and go back to the users to elicit the answers.
7. Write the requirements to include the information described under the requirement contents.

A common question raised at this point by all clients learning how to use the framework and pattern is, "When do analysis techniques come into play?" We will address that question in next month's tip.

The Requirements Meta Pattern™ is available in the forthcoming book, A Requirements Pattern: Succeeding in the Internet Economy (AWL, 11/2001). SBDi is available to assist your organization in learning more or implementing a customized version of the Requirements Meta Pattern™.

Pat Ferdinandi