- Requirement Categories
- Requirement Organization
- Product Constraints
- Project Constraints
- Adding Community to the Infrastructure
- Requirement Associations
- Organization Impact
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Adding Community to the Infrastructure
The Zachman Information Systems Architecture (see Figure 3.7) shows how the framework works for software deliverables. Figure 3.8 shows the framework extended to support the important nonfunctional requirements. Notice that product and project constraints fit with the same perspectives as the six functional requirement types.
){kind=link}
){kind=link}
Figure 3.7 John Zachman Information Systems Architecture for Software Perspectives and Focus (Source: John A. Zachman, Zachman International, 810-231-0531, www.zifa.com.)
Figure 3.8 Zachman's Framework, Expanded Focus
Although Figure 3.8 expands the number of focus areas compared with the Zachman framework, it still omits some of the different organizations involved in developing an Internet product. For example, to actually roll out an Internet application, other business areas are involved:
Advertising: to develop the media representation for the product
Legal: to develop product liability, copyright, and warranty documentation
Customer Service: to develop processes to train persons assisting customers with questions, complaints, and returns
Each of these additional areas has its own process to provide the details for each perspective and focus. Each may have assigned a different project identifier, but the project objectives must satisfy the initiating requirements. Each has a different deliverable for each perspective and focus cell, organized as previously discussed for the information technology cells.
With regards to the overall product plan, this creates a third dimension to the requirements set. This dimension, community, represents the different areas of business concentration. A community could be a business unit or a department of a business unit. The way in which a community is defined varies by organization and should be determined at the beginning of the program. The organization chart for your company is a good start for selecting communities. Here are some points to consider for communities:
Product development and implementation require additional involvement by other organizations.
Other organization areas will be dependent on perspective and focus requirements.
Other organization areas will develop perspective and focus requirements that may impact software.
Each organization area will have its own process that develops focus requirements through perspective levels.
Community changes the two-dimensional pattern shown in Figure 3.8 so that each requirement cell becomes multidimensional (see Figure 3.11 ). As stated earlier in this chapter, we can categorize the communities into:
){kind=link}
- Business practices (BP)
- Business support (BS)
- Business organization (BO)
- Information technology (IT)
Each of these areas can be broken into finer detail, depending on the deliverables that are required to develop a piece of the end product. For example, under business practice one may find marketing. Marketing may be further segmented into advertising and market research. Again, the breakdown will vary from organization to organization. No matter what level of breakdown, each subdivision has a separate deliverable and a different set of requirements it needs to satisfy to develop the complete end product. Each would follow the same objectives for each cell. To customize the framework for your business communities:
Apply the organizational structure to the framework.
Have each community represent specific areas of concentration that relate specifically to the organizational structure.
Create Zachman's focus and perspectives for each organization or area initiating a subproject to satisfy the business objective.
Add the two nonfunctional focus areas.
Create embedded matrices of focus and perspective details specific to the community area.
Create the association requirements to keep all cubes in sync in order to reach the common objectives of the product to be delivered.
Derive all requirements from the initial business need (initiating requirement) or wants (the requirement request).