Updated 27 September 2026: a practical guide to connecting business outcomes, user needs, software behavior and acceptance checks.
Business requirements describe the outcomes or capabilities an organization needs; functional requirements describe behavior the solution must provide. A target such as reducing unassigned enquiries explains why a project matters. A rule that routes a valid enquiry to an active owner describes something the software must do.
Both are necessary, but a list of completed features does not establish that the business problem has been solved. This guide follows a hypothetical support team from an operational problem to testable requirements. The numbers are illustrative planning targets, not client results.
Separate the problem, the outcome and the behavior
“We need a dashboard” already proposes a solution. Start with the observation behind it: support enquiries wait in a shared inbox because nobody knows who owns them. A dashboard might help, but clearer responsibility, an existing helpdesk configuration or a different staffing arrangement might also address that problem.
| Statement | Question answered | Example |
|---|---|---|
| Business problem | What is going wrong? | Enquiries remain unassigned, delaying the start of support work. |
| Business requirement | What outcome or capability is needed? | Reach an agreed level of timely enquiry ownership during the pilot. |
| User need | What must a person accomplish? | A support manager needs to find enquiries awaiting an owner. |
| Functional requirement | What behavior must the system provide? | Display unassigned enquiries in a manager's queue with receipt time and routing failure reason. |
| Acceptance check | What evidence demonstrates that behavior? | An enquiry with an unsupported category appears in that queue with the correct reason. |
Terminology varies between organizations. Agree the definitions your team will use and preserve the relationships even if your documents have different names. NASA's systems engineering guidance connects stakeholder expectations, measurable objectives and derived requirements through traceability. The lightweight software example below applies that general principle; it is not a NASA documentation procedure.
Define a business requirement you can evaluate
Record the starting problem as BP-01: enquiries can wait without a named owner. The support manager must first establish how often this happens. Review four representative weeks of incoming enquiries and record receipt time, first valid ownership time, channel and category. Label missing timestamps as unknown; do not quietly remove difficult cases from the analysis.
A proposed BR-01 for this hypothetical pilot is: at least 95% of eligible enquiries receive an active, named support owner within two business hours. Evaluate each of four consecutive weeks after the pilot begins. The manager must approve the target after reviewing the baseline and staffing capacity. It is a desired outcome, not a measured improvement or delivery guarantee.
Define “business hours” using one published timezone, working schedule and holiday calendar. Define eligibility before measurement: which channels, spam rules and duplicate rules apply? For each weekly receipt cohort, wait until every enquiry's two-hour window has elapsed. Then divide those assigned within the window by all eligible enquiries in that cohort. Keep overdue unassigned cases in the denominator; report unknown records separately and resolve them before declaring success.
Compare the baseline and pilot using the same definitions. A routing change may help, but staffing, incoming volume and category mix also affect the outcome. Check the proportion reassigned because of incorrect routing and the time to a meaningful first response, so rapid assignment alone does not hide poor service.
Trace the outcome into user needs and requirements
For the first release, assume one website enquiry form, three support categories and a manager-controlled mapping from category to an active owner. A fallback queue handles cases that cannot be assigned. Email ingestion and chat channels remain outside the pilot, with their existing handling process still owned by the support team.
The following table is a compact traceability register. BP-01 motivates BR-01; each row connects BR-01 to a user need, proposed behavior and evidence. The identifiers let a reviewer follow a change without relying on a paragraph's position in a document.
| Parent | User need | Functional requirement | Acceptance check |
|---|---|---|---|
| BR-01 | UN-01: the manager needs a reliable record of incoming work. | FR-01: save each valid form submission with its source identifier and server receipt time; repeated delivery of that identifier refers to the same enquiry. | AC-01: submit the same source identifier twice; one enquiry exists and retains its original receipt time. |
| BR-01 | UN-02: an agent needs clear responsibility for a new enquiry. | FR-02: assign the enquiry to the active owner configured for its category and record the assignment time. | AC-02: a valid Billing enquiry receives the configured active Billing owner; its recorded assignment time matches the event. |
| BR-01 | UN-03: the manager needs to find routing exceptions. | FR-03: when no valid owner mapping exists, retain the enquiry as unassigned and show it in the manager's queue with the reason. | AC-03: an unmapped category and an inactive mapped owner each produce an unassigned entry with the corresponding reason. |
| BR-01 | UN-04: the manager needs to resolve an exception. | FR-04: allow an authorized manager to assign an unassigned enquiry to an active support member and record the actor and time. | AC-04: the manager assigns a valid member; the enquiry leaves the unassigned queue and keeps its assignment history. |
A real register also needs an owner, priority, status, assumptions and links to the relevant test evidence. One business requirement can need several functions, and a function can support several outcomes. Do not force an artificial one-to-one mapping. If a function has no business rationale, user need or other justified source, investigate why it is included.
Make the acceptance checks specific enough to disagree with
“The routing works” cannot settle a review. For AC-02, prepare a known Billing category, a configured active owner and a valid enquiry. Check the saved owner and event time, not just a success message. Repeat with the owner deactivated and verify AC-03 instead. Save the fixture, expected result, actual result and tested version.
Agree the rules for less comfortable cases before estimating the release:
- Missing or invalid data: identify fields that block submission and how the sender receives an error. Do not silently accept and discard an enquiry.
- Changed configuration: specify whether editing a category mapping affects only future enquiries or triggers a reviewed reassignment of existing work.
- Simultaneous actions: if two managers assign the same enquiry, one action succeeds and the other sees the updated state instead of silently replacing it.
- Failed notification: preserve the assignment and expose notification failure for recovery. A delivered notification is separate from ownership.
- After-hours receipt: retain the actual receipt timestamp while calculating elapsed business time using the agreed calendar.
Some checks verify behavior; others demonstrate that users can complete the whole task. Include a short pilot with the people who will operate the queue. Passing the software acceptance checks proves the agreed behavior under the checked conditions. It does not prove BR-01 has been achieved; that requires the operational measurement described above.
Keep quality and security requirements alongside the workflow
The business-versus-functional distinction is not a complete specification. Access restrictions, data retention, availability, response times and recovery requirements still need owners and acceptance evidence. An agent must not gain permission to reassign enquiries merely because an assignment screen exists.
Security can produce both functional behavior, such as rejecting an unauthorized assignment, and broader constraints, such as restrictions on data access and storage. Avoid putting everything described as “security” into a vague nonfunctional bucket. Our functional versus technical requirements guide explains how to separate behavior, quality requirements and engineering decisions.
Prioritize a complete workflow and control changes
For this pilot, capture, valid assignment, exception handling, access controls and measurement are release essentials. A colored dashboard and workload forecasting can wait. Write down the consequence of deferring an item: removing exception handling would leave some real enquiries without an operational path, so it is not merely a cosmetic cut.
When someone requests a new channel, create a change entry rather than silently expanding FR-01. Record the reason, affected requirement IDs, data and permission changes, revised acceptance checks, delivery impact and decision owner. Adding email may require conversation matching and duplicate rules that the website form never needed.
Review the change with the support manager and delivery lead, then approve, defer or reject it with a reason. Version the agreed requirements and retain the previous decision. NASA's requirements-management guidance describes using traceability and impact assessment when requirements change. A small team can keep these links in a shared document or issue tracker.
Turn the example into your own project brief
Start with one problematic workflow, its business owner and baseline evidence. Write the intended outcome, agree the measurement, identify the users' tasks, and add observable system behavior with acceptance checks. Review the complete path with an operator before expanding into a feature backlog.
Download the software requirements template for an adaptable planning structure. Its worked example is separate from this enquiry-routing scenario; replace the sample assumptions, responsibilities and thresholds with your own decisions.
If the requirements reveal that an existing product could meet the need, our bespoke software development guide helps compare buying, configuring and building. For a custom project, our custom software development service starts with the workflow, constraints and first release you can meaningfully review.