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 |
|
Ó 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
Change Record
|
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 |
|
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.}]
[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>>
[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>>
[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>>
[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>>
[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>>
[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>>
[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>>
[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>>