Business Requirements Template
Business Requirements Template
Business Requirements Template
DOCUMENT
FOR
<PROJECT NAME>
Project Number:
Project Manager:
Version #:
APPROVALS
1. PURPOSE ................................................................................................................... 5
1.1 APPROACH ................................................................................................................................. 5
2. BUSINESS NEED...................................................................................................... 6
2.1 CURRENT STATE CONTEXT .................................................................................................. 6
3. REQUIREMENTS GATHERING SCOPE ............................................................. 8
3.1 IN SCOPE .................................................................................................................................... 8
3.2 OUT OF SCOPE .......................................................................................................................... 8
4. INTERDEPENDENCIES ......................................................................................... 9
4.1 DEPENDENCIES ....................................................................................................................... 9
4.2 ASSUMPTIONS .......................................................................................................................... 9
4.3 CONSTRAINTS .......................................................................................................................... 9
4.4 REQUIREMENTS RISKS.......................................................................................................... 9
5. BUSINESS PROCESS REQUIREMENTS .......................................................... 10
5.1 AS IS PROCESS MAPS ............................................................................................................ 11
5.2 TO BE PROCESS MAPS .......................................................................................................... 11
5.3 IMPACT OF PROPOSED CHANGES ON BUSINESS SERVICES AND PROCESSES ... 12
6. REQUIREMENTS ................................................................................................... 14
6.1 BUSINESS REQUIREMENTS................................................................................................ 14
6.2 BUSINESS RULES ................................................................................................................... 17
6.3 DATA DEFINITIONS .............................................................................................................. 18
6.4 REPORTING REQUIREMENTS............................................................................................ 18
APPENDIX B – GLOSSARY ........................................................................................ 19
APPENDIX C - SUPPORTING DOCUMENTS ......................................................... 20
Contact Information:
For further information, or to request changes, contact:
<Summarize the purpose of this document and describe the relevant audience>
1.1 APPROACH
<Summarize the methods used to gather the business requirements, including who, what how
and why, etc., to complete the requirements. >
<Ensure that during requirements gathering activities all identified stakeholders were contacted
for impact assessment and requirements validation.>
<e.g. Interview sessions were held from user groups to capture the business requirements and to
validate the business drivers of the solutions. These requirements are to be individually
prioritized and slotted into targeted phases. The product of this exercise was the “Business
Requirements Document” packaged as part of the deliverables of the “Gas Consumption Data -
Discovery Phase” project.>
<Describe a problem that the organization is facing (or is likely to face), or an opportunity that it
has not taken, and the desired outcome. Explain the reason why this need has to be addressed
and what would the consequences be if it is not addressed.>
<Include current state context diagram and any clarification that is required.>
Ensure that all systems that have interaction with the project scope are included on the diagram.
Interface library tool can be used for the impact analysis. It lists all cross-system interfaces, their
details and contact information.
Application and interface inventory can be located on the Architecture Office team site: [Client
link]
3.1 IN SCOPE
<List features, functions, business processes, IT systems, and other technology that will likely be
affected by the project and was analysed as part of the detailed requirements gathering
activities.
Ensure that every system and user role identified within current state Context diagram above is
listed as either In or Out of scope and relevant stakeholders are identified and contacted as part
of stakeholder analysis.>
<List features, functions, business processes, IT systems and other technology components
excluded from detailed requirements gathering activities.>
4.1 DEPENDENCIES
<Identify any deliverables from other projects or associated requirements that are crucial to the
requirements documentation task.>
4.2 ASSUMPTIONS
<Identify key assumptions that may affect the completeness of the requirements.>
4.3 CONSTRAINTS
<Identify constraints that may affect the project’s requirements and requirements gathering and
documentation activities. E.g. Legal Constraints, Regulatory Requirements, Policy etc.>
<Identify key risks that may affect the completeness of the requirements documentation task.>
<This section should provide process maps for all business processes identified as ‘in scope’ in
section 3.1 above. Level of details required for business process map should be determine at the
stage of Business Analysis Approach planning (phase 1 of Business Process Centric Approach to
Requirements Gathering).>
5.1.1 X PROCESS
<Insert images of all as-is process maps and all their explanation pages. Use ICRP notation to create the maps:
5.2.1 X PROCESS
<Insert images of all to-be process maps and all their explanation pages. Use ICRP notation to create the maps:
<Summarize the impact of changes to the business in the table below: ensure every map change
from ‘as-Is’ to ‘to-be’ has a corresponding line in the table below.>
<The section can be complemented with the deliverables from the process centric approach, e.g.
list of pain points and opportunities traced to the future process step.>
Req Category Name* Description* Priority* Owner Matching Linking Req. # Business
ID* Process Rule #
Steps
<e.g. <Use this <Short name <Detailed <1- low; 2 <Name <List all <List all <List all
BRQ- column to for the definition of the – medium; contact process requirement IDs business
001> logically group requirement. requirement and 3 - high> person to steps the that are impacted rules that are
requirements. This will be any additional validate requirement by this requirement relevant to
For Example, visible in QC clarification changes to is applicable implementation. this
use lists.> needed.> the to within For example: list requirement>
‘Administration’, requirement ‘to-be’ any requirements
‘Presentation’, with> process that will need to be
‘Audit’ maps> removed from
categories> scope if this
requirement is
considered out of
scope>
R.326 Work Requests Ability to System should 3-high 4.1.21,
associate a provide the ability 4.2.1.1,
Work to indicate that 4.2.1.19
Request with work request was
an asset performed on a
particular asset
R.328 Administrative Ability to System should 3-high 4.2.1.11,
define follow provide means to 4.2.1.16
up process configure behavior
based on based on work
work request completion
completion code, e.g. next step
result of the workflow
can be either close
complete work or
submit for further
Req ID* Category Name* Description* Priority* Owner Matching Linking Req. # Business
Process Rule #
Steps
<continue <pick from <Short name <Detailed <1- low; 2 <Name <List all <List all <List all
numbering the list for the definition of the – medium; contact process requirement IDs business
from the above.> requirement. requirement and 3 - high> person to steps the that are impacted rules that are
previous This will be any additional validate requirement by this relevant to
table> visible in QC clarification changes to is applicable requirement this
lists.> needed.> the to within implementation. requirement>
requirement ‘to-be’ For example: list
with> process any requirements
maps> that will need to be
removed from
scope if this
requirement is
considered out of
scope>
R.400 Usability Use with System should 3- high
hand allow to be used
protection while wearing
hand protection
equipment
(gloves).
Term Definition
Authentication Describes the verification of the identity of a person or process.
Authorization Refers to the granting of specific types of service to a user, based on their
authentication.
Data Integrity Describes the measures to ensure that (1) information in storage is modified
only by authorized mechanisms and (2) information being transmitted
arrives at its destination without modification.
Non repudiation Describes the recipient of a message must have a high level of confidence in
the identity of the sender. Nor should the sender be able to deny sending the
message.
Data Was classified using the Information Classification section of the [Client]
confidentiality Guidelines for Developing Application System Security (the Information
Classification document.)