This business requirements document template turns that fictional app request into an outcome, stakeholder needs, scope, and a transition question. Keep the desired business result clear while the solution choice is still open.
Replace the feature request with an outcome
The original teaching case begins with two notes:
| Record | Supplied note |
|---|---|
| N1 | Build a mobile app. |
| N2 | Staff cannot tell which open requests await equipment details and which await scheduling confirmation. |
N2 gives the team a problem to discuss. It does not supply a measured request volume, delay baseline, budget, or evidence that a mobile app is the right answer.
The worked business outcome, B1, is:
At daily review, the coordinator can identify each open request's next action and the role responsible for it.
That outcome lets the team examine a proposal without committing to an interface. A tool that looks polished but leaves the next action unclear would still miss the stated need.
The IIBA requirements-category infographic distinguishes business outcomes, stakeholder needs, solution capabilities, and temporary transition requirements. The equipment-request example here applies those distinctions to an original process.
Put the needs beside the outcome they support
Select an entry in the example to inspect its category and rationale:
| Entry | Category | Why it belongs |
|---|---|---|
| B1: Identify each open request's next action and responsible role at daily review. | Business outcome. | Describes what the process needs to achieve. |
| S1: The requester needs to see which equipment details remain to be supplied. | Stakeholder need. | Helps the requester provide the information needed for the next action. |
| S2: The coordinator needs open requests grouped by next action. | Stakeholder need. | Supports the daily review described in B1. |
| Mobile app, shared request form, or adapted existing tool. | Open solution choices. | Different approaches to investigate against the needs. |
| T1: Map existing open requests into the agreed status meanings before switching processes. | Transition requirement. | Addresses the move from the current process to the new one. |
S1 and S2 describe different views of the same work. Neither requires the team to choose an app yet. After choosing an approach, the team can define the capabilities and behavior it must provide.
T1 prevents a different gap: a new process may use clear status labels while older requests remain ambiguous. The transition needs a way to interpret those existing records.
Make the scope decision explicit
The worked BRD includes request clarification and next-action visibility. It excludes payments and equipment allocation.
That boundary matters when someone asks to add a booking or payment feature. Record it as a scope question instead of silently expanding “request visibility” into a complete studio-management system.
Use a short decision log:
| Question | Current position | Next discussion |
|---|---|---|
| Which solution should be used? | Open. | Compare feasible approaches with S1 and S2. |
| What does each status mean? | Meanings to agree. | Define the next action and responsible role for each state. |
| How will existing requests move over? | T1 requires a mapping. | Review a sanitized set of current request scenarios. |
| Are payments or allocation included? | Excluded from this example's scope. | Treat any proposed addition as a separate scope decision. |
Keep the original request visible when its wording changes. N1 can remain in the background notes while B1 becomes the requirement the team reviews.
Propose evidence for success before choosing a target
The team can review a declared set of sanitized request scenarios and check whether the coordinator can identify each next action and responsible role.
For example, one scenario could lack equipment details; another could have those details but still need scheduling confirmation. Define the intended action and role for each scenario before using it to review a proposed process.
Agree on the scenario set, reviewer, baseline, and acceptable result. Those fields remain open in the worked document. An invented “50% faster” target would add precision without evidence.
The blank BRD organizes the problem, outcome, stakeholder needs, scope, constraints, transition needs, and open decisions. Build review copy identifies missing sections so the team can finish the discussion document.
Prepare your own BRD
Create one complete, self-contained HTML business requirements document.
Initiative and process owner: [FILL IN]
Original request: [PASTE]
Business problem and its evidence: [PASTE]
Desired business outcome: [PASTE]
Stakeholders and their distinct needs: [PASTE]
Included and excluded scope: [PASTE]
Known constraints and assumptions: [PASTE]
Solution approaches still under consideration: [PASTE]
Transition needs for existing work or data: [PASTE]
Proposed success evidence, baseline, and agreed target: [PASTE OR MARK TO AGREE]
Open questions and decision owners: [PASTE]
Produce a complete readable BRD summary and needs register. Separate
business outcomes, stakeholder needs, solution choices or capabilities,
and temporary transition requirements. Connect each stakeholder need
to the outcome it supports. Keep alternatives open where no decision
has been supplied; do not automatically choose a technology.
Compare feature-only wording with a proposed outcome-led revision.
Show the original request separately from the revised requirement.
Include scope boundaries, constraints, assumptions, and a decision log.
Leave unsupplied metrics, approval, budget, and baseline blank.
Provide a blank BRD scaffold that names missing problem, outcome,
stakeholder need, or scope. Preserve temporary review notes when
switching entries. Mark generated review output stale after edits
and ask before resetting typed work. Do not simulate sign-off,
project execution, saved decisions, or external integrations.
Use text of at least 16px, labeled keyboard-accessible controls, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline with no external dependencies. Return complete HTML.
Get agreement on the need before designing the screen
Bring B1, S1, and S2 to the coordinator and requester representatives. Ask them to walk through a request missing details and another waiting for scheduling confirmation. Their explanation should make the required next action clear enough to record.
Use NOS to revise the BRD's visible wording during that review if you have prepared it as HTML. Replacing “build an app” with the agreed outcome keeps the discussion focused on the work the change must support. The solution comparison can follow once the needs and boundaries are understood.