User Requirements Specification Free Document Template
This document template allows you to document all business policy relevant to the development of the product or feature. It should be used as the basis for determining development priorities. This means that as well as describing the functionality required of the product or feature at a high level it may also cover:
- Operational responsibilities
- Product or feature performance and resilience
- Security
- Archiving and audit
- Migration and acceptance of the product or feature
The purpose of this free document template is to detail the user requirements for the
The target audience of this free document template is commercial and technical readers who wish to gain a detailed understanding of the functional and non-functional requirements for the
The scope of this free document template is to provide sufficient detail on the functional and non-functional requirements of the
How this free document template is organized
This free document template is divided into three chapters. The first chapter provides a system overview in order to put the various topics, as presented in subsequent chapters, into perspective.
The second chapter focuses on the functionality offered by the ABC system. It contains basic functionality, functionality which can be tailored to the customer’s needs and optional functionality.
The third chapter focuses on the interfaces to external systems. It describes the capabilities of these interfaces and how they relate to the systems functionality.
The document covers the following topics:
- How this free document template is organized
- Business Requirements
- Background, Business Opportunity and Customer Needs
- Business Objectives/ Success Criteria
- Major Features
- Assumptions / Dependencies
- Known Constrains
- Use Cases
- Product / Feature Requirements
- General / User Requirements
- Future Enhancements
- User Requirements Specification Free Document Template Download
- Free Online Document Template: Copyrights Guidance
Business Requirements
Background, Business Opportunity and Customer Needs
Introductory information on the business opportunity and/or customer needs being addressed by the proposed functionality. Include any background information, including a historical perspective where relevant. If this information has been provided in the Statement of Work then it could be included or summarized here.
Example
The hiding, or aliasing, of subscriber MSISDN values to prevent unauthorized messaging by external content providers was first implemented for AA Telecom in release 1234. This implementation used a proprietary encryption algorithm provided by AA Telecom. This functionality was required by AA Telecom to address legislative demands within France for the protection of the personal details of mobile subscribers.
Since this time there have been a number of RFI/ RFQs requesting this same functionality and so it has been determined that generic subscriber MSISDN aliasing should be introduced into the Telecom product.
Business Objectives/ Success Criteria
Provide a summary of the business objectives and success criteria. These will be detailed further in the following section.
Major Features
List the key high level user requirements as determined from initial customer contact. These can be summarized from a customer-provided requirements document, from Remedy CRs or customer requirements elicitation sessions.
Assumptions / Dependencies
List here any assumptions or dependencies that are present at the time of writing. These may be outstanding issues awaiting clarification by the customer or dependencies on delivery of code/systems by a third party.
Known Constrains
List here any known constraints that are present at the time of writing. These may anything getting in the way of the job done and must be worked around (thus this is different than a dependency), or may be known limitations/boundaries on implementation that must be honored by the specification/design. Where dependencies must be cleared for implementation, constraints will likely remain in place for the full life cycle.
Use Cases
This section would only be present where a UML approach is being used to gather user requirements.
Product / Feature Requirements
Where a use-case approach is being used and section 3 is present then this section may optionally be included for user requirements that cannot be described with use-cases.
Where use-cases are not used and section 3 is not present then this section is mandatory to describe the user requirements.
General / User Requirements
This chapter details additional requirements that were not covered in the preceding sections. This will include customer specified non-functional requirements.
Future Enhancements
This chapter should be included to record any functionality that has been identified but not scheduled for immediate development. It may include items with varying levels of detail:
- Fully described but scheduled for later implementation.
- Described in outline only.
- Identified as a possible future application.
User Requirements Specification Free Document Template Download
