This chapter is from the book
This chapter is from the book
This chapter is from the book
Requirement Associations
Requirements may not succeed all on their own. They need to be implemented with other requirements. For example, the process needs data to be able to perform its operations. For this reason, it is important to "link" or associate requirements that are dependent on each other. There is no need to define the data for both the "what" focus and the "how" focus. The data should be documented once and "used by" the process. To identify the process needs for the data, the data is associated to the process at the point it is needed. This builds a relationship requirement between data and process for specific purposes.
This association allows requirements to be normalized, in other words, to be stated once. One requirement may impact many requirements. For example, using the nonfunctional product constraints of reliability, a reliability requirement affects multiple "how" or "where" requirements. They need to be associated to build the quality requirement. Each association needs to be qualified in order to reflect the specific details of the reliability impact.
Just as any other requirement, association requirements must be satisfied to have a high-quality Internet product. These requirements are spawned by a specific requirement cell (perspective, focus, and community) to be satisfied by another area in order for them to work together. They are the glue that holds the different requirements together in a multidimensional model. (See Figure 3.9.)
){kind=link}
Figure 3.9 Potential Requirement Associations
Within each cell, specific needs must be addressed to refine the requirements set. For example, both the inventory subset of requirements and the billing subset of requirements can be defined separately. They may be two existing systems in larger brick-and-mortar type companies. In order to streamline the workflow between inventory management and billing, each system needs to be modified to work together. These special derived requirements are important for holding two separate requirements subsets (billing and inventory) together.
When one requirement needs to use (or reference) information captured in another cell, it is important to build a link between them. Most CASE tools do this automatically. This creates a "usage trail" so that if either requirement changes during the development process, you can easily identify the potential impact on other requirements. All affected requirements (the two independent and the one relationship) need to be implemented in order to have a successful Internet system. They can be tested and implemented independently. (See Figure 3.10.)
){kind=link}
In Figure 3.11 the Zachman framework is extended, showing how the relationships (associations) form the mortar between the requirement cells.
){kind=link}
Figure 3.10 Internal and External Cell Association
Figure 3.11 Requirements Set Framework Showing Perspective and Focus Categories
Two pieces of information are required in order for the association requirement to be connected. One is the actual content; the other is the usage trail (link). The usage trail is the identifier of both requirements that are being associated.
These types of requirements are often overlooked. Once a requirement is allocated to a specific community, the community may satisfy its requirements without thinking of the possible impact the requirement may have on another community. The need for these types of requirements is finally realized somewhere down the product's development path. The result is that the other areas are playing catch-up or that both areas are modifying the design to accommodate the interaction. The modification is usually not ideal and could have been accounted for earlier in the development cycle. The catch-up is costly in terms of time and money.
To account for these association requirements, the set of requirements should be available for all communities, focus areas, and perspectives. As the requirements are being written for the specific cell, the requirements engineer should ask what needs to be done for other cells to succeed in satisfying this requirement. As existing requirements for other cells are reviewed, it is important to ask those same questions. If one cell needs to be associated with another cell, what additional requirements need to be developed to facilitate the association?
Some of the support associations will be noted by the individual community as its "who" or association requirement. Others will not. For example, network planning is often forgotten until a month before the software product is to be implemented. The network-planning people need information that should have been gathered early in the program. Unfortunately, the program ends up delayed or the network personnel run ragged just to keep to the deadline.