VCAP6.5-DCV Design - Objective 1.3 Determine risks, requirements, constraints, and assumptions

This blog post covers objective 1.3 (Determine risks, requirements, constraints, and assumptions) of the VCAP6.5-DCV Design exam. It is based on the VMware Certified Advanced Professional 6.5 in Data Center Virtualization Design (3V0-624) Exam Preparation Guide (last update August 2017).

The first objective of the exam prep guide has covered the business requirements. Now we have to do similar for the affected applications.

The necessary skills and abilities are documented in the exam prep guide for the older VCAP6-DCV Design exam (3V0-622). I think they also apply to the current version of the exam:

  • 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

Differentiate between the concepts of risks, requirements, constraints, and assumptions

I wrote a couple of times about risks, requirements, constraints and assumptions, but I missed to explain the meaning of each of these terms. I will use the following order:

  • requirements
  • risks
  • constraints
  • assumptions

So let us start with “What is a requirement”? A requirement is something that a has to be achieved. This can be applied to business or technical things. Without defined requirements, you would have no clue what your design should cover. If you define a requirement, you should test it with the following question: Is the defined requirement

  • specific
  • feasable
  • verifiable
  • traceable
  • unambiguous

When we talk about requirements, we have to differ between functional (WHAT) and non-functional (HOW) requirements. Some examples:

  • Solution must comply with ISO standards
  • The uptime must be at a minumum of 99,9%
  • Users must be able deploy new virtual machine within 15 minutes after approval

A Risks is a potential event, that might prevent us from achieving the defined project goals, or which can cause that the project completely fails. They are often common points in every projekct. The best we can do is to identify and list every risk that might prevent us from successfully finish the project. Some examples:

  • Missing the delivery date
  • Vendor discontinued parts of the solution
  • Hidden incompatibility with currently used frameworks

Constraints can be a limiting factor when we design our solution. They can be understood as cornerstones that set the borders of our solution. Contraints are always very specific. Examples:

  • The costs per user must not exceed 5 €
  • The project has to be finished withing 9 months
  • The solution must include servers from HPE

In opposite to constraints, which are very specific, assumptions are considered to be true without proof in the planning phase. This is pretty important! We are talking about the time, when we put our design together. Examples:

  • Rackspace will be available when the HW needs to be deployed
  • A MS SQL database server will be available at the installation date
  • A specific decision is made when needed


As I wrote at the beginning of this article: It is important to understand these terms. In simple words:

  • requirements: Things that have to met to successfully finish the project
  • risks: Things that might happen and that put our project at risk
  • constraints: Limiting factors to our project design
  • assumptions: Things that are considered to be true, but that are not proofed during the planning phase

That is a pretty simple summary, but it should be good enough to be memorized. :)