Aabb Business Requirements Document (Brd)

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

Key Contributors

[List Key Contributors of content who have been consulted with in order to document this process]

Reviewers of Document

[Identify the individuals who reviewed the BRD and the date that the review was completed. Signatures are not required]

Approval Signature Page

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.

Acronyms 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.]

Purpose 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.]

1. [Objective 1]

Stakeholders

[Identify the stakeholders for the project – departments, their clients, etc.]

Requirements 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.]

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.]

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.]

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.

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]

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)].

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.]

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.]

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.]

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.

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.]

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.]

Dependencies

[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.]

Constraints

[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.]

Appendix 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.]

[Project Name]

12/25/2018 Classified: Internal Use Only Page 1 of 16