This chapter is from the book
This chapter is from the book
This chapter is from the book
Conclusion
This chapter introduced how the different types of requirements can be organized. Categorizing the requirements makes it easier to develop the question list as well as to identify gaps in knowledge. The objective is to ensure that the product to be developed is fully understood from all angles. Adding the question list and process to the organizational structure turns the framework into a pattern (see Appendix B).
Perspectives reflect the areas of responsibility for each role. For example, a designer's perspective is quite different from the owner's perspective; the builder's perspective is different from a designer's. Each evolves the requirements by providing details needed to interpret his perspective. The owner's perspective must be satisfied in the final product. Though each role has a different perspective, all roles work together as a team to build the quality product.
When building a home, each perspective requires a different focus or view. These views concentrate on a specific area for that perspective. For example, the house requires a plumber's view, an electrician's view, a landscaper's view, and so forth. Each has similar deliverables: scope, owner's model, physical model, specifications, components, and the final product. The deliverables at each perspective level have their own focus areas.
In software engineering terms, the focus includes both functional and nonfunctional requirements. Functional requirements are the "who" (interface associations), "what" (data), "where" (networks), "when" (events), "why" (business rules), and "how" (processes). The nonfunctional requirements are the product and project constraints. Similarly, each perspective has eight different views, one for each of these eight areas.
It is important to realize that nothing can be viewed independently. All focuses and perspectives are important for building a high-quality product. Each view must drill down a concept into finite detail to ensure compliance and quality and to meet the business needs. Each focus and perspective requires different probing questions.
Linking the different focuses and perspectives requires additional association or support-type requirements that will tie all intersecting squares. For example, when building a home, electricians need to ensure they do not affect the plumber's requirements. This creates additional association requirements for the electrician and plumber. In system engineering terms, association requirements are created for hardware and software to work together. Probing questions are required to tie the focus and perspective to other focus areas and perspectives.
We need to expand our view of requirements beyond software-implemented requirements. Additional dimensions need to be included to incorporate all business areas that may be affected by the business request. This includes such business areas as legal and human resources. Each business area will react in some way to the original requirement. Each business area will have its own process for satisfying a specific need. Each business community may spawn additional IT requirements. These may initiate additional software projects that enhance existing systems (for example, change billing system) or require maintaining data contents (for example, add a new product number), or they may initiate non-IT projects (for example, modify legal contracts).
The Zachman framework can be expanded to include the additional dimension of community to support each business area. Each community has its own focus and perspective. Each multidimensional cube requires additional association requirements to support the linkage of the requirements.
The requirements that fall into each community, perspective, focus, and association create a full requirements set. A requirements set contains all the individual requirements and related information associated with a business objective. Some general guidelines follow:
Each requirement should be stated only once.
Requirements should not overlap, that is, they should not refer to other requirements or the capabilities of other requirements.
Explicit relationships should be defined among individual requirements to show how the requirements are related to or dependent on each other to form a complete product.
The requirements set should include all requirements needed by the business user as well as those needed for the definition of the product.
The requirements set should be consistent and noncontradictory in the level of detail between formats.
Community and perspective should be used to subdivide the requirements set. Though many different groups may develop specific focuses, this is not recommended since it increases the risk of missing association requirements or requirements that tie focus requirements with other focus areas.
A skilled requirements engineer should be involved in implementing the framework into a requirements management tool. This includes the transition from different CASE tools and other formats into the requirements management tool.
Adding a process for filling each cell, as well as filter rules for each cell, turns the framework into a pattern. This requirements pattern is a meta pattern that can be tailored to any type of application. The next chapter does just this: it takes the requirements set framework and discusses the objectives and the types of questions that should be asked to capture the needs of the Internet product.