This blog post has not the intend to define what a requirement/constraint is, there are already very good posts out there. Lately I pointed a lot of people over to Jeffrey Kusters who did an excellent job of summarizing it but I included also two other good links:

What is this about?

If you are like me, coming from a pure technical background, the conceptual model of the VCDX exam proves to be the hardest part - especially since your journey starts with it and there is no shortcut around it (Rene gives good advice, as always https://vcdx133.com/2014/07/09/vcdx-how-do-i-measure-if-my-customer-requirements-are-being-met/)).  Think of the conceptual model like the foundation of a house, if it is not solid everything you build on top of it will collapse eventually (btw: It happened to me, forcing me to re-write on more than one time. Pro tip: don’t be like me on this).

Summing it up: Ideally this post forces you to realise that you need to invest time into the process of learning on how to develop a conceptual model and, with as the post has a focus on requirements, learn that they do not come out of thin air. There is actually a whole field called “requirement engineering” which has the target to gather and formulate requirements - just to give you a feeling for the relevance of this topic.

Requirement engineers have methods and techniques which you can study. Use this to build an understanding of what is relevant and how it is done. Try to apply this by formulating some solid requirements for your VCDX process (and keep that knowledge for your future projects).

Where do I start?

You know, there is always google :-)

Seriously, (solid) requirements are needed in a lot of places, one of my favorite reads is provided by the NASA.
They have a whole book online, for free - start looking at chapter 4, the System Design process: https://www.nasa.gov/connect/ebooks/nasa-systems-engineering-handbook

Do you need to read all of this and how does this all apply to VCDX?

Heck, no you don’t need all of this! But start digging into it and you learn some good stuff - they key here is building an understanding to know why requirements are important. For instance, I like the “TABLE 4.2-1 Benefits of Well-Written Requirements”.

Also, did you consider to try to talk to people who deal with requirements on a daily basis? Do you know any project manager or software developer/architect? They might be more than happy to help you out.

Can you sum it up, what does it mean for my VCDX document?

I cannot give you a definitive answer but a few personal opinions:

  • Write a requirement like the stakeholder investing money, not like the tech nerd you are (I include myself here).
  • Don’t focus on the implementation and do not make a hidden design decision out of a requirement: Focus on what the system/infrastructure needs to achieve, not how.
  • Did you test if other people understand your requirement? Ask around, also among non-technical people. Does everybody expects the same when reading your requirement?
  • For the majority of requirements, do not use subjective adjectives, e.g. what do you mean by fast storage? People might have different opinions on that.
  • Going in the same direction as the bullet point above, can you validate your requirement in any way? (Yes, this is one reason why there is a validation plan in the VCDX)
  • Be specific, set scope and expectations: Like when you include growth in percent, is it measured from your baseline or a “year over year”-value? For how many years do you need to plan? Which areas (compute, storage, …) do you need to consider?
  • Avoid any mis-interpretation with negative requirements, e.g. must not do X or Y. The “not” might be easily overlooked and there is still room for the question what the design must do.

On the topic of how much meta-data a requirement needs, I had a table with the following information:

  • Unique ID: Allows you reference the requirement in your design
  • Description: The main matter of a requirement.
  • _Design quality: _More for my sake to ensure I got everything covered
  • _Issuer: _Who signed off on the money going into this requirement?

I won’t say it is perfect but it did the job and it may be a good starting point if you haven’t considered anything in this regard.

The end

This is not much but I hope it points candidates into the right direction. I am always open for discussion and feedback, hit me on twitter if you like!

Disclaimer: Honestly, I feel like an imposter for writing this, constantly debating with myself if I can dare to put this out into the wild as I feel that my own stuff was not stellar. However, with some support from Bilal and Chris I decided to go for it. After all, it is a topic most candidates struggle with and I was no exception.