Operations RequirementsProject Name
Operations Requirements
The Operations Requirements describe what the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks.
The paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized.
September 17, 2008
Revision Chart
This chart contains a history of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created.
The document itself should be stored in revision control, and a brief description of each version should be entered in the revision control system. That brief description can be repeated in this section.
Version / Primary Author(s) / Description of Version / Date CompletedDraft / TBD / Initial draft created for distribution and review comments / TBD
Preliminary / TBD / Second draft incorporating initial review comments, distributed for final review / TBD
Final / TBD / First complete draft, which is placed under change control / TBD
Revision 1 / TBD / Revised draft, revised according to the change control process and maintained under change control / TBD
etc. / TBD / TBD / TBD
Preface
The preface contains an introduction to the document. It is optional and can be deleted if desired.
Introduction
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.
Contents
New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.
1.Introduction......
1.1Operations Requirements Summary......
1.2Definitions, Acronyms, and Abbreviations......
1.3References......
2.Scalability......
3.Strong Security......
4.Manageability......
5.Supportability......
6.Availability/Reliability......
7.Staffing Requirements......
8.Operations Staff Training Requirements......
9.Service Level Agreement Summary......
10.Index......
11.Appendices......
List of Figures
New figures that are given captions using the Caption paragraph style will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.
This section can be deleted if the document contains no figures or if otherwise desired.
Error! No table of figures entries found.
1.Introduction
This section should provide an overview of the entire document. No text is necessary between the heading above and the heading below unless otherwise desired.
1.1Operations Requirements Summary
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.
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.
1.2Definitions, Acronyms, and Abbreviations
Provide definitions or references to all the definitions of the special terms, acronyms and abbreviations used within this document.
1.3References
List all the documents and other materials referenced in this document. This section is like the bibliography in a published book.
2.Scalability
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.
3.Strong Security
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.
4.Manageability
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.
5.Supportability
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.
6.Availability/Reliability
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 any existing SLAs.
7.Staffing Requirements
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.
8.Operations Staff Training Requirements
The Operations Staff Training Requirements section defines the training requirements for the operational roles based on an assessment of current skill-sets. This should include a definition of each skill-set gap and the specific training required to close that gap.
9.Service Level Agreement Summary
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.
10.Index
The index is optional according to the IEEE standard. If the document is made available in electronic form, readers can search for terms electronically.
11.Appendices
Include supporting detail that would be too distracting to include in the main body of the document.
Operations_Requirements.doc (04/30/09)Page 1