BUSINESS/IT

REQUIREMENTS
DOCUMENT

<Project Name:>
<Project Reference:>

Project Sponsor: <The name of the sponsor advocating the change>

Business Project Manager: <The name of the business project manager who is responsible for
the requirements>
IT Project Manager: < The name of the IT project manager who is responsible for the IT
requirements>
Business Analyst: <The name of the Business Analyst who is responsible for gathering
and documenting the requirements>

Document Author: <The name of the author of this document>

Version Number: <Document version number>

www.ba-guru.com
Giving you the leading edge
Last Updated: <The date the document was last updated>
Status: <The status of the document – Draft/Released>

www.ba-guru.com
Giving you the leading edge
<Project

DOCUMENT CONTROL
<Blue italic text is included to provide guidance to the author and should be deleted before
publishing>
Contacts
<Contacts that would be useful to provide for business information>
Name: <Contact name>
Title: <Contact title>
Location: <Where the contact can be located>
Contact Number: <Contact internal/external number>
Email: < The email correspondence for the contact>

Document Approval
<Enter details of all stakeholders who will be subject to approval of this document>
Approver Title Business Area Approval Date

Document Distribution
<Enter details of all stakeholders who will be subject to receipt of this document for
reference purposes>
Name Title Business Area

Revision History
<Initially a document will be numbered 0.1 to 0.9 until it becomes the first issue for approval
at which point the document is numbered 1.0. For future updates the document will be
numbered using decimals to 1 place until it adopts the next whole number for issue>
Date Author Version Summary Of Changes Status

Related Documents
<List any significant documents that precede and relate to the project>
Document Name Version Author Date

Status: <Draft/Released For Page 2 of

www.ba-guru.com
Giving you the leading edge
<Project

<Not all of the following sections may be applicable to the work being
performed. If so, the preference would be to keep the section heading, but
make a note such as “This section is not applicable for this process” and
provide an explanation for the reasons why>

Status: <Draft/Released For Page 3 of

www.ba-guru.com
Giving you the leading edge
 <Project

Table of Contents
1 Introduction....................................................................................................................................5
2 Problem/Impact/Successful Outcome............................................................................................5
3 Objectives.......................................................................................................................................5
4 Purpose Of Document....................................................................................................................5
5 Scope..............................................................................................................................................5
6 Definitions, Acronyms and Abbreviations......................................................................................6
7 Risks................................................................................................................................................6
8 Assumptions...................................................................................................................................6
9 Issues..............................................................................................................................................6
10 Dependencies.............................................................................................................................6
11 As Is Process................................................................................................................................7
12 Context Diagram.........................................................................................................................7
13 Process Overview Diagram.........................................................................................................7
14 High Level To Be Business Requirements....................................................................................7
15 Detailed Business/IT Requirements............................................................................................8
15.1 Functional Requirements........................................................................................................8
15.2 Process Diagram......................................................................................................................9
15.3 Non Functional Requirements.................................................................................................9
16 Costs.........................................................................................................................................13
17 Appendices...............................................................................................................................13

Status: <Draft/Released For Page 4 of

<Project

1 Introduction

<This should be a high level introduction and background to the Project>

2 Problem/Impact/Successful Outcome

The Problem The Impact The Successful Outcome

<Detail the impact of the <Detail, at high level, what
problem upon the business successful outcome would
<Detail the problem/issue community, application or provide a resolution to the
which requires a resolution> process> problem>

3 Objectives
<State the objectives to be met by the business solution. The ID number will take the form of Oxx
where xx = a consecutive number per entry>

ID Business Objective Business Owner Business Importance

Oxx

4 Purpose Of Document
The Business Requirements Specification details the business requirements as elicited by the
business analyst from the key stakeholders. The document presents the requirements in a
structured way that facilitates review and sign off by the designated approvers.

Building on the high level scope of the project as defined in the Project Definition Document, the
business requirements clearly state in business language what any chosen solution must do.
This document captures the business requirements in a structured way, providing the basis for
ensuring that the solution delivered meets the requirements.

It should:-
 Facilitate a shared understanding for all stakeholders of the business requirements
 Be the key input for the preparation of a functional requirements specification
 Facilitate the identification of possible solutions

5 Scope

In Scope Out Of Scope

<A brief description or bullet points of what is in <A brief description or bullet points of what is
scope> out of scope>

Status: <Draft/Released For Page 5 of

<Project

6 Definitions, Acronyms and Abbreviations

<This subsection provides the definitions of all terms, acronyms, and abbreviations required to
properly interpret the BRS>

Abbreviation/Acronym Description

7 Risks
<Insert details of any risks you forsee in being able to complete the requirements. The ID number will
take the form of Rxx where xx = a consecutive number per entry >

Ref Risk Detailed BRS Reference

Rxx

8 Assumptions
<Insert details of any assumptions made during elicitation of the requirements. The ID number will
take the form of Axx where xx = a consecutive number per entry>

Ref Assumption Detailed BRS Reference

Axx

9 Issues
<Insert details of any issues which contribute to the requirements being incomplete. The ID number
will take the form of Ixx where xx = a consecutive number per entry>

Ref Issue Detailed BRS Reference

Ixx

10 Dependencies
<Insert details of any dependencies for the requirements to be completed. The ID number will take
the form of Dxx where xx = a consecutive number per entry>

Ref Dependency Detailed BRS Reference

Dxx

Status: <Draft/Released For Page 6 of

<Project

11 As Is Process
< Detail, at high level, the current As Is process. Include a process flow diagram if required.
The As Is process may already have been documented separately. Make reference to this within the
Related Documents section >

12 Context Diagram
<This is a diagram that details how and where the new process to be defined sits within the overall
E2E business process and illustrates the relationship among actors, processes and information.
Define clearly in which part of the process the changes will take place. If the requirements are a
component of a larger system, detail this within the diagram. This may take the form of a mind map,
process flow or any other notation which suits the business/author >

13 Process Overview Diagram

<Add a high level process flow diagram of the E2E business process to which this requirements
document relates>

14 High Level To Be Business Requirements

< Detail, at high level, the To Be business requirements>

Status: <Draft/Released For Page 7 of

<Project

15 Detailed Business/IT Requirements

15.1 Functional Requirements

<List the functional requirements which will deliver the business/IT requirements>

MoSCoW
ID Title Requirements Description Type (*) Priority Originator Status (**) Delivered By Test ID
FRxxx

* Type Key:-

 Business
 Application
 Information
 Integration
 Technical

** Status Key:-

 Proposed
 Accepted

MoSCoW Rating:-

 Must Have: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success
 Should Have: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one
which can be satisfied in other ways if strictly necessary.
 Could Have: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
 Would Have: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered

Status: <Draft/Released For Page 8 of

<Project

15.2 Process Diagram

<Include a process flow diagram which links to the functional requirements above if necessary>

15.3 Non Functional Requirements

<List the non-functional requirements which will deliver the business/IT requirements>

MoSCoW Test
ID Title Requirements Description Type (*) Priority Originator Status (**) Delivered By ID
NFRxxx

* Type Key:-

 Technical
 Integration
 Security
 Audit
 Performance
 Capacity
 Availability
 Reliability
 Recovery
 Compatibility
 Maintainability
 Usability

** Status Key:-

 Proposed
 Accepted

Status: <Draft/Released For Page 9 of

<Project

<Non Functional requirements checklist:-

TYPE SAMPLE DETAIL

SECURITY
Login Requirements Access levels, CRUD levels (Create/Retrieve/Update/Delete)
Password Requirements Length, special characters, expiry, recycling policies
Inactivity Timeouts Durations, actions
AUDIT
Audited Elements What business elements will be audited
Audited Fields Which data fields will be audited
Audit File Characteristics Before image, after image, user & time stamp
PEFORMANCE
Response Times Application loading, screen open & refresh times
Processing Times Functions, calculations, imports, exports
Query & Reporting Times Initial loads & subsequent loads
CAPACITY
Throughput How many transactions per hour does the system need to be able to
handle?
Storage How much data does the system need to be able to store?
Year on year growth
requirements
AVAILABILITY
Hours of Operation When is it available? Consider weekends, holidays, maintenance
times etc
Locations of Operation Where should it be available from; what are the connection
requirements?
RELIABILITY
Meantime Between Failures What is the acceptable threshold for down-time eg. one a year, 4,000
hours etc
Meantime To Recovery If broken, how much time is available to get the system back up
again?
INTEGRITY
Fault Trapping How to handle electronic interface failures
Bad Data Trapping Data imports; flag-and-continue or stop the import policies etc
Data Integrity Referential integrity in DB tables and interfaces
Image Compression &
Decompression Standards
RECOVERY
Recovery process How do recoveries work; what is the process?
Recovery Timescales How long should a recovery take to perform?
Backup Frequencies How often is the transaction data, set-up data and system (code)
backed up?
Backup Generations What are the requirements for restoring to previous instance(s)?
COMPATIBILITY
Compatibility With Shared What other systems does it need to talk to?
Application
Compatibility With 3rd Party What other systems does it have to live with amicably?
Applications
Compatibility On Different What does it have to be able to run on?
Operating Systems

Status: <Draft/Released For Page 10 of

<Project

Compatibility On Different What are the hardware platforms it needs to work on?
Platforms?
MAINTAINABILITY
Conformance to Architecture What are the standards it needs to conform to or have exclusions
Standards from?
Conformance to Design What design standards must be adhered to or exclusions created?
Standards
Conformance to Coding What design standards must be adhered to or exclusions created?
Standards
USABILITY
Look And Feel Standards Screen element density, layout and flow, colours, UI, metaphors,
keyboards and shortcuts
Internationalization/ Languages, spellings, keyboards, paper sizes etc
Localization Requirements

Status: <Draft/Released For Page 11 of

<Project

16 Business Impact Assessment

Lens Key Impacts

Process  Impacts on business process and to what extent
 Introduction of any automation to business processes
and if so has the business/cost model been reviewed
to reflect this
 Have any new/amended policies been introduced
People  New/revised organisation design impacts including
resource impacts and if applicable recruitment
needs
 Training and development requirements
 Additional cultural change requirements
 Communication requirements
Customer  Customer communication requirements before, during
and after
 Impacts on customer experience if everything
goes according to plan
 Impacts on customer experience if things do not
go according to plan and mitigation requirements
Financial  Operational cost impacts, e.g. licenses and
ongoing support/maintenance
 Benefits management processes in place
Data & MI  Data cleanse requirements/approach
 Data governance/policy requirements
 Data migration requirements
 Data access requirements
 MI/reporting requirements
Product &  Change to existing products as a result of this change
Proposition  New product development
 Product governance requirements, e.g. product
implementation group
 Customer needs understood/documented
Supplier  Existing contract impacts, e.g. re-negotiation,
rights to use
 New contract impacts
 Supplier communication requirements
 Supplier interface/governance/data impacts
Management  Business readiness management requirements
 Business readiness plan requirements
 Stakeholder engagement/communication requirements
Governance & Risk  Operational risk impacts and where
appropriate mitigation requirements
 Risk and control framework impacts, e.g. changes
to control owners
 Regulatory compliance impacts and
documentation/evidence of obligations
met
 New/revised governance

Status: <Draft/Released For Page 12 of

<Project

17 Costs
<Include any costs associated with this change if applicable.
Note: This section has been specifically added at the request of the Food Business Analysts>

18 Appendices
<Additional document/s to add as a reference to the requirements>

Status: <Draft/Released For Page 13 of