Sample Business Requirements Document
Content
Business Requirements Document
Template
for
Your Company Name
Version #.#
Month Day, Year
< Project name goes here >
BUSINESS REQUIREMENTS DOCUMENT
Project Name:
Project Identifier:
Executive Sponsor:
(LOB) Project Manager:
IT Project Manager:
IT Relationship Manager:
Business Requirements QC
Manager:
Date Submitted:
Date Approved by Executive Sponsor:
Date Approved by Governance Committee:
Change History
Version
No.
Date
Revised By
Requested By
Page 2 of 17
Change Description
< Project name goes here >
CONTENTS
1
2
3
4
INTRODUCTION.......................................................................................................5
1.1
Background............................................................................................................................. 5
1.1.1 Current Situation / Business Need...............................................................................5
1.1.2 Project Objectives........................................................................................................ 5
1.2
Scope....................................................................................................................................... 5
1.2.1 Out Of Scope................................................................................................................ 5
1.3
Desired Outcomes.................................................................................................................. 5
1.4
Stakeholders and End Users................................................................................................. 5
1.5
Dependencies......................................................................................................................... 6
1.6
Risks / Issues.......................................................................................................................... 6
1.7
Assumptions........................................................................................................................... 6
CURRENT STATE.....................................................................................................7
2.1
Description.............................................................................................................................. 7
2.1.1 Business Processes..................................................................................................... 7
2.1.2 Systems....................................................................................................................... 7
2.1.3 People / Organization................................................................................................... 7
2.1.4 Other............................................................................................................................ 8
2.2
Challenges and Opportunities............................................................................................... 8
2.2.1 Challenges................................................................................................................... 8
2.2.2 Opportunities................................................................................................................ 8
2.3
Information Transfers............................................................................................................. 8
PROPOSED STATE..................................................................................................9
3.1
Proposed Vision..................................................................................................................... 9
3.2
Benefits................................................................................................................................... 9
3.3
Proposed Business Processes............................................................................................. 9
3.4
Business Requirement Descriptions....................................................................................9
3.5
Systems................................................................................................................................. 10
3.6
Information Transfers........................................................................................................... 10
3.7
Minimum / Recommended Performance Considerations.................................................10
3.8
People / Organization........................................................................................................... 10
3.9
Optional Features................................................................................................................. 10
3.10
Impacts on Other Business Areas....................................................................................10
3.11
Future Considerations....................................................................................................... 10
BUSINESS REQUIREMENTS................................................................................12
Page 3 of 17
< Project name goes here >
5
6
4.1
Requirement Format............................................................................................................ 12
4.2
Example Requirement.......................................................................................................... 13
IMPLEMENTATION CONSIDERATIONS...............................................................15
5.1
Critical Dates......................................................................................................................... 15
5.2
Constraints and Dependencies...........................................................................................15
5.3
Disaster Recovery Considerations.....................................................................................15
5.4
Security Requirements......................................................................................................... 15
5.5
Statutory and Regulatory Requirements............................................................................15
5.6
Training.................................................................................................................................. 16
ADDITIONAL INFORMATION................................................................................17
6.1
Reference Material................................................................................................................ 17
6.2
Glossary of Terms................................................................................................................ 17
Page 4 of 17
< Project name goes here >
1 INTRODUCTION
1.1
Background
In a few paragraphs, introduce the project and why we are doing it.
1.1.1
Current Situation / Business Need
Provide a background and description of project, including factual information on the current situation and
business need. What is the impact of this problem on the business? Is there anything depending on this
project?
1.1.2
Project Objectives
What does the project hope to achieve?
1.2
Scope
Describe the boundaries of the business process. Detail what is included (deliverables, product areas,
etc.) within the scope of this BRD – bullet points are OK.
1.2.1
Out Of Scope
To add clarity, indicate what is out of scope.
1.3
Desired Outcomes
Summarize the desired end result(s) of the project.
1.4
Stakeholders and End Users
Identify the primary / key stakeholders and users impacted by the project. These can include the actual
users of the system, managers of any impacted systems that need to be modified, and the senior
executive / sponsor of the project, among others.
The following Stakeholders and End Users have been identified:
Stakeholder
List the stakeholder (manager
level and above)
1.5
Job Function / Impact
Add the job function or the area of impact
Dependencies
List dependencies that have been identified and are being actively managed. These could be
dependencies on other projects, resources, people or business areas/functions.
Page 5 of 17
< Project name goes here >
The following dependencies have been identified and are being actively managed:
Dependency
List the
dependency name
1.6
Description
Dependency Type
Add a brief description of the
dependency
Are we dependent on
the project? Are they
dependent on us? Or
both?
Coordination Approach
What measures are in
place to manage the
dependency?
Risks / Issues
List any risks / issues that have been identified and are being actively managed. Include high-level risks
and issues rather than smaller day-to-day ones.
The following project risks have been identified and will need to be managed to ensure the project is
successfully launched on schedule:
Risk / Issue
List the risk / issue name
1.7
Likelihood / Impact
What is the likelihood it will
occur? If it does occur,
how significant is the
impact?
Mitigation Approach
What mitigation approach will be used
to manage the risk?
Assumptions
Clearly detail all assumption in relation to this BRD. For example:
This BRD assumes that ABC will continue to be the external provider of service XYZ.
The following Assumptions have been identified at this time:
Assumption #1
Assumption #2
Assumption #3
Assumption #n
Page 6 of 17
< Project name goes here >
2 CURRENT STATE
The Current State section of the BRD provides factual information describing how the business currently
operates, and any problems or enhancements that will be addressed by the project.
NOTE: If you do not include this section in the BRD you are required to provide the information in a
separate document that is signed off by the business.
2.1
2.1.1
Description
Business Processes
Provide diagrams of the current business processes. Include details such as activities being undertaken,
who undertakes the activities and systems and tools used. Swimlane process maps (see below) may be
useful. Written explanation may also be required.
Person, Team or
Business Area
Person, Team or
Business Area
These are called
Person, Team or swimlanes. They are used
to show who performs each
Business Area
activity/task
2.1.2
Other
process
name
Activity
Name
Activity
Name
This shows what activities comprise the process and who
performs each activity/task.
You can also add information regarding tools/systems used etc
Systems
Outline the systems involved in the current business processes. Include system names and the specifics
of their involvement with this project. Systems can also be indicated on the process maps. Context
Diagrams may be used as well.
2.1.3
People / Organization
Detail the people involved in the current business process and organizational structure if relevant –
include details such as team names and roles, if known, and their involvement within the current
processes. This may be covered by the process map(s) in Section 2.1.1 above. For example:
Operators within the Admin Processing Team are required to manually manipulate reports on a
daily basis, which takes between 1 and 2 hours.
2.1.4
Other
Provide other detailed information relating to the Current State not covered in the preceding sections. For
example:
Page 7 of 17
< Project name goes here >
The physical location of the system may need to be changed as the lease on the current floor
expires at the end of 2006 and may not be renewed.
2.2
Challenges and Opportunities
Your project may be responding to one or more business challenges or opportunities. Enter information
into the appropriate section(s). Delete any sections that do not relate to your project.
2.2.1
Challenges
Clearly detail the business challenges with the Current State and their impacts on the business. The
requirements detailed in later sections of the BRD will refer back to the challenges you are trying to
resolve. Challenges can be related to things that are broken, a need for improvement, a compliance
need, etc.
Copy this table for each challenge.
Challenge #n
< Name of challenge >
Description
< Description of the challenge >
Business Impacts
< Describe the impact the challenge has on the business (for example:
rework, reduced adviser satisfaction, loss of sales, compliance breach, etc.) >
Size of Problem
< Include details such as volumes, $$ and FTEs to demonstrate the size of the
problem >
Cause
< Describe the root cause of this problem >
2.2.2
Opportunities
Clearly detail the business opportunities this project will address. The requirements detailed in later
sections of the BRD will refer back to these opportunities.
Copy this table for each opportunity.
Opportunity #n
< Name of opportunity >
Description
< Description of the opportunity >
Business Benefits
< Describe the benefits the opportunity may have for the business (for
example: sales growth, adviser satisfaction, etc.) >
Size of Opportunity
< Include details such as sales volumes (eg FUA or AP), FTE savings etc to
demonstrate the size of the opportunity >
2.3
Information Transfers
Describe the information needed to support the current business processes. List information exchanged
with other business areas and systems, both inside and outside the enterprise.
Page 8 of 17
< Project name goes here >
3 PROPOSED STATE
This section of the BRD provides a description of the proposed business state. In addition to describing
the proposed state, you should indicate which aspects represent a change from the current situation.
NOTE: If you do not include this section in the BRD you are required to provide the information in a
separate document that is signed off by the business.
3.1
Proposed Vision
Provide a high-level overview or vision of the Proposed State and the expected outcomes.
3.2
Benefits
List the intended benefits of the Proposed State, and which specific Challenges and Opportunities from
Sections 2.2.1 and 2.2.2 that they resolve.
3.3
Proposed Business Processes
Provide diagrams of the proposed business processes. Include details such as activities that will be
undertaken, who undertakes the activities and systems and the tools used. Swimlane process maps (see
below) may be useful. Written explanation may also be required.
Person, Team or
Business Area
Person, Team or
Business Area
These are called
Person, Team or swimlanes. They are used
to show who performs each
Business Area
activity/task
3.4
Other
process
name
Activity
Name
Activity
Name
This shows what activities comprise the process and who
performs each activity/task.
You can also add information regarding tools/systems used etc
Business Requirement Descriptions
List the high-level process groups or requirement functions that need to be addressed to deliver the
Proposed State. Provide narrative descriptions of the Proposed Business Processes if available. For
example, “Obtain Customer Information” could be one process grouping that further analysis will detail in
greater depth in Section 4 of this BRD.
NOTE: The process groupings or requirement functions identified in this section will specifically drive the
requirements decomposition, with those results being captured in Section 4.
Page 9 of 17
< Project name goes here >
3.5
Systems
Outline the systems involved in the future business processes. Include system names and their
particulars involvement with this initiative. Systems employed can also be indicated on the process maps
in Section 3.2 above.
NOTE: In this section you are discussing the system requirements from a business perspective, rather
than detailing the IS solution.
3.6
Information Transfers
Describe the information needed to support future business processes. Include the need for historical
information, data conversions or reformatting, and impacts / dependencies with other business areas and
systems (both inside and outside the enterprise).
3.7
Minimum / Recommended Performance Considerations
Outline the expected performance criteria (minimum and recommended) for the proposed business
processes and solution.
3.8
People / Organization
Identify any people or organizations impacted by the Proposed State. Include details such as team
names, roles, and their involvement within the future processes.
NOTE: This may be covered by the Proposed Business Processes map in Section 3.2 above.
3.9
Optional Features
Detail any features that may enhance the value of the overall effort, but that are not required as a part of
this project.
3.10 Impacts on Other Business Areas
Describe any impacts to other business areas as a result of the Proposed State, if not already described
in previous sections.
3.11 Future Considerations
Detail any issues or requirements that are not being addressed by the proposed future state due to
project constraints (such as time, budget, dependencies, etc.), but that the business may wish to consider
at a later date. Make sure you indicate that these are OUT OF SCOPE in the current project. For
example:
Once Phase 1 of the XYZ project has been launched successfully, implementation of a report
module may provide added value to the business. This report module is OUT OF SCOPE for
Phase 1.
Page 10 of 17
< Project name goes here >
Scoping Approvals
Name
Signature
Business Line Sponsor:
IT SIO Sponsor:
Business Requirements
QC Manager:
Page 11 of 17
Date
< Project name goes here >
4 BUSINESS REQUIREMENTS
Use the following outline to provide details of the business requirements for the Proposed State. This
section of the BRD should provide the detail on the features of the Proposed State and list the planned
outcomes.
Section 2 (Current State) and Section 3 (Proposed State) of this BRD should be completed in sufficient
detail to provide the feature groupings that will drive the outline of this business requirements section.
Section 3.2 should specifically list these high level requirement or feature categories. In the example
below, “2.0 Obtain Customer Information” represents one individual Requirement or feature grouping /
family.
Where appropriate include tables, diagrams and screen prints to outline business requirements
necessary to deliver proposed state.
Use the following format to detail each requirement – repeat the format for each requirement grouping.
4.1
Requirement Format
Requirement Number
Requirement Title
Process or Context Diagram
Summary Process Narrative
Triggering Event(s) and Pre-Conditions
Outcome(s) and Post-Conditions
Alternatives Considered
Design Considerations / Notes
Issues / Assumptions / Risks
Requirements List
Page 12 of 17
< Project name goes here >
4.2
Example Requirement
The following sections provide an example of how to structure business requirements in the BRD.
2.0
Obtain Customer Information
Process Diagram
CUSTOMER
other
driver detail
customer & other
driver detail
vehicle garaging
address
CAMPAIGN
mailing /
alternate
solicitation /
response
channel
CALL
Obtain
Customer
Information
CUSTOMER
known
info
new / update
garaging
address
VEHICLE
vehicle detail
reason
forcall
csutomer & other
driver detail
QUOTE
Summary Process Narrative
When the agent has picked up the call, the system will display any information about the
customer that has been found as a result of a system search and/or entered by the customer
through the IVR. The agent will verify the information. The reason for the call, the solicitation
channel and the response channel will be recorded.
Customer information will be verified (or entered if it is a new customer with no Customer ID or if
the customer does not know their Customer ID). The agent will record information about all
drivers who are to be insured, including the relationship between the drivers.
Triggering Event(s) and Pre-Conditions
Agent available and picks up phone
Outcome(s) and/or Post-Conditions
Recorded customer information
Keycode determined
Alternatives Considered
Through IVR/Not through IVR
Customer ID available/Not available
Resident of more than one state
Design Considerations/Notes
Want ability for reps to re-request CBUS with additional information without doing a manual
workaround
Page 13 of 17
< Project name goes here >
Score and reason codes cannot be altered (security)
Want ability to capture ANI and link to policy/quote without adding as alternate number
Ability to capture all phone numbers, but only display the number most commonly used
Issues / Assumptions / Risks
When do we order the CBUS?
Is extension still used?
Determine / design rules to determine head of household – automation exists in OCR project
for MQS.
Customer database needs to be enhanced to allow capture of customer telephone numbers.
Assume that zip will populate city and state.
How do we want to deal with referrals?
When do we advise the agent that the quote will DNQ?
Requirements List
2.0
Obtain Customer Information
2.1
The system shall be capable of determining a customer exists using on the telephone
number that the customer dialed from.
2.2
The system shall be capable of determining if a customer exists based on the
customer’s last name and zip code.
2.3
The system shall be capable of allowing the agent to record the reason for a call.
2.4
The system shall be capable of recording the response channel as “phone” when a
customer calls in to speak to an agent.
2.5
The system shall be capable of allowing the agent to record the solicitation channel.
2.6
The system shall be capable of allowing the agent to record new customer detail.
2.7
The system shall be capable of allowing the agent to update existing customer
information if it has changed.
2.8
The system shall be capable of recording the details of the agent transferring a call and
the details of the agent or department to whom the call was transferred.
2.9
The system shall be capable of allowing the agent to record other driver information for
as many drivers as the customer wishes to insure in the household.
2.10
The system shall be capable of allowing the agent to record the relationship between
the head of the household and other drivers.
2.11
The system shall be capable of recording the customer’s home address as the default
risk address for the vehicles.
Page 14 of 17
< Project name goes here >
5 IMPLEMENTATION CONSIDERATIONS
5.1
Critical Dates
List any Critical Dates that must be met to ensure the project is a success. For example:
The system must be implemented by August 14 to enable 2006/07 tax statements to be
produced.
5.2
Constraints and Dependencies
Include any constraints and dependencies that may impact the project’s ability to achieve the planned
outcomes.
5.3
Disaster Recovery Considerations
List the expected functionality that must be available in the event of a disaster.
5.4
Security Requirements
List the security considerations for enabling access to business applications and components for the
Proposed State solution.
Using the “Standards for the System Development Life Cycle” form, review the Overview, Requirements,
Functional Design and Business Continuity Planning tabs. Each of these sections contains important
considerations for the Business Requirements phase. Ensure that the requirements address the issues
listed that are relevant to your project.
The “Standards for the System Development Life Cycle” form is available by navigating to:
Teams => Operational Risk Management => Information Security => Forms => Standards for the
System Development Life Cycle
It can also be accessed directly at:
http://intranet.axa-financial.com/Teams/RiskMgmt/Info_Security_Library.html#forms
Some of the important issues addressed there include security forum reviews, data transfer in and out of
the enterprise, third party contractual relationships, risk assessment, key project roles for security,
information classification, disaster recovery, integration with standard access control systems, defining
user profiles for role based access control, etc. See the form for further details.
5.5
Statutory and Regulatory Requirements
Outline statutory or regulatory key controls required for future business processes.
All solutions are affected in some way by federal, state and or local regulations. The key is determining
which regulations apply to the Proposed State solution, and what must be done to ensure both immediate
and sustained compliance. Some examples of regulations that may apply include:
Gramm-Leach-Bliley Act (GLBA)
Page 15 of 17
< Project name goes here >
Health Insurance Portability and Accountability Act (HIPAA)
Sarbanes-Oxley Act
California Senate Bill SB-1386 and similar state “security breach” notification requirements
USA Patriot Act
SEC, NASD and State Insurance Regulations
It is critical that requirements that pertain to regulatory compliance are clearly identified. This will help
ensure that future decision-makers do not inappropriately nullify a compliance requirement due to an
imperfect understanding of the intent and consequences.
5.6
Training
Identify any training needs for using the new / modified tools or processes. Describe the expected
approach for training including who will provide the training, the type of training to be provided, when
training needs to occur (timing), the location of training, etc.
Page 16 of 17
< Project name goes here >
6 Additional Information
6.1
Reference Material
Identify any documents that are referenced in the BRD, and where they may be located.
The following documents are referenced in this document:
Document No.
Enter the Document
Number here
6.2
Description
Location
Enter a description of the document,
including Author, Title, Document Type (for
example Business Case, Journal Article,
etc.), and Date
Enter URL or other location
on the AXA Equitable
intranet where the latest
version of the document is
located
Glossary of Terms
Identify any phrases, acronyms and abbreviations that are used in the BRD and may not be understood
by all readers of the requirements document:
The following phrases, acronyms and abbreviations are used throughout this document:
Term
Enter phrase, acronym, or
abbreviation here
Definition
Enter the definition here
Page 17 of 17
Template
for
Your Company Name
Version #.#
Month Day, Year
< Project name goes here >
BUSINESS REQUIREMENTS DOCUMENT
Project Name:
Project Identifier:
Executive Sponsor:
(LOB) Project Manager:
IT Project Manager:
IT Relationship Manager:
Business Requirements QC
Manager:
Date Submitted:
Date Approved by Executive Sponsor:
Date Approved by Governance Committee:
Change History
Version
No.
Date
Revised By
Requested By
Page 2 of 17
Change Description
< Project name goes here >
CONTENTS
1
2
3
4
INTRODUCTION.......................................................................................................5
1.1
Background............................................................................................................................. 5
1.1.1 Current Situation / Business Need...............................................................................5
1.1.2 Project Objectives........................................................................................................ 5
1.2
Scope....................................................................................................................................... 5
1.2.1 Out Of Scope................................................................................................................ 5
1.3
Desired Outcomes.................................................................................................................. 5
1.4
Stakeholders and End Users................................................................................................. 5
1.5
Dependencies......................................................................................................................... 6
1.6
Risks / Issues.......................................................................................................................... 6
1.7
Assumptions........................................................................................................................... 6
CURRENT STATE.....................................................................................................7
2.1
Description.............................................................................................................................. 7
2.1.1 Business Processes..................................................................................................... 7
2.1.2 Systems....................................................................................................................... 7
2.1.3 People / Organization................................................................................................... 7
2.1.4 Other............................................................................................................................ 8
2.2
Challenges and Opportunities............................................................................................... 8
2.2.1 Challenges................................................................................................................... 8
2.2.2 Opportunities................................................................................................................ 8
2.3
Information Transfers............................................................................................................. 8
PROPOSED STATE..................................................................................................9
3.1
Proposed Vision..................................................................................................................... 9
3.2
Benefits................................................................................................................................... 9
3.3
Proposed Business Processes............................................................................................. 9
3.4
Business Requirement Descriptions....................................................................................9
3.5
Systems................................................................................................................................. 10
3.6
Information Transfers........................................................................................................... 10
3.7
Minimum / Recommended Performance Considerations.................................................10
3.8
People / Organization........................................................................................................... 10
3.9
Optional Features................................................................................................................. 10
3.10
Impacts on Other Business Areas....................................................................................10
3.11
Future Considerations....................................................................................................... 10
BUSINESS REQUIREMENTS................................................................................12
Page 3 of 17
< Project name goes here >
5
6
4.1
Requirement Format............................................................................................................ 12
4.2
Example Requirement.......................................................................................................... 13
IMPLEMENTATION CONSIDERATIONS...............................................................15
5.1
Critical Dates......................................................................................................................... 15
5.2
Constraints and Dependencies...........................................................................................15
5.3
Disaster Recovery Considerations.....................................................................................15
5.4
Security Requirements......................................................................................................... 15
5.5
Statutory and Regulatory Requirements............................................................................15
5.6
Training.................................................................................................................................. 16
ADDITIONAL INFORMATION................................................................................17
6.1
Reference Material................................................................................................................ 17
6.2
Glossary of Terms................................................................................................................ 17
Page 4 of 17
< Project name goes here >
1 INTRODUCTION
1.1
Background
In a few paragraphs, introduce the project and why we are doing it.
1.1.1
Current Situation / Business Need
Provide a background and description of project, including factual information on the current situation and
business need. What is the impact of this problem on the business? Is there anything depending on this
project?
1.1.2
Project Objectives
What does the project hope to achieve?
1.2
Scope
Describe the boundaries of the business process. Detail what is included (deliverables, product areas,
etc.) within the scope of this BRD – bullet points are OK.
1.2.1
Out Of Scope
To add clarity, indicate what is out of scope.
1.3
Desired Outcomes
Summarize the desired end result(s) of the project.
1.4
Stakeholders and End Users
Identify the primary / key stakeholders and users impacted by the project. These can include the actual
users of the system, managers of any impacted systems that need to be modified, and the senior
executive / sponsor of the project, among others.
The following Stakeholders and End Users have been identified:
Stakeholder
List the stakeholder (manager
level and above)
1.5
Job Function / Impact
Add the job function or the area of impact
Dependencies
List dependencies that have been identified and are being actively managed. These could be
dependencies on other projects, resources, people or business areas/functions.
Page 5 of 17
< Project name goes here >
The following dependencies have been identified and are being actively managed:
Dependency
List the
dependency name
1.6
Description
Dependency Type
Add a brief description of the
dependency
Are we dependent on
the project? Are they
dependent on us? Or
both?
Coordination Approach
What measures are in
place to manage the
dependency?
Risks / Issues
List any risks / issues that have been identified and are being actively managed. Include high-level risks
and issues rather than smaller day-to-day ones.
The following project risks have been identified and will need to be managed to ensure the project is
successfully launched on schedule:
Risk / Issue
List the risk / issue name
1.7
Likelihood / Impact
What is the likelihood it will
occur? If it does occur,
how significant is the
impact?
Mitigation Approach
What mitigation approach will be used
to manage the risk?
Assumptions
Clearly detail all assumption in relation to this BRD. For example:
This BRD assumes that ABC will continue to be the external provider of service XYZ.
The following Assumptions have been identified at this time:
Assumption #1
Assumption #2
Assumption #3
Assumption #n
Page 6 of 17
< Project name goes here >
2 CURRENT STATE
The Current State section of the BRD provides factual information describing how the business currently
operates, and any problems or enhancements that will be addressed by the project.
NOTE: If you do not include this section in the BRD you are required to provide the information in a
separate document that is signed off by the business.
2.1
2.1.1
Description
Business Processes
Provide diagrams of the current business processes. Include details such as activities being undertaken,
who undertakes the activities and systems and tools used. Swimlane process maps (see below) may be
useful. Written explanation may also be required.
Person, Team or
Business Area
Person, Team or
Business Area
These are called
Person, Team or swimlanes. They are used
to show who performs each
Business Area
activity/task
2.1.2
Other
process
name
Activity
Name
Activity
Name
This shows what activities comprise the process and who
performs each activity/task.
You can also add information regarding tools/systems used etc
Systems
Outline the systems involved in the current business processes. Include system names and the specifics
of their involvement with this project. Systems can also be indicated on the process maps. Context
Diagrams may be used as well.
2.1.3
People / Organization
Detail the people involved in the current business process and organizational structure if relevant –
include details such as team names and roles, if known, and their involvement within the current
processes. This may be covered by the process map(s) in Section 2.1.1 above. For example:
Operators within the Admin Processing Team are required to manually manipulate reports on a
daily basis, which takes between 1 and 2 hours.
2.1.4
Other
Provide other detailed information relating to the Current State not covered in the preceding sections. For
example:
Page 7 of 17
< Project name goes here >
The physical location of the system may need to be changed as the lease on the current floor
expires at the end of 2006 and may not be renewed.
2.2
Challenges and Opportunities
Your project may be responding to one or more business challenges or opportunities. Enter information
into the appropriate section(s). Delete any sections that do not relate to your project.
2.2.1
Challenges
Clearly detail the business challenges with the Current State and their impacts on the business. The
requirements detailed in later sections of the BRD will refer back to the challenges you are trying to
resolve. Challenges can be related to things that are broken, a need for improvement, a compliance
need, etc.
Copy this table for each challenge.
Challenge #n
< Name of challenge >
Description
< Description of the challenge >
Business Impacts
< Describe the impact the challenge has on the business (for example:
rework, reduced adviser satisfaction, loss of sales, compliance breach, etc.) >
Size of Problem
< Include details such as volumes, $$ and FTEs to demonstrate the size of the
problem >
Cause
< Describe the root cause of this problem >
2.2.2
Opportunities
Clearly detail the business opportunities this project will address. The requirements detailed in later
sections of the BRD will refer back to these opportunities.
Copy this table for each opportunity.
Opportunity #n
< Name of opportunity >
Description
< Description of the opportunity >
Business Benefits
< Describe the benefits the opportunity may have for the business (for
example: sales growth, adviser satisfaction, etc.) >
Size of Opportunity
< Include details such as sales volumes (eg FUA or AP), FTE savings etc to
demonstrate the size of the opportunity >
2.3
Information Transfers
Describe the information needed to support the current business processes. List information exchanged
with other business areas and systems, both inside and outside the enterprise.
Page 8 of 17
< Project name goes here >
3 PROPOSED STATE
This section of the BRD provides a description of the proposed business state. In addition to describing
the proposed state, you should indicate which aspects represent a change from the current situation.
NOTE: If you do not include this section in the BRD you are required to provide the information in a
separate document that is signed off by the business.
3.1
Proposed Vision
Provide a high-level overview or vision of the Proposed State and the expected outcomes.
3.2
Benefits
List the intended benefits of the Proposed State, and which specific Challenges and Opportunities from
Sections 2.2.1 and 2.2.2 that they resolve.
3.3
Proposed Business Processes
Provide diagrams of the proposed business processes. Include details such as activities that will be
undertaken, who undertakes the activities and systems and the tools used. Swimlane process maps (see
below) may be useful. Written explanation may also be required.
Person, Team or
Business Area
Person, Team or
Business Area
These are called
Person, Team or swimlanes. They are used
to show who performs each
Business Area
activity/task
3.4
Other
process
name
Activity
Name
Activity
Name
This shows what activities comprise the process and who
performs each activity/task.
You can also add information regarding tools/systems used etc
Business Requirement Descriptions
List the high-level process groups or requirement functions that need to be addressed to deliver the
Proposed State. Provide narrative descriptions of the Proposed Business Processes if available. For
example, “Obtain Customer Information” could be one process grouping that further analysis will detail in
greater depth in Section 4 of this BRD.
NOTE: The process groupings or requirement functions identified in this section will specifically drive the
requirements decomposition, with those results being captured in Section 4.
Page 9 of 17
< Project name goes here >
3.5
Systems
Outline the systems involved in the future business processes. Include system names and their
particulars involvement with this initiative. Systems employed can also be indicated on the process maps
in Section 3.2 above.
NOTE: In this section you are discussing the system requirements from a business perspective, rather
than detailing the IS solution.
3.6
Information Transfers
Describe the information needed to support future business processes. Include the need for historical
information, data conversions or reformatting, and impacts / dependencies with other business areas and
systems (both inside and outside the enterprise).
3.7
Minimum / Recommended Performance Considerations
Outline the expected performance criteria (minimum and recommended) for the proposed business
processes and solution.
3.8
People / Organization
Identify any people or organizations impacted by the Proposed State. Include details such as team
names, roles, and their involvement within the future processes.
NOTE: This may be covered by the Proposed Business Processes map in Section 3.2 above.
3.9
Optional Features
Detail any features that may enhance the value of the overall effort, but that are not required as a part of
this project.
3.10 Impacts on Other Business Areas
Describe any impacts to other business areas as a result of the Proposed State, if not already described
in previous sections.
3.11 Future Considerations
Detail any issues or requirements that are not being addressed by the proposed future state due to
project constraints (such as time, budget, dependencies, etc.), but that the business may wish to consider
at a later date. Make sure you indicate that these are OUT OF SCOPE in the current project. For
example:
Once Phase 1 of the XYZ project has been launched successfully, implementation of a report
module may provide added value to the business. This report module is OUT OF SCOPE for
Phase 1.
Page 10 of 17
< Project name goes here >
Scoping Approvals
Name
Signature
Business Line Sponsor:
IT SIO Sponsor:
Business Requirements
QC Manager:
Page 11 of 17
Date
< Project name goes here >
4 BUSINESS REQUIREMENTS
Use the following outline to provide details of the business requirements for the Proposed State. This
section of the BRD should provide the detail on the features of the Proposed State and list the planned
outcomes.
Section 2 (Current State) and Section 3 (Proposed State) of this BRD should be completed in sufficient
detail to provide the feature groupings that will drive the outline of this business requirements section.
Section 3.2 should specifically list these high level requirement or feature categories. In the example
below, “2.0 Obtain Customer Information” represents one individual Requirement or feature grouping /
family.
Where appropriate include tables, diagrams and screen prints to outline business requirements
necessary to deliver proposed state.
Use the following format to detail each requirement – repeat the format for each requirement grouping.
4.1
Requirement Format
Requirement Number
Requirement Title
Process or Context Diagram
Summary Process Narrative
Triggering Event(s) and Pre-Conditions
Outcome(s) and Post-Conditions
Alternatives Considered
Design Considerations / Notes
Issues / Assumptions / Risks
Requirements List
Page 12 of 17
< Project name goes here >
4.2
Example Requirement
The following sections provide an example of how to structure business requirements in the BRD.
2.0
Obtain Customer Information
Process Diagram
CUSTOMER
other
driver detail
customer & other
driver detail
vehicle garaging
address
CAMPAIGN
mailing /
alternate
solicitation /
response
channel
CALL
Obtain
Customer
Information
CUSTOMER
known
info
new / update
garaging
address
VEHICLE
vehicle detail
reason
forcall
csutomer & other
driver detail
QUOTE
Summary Process Narrative
When the agent has picked up the call, the system will display any information about the
customer that has been found as a result of a system search and/or entered by the customer
through the IVR. The agent will verify the information. The reason for the call, the solicitation
channel and the response channel will be recorded.
Customer information will be verified (or entered if it is a new customer with no Customer ID or if
the customer does not know their Customer ID). The agent will record information about all
drivers who are to be insured, including the relationship between the drivers.
Triggering Event(s) and Pre-Conditions
Agent available and picks up phone
Outcome(s) and/or Post-Conditions
Recorded customer information
Keycode determined
Alternatives Considered
Through IVR/Not through IVR
Customer ID available/Not available
Resident of more than one state
Design Considerations/Notes
Want ability for reps to re-request CBUS with additional information without doing a manual
workaround
Page 13 of 17
< Project name goes here >
Score and reason codes cannot be altered (security)
Want ability to capture ANI and link to policy/quote without adding as alternate number
Ability to capture all phone numbers, but only display the number most commonly used
Issues / Assumptions / Risks
When do we order the CBUS?
Is extension still used?
Determine / design rules to determine head of household – automation exists in OCR project
for MQS.
Customer database needs to be enhanced to allow capture of customer telephone numbers.
Assume that zip will populate city and state.
How do we want to deal with referrals?
When do we advise the agent that the quote will DNQ?
Requirements List
2.0
Obtain Customer Information
2.1
The system shall be capable of determining a customer exists using on the telephone
number that the customer dialed from.
2.2
The system shall be capable of determining if a customer exists based on the
customer’s last name and zip code.
2.3
The system shall be capable of allowing the agent to record the reason for a call.
2.4
The system shall be capable of recording the response channel as “phone” when a
customer calls in to speak to an agent.
2.5
The system shall be capable of allowing the agent to record the solicitation channel.
2.6
The system shall be capable of allowing the agent to record new customer detail.
2.7
The system shall be capable of allowing the agent to update existing customer
information if it has changed.
2.8
The system shall be capable of recording the details of the agent transferring a call and
the details of the agent or department to whom the call was transferred.
2.9
The system shall be capable of allowing the agent to record other driver information for
as many drivers as the customer wishes to insure in the household.
2.10
The system shall be capable of allowing the agent to record the relationship between
the head of the household and other drivers.
2.11
The system shall be capable of recording the customer’s home address as the default
risk address for the vehicles.
Page 14 of 17
< Project name goes here >
5 IMPLEMENTATION CONSIDERATIONS
5.1
Critical Dates
List any Critical Dates that must be met to ensure the project is a success. For example:
The system must be implemented by August 14 to enable 2006/07 tax statements to be
produced.
5.2
Constraints and Dependencies
Include any constraints and dependencies that may impact the project’s ability to achieve the planned
outcomes.
5.3
Disaster Recovery Considerations
List the expected functionality that must be available in the event of a disaster.
5.4
Security Requirements
List the security considerations for enabling access to business applications and components for the
Proposed State solution.
Using the “Standards for the System Development Life Cycle” form, review the Overview, Requirements,
Functional Design and Business Continuity Planning tabs. Each of these sections contains important
considerations for the Business Requirements phase. Ensure that the requirements address the issues
listed that are relevant to your project.
The “Standards for the System Development Life Cycle” form is available by navigating to:
Teams => Operational Risk Management => Information Security => Forms => Standards for the
System Development Life Cycle
It can also be accessed directly at:
http://intranet.axa-financial.com/Teams/RiskMgmt/Info_Security_Library.html#forms
Some of the important issues addressed there include security forum reviews, data transfer in and out of
the enterprise, third party contractual relationships, risk assessment, key project roles for security,
information classification, disaster recovery, integration with standard access control systems, defining
user profiles for role based access control, etc. See the form for further details.
5.5
Statutory and Regulatory Requirements
Outline statutory or regulatory key controls required for future business processes.
All solutions are affected in some way by federal, state and or local regulations. The key is determining
which regulations apply to the Proposed State solution, and what must be done to ensure both immediate
and sustained compliance. Some examples of regulations that may apply include:
Gramm-Leach-Bliley Act (GLBA)
Page 15 of 17
< Project name goes here >
Health Insurance Portability and Accountability Act (HIPAA)
Sarbanes-Oxley Act
California Senate Bill SB-1386 and similar state “security breach” notification requirements
USA Patriot Act
SEC, NASD and State Insurance Regulations
It is critical that requirements that pertain to regulatory compliance are clearly identified. This will help
ensure that future decision-makers do not inappropriately nullify a compliance requirement due to an
imperfect understanding of the intent and consequences.
5.6
Training
Identify any training needs for using the new / modified tools or processes. Describe the expected
approach for training including who will provide the training, the type of training to be provided, when
training needs to occur (timing), the location of training, etc.
Page 16 of 17
< Project name goes here >
6 Additional Information
6.1
Reference Material
Identify any documents that are referenced in the BRD, and where they may be located.
The following documents are referenced in this document:
Document No.
Enter the Document
Number here
6.2
Description
Location
Enter a description of the document,
including Author, Title, Document Type (for
example Business Case, Journal Article,
etc.), and Date
Enter URL or other location
on the AXA Equitable
intranet where the latest
version of the document is
located
Glossary of Terms
Identify any phrases, acronyms and abbreviations that are used in the BRD and may not be understood
by all readers of the requirements document:
The following phrases, acronyms and abbreviations are used throughout this document:
Term
Enter phrase, acronym, or
abbreviation here
Definition
Enter the definition here
Page 17 of 17
