If you continued with the exercise of developing your Requirements Set Pattern, you developed at least five questions for each of the focus cells in the Builder and Subcontractor Perspective. A sample chapter is now available from AWL, the publishers of A Requirements Pattern.

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

Over the past several months, we have concentrated on two of the Requirements Set Framework™ dimensions - Focus and Perspectives. The third - Community - is equally important.

Every organization has some structure that aligns itself to business responsibilities. To repeat a portion from the July 2001 Tip, the broad categories of business communities include:

1. Business Practice - Business areas that build the product or service sold by the corporation. For example: product development, marketing, customer services, and logistics.
2. Business Support - Areas that support and protect the business communities within the corporation. For example: legal, human resources, and finance.
3. Business Organization - Decision-makers that establish the policies and procedures that dictate the strategy for the organization. For example: the executive management and the board of directors.
4. Technology - The group responsible for building information technology products that are to support the different business communities or build the product or service to be sold. This would include hardware, software, and networks.

Each of these communities develop their specific work products. All of the work products are required to be built to arrive at the business objective. Each community has requirements that evolve through the same perspectives. Each community identifies requirements that fall into one of the eight focus areas.

Requirements are initiated by an idea from either an internal or external source. A business community will champion the idea and obtain approval from the executive community. No software product should ever be viewed as a single, stand-alone project. They must coordinate the business objective with the overall business (enterprise) strategy. This coordination requires that all business communities participate on every project by detailing requirements that impact their area of responsibilities. Identifying the level of participation of each business community requires that the product concept follows an allocation process. The requirement is allocated or delegated to the appropriate business community by reviewing the requirement at the following levels:

1. Corporate - Determines the level of involvement throughout the company.
2. Divisional - Determines the work products that need to be developed.
3. Architectural - Determines the pieces of the work products that need to be developed.
4. Product - Develops the pieces of the work products or the work product itself.

It is at the product level that the perspectives evolve. Click here for a PDF illustration of process/allocation/perspective correlation. The purpose of requirement allocation is to ensure the following:

• All work products are developed in parallel.
• All work products work from the same initiating idea.
• All work products do not conflict with other work products.
• All work products meet the same business objectives.

All requirements across communities should be reviewed for conflicts between the communities. For example:

• The advertising should match what is being implemented into the product.
• The business-to-business partnership should state the responsibilities of each company that should be reflected in the design.

The Requirements Engineer should work with the different communities to develop a question set for their Requirement Cells. Their role could easily be expanded to be the facilitator for eliciting, analyzing, specifying, validating, and managing ALL requirements. After all, a requirement is ANY NEED TO BE SATISFIED to meet the business objective.

We hope that you have found this year's topics to be helpful in developing a quality Requirements Set. It is our belief that if you learned just one useful piece of information, it was worth our effort in preparing these monthly tips. We invite your thoughts and suggestions for more topics so that we continue to provide Tips that are relevant to you.

We at SBDi would like to take this opportunity to wish everyone on the list and his or her family, friends and co-workers a happy, healthy, and successful 2002!

The Requirements Meta Pattern™ is available in the recently released 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