BRD - Business Requirements Template
[AABB] BUSINESS REQUIREMENTS DOCUMENT (BRD)
[ REQUIREMENTS NAME] REQUIREMENTS
December 25, 2018
DRAFT /Version 1.0
[PROJECT NAME]
Internal Use Only
Banner HR
12/25/2018 2:31 PM Classified: Internal Use Only1
Table of Contents
Document Information and Revision History
Key Contributors
Reviewers of Document
Approval Signature Page
Acronyms and Glossary
Purpose of the Business Requirement Document
Project Overview
Background
Business Need
Objectives
Stakeholders
Requirements Guidelines
Description
Template Guidelines
Regulatory/Policy Requirements
Functional Requirements
Approval Requirements
Report Requirements
Data Requirements
Interfaces/Batch Process Requirements
Performance Requirements
Operational Requirements
Usability Requirements
Security Requirements
Training Requirements
Assumptions, Dependencies and Constraints
Assumptions
Dependencies
Constraints
Appendix A: References
BRD - Business Requirements Template
Document Information and Revision History
File Name / BRD - Business Requirements Template.docOriginal Author(s) / [Author Name(s)]
Current Revision Author(s) / [Author Name(s)]
Version / Date / Author(s) / Revision Notes
1 / mm/dd/yyyy / [Author Name(s)] / [Notes]
Key Contributors
[List Key Contributors of content who have been consulted with in order to document this process]
Name / Organization / Role / Notes/CommentsReviewers of Document
[Identify the individuals who reviewed the BRD and the date that the review was completed. Signatures are not required]
Name / Organization / Role / Notes/CommentsApproval Signature Page
Deliverable Name:Version Number:
Project Name:
I agree that this document represents my best understanding of the information presented within this Deliverable for this project today. Future changes in this baselined document can be made through the project’s change management process. I realize that approved changes might require us to renegotiate the cost, resource, and schedule commitments for this project.
Approver Name / Approver Title / Approver Signature/Electronic Vote/Email / DateAcronyms and Glossary
If this section of the document is not required indicate with N/A and delete all content for the section below.
[The following table includes definitions for any unique symbols or notations that are used in the document, which may cause confusion with the intended message, or may result in multiple interpretations of some key terms.]
Acronym / Term / DefinitionPurpose of the Business Requirement Document
This Business Requirements Document (BRD) is intended to [describe intention].
The BRD is the basis for all subsequent project planning, design and coding. It describeswhat should happen in the system under various conditions, as completely as known at this time. The BRD does NOT contain design information or anything related to how the system will provide the functionality.
This document expresses the functions and capabilities that a system must provide for the [enter project name] to be successful. All known constraints, assumptions and dependencies are also defined.
All attempts have been made to use business terminology and language in describing the business requirements. Only common technical terminology is used in this document.
Intended Audience
[Indicate who will benefit from reading this document]
e.g. This document is intended mainly for the business owners and end users of the Banner Student system to verify that their business requirements have been documented here completely, accurately and unambiguously.
Technical staff will benefit when considering how to design a system to meet the business requirements.
Project Overview
[Provide an introduction to the Project (copy from Project Charter). This includes describing the business context of the project and an overview of the client’s operation. Include a high-level overview of each of the functional business areas.]
Background
[Provide a brief background on the history of the requirements, the problem that must be addressed, the issues, concerns, challenges, etc.
Business Need
Define the business need that this project will address
[Describe why the project needs to be done at this point in time (copy from Project Charter).]
Objectives
[List the high level business needs that must be met by the defined solution.]
- [Objective 1]
Stakeholders
[Identify the stakeholders for the project – departments, their clients, etc.]
Name / Title / Department / Describe involvementRequirements Guidelines
These guidelines are for the document author. This section may be deleted.
Description
Requirements describe WHAT the system, process or product/service must do in order to fulfill the business need(s).
Template Guidelines
In each of the following tables, use the following guidelines:
- Req # – Use to uniquely identify each requirement. The number should be a sequential number starting at one and should not be prefixed or reset when starting a new requirement.
- Source – Enter the name of the person who identified the requirement.
- Organization – Enter the organization for the source of the requirement.
- RequirementDescription–Define the requirement ensuring each accurately describes the functionality to be delivered.
- Requirement Owner – Enter the name of the owner of the requirement (person or group)
- Priority – Indicate if the requirement is High, Medium or Low.
- High - Requirements identified as High are deemed critical to the operation of the proposed system. They represent features that the client cannot function without
- Medium - Requirements identified as Medium are those that are not mission critical to the client’s business but could provide significant benefit to the organization.
- Low - Requirements identified as Low are not critical to the operations of the proposed system, but would represent helpful or convenient features that would be beneficial to the client.
Regulatory/Policy Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In the table below, list any policies, standards or legal constraints that apply to this process. These are existing policies that MUN has identified or have been defined by external parties that the system must respond to. Paste here and list the source and date of the documentation.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityGraduate Student Support Payroll Form (Nov 2011) / School of Graduate Studies / For International Students, Graduate Assistantship Stop Date CANNOT exceed expiry date on graduate’s Social Insurance Number / School of Graduate Studies / H
Functional Requirements
[List the functionalrequirements that are necessary to meet the business needs. Where requirements are particular to a location or subset of the employee population (e.g. exempt vs. non-exempt, note this as an aspect of the requirement. These statements should be measurable and finite enough to generate a technical design. Decompose broad processes and procedure statement into system parameters.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / Users completing payroll requests shall be able to enter more than one payment source on a graduate payroll request. / School of Graduate Studies / H
Approval Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In the table below, list approval requirements for this process (if any). In the description, list whether an approval, formal review, or simply a notification is required.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / User shall be able to approve Payroll requests. / School of Graduate Studies / H
Report Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In the table below, list report requirements necessary for this process. When defining a report requirement, be sure to describe how the report is used in the process, the source of the report, frequency (daily, weekly, ad hoc), and who uses the report.
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / User shall be able to report on unapproved payroll requests. / School of Graduate Studies / H
Data Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In the table below, list data requirements (conversion, cleansing, retention, etc.). For data retention requirements, detail the source of data, how often the data must be accessed, whether or not this is a regulatory requirement and how many years the data must be retained]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / User shall be able to approve Payroll requests. / School of Graduate Studies / H
Interfaces/Batch Process Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In the table below, list interfaces that are necessary for this process (information that must be provided to other entities)].
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJohn Smith / Registrar’s Office / The system must pass class schedule information to the room booking system. / Registrar’s Office / H
Performance Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In this section, describe the requirements for speed, reliability, capacity, scalability, etc.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / The application shall clearly acknowledge all user requests within 0.5 seconds. / School of Graduate Studies / H
Operational Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[In this section, describe the environments (hardware/software), availability, supportability, and recoveryrequirements.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / The Payroll system shall not have more than 5 hours of scheduled downtime per month and not more than an average of 1 hour of unscheduled downtime per month. / School of Graduate Studies / H
Usability Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[Usability requirements identify what users’ abilities and expectations of usage experiences the product must conform to. Meant to address user friendliness and how the user interfaces (screens) are designed with consideration for the different types or users and their skill sets.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / The system will populate any effective date field with the current date when adding or updating a record. / School of Graduate Studies / H
Security Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[Security requirements identify the security, confidentiality, integrity and privacy issues affecting access to the product, use of the product, and protection of the data the product uses or creates.
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / The system shall not require users to identifythemselves multiple times during a single session (i.e., single sign on). / School of Graduate Studies / H
Training Requirements
If this section of the document is not required indicate with N/A and delete all content for the section below.
[Training requirements identify all user, help desk and support training required,e.g. required materials, level of training, number of participants, duration of training, etc.]
Req # / Source / Organization / Requirement Description / Req. Owner / PriorityJane Doe / School of Graduate Studies / All users must attend basic system training before being granted access to the system. / School of Graduate Studies / H
Assumptions, Dependencies and Constraints
Assumptions
[Identify any assumptions; factors that, for planning purposes are considered to be true, real or certain without proof or demonstration.]
# / DescriptionDependencies
[Identify any factors that are linked together where each has some effect on the other. These may include things like availability of project resources, users or stakeholders, equipment, business processes and regulatory approvals.]
# / DescriptionConstraints
[Identify any factors that limit or place constraints on the development of the solution. These may include but are not limited to time and budget constraints, regulatory, technological or business realities.]
# / DescriptionAppendix A: References
If this section of the document is not required indicate with N/A and delete all content for the section below.
[List external documents to which this document refers and their location e.g., URL, folder, etc.]
References / Location[Project Name]
12/25/2018 Classified: Internal Use Only Page 1 of 16