SMART Requirements

This section discusses how to make your measurements more useful. Although the definition for "T" is a variation on the acronym's traditional definition, it is important to capture requirements that are SMART:

  • Specific The description and purpose is clear and unambiguous.

  • Measurable The requirement is quantifiable, observable, verifiable, and testable.

  • Attainable The requirement is technically or operationally possible (for instance, 101% uptime is not).

  • Realizable The requirement is possible to implement in the current context of the organization (for example, 50% uptime may not be realizable in a datacenter with no roof).

  • Traceable The requirement can be linked back to the KBDs and linked forward to requirement validation and acceptance criteria activities, as discussed in the previous section.

If a particular requirement is not SMART, it needs to be broken down into additional requirements and constraints that are SMART. The acceptance criteria for each requirement should be gathered at the same time as the requirement. By using the collected methods, the tests performed or qualities demonstrated in the final solution should prove that the requirements have been satisfied in a completely unambiguous manner.

Poorly formed service level requirements (SLRs) lead to ambiguity and unmeasurable or unverifiable success criteria. Properly formed SLRs should at least contain the following information:

  • Stakeholder

  • Goal

  • Context

  • Range

  • Hazard response

The stakeholder is the person or organization who owns or is driving the SLR. The stakeholder will need to see the output of your SLR verification. The presence of this SLR means that the stakeholder has already stated the goal, so it is your starting point for negotiation or analysis regarding how to measure or demonstrate that the goal has been, or will be, met.

The context should include the use cases or scenarios in which this goal is essential. The context sets some constraints on the SLR by describing the environment and exact steps the actor performs when the SLR will be measured or verified. In this way, the context provides some level of an unambiguous environment in which the SLA measurement will be made.

The range begins to outline possible acceptable outcomes, if appropriate. Are they really asking for exactly a 5-millisecond response time? Or, is a 2-millisecond to 7-millisecond response time acceptable? Is 80 percent less than 5 milliseconds another possible way to categorize this goal? These considerations can have important influences on the a solution cost and design choices.

The hazard response outlines what should happen when the SLR is not met (for example, when transaction time is above the threshold). For every SLR, there are three types of hazard responses to consider and discuss: measures you take to prevent the problem from happening in the first place, measures taken to alert someone before the problem goes too far, and a contingency plan for what to do when the problem does occur. The hazard responses that a customer is willing to build into the architecture are an indication of the importance of the requirement. Because hazard responses often involve people and process, they are also a good source of derived operational requirements.

Buliding N1 Grid Solutions Preparing, Architecting, and Implementing Service-Centric Data Centers
Buliding N1 Grid Solutions Preparing, Architecting, and Implementing Service-Centric Data Centers
Year: 2003
Pages: 144 © 2008-2017.
If you may any questions please contact us: