<<Project Name>>

Operations Requirements

Customer Name

Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.

Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:

Heading 1 – Arial Bold 16 font
Heading 2 – Arial Bold Italic 14 font
Heading 3 – Arial Bold 13 font
Heading 3 – Arial Bold Italic 12 font

You may elect to indent sections for readability.

Author
Author Position
Date

Version: 1.0

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.

Revision & Sign-off Sheet

Change Record

Date	Author	Version	Change Reference

Reviewers

Name	Version Approved	Position	Date

Distribution

Name	Position

Document Properties

Item	Details
Document Title	Operations Requirements
Author
Creation Date
Last Updated

Description: The Operations Requirements describe what the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks. It addresses the key elements of operations - reliability, availability, scalability, supportability, and manageability.

Justification: Operations requirements define how the solution must behave in its operational environment. This information will influence the design, and establish measurement parameters for the solution’s success.

{Team Role Primary: Program Management is responsible for ensuring that the operations requirements are completed. Development has the primary responsibility for creating the content of the operations requirements document. Release will participate with Development both in content creation and review to ensure operational, deployment, migration, interoperability and support needs are addressed within the requirements document.

Team Role Secondary: Product Management will review and understand the operations requirements in order to convey those requirements to parties external to the team. Test and User Experience will review the operations requirements to understand their content and have context for developing their plans.}]

Operations Requirements Summary

[Description: Provide an overall summary of the contents of this document. This should include the criteria by which the operations requirements were established and how they were validated.

Justification: Some project participants may need to know only the document’s highlights, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.]

Scalability

[Description: The Scalability section uses the scalability requirements for business (located in the Business Requirements document) as context and describes the specific operational scaling requirements that the solution must meet. This should include a description of any constraints imposed by business, system, and user requirements that might impede scalability.]

Strong Security

[Description: The Strong Security section uses the security requirements for business (located in the Business Requirements document) as context and describes the security requirements and standards that must be met for the solution to go into production.]

Manageability

[Description: The Manageability section defines what needs to be in place to facilitate a highly manageable solution. This should include an understanding of the trade offs between manageability and time to market pressures. It should identify and describe the processes that must be in place to ensure successful solution manageability. This section should also identify and define any constraints imposed by business, system, and user requirements that might impact manageability.]

Supportability

[Description: The Supportability section defines the level of support the solution will require. This should include a definition of the support skill set requirements. Is should also identify and define any constraints imposed by business, system, and user requirements that might impede supportability.]

Availability/Reliability

[Description: The Availability/Reliability section defines the operational expectations of the solution’s availability and reliability. These requirements should be developed in the context of the business availability/reliability requirements (located in the Business Requirements document). This should include a description of the acceptable compromises to availability that won’t impact an existing SLAs.]

Staffing Requirements

[Description: The Staffing Requirements section describes the operations teams necessary to manage the solution, the specific roles and responsibilities for each team, and the baseline skill set requirements for each role.]

Operations Staff Training Requirements

[Description: The Operations Staff Training Requirements section defines the training requirements for the operational roles based on an assessment of current skillsets. This should include a definition of each skillset gap and the specific training required to close that gap.]

Service Level Agreement Summary and 7 x 24 x 365 Requirements

[Description: The Service Level Agreement Summary and 7 x 24 x 365 Requirements section identifies and describes the Service Level Agreements (SLAs) that must be in place in order for the solution to be accepted into production. If there are existing SLAs, this section should define what (if any) modifications are required to those agreements.]