Quite recently, I have reviewed some designs that contained some wrongly defined requirements. A wrongly defined requirement can have a huge impact on the design, that’s why I thought it would be a good idea to put together a post with some background information about this topic.
Requirement vs Constraint
According to Wikipedia, a requirement is described as follows:
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
It is not to be mixed up by a constraint, which is described as:
A restriction or limitation on the degree of freedom you have in providing a solution.
Two examples:
1. The solution should be available from outside the company premises.
2. The solution must be built on existing HP hardware
The first one states that you should design a solution that is available from external locations. Because this doesn’t limit you in your choices of the design, but purely gives you a drive in a certain direction, therefore this is a requirement.
The second example is a specific limitation to your design choices (because you got none) and thus is a constraint.
Requirements gathering
Requirements gathering is the most important part of the design process. Because these gathered requirements will drive your design. For instance, if a company requires an availability of the VDI service of 99% per year, it would mean that the service could only have a downtime of 3 days and 15 hours per year. In that case, it is not necessary for the VDI to be deployed in a multi data center platform with active/active load balancing. Recovering the VDI from a backup is quite doable within that timeframe.
But, let’s say if the customer requires an availability of four nines (99,99%), one data center will likely be insufficient. This means that the VDI will only tolerate 52 minutes downtime per year to still be compliant to the SLA.
The most important thing for every requirement, is that they can be validated. So, if your customer has as requirement for 99,99% availability and you decide to build a single data center based VDI solution, make sure you can validate that in case of a disaster you are able to make the VDI solution available again within 52 minutes.
Another example is performance. If your customer has the equirement that the process from clicking a remote desktop icon on an endpoint until the moment the user is presented with a desktop is 1 minute, make it SMART (and be sure you can validate it.
For both requirements, it is also important that they are monitored. You want to make sure that as soon as the load on a platform grows, you are still able to be compliant to the requirements in the design.
Requirements must always be accompanied with a design scope or context. The number of users, working locations and infrastructure sizing (aggressive or conservative) are all examples of scope items. So, if you agree with a customer that they have a maximum of 2000 users and during the deployment you are able validate that the performance requirement for the logon process is compliant, you did a good job. But as soon as the customer decides to add an additional 1000 users to the current platform without adding additional host/storage capacity, the infrastructure might violate the performance SLA. So, make sure that the design scope and requirements are clearly described and signed off by the customer.
Functional vs Non-Functional Requirements
Requirements can either be functional or non-functional.
A functional requirement describes what the system should do.
Typical functional requirements include:
• Business Rules
• Transaction corrections, adjustments and cancellations
• Administrative functions
• Authentication
• Authorization levels
• Audit Tracking
• External Interfaces
• Certification Requirements
• Reporting Requirements
• Historical Data
• Legal or Regulatory Requirements
For example:
• The user should be able to install software in their own virtual desktop.
• The user should be able to use a USB headset for VOIP integration.
A non-functional requirement describes how the system the system performs a certain function.
Typical non-functional requirements include:
• Performance
• Scalability
• Capacity
• Availability
• Reliability
• Recoverability
• Maintainability
• Serviceability
• Security
• Regulatory
• Manageability
• Environmental
• Data Integrity
• Usability
• Interoperability
For example:
• The VDI platform should have an uptime of 99,9%
• Login on to the desktop should not take longer than 20 seconds.
Design qualities
Requirements can be categorized in qualities. The most common design qualities are:
Manageability
The effect of a design choice on the flexibility of an environment and the ease of operations in its management. Sub-qualities might include scalability and flexibility.
Availability
The effect of a design choice on the ability of a technology and the related infrastructure to achieve highly available operation.
Recoverability
The effect of a design choice on the ability to recover from an unexpected incident that affects the availability of an environment.
Security
The effect of a design choice on overall infrastructure security. As a design quality, security may also indicate whether a design has an impact on the ability of a business to demonstrate or achieve compliance with certain regulatory policies.
Performance
The effect of a design choice on the performance of the environment. This does not necessarily reflect the impact on other technologies within the infrastructure.
Scalability
Depicts the effect the option has on the ability of the solution to be augmented to achieve higher sustained performance within the infrastructure.
More design qualities can be found on the following Wikipedia page:
https://en.wikipedia.org/wiki/Non-functional_requirement
Example
When you take a road warriors use case as an example:
Road warriors are sales and consultancy employees who spend at least 90% of their time outside the company offices. They need secure access to business-critical applications such as the CRM and project management tools. Depending on the location of the customer and their business hours, road warriors might work outside of the standard business hours of the company.
We can extrapolate a couple of requirements from this use case story:
• The VDI must be available from outside the company premises.
• The VDI must be available outside of the company business hours.
• Access to the VDI must be secured.
These requirements will be the base for design decisions that you are going to make in a logical design such as “Unified Access Gateways will be used to provide a desktop to external users”. In this case, this decision is justified with the requirement that the VDI must be available from outside the company premises.
I hope this gave you a better understanding of what a requirement is and how important the Requirement gathering phase at a project actually is.
- VMware Explore 2023: Back to Vegas Baby! - July 11, 2023
- My session picks for VMware Explore 2022 in Barcelona - September 27, 2022
- VMware Explore 2022 EUC Recap - September 26, 2022
