<<Project Name>>

Business 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:

You may elect to indent sections for readability.

 

 

 

Author

 

Author Position

 

Date

 

 

 

 

 

Version: 1.0

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ó 2002 Microsoft Corporation. All rights reserved.

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

Business Requirements

Author

 

Creation Date

 

Last Updated

 

 



 

Table of Contents

Business Requirements Summary

Cost Benefit Analysis – ROI

Scalability for Business Needs

Availability/Reliability for Business Needs – Access to Services and Solution

Strong Security

Support for Multiple Device Types

Performance Requirements

Accountability and Audit Back to Business Sponsors

 


 

[Introduction to the Template

 

Description: The Business Requirements document defines the needs of the organization with regards to the solution. While user requirements address individual or groups of users, operations requirements address the needs of the operating environment, and system requirements address the hardware and operating system needs, the business requirements define what the solution must deliver to capitalize on a business opportunity or to manage business challenges. 

 

Justification: Creating business requirements treats the organization as a legitimate entity that has its own set of needs for the solution. These requirements exist at the managerial decision-making level and provide “bottom-line” context for the solution.]

 

{Team Role Primary: Program Management is responsible for ensuring that the Business Requirements document is completed and its content is consistent with the Vision/Scope document. Product Management and Development have the primary responsibility for creating the content of the business requirements. Development will contribute to the technical sections of the document and be familiar with all its content to ensure they have a solid framework for creating the remaining requirements documents. 

 

Team Role Secondary: All other roles will review and understand the business requirements to use as context for their plans.}]

 


 

Business Requirements Summary

[Description: Provide an overall summary of the contents of this document. This should include the criteria by which the business 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.]

<<Begin text here>>

 

Cost Benefit Analysis – ROI

[Description: The Cost Benefit Analysis - ROI section defines how the customer will derive value from the solution. It connects the customer’s business goals to the specific performance expectations realized from the solution. This information should include an estimate of solution cost and how that investment will be converted into savings and/or revenue for the customer. 

 

Justification: All investments need to show a return. Developing this section assists the team in understanding the project’s overarching drivers.]

<<Begin text here>>

 

Scalability for Business Needs

[Description:  The Scalability for Business Needs section defines how the solution must be able to respond efficiently to business growth expectations. This information includes a description of the expected growth in terms of time, magnitude, and location.

 

Justification: This information describes the measured process that will ensure that the delivery of versioned solutions do not impede stability and supportability.]

<<Begin text here>>

 

Availability/Reliability for Business Needs – Access to Services and Solution

[Description: The Availability/Reliability for Business Needs – Access to Services and Solution section defines the business sponsor’s expectations of the solution’s availability. It describes the tolerance for availability versus cost. In some scenarios, 7x24x365 must be ensured regardless of cost. In other scenarios, a minimum hour downtime per day or week is acceptable in off hours to reduce the cost of solution. This section specifies the time periods that are acceptable for downtime and those where availability must exist.

 

Justification: This information will influence the design.]

<<Begin text here>>

 

Strong Security

[Description: The Strong Security section describes the overall the solution’s security vision and answers the following questions at a strategic level:

 

 

Justification: This information will influence the design.]

<<Begin text here>>

 

Support for Multiple Device Types

[Description: The Support for Multiple Device Types section defines the need to support the solution across many possible devices/form factors. It also identifies the acceptable and unacceptable constraints for feature degradation.

 

Justification: This information will influence the design.]

<<Begin text here>>

 

Performance Requirements

[Description: The Performance Requirements section defines the performance metrics the solution must meet across all user groups and deployments (i.e., screen load on a PDA must be under 10 seconds, complete with data population). This information should identify metrics for all key elements of the solution.

 

Justification: This information will influence the design.]

<<Begin text here>>

 

Accountability and Audit Back to Business Sponsors

[Description: The Accountability and Audit Back to Business Sponsors section identifies the metrics that will quantify and qualify that the solution meets its business requirements. It should include a description of what will be measured and to whom that information will be conveyed within the sponsoring business unit.

 

Justification: This information creates accountability and creates confidence for the customer.]

<<Begin text here>>