Business Requirement Specification

Business Requirement Specification

Business Retirement Specification Template

 

<enter project name>

Business Requirements Document

 

Document Instructions

<This document template contains directions for use or sample entries. These directions are enclosed in brackets  and are italicized. They are included to help you fill out the form. As you complete the form, delete these instructions.

Please follow this document naming convention to facilitate document search and retrieval:

 <project code (if appropriate)>  <project name (abbreviated)>  <document name (abbreviated)>  <version (if appropriate)>

 All documents should be posted to the appropriate project folder in SharePoint. >

Document History

<The document history is a log of changes that are made to the document, who made the changes, and when.  For example, the initial creation of the document may contain the following:  Version 0.1, Date 1/1/2004, Author Charlie Brown, Status Initial creation.  Subsequent updates to the document will be Version 0.2, 0.3, etc.  The first published version of the document should be Version 1.0.>

Version Date Author Status Section Revision Description
0.1 Initial Draft
1 First Published

Approvals

 <The required approvals for this document are outlined in the project Change Management Plan. SharePoint workflow approvals may be used In lieu of this Approval section. If utilizing SharePoint, attach this document to the Change Request list item. If utilizing the document, distribute the document and request electronic signatures to indicate approval.

Copy additional signature line and details as needed>

 Your signature below indicates that this document meets its objectives and is acceptable.

Signature Signature
<Name> <Name>
<Date> <Date>
<Title> <Title>
<Role> <Role>

 

Table of Contents

1.Purpose

2 .Glossary and Acronyms

3. Executive Summary

3.1. Background

3.2.Objectives

3.3.In Scope

3.4. Out of Scope

4 . Requirements Elicitation and Gathering

4.1. Approach Overview

4.2. References/Inputs

5. Business Model

5.1. Organizational Profile

5.2. High Level ‘As-Is’ Process Flow

5.3. High Level ‘To-Be’ Process Flow

5.4. Process Mapping

5.5. Gap Analysis.

6. Requirements Definition

7. Appendix

———————————-****************___________________

Now I am going to discuss about each paragraph in detail.

1.Purpose

The purpose of the Business Requirements Document (BRD) is to lay the foundation for the design and development of a technical solution through definition of the business’ needs and achieve the goals and objectives of the <enter project name> project. The BRD describes the high-level business process and outlines the business needs that will be fulfilled by the successful completion of the project. In combination with the Requirements Traceability Matrix (RTM), it identifies actual technical or system requirements for the solution.

The foundation for a successful project is built upon the quality and thoroughness of requirements gathering. The BRD establishes key requirements, objectives, and goals that drive all other subsequent lifecycle phases. The RTM describes the business problem to be solved in terms of verifiable and traceable characteristics and constraints. In addition to key program level requirements, the requirements capture operational concepts and program level interfaces. The RTM should be continuously referenced during the project lifecycle phases to ensure that the deliverables from the project meet the approved requirements.

Signoff requirements of the BRD, inclusive of the RTM, are defined in the project’s Change Management Plan. Approval by the project sponsor ensures the requirements will support achieving the project’s goals and objectives.

2. Glossary and Acronyms

<A general list of common terms and acronyms are listed. Provide any project-specific terms or acronyms that may be used within this document; remove any that do not apply.>

Table: Terms and Acronyms Used in This Document

ALS Ambulance Licensure Service
BIIT Bureau of Informatics & Information Technology
BEMS Bureau of Emergency Medical Services
BRD Business Requirements Document – Details the business solution for a project including the documentation of customer needs and expectations.

<If a project charter does not exist, this section is intended to provide a brief, one-page summary describing the purpose, background, objectives, and scope for the overall project. Sign-off of the document provides a foundation for the project team and base criteria for decision-making, prioritization, and issue resolution.

3. Executive Summary

 Delete this section if the project has an approved charter.>

[Enter the Executive Summary text here]

3.1. Background

<Provide high-level description of the problem/opportunity which originated the project.>

[Add text here].

3.2 .Objectives

<List top 3-5 objectives, including success criteria/measurements>

[Add text here].

3.3. In Scope

<List top processes, features, and/or functions addressed by the project>

[Add text here].

3.4. Out of Scope

<List top processes, features, and/or functions NOT addressed by the project>

[Add text here].

4. Requirements Elicitation and Gathering

4.1. Approach Overview

< In this section, provide a summary describing the approach, methods, and documentation of the business requirements, including: project drivers, key project stakeholders, main functions that will be performed by the system, and a general requirements documentation timeline.>

[Add text here].

4.2.References/Inputs

<Identify the sources of information/reference materials that were used to develop the Requirements Plan, such as:

  1. Author name, title, and publication date.2. Author name, title, and publication date.>

[Add text here].

5.Business Model

<Describe the current environment in detail to help identify and support the needs and goals described in the previous section.  Consider the following list of questions to help define the current environment

  • What are the current problems faced (without the system) today?
  • What problems should this system solve?
  • Do you have to do things manually that you would like to automate?
  • Do you have performance problems that need to change?
  • Do you have functional limitations that you would like to change?
  • Are you using packages that force you to constrain your business functionality to the boundaries of the package?>

[Add text here].

5.1. Organizational Profile

<Describe the organizational entities (program area, bureau, etc.) that are involved in or will be affected by the system being developed or modified. At a minimum, answer these questions: Who (including titles and roles) will be using the system? What are their levels of expertise?>

[Add text here].

 5.2 . High Level ‘As-Is’ Process Flow

<A high level process flow depicts pictorially the business function information.  It can be a valuable tool when explaining to others the business functions of a system. A process flow can illustrate the following elements: What elements are in place when the process is initiated? Who is responsible for initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is the recipient of the process outputs? What procedural steps are completed during the process? What are the exit criteria of the process (i.e., what must be satisfied before the process ends?  This information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow diagram here].

 5.3.High Level ‘To-Be’ Process Flow

<This section should include an introduction describing the major functional areas of the system from users’ perspectives.  If the new system has been segmented into subsystems, the functional requirements are defined by subsystems.  The project team defines, by subsystems, those functions which the new system must perform in order to achieve the objectives and realize the benefits >

 <A high level process flow depicts pictorially the business function information.  It can be a valuable tool when explaining to others the business functions of a system. A process flow can illustrate the following elements: What elements are in place when the process is initiated? Who is responsible for initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is the recipient of the process outputs? What procedural steps are completed during the process? What are the exit criteria of the process (i.e., what must be satisfied before the process ends?  This information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow graphic here.

 5.4      Process Mapping

<Processing Mapping allows the reader to quickly see how the current functions will be addressed by the proposed solution.  This can be done in narrative form or can be depicted in a table format.  This method is especially useful if there are multiple system modules or multiple systems within a solution.

[Add text or table here]

5.5. Gap Analysis

<A gap analysis compares the ‘as-is’ and ‘to-be’ processes and identifies which functional areas may not be fully addressed by the solution.  Recommended mitigating strategies and/or business process redesign should also be included.>

[Add text here]

6. Requirements Definition

To ensure traceability throughout the project lifecycle and adherence to the change management process, each detailed requirement for the project is defined within the RTM.

Requirements usually reflect a need from the business/program area and is a condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document. Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer or other stakeholder. A requirement may include technical components if there is a specific business need associated with a technology platform, approach, or solution.

<Please refer to the PMM templates to access the RTM tool.  Please delete the descriptive text and insert a link to the RTM or embed the document here.>

7 . Appendix

<In this section add any additional information relevant to this document’s subject matter. >

[Enter text here]

 

Basource

1 comment so far

BRS VS SRS VS FRS Posted on10:18 am - Oct 18, 2018

[…] To Know about BRS template Click Here  […]