Document Control

Summary of Document Changes

Version	Date	Author	Reason

Quality Assurance

Version	Date	Reviewer

Document Approver

Name	Date	Signature

Introduction

Purpose

<Document the purpose of this document

Example: The purpose of this document is to detail the business requirements>

Background

<Brief description on the initial stimuli of the project and how the organization intends to achieve its goals and make the desired transition and by what means>

Definitions

<List any terms the audience may not understand, including specific terms, abbreviations and acronyms>

Terms, abbreviations and acronyms	Meaning

Referenced Documents

Document Number / Location / Links	Reference Description/Name

Business Scope and Objectives

In Scope

<Include the scope of the project providing a ‘high-level’ understanding of what the Department / Agency is and aspires to become>

Out of Scope

<List what is excluded from the project scope>

Objectives

<Identify the overall projects objectives.  This will help in providing the context in which the project is intends to be undertaken>

As-Is Business Process Flows

<Document the “As-is” business process flows here.   Suggestions could include the following:

·       Including a business process model which could provide a graphical representation of the flow of work

·       Depicting the usage and interaction between the various components – people, hardware and software>

Business Requirements

<Document the business requirements here.  It is important that the Business requirements are clear and fit into one or more of the following characteristics:

·       They support a business scope and / or objective

·       They have a business purpose / focus

·       They state “what” needs to be accomplished using business language

·       They are non-technical>

In order to ensure that the highest value requirements are completed first, it is key that the requirements are prioritized.  One way of deciding on the priority of requirements is by assigning each a priority rating, using MoSCoW or ECO:–

MoSCoW

ECO

(M) Must(S) Should(C) Could(W) Want

(E) Essential – This implies that the application/software/hardware will not be acceptable unless these requirements are provided in an agreed manner(C) Conditional – This implies that these are requirements that would enhance the application/software/hardware product, but would not make the product unacceptable if they are absent(O) Optional – This implies that the function that may or may not be worthwhile.

It is recommended to also document the Testing requirements here linking them back to the business requirements.>

Business Functional Requirements

Business Functional Requirement (BFR) ID	Requirement	Priority
BFR1
BFR2
BFR3
BFR4

Business Non-Functional Requirements

Business Non Functional Requirement (BNFR) ID	Requirement	Priority (E, C & O)
BNFR1
BNFR2
BNFR3
BNFR4

Testing requirements

Business Functional / Non Functional Requirement ID	Description

Success criteria and associated metrics

< Success criteria / acceptance criteria ensure that the agreed to business requirements (functional and non-functional) are clear and unambiguous and can be used to measure the success of the project.>

Success Criteria for Business Functional Requirements

<This section should have the same list of business functional requirements identified in the earlier section together with the success criteria for each requirement.>

Business Functional Requirement (BFR) ID	Requirement	Success Criteria and Associated Metrics
BFR1
BFR2
BFR3
BFR4

Success Criteria for Business Non-Functional Requirements

<This section should have the same list of business non-functional requirements identified in the earlier section together with the success criteria for each requirement.>

Business Non-Functional Requirement (BFR) ID	Requirement	Success Criteria and Associated Metrics
BNFR1
BNFR2
BNFR3
BNFR4

Assumptions, Issues and Constraints

Assumptions

<Outline any critical assumptions related to the business requirements. This may include that one individual represents/speaks for a collective.>

Issues

<Outline any issues related to the business requirements. This may include stakeholders dropping out>

Constraints

<Outline any constraints related to the business requirements. This may include time limits>

Appendices

Appendix 1

<Include any additional annexures which might be useful for example Process maps>