BRD Detail

Business Requirements Document Version: 1.0
Page 1 of 18
Table of Contents
1 Document Revision History................................................................. Error! Bookmark not defined.
2 Document Approval History ................................................................ Error! Bookmark not defined.
3 References.......................................................................................... Error! Bookmark not defined.
Table of Contents ........................................................................................................................................ 1
4 Document Purpose ............................................................................................................................. 2
5 Program / Project Vision ..................................................................................................................... 2
6 Program / Project Background............................................................................................................ 2
7 Assumptions / Dependencies / Constraints ........................................................................................ 2
8 Actor Catalog ...................................................................................................................................... 3
9 End User Profile.................................................................................................................................. 3
10 Business Process Flows ..................................................................................................................... 4
10.1 Online Marcom Application: Collect Required Patriot Act consumer Information ...................... 5
10.2 Online Checkout: Collect Required Patriot Act consumer Information...................................... 8
10.3 Symphony: Collect Required Patriot Act consumer Information ............................................. 10
10.4 RAMS: Collect Required Patriot Act consumer Information ...... Error! Bookmark not defined.
10.5 ==Titanium Account (ATA): Collect Required Patriot Act consumer Information ............. Error!
Bookmark not defined.
11 Project Tradeoff Matrix........................................................................ Error! Bookmark not defined.
12 Business Risk Assessment............................................................................................................... 15
13 Impacts.............................................................................................................................................. 15
14 Critical Success Factors.................................................................................................................... 15
15 Acceptance Criteria........................................................................................................................... 16
16 Key Business Indicators.................................................................................................................... 16
16.1 Stability..................................................................................................................................... 16
16.2 Capacity ................................................................................................................................... 16
16.3 Disaster Recovery Class .......................................................................................................... 17
17 Data Security Requirements ............................................................................................................. 17
18 Application Support Requirements and Acceptance Criteria ............................................................ 17

Page 2 of 18
1 Document Purpose
The Business Requirements Document defines the business objectives and the business requirements of
the customer requesting the system or product. This document is created by the customers or business
representatives and reviewed and approved by their IT counterparts.
Note: The appendices are considered to be part of these business requirements.
2 Program / Project Vision
------
3 Program / Project Background
----
4 Assumptions / Dependencies / Constraints
Described below are the infrastructure, resources, training and other project releases assumed to be in
place to make this project successful.
No. Assumption Impact if not True
ASM1 I/T will prioritize and complete work. Project not completed. The benefits of
the streamlined process will not be
realized.
ASM2 sales workflow process will be changed to accommodate
these requirements
Project not completed. The benefits of
realized.
ASM3 No upcoming changes to the Patriot Act Requirements will need to be updated.
ASM4 ==IT will prioritize and complete work. Project not completed. The benefits of
realized.
ASM5 -- solutions can be delivered separately. Releases must be tightly coordinated.
Increased risk of delay.
List any projects, tasks or vendor support this project depends on to work successfully.
No. Dependency
DP1
Provide a general description of any other items that will limit the project team’s options. A constraint is
defined as a restriction on the degree of freedom the team has in providing a solution.
No. Constraint Rationale for Constraint

Page 3 of 18
5 Actor Catalog
An actor is anything that interfaces with the system. Actors can be people, organizations, other software
systems, hardware devices, databases or network services.
No. Actor Name Description
A1 Sales Representative Staff taking inbound sales calls for Consumer segment in
the call centers
A2 Customers Person who has requested ---
A3 APS Team Asset Protection Services team member – This team is
responsible for working the PO Box queue in Falcon ID.
A4 DFS Assist Team who assists sales representatives and customers
with finalizing information
A5 Symphony Sales application used by Sales Representatives
A6 Online Online store used by customer
A7 RAMS Revolving Account Management System
A8 CPS Customer processing system. This is where the physical
address will be stored.
A9 Falcon ID Workflow tool used to manage the PO Box Queue
A10 DOMS Order Management System
A11 Blaze Where queuing rules are applied
A12
A13
6 End User Profile
This section identifies and classifies User Types. A User Type is one type of actor (i.e., the end users
who will interact directly with the product). The following table is used to assess their goals, expectations,
constraints and project risks. The description of the user type should come from the actor survey.
Note: The same end user may be listed multiple times depending on location, language or other factors.
Profile Component
Sales
Representative Customer APS Team
DFS
Assist
==Sales
Represent
ative

Page 4 of 18
Profile Component
Sales
Representative Customer APS Team
DFS
Assist
==Sales
Represent
ative
7 Business Process Flows
This section contains the business process flows, business requirements and report requirements. Use
cases can be used to document business requirements (See Appendix E). Each business requirement
has a MoSCoW Ranking as defined below:
MoSCoW Ranking [Key = M, S, C, W]
M: Must have for launch (Critical).
S: Should have but not critical for launch, (but critical for roll out or some part of it is).
C: Could have.
W: Won’t have (yet).

Page 5 of 18
7.1 Online Marcom Application: Collect Required --consumer Information
Existing Business Process Flow Diagram
k
New Business Process Flow Diagram
Business Process Flow Steps
Step
No.
Process
1.0 Customer selects to apply for DPA from any location prior to checkout. (Existing process)
2.0 System display Marcom Application in a pop-up window. (Existing process)
3.0 Customer enters his/her contact information. The customer is allowed to enter a PO Box as
billing address. (New process)

Page 6 of 18
4.0 Customer enters his/her personal information. (Existing process)
5.0 Customer enters his/her physical address. (New process)
6.0 Customer agrees to terms and conditions by activating the check box. (Existing process)
7.0 Customer submits the application. (Existing process)
8.0 System validates the application for required fields, and performs basic edit checking.
(Existing process)
8.1 If validation fails, the system displays the appropriate error message and allows the
customer to correct and resubmit the application. (Existing process)
9.0 System validates that a physical address has been provided. (New process)
customer to correct and resubmit the application. (New process)
10.0 Once all validation has passed, the system sends a request to DFS for adjudication.
(Existing process)
Business Requirements
Business requirements describe the tasks the users must be able to accomplish with the product.
Business requirements reflect business processes and are generally written in the format verb +
object.
BR # Business Requirement Owner MoSCoW
Ranking
Priority Release
BR
1.1.0
Validation of Name
BR
1.1.1
Provide error message when
the Name field is invalid
IT M
BR
1.2.0
Validation of DOB
BR
1.2.1
DOB provided is invalid
IT M
BR
1.3.0
Collection of Physical Address
BR
1.3.1
Provide fields within the
Marcom application for a
customer to provide a physical
address.
IT M
BR
1.3.2
Provide appropriate scripting
within the Marcom application
to explain why the physical
address is being collected.
IT M
BR
1.3.3
Allow the customer to indicate
that their physical address is the
same as their billing address
without re-entering the entire
address.
IT M
BR
1.4.0
Validation of Physical Address

Page 7 of 18
BR
1.4.1
Provide an error message when
the customer provides a PO
Box as the billing address, but
does not provide a physical
address.
IT M
BR
1.4.2
customer enters a PO Box as
the physical address.
IT M
BR
1.5.0
Submission of Request
BR
1.5.1
Send both billing and physical
addresses to DFS as part of the
request.
IT/DFS
IT
M
BR
1.5.2
Use the physical address for
obtaining report when the
billing address is a PO Box
DFS IT M
BR
1.5.3
Standardize the collected
physical address. This is
expected to be similar to the
standardization using IQ-8 in
the SMB request.
DFS IT S
BR
1.5.4
Make the results of the address
standardization available to
APS.
DFS IT S
BR
1.6.0
Retention of --information
BR
1.6.1
Retain and archive the collected
--information
DFS IT M
Performance Needs
Performance is the rate, volume or number of transactions or units of work a system/application is
capable of, measured over time. An understanding of the immediate and projected performance
needs for a business process flow is critical to ensure that they are taken into consideration in the
design.
No. Question Typical
Business Day
Non-Typical
Business Day
PN1 Approximate number of transactions / units of work per
user per minute.
Existing Existing
PN2 Approximate number of transactions per user per day. Existing Existing
PN3 Approximate number of users per day. Existing Existing
Report Requirements
Report Requirements provide descriptions of the reports needed, indicating the purpose, users,
frequency, data fields and other important information about each report.
Existing reporting will be used

Page 8 of 18
7.2 Online Process: Collect Required --consumer Information
Step
No.
Process
1.0 Customer applies for DPA as the method of payment. (Existing process)
2.0 System displays DPA Application. (Existing process)
3.0 Customer enters his/her billing address. (Existing process)
4.0 Customer enters his/her personal information. (Existing process)
5.0 Customer enters his/her physical address. (New process)

Page 9 of 18
6.0 Customer agrees to terms and conditions by activating the check box. (Existing process)
7.0 Customer submits the application. (Existing process)
8.0 System validates the application for required fields, and performs basic edit checking.
(Existing process)
customer to correct and resubmit the application. (Existing process)
9.0 System validates that a physical address has been provided. (New process)
customer to correct and resubmit the application. (New process)
10.0 Once all validation has passed, the system sends a request to DFS for adjudication.
(Existing process)
object.
Ranking
Priority Release
BR
2.1.0
Validation of Name
BR
2.1.1
the Name field is invalid
IT M
BR
2.2.0
Validation of DOB
BR
2.2.1
DOB provided is invalid
IT M
BR
2.3.0
Collection of Physical Address
BR
2.3.1
Provide fields within the
application for a customer to
provide a physical address.
IT M
BR
2.3.2
Provide appropriate scripting
within the application to
explain why the physical
address is being collected.
IT M
BR
2.3.3
Allow the customer to indicate
that their physical address is the
same as their billing address
without re-entering the entire
address.
IT M
BR
2.4.0
BR
2.4.1
the customer provides a PO
Box as the billing address, but
does not provide a physical
IT M

Page 10 of 18
address.
BR
2.4.2
customer enters a PO Box as
IT M
BR
2.5.0
BR
2.5.1
request.
IT/DFS
IT
M
BR
2.5.2
Use the physical address for
obtaining report when the
billing address is a PO Box
DFS IT M
BR
2.5.3
the SMB request.
DFS IT S
BR
2.5.4
APS
DFS IT S
BR
2.6.0
Retention of --information
BR
2.6.1
--information
DFS IT M
Performance Needs
design.
Business Day
Non-Typical
Business Day
user per minute.
Existing Existing
Report Requirements
7.3 Symphony: Collect Required --consumer Information

Page 11 of 18

Page 12 of 18
Step
No.
Process
1.0 Sales representative configures and verifies an order for a customer (Existing Process)
2.0 Sales representative selects DPA as the payment method (Existing Process)
3.0 Sales representative collects and completes the DBC information (personal & contact
information). (Existing Process)
4.0 Sales representative collects and completes physical address. (New Process)
5.0 The representative submits the order. (Existing Process)
6.0 System validates that a physical address has been provided. (New Process)
representative to correct and resubmit the application. (New Process)
8.0 The representative then reads the terms and conditions to the customer (Existing Process)
9.0 If the customer is not satisfied with the terms and conditions, the system allows the
representative to change the payment method. (Existing Process)
10.0 Once the customer accepts the terms and conditions the transaction is sent to DFS
(Existing Process)

Page 13 of 18
object.
Ranking
Priority Release
BR
3.1.0
Collection of Physical address
BR
3.1.1
Provide fields in the second part
of the application within the
Order Create Screen for a
customer to provide the sales
representative with a physical
address.
IT M
BR
3.1.2
Allow the sales representative
to indicate that the customer’s
physical address is the same as
the billing address without re-
entering the entire address.
IT M
BR
3.2.0
BR
3.2.1
the customer provides the sales
representative with a PO Box as
the billing address, but does not
also provide a physical address.
IT M
BR
3.2.2
Customer provides the sales
representative with a PO Box as
IT M
BR
3.3.0
BR
3.3.1
customer information.
IT/DFS
IT
M
BR
3.3.2
Ensure that account is not
created until --compliance is
met. (This is similar to Security
Statement logic.)
DFS IT M
BR
3.3.3
the SMB request.
DFS IT S
BR
3.3.4
APS
DFS IT S
BR Retention of --information

Page 14 of 18
3.4.0
BR
3.4.1
--information
DFS IT M
Performance Needs
design.
Business Day
Non-Typical
Business Day
user per minute.
Existing Existing
Report Requirements

Page 15 of 18
7.4
8 Business Risk Assessment
Described below are the business risks to or users.
Probability Impact
Evaluate each risk item and assess the probability of
that event occurring. Indicate that probability in the
“Probability” column using the following terms:
• High – Probability is greater than 75%.
• Medium – Probability is between 25% and 75%.
• Low – Probability is less than 25%.
Evaluate each item marked as High, Medium or Low
and assess the consequences to the project if the
event occurs. Indicate the impact of the occurrence in
the “Impact” column using the following terms:
• High – Consequences of the occurrence could
have a significant impact on the project.
• Medium – Consequences of the occurrence
could have a medium impact on the project.
• Low – Consequences have little impact.
# Risk Factors Probability Impact Risk Response
1 prioritization High Project not
completed
Continue with existing
process on backend.
2 ==prioritization High Project not
completed
Continue with existing
process on backend.
9 Impacts
Described below are the potential impacts to existing products or projects.
Product/Project
Name
OASIS/Product #
(if applicable)
Impact Description
State the impact
level: low, medium
or high.
Describe the impact this project will have
on the existing product/project.
10 Critical Success Factors
The Critical Success Factors describe how the success of the project is to be measured, how the project
team will know that the project is progressing as planned, etc.
Success Factor How Measured

Page 16 of 18
Success Factor How Measured
11 Acceptance Criteria
The project’s acceptance criteria are documented in the following table. The criteria are used to
determine whether the solution is ready to be made operational (i.e., ready to be deployed to the
production environment during the Developing phase) and whether the project is ready to exit the
Stabilizing phase.
Criteria How Measured
Defect Tolerance Zero severity 1 defects outstanding.
Zero severity 2 defects outstanding.
No more than ten severity 3 defects outstanding.
No limit on severity 4 defects outstanding.
Completed Documentation All project documentation is up to date and accurate,
including Application Support documentation and
System Training documentation.
Go/No-Go Criteria Established All Conditions for a Go Decision are met prior to
system deployment.
12 Key Business Indicators
12.1 Stability
Stability is the measure of continuous operation of a system or application over time. This project will
employ the appropriate technologies to address the consequences of failure in the application, the
underlying database and infrastructure as well as any upstream or downstream dependencies.
In order to create an application that meets the business requirements in relation to stability or availability,
businesses requirements in this area are outlined below.
No. Question Typical Business Day
1
2
12.2 Capacity
It is anticipated that the business will grow its business on a continuing basis. This means that the
applications that are developed today must be developed with future business requirements in mind.
In order to plan ahead, the following information is provided.
Business Day
Non-Typical
Business Day

Page 17 of 18
1
2
3
4
5
12.3 Disaster Recovery Class
Below is the business’s thought on what the DR class should be. However, the final determination of the
DR Class will be stated in the System Requirements Specification (SRS).
DR Class DR Class Description
I
Mission
Critical
13 Data Security Requirements
As part of the Global Security Policy, it is required that all data used within a project is assigned a
classification for confidentiality, integrity and availability. As far as possible, assign a classification for
each of these headings to the major groups of data used in the project.
All classifications and definitions can be found in the Global Data Classification Policy, which can be
found at: ===
ClassificationsFunctional
Area
GEMC Member /
Data Owner
Information Subject
Area
Confidentiality Integrity Availability
14 Application Support Requirements and Acceptance
Criteria
Unless otherwise noted, below is the list of high-level Application Support Requirements and acceptance
criteria that will need to be considered to effectively support the system in production. The specific
Application Support Requirements, as applicable to the application, will be documented in the System
Requirements Specification. See the Guide to System Support Requirements Work Aid for specific
information on the type of application support requirements that will be considered.
High-level Application Support Requirements
1 Application should provide Error Handling processes
2 Application should provide Monitoring processes
3 Application should provide Exception Handling processes

Page 18 of 18
High-level Application Support Requirements
4 Application should follow Batch Processing
5 Application should provide Notification processes
6 Application should provide Application Maintenance processes
7 Application should provide Automated Deployment processes
8 Application should provide Support Task Automation processes
9 Application should provide Vendor processes
10 Application should provide Security Management processes
Criteria How Measured

BRD Detail

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a BRD Detail

Semelhante a BRD Detail (20)

Último

Último (20)

BRD Detail