Business Requirements Specification: [Initiative name]

Complete business requirements specification (BRS, also called a business requirements document or BRD). The section structure follows the business requirements information item of ISO/IEC/IEEE 29148:2018 (clause 9.3), extended with common business analysis practice for measurable objectives, requirement attributes and success metrics. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction
2. References
3. Business management requirements
4. Business operational requirements
5. Operational concept of the proposed solution
6. Business requirements
7. Project constraints
8. Success metrics and benefits realisation
9. Traceability
10. Appendices

1. Introduction

1.1 Business purpose

[The problem or opportunity, why it matters now, and what the organisation will gain. Quantify where possible.]

Example: Accounts payable processes 18,000 supplier invoices a month at an average cost of 7.40 per invoice and 11 days cycle time. Late payments cost 210,000 a year in lost early-payment discounts. The organisation wants to halve cycle time and capture at least 80% of available discounts.

1.2 Business scope

• Processes in scope: [process 1], [process 2].
• Organisational units: [units, countries, subsidiaries].
• Out of scope: [process or unit excluded], [later phase].
• Interfaces with other initiatives: [related programme and how they depend on each other].

1.3 Business overview

[How the affected part of the business works today and how it fits the wider organisation. Include volumes, sites and headcount.]

Example: Accounts payable sits in the group finance shared service centre in [city] with 22 staff. It serves four operating companies in three countries and pays about 2,400 active suppliers. Invoices arrive by post, email and supplier portal; 30% have no purchase order and must be coded by hand. Budget holders approve by replying to email, which leaves no reliable audit trail.

1.4 Definitions

[Business terms with a specific meaning in this document. Full glossary in 10.1.]

1.5 Major stakeholders

2. References

3. Business management requirements

3.1 Business environment

[External and internal factors: market, competition, regulation, technology, economic conditions, and the organisation's capacity for change. Note which factors could invalidate the business case.]

Example: E-invoicing becomes mandatory for business-to-business transactions in two of the three countries within 24 months. Suppliers increasingly expect payment status online. Finance headcount is frozen, so volume growth of 8% a year must be absorbed without new hires.

3.2 Mission, goals and objectives

3.3 Business model

[How value is created in the affected area: customers or internal clients, services, revenue or cost drivers, partners. Note the intended change to the model.]

3.4 Information environment

[Key information the business relies on, systems of record, data owners, and known data quality issues.]

4. Business operational requirements

4.1 Business processes

4.2 Business operational policies and rules

4.3 Business operational constraints

[Limits on operations: staffing, union agreements, regulatory deadlines such as tax filing, month-end close calendar, outsourcing contracts.]

4.4 Business operational modes

4.5 Business operational quality

[Quality the business must achieve in operation, in business terms: accuracy, timeliness, compliance, customer or supplier satisfaction.]

Example: Payment errors below 0.1% of invoice value; supplier satisfaction with payment process at least 4 out of 5.

4.6 Business structure

[Organisation units, roles, reporting lines and locations involved, and planned structural changes such as a shared service centre.]

Example: The AP manager reports to the group financial controller. Three team leads each run a team aligned to one operating company. After the change, teams will be organised by process step (capture, exceptions, supplier queries) rather than by company, and two roles move to supplier onboarding.

5. Operational concept of the proposed solution

5.1 High-level operational concept

[Describe how work will flow after the change, who does what, and what stops happening.]

The target process for the example is shown below.

5.2 Operational scenarios

5.3 Other life-cycle concepts

6. Business requirements

6.1 Conventions

IDs: BR-<nnn>. Priority: Must / Should / Could / Won't (MoSCoW). Status: Proposed, Agreed, Deferred, Rejected. Acceptance: the business test that proves the requirement is met.

6.2 Requirements

6.3 Out-of-scope and deferred requirements

7. Project constraints

8. Success metrics and benefits realisation

Discount capture is calculated as:

Review points: [30, 90 and 180 days after go-live]. A benefit below 70% of target at the 180-day review is escalated to the sponsor.

9. Traceability

10. Appendices

10.1 Glossary and acronyms

10.2 Assumptions and dependencies

10.3 Risks

10.4 Open issues

Standard and licence note

Structure aligned with ISO/IEC/IEEE 29148:2018, Systems and software engineering: Life cycle processes, Requirements engineering, business requirements specification information item, combined with common business analysis practice for objectives and benefits tracking. This template is original text written for this collection and reproduces no text from the standard; obtain the standard from ISO, IEC or IEEE for its normative requirements. Template licence: MIT.