The Requirement Specification document lists the needs of the stakeholders and is used to drive design decisions and check that the solution is fit for purpose (ie. meets the needs of the stakeholders).

The requirements are divided into technical and service requirements and used in all of the workshops in the Designing stage to refine and improve the requirements and the design decisions and documents.

VMware Certified Professionals (VCP), IT Architects/Designers and Project Management Professionals (PMP or Prince2)

• Inputs to the Requirements Specification

• How the requirements are managed (submitted, change controlled, refined in workshops)

• Technical Requirements

• What constitutes a Technical Requirement

• Table of Technical Requirements

• Service Requirements

• What constitutes a Service Requirement

• Table of Service Requirements

• Outputs of the Requirements Specification

• Workshops

• Implementation

Requirements come from the VI3.Blueprint Business Case, the VI3.Blueprint Project Charter and the VI3.Blueprint Project Charter efforts, plus specifications learned in the VI3.Blueprint Proof of Concept need to be managed as they might be ruled out of scope, or changed in some way.

Having a document that states the requirements, and their specification, provides an objective, open view of what the project is supposed to achieved and through a process of change control, everyone understands how the requirements impact the project and vice versa.

The starting requirements come from the VI3.Blueprint Business Case and the VI3.Blueprint Project Charter. This exercise expands those to specify what they mean in terms that can be delivered by the project.

The requirements from the Business Case are taken from the Objectives section, or they can be taken from the Project Charter's Business Needs section. The list of requirements from these two documents is:

An additional input to Requirements Specification is a result of the findings of the VI3.Blueprint Proof of Concept. The PoC is like a scientific experiment, where hypothesis (e.g. this feature works) are tested (e.g. does this feature work?). The observations and findings in the PoC are a way to test early requirements (e.g. restricting remote SSH logon to ESX Host) and firming up the specifications (e.g. modify /etc/ssh/sshd_config to restrict remote SSH logon).

The total list of requirements should be refined through the workshops as part of the Designing stage. It is important to refine these before (are the requirements, relevant to this workshop, complete?) and after a workshop (update the requirements and specifications with workshop findings). So with the workshop list in your hand - go through the requirements to refine and add any requirements relevant to each workshop.

The workshops are divided into Technical and Service workshops, so the requirements are similarly divided though there is obviously close coupling between the two areas through things like tools (e.g. ESX Host design is a technical activity but reporting on capacity of that ESX Host is a service activity).

Starting with the original requirements from the VI3.Blueprint Business Case and the VI3.Blueprint Project Charter, the requirements are written into the Requirements Specification doc which is then owned by the Project Manager and placed under change control.

Any changes to the Requirements Specification document must adhere to the RACI Diagram specification in the VI3.Blueprint Project Charter. For any changes, ensure that the correct approval is obtained, consultation is sought, and communication is made to keep people informed - all as per the RACI Diagram.

What constitutes a Technical Requirement

Technical Requirements focus on the hardware and software assets and configurations in the solution, and they are refined in the Technical Workshops in the Designing stage.

Technical requirements are usually driven by:

• industry best practice (e.g. four pNICs per ESX host)

• corporate standards (e.g. VM vNIC can only connect to Internal network)

*How should a Requirement be Specified?

Each requirement maps to either a Technical or Service workshop and needs to be satisfied with a design decision.

To work out if that design decision will satisfy the requirement, we need some quality criteria to test against. An example is:

For this requirement, the design must specify four physical NICs for each host.

Table of Technical Requirements

|

MORE TO ADD AS THIS DOCUMENT IS COLLABORATED ON

What constitutes a Service Requirement

Service Requirements focus on the process between the technology and the end-user in the solution, and they are refined in the Service Workshops in the Designing stage.

An example of a Service Requirement is a Capacity Management "Alert on VMs that consistently use less than 10% CPU" for VM Recycling.

*How should a Requirement be Specified?

Each requirement maps to either a Technical or Service workshop and needs to be satisfied with a design decision.

To work out if that design decision will satisfy the requirement, we need some quality criteria to test against. An example is:

For this requirement, the design must specify how ESX SSH access will be restricted to IT Ops.

Table of Service Requirements

MORE TO ADD THROUGH COLLABORATION