Template
Business Requirements
Document (BRD)
For [insert Project Name here]
Prepared by:
|
|
Prepared for:
|
|
Date submitted:
|
|
Project Sponsor:
|
|
Client Acceptor:
|
|
Project Manager:
|
|
Business Analyst:
|
|
Filename:
|
Document2
|
Document Number
|
|
Last Edit:
|
2/1/20XX 4:15:00 PM by
|
Comments:
|
Table of Contents
Section Zero: Positioning of the Business
Requirements Document ....5
The Goal: Common Understanding Through
Structured Business Analysis and a Standard Business Requirements
Document................................5
A Word of Caution about Removing/Adding
Sections
Different Types of Requirements................................................................. 6
Prioritizing Requirements............................................................................ 6
Section One: Glossary................................................................................. 7
Section Two: Project Scope and Objectives Summary................................. 8
Section Three: Technology Infrastructure and
Information Architecture Compliance 9
Section Four: Intended Audience.............................................................. 10
Section Five: Decision Making and Approval Process
for the Business Requirements Document 11
Section Six: Approach............................................................................... 12
Section 6.1 – Overall Project Management
Approach........................... 12
Section 6.2 – Business Analysis Approach................................................ 12
Section Seven: Background, Historical and Prior
Project Information......... 13
Section Eight: Business-Level Requirements: Goals, Value Proposition and Benefits 14
Section 8.1 – Regulatory Requirements.................................................... 14
Section 8.2 – Related Strategic Goals (Organization
Level).................... 14
Section 8.3 – Related Tactical Goals (Division
Or Department Level)...... 14
Section 8.4 – Related Operational Goals (Staff
Level)............................. 14
Section Nine: User Class Profiles and Key Delegations............................... 16
Section 9.1 – Sponsors and Stakeholders................................................ 16
Section 9.2 – Primary Users....................................................................... 16
Section 9.3 – Secondary Users................................................................. 16
Section Ten: User and Functional Level Requirements................................ 18
Section Eleven: Additional Information Regarding
Functional Requirements Related to Output and Reporting 19
Section Twelve: Conceptual Data Model................................................... 20
Section Thirteen: Nonfunctional
Requirements............................................ 21
Section 13.1 – Operational Environment................................................. 21
Section 13.2 – User Interface Requirements.............................................. 21
Section 13.3 – User Access/Security
Requirements................................... 21
Section 13.4 – Service Level/Performance / Capacity
Requirements...... 21
Section 13.5 – Data Requirements (Input,
Correlative)............................ 22
Section 13.6 – Business Continuity And Recovery
Requirements.............. 22
Section 13.7 – Integration/Migration Requirements................................. 23
Section 13.8 – Administrative/Backup / Archive
Requirements............... 23
Section 13.9 – Expected Life Span
Requirements..................................... 23
Section 13.10 – Documentation Requirements........................................ 24
Section 13.11 – Training Requirements..................................................... 24
Section 13.12 – Other Nonfunctional Requirements................................. 25
Section Fourteen: Assumptions,
Dependencies and Constraints............... 25
Section 14.1 – Assumptions...................................................................... 26
Section 14.2 – Dependencies.................................................................. 26
Section 14.3 – Constraints........................................................................ 26
Section Fifteen: Risks and Risk Management Process................................ 27
Section Sixteen: Solution Options............................................................... 30
Section 16.1 – Short List Solution Options................................................. 30
Section 16.2 – Information Regarding Pilot.............................................. 30
Section 16.3 – Rejected Solution Options................................................ 31
Section Seventeen: Change Management Process................................... 32
Section Eighteen: Business Requirements Document Revision Log............. 33
Section Nineteen: Appendices.................................................................. 34
Section Twenty: Approval.......................................................................... 35
Section Zero: Positioning of the Business Requirements
Document
The Goal:
Common Understanding Through Structured Business Analysis and a Standard
Business Requirements Document
The
Business Requirements Document is a major deliverable representing the
achievement of the Business Analysis milestone in a typical project management
methodology. As such it requires formal review and sign off by the Client
Acceptor (representing the interests of business area stakeholders). Under
normal circumstances, the Business Requirements Document is created by the
Senior Business Analyst delegated to a project.
This
Business Requirements Document template conforms to industry best practices in
business analysis, and is the primary tool for structuring requirements
gathering activities. Interim feedback loops and approvals for Business Requirements
Document sections are achieved in an iterative manner, as requirements become
clear over successive meetings with project stakeholders, primary and secondary
users. This facilitates the final review and approval of the overall document,
which by then will contain “no surprises”.
A Word of Caution about Removing/Adding
Sections
Do
not arbitrarily add or remove sections within your Business Requirements
Document. To do so raises the risk of diluting the standard, as future teams
may look to your documents for guidance in building their own reports. That
being said, please use the following guidelines.
Adding Sections – While all project Business
Requirements Documents begin with the standard template sections, the unique
nature of each project may require additional sections and information. These
are organized as Appendices.
Removing Sections – Since the Business Requirements
Document template has been designed as a comprehensive study, removal of
specific sections of the standard template is not recommended. Doing so
represents requirements detail that will not be covered, and therefore can
create project risk. Whoever authorizes removal of standard sections is accountable
for ownership of that risk, and any consequences that emerge as a result. This
is a key point that must be understood by all members of the project team.
Document the sections that have been removed, and under whose direction, within
the Risk section of the Business Requirements Document.
Final Note – Balance brevity with completeness,
quality with quantity. You cannot document everything down to the tiniest
details and thereby eliminate all project risk. The Project Sponsor needs to
have sufficient understanding to create an Acceptable Level of Risk in
proceeding. This will vary based on project importance and urgency, as well as
the business environment within which your project lives.
Different Types of Requirements
Functional
requirements can only be derived following elicitation and documentation of
business and user requirements. The distinctions between these different
requirements levels are important.
1.
Business
Requirements – place the business at the center of focus, and tie the project
to documented regulatory, strategic, tactical and operational goals. If you are
developing products or services for sale, customer requirements will also need
to be documented. Customer requirements are covered off at a high level in this
section, then in detail under User Requirements.
2.
User
Requirements – place the user at the center of focus, and describe, with
Flowcharts, Use Case Diagrams, Use Case Scenarios, Line of Vision and other
process models, the “to be” user experience with the new system. In some cases,
especially where business processes are being modified, it may also be necessary
to document the “as is” state of user experience with the current system.
3.
Functional
Requirements – place the proposed system at the center of focus, and provide a
prioritized list of capabilities the system must demonstrate in order to
satisfy business and user requirements.
4.
Non-Functional
Requirements – refer to needs that must be fulfilled related to things like the
user interface, access security, availability, robustness, system failure,
integration, migration and documentation. As such, they do not deal with the
actual functionality of the system, but represent key project success factors
nevertheless.
Prioritizing Requirements
Ensure
that your users are aware of the following interpretations regarding the
prioritization of requirements:
§ Must Have – will be included in
this release. These items represent core functionality and must be present.
Absence of any Must Have functionality represents project failure.
§ Should Have – will be included in
this release provided all Must Have requirements have been met and sufficient
project resources and time remain.
§ Nice to Have – will be included in
this release provided all Must Have and Should Have requirements have been met
and sufficient project resources and time remain.
Section One: Glossary
Term
|
Definition
|
This section identifies any
industry or line of business jargon, acronyms, common words used in special
context, and special terms that are used within the project and the Business
Requirements Document itself. Pay particular
attention to acronyms that may have multiple meanings: a commonly used one and
a meaning that has special significance to the business area. For example, the acronym PMO is an
industry-wide acronym for Project Management Office. It may also stand for
Prime Minister’s Office or Preventive Maintenance Optimization. The project and business context determine the
meaning.
Section
Two: Project Scope and Objectives
Summary
Scope:
·
Main
body of Scope statement
·
Exception
/ Exclusions to the scope.
|
Project Objectives:
·
·
·
·
·
·
|
·
Is
there a vision associated with this work?
·
What is
the high level objective?
·
What
business area is the project for?
·
Does
the project cross into other areas?
·
What
are we trying to accomplish?
·
Why
does it make sense to do this work?
·
What is
the expected timeframe? Best case ? worst case?
·
What
will the deliverables look like?
·
What
would a successful project look like?
·
Who is
likely to be the sponsor?
·
What
potential hurdles may there be?
·
Are
there any metrics or measures?
·
What is
the business reason for doing this work?
·
Will
this work be a stand alone system or a component in a bigger system?
·
What
are the potential benefits of this work?
·
Who is
the customer?
·
What is
not included in the scope?
Section Three: Technology Infrastructure and
Information Architecture Compliance
Technology / Architectural component
|
Compliance
|
·
On what
platform will this application reside?
·
Is
there any history as to why this application exists?
·
Will
the existing infrastructure support this work?
·
Is this
work in line with our technology standards?
It
is important that all project initiatives and their requirements comply with
existing technology standards. Use this section to position this project within
that framework. Remember that specific technologies are not normally a part of
requirements. If presented as such, they often become constraints. For example,
a user might state “the solution must use a Microsoft SQL Serverâ database”. Since this might be a
violation of the approved information architecture and technology
infrastructure of your company, you must verify compatibility, documenting any
variance here. Note also that the only reason the existing infrastructure
exists is that some prior project with a strong enough business case pushed the
envelope. Your project may do the same.
Do
not prejudge approval or disapproval of technology constraints that are
presented as requirements. Simply raise the red flag, providing information to
support a decision. However, if the decision is made during business analysis
activities, document both the requirement and the decision here, indicating
parties involved and when the decision was made. Don’t lose the history.
Section Four: Intended Audience
Person
|
Position
|
Telephone
|
·
Who
will be the readers of this BRD?
·
Who
will be responsible for approving this BRD?
·
What
are their organizational titles?
·
What
are their roles?
·
Is an
org chart available?
Both readers and approvers of the
Business Requirements Document are identified here. Organizational titles and
functional project roles for each individual are included. An organizational
chart is very helpful in complex reader / approver environments.
Section
Five: Decision Making and Approval Process for
the Business Requirements Document
Decision
Making Process
|
·
·
·
·
·
·
·
|
Approval
Process
|
·
·
·
·
·
·
·
·
|
·
Who are
the key stakeholders?
·
What
are their titles?
·
Who
will provide interim approval?
·
Who is
the single client acceptor?
·
Are
there any cultural issues to be aware of?
·
Are
there any personality issues to be aware of?
·
Is
there any reason this project would get resistance? If so, from who?
In some cases, projects will have a
number of key stakeholders who must discuss and provide interim approval for
all or for specific sections of the Business Requirements Document. However,
there must always be a single Client Acceptor who will ultimately approve the
document, representing the requirements viewpoint of the business area
addressed by the project.
Within project management and
business analysis, the identification of the Client Acceptor is a key
delegation. The delegation of Client Acceptor may be awarded to the same
individual who serves as Business Area Project Sponsor.
Pay particular attention to cultural
or behavioral norms within the
organization that may affect the decision making process. This includes standard intervals for getting
together (the monthly meeting), and the in-place approval and conflict
resolution approach of the group.
Section
Six: Approach
This
section describes:
Section 6.1 – Overall Project
Management Approach
·
Projects are
managed in accordance with industry best practices, following the disciple of
the PMI model of proper project management.
·
Each project has
a well defined project plan which is managed from initiation to closure.
·
Outside
resources, vendors and subcontractors are managed as an additional resource
to the project plan.
·
Project
management approach follows the knowledge areas of the PMBOK.
·
x
·
x
·
x
·
|
Section
6.2 – Business Analysis Approach
·
The BA will
serve as the liaison among stakeholders to elicit, analyze, communicate and
validate requirements.
·
The BA helps
understand business problems and opportunities and recommends solutions that
enable the business to achieve its goals and objectives.
·
The BA will
utilize the most appropriate means of gathering business requirements and
assimilating those into system requirements.
·
Business
Analysis approach follows the knowledge areas of the BABOK.
·
x
·
x
·
x
|
Section
Seven: Background, Historical, and Prior
Project Information
Projects
exist as development or sustainment efforts within the Product Life Cycle of
systems and solution applications. Use this section to document the positioning
of your project within that context. Diagrams are often helpful here.
Background
|
·
x
·
X
·
X
·
X
·
x
|
History
|
·
x
·
x
·
x
·
x
|
Prior Projects
|
·
x
·
x
·
x
·
x
·
x
|
·
Have
there been any previous efforts to accomplish this work?
·
Was
there a previous project?
o
If so,
are there records of it? (diagrams, documentation, etc)
o
If so,
who was involved?
·
Is
there any historical info that would be helpful?
·
Are
there any other projects that are related to this work?
Section
Eight: Business-Level Requirements:
Goals, Value Proposition, and Benefits
All
project initiatives exist within the organizational context of your company and
consume organizational resources. As such, they must be justified by tying them
to strategic, tactical and operational goals. In some cases, there may also be
regulatory governance considerations that must be taken into account. When
present, regulatory requirements are documented first. Documenting business
level requirements is a critical exercise, because:
Section 8.1 – Regulatory
Requirements
ID
|
Regulation / Policy
|
8.1.1
|
|
8.1.2
|
|
8.1.3
|
|
·
Are
there any regulator requirements that relate to this project?
o
If so,
can we identify them?
o
Is
there any date/time sensitive requirements?
Section
8.2 – Requirements relating to Strategic Goals (Organization Level)
ID
|
Description
|
8.2.1
|
|
8.2.2
|
|
Section 8.3 – Related Tactical
Goals
(Division or Department Level)
ID
|
Description
|
8.3.1
|
|
8.3.2
|
|
Section
8.4 – Related Operational Goals (Staff Level)
ID
|
Description
|
8.4.1
|
|
8.4.2
|
|
Section
Nine: User Class Profiles and Key Delegations
Users
are categorized by functional groups, then by job titles as appropriate. Actual
names of key individuals are supplied. The following groups are identified and
described:
Section 9.1 – Sponsors and
Stakeholders
Name
|
Position
|
Sponsor
|
Stakeholder
|
Section
9.2 – Primary Users
Name
|
Position
|
Section
9.3 – Secondary Users
Section
Ten: User and Functional Level
Requirements
Ranking = M-Mandatory; D-Desirable; F- Future
ID
|
Requirement
|
Rank
|
||
M
|
D
|
F
|
||
10.1
|
·
|
|||
10.2
|
·
|
|||
10.3
|
·
|
|||
10.4
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
What
are the end user expectations?
·
What
are the “must haves”?
·
What
are the “should haves”?
·
What
are the “nice to haves”?
·
Are
there stages of completion?
·
What
are the key deliverables at each stage?
·
Can the
current process be graphically depicted?
·
Is
there a user wish list?
This section provides detailed user
and functional requirements information through text and process modeling. Your
company will have standard tools that have been approved for use. These may
include:
Clear description of functional
requirements defines success factors for the project. As such, functional
requirements are closely tied to the project’s Quality Plan. It is critical to
understand that Quality is conformance to documented and approved requirements
and specifications. It is therefore not the same as Excellence or Perfection.
Excellence is a moving target representing the highest level of quality
achievable within the timeframe of the project. Perfection is zero defects. In
addition, quality has a cost expressed as follows:
Cost
of Quality = Cost of Conformance + Cost
of Non-conformance
Non-conformance of deliverables is
frequently tied to insufficient levels of detail in the documentation of
requirements. In light of this, the real focus of the Business Requirements
Document can be expressed as the establishment of project quality standards for
project deliverables. An overall focus on the identification, definition,
elicitation and documentation of quantitative measures versus qualitative
descriptions is a key element of functional requirement definition. You may
begin your descriptions using qualitative language such as “improved” or
“faster”, but follow this with actual metrics.
Section
Eleven: Additional Information Regarding
Functional Requirements Related to Output and Reporting
ID
|
Requirement
|
Rank
|
||
M
|
D
|
F
|
||
11.1
|
·
|
|||
11.2
|
·
|
|||
11.3
|
·
|
|||
11.4
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
Are
there any special reports needed?
·
Are
there any special queries?
·
Are
there management requirements?
·
Are
there scheduled operations?
·
Are
there repeated or sequenced operations?
·
Are
there key business rules that need documenting?
·
Who
gets the information that is generated?
·
Is this
info needed by a certain timeframe ? weekly? monthly? yearly?
This
section describes the requirements of primary and secondary users related to
screen, transmitted, and hardcopy output from the proposed system. This
includes but is not limited to:
Also
included here are:
Section
Twelve: Conceptual Data Model
This
is a very high level, requirements oriented set of diagrams that will be
elaborated upon by database analyst personnel during solution design. This
section may be limited to simply identifying database systems and their
interactions with project applications. Alternatively, it may include actual
database schema diagrams and descriptions. The amount of detail will vary by
project and company policy.
Enter
content here.
Section
Thirteen: Nonfunctional Requirements
This
section documents requirements that are not directly related to the
functionality of the proposed system.
Like functional requirements, the clear, quantitative definition of
these requirements feeds the project’s Quality Plan. Please be conscientious in
your investigation of non-functional requirements, as these are often
overlooked or given insufficient attention.
Section 13.1 – Operational
Environment
ID
|
Requirement
|
Rank
|
||
M
|
D
|
F
|
||
13.1.1
|
·
|
|||
13.1.2
|
·
|
|||
13.1.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section 13.2 – User Interface
Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.2.1
|
·
|
|||
13.2.2
|
·
|
|||
13.2.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.3 – User Access / Security Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.3.1
|
·
|
|||
13.3.2
|
·
|
|||
13.3.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.4 – Service Level / Performance / Capacity Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.4.1
|
·
|
|||
13.4.2
|
·
|
|||
13.4.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.5 – Data Requirements (input, correlative)
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.5.1
|
·
|
|||
13.5.2
|
·
|
|||
13.5.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section 13.6 – Business Continuity
and Recovery Requirements
ID
|
Requirement
|
Rank
|
||
M
|
D
|
F
|
||
13.6.1
|
·
|
|||
13.6.2
|
·
|
|||
13.6.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.7 – Integration / Migration Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.7.1
|
·
|
|||
13.7.2
|
·
|
|||
13.7.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section 13.8 – Administrative /
Backup / Archive Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.8.1
|
·
|
|||
13.8.2
|
·
|
|||
13.8.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.9 – Expected Life Span Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.9.1
|
·
|
|||
13.9.2
|
·
|
|||
13.9.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.10 – Documentation Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.10.1
|
·
|
|||
13.10.2
|
·
|
|||
13.10.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.11 – Training Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.11.1
|
·
|
|||
13.11.2
|
·
|
|||
13.11.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
13.12 – Other Non-functional Requirements
Requirement
|
Rank
|
|||
M
|
D
|
F
|
||
13.12.1
|
·
|
|||
13.12.2
|
·
|
|||
13.12.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section Fourteen:
Assumptions, Dependencies, and Constraints
Assumptions: All projects operate in a
less-than-perfect world. Not everything can be officially verified as existing
or available ahead of time. These “unknowns” are documented in project
assumptions. An example might be “The project assumes the continued
availability of funding following the upcoming merger”.
Dependencies include, but are not limited to
the availability of project resources, applications and systems that interact
with this one, hardware, facilities, equipment, business processes and
regulatory approvals. Of particular importance is the dependency on the
availability of project stakeholders and users, and conformance to approval and
change management processes.
Constraints are those regulatory,
technological or business realities that legitimately constrain solution
development. An example might be “The new system must be built in Oracle” ™.
Although this example might sound, on the surface, like a specification (and
therefore not part of a Business Requirements Document) it becomes a
constraining requirement when stated up front. It is for this reason that users
must be cautioned against careless statement of constraints.
In
essence, this section allows you to document that which cannot be ascertained
in advance. These items may feed the Risks and Risk Management section, which
follows.
Section 14.1 – Assumptions
Uncertainty Ranking = H- High level of
uncertainty
M-Medium level of uncertainty
L-
Low level of uncertainty
Assumptions
|
Uncertainty
|
|||
H
|
M
|
L
|
||
14.1.1
|
·
|
|||
14.1.2
|
·
|
|||
14.1.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
14.2 – Dependencies
Dependencies
|
Uncertainty
|
|||
H
|
M
|
L
|
||
14.2.1
|
·
|
|||
14.2.2
|
·
|
|||
14.2.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section
14.3 – Constraints
Assumptions
|
Uncertainty
|
|||
H
|
M
|
L
|
||
14.3.1
|
·
|
|||
14.3.2
|
·
|
|||
14.3.3
|
·
|
|||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
·
|
||||
Section Fifteen: Risks and Risk Management Process
1=Low 5=Medium 10=High
ID
|
Item
|
Likelihood
of
occurrence
|
Business
Impact
|
Score
A*B
|
15.1
|
||||
15.2
|
||||
15.3
|
||||
Section
Sixteen: Solution Options
As
a business analysis vehicle, the Business Requirements Document focuses on
requirements, not specifications nor solutions. Nevertheless, as requirements
are elicited and documented, discussion around solution options will occur.
This section is used to document those options which have been considered to
date, rejected, or approved for further investigation. It is important to
include rejected entries for the historical record of the project, and to
pre-empt future readers who may ask “did they consider such-and-such?”.
Remember
that solution options must be derived based on clear understanding of project
requirements, assumptions, dependencies and constraints.
Section 16.1 – Short List Solution
Options
ID
|
Solution Options
|
16.1.1
|
· |
16.1.2
|
· |
16.1.3
|
· |
· |
|
· |
|
· |
|
· |
Section
16.2 – Information Regarding Pilot
ID
|
Solution Options
|
16.2.1
|
· |
16.2.2
|
· |
16.2.3
|
· |
· |
|
· |
|
· |
|
· |
Note:
this section is included only if a pilot has, in fact, been proposed. It will cover the specific target user
groups, subset of requirements to be addressed, funding, timing and key
personnel required. Do not use this section as a project plan for a pilot,
although it will identify the pilot’s key personnel.
Section
16.3 – Rejected Solution Options
ID
|
Solution Options
|
16.3.1
|
· |
16.3.2
|
· |
16.3.3
|
· |
· |
|
· |
|
· |
|
· |
Section
Seventeen: Change Management Process
Since
business analysis activities are exploratory and iterative up to the approval
of the Business Requirements Document, it is likely that some requirements will
evolve throughout the process. This consumes project resources and so must be
governed by change management. For example, a requirement that takes one day to
elicit, document and approve, but that changes 30 times during business
analysis will consume 30 project days worth of appropriate resources.
This
section provides information, normally documented in official policy, regarding
the change management process to be used for this project. It also includes
details regarding any additional change management that must be applied due to
the special needs or unique nature of this project.
If
there is an official change management policy that is documented elsewhere
(such as in the Project Plan), you may simply reference it here.
Enter
content here.
Section
Eighteen: Business Requirements Document
Revision Log
This section documents requirements
that have changed over the course of successive documentation iterations during
business analysis activities. Pay particular attention to requirements with
ongoing adjustment. These are high risk areas that may represent:
If you find that a majority of must
have requirements cannot be nailed down, you may have a situation where the
project itself must be reassessed at a scope level.
Rev
|
Date
|
Change
Description
|
Author
|
0
|
Initial Release
|
||
Section
Nineteen: Appendices
Appendix
A – Comprehensive Requirements Listing
Type Key B=Business; U=User; F=Functional;
N=Non functional; R=Reporting
Req. ID
|
Requirement
|
Req. Type
|
Req.
Priority
|
Section Twenty: Approval
This
section documents the approvals required for sign off of the Business
Requirements Document and establishment of the Requirements Analysis milestone.
Each signatory is described by both organizational title and project functional
role. Required signatories are the Business Analyst and the Client Acceptor.
Other signatories may be required by your company policy.
This
document has been approved as the official Business Requirements Document for
the [name of project] project, and accurately reflects the current
understanding of business requirements. Following approval of this document,
requirements changes will be governed by the project’s change management
process, including impact analysis, appropriate reviews and approvals, under
the general control of the Project Plan and according to company policy.
Prepared
by
|
|
________________________________________
|
________________
|
Business Analyst
|
Date
|
Approved
by
|
|
________________________________________
|
________________
|
Client Acceptor
|
Date
|
No comments:
Post a Comment