BUSINESS REQUIREMENTS DOCUMENT
Original fictional BriefRelay intake example and blank form. Checked October 28, 2026.
All observations, targets, roles and identifiers below are invented teaching material.

EXAMPLE BRD: COORDINATED CLIENT INTAKE
Business problem: project briefs arrive through multiple channels and a coordinator cannot consistently identify the responsible team.
Decision: define the operating need before selecting the product behavior and implementation.
Stakeholders: client requester, intake coordinator, Support, Engineering and Product owner. These roles are illustrative; no interviews were conducted.
Current process: requester sends a brief; coordinator checks for missing details; the team creates a manual reference; Support searches messages when status is unclear.
Desired process: a permitted request has an identifiable owner and reference, exceptions have a recovery path, and status can be retrieved within the authorized workspace.

BR-1 Ownership: every accepted pilot request has one named operational owner.
Business rule: the intake team must define the assignment source and exception owner before the pilot.
Proposed observation: compare the permitted pilot request list with the ownership record using the same population and window.
BR-2 Traceability: an accepted request has a stable reference that a permitted requester and support workflow can use.
Business rule: the reference identifies the request; it does not itself grant access.
Proposed observation: trace a synthetic request through submission, receipt and scoped support lookup.
BR-3 Recovery: a rejected request explains the recoverable problem and the next permitted action.
Business rule: exceptions must not disappear into an unexplained completed state.
Proposed observation: rehearse one missing-detail case and one unsupported-file case.
BR-4 Workspace separation: status lookup respects the requesting party's authorized workspace.
Business rule: a submitted workspace identifier is not evidence of membership.
Proposed observation: compare permitted and cross-workspace requests through the actual server boundary.

Success evaluation: Product reviews evidence for BR-1 through BR-4 against an identified pilot candidate. No percentage improvement or industry benchmark is claimed.
Constraints: existing identity provider, bounded pilot scope, synthetic staging data before any customer rollout, and named delivery/support owners.
Assumptions: a current membership source exists and the team agrees the accepted file types. Confirm them before detailed product planning.
Dependencies: operating owner assignment, workspace-scoped identifiers, support status access and an accepted recovery process.
Exclusions: replacing identity, payment handling, a new CRM and unrestricted file ingestion.
Traceability: the companion CSV maps business needs to proposed product requirements and verification. Its statuses remain proposed.
Approval state: NOT APPROVED. Record the actual owner, scope version, decision, unresolved questions and date.

BLANK BRD
Document ID / version / owner:
Business problem and evidence references:
Decision to support:
Affected stakeholders and missing perspectives:
Current process:
Desired operating outcome:
Business requirements with stable IDs:
Business rules:
Success observations, population, period and measurement owner:
Constraints:
Assumptions and how to confirm them:
Dependencies:
Excluded outcomes:
Links to product requirements and verification:
Open decisions and risks:
Approval owner, decision, scope version and date:
Review trigger:

Use the level of documentation needed for your decision. A BRD is not a universal mandatory stage or a substitute for discussing unresolved needs.