BUSINESS REQUIREMENTS DOCUMENT (BRD)

< Project Name >

Project Name: < Project Name >

Document Version: 0.1
Creation Date: < Release Date >
Last Modified Date: -
Author(s): < Author or group name >

Template. : Business Requirements Document

Version : V1.1
Governance : : PMO & PQM

Montclair State University – Proprietary

Use Pursuant to Organization Instructions

Document1 Page: 1 of 6
 BUSINESS REQUIREMENTS DOCUMENT (BRD)
< Project Name >

Table of Contents

PURPOSE ......................................................................................................................................... 3
SCOPE .............................................................................................................................................. 3
DEFINITIONS.................................................................................................................................... 3
BUSINESS REQUIREMENTS ............................................................................................................. 3
NON-FUNCTIONAL REQUIREMENTS ............................................................................................... 4
INTERFACE REQUIREMENTS ........................................................................................................... 5
USE CASES ....................................................................................................................................... 5
DOCUMENT CONTROL .................................................................................................................... 6
Document Version ...................................................................................................................... 6
Document Approval .................................................................................................................... 6
Document Change Control ......................................................................................................... 6
References .................................................................................................................................. 6

Document1 Page: 2 of 6
 BUSINESS REQUIREMENTS DOCUMENT (BRD)
< Project Name >

< Blue Text within angle brackets “< - >” in this template is guidance information and blue text
without brackets is example data. All blue text must be replaced and turned to black text or
removed when creating the final document. >

PURPOSE
< The purpose of this project should be described here that includes the business capabilities
the project should provide. >

SCOPE
< Each project should have only one BRD. This section should define at a high level, the
intended scope for this project. This would include impacted systems and departments. Visio
models or descriptive text may be used (or a combination) at the project managers discretion. >

DEFINITIONS
Standard acronyms and definitions are contained in OM-STD-003 Standard Definitions and
Acronyms. Below are significant definitions required by this document.
Term Definition
The collection of internal documents that control the organization’s work. (e.g.:
Process Policies, System Descriptions, Process Descriptions, Procedures, Templates,
Documentation Standards, Tools, Training Slides, etc.) The full set of document types and their
descriptions are documented in OM-ARC-001 Process Documentation Architecture
Process Documentation Library – This library contains the authorized and approved
PDL
process documents and tools. It is located on the OneMontclair Blackboard portal

BUSINESS REQUIREMENTS
< This section should include the high level business requirements described in terms of the
business capability needed. Each business requirement (BR) should have one or more
functional requirements. Each functional requirement (FR) should have one or more business
rules and one or more data requirements. Each business rule (BZ) should describe in detail the
specific criteria needed to provide the desired output, such as formulas, edit checks, IF-THEN-
ELSE logic, etc. Each data requirement (DR) should describe each required field, how those
fields will be populated (either by the user or some other system), where the data should be
stored and any downstream systems that the data should be sent to. The example below shows
one completed BR that has only one FR with one BZ and one DR, but real business requirements
may include multiple FR’s, BZ’s and DR’s. (Business Analysts may describe the requirements

Document1 Page: 3 of 6
 BUSINESS REQUIREMENTS DOCUMENT (BRD)
< Project Name >

using Use Cases instead of the example method below. Please see Use Cases section for
examples). >
ID PRIORITY DESCRIPTION DEPENDENCIES COMMENTS
BR01 The system should provide New student These examples in
the capability to add a new application blue should be
student. replaced by project
requirements and
italics removed.
FR001.01 High The system must be able to FR’s should be
accept first name, last name, numbered so they
(Identifies BR01 (Priorities
address and social security can be associated
association) are only
number. with one and only
associated
one BR.
with FR’s)
BZ01.001 As user moves from social Social security BZ’s should be
security number field, the number must be numbered so they
(identifies FR001
system must compare entered for new are associated with
association)
against both the current applicant and user one and only one
student master DB and must attempt to FR.
previous applications DB and move to another
alert user if a match is found. field by using the
<tab> key.
DR01.001 All data for this FR must be DR’s should be
entered by the user, but numbered so they
(Identifies FR001
comparisons of the social are associated with
association)
security number must be one and only one
performed with master FR.
student DB and any saved
data from previous
applications over the last 12
months.
BR02

NON-FUNCTIONAL REQUIREMENTS
< Non-functional requirements should be described in this section and examples are Security
requirements, Performance requirements, etc. Non-functional requirements should be stated
on one line instead of broken out into FR’s, BZ’s, etc. like business requirements. >
ID PRIORITY DESCRIPTION DEPENDENCIES COMMENTS

Document1 Page: 4 of 6
 BUSINESS REQUIREMENTS DOCUMENT (BRD)
< Project Name >

INTERFACE REQUIREMENTS
Normal Text

USE CASES
< Copy the Use Case table for each new Use Case >
USE CASE TITLE Enter New Student Application

Use Case ID UC01

Actor(s) Admissions Analyst

Description A new student is applying for admission.

Used by Evaluate new student application (UC02)

Preconditions 1) A new student must be submitting an application for admission.

2) Master student database must be available.
3) Previous admissions application database must be available.

Postconditions Admissions application can be complete, incomplete or cancelled.

Trigger
Primary Case Steps Step No. Actor Action System Response
1
2
3

Extensions Step No.

Exceptions Step No.

Comments

Document1 Page: 5 of 6
 BUSINESS REQUIREMENTS DOCUMENT (BRD)
< Project Name >

ASSUMPTIONS

< List any assumptions about the requirements here>

CONSTRAINTS

< List any constraints on the requirements here>

DOCUMENT CONTROL
Document Version
Version Date Author Change
1.0 05-Dec-2013

Document Approval
This plan is approved by the persons named below. Signatures are on file.
Title Name Approval Date
Executive Director 01-Jan-2014
Project Sponsor 01-Jan-2014
Functional Department Head 01-Jan-2014
Functional SME(s) providing requirements 01-Jan-2014

Document Change Control

< Revise the paragraph below as appropriate for this document >
This document is under the control of the Project Manager. Change requests or updates are
submitted to the Project Manager for consideration. The approvers listed above will consider
and approve document revisions.

References
< Enter all and only documents that are actually referenced in the text of this document >
 OM-STD-003 – Standard Definitions and Acronyms


Document1 Page: 6 of 6