One of the cornerstones of the way we work at SystemsUp is the use of our AssuredDelivery methodology. This is the process of project delivery performing the following steps in a prescribed order:-

  • Requirements
  • Discovery
  • High Level Design
  • Low Level Design
  • Implementation and Testing
  • Handover

There are many determining factors in the success of a project, but a solid list of Requirements (business, technical and otherwise) is key to setting strong foundations for delivery. By ensuring the Requirements document is accurate, realistic and measurable, we can increase the chances of delivery on time, on budget and to high quality by a large amount.

There are lots of excellent articles out there on the internet that cover this topic in some depth and this article is an attempt to distil this down into a single reference, to help you determine your requirements before the actual engagement begins.

Much like any document in a project, Requirements documents should be as unambiguous as possible. I find a lot of value in getting each iteration of the document peer reviewed to ensure any semblance of ambiguity is removed. This is not a vehicle for “dodging responsibility” but more to ensure both parties are in complete lock step on what the solution must deliver and how it will achieve that. All too often, assumptions can be made by both parties which may seem reasonable in isolation, but when not communicated lead to delays, additional cost and high impact to the project delivery timelines.

A “good” requirement has several characteristics and we’ll cover them individually below:-


This characteristic is singular in scope, meaning that the requirement covers one thing and one thing only. A good example of this in a public cloud project is “Azure virtual machines must reside in the UK South region“. A bad example of this is “Azure virtual machines must reside in a UK data centre, SQL Server instances in North Europe and Storage in West Europe“. The former example covers a single topic (virtual machines), whereas the latter example covers three topics (virtual machines, databases and storage).

Another way to quickly check that a requirement is unitary is to ensure the requirement does not feature “and, and, and” type verbiage – “Solution instances must reside in the UK South region and SQL Server instances reside in the North Europe region and Storage reside in the West Europe region and GRS enabled“.


In order to properly measure a requirement (see below), the requirement must be as unambiguous, clear and concise as possible. A good example of this is “Solution will use ten Azure Standard A4 Windows Server 2012 R2 instances with the Web Server role installed and configured to start on boot on port 443“. Conversely, a poor requirement might read “Solution will use Windows Servers with a web server enabled”.

Because the requirement is unambiguous, it then becomes easier to measure.


As in the example given above, because we express the requirement as  “Solution will use ten Azure Standard A4 Windows Server 2012 R2 instances with the Web Server role installed and configured to start on boot on port 443“, we then have several touch points within that requirement that can be measured or verified in a binary way, true or false.

The tests to verify this may comprise:-

  • Does the solution have ten A4 Windows Server instances?
  • Do all instances run Windows Server 2012 R2?
  • Is the Web Server role installed?
  • Does the Web Server service start automatically on boot on every instance?
  • Does the Web Server accept incoming traffic to port 443 on every instance?

Already you can see that just from a single, simple technical requirement expressed in a very clear manner that five tests flow from this to determine whether this requirement can be measured and deemed successful or not. For all of the tests listed above, should the answer be “no” to any of the questions, then the requirement compliance has not been met.

Consistent / Non-Contradictory

Requirements can often overlap but they should never contradict themselves. This is a recipe for project delivery failure. For example, one requirement may state “Solution must use Windows Server 2012 R2 Standard” but then another requirement may state “Instances running SQL Server must run Windows Server 2008 R2 Datacenter Edition“.

In this case, we have stated a strong technical requirement for a single version of Windows Server (but also made the statement ambiguous) but then have contradicted this requirement by stating that specific types of workloads (in this case SQL Server) must run a different version of Windows Server (in this case not just a different version but also a different edition). A better way to express this would be:-

Solution must use Windows Server 2012 R2 Standard for non-SQL Server workloads”

“Solution must use Windows Server 2008 R2 Datacenter for SQL Server workloads

By making this requirement clear, we have now made it unambiguous, measurable, consistent and unitary.


By ensuring that the requirement can be met with current technology, this makes the requirement realistic. One of the dilemmas with modern public cloud solutions is that solutions change on a daily, weekly and monthly basis with new features being added in a rapid manner. Also, you must not hedge your bets on your requirement being met at some point in the future, whether the feature needed is on a road map or not. Road maps tend to be for illustrative purposes anyway and offer no guarantees, and as such cannot and must not be relied upon.


Finally, one of the most important characteristics of a requirement is that it is feasible and realistic. The constraints on project delivery include the classic project management “triangle” of time, cost and quality. To affect one has a direct and material effect on the other two. If a requirement is to provide 500 IOPS per disk (because of an application dependency, for example) but Basic Azure VMs are stipulated as a requirement on cost grounds, this is not realistic because of the fact that Basic Azure VMs provide only 300 IOPS per disk.

Either the cost requirement must change or the IOPS requirement must be addressed in a different way.


I realise the topic of requirements analysis and documentation is pretty dry stuff, but this should be offset against the reality that having a sound Requirements Document agreed by all stakeholders that adherse to the principles listed above, helps to ensure the success of a public cloud deployment, whether it is “lift and shift” IaaS or CI/CD deployments with GitHub and Jenkins.

By Chris Beckett, Technical Consultant, SystemsUp  

To find out more about how SystemsUp works to deliver successful outcomes for public cloud projects please contact us   

Further References

Requirement” – Wikipedia, September 2016

The Quest for Good Requirements” – BA News, January 2011

Related Post