We introduced the three dimensions of the requirements set framework in this tip.

• 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.

We discussed that although requirements need to be implemented and tested independently, requirements are frequently dependent upon each other. This dependency identifies "associative" requirements.

The objective of the exercise was to begin to illustrate the benefit of filling every cell with requirements. SBDi is often called in to review requirements specifications. It has been our experience that three gaps occur in the following scenarios.

1. Requirements specifications include only functional software requirements.
   When requirements specifications include only functional software requirements, this eliminates important Product and Project Constraints. This often results because either only one method of analyzing requirements was used (e.g., event partitioning or UML) or the CASE tool used to specify requirements does not support all types of requirements. When these important focus areas are omitted, user and management expectations are not captured. Poor performance, unreliability and other product constraints may affect design decisions. Budget and resource requirements are seldom documented as they are reviewed for feasibility.

2. Associations are minimally identified.
   When associations are minimally identified, this eliminates the ability to identify conflicts between requirements. Who/What/When/How are usually documented with associations (e.g., processes know what information is required when, and by whom). Often forgotten are the associations of product and project constraints on these requirements. For example:
   • Can you meet the performance expectations processing a function during the peak time period?
   • Can you make the deadline within budget with the staff limitation AND satisfy all the functional requirements?
   • Can the network support the volume of data being passed?
   • Which actors can use which devices?
   • What can be transmitted to which devices?
   
   
3. Requirements are either omitted completely or minimally documented.
   When requirements are omitted completely or minimally documented, this eliminates important information Network Engineers need to perform their responsibilities. For example:
   • Locations need to be identified from the beginning point through to the end point.
   • The device type for the points needs to be identified (e.g., wireless devices will have an impact on what and how much can be transmitted).
   • Associations between where and who/what/when needs to be documented to be able to define the network infrastructure.
   • Product constraints affect network decisions and must be defined as associative requirements.
   • Design decisions must also take into account budget and time limitations.

The Requirements Engineer must be prepared to identify focus area requirements and define relationships between the different requirements within each focus area and between them. The compilation of all the requirements in the different cells form a requirements set. This set defines the contract between stakeholders and the development of ANY solution.

To prepare for any elicitation session, a Requirements Engineer should have a question set for each focus area (and eventually, each cell in the Requirements Set Framework). This will lead us to next month's discussion on the Requirements Meta Pattern™.

To prepare for this discussion, this month's exercise is to begin to define a question set for the Planner Perspective. This perspective is the broadest level of requirement definition. Its purpose is to define the scope of investigation. The documentation produced at this perspective is merely a list of what is in and out of scope. At this point, do not worry about associative requirements. Concentrate on targeting the questions to elicit the focus areas.

1. Who - Person, organization, or system that will and will NOT require access to the solution.
2. What - Things or business objects that are important to the business.
3. Where - Places the business operates including customer access and any business partnerships.
4. When - Triggers and responses to triggers of action from the scope.
5. Why - Constraints that must be enforced to protect the integrity of the corporation or product.
6. How - Business processes that are important to the business.
7. Product Constraints - Product expectations that will constrain design decisions.
8. Project Constraints - Limits applied to project execution.

At the end of this exercise, each of the eight focus areas must have at least five questions.

1. Write down questions that will help identify requirements for each focus area.
2. Eliminate any question that crosses focus boundaries.
3. Eliminate any question that associates requirements or defines relationships between requirements.
4. Eliminate any question that implies a specific design solution.
5. Eliminate any question that defines details about the scope item (such as entity object attributes).
6. Apply these questions to the requirement specification that was used last month. Highlight questions that do not have answers...and go back to the users to elicit the answers.

SBDi has been successfully using this structure complete with a customizable question set, a sample of which will be available in the book, A Requirements Pattern: Succeeding in the Internet Economy (AWL, 11/2001). SBDi is available to assist your organization in learning more about or implement the use of the Requirements Framework.

Pat Ferdinandi