Write a business requirements document

A business requirements document (BRD) says what the business needs and how it will know the need is met, before anyone chooses a vendor or designs a solution. It is the document procurement, suppliers and approvers read, so ambiguity in it becomes cost later: change requests, disputes about what was promised, and systems that pass a demo but fail on the warehouse floor. Business analysis practice (the BABOK guide is the common reference) asks for requirements that are tied to a business objective, solution-neutral (what, not which product), unambiguous, testable, prioritised and traceable to a stakeholder. Words like "user-friendly", "fast", "flexible" or "seamless" are not requirements until they carry a measure. This prompt covers business processes and system purchases outside software development: phone systems, outsourcing, facilities, fleet, finance processes.

Write a business requirements document for this initiative.

Only if [STAKEHOLDERS] is given:

Only if [CONSTRAINTS] is given:

1. If the business problem or the current process is too thin to derive needs from (no steps, volumes or pain points), ask up to four specific questions and stop.
2. If the initiative names a solution as the goal ("buy product X"), restate the underlying business need, record the named product as a constraint or a candidate, and keep the requirements solution-neutral.
3. Write the BRD with these sections:
4. Purpose and background: the problem in two or three sentences, with figures from the input.
5. Business objectives: two to five objectives, each measurable (metric, baseline, target, date) where the input allows; otherwise [NEEDED: target].
6. Scope: in scope and out of scope as bullet lists; out of scope is as important as in.
7. Stakeholders: a table with stakeholder, role (sponsor, approver, user, consulted, informed), interest and how they are affected.
8. Current state: the process as numbered steps with volumes and pain points.
9. Future state: the process as it should work, at the same level of detail, without naming a product.
10. Business requirements: a table with ID (BR-01…), requirement as a "The solution shall…" statement, priority (Must, Should, Could, Won't for now), source stakeholder, rationale linked to an objective, and acceptance criterion (a concrete, testable condition).
11. Non-functional and service requirements: availability and support hours, capacity and volumes, security and data protection, retention and audit, accessibility, training, transition and exit (data return, notice), each with a measure.
12. Assumptions, constraints and dependencies.
13. Risks: the main risks with likelihood, impact and mitigation.
14. Approval: who signs off.
15. Number every requirement once and keep each to one testable need; split compound ones.

• Use only facts given; never invent volumes, costs, dates, regulations or stakeholder positions. Mark gaps [NEEDED: …] and list them under Open questions.
• Requirements are solution-neutral: no product names, vendors or design choices inside requirement statements.
• Every requirement has a measurable or observable acceptance criterion; reject vague words (fast, easy, intuitive, robust) unless quantified.
• Where data protection, employment, accessibility or sector rules plausibly apply, add a requirement to confirm compliance with the named area and mark it for legal or compliance review, without stating what a specific law requires.
• Concise: tables over prose; no padding sections that have no content (write "None identified").

Business requirements document

The BRD with the numbered sections above.

Open questions

Numbered questions, each with who can answer it.

Requirements quality check

A short list of any requirement that is still vague, compound, untestable or not traced to an objective, with the fix, or "All requirements pass".