The past tips have alluded to a structure for the set of requirements. This type of structure is called a framework and is used as a means of categorizing information in a standard arrangement using a common language.

The purpose of a Requirements Set Framework™ is to organize the different types of requirements so that gaps in knowledge or weak knowledge areas can be identified. It extends the work of John Zachman's Information Systems Architecture (www.zifa.com) from two to three dimensions and narrows the space to requirements.

The three dimensions of the requirements set framework include:

• Community - Represents the business area the requirement supports.
• Perspective - Represents the evolutionary detail of the requirement.
• Focus - Represents the specialized view or architectural component of the requirement.

Every organization has some structure that aligns itself to business responsibilities. 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.

Requirements evolve in detail providing a different perspective at the requirement set. These different perspectives include:

1. Planner - Clarifies the scope of investigation.
2. Owner - Requirements and dependencies.
3. Designer - Essential details of the requirements.
4. Builder - Requirements to support development.
5. Subcontractor - Requirements that pertain to monitoring for opportunities to improve the product.

To build effective software solutions, requirements must be captured that incorporate the following specialized views or focus.

1. Who - Captures the people, organizations and systems; in other words, the actors and their responsibilities. These include the customers, suppliers and internal organizations of the corporations involved in the product.
2. What - Captures the information that is important to the business and the individual business communities. This includes entity and entity object identification.
3. Where - Captures the locations in which the business operates. This identifies the underlying network structure.
4. When - Captures the events that require action on the part of the organization. This defines the triggers for processing.
5. Why - Captures the policies that define the corporate culture and strategy of the organization. This defines constraints that will affect all other focus areas.
6. How - Captures the functions and their workflow that support the events. This defines the processing and methods the objects must perform.
7. Product Constraints - Captures expectations of the organization and customer. This defines the quality of service non-functional requirements; for example, performance, security, and reliability. This may include specific hardware, software, standards, and such that must be used in designing the solution.
8. Project Constraints - Defines the limitations of resources during project execution. This defines constraints in respect to budget, time and resources.

With this categorization, individual requirements fall into "cells." Though requirements need to be able to be implemented and tested individually, they are also dependent on other requirements in other "cells." To build in the dependencies, requirements are associated with qualifiers. This category of requirement is called "association." The association describes the dependency between one requirement with another requirement that is within or outside the same category cell.

Over the following months we will review the categorization and evolution of requirements. In the meantime, let's try a little exercise.

1. Take a look at a current or past requirement specification.
2. Next to each requirement, identify the focus that it supports.
3. Document requirements as "associative" if the requirement supports more than one focus area.
4. Reorganize the document focus area.
5. Note any gaps in knowledge.

   a. Which focus areas have no requirements?
   b. Which focus areas have less than five requirements?
   c. Do all focus areas connect with all other focus areas with associative requirements?
   d. Do you have any requirements that you did not know how to categorize?

SBDi has been successfully using this structure to assist in identifying, categorizing, and validating the requirement set. Each project (ranging in size, development type, and product type) developed a comprehensive set of requirements that lead to successful implementation of a software product. SBDi is available to assist your organization in learning more or implementing the use of the Requirements Set Framework.

Pat Ferdinandi