This post is intended to address the VCAP design objective around gathering and analyzing business requirements. At the time of writing, the required ‘Skills and Abilities’ listed by VMware for this topic are:
- Associate a stakeholder with the information that needs to be collected.
- Utilize inventory and assessment data from a current environment to define a baseline state.
- Analyze customer interview data to explicitly define customer objectives for a conceptual design
- Determine customer priorities for defined objectives.
- Ensure that Availability, Manageability, Performance, Recoverability and Security (AMPRS) considerations are applied during the requirements gathering process.
- Given results of the requirements gathering process, identify requirements for a conceptual design.
- Categorize requirements by infrastructure qualities to prepare for logical design requirements
There are a lot of great resources to cover the topics required for this objective. I’ve included a list of useful pages at the bottom of this page. The rest of the content here are my notes on some of the things relevant for this objective.
This topic is all about how to approach the initial phase of a design, which involves collecting information from various sources, then organising and categorizing it with the aim of creating a conceptual design then, later, a logical design.
Associate a stakeholder with the information that needs to be collected
Stakeholders are the people that have an interest in the work that is going to be carried out. These could be, but not limited to:
- Director of IT
- SMEs
- Network Engineers
- Storage and Backup Engineers
- Virtualisation and Wintel Engineers
- CEO
- CFO
- CTO
- End-Users
Once individuals have been identified, interviews should take place to discuss their requirements, and to help get an understanding of the current environment.
Utilize inventory and assessment data from a current environment to define a baseline state
This is about understanding what the environment currently looks like. What is deployed in the current environment? Here we can use a number of tools to gather data to help us understand what is deployed. Tools such as:
- VMware Capacity Planner
- Microsoft Map Tool (link)
- Performance monitoring tools such as perfmon
- Powershell
- Custom Scripts
- WMI
The data gained from running these tools can then be used alongside interviews with the stakeholders and existing environment documentation to get as complete a picture of the current environment as possible.
Analyze customer interview data to explicitly define customer objectives for a conceptual design
This is about determining what the objectives for the design are. This will entail collecting and documenting information around the following:
- Design Goals – what is the purpose of the design, and over what time frame?
- Scope – Agree and state clearly what is and what isn’t in scope
- Business Requirements – These include both functional and non-functional requirements. These requirements should be addressed in the design. E.g it might be a requirement that the solution must be designed for high availability and designed for scalability for future expansion, or that there are particular security requirements, and so on. All business requirements should be documented.
- Constraints – For example, the hardware, storage and network equipment to be used may be pre-determined. It may be that the business uses a particular hardware vendor, or storage vendor.
- Assumptions – This could be something like ‘Licenses will be supplied prior to the project implementation’ or ‘Customer will provide syslog server for log collection’ and so on.
- Risks – Any identified risks should be documented. An example could be that there’s a dependency on another project or that budget has not yet been agreed.
All of the above should be documented and tracked. One approach would be to create a ‘workbook’ document where all requirements, risks, constraints etc are listed.
It’s important to understand the difference between functional and non-functional requirements. A functional requirement describes what a software system should do, while non-functional requirements place constraints on how the system will do so.
Determine Customer Priorities for Defined Objectives
Once the requirements/objectives have been established, it will be necessary to determine the priorities for each and their importance.
Ensure that Availability, Manageability, Performance, Recoverability and Security (AMPRS) considerations are applied during the requirements gathering process
It’s important to understand the definitions of each of these, as a design should cover the requirements for all of these areas:
- Availability: requirements to deliver highly available operation in compliance with SLAs, as measured by percent uptime of relevant components. For example, requirements around HA configuration.
- Manageability: requirements for ease of managing the environment and maintaining normal operations. Sub-qualities may include scalability and flexibility. This could cover topics such as alerting and reporting, and access models.
- Performance: required standards of responsiveness of components of the designed environment. This covers requirements around performance of the environment for compute, storage, network etc.
- Recoverability: requirements for the ability to recover from an unexpected incident that affects the availability of an environment. Topics such as backups and disaster recovery need to be addressed here.
- Security: This covers the requirements for overall data control, confidentiality, integrity, accessibility, governance, and risk management, often including the ability to demonstrate or achieve compliance with regulation.
Given results of the requirements gathering process, identify requirements for a conceptual design
Once you have collected all the information discussed above, such as the requirements, the environment state data from the discovery tools and the interviews with the relevant stakeholders you should be in a position to begin putting together a conceptual design. This document can then be reviewed with key stakeholders – this is an iterative process, and it’s important to make sure everything is covered. Once the high-level conceptual design is approved, the next stage is to move on to putting the logical design together.
Categorize requirements by infrastructure qualities to prepare for logical design requirements
This is simply about categorizing the documented requirements into ‘infrastructure qualities’, e.g storage, networks and so on, which will help when creating the logical, high-level, design.