Requirements are an output of architecture because N1 Grid requirements are derived as part of the process of getting to the architecture, rather than trying to design the architecture from raw statements of need from stakeholders. The raw Voice of the Customer (VOC) statements serve as a basis for a series of activities, such as:
All three activities are designed to help organize and prioritize requirements.
Requirements serve as a link between key business drivers and the architecture, people, processes, and products that make up the solution. Requirements should establish the measurable success criteria for the solution in terms of the operational, functional, and service-level objectives. The gathering of requirements is an iterative process. It must start with an identification of stakeholders and other places from which requirements might be gathered. The stakeholders can be the source of explicit raw VOC requirements, as well as the validators of activities that identify implied requirements and an understanding of the constraints and assumptions across the business, functional, and operational boundaries.
As shown in FIGURE 5-1, iteration occurs when stakeholders are both the source and validators of business drivers, use cases, service level requirements (SLRs), and information derived from architectural or operational assessments. It is important to capture the ownership of the requirement (that is, the person who will say that the requirement has been met) and a means for requirement acceptance (an agreement for how the requirement is to be satisfied) at the same time the requirement is documented.
Figure 5-1. Stakeholder Activities During the Requirements Phase
The boxes represent possible artifacts of the requirements process where stakeholder information is documented. The arrows show how stakeholders can be active in all phases of the requirements gathering, analysis, validation, and approval phases.
In addition to their activities in the requirements gathering phase, the stakeholders and requirements have interaction throughout the entire architecture life cycle, as shown in FIGURE 5-2.
Figure 5-2. Stakeholder and Requirements Interaction
This diagram shows that the requirements can be updated throughout the architectural process as new information is uncovered. Although not drawn in FIGURE 5-2, these iterative updates might also eminate from the ongoing operation and solution maintenance box. Experiences with complex network computing problems bear this out:
Prototypes and other side projects that quickly model some aspect of the architecture can uncover previously unknown opportunities or solidify previously undefinable requirements. This is usually the exact purpose of inserting them into the architecture analysis process.
Requirements contribute to the architectural analysis by guiding the choices that are made and way they are presented for design and validation (for example, there are many ways to deliver single sign-on, and some might be in conflict with other functional or operational requirements).
Requirements contribute to the validation of the design phase by documenting the testing of the functional (for example, "This must happen when I click this button," and "The architecture must support 10,000 simultaneous clicks.") or the operational (for example, the people and processes are in place to respond to this alert) use cases required to demonstrate a working solution.
Requirements contribute to the ongoing operation of the solution (for example, the method exists to update parts of the solution without service interruption) and guide the mechanisms to collect and places to report information that demonstrate the delivery of SLRs captured in the requirements artifacts.
Traceable requirements are the key to enable the prioritization, validation, and measurement of the requirements activities just discussed. Traceability of requirements has several implications:
All project activities can be linked to the analysis, delivery, measurement, or reporting of a captured requirement.
All captured requirements can be traced back to key business drivers (KBDs).
All captured requirements can be directly measured or decomposed into directly measurable derived requirements.
All new information from the iterative architecture methodology can be propagated to the appropriate existing requirements for deprecation or updating
All measurement techniques for changed, updated, or deprecated requirements can be likewise changed, updated, or deprecated
All captured requirements have an owner who could sign off after the demonstrated delivery of that requirement.
FIGURE 5-3 demonstrates this traceability for a fictitious subset of requirements.
Figure 5-3. Requirements Traceability
For discussion, suppose that the items in FIGURE 5-3 are the current state of the documented requirements. The following discussion is based on the just discussed bullet points:
All of the requirements should have an owner. Owners serve as the source of initially derived requirements and of information that determines how the requirement has been delivered. In this way, requirement owners provide information, but they are also accountable for the process to verify the delivery of the features they demand.
All of the requirements should point to the KBDs they support. In the diagram, the fourth requirement has been captured, and although it has been decomposed into derived requirements, it does not point back to a KBD. Such items are either points of interest (that is, they illustrate an important missing KBD or requirement), or they might turn out to be items on someone's agenda collected during the gathering process, but not aligned with the rest of the project requirements. In addition, the third KBD does not currently have requirements supporting its existence. This fact should either motivate its removal or point out that additional analysis must be undertaken to uncover stakeholders and information that support it.
All of the requirements should be directly measurable or eventually decomposed into directly measurable derived requirements. In this case, the owner of the third requirement must agree that it is completely measurable as captured; otherwise, the requirement should be rejected or additional decomposition should occur. The fourth requirement was decomposed into multiple derived requirements. Each derived requirement (four through six) must be measurable in a way that is acceptable to its owner, and the derived requirement measurements combined in a way that is acceptable to the owner of the fourth requirement.
All of the project activities on the far right should be linked to the requirement they address. The third activity is an example of project activity that should probably be challenged. It has somehow been identified as needed, but it has not yet been linked to a requirement it supports in terms of adding value.
The iterative nature of analysis and traceability fills out the links and documents the priorities (that is, prioritized KBDs). In this way, you do not need to work solely from left to right. You can start with any mix of drivers, activities, and requirements and still end up with a completed list of traceable requirements. The requirements analysis phase is often where many of the derived requirements and implied constraints emerge. They are added into the table, as solutions are worked out more completely in pilots and benchmarks and illuminate or disprove some functionality.
The validation and verification activities finalize and socialize the requirements and CTQs, ensuring that the stakeholders agree and sign off to the requirements as a complete and accurate description of the desired future state.