<Project Name>

Business Requirements Template

Version:

Status:

Author:

Document Location:

raidlogs.co.uk Business Requirements Template Page: 1 / 16

Table of Contents
1. Document Control............................................................................................3
1.1 Version Control............................................................................................................. 3
1.2 Document Distribution................................................................................................... 3
1.3 Document Sign Off........................................................................................................ 3
1.4 References.................................................................................................................... 3
2. Executive Summary.........................................................................................4
3. Introduction......................................................................................................5
3.1 Document Purpose....................................................................................................... 5
3.2 Document Scope.......................................................................................................... 5
3.3 Stakeholders................................................................................................................. 5
3.4 Associated Documentation........................................................................................... 5
4. Project Summary..............................................................................................6
4.1 Project Background....................................................................................................... 6
4.2 Project Objectives......................................................................................................... 6
4.3 Project Scope................................................................................................................ 6
4.4 Assumptions & Constraints........................................................................................... 6
4.5 Dependencies............................................................................................................... 6
4.6 Success Criteria............................................................................................................ 7
5. Business Requirements..................................................................................8
5.1 Context Diagram........................................................................................................... 8
5.2 Business Scenarios...................................................................................................... 8
5.3 High-Level Business Requirements..............................................................................8
5.4 Requirements Prioritisation........................................................................................... 9
6. Functional Requirements..............................................................................10
6.1 Detailed Requirements................................................................................................ 10
7. Non-Functional Requirements......................................................................11
8. Business Change Requirements..................................................................12
8.1 Business Impacts........................................................................................................ 12
8.2 Communications......................................................................................................... 12
8.3 Training....................................................................................................................... 12
8.4 Business Testing......................................................................................................... 12
8.5 Implementation........................................................................................................... 12
Appendices...............................................................................................................13

raidlogs.co.uk Business Requirements Template Page: 2 / 16

1. Document Control
1.1 Version Control

Version Date Status Change Author

1.2 Document Distribution

Name Role / Responsibility

1.3 Document Sign Off

Name Role / Responsibility Approval

1.4 References

Ref. Document Name Location

raidlogs.co.uk Business Requirements Template Page: 3 / 16

2. Executive Summary
< The purpose of an executive summary is to summarize the key points of what is in the document.
This section should provide the individual reading the text with an overview of the document contents
and the main points that have been made. This section should be the last section completed and
shouldn’t run over more than 2 pages at maximum>

raidlogs.co.uk Business Requirements Template Page: 4 / 16

3. Introduction
3.1 Document Purpose
< This document is designed to capture the business requirements for the project. They will form the
basis on which the analysis will be performed and will be expanded to define detailed requirements to
feed into the detailed solution design. These requirements will be signed-off by the agreed group of
approvers.
The requirements are recorded as Business Needs, which are unique requirements defined from
business request(s). Many business requests may be rationalised into a single Business Need.
The document is focused on the business requirements and will not be used to define the solution to
meet those requirements >

raidlogs.co.uk Business Requirements Template Page: 5 / 16

3.2 Stakeholders

< A list of people who have a vested interest in the project, either from using, managing or
commissioning the final deliverables. The stakeholders must be empowered and able to advise of
requirements without the need to check back with their managers. They may be from enabling business
units (e.g. IS, HR) too >





3.3 Associated Documentation

< A list of others documents relevant to the production of this document, for example ... >

Project Definition Document

 location

High Level Proposed To-Be Process

 location

RAID Log

 location

raidlogs.co.uk Business Requirements Template Page: 6 / 16

4. Project Summary

4.1 Project Background

4.2 Project Objectives

4.3 Project Scope

4.3.1 In Scope
The following points are considered in scope for this project:






4.3.2 Out of Scope

The following points are considered out of scope for this project:






raidlogs.co.uk Business Requirements Template Page: 7 / 16

4.4 Assumptions & Constraints

The RAID Log maintained by the project will be the standard point of reference for current status.
Available at: location

The following are currently of particular interest.





4.5 Dependencies
The RAID Log maintained by the project will be the standard point of reference for current status.
Available at: location

The following are currently of particular interest.





raidlogs.co.uk Business Requirements Template Page: 8 / 16

4.6 Success Criteria

Case for Action Supporting

Supporting Statements Success Criteria
Statement Measurements

raidlogs.co.uk Business Requirements Template Page: 9 / 16

5. Business Requirements
5.1 Context Diagram
<High level illustration of Business Processes/Systems which are within the scope of the project. May
make reference to event-driven use cases (referenced in Appendices), which will inform structuring of
functional requirements>

raidlogs.co.uk Business Requirements Template Page: 10 / 16

5.2 Business Scenarios

<Description of Business Processes/Systems which are within the scope of the project. May make
reference to event-driven use cases (referenced in Appendices), which will inform structuring of
functional requirements>

5.3 High-Level Business Requirements

<This section provides a specification of what the business wants. This is usually expressed in terms of
broad outcomes the business requires, expressed as ‘one-liners’, rather than specific functions the
system may perform.

Specific design elements are usually outside the scope of this document, although design standards
may be referenced.

Typically this table will be presented in landscape format. >

<Unique id #>
Requirement ID
<Enter concise description of requirement>
Statement
<Enter supporting detail to the requirement statement>
Description
<As appropriate, provide a brief rationale/business benefits for the
requirement. Note:Financial benefits will be documented in the business
Business Benefits
case>

<Name of Requirement Provider>

Source
<See below>
Priority

raidlogs.co.uk Business Requirements Template Page: 11 / 16

5.4 Requirements Prioritisation

<The table below defines the words used to signify the priority of the requirements.>

Term Description

This word or the terms "REQUIRED" or "SHALL", mean that the definition is
MUST
an absolute requirement of the specification.

This phrase, or the phrase “SHALL NOT”, means that the definition is an
MUST NOT
absolute prohibition of the specification.

This word, or the adjective "RECOMMENDED", means that there may exist
valid reasons in particular circumstances to ignore a particular item, but the
SHOULD
full implications must be understood and carefully weighed before choosing
a different course.

This phrase, or the phrase "NOT RECOMMENDED" mean that there may
exist valid reasons in particular circumstances when the particular behaviour
SHOULD NOT is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behaviour
described with this label.

This word, or the adjective "OPTIONAL", means that an item is truly

MAY optional. One Supplier may choose to include the item because a particular
marketplace requires it, while another Supplier may omit the same item.

raidlogs.co.uk Business Requirements Template Page: 12 / 16

6. Functional Requirements
<In the early stages of a project, documentation of requirements may stop at the High-Level Business
Requirements as set out in Section 5>

6.1 Detailed Requirements

<While functional requirements may be included within the Business Requirements documentation, it is
permissible, according to the scale and complexity of the project to document Functional Requirements
in a standalone document with clear line of sight to signed-off business requirements.

The functional requirements should derive from the Business Requirements. It may be appropriate to
sub-classify functional requirements e.g.:
 Business Policy or Business Rules-related (if new business policies or rules are
envisaged)
 Processing requirements
 Organisational requirements (if any changes to business organisation are expected)
 Support requirements
 MI / Reporting requirements
Typically the table will be presented in landscape format.

It may be appropriate to present supporting detail in an Appendix. >

<Unique id #>
Requirement ID
<Enter Short Name>
Name
<Supporting detail to the requirement>
Description
<As appropriate, provide a brief rationale/business value for the
Rationale requirement.>

<Name of Requirement Provider>

Source
<Provide a target that makes it possible to test if requirement was satisfied>
Acceptance
Criteria
<See Section 5.4>
Priority

<The functional requirements should cross-reference the following, if relevant:

 Any Non-Functional Requirements specific to this requirement
 Dependencies / assumptions specific to this requirements
 Existing Business Policies & Rules specific to the requirement>

raidlogs.co.uk Business Requirements Template Page: 13 / 16

7. Non-Functional Requirements
<In addition to the functional requirements, the non-functional requirements require specification.
Typical categories, which are not exhaustive, are:

 Performance Requirements / SLAs

 Volumes
 Capacity (at peak)
 Call times
 Availability
 Usability
 Business Continuity / Disaster Recovery
 Backup / Archiving
 Security
 Support & Maintenance
 Documentation
 Legislative
 Audit>

<Unique id #>
Requirement ID
<Enter category for non-functional requirement>
Category
<Supporting detail to the requirement statement>
Description
<As appropriate, provide a brief rationale/business value for the
Rationale requirement.>

<Name of Requirement Provider>

Source
<Provide a target that makes it possible to test if requirement was satisfied>
Acceptance
Criteria
<See Section 5.4>
Priority

raidlogs.co.uk Business Requirements Template Page: 14 / 16

8. Business Change Requirements
<Optional: It may be appropriate to set-down an initial view of the business change requirements in
bullet point form. These may become the subject of specific project workstreams e.g.
Communications, Training, Business Testing, Implementation.>

8.1 Business Impacts

< What business areas are impacted?
What staff roles are impacted?>

8.2 Communications
<What are the communication requirements across the organisation?
What types of communication may be required?>

8.3 Training
<What is known about training requirements?>

8.4 Business Testing

<What will be the approach to business testing?
Are there acceptance criteria not listed under specific requirements?>

8.5 Implementation
<Are there specific migration requirements?
Are there specific implementation constraints?
What is known about sign-off criteria for implementation?>

raidlogs.co.uk Business Requirements Template Page: 15 / 16

Appendices
<The need for supporting Appendices will be driven by the nature of the opportunity/problem under
investigation. The following should be considered.>

< Key terms, acronyms>

Glossary
 Business Process Scenarios
 ‘as is’ processes
Business Models
 ‘to be’ processes

<Reference Documentation>
Business Policies /
Business Rules
< e.g. to include examples of
Examples / Use  Use Cases
Cases  Screen or Report formats>

<Supporting detail to the requirement statement:

 Cross – reference to functional requirement
Requirements  Unique i/d for the detailed requirement
Detail (to support a  Description, including full supporting detail. May include specification of
Functional Requirement
in the Requirement
inputs/outputs/error handling
Catakogue)  Priority
 Whether functionality is New, Exists or Manual>

 Business Stakeholders
Organisational  Job role requirements
Model  Training requirements

 Business Locations
Location Model
<E.g. to include
 Logical Data Model
Information Model  Data Requirements
 Reporting Requirements>

raidlogs.co.uk Business Requirements Template Page: 16 / 16