Sprint to VCIX (Part 4) — Determine Requirements, Constraints, Assumptions, and Risks

We are going to wrap up the conceptual design by categorizing the assessment findings into requirements, constraints, assumptions, and risks (RCARs).

Section 1 – Create a vSphere 6.5 Conceptual Design

Objective 1.3 for the VCAP-DCV Design exam is to Determine Requirements, Constraints, Assumptions, and Risks. vBrownBag hosted a 52-minute discussion on Objective 1.3 for the Design exam:

I think Rebecca Fitzhugh did a great job in the presentation. Personally, this is the most difficult part of the material to really lockdown. Throughout the vBrownBag series, many of the presenters do short quizzes on determining whether a statement is a requirement, constraint, assumption, or risk. Even at the writing of this article, I still spend quite a bit of time thinking about it. I have a management and design background and I still have to pay attention to the specific definitions of each concept.

“Determining the requirements, making and proving assumptions, determining constraints, and identifying risks forms the conceptual design and provides the foundation to build on for the logical design. Business and technical design factors that are identified as part of the conceptual design will be mapped to the resources that are necessary to satisfy them during the logical design process. The conceptual design phase is highlighted within the overall design and implementation flow diagram:”

VMware vSphere 6.7 Data Center Design Cookbook

The conceptual design is the combination of documented requirements, constraints, assumptions, and risks. It organizes design factors and qualities into a comprehensive reference for the rest of the design process. With a high-level diagram, the conceptual design is the foundation for design decisions.

Differentiate between the concepts of Requirements, Constraints, Assumptions, and Risks


There are two types of requirements: functional requirements and nonfunctional requirements.

Hersey Cartwright, one of the authors of VMware vSphere 6.7 Data Center Design Cookbook, outlined a simple explanation of functional vs. nonfunctional requirements in a Reddit reply:

“From a very high level the way I look at it is a functional requirement is the WHAT and a non-functional requirement (or constraint) is the HOW the WHAT has to be accomplished. Functional requirements are the things the design must do. A non-functional requirement would be a constraint on HOW the design meets the functional requirements. A customer specifically noting something does not change the type of requirement (functional or non-functional). A design must satisfy both the functional requirements and non-functional requirements.

Providing N+2 redundancy to support a failure during a maintenance operations (one thing in maintenance and one thing fails) is functionality the design must provide. Splitting a hair or two here, the better way the requirement might be listed is: Provide the redundancy to support a failure during a maintenance operation(WHAT). Then you might list N+2(HOW) as a constraint due to the level of redundancy the design must provide (WHAT). In a customer design I (and this is a personal thing) probably would not separate it like that – though it would probably be more correct when aligning directly to the VMware Design methodology.”

Hersey Cartwright, Reddit


WHAT must be done? A functional requirement specifies a function that a system or component must accomplish. Rebecca gives an interesting perspective in the video above: “The business can’t function…without meeting this requirement.”

  • Business goals, rules, or policies
  • Legal, regulatory, certification, and compliance requirements
  • Reporting requirements
  • Data Retention
  • Audits Trails

For example:

  • The design will store and transact customer PHI so it must meet HIPAA compliance
  • The design should allow for auditing of all user actions within the compute systems
  • The design must allow for backups


HOW must the WHAT be done? A nonfunctional requirement defines how the design accomplishes the functional requirements. These are descriptions, usually categorized as a design quality.

  • Availability
  • Manageability
  • Performance
  • Recoverability
  • Security

For example:

  • The patient PAC and EMR databases need to store up to 1000 patients’ records
  • The auditing system must be able to retain logs for at least 90 days
  • The backup storage system must be able to de-duplicate the data by at least 3x


“Constraints limit design choices. If multiple options are not available to make a design decision, then it’s a constraint.”

VCAP6-DCV Design Objective 1.3 with Rebecca Fitzhugh

Pre-existing vendor relationship/contract seems like a common stated constraint in the vBrownBag series and other resources. The vendor lock-in eliminates many design possibilities and features that could be made with freedom to go with another vendor.

Personal Thought: To me, most constraints are rooted in cost. If there was an unlimited budget, then you could forgo most constraints. This is how I differentiate between a nonfunctional requirement (often a constraint-ish statement desiring a specific quality — AMPRS) and a true constraint — the cost origin. The nonfunctional requirement is usually a constraint on the design with a feature or quality requirement that has room for decisions, whereas a constraint is a fixed limitation due to some unacceptable cost to the business.

In my mind, that alludes to the largest constraint, project budget. Every project will have a budget and the design will be constrained by how much money can be spent on the solution.

Other constraints I’ve seen have to do with business policies that dictate very specific technical methods: must use VPN to access internal resources, encryption standard/key lengths.

This is where I think people talk themselves into fitting things into one category or another while applying their own assumptions about a statement without being able to ask questions. As a test-taking strategy, I think it is important to make sure you do not read into the question too much and get yourself confused.

  • I think, on the test, the statement “External access must be through the standard corporate VPN,” by itself, is a constraint. Take it for face value and do not add your assumptions or experience.
  • In an actual customer engagement, I would ask if this is a security policy, compliance issue, or another factor that may give insight as to why we are being constrained in this way. The business is making this decision for a reason and the reason may be an arbitrary interpretation of a policy, standard, etc. turning this into a requirement that we can design around. If the reason is they don’t have the resources to have a new solution or it is out of scope (for whatever reason), then it is a constraint.


Assumptions are statements about the environment or design that are necessary to continue through the design process but have not been validated to be true. Many things at the beginning of the design will be assumed to be a certain way but need to be validated as true or false before implementation.

We need to document these assumptions and who we talked to about that assumption. Continuous assessment during the design process, ideally, gets us an assumption-free implementation.

For example:

  • The organization has sufficient bandwidth and low enough latency between sites to support replication.
  • The server closet HVAC can cool the new infrastructure.


Anything that may prevent you from meeting business or application requirements is a risk. All risks should be mitigated and documented in your design.

As we work through the design process and identify requirements, constraints, and assumptions; inherent risks will be identified. Limited choices and unknown variables introduce risk. These could be not having the resources to implement a best practice or not having the information required to design properly.

The vBrownBag had a great discussion on this risk: the organization’s main datacenter contains only a single core router, which is a single point of failure. This was identified in discovery but poses a risk to the virtual infrastructure and should be mitigated. The best practice would be to add core networking components, but that may be out of scope/budget. Identify, document, and reengage with stakeholders to try to mitigate the risk. Maybe they have a support contract with their vendor to do a 1-for-1 swap in less than 48hrs. Is that an acceptable amount of downtime for their datacenter? Perhaps the DC is in a COLO and they have a support SLA with them to mitigate lost revenue during downtime.

Given a statement, determine whether it is a risk, requirement, constraint, or an assumption

I think this is a pure test-taking objective and if we are solid in our understanding of RCARs then we should be able to read a statement or drag and drop statements in the test.

Analyze the impact of VMware best practices to identified risks, constraints, and assumptions

We need to be familiar with the VMware best practices so we can identify what constraints, assumptions, and risk will have impact on our design and know what we can do to mitigate those risks. This is from the VMware Networking Best Practices concerning recommended service bandwidth and limiting broadcast domain traffic:

Constraint: The project scope and budget do not allow for the purchasing of new networking devices. In-place 1Gbps network must be incorporated into the design.

Risk: VMware services and VM traffic will be limited to 1Gbps physical network

Impact: Possible network resource contention

Risk mitigation: LACP/LAGs, greater port density on hosts, teaming/failover, Network I/O Control, etc

Conceptual Design Diagram

Some of the vBrownBags use a rainbow blob as their conceptual diagram but the one above is pulled from the VMware SDDC Architecture Overview Documentation. I have given similar diagrams and briefs to Directors and non-technical leaders. I would add blocks representing each requirement and be prepared to discuss constraints, assumptions, and risks with business leaders.

I found another example from Craig Kilborn at VMFOCUS

This conceptual design will have the requirements represented as well as documented with the constraints, assumptions, and risks. This can sometimes be in a spreadsheet.

Section 1 Conclusion

This finishes up Section 1 from the VMware VCAP-DCV Design Exam guide. Next, we will start with Section 2 and start mapping conceptual design components to logical design components.

Leave a Reply

Your email address will not be published. Required fields are marked *