In a previous tip you were asked to develop at least five questions for each focus cell in the Owner Perspective. Click here to review a sample question set 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.

The Requirements Set Framework and Requirements Set Pattern DOES NOT omit the need for tried and true analysis techniques and methods...they ENHANCE them! Analysis techniques, such as Object Oriented Analysis, Event Partitioning, Structured Analysis, and Data Modeling all help to uncover gaps in knowledge, which assist in eliciting more requirements.

Analysis techniques identify and evolve requirements for specific focus areas from one perspective to another. The important point is that no single technique will capture every requirement that needs to be captured to build a quality product that meets the business objective! Relying on one technique will guarantee an incomplete requirement set! This may happen if your chosen CASE tool supports only one technique.

SBDi encourages Requirements Engineers to learn as many analysis techniques as possible. Some work better with different communities. Others work better with specific technical architectures. The more you know, the better prepared you will be to select the technique which best suits the project at hand.

The beauty of the Requirements Set Pattern and Framework is that it is technique independent. It works if you use one, many or none of the available analysis techniques. The Requirements Set Framework just cares that all the requirements are captured. The Requirements Set Pattern helps by providing question sets to elicit the requirements. Analysis techniques help you review portions of the requirement set, validating for completeness of specific focus areas. For Requirement Cells not covered, the question set can be used to document individual requirements. These can be documented outside of the CASE tool.

Recommending a technique or tool should be part of a Requirements Process Definition; it does not belong in the Requirements Set Pattern. If you wish to follow a specific set of techniques, document the steps in the Requirement Process for the specific focus area. Customize the question set in the Requirements Set Pattern to include questions that will help you follow the technique.

Be careful how you word the questions! The provider of requirements, in most cases, will not know the technique or terminology. Write all questions in the requirement supplier's terminology, not yours! If you must use specific terms, develop a glossary to be distributed to the requirement suppliers at the beginning of every elicitation and review session.

Let's continue with the exercise.

The Designer Perspective identifies details. Concentrate your question development to include the following:

1. Complete each requirement with details. This includes identifying the steps to perform a process or the data items that define the entity class.
2. Define the means of validating each requirement (including relationships).
3. Review that each cell, and the relationship between each cell, has been discussed.
4. Evaluate dependencies and priorities to segment requirements into iterations.
5. Clarify the feasibility (and the cost) of satisfying the requirement.

Before starting this month's exercise, let's review the work of last month.

1. Does your question set contain questions that would elicit all the information that should associate one requirement with another?
2. Are your requirements written to include associative information?
3. Did you qualify the association?

This month's exercise is to develop the Designer Perspective Question Set.

1. Write down questions to help identify the details about all the captured requirements for each focus area.
2. Eliminate questions that associate requirements or define relationships between requirements.
3. Eliminate questions that imply a specific design solution.
4. Eliminate questions that define details about the scope item (such as entity object attributes).
5. Apply these questions to the requirements specification which was used last month. Highlight questions that do not have answers and go back to the users to elicit the answers.
6. Write the requirements to include the information described under requirement contents.

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

Pat Ferdinandi