# 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*.

<!--
Guidance: How to use this template
- The BRS answers "why is the organisation doing this, and what must be
  true for the business when it is done?" It is written for executives,
  process owners and finance, not for developers.
- State business requirements, not solutions. "Reduce invoice processing
  cost to under 2 per invoice" is a business requirement; "buy an OCR tool"
  is a solution option.
- Fill section 3.2 (objectives with baseline and target) before anything
  else. Every business requirement in section 6 must serve one objective.
- Keep the numbering; stakeholder and system requirements trace back to
  the BR IDs defined here.
-->

## Document control

<!-- Guidance: Identify the document so every copy can be traced to one version. -->

| Field | Value |
|---|---|
| Document ID | [BRS-INITIATIVE-001] |
| Initiative | [Initiative or programme name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@business-analyst] |
| Executive sponsor | [@sponsor] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Business case], [Project charter], [StRS-xxx], [ConOps-xxx] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Finance business partner | [@name] | [Decision] | YYYY-MM-DD |
| Process owner(s) | [@name] | [Decision] | YYYY-MM-DD |
| Programme manager | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per published version; name requirement IDs added or changed. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft from sponsor interviews |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added BR-012 on supplier self-service; revised BO-02 target after finance review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Baselined at steering committee |

## Contents

<!-- Guidance: Keep this list in sync with the headings. -->

1. [Introduction](#1-introduction)
2. [References](#2-references)
3. [Business management requirements](#3-business-management-requirements)
4. [Business operational requirements](#4-business-operational-requirements)
5. [Operational concept of the proposed solution](#5-operational-concept-of-the-proposed-solution)
6. [Business requirements](#6-business-requirements)
7. [Project constraints](#7-project-constraints)
8. [Success metrics and benefits realisation](#8-success-metrics-and-benefits-realisation)
9. [Traceability](#9-traceability)
10. [Appendices](#10-appendices)

## 1. Introduction

<!-- Guidance: Orient an executive reader in under five minutes. -->

### 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

<!-- Guidance: Draw the boundary in business terms: processes, organisational units, products, regions. -->

- **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

<!-- Guidance: Who sponsors, who benefits, who pays, who changes how they work, who can block. -->

| Stakeholder | Role in initiative | Key interest | Influence | Engagement |
|---|---|---|---|---|
| *Example:* CFO | Sponsor | Working capital, cost per invoice | High | Monthly steering |
| *Example:* AP team leads | Process owners | Workload, accuracy | Medium | Weekly workshops |
| *Example:* Suppliers | External | Paid on time, payment visibility | Medium | Survey, pilot group |
| *Example:* Internal audit | Assurance | Segregation of duties | High | Review at baseline |
| [Stakeholder] | [Role] | [Interest] | [Level] | [Engagement] |

## 2. References

<!-- Guidance: Every cited document with version and date. -->

| ID | Title | Version / date | Source |
|---|---|---|---|
| REF-01 | ISO/IEC/IEEE 29148:2018 Requirements engineering | 2018 | ISO / IEC / IEEE |
| REF-02 | [Business case] | [x.y] | [Location] |
| REF-03 | [Corporate strategy or annual plan] | [Year] | [Location] |
| REF-04 | [Process maps, policies] | [x.y] | [Location] |

## 3. Business management requirements

<!-- Guidance: The strategic context: environment, goals, business model and information. -->

### 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

<!-- Guidance: Objectives must be SMART: specific, measurable, achievable, relevant, time-bound. Record the baseline now; you cannot show improvement without it. -->

| ID | Goal | Objective | Measure | Baseline | Target | Deadline |
|---|---|---|---|---|---|---|
| BO-01 | *Example:* Faster payment | Cut invoice cycle time | Median days from receipt to approval | 11 days | 5 days | YYYY-MM-DD |
| BO-02 | *Example:* Lower cost | Cut processing cost | Cost per invoice | 7.40 | 3.50 | YYYY-MM-DD |
| BO-03 | *Example:* Capture discounts | Raise discount capture | % of available discount value taken | 35% | 80% | YYYY-MM-DD |
| BO-04 | [Goal] | [Objective] | [Measure] | [Value] | [Value] | YYYY-MM-DD |

### 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.]

| Information | System of record | Owner | Known issues |
|---|---|---|---|
| *Example:* Supplier master | ERP | Procurement | 9% duplicate suppliers |
| *Example:* Purchase orders | ERP | Procurement | 30% of invoices have no PO |
| [Information] | [System] | [Owner] | [Issues] |

## 4. Business operational requirements

<!-- Guidance: How the business must operate, regardless of the solution chosen. -->

### 4.1 Business processes

| ID | Process | Owner | Volume | Current pain point |
|---|---|---|---|---|
| BP-01 | *Example:* Invoice receipt | AP lead | 18,000 / month | 40% arrive on paper |
| BP-02 | *Example:* Three-way match | AP lead | 12,000 / month | Manual matching takes 6 min each |
| BP-03 | *Example:* Approval | Budget holders | 6,000 / month | Approvals wait in email |
| BP-04 | [Process] | [@owner] | [Volume] | [Pain point] |

### 4.2 Business operational policies and rules

| ID | Rule | Source |
|---|---|---|
| BRULE-01 | *Example:* Invoices over 10,000 require approval by a budget holder and a finance manager. | Delegation of authority |
| BRULE-02 | *Example:* The person who enters an invoice may not approve it. | Internal control framework |
| BRULE-03 | [Rule] | [Source] |

### 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

| Mode | When | What changes |
|---|---|---|
| *Example:* Normal | Days 1 to 24 of the month | Standard approval routes |
| *Example:* Month-end close | Last 5 working days | Cut-off rules; accruals for unapproved invoices |
| *Example:* Year-end audit | January | Read-only access for auditors |
| [Mode] | [When] | [Changes] |

### 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

<!-- Guidance: A preliminary, solution-neutral picture of how the business will operate. Detail belongs in a ConOps. -->

### 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.

```mermaid
flowchart LR
  A[Invoice received electronically] --> B[Data captured automatically]
  B --> C{Matches PO and receipt?}
  C -->|Yes| D[Auto-approved within tolerance]
  C -->|No| E[Routed to AP for exception handling]
  E --> F[Budget holder approves]
  D --> G[Scheduled for payment on discount date]
  F --> G
```

### 5.2 Operational scenarios

| ID | Scenario | Steps (summary) | Objectives served |
|---|---|---|---|
| OS-01 | *Example:* Matched PO invoice | E-invoice arrives, matches, auto-approved, paid on day 9 to take 2% discount | BO-01, BO-03 |
| OS-02 | *Example:* Non-PO invoice | Captured, coded by AP, routed to budget holder, approved within 2 days | BO-01 |
| OS-03 | *Example:* Price variance | Match fails by 4%, routed to buyer, credit note requested | BO-02 |
| OS-04 | [Scenario] | [Steps] | [BO-IDs] |

### 5.3 Other life-cycle concepts

| Concept | Expectation |
|---|---|
| Acquisition | [Build, buy, outsource; procurement route] |
| Deployment | [Pilot business unit, phased rollout by country] |
| Support | [Who supports the business process and the solution] |
| Retirement | [What happens to legacy tools and records] |

## 6. Business requirements

<!-- Guidance: Each business requirement states a capability or result the business needs, with attributes. Keep them solution-neutral and measurable. Aim for tens, not hundreds; detail belongs in stakeholder and system 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

| ID | Business requirement | Objective | Source | Priority | Owner | Acceptance criterion | Status |
|---|---|---|---|---|---|---|---|
| BR-001 | *Example:* The business shall receive at least 85% of invoices in a structured electronic format. | BO-01, BO-02 | CFO interview | Must | AP lead | 3-month average at or above 85% | Agreed |
| BR-002 | *Example:* The business shall approve matched PO invoices without manual touch when within tolerance. | BO-01 | Workshop W-2 | Must | AP lead | 70% touchless rate in pilot | Agreed |
| BR-003 | *Example:* Budget holders shall be able to approve invoices from mobile devices. | BO-01 | Survey S-1 | Should | Finance ops | Median approval wait under 1 day | Proposed |
| BR-004 | *Example:* The business shall enforce BRULE-01 and BRULE-02 on every invoice. | Compliance | Audit | Must | Controller | Zero control exceptions in audit sample | Agreed |
| BR-005 | *Example:* Suppliers shall be able to see payment status without contacting AP. | BO-02 | Supplier survey | Should | Procurement | 50% fewer status calls | Proposed |
| BR-006 | [Requirement] | [BO-ID] | [Source] | [MoSCoW] | [@owner] | [Criterion] | [Status] |

### 6.3 Out-of-scope and deferred requirements

| ID | Requirement | Reason | Revisit |
|---|---|---|---|
| *Example:* BR-020 | Automated expense claims | Separate programme | YYYY-MM-DD |
| [ID] | [Requirement] | [Reason] | YYYY-MM-DD |

## 7. Project constraints

<!-- Guidance: Limits on the initiative: budget, deadlines, mandated suppliers, resources. -->

| ID | Constraint | Source | Consequence |
|---|---|---|---|
| PC-01 | *Example:* Total budget of [amount] including change management | Approved business case | Phased scope |
| PC-02 | *Example:* No go-live during month-end close or year-end | Controller | Fixed release windows |
| PC-03 | [Constraint] | [Source] | [Consequence] |

## 8. Success metrics and benefits realisation

<!-- Guidance: Define how and when benefits will be measured after go-live, and who is accountable. Benefits without an owner are not realised. -->

| Metric | Objective | Data source | Frequency | Baseline | Target | Benefit owner |
|---|---|---|---|---|---|---|
| *Example:* Median invoice cycle time | BO-01 | ERP workflow log | Monthly | 11 days | 5 days | AP lead |
| *Example:* Cost per invoice | BO-02 | Finance cost model | Quarterly | 7.40 | 3.50 | Finance ops |
| *Example:* Discount capture | BO-03 | Payment run report | Monthly | 35% | 80% | Treasury |
| [Metric] | [BO-ID] | [Source] | [Frequency] | [Value] | [Value] | [@owner] |

Discount capture is calculated as:

$$
\text{Capture rate} = \frac{\sum \text{discounts taken}}{\sum \text{discounts available}} \times 100\%
$$

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

<!-- Guidance: Link each objective to its business requirements and onward to stakeholder requirements and scenarios. An objective with no requirement, or a requirement with no objective, is a gap. -->

| Objective | Business requirements | Stakeholder requirements | Scenarios | Metric |
|---|---|---|---|---|
| BO-01 | BR-001, BR-002, BR-003 | [STK-UR-001..004] | OS-01, OS-02 | Cycle time |
| BO-02 | BR-001, BR-005 | [STK-UR-010] | OS-03 | Cost per invoice |
| BO-03 | BR-002 | [STK-UR-012] | OS-01 | Capture rate |
| Compliance | BR-004 | [STK-UR-020] | OS-02 | Control exceptions |
| [BO-ID] | [BR IDs] | [STK IDs] | [OS IDs] | [Metric] |

## 10. Appendices

<!-- Guidance: Supporting material and registers. -->

### 10.1 Glossary and acronyms

| Term | Definition |
|---|---|
| AP | Accounts payable |
| PO | Purchase order |
| Three-way match | Comparison of invoice, purchase order and goods receipt |
| [Term] | [Definition] |

### 10.2 Assumptions and dependencies

| ID | Assumption or dependency | Impact if false | Owner |
|---|---|---|---|
| AD-01 | *Example:* 60% of suppliers can send e-invoices within 6 months | BR-001 target slips | Procurement |
| AD-02 | [Assumption] | [Impact] | [@owner] |

### 10.3 Risks

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| R-01 | *Example:* Budget holders resist mobile approval | Medium | Medium | Pilot with champions; training | Finance ops |
| R-02 | [Risk] | [L/M/H] | [L/M/H] | [Response] | [@owner] |

### 10.4 Open issues

| ID | Issue | Owner | Due | Resolution |
|---|---|---|---|---|
| OI-01 | *Example:* Confirm tolerance for touchless approval (2% or 5%) | Controller | YYYY-MM-DD | [Open] |

## 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.