This post is intended to address the VCAP design objective around determining risks, requirements, constraints and assumptions. At the time of writing, the required ‘Skills and Abilities’ listed by VMware for this topic are:
- Differentiate between the concepts of risks, requirements, constraints and assumptions
- Given a statement, determine whether it is a risk, requirement, constraint or an assumption
- Analyze impact of VMware best practices to identified risks, constraints and assumptions
This objective is fairly straight forward – you need to know the differences between risks, requirements, constraints and assumptions. This will be a short post to cover these topics, with a short section on each concept.
Requirements
A requirement can be defined as a need that must be met. It could be a business need or a technical need, and must be met as part of the design. There can be functional and non-functional requirements.The linked document states the following:
Functional requirements specify specific behavior or functions, for example:
“Display the heart rate, blood pressure and temperature of a patient connected to the patient monitor.”Non-functional requirements specify all the remaining requirements not covered by the functional requirements. They specify criteria that judge the operation of a system, rather than specific behaviors, for example: “Display of the patient’s vital signs must respond to a change in the patient’s status within 2 seconds.”
Essentially, a functional requirement defines what the requirement is (what is must do) whilst a non-functional requirement is about how it functions (how it does it).
The requirements will have been defined by the customer, and discussed and documented during interviews with the project stakeholders. Aim to avoid ‘vague’ requirements where possible. For example, there may be a requirement to design a solution with future growth in mind. Ideally the documented requirement should specify what the percentage growth will be so that it can be accommodated in the design.
Examples of a requirement could be:
- The solution must be highly available
- The solution must meet defined security objectives
- The solution must provide a way to fail over virtual machine workloads across data centers
The above are a mixture of requirements – avoid ‘vague’ requirements such as ‘the environment must be scalable’, in favor or requirements which are stated clearly such as ‘The environment must be capable of supporting increased compute utilization of 20% per year over five years’.
Constraints
A constraint is something that will limit the choices you have for a design – a limitation or restriction. For example you may be restricted around the choice of hardware due to an existing vendor relationship a customer may have.
Assumptions
An assumption is something that is understood to be true, though not verified, whilst putting a design together. Examples of assumptions could be that:
- There will be a syslog server available for logging
- There will be sufficient network port capacity for new servers
All assumptions that affect the design should be listed in the design documentation.
Risks
A risk is something that could negatively affect the outcome of the project, or could adversely affect the design. An example of a risk could be “The design will be deployed on aging hardware”.