University of Edinburgh

_______________________________________________________________________________________________________

Stage: Business Analysis

Business Requirements Document

[PROJECT NAME]
[PROGRAMME NAME]
[PROJECT CODE]
[ANNUAL PLAN NUMBER]

Document Version: [x.x]

Date: [dd/mm/yy]

_______________________________________________________________________________________________________

Information Services - Template Revised June 2009

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

Contents
1
1.1
1.2
2
2.1
2.2
2.3
2.4
3
3.1
3.2
3.3
3.4
4
4.1
4.2
5
5.1
5.2
5.3

DOCUMENT MANAGEMENT....................................................................3
Contributors.....................................................................................................3
Version Control.................................................................................................3
OVERVIEW................................................................................................4
Project Description...........................................................................................4
Objectives..........................................................................................................4
Business Dependencies and Constraints........................................................4
Legislative Impact............................................................................................4
CURRENT PROCESSES...........................................................................5
Business Process Description...........................................................................5
Business Process Maps.....................................................................................5
Targeted Business Processes............................................................................5
Current System Context Diagram..................................................................6
BUSINESS REQUIREMENTS...................................................................7
Functional Requirements................................................................................7
Non-Functional Requirements........................................................................8
PROPOSED PROCESSES......................................................................10
Business Process Description.........................................................................10
Business Process Maps...................................................................................10
Proposed System Context Diagram..............................................................10

DATA REQUIREMENTS.........................................................................11

USER ACCEPTANCE TESTING.............................................................12

7.1
7.2

Acceptance Test Strategy...............................................................................12

Test Scenarios and Acceptance Criteria.......................................................12

TRAINING................................................................................................13

DOCUMENT SIGN OFF...........................................................................13

_______________________________________________________________________________________________________

Page 2 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

1 Document Management
When completing this document, please mark any section that is not required as
N/A. A brief description of why the section is not required should also be included.

1.1 Contributors
Please provide details of all contributors to this document.
Role
Business Analyst
(Owner)
Project Manager
Project Sponsor
Business Area Manager
Systems Analyst
Designer
Other document
contributors

Unit

Name

1.2 Version Control

Please document all changes made to this document since initial distribution.
Date

Version

Author

Section

Amendment

_______________________________________________________________________________________________________

Page 3 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

2 OVERVIEW
Please provide an overview of the project in the sections below

2.1 Project Description

Provide a summary of the project

2.2 Objectives
As identified at TOR stage

2.3 Business Dependencies and Constraints

Certain business dependencies exist that may affect the project team's ability to
implement the project, e.g. concurrent projects, unknown technology. These
dependencies are listed below so that they can be communicated and addressed.

[Add a dependency here.]

Please ensure that any potential risks are identified in the project Risk
Register.

2.4 Legislative Impact

Please highlight any legislative issues that could impact this project, including:

Data Protection
Freedom of Information
Records Management
SENDA Compliance
Disability

Please ensure that any potential risks are identified in the project Risk
Register.

_______________________________________________________________________________________________________

Page 4 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

3 CURRENT PROCESSES
This section provides details of the current processes a process is defined as a
serious of actions, operations, or functions that produces the required outputs.
Current processes should be mapped, even where process is manual.

3.1 Business Process Description

Please provide a description of the current business processes

3.2 Business Process Maps

Use Triaster, or an alternative business process mapping tool, to map the activities
and identify inputs and deliverables for the current business process.
The current business process flow diagram describes the current process accurately,
including any flaws, or short comings that exist in today's process that will be
targeted for repair or improvement by the future process
Individual business processes should be mapped separately. If required, provide an
index of process maps.
Add in links to:
Html version of process maps sample
PDF printable version of process maps sample

3.3 Targeted Business Processes

Annotate targeted areas (areas which require change) in the process maps, and
document these in full below.

_______________________________________________________________________________________________________

Page 5 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

3.4 Current System Context Diagram

The information in the current business system flows from and to other systems.
The following diagrams represent the high level context for the information flow
between the current system and external entities.
Sample diagram: http://hsc.csu.edu.au/ipt/project_work/3287/contextdiagram.gif

_______________________________________________________________________________________________________

Page 6 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

4 BUSINESS REQUIREMENTS
4.1 Functional Requirements
Review the current process maps and targeted processes with the customer to
identify the business requirements for the new development.
Specifying technical solutions should be avoided unless these are an agreed
constraint on the solution. Technical specifications will be detailed during the Design
Stage.
Record the agreed business requirements below:

Separate requirements into sections e.g. by functional area

Uniquely identify each requirement

Describe each requirement in sufficient detail to enable verification by the

business user, definition of acceptance criteria and cross-referencing
during the Design stage.

Specify the category for each requirement, using the following

abbreviations:
M = mandatory; HD = highly desirable; D = desirable
For example:

1 Capture HR data for current HESA return

ID

Requirement

1.1
1.2
1.3
1.4

Facility to capture current version of Finance hierarchy

Automatic facility to load Finance hierarchy into HR core system
Ability to validate HESA specific data in Core HR system
Ability to report against extract tables

Categor
y
M
HD
M
M

2 Archive data from final HR HESA submission

ID

Requirement

2.1
2.2

Archive of each years submission must be captured and stored

Ability to report against archive

Categor
y
M
HD

_______________________________________________________________________________________________________

Page 7 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

4.2 Non-Functional Requirements

Identify and record requirements for aspects of the solution other than those explicitly
concerning its functionality. Examples of non functional requirements will include
those relating to security, scalability, performance, backup and recovery, extensibility,
portability etc.
Record the agreed non-functional requirements below:
Separate requirements into sections
Uniquely identify each requirement
Describe each requirement in sufficient detail to enable verification by the
business user, definition of acceptance criteria and cross-referencing
during the Design stage.
Specify the category for each requirement, using the following
abbreviations:
M = mandatory; HD = highly desirable; D = desirable

For example:

Security
Ref

Security

Requirement

1.1
1.3

Authentication
Authorisation
Levels

EASE Authentication to be used

Admin read/write access to applications
administrative functionality and to all data
Owner read/write access to all data
functionality but no admin permission
User view-only access to application data;
no access to sensitive data (as defined
above)

Categor
y
M
M

Scalability
Ref

Scalability

2.1

Typical and
Maximum number
of concurrent users
Expected annual
user growth
Expected initial and
maximum data
volumes
Expected annual
data growth

2.2
2.3
2.4

Requirement

Categor
y
M
M

Performance
Ref

Performance

Requirement

3.1
3.2

e.g Page render times

e.g Report run times

5 sec
30 sec

Categor
y
M
HD

_______________________________________________________________________________________________________

Page 8 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

_______________________________________________________________________________________________________

Page 9 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

Availability/Business Continuity
Ref
4.1
4.2

Availability/Business
Continuity
The solution should be designed
to be highly available during
normal working ours
In the event of a failure the
system must be designed to be
recoverable in less than 1
working day with minimal data
loss

Requirement
99.9% availability excluding
planned maintenance during
8am 6pm
Recovery in less than 1 working
day from time of failure with no
loss of completed transactional
data

Categor
y
HD
HD

Back Up/Archive
Please highlight any archive and back up requirements. For example:
Ref

Backup/Archive

Requirement

5.1
5.2

Full database archive

Backup

Annual snapshot on 31st July

Nightly backup for Disaster
Recovery

Categor
y
M
HD

Data Migration
Please provide details of data migration requirements (if any), including timescales. For
example:
Ref

Data Migration

Requirement

6.1

Financial Transactions

6.2

Staff Data

To be posted in real time to

Finance System
To be refreshed at least daily
from HR System

Categor
y
HD
M

Conformance with Browsers, Operating Systems and Mobile Devices

Please provide details of the environment(s) in which the system is required to operate. For
UoE systems only windows, mac and linux operating systems are supported.
Ref

Browser

7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9

IE 7.x
IE 6.x
IE 5.5
Earlier IE Versions
Firefox all versions
Opera 8 onwards
Safari 2 onwards
Google Chrome 1.x
Other Browsers

PC

Mac

M
---M
HD
HD
---

M
---M
HD
HD
---

IPhon
e
HD
---HD
D
D
---

Mobile
/PDA
----------

Xbox /
PS3

The current preferred browsers for University IT systems is published at:

http://www.ucs.ed.ac.uk/ucsinfo/browsercompat.html

_______________________________________________________________________________________________________

Page 10 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

PROPOSED PROCESSES

This section provides details of the future processes a process is defined as a

series of actions, operations, or functions that produces the required outputs.

5.1 Business Process Description

Please provide a description of the proposed business processes

5.2 Business Process Maps

Taking into account the business requirements defined above, use Triaster, or an
alternative business process mapping tool, to map activities and identify inputs and
deliverables for the future business process.
Individual business processes should be mapped separately. If required, provide an
index of process maps.
Add in links to:
Html version of process maps
PDF printable version of process maps

5.3 Proposed System Context Diagram

The information in the current business system will flow from and to other systems.
The following diagrams represent the high level context for the information flow
between the proposed system and external entities.
Sample diagram: http://hsc.csu.edu.au/ipt/project_work/3287/contextdiagram.gif

_______________________________________________________________________________________________________

Page 11 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

DATA REQUIREMENTS

Please include details of the data to be captured by the new software. This should
be listed in the table below. If this is a substantial amount of information, please
provide a high level summary in this section, and attach the details as an appendix.
For example:
Data Group
Customer

Contract of
Employment

Data required
Name
Date of birth
Gender
Nationality
Campus identifier
Contract identifier
Terms of employment

Source
Application form
Application form
Application form
Application form
HR system
HR System
Core HR

_______________________________________________________________________________________________________

Page 12 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

7 USER ACCEPTANCE TESTING

Please highlight the UAT strategy identified for this project

7.1 Acceptance Test Strategy

Provide an overview of the acceptance test strategy. Please ensure the following are
included in your considerations:

Scheduling and duration

Test setup requirements (e.g. test environment, co-dependencies, business
cycles)
Sources of test data
Test scripts
Required test participants and any training requirements
Technical and business support required during testing
Communication requirements

Link to updated User Acceptance Test Plan

7.2 Test Scenarios and Acceptance Criteria

Referring back to section 4, identify test scenarios and acceptance criteria for each
functional and non functional requirement. Please note that this section will be used
as sign off criteria for the User Acceptance Test Plan.
Examples:

1 Capture HR data for current HESA return

Re
f
1.1
1.2
1.3
1.4

Requirement

Test Scenario and Acceptance Criteria

Facility to capture current

version of Finances hierarchy
Automatic facility to load
finance hierarchy into HR core
system
Ability to validate HESA
specific data in Core HR
system
Ability to report against extract
tables

Check current finance hierarchy appears in Core HR

system
Current finance hierarchy appears without manual
intervention in Core HR system
Run validation report
Generate report from tables

2 Archive data from final HR HESA submission

Ref
2.1
2.2

Requirement
Archive of each years
submission must be captured
and stored
Ability to report against
archived data

Test Scenario and Acceptance Criteria

Evidence, e.g. demonstration, that required data is
correctly archived
Generate report from archive

_______________________________________________________________________________________________________

Page 13 of 14

Business Analysis: Business Requirements Document

[Version: x.x]

[Project Name]

_____________________________________________________________________________________________

8 TRAINING
Please provide details on training requirements, including

Which groups will require training

Who will provide training
Required Format of training materials

9 Document Sign Off

Please add other sign off roles where required:
Project Manager
Project Sponsor
Business Analyst
Systems Analyst Designer

Name
Name
Name
Name

_______________________________________________________________________________________________________

Page 14 of 14