<<Project Name>>

User 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

User Requirements

Author

 

Creation Date

 

Last Updated

 

 



 

Table of Contents

Summary

User Experience

Ease of Use

Reliability

Performance

Multi-language Requirements

Accessibility

End-User Training Requirements

 


 

[Introduction to the Template

 

Description: The User Requirements document defines the non-functional aspect of the userís interaction with the solution. It provides guidance on the user interface, expectations of the solutionís performance, reliability, and accessibility, and defines what must be done in order to properly train the users on the solution. 

 

Justification: A successful solution satisfies both the organizationís need for technology and the userís expectations for employing that technology. Strong, explicit user requirements facilitate the development and delivery of a solution that users consider an asset to their organizational activities.

 

{Team Role Primary: Program Management is responsible for ensuring that the user requirements document is completed in a timely manner. Development has the primary responsibility for creating the content of the user requirements document. User Experience is responsible for ensuring that all relevant user roles and user perspectives and needs are identified.

 

Team Role Secondary: Product Management will review and understand the user requirements document in order to convey those to parties external to the team and to ensure that user requirements are represented according to initial project sponsor requirements. Test will review the user requirements to ensure test plans are in place to validate the requirements. Release Management will review the document to ensure operational, deployment, migration, interoperability and support needs are addressed.}]

 


 

Summary

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

User Experience

[Description: The User Experience section lists and defines the user experience requirements. This includes a description of the elements of the current user experience that are acceptable for the new solution and what elements need to change to surpass the current user experience. This section may also define the processes that will collect feedback from the user community regarding how well the requirements were implemented.

 

Justification: This information supports the approach that puts the user, rather than the technology, at the center of the process. Gathering user concerns and expectations promotes the principle that the usersí needs should be foremost in any design decisions.]

<<Begin text here>>

 

Ease of Use

[Description: The End of Use section defines the usersí ability to employ the solution without any negative impact on their primary work responsibilities. Ease of use requirements may include a definition of the solutionís flow/navigation and interface design (simplicity, alignment with other solutions already in place, intuitive, etc). This section may also define the processes that will collect feedback from the user community regarding how well the requirements were implemented.

 

Justification: This information supports the approach that puts the user, rather than the technology, at the center of the process. Gathering user concerns and expectations promotes the principle that the usersí needs should be foremost in any design decisions.]

<<Begin text here>>

 

Reliability

[Description: The Reliability section describes the usersí expectations on how reliable the solution must be. This information may be stated at both the solution level as well as the feature level. This section may also define the processes that will collect feedback from the user community regarding how well the requirements were implemented.

 

Justification: Reliability expectations from the users are from their business perspective - what the solution must deliver to ensure their productivity. This is important information that will lead to designing a solution that is stable and trustworthy in its operational environment.]

<<Begin text here>>

 

Performance

[Description: The Performance section describes the usersí expectations on the solutionís performance, usually described as application response time. This information may be stated at both the solution level as well as the feature level. This section may also define the processes that will collect feedback from the user community regarding how well the requirements were implemented.

 

Justification: Performance expectations from the users are from their business perspective - what the solution must deliver to ensure their productivity. This is important information that will lead to designing a solution that is stable and trustworthy in its operational environment.] 

<<Begin text here>>

 

Multi-language Requirements

[Description: The Multi-Language Requirements section identifies any international support that the solution must address.

 

Justification: Understanding these requirements early will enable the development team to design all international support features into the solution and ensure that the entire scope of users is accommodated.]

<<Begin text here>>

 

Accessibility

[Description: The Accessibility section identifies the handicap/accessibility requirements that the solution must meet. Examples of these are support for multiple hardware input types, support for existing operating system accessibility features, etc.

 

Justification: Understanding these requirements early will enable the development team to design all support features into the solution and ensure that the entire scope of users is accommodated.]

<<Begin text here>>

 

End-User Training Requirements

[Description: The End-User Training Requirements section defines the training requirements that must be met prior to the solutionís production deployment. This information does not identify specific training events or mediums (that information is in the Training Plan). Training requirements define the competencies that the users must have in order to employ the solution successfully and identifies where users do not currently have those competencies. The gap between the needed competency and the existing competency becomes the training requirements.

 

Justification: The Training Plan is created based on the training requirements.]

<<Begin text here>>