Enterprise AI Project Wiki · Requirements and business scenarios
Business requirement
Also calledBusiness requirements · Organisational requirement · Business capability requirement · High-level business requirement
A business requirement is a manageable statement of the capability, business outcome, or high-level constraint an organisation must obtain to achieve an established business purpose. It connects a problem or opportunity to scope, stakeholder and user requirements, business rules, solution requirements, verification, and benefit measurement while remaining appropriately independent of a particular product, supplier, interface, or algorithm.
A business requirement says what capability or outcome the organisation must obtain, not which system to build
Purchase requests are returned twice on average is a current-state problem; reduce avoidable returns to an approved target is an objective; the business can identify evidence missing under the current rules before submission and show a verifiable basis is close to a business requirement. Build an AI review assistant has already selected a solution.
Business requirements sit between strategy and solution. They trace upward to a need, obligation, objective, or opportunity and downward to scenarios, user and stakeholder requirements, rules, processes, data, and system requirements. They are higher-level than directly codable statements but still specific enough to judge necessity, boundary, and business intent.
Industry usage is not uniform. Some organisations reserve the term for enterprise capability and outcome; others put every business-originated function into a Business Requirements Document. The requirements plan and glossary should define levels, IDs, approval authority, and downward traceability rather than relying on a document title.
How need, objective, business requirement, and solution requirement connect
These levels often appear in the same meeting and are easily called one generic requirement. A useful distinction is that need explains why change is considered, an objective says how far the organisation hopes to improve, a business requirement names the capability it must obtain, and solution requirements allocate that capability to people, process, and systems. Each lower level should still explain its link upward.
Business need, problem, or opportunity
Explains why change is being considered—cost, service failure, obligation, or opportunity—and starts the business case without prescribing a deliverable.
Objectives and expected benefits
Objectives set direction and target level; benefits are attributable value from change. They compare options and measure outcomes rather than being replaced by a feature tick.
Business requirement
States what the organisation must be able to do, which business outcome it needs, or which high-level constraint it must meet, with suitable solution independence.
Stakeholder and user requirements
Allocate the need to affected or accountable groups, roles, use contexts, and interaction quality so organisational value does not externalise harm or operating burden.
Rules and process requirements
Rules define acceptable state, conduct, and decisions; processes connect work and hand-offs. Together they elaborate the business capability.
System and solution requirements
Define functions, quality, interfaces, data, security, and operating characteristics that concrete products and enabling components must satisfy.
Acceptance and benefits realisation
Acceptance proves a deliverable meets approved requirements; post-release measurement determines whether the business problem improved. Conformance is not realised benefit.
What to record for a manageable business requirement
“Improve procurement efficiency” can begin a conversation, but it cannot support an investment or scope decision. The team needs the present problem, accountable owner, required capability, observable change, and unproven assumptions. These details do not make the sentence bureaucratic; they make it possible to approve, decompose, and review.
Stable ID and concise name
Use a cross-document identifier and a capability or outcome name, not a menu label, vendor module, or temporary task.
Authority and business owner
Record strategy, policy, regulation, audit, customer commitment, operating evidence, or sponsor decision and who can approve, interpret, and own benefit.
Problem, opportunity, and baseline
Describe current state, affected population, frequency, scale, loss or risk, and evidence period and limitations. Without a baseline value cannot be tested.
Required capability or outcome
Say what the organisation must be able to do, control, know, or achieve, not the application, model, button, database, or architecture.
Applicability and boundary
Name business unit, role, jurisdiction, product, channel, scenario, period, affected parties, and exclusions so one sentence does not expand to the whole enterprise.
Success measure and observation period
Link metric, baseline, denominator, data source, target, tolerance, and period, distinguishing delivery measures from operating benefits.
Constraints, assumptions, and dependencies
Record legal, policy, budget, time, data, process, people, third-party, and technical conditions, with an owner for each unvalidated assumption.
Priority, value, and consequence
Explain why now, trade-offs, and the outcome of delay or omission instead of marking everything highest priority.
Traceability, state, and version
Connect purpose and evidence to downstream requirements, delivery, verification, and benefit measures; retain draft, approved, deferred, superseded, and retired history.
How to discover and confirm a genuine business requirement
The first proposal from a business team is often simply the easiest solution to describe. Discovery steps back and compares operating data, complaints, audit findings, and frontline work, then separates visible symptoms from causes and worthwhile change. Technical staff can clarify possibilities, but they cannot decide business value on the sponsor's behalf.
Establish sponsorship and decision authority
Identify sponsor, process owner, budget and risk owners, and affected groups. Analysts clarify; they do not take the organisation's value and risk decision.
Build current-state evidence
Combine operating and financial measures, support cases, audit, observation, user research, and staff evidence, retaining period, population, and limitations.
Separate symptom, cause, and opportunity
A high return rate may result from unclear rules, fragmented evidence, responsibility conflict, or a system limitation. Do not turn the first symptom into a feature.
Define objective and business-as-usual
State the desired outcome, what happens without intervention, and alignment with strategy, policy obligations, and risk tolerance.
Extract solution-independent capability
Ask what a proposed chatbot would enable—retrieval, judgement, explanation, hand-off, or control—then compare process, training, non-AI, and technical options.
Check users, operations, and controls
Test alignment with real user needs, frontline work, support, privacy, security, finance, compliance, and affected people without accounts; document conflict and trade-off.
Define evidence, boundary, and dependency
Set success evidence, scenarios, exclusions, dependencies, assumptions, and consequence of omission so scope and business case can decide.
Review, approve, and baseline
Review across business, user, operations, technology, data, security, compliance, finance, and delivery; an authorised sponsor approves, while open issues remain explicit.
Checks before baselining a business requirement
Once approved, a business requirement influences budget, project scope, and the definition of success. An unclear boundary or missing baseline can then become very different delivery expectations across teams. The review asks whether the organisation is prepared to invest on this basis and can later tell whether the original problem improved.
- Necessary and evidenced?
It traces to a confirmed problem, opportunity, obligation, or objective and current-state evidence, not preference or a vendor demonstration.
Check source, baseline, and sponsor confirmation.
- At the organisational result level?
It states capability, outcome, or high-level constraint rather than a user control, report field, or component.
Check taxonomy and glossary.
- Solution-independent enough?
Beyond genuine constraints it permits process, people, rule, data, procurement, and technology alternatives rather than presupposing AI.
Check options and design decisions.
- Clear boundary?
Business unit, object, jurisdiction, scenario, time, and exclusions prevent incompatible interpretations of delivery size.
Check scenarios and exclusions.
- Measurable value and success?
Baseline, metric, data, target, and observation period are defined or a route to establish them is approved.
Check benefits map and measurement plan.
- Feasible with visible constraints?
Budget, time, data, authority, process, people, legal, and technical conditions have an initial assessment; unknowns are assumptions or risks.
Check feasibility, dependencies, and risks.
- Consistent and traceable?
It does not conflict with requirements, policy, and rules and traces upward to reason and downward to delivery and evidence.
Check conflict review and trace matrix.
Constructed example: from business problem to requirement
This customer-independent procurement situation follows the whole chain. It first treats repeated returns as a problem that still needs data, then defines improvement without weakening controls, and finally states the organisation's required decision, stop, and observation capabilities. An AI assistant remains only one implementation option to compare.
Problem and baseline
An imagined organisation sees unfamiliar-category requests repeatedly returned, increasing lead time and staff effort. Actual rate, duration, cost, and cause still require operating evidence.
Objective
Reduce avoidable evidence-related returns without weakening separation of duties, evidence completeness, or compliance; an authorised sponsor approves target and observation period.
BRQ-01: submission-readiness capability
Before formal approval, procurement can determine whether evidence meets current submission rules and explain missing items, applicable authority, and cannot-decide reasons.
BRQ-02: decision boundary
Readiness does not replace budget, procurement, or compliance approval or bypass separation of duties. Missing facts or conflicting rules stop automation and route to an authorised role.
BRQ-03: measurement and traceability
The business can observe first-time completeness, avoidable returns, processing time, and human takeover by category, reason, and rule version, and trace facts and rules used.
Downstream decomposition
User needs describe requester and approver outcomes; business rules define submission and authority; system requirements define retrieval, validation, records, access, and interface. An AI assistant remains one option.
Two kinds of success evidence
Acceptance first proves the chosen solution meets downstream requirements. Operations then measures return, lead time, risk, and cost over the approved period.
How business requirements govern scope, price, acceptance, and benefits
A business requirement does not finish its work when the requirements document is signed. It should continue to explain why this scope exists, which unknowns the estimate covers, what acceptance proves, and who observes benefits after go-live. If that trace breaks, a team can deliver every feature on time and still lose the reason for building them.
Maintain a business-requirements register
Store ID, statement, authority, owner, baseline, measure, value, priority, boundary, assumptions, dependencies, state, version, and links together.
Build bidirectional traceability
Link upward to problem, objective, policy, and business case and downward to scenario, user and stakeholder requirements, rules, scope, system requirements, tests, and benefit measures.
Let requirements inform scope
Scope selects which approved requirements and outcomes this phase delivers; deferred, partial, and externally owned portions remain explicit.
Price coverage and uncertainty honestly
The estimate names covered requirements, discovery, validation, client inputs, dependencies, and assumptions. An undecomposed high-level need is not fixed effort.
Separate delivery and benefit evidence
Acceptance criteria judge the deliverable; the benefits plan sets baseline, owner, data, period, and attribution. They are linked but close at different times.
Change the baseline through control
Changes in objective, policy, users, process, rule, data, or risk require impact on scope, solution, cost, schedule, test, operations, and benefits and an authorised decision.
Review business validity after go-live
Compare outcomes and distributional effects with objectives. If benefit fails, examine requirement, assumption, adoption, process, and environment before adding features or replacing the model.
Enterprise AI business requirements start with business decisions, not model capability
Model demonstrations usually begin with what the model can summarise, answer, or operate. Investment cannot begin there. The organisation first decides which work should improve, how far AI may influence it, and who detects and bears the consequences of error. Only then does a model capability have a defined place—and a reason to be accepted or rejected.
Use AI is not a business requirement
Models, agents, RAG, and automation are solution choices. State the needed capability or outcome and compare search, rules, process, conventional software, and no-change options.
Define intended and prohibited uses
Name supported roles, scenarios, and decisions and excluded objects, actions, and impacts; evaluate value only in that context.
Connect value and risk tolerance
Balance efficiency, quality, coverage, or response with error, bias, privacy, security, IP, reputation, and affected-group risks rather than one average metric.
Distinguish assistance, advice, and decision
State whether AI drafts, retrieves, classifies, recommends, or triggers actions; each authority level needs different evidence, oversight, access, and stops.
A better model score does not prove a better business outcome
Accuracy, recall, and latency describe test performance, but they do not say whether requests are returned less often, staff repeat less work, or controls remain effective. Map each model measure to scenario-specific errors, consequences, human effort, and task results, then use production business data to judge benefits.
Require insufficiency and human paths
On weak evidence, source conflict, unauthorised use, high risk, or tool failure, require refusal, clarification, human takeover, blocked action, and recovery with named responsibility.
Reassess the behaviour combination
Changes to model, prompt, knowledge, retrieval, rules, data, or tools can alter behaviour; define triggers to revisit requirement and risk assumptions.
Measure neglect and negative impact
Observe non-use, workarounds, false acceptance, rework, appeals, group differences, and effects on non-users so benefits do not hide transferred cost.
Concepts commonly confused with business requirements
Objectives, user needs, project scope, and system requirements all connect closely to business requirements, so the same sentence is often copied among their documents. Ask whether it explains why the organisation changes, states a capability the organisation must obtain, defines this phase's delivery, or specifies system behaviour. The answer changes approval, verification timing, and change impact.
| Related concept | How it differs from a business requirement |
|---|---|
| Business need, problem, or opportunity | Explains why change may be needed; the requirement says which capability, outcome, or constraint the organisation must obtain in response. |
| Business objective or KPI | Sets direction, target, and measurement; the requirement states an organisational capability or result needed to reach it. |
| Expected benefit | Benefit is attributable value, often realised after go-live; the requirement is one condition needed to create that value. |
| Business case | Compares status quo, options, cost, benefit, risk, and deliverability for an investment decision. Requirements are inputs and trace anchors, not the complete case. |
| User need | A user's prerequisite for an outcome in context; a business requirement starts from organisational capability and result. Both must be reconciled. |
| Stakeholder requirement | Expresses what a stakeholder class requires; a business requirement represents an authorised organisational purpose, not a collection of all requests. |
| Business rule | Defines terms, permitted states, obligations, prohibitions, and decisions. A requirement states needed capability or outcome and is constrained by rules. |
| Project scope | Defines this phase's delivery and work boundary. It selects approved requirements; one need may be phased or excluded. |
| Functional or system requirement | Defines concrete solution behaviour, quality, interface, and constraint downstream of business, scenario, and stakeholder analysis. |
| Solution or design | Selects the people, process, procurement, and technology combination and how it works. The business requirement should allow alternatives first. |
| Acceptance criterion | Provides a pass rule for a specific deliverable. The business requirement supplies rationale and may continue into post-release benefits evaluation. |
Sources and scope
This entry uses business requirement in its narrower business-analysis sense: a capability, outcome, or high-level constraint that an organisation must have to address a confirmed problem, exploit an opportunity, discharge an obligation, or achieve a business objective. Some organisations use the term for any request made by business staff, so every project should declare its taxonomy. This entry does not own the complete definition of business need, problem, business case, objective, KPI, benefit, user need, stakeholder requirement, business rule, project scope, system or functional requirement, design, acceptance criterion, or contractual requirement. An authorised business sponsor confirms the requirement; technical possibility does not create a business need.
- ISO/IEC/IEEE 29148:2018: lifecycle requirements-engineering processes, information items, and specification content; confirmed current in 2024
- PMI Guide to Business Analysis: standard and guide for high-quality requirements, stakeholder engagement, and intended business outcomes
- PMI Business Analysis: identify business needs, assess viable solutions, manage requirements, and deliver expected benefits
- NASA Stakeholder Expectations Definition: move from needs, goals, objectives, assumptions, constraints, and operating concepts to validated expectations
- NASA Technical Requirements Definition: transform expectations into validated, feasible, traceable technical requirements ready for baseline
- NASA Requirements Management: baselines, bidirectional traceability, status, and change across expectations and requirement levels
- HM Treasury Green Book 2026: case for change, objectives, business as usual, theory of change, strategic fit, options, costs, benefits, risks, and evaluation
- UK Government GovS 002: project framework for business case, benefits, requirements, scope, governance, traceability, risk, and change
- GOV.UK Service Manual: connect strategic objective, end and intermediate benefits, enabling changes, deliverables, and problem baseline
- NIST AI RMF Core: mission goals, business value, intended use, system requirements, risk tolerance, evaluation, and lifecycle review