Business REquirement document to be used in projects

Business Requirements Document
(Guide S50 Version 1.0)
for
<PROJECT NAME>
<Version #>
Prepared for
British Columbia Ministry of Forests & Range
<Business Area>
<Date>
Prepared by
<Name/Organization>
<Contact Details>

<This page is intentionally left blank.>
1.1
XXX Project – Business Requirements Document v. #
BC Ministry of Forests and Range
Date Page i

About This Document: THE FOLLOWING TWO PAGES ARE NOT TO BE INCLUDED IN
DOCUMENT
This document is the accepted template for the Ministry of Forest & Range (MFR) Business
Requirements Document (BRD) which is part of the Systems Development Life Cycle (SDLC)
framework Analysis phase. The document output represents ‘best practices’ for Business
Analysis within the Information Management Branch (IMB).
All parties engaged to perform business analysis and BRD deliverables for MFR information
systems development are instructed to follow and conform to the standards outlined in this
document. This fact must be specified in the RFP and contract particulars.
BRD Definition:
The Business Requirements Document is an approved requirements document that describes
all facets of regulatory, business, user, functional, non-functional and transitory requirements.
It provides insight into both the ‘as-is’ and ‘to-be’ states of the business area. The BRD is
written for a user audience, describing user needs and the impact of the anticipated changes on
the user community. The structured set of prioritised and validated requirements must be user
approved and maintained in order to meet the core business needs. Requirements are
commonly modelled using techniques such as business, process, data and workflow models.
The BRD represents the ‘what’ for proposed business requirements for implementation and
becomes the performance baseline of the sponsoring program. The performance of the
solution post implementation will be measured against the signed off business requirements to
determine the value delivered and to identify opportunities for improvement.
Green text enclosed in angle brackets <> are information comments that would not be included
in an actual BRD. Black text comments enclosed in angle brackets <> may be included in an
actual BRD.
SDLC and BRD Right-sizing
[] Simple [] Intermediate [] Complex
The BRD deliverable will require synchronising with the SDLC project right sizing calculator.
Projects that have greater or lesser complexity will need to adjust business analysis content
accordingly. The BRD Table of Contents reflects the current base content for all projects and
there could be some systems/applications where some sections may not apply. However each
section must be included in the requirements document and in these cases, the document must
contain an appropriate statement indicating that this section does not apply. Other pertinent
BA content not listed in the table of contents can be included as the discretion of the writer.
Future BRD review could indicate refinement to mandatory or optional statements for simple,
intermediate or complex projects.
Different Types of Requirements:
Date Page ii

As defined from the Business Analysis Body of Knowledge- BABOK v2.0
1. Business Requirements – place the business at the centre of focus, and tie the project to
documented regulatory, strategic, tactical and operational goals through Enterprise Analysis.
Customer requirements are covered at a high level in this section, then in detail under User
Requirements.
2. User Requirements – place the user at the centre of focus, and describe the "to be" user
experience with the new system, using Flowcharts, Use Case Diagrams, Use Case Scenarios,
Line of Vision and other process models. 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 centre 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 in relation 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.
5. Transition Requirements- temporary capabilities that the solution must have in order to
facilitate transition from the current enterprise state to the desired future state, but will not be
needed once the transition is completed. Both old and new systems may run in parallel. They
are not defined until a solution has been designed.
Other related standards can be found on the Information Management Branch standards web
page https://extranet.for.gov.bc.ca/AppDev/Guides>
Date Page iii

Table of Contents
1. DOCUMENT REVISION LOG.........................................................................................................................1
2. DOCUMENT REVIEWERS.............................................................................................................................1
3. APPROVER & SIGNOFF...............................................................................................................................1
4. INTRODUCTION (ANALYSIS DESCRIPTION)..................................................................................................3
4.1 DOCUMENT PURPOSE....................................................................................................................................3
4.2 DOCUMENT SCOPE........................................................................................................................................3
4.3 DOCUMENT INTENDED AUDIENCE................................................................................................................4
4.4 BUSINESS ANALYSIS APPROACH....................................................................................................................4
4.5 REQUIREMENTS QUALITY ASSURANCE..........................................................................................................5
4.6 INFORMATION REFERENCES..........................................................................................................................5
4.7 DEFINITIONS, ABBREVIATIONS & ACRONYMS...............................................................................................6
5. BUSINESS REQUIREMENTS (OPPORTUNITY)................................................................................................7
5.1 PROJECT BACKGROUND.................................................................................................................................7
5.2 SCOPE STATEMENT........................................................................................................................................7
5.3 BUSINESS REQUIREMENTS PURPOSE.............................................................................................................7
5.4 BUSINESS CONTEXT DIAGRAM.......................................................................................................................7
5.5 BUSINESS OBJECTIVES & BENEFITS SUMMARY..............................................................................................9
5.6 BUSINESS DRIVERS/ISSUES............................................................................................................................9
5.7 DEPENDENCIES..............................................................................................................................................9
5.8 ASSUMPTIONS...............................................................................................................................................9
5.9 CONSTRAINTS/RESTRICTIONS......................................................................................................................10
5.10 BUSINESS TRANSACTION VOLUMES........................................................................................................10
5.11 REGULATORY CONSIDERATIONS.............................................................................................................10
5.12 PRIVACY IMPACT ASSESSMENT – REFER TO COMPLETED PIA.......................................................................10
5.13 RECORDS IMPACT ASSESSMENT – REFER TO COMPLETED RIA......................................................................11
5.14 OPEN ISSUES...........................................................................................................................................11
6. USER REQUIREMENTS (NEEDS).................................................................................................................12
6.1 USE CASE OVERVIEW...................................................................................................................................12
6.2 BUSINESS PROCESS MODEL.........................................................................................................................13
6.3 ACTOR PROFILES & LOCATIONS...................................................................................................................14
6.4 INPUTS.........................................................................................................................................................14
6.5 OUTPUTS.....................................................................................................................................................14
6.6 USER INTERFACE..........................................................................................................................................15
6.7 TRIGGERS.....................................................................................................................................................15
6.8 BUSINESS RULES..........................................................................................................................................15
6.9 FUNCTION HIERARCHY DIAGRAM & REPORT...............................................................................................16
6.10 DATA FLOW DIAGRAM............................................................................................................................17
7. FUNCTIONAL REQUIREMENTS (PRODUCT CAPABILITIES & BEHAVIOUR)....................................................18
7.1 OPERATIONAL ENVIRONMENT....................................................................................................................18
7.2 SYSTEM INTERFACE......................................................................................................................................18
7.3 COMMUNICATIONS INTERFACE...................................................................................................................18
7.4 SOFTWARE INTERFACE................................................................................................................................18
7.5 HARDWARE INTERFACE...............................................................................................................................18
Date Page iv

7.6 FUNCTION/USER SECURITY MATRIX............................................................................................................19
7.7 USER GROUP & SYSTEM ACCESS SUMMARY................................................................................................20
8. NON-FUNCTIONAL REQUIREMENTS (SUCCESS FACTORS)..........................................................................21
8.1 RESPONSE/ PERFORMANCE.........................................................................................................................21
8.2 CAPACITY.....................................................................................................................................................21
8.3 RELIABILITY..................................................................................................................................................21
8.4 OPERABILITY................................................................................................................................................21
8.5 MAINTAINABILITY........................................................................................................................................21
8.6 SCALABILITY.................................................................................................................................................21
8.7 AVAILABILITY................................................................................................................................................22
8.8 DELIVERY......................................................................................................................................................22
8.9 RECOVERY....................................................................................................................................................22
8.10 TRANSITION REQUIREMENTS..................................................................................................................22
9. DATA REQUIREMENTS (STRUCTURE)........................................................................................................23
9.1 LOGICAL DATA MODEL................................................................................................................................23
9.2 DATA CONVERSION REQUIREMENTS...........................................................................................................23
9.3 WAREHOUSING............................................................................................................................................23
9.4 DATA VOLUMES & SIZE................................................................................................................................23
9.5 DATA RETENTION/ARCHIVE/PURGE............................................................................................................23
10. ALL REQUIREMENTS LIST/TRACEABILITY MATRIX (REQUIREMENTS BASELINE)..........................................24
11. CONSIDERATIONS (PLANNING EFFORT)....................................................................................................26
11.1 PRELIMINARY DESIGN.............................................................................................................................26
11.2 WORK PLAN............................................................................................................................................26
11.3 RESOURCING...........................................................................................................................................26
11.4 COSTS......................................................................................................................................................26
11.5 DELIVERY REQUIREMENTS......................................................................................................................26
11.6 TEST STRATEGY.......................................................................................................................................26
11.7 IMPLEMENTATION PLAN.........................................................................................................................26
11.8 USER TRAINING.......................................................................................................................................26
11.9 SUPPORT.................................................................................................................................................27
11.10 SYSTEM MAINTENANCE AND OPERATIONS............................................................................................27
11.11 APPLICATION DEACTIVATION..................................................................................................................27
12. APPENDICES (SUPPORTING DOCUMENTATION)........................................................................................28
List of Tables
Table 1 Document Revision Log
Table 2 Document Reviewers
Table 3 Client Acceptor (Project Sponsor)
Table 4 Document Audience
Table 5 Information References
Table 6 Terms, Acronyms & Abbreviations
Table 7 Dependencies
Table 8 Assumptions
Date Page v

Table 9 Constraints/Restrictions
Table 10 Open Issues
Table 11 Actor Profiles & Locations
Table 12 Business Rules
Table 13 Function/User Security Matrix
Table 14 User Group & System Access Summary
List of Appendices
Appendix A: Business Context Diagram
Appendix B: Use Case Diagram
Appendix C: Business Process Map
Appendix D: Function Hierarchy Diagram
Appendix E: Data Flow Diagram
Appendix F: Logical Data Model
Appendix G: All Requirements List & Traceability Matrix
Date Page vi

1. DOCUMENT REVISION LOG
<Suggested numbering convention:
0 to 0.9 are for pre-Peer Review drafts; 1.0 is for an approved document from the Peer
Review (review can be from either MFR or Vendor community)
1.0 – 1.9 is for the IT oversight; 2.0 is for an IT Oversight approved document
2.1 – 2.9 is for Client reviews; 3.0 is for a Client-approved document
3.1 – 3.9 is an IMB approved document.
A BRD with a version number of 4.0 has been thoroughly reviewed and is ready for a
Statement of Work and/or Design Specification.>
Table 1 Document Revision Log
Date Author Version Reason for Change
2. DOCUMENT REVIEWERS
<The Document Reviewers provide comment and validate the structure and content of
the document for the purpose ensuring that key points of contact for the initiative have
input or review. The review may not necessarily be specific to the detail but may view
from context or presentation perspectives.>
Table 2 Document Reviewers
Name & Title Role Approval Date Version
3. APPROVER & SIGNOFF
<In some cases, projects will have a number of key stakeholders who must discuss and
provide interim approval for all, or specific sections of the BRD. However, there must
always be at least one 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 the key delegation. The delegation of Client Acceptor may be awarded to the
same individual who serves as Business Area Project Sponsor.>
Table 3 Client Acceptor (Project Sponsor)
Date Page 1

Name & Title Role Approval Date Version
Signature:
Date Page 2

4. INTRODUCTION (Analysis Description)
4.1 DOCUMENT PURPOSE
<This section describes the reasons and purpose of the BRD.>
<The purpose of the Business Requirements Document (BRD) is to present the
stakeholder requirements needs for <an application> completely, accurately and
unambiguously in a technology-independent manner. This information is captured and
written by the Business Analysis team during the project Analysis phase. Business
language is used to describe the requirements authored in this document and is the
definitive specification of the user requirements. The BRD is the primary input to the
design and development phases, and is the primary specification for User Acceptance.
This document is intended to be read by all responsible for the management of the
project development initiative including business users, user representatives and
sponsors, and other interested parties.>
4.2 DOCUMENT SCOPE
<This section describes the scope of the BRD.>
<As determined during the Analysis phase of the project, the scope of this document is
limited to describing the <Project> stakeholder business needs including stakeholder
categories (who, e.g. primary and secondary users), the business data relationship map
(what, e.g. data model), the event-response table (when, e.g. state diagrams), business
policies (why, e.g. business rules), and the process map (how, e.g. use cases). The
approved and signed version of this document will serve as the basis for subsequent
phases of the project.
This document intends to define and describe the:
 Business requirements,
 User requirements,
 Use cases that support the business processes,
 User profiles and locations,
 Business processes and rules,
 Functional requirements,
 Non-functional requirements,
 Data requirements,
XXX Project – Business Requirements Document V0.0
Date Page 3

 Requirements baseline and traceability,
 Future considerations,
This document does not include:
 Technical and design specifications – these will be provided in the next phase of
the project as part of the system design documentation
 Descriptions of functionality, interfaces or requirements of processes outside of
the business area
 Detailed analysis of requirements related to other applications, and
 Out of scope requirements>
4.3 DOCUMENT AUDIENCE
Table 4 Document Audience
Document Audience Location
<The main intended audience for this document are the business owners of the proposed
system or other change initiative. They must be able to verify that their business
requirements have been documented completely, accurately and unambiguously. Data
Architects, Application Architects and Technical Architects would also find the
information in this document useful for designing a solution that will address these
business requirements. Since the requirements are documented here in technology-
independent manner, the end-users of the system should be able to comprehend the
requirements fairly easily from this document.>
4.4 BUSINESS ANALYSIS APPROACH
<This section describes the output from tasks and activities that was used to perform
business analysis for this project. This may include, but is not limited to, conceptual
requirements and input from the SDLC Planning phase, consultation preparation,
working group meetings, decision request documents, interviews, JAD sessions, surveys
and questionnaires.>
< The objective of the Analysis phase of the project was to document the list of
requirements of interest to the business and to provide supporting documentation for
the solution in sufficient detail for next phase work. The Analysis phase included <both a
review of existing information and> identification of new or modified requirements.
Date Page 4

The approach included:
 Business analysis planning and monitoring
 Elicitation
 Requirements management and communication
 Requirements analysis
 Solution assessment and validation
The inputs to this phase included:
 Business Case
 Master Project Plan
 Project Charter
 Business Analysis Work Plan
4.5 REQUIREMENTS QUALITY ASSURANCE
<Quality assurance for requirements planning and management focuses on ensuring
that the processes and activities will deliver outputs that meet an appropriate level
of quality. The processes and activities may include techniques such as BRD peer
review, contractor status reporting and metrics, requirements change management
process, requirements completeness checklist, client participation in requirements
acceptance and signoff, and vendor project quality assurance plans. State if
structured walkthrough of finalized set of requirements will be conducted for
ensuring the quality of the requirements.>
<There are a number of levels at which this document should be reviewed
including;
 Business Case Synchronicity Check (the Sponsor has identified the means for
validating the project success)
 Requirements Document Check (the document is worth reading at the business
context level)
 Requirements Statements Content Check (the individual and related requirement
statements are unambiguous, clear, valid and traceable)>
4.6 INFORMATION REFERENCES
<This section should provide a complete list of all the applicable and reference
documents, identified by title, author, date and version. Alternatively, the list of
Date Page 5

documents may be put into an appendix. However, even in that case, a clear indication
of the existence of applicable documents, and a pointer to where the list of them may be
found, must as a minimum be included in the section. e.g., Business Case, Master Project
Plan, PIA, RIA, STRA. >
Table 5 Information References
Document Name Author Date Version
4.7 DEFINITIONS, ABBREVIATIONS & ACRONYMS
<This section should provide the definitions of all terms, acronyms, and abbreviations, or
refer to other documents where the definitions can be found.>
<The following terms, acronyms, and abbreviations are used throughout this
document.>
Table 6 Terms, Acronyms & Abbreviations
Name Definition
Date Page 6

5. BUSINESS REQUIREMENTS (Opportunity)
5.1 PROJECT BACKGROUND
<Provide a short description of the proposed solution being specified and its purpose in
relation to the recommendation of corporate goals or business strategies. At the high-
level articulate the “as is” in terms of what the Customer has now (business functions,
processes, and infrastructure). State why the current situation needs improvement, then
articulate what the Customer expects to be able to do in the “to be” state.>
5.2 SCOPE STATEMENT
5.2.1 IN SCOPE
<Use the In Scope section to describe at a high-level “what the customer expects this
project to deliver”.>
5.2.2 OUT OF SCOPE
<Is there anything that has been discussed as a possible activity of the project that needs
to be identified as explicitly out of scope? If nothing is identified as out of scope, will
everyone’s expectations be met?>
5.3 BUSINESS REQUIREMENTS PURPOSE
<This section describes the purpose of the Business Requirements Document. Tick one or
more of the appropriate check boxes and describe the purpose of the Business
requirements briefly underneath.>
Major enhancements to an existing system
New application development
Replacement application development
Maintenance to an existing system
Policy and legislation changes
Health and safety
5.4 BUSINESS CONTEXT DIAGRAM
<Describe the system context that defines the relationships of this system with users and
external systems. The system context draws the boundary that distinguishes what's in
the system and what's outside of it. The context also represents the relationships
between the system and the external entities with which the system interacts.
Date Page 7

If many user roles and external systems exist, simplify with abstractions. The detailed
requirements for the relationships of the system with the external world are better
expressed in the User Requirements than in the Business Requirements section.>
5.4.1“AS IS” – CURRENT STATE
 <’As Is’ State: Provide a high level business context description of the current
business state.>
5.4.2“TO BE” – FUTURE STATE
 <’As Is’ State: Provide a high level business context description of the current
business state.>
Appendix A: Business Context Diagram(s)
<INSERT DIAGRAM HERE>
Date Page 8

5.5 BUSINESS OBJECTIVES & BENEFITS SUMMARY
< This section describes the primary business objectives and benefits to be achieved with
the implementation of the Business Requirements as prescribed in the Business Case.
Describe at a strategic enterprise level “what the client expects this product to provide”
and “what the client agrees to defer”.>
5.6 BUSINESS DRIVERS/ISSUES
<Define the critical business factors that are to be addressed or satisfied by this system.
Consider any business issues that may impact or impede the success of the system.>
5.7 DEPENDENCIES
<This section lists the dependencies between and within the system for which these
requirements are written and the subsequent project phases or other systems. Describe
which factors may influence the quality and the success of the product, such as the
availability of an external component in a certain date. Dependencies are a form of
constraint in that they can influence the timing, content, risk, etc. for a project. If there
are none, delete the table and add the text,
<There are no project requests active projects related to this BRD.>
<The following projects are related to this project request.>
Table 7 Dependencies
ID Project/System Name Active? (Y/N) Nature of Dependency
5.8 ASSUMPTIONS
<This section lists the assumptions for which these requirements are written and the
subsequent project phases. If the limitation is due to a business rule or an IT policy,
identify the rule or policy in simple terms or provide a reference. List any assumed
factors (as opposed to known facts) that could affect the requirements stated in the
BRD. These could include third-party or commercial components, development or
operating environment issues, or constraints. The project could be affected if these
assumptions are incorrect, are not shared, or changed.>
<The following are assumptions that the project depends on but which are beyond the
control of the project team. These assumptions will be managed as risks in the project
plan.>
Date Page 9

Table 8 Assumptions
ID Assumptions
5.9 CONSTRAINTS/RESTRICTIONS
< This section lists the constraints and restrictions for which these requirements are
written and the subsequent project phases. They often impact and/or provide direction
on how the system must ultimately be developed. Use the following table to detail and
uniquely identify any conditions that restrict the requirements and/or technology to
specifying a system.>
Table 9 Constraints/Restrictions
ID Constraints/Restrictions
5.10 BUSINESS TRANSACTION VOLUMES
<Define the expected volumes associated with the input and output requirements
showing different types of data as well as the internal storage and processing volumes.
Define the nature of processing (timing), and the volume (size) of transactions that
typically are processed per 'cycle.' Are transactions processed on a monthly cycle, such
as preparing a billing statement? Other transactions are processed the same day they
are entered into the system, such as items received in an inventory system or a customer
payment received in a billing system. Still other transactions are entered into the system
and held for processing on a particular date or awaiting an event trigger.>
5.11 REGULATORY CONSIDERATIONS
5.11.1 EXTERNAL REGULATIONS
<Describe external regulations governing the sponsoring organization that will or
may impact the project, timeline and deliverables.>
5.11.2 INTERNAL REGULATIONS
<Describe internal regulations governing the sponsoring organization that will or
may impact the project, timeline and deliverables.>
5.12 PRIVACY IMPACT ASSESSMENT – Refer to Completed PIA
Date Page 10

5.13 RECORDS IMPACT ASSESSMENT – Refer to completed RIA
5.14 OPEN ISSUES
<Use this section to track unresolved issues needing to be resolved for requirements to
be complete. Maintain this list during the development of this document. In the
description of the issue, include an assessment of the complexity of the issue and its
potential impact if not resolved e.g. standing issues for next stage. >
Table 10 Open Issues
I
D
Issue/Priority/Impact Target Resolution Date Responsibility
Date Page 11

6. USER REQUIREMENTS (Needs)
6.1 USE CASE OVERVIEW
<Where a business process already exists, provide high-level business use cases that
describe what the users are expecting. These use cases will provide the basis for
planning user acceptance testing. If a new business process will be created ensure to
map out the new business process so that there will be a basis for user acceptance
testing and requirements traceability. Use Cases are used in system analysis to identify,
clarify, and organize system requirements, and consists of a set of possible sequences of
interactions between systems and users in a particular environment and related to a
particular goal through primary and alternate flows.>
Appendix B Use Case
Use Case Number <the number assigned to the Use Case>
Name <goal or event described by verb and noun>
Description
<brief description of the business activity accomplished by this use
case>
Actor(s) <who performs this activity?>
Pre-conditions <this case processes the following inputs…>
Flow of Events <Standard path, Alternate path, Exception path>
Post-conditions <this case generated the following post conditions …>
Exit Criteria <this case is complete when…>
User
Requirement # <identify user requirement number associated to this case>
Notes & Issues
<identify user requirement number associated to this case>
Date Page 12

6.2 BUSINESS PROCESS MODEL
<A business process model diagram should be created in each of the following cases: for
each function one level above the elementary function level; and where more than one
system process is used to implement the elementary function level, one process model
diagram should be created for each elementary business function.
In the former case, the diagram will include a number of elementary business functions,
and the business event(s) and outcome(s) associated with each. The diagram should be
given the same name as the higher level function on which it is based. In the latter case,
each diagram will show all of the system processes used to implement the elementary
business function being depicted, the system trigger(s) used to implement the business
event(s), the outcome(s) of the elementary business function, and the flow lines that
indicate the processing order.>
6.2.1 “AS IS” – CURRENT STATE
 <’As Is’ State: Provide a high level description of the business area in terms of the
business functions being accomplished. Also identify the systems being used to
address the business functions.>
6.2.2 “TO BE” – FUTURE STATE
 <’To Be’ State: Summarize the findings from the review of the systems. Identify any
redundancies on process or data, data sinks (data coming in not being used by any
other processes) and data gaps (data being used but not coming in from another
source). If this review covers multiple business areas or sub-systems, you may want
to create a general findings section and a Program Area specific section to ensure all
topics are covered.>
Appendix C Business Process Model Diagram
INSERT DIAGRAM HERE
Date Page 13

6.3 ACTOR PROFILES & LOCATIONS
<Identify the various user classes that you anticipate will use this product e.g. Sponsor, Primary
User, Secondary User. User classes may be differentiated based on frequency of use, subset of
business functions performed, technical expertise, security or privilege levels, educational level,
or experience. Describe the pertinent characteristics of each user class. Certain requirements
may pertain only to certain user classes.>
Table 11 Actor Profiles & Locations
Organizational Job
Function
Nature of the
Interaction
Organizational
Relationship Job Title
6.4 INPUTS
< Describe the input media at a conceptual context that can be used by the operator for
providing information to the system. Where appropriate provide the layout of all input data
screens or graphical user interfaces (GUIs) (for example updates to existing screens, prototype
etc.). Provide a graphic representation of each interface.
This section should contain a list of the data entities. Specific values, range of values,
mandatory/optional, alphanumeric values, and length are defined and identified in the Data
Requirements Section 6.
Where applicable discuss the miscellaneous messages associated with operator inputs,
including the following:
 Copies of form(s) if the input data are keyed or scanned for data entry from printed forms
 Description of any access restrictions or security considerations
 Each transaction name, code, and definition, if the system is a transaction-based
processing system.>
6.5 OUTPUTS
<This section describes of the system output requirement relative to the user/operator; show a
mapping to the high-level data flows. System outputs include reports, data display screens and
GUIs, query results, etc. The output files are described in Section 3 and may be referenced in
this section. The following should be provided, if appropriate:
 Description of the purpose of the output, including identification of the primary users
 Description of the output which may be represented by report and screen contents
(provide a graphic representation of each layout and define all data elements associated
with the layout or reference the data dictionary)
 Report distribution requirements, if any (include frequency for periodic reports)
Date Page 14

 Description of any access restrictions or security considerations>
6.6 USER INTERFACE
<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., help)
that will appear on every screen, keyboard shortcuts, error message display standards, and so
on. Define the software components for which a user interface is needed. Details of the user
interface design should be documented in a separate user interface specification.>
6.7 TRIGGERS
<Define the relationships between the functions and the business processes that drive or initiate
the function(s) e.g. dates, event, state change.>
6.8 BUSINESS RULES
<A business rule describes a standard business practice that constrains the design of the
solution. Business rules define acceptable corporate behaviour in response to business events.
They grant authority to act while imposing limits and conditions on how users interact within
their business environment. From an information system perspective, the rules define which
processes, data, constraints and performance criteria are acceptable. Properly expressed, they
are a set of formal business requirements. OPERATIVE RULES= policy/legislation (e.g. an
authorized permit must be in place); STRUCTURAL RULES=true or not true (e.g. every employee
must have a 3 digit employee number. An example is:)>
Table 12 Business Rules
Rule
ID #
Rule Type Statement Source/
Date
Priority Linked
Requirement
#
Use
Case
Source
Test
Case
Source
Date Page 15

6.9 FUNCTION HIERARCHY DIAGRAM & REPORT
<If Use Cases are not supplied then include the Function Hierarchy Diagram & Report. The
business should be represented on as few diagrams as possible that will meet the objective of
clear communication. If the entire function model can be shown on a single page without
becoming either illegible or too complex, then only one page should be used.
A function definition report should be generated to correspond to each function hierarchy
diagram. If no properties have been captured for higher level functions, then the report should
include only elementary business functions presented in alphabetic order by function label>.
Appendix D Function Hierarchy Diagram
INSERT DIAGRAM HERE
Date Page 16

6.10 DATA FLOW DIAGRAM
<As distinct from the business process model, defines the understanding of the range of data for
the information input, processed, stored, and output between functions. Define the method of
ensuring that the function process is adhered to within the system.>
Appendix E Data Flow Diagram
INSERT DIAGRAM HERE
Date Page 17

7. FUNCTIONAL REQUIREMENTS (Product Capabilities & Behaviour)
7.1 OPERATIONAL ENVIRONMENT
<This section describes what the system must be developed to, to conform to Ministry standards
in effect at the time of development with respect to:
 corporate data modelling and administration;
 corporate database technology; and
 application development environment>
7.2 SYSTEM INTERFACE
<This section describes interfaces with other solutions, processes that this business process must
interact with e.g.
 data source from Geo database
 data replicated to LRDW
 XML
 ESF
 Handhelds.>
7.3 COMMUNICATIONS INTERFACE
<Describe the requirements associated with any communications functions required by this
system including
 e-mail,
 web browser,
 network server communications protocols,
 electronic forms,
Define any pertinent message formatting. Identify any communication standards that will be
used, such as FTP or HTTP. Specify any communication security or encryption issues, data
transfer rates, and synchronization mechanisms.>
7.4 SOFTWARE INTERFACE
<Describe the connections between this system and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages coming into the system and going
out and describe the purpose of each. Describe the services needed and the nature of
communications. Refer to documents that describe detailed application programming interface
protocols. Identify data that will be shared across software components. If the data sharing
mechanism must be implemented in a specific way (for example, use of a global data area in a
multitasking operating system), specify this as an implementation constraint.>
7.5 HARDWARE INTERFACE
<Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device
Date Page 18

types, the nature of the data and control interactions between the software and the hardware,
and communication protocols to be used.>
7.6 FUNCTION/USER SECURITY MATRIX
<Define the relationship between each user group (actor) both internal and external, and
the functions (or use case) as described in the functional hierarchy or use case
descriptions.>
These matrixes are important in the phase of your analysis when both the business
function model and entity relationship model seem consistent internally. You can use a
CRUD matrix to answer the following questions:
 Do the business functions require the entities that are missing?
 Are there entities that are not used by any of the functions?
<The following symbols represent the level of access by each of the user groups:>
C Create
R Read
U Update
D Delete
Table 13 Function/User Security Matrix
Actor:
Function
(or Use
Case):
Date Page 19

7.7 USER GROUP & SYSTEM ACCESS SUMMARY
<Define any special user access security that relates to entities within the data. >
Table 14 User Group & System Access Summary
User Group System Access
Date Page 20

8. NON-FUNCTIONAL REQUIREMENTS (Success Factors)
8.1 RESPONSE/ PERFORMANCE
< State the performance requirements for functions or features given the proposed
resources and explain their rationale to enable suitable design choices including
 speed
 precision>
8.2 CAPACITY
<State the expected averages and levels of system growth for
 volumes of transaction,
 users, and
 peak times usage>
8.3 RELIABILITY
<State the reliability requirements for the system including ability to recover from
 errors, and
 failures in the interfaces>
8.4 OPERABILITY
<State the operability requirements including
 the ease of learning the application
 error handling & messaging
8.5 MAINTAINABILITY
<State the maintainability requirements for the application post implementation
including
 the ability to implement changes without causing unexpected failures
 the ease of making changes
 the ability to make changes to components without affecting others
8.6 SCALABILITY
<State the expected scalability for
 users,
 uptake,
 storage,
 infrastructure support,
 modules,
 licensing needs>
Date Page 21

8.7 AVAILABILITY
<State the availability requirements for the system including
 time of day, days of year
 what loss of availability during those times is tolerable
 how will the users learn of non-availability
 fallback facilities needed in the event of non availability
 special provision needed for bringing the system back into safe, productive operation
after a period of non availability>
8.8 DELIVERY
<State the core types of deliverable components expected for each application release
including
 executable software
 source code
 build scripts
 development tools
 documentation>
8.9 RECOVERY
<Define specific and critical requirements for system planning that need to be considered
during the detailed technical design stage of the system. What are the needs for timing of
backups? >
8.10 TRANSITION REQUIREMENTS
<Identify any transition requirements for the system solution or user skill set needed to
operate the system.>
Date Page 22

9. DATA REQUIREMENTS (Structure)
9.1 LOGICAL DATA MODEL
<Details are covered in the Data Administration standards. Please refer to these
documents in conjunction with this analysis standard when preparing system
requirements. Specify any special requirements for accessing other systems data. Show
validation requirements and edit rules. Include the following components. Additional
information can be found at: http://www.for.gov.bc.ca/his/datadmin/s7.pdf>
Appendix F Logical Data Model
 Entity Relationship Diagram- include diagram or reference to diagram
o Include relationship descriptions
 Entity & definitions- include or reference
 Entity Attributes and Definitions- include reference
 Code Lists
9.2 DATA CONVERSION REQUIREMENTS
<This section describes the high-level Data Conversion Requirements which identifies and
defines the source data (data sets) which must be converted into the new database
tables (or existing tables) as a result of this project. It will show the list of major entity
(source) to entity (target) mappings. (More details e.g. column mappings, will be added
in the design phase.)>
9.3 WAREHOUSING
<This section defines the high level warehousing requirements for the project. The data
warehousing is to be treated as a separate “system” in parallel to the main business
system. There are separate and different requirements for data, processing and
reporting associated with the data warehouse.>
9.4 DATA VOLUMES & SIZE
<This section describes the expected approximate Data volumes (initial volume and
annual growth percentage for each conceptual Entity.>
9.5 DATA RETENTION/ARCHIVE/PURGE
<This section describes the Data retention (time frames for online Data retention before
archiving) and also the archiving requirements. Refer to records management policy.>
Date Page 23

10.ALL REQUIREMENTS LIST/TRACEABILITY MATRIX (Requirements
Baseline)
<This section shall be divided into statements to specify the requirements, that is, those
characteristics of the requirements that are conditions for its acceptance. Each
requirement shall be assigned a project-unique identifier to support testing and
traceability, and shall be stated in such a way that an objective test can be defined for it.
The final product must be tested and validated against the design and original
requirements. A "strong" requirement is tightly, unambiguously, and precisely defined in
such a way that leaves no other interpretation or meaning to any individual
requirement.
Requirements tracing is the process of documenting the links between the user
requirements for the system and the work products developed to implement and verify
those requirements in a bi-directional manner e.g. source of requirements, requirements
and work products that implement the requirement. These work products include
software requirements, design specifications, software code, test plans and other
artifacts of the systems development process. Requirements tracing helps the project
team to understand which parts of the design and code implement the user’s
requirements, and which tests are necessary to verify that the user’s requirements have
been implemented correctly.
The format for requirement presentation can be as follows:
 Requirement Identification Number
<Provide an identification number for the requirement.>
 Requirement Type
<Provide a definition of the requirement type.>
 Statement
<Provide a definitive statement of the business condition or capability in clear, consistent
and unambiguous language. Avoid specifying the design.>
 Source/Date
<The source of and date of the requirements statement.>
 Priority
Date Page 24

<Use “Priority” to sort the requirements so that the most important are distinguished
from the rest. The choices are Mandatory, Value Added, Optional, and Excluded.>
 Business Rule Number
< State the business rule that is related to this requirement.>
 Backward Traceability
<Show the origin of an item. This can be used to determine if unnecessary items are
being created (gold plating) that are not warranted by the requirements or to discover
the reason for an item. Tie back to hi-level business requirements statement.>
 Use Case Source
<State the detail use case that is related to this requirement.>
 Test Case Source
<State the high level test case that is related to this requirement.>
Appendix G All Requirements List & Traceability Matrix
ID #
Requirement Type
Statement
Source/Date
Priority
Business Rule #
Backward
Use Case Source
Test Case Source
Date Page 25

11.CONSIDERATIONS (Planning Effort)
<Most of these headings are covered under other SDLC phases and are optional to
complete. Provide high level statements for consideration in future work.>
11.1 PRELIMINARY DESIGN
<Provide preliminary design information to enable framing of the design phase
deliverables and preferred contract type. Where there is an agreement that the
contractor performing the analysis phase will be proceeding with the design phase, these
details should be specific and accurate.
If there is no agreement that the contractor performing the analysis phase will be
proceeding with the design phase, these details may be more general and high level or
not present.>
11.2 WORK PLAN
<Provide a high-level work plan for the design phase identifying all major milestones
including the proposed delivery schedule.>
11.3 RESOURCING
<Identify the ministry branches and/or other ministries and contracted resources
required and responsible for the detail planning and estimating of the design phase.>
11.4 COSTS
<Estimate the costs and preferred contract type for the design phase based on the scope
definition. It is preferred that the scope be defined to such a degree so as to enable the
estimates to be fixed priced.>
11.5 DELIVERY REQUIREMENTS
<Identify the business and technical units a general definition of the new solution by
policies, procedures, business rules, training, manuals retooling, staffing and facilities
needed.>
11.6 TEST STRATEGY
<Identify the high level test strategy that would cover off the requirements scope.>
11.7 IMPLEMENTATION PLAN
<Identify the system implementation strategy that addresses the general timing and
activities required for implementation and post implementation support.>
11.8 USER TRAINING
Date Page 26

<Identify a high level system training and support strategy that addresses productivity
gains around assembly, maintenance, publishing and delivery of learning content for
primary and secondary users.>
11.9 SUPPORT
<Identify at a high level the expected support for the system once in production.>
11.10 SYSTEM MAINTENANCE AND OPERATIONS
<Identify the collaborative technical and business strategy to fix problems and
implement enhancements that add value to the system and ultimately the organization.>
11.11 APPLICATION DEACTIVATION
<Identify the future high-level business, technical and regulatory strategies that would
address the deactivation of the business solution should it be replaced or retired.>
Date Page 27

12.APPENDICES (Supporting Documentation)
Appendix A: Business Context Diagram
Appendix B: Use Case Diagram
Appendix C: Business Process Map
Appendix D: Function Hierarchy Diagram
Appendix E: Data Flow Diagram
Appendix F: Logical Data Model
Appendix G: All Requirements List & Traceability Matrix
Date Page 28

Business REquirement document to be used in projects

More Related Content

Similar to Business REquirement document to be used in projects (20)

More from Wilber Tuttleman (20)

Recently uploaded (20)

Business REquirement document to be used in projects