Enterprise AI Project Wiki · Requirements and business scenarios
Stakeholder requirement
Also calledStakeholder requirements · Stakeholder needs and requirements · Interested-party requirement
A stakeholder requirement is an authorised, reconciled, traceable, and verifiable normative statement that translates the service, interaction, quality, information, control, or constraint needed by an identified stakeholder or stakeholder class in a defined lifecycle and operational context. It connects upstream needs and expectations to system requirements and provides a basis for solution validation.
Stakeholder requirements are a common service specification, not a collection of opinions
Stakeholders can include acquirers, sponsors, users, operators, maintainers, support teams, business owners, security and compliance roles, regulators, external-system owners, suppliers, and people affected by a decision without holding an account. Formal approval, specialist constraint, system use, and exposure to consequences are different relationships; they cannot all be reduced to the customer decides.
Raw inputs such as make it faster, never disclose this, retain human approval, or copy the current form remain expectations, needs, candidate constraints, or design clues. The project confirms source and context, removes ambiguity, finds conflict, assesses feasibility, and converts them into traceable and verifiable statements about service and operational interaction before baselining them.
Stakeholder requirements normally sit between needs and system requirements. They focus on services, interactions, qualities, and constraints observable or borne by stakeholder classes. System requirements then allocate the common set across product, people, process, interface, and enabling systems. More implementation detail does not make a stakeholder requirement better.
Stakeholder classes a project should consider
Stakeholders are not limited to people invited to a requirements workshop. One funds the work, another uses it daily, another handles incidents, and another bears compliance responsibility. Some never receive an account but are still affected by a classification or decision. Separating these roles shows who supplied a requirement, who may confirm it, and who carries the consequence of omission.
Customer, sponsor, and funding authority
Set business purpose, funding, and success constraints within their authority. Funding does not allow them to waive another party's legal, safety, security, or user rights.
Direct and represented users
People operating the service and people served through an agent, caseworker, carer, or employee need separate tasks, capabilities, access conditions, and outcomes.
Casework, approval, and oversight roles
People who process cases, decide, review exceptions, or own outcomes need different information, access, explanation, hand-off, and separation-of-duties controls.
Operations, support, maintenance, and training
Monitoring, incident handling, content, accounts, backup, versioning, service desk, and training determine whether the service remains operable after release.
Data, privacy, security, compliance, and legal roles
Provide authorised constraints for purpose, retention, access, controls, audit, duties, and incident response; they cannot be postponed to one pre-launch approval.
External systems and service owners
Identity, payment, messaging, data, and model providers own interfaces, capacity, changes, support, and terms and are more than technical endpoints.
Affected non-users
People classified, ranked, refused, investigated, or affected by resource allocation may need notice, explanation, correction, appeal, fairness, and protection without using the system.
Procurement, audit, insurance, and regulators
Bring evidence, liability, licensing, supply-chain, financial, auditability, and continuing-compliance constraints whose authority differs from preference.
Future operators and retirement parties
Successor teams, replacement suppliers, data recipients, and retirement owners need code, data, configuration, records, deletion, and continuity conditions beyond the build phase.
What to record for a manageable stakeholder requirement
“Finance wants tighter control and operations wants speed” is only the outline of a conflict. A manageable requirement identifies the represented group, context, result to provide or protect, confirmation authority, and eventual allocation to systems and processes.
Stable ID and one obligation
One durable ID carries one main result or obligation so conflict, allocation, change, and verification can be handled independently.
Stakeholder class and representation
State whom it represents, who participated or was authorised to represent them, the evidence base, and confirmation authority. One interviewee is not a whole class.
Source, need, and rationale
Link research, business objective, policy, law, contract, operational evidence, risk, or parent requirement and state the consequence of non-satisfaction.
Lifecycle and use context
Specify acquisition, design, deployment, operation, support, change, or retirement and the role, trigger, location, channel, frequency, and preconditions.
Required service, interaction, or constraint
State an observable receiving, providing, viewing, deciding, correcting, taking over, auditing, or protecting result without prematurely fixing design.
Quality, limits, and tolerance
Where time, accuracy, capacity, availability, accessibility, security, or retention matters, define object, conditions, unit, statistic, and permitted range.
Priority, conflict, and trade-off status
Record value, risk, mandatory status, urgency, competing statement, decision maker, and rationale rather than treating majority vote or seniority as an algorithm.
Verification and confirmation
Define inspection, analysis, demonstration, test, or operational evaluation and who provides samples, witnesses, and confirms the result.
Allocation, traceability, version, and state
Link needs to system, people, process, interfaces, tests, and acceptance and retain draft, agreed, deferred, rejected, superseded, retired, and change history.
How needs and expectations become stakeholder requirements
Elicitation is not a transcription of workshop comments. The team combines observation, operating records, policy, and incident experience to understand the task and responsibility behind each statement. Scenario playback then turns preferences, constraints, and proposed solutions into outcomes that the relevant people can confirm together.
Define system boundary and lifecycle
Name the product or service layer, covered lifecycle stages, and operational interfaces so the stakeholder set and questions do not expand without limit.
Map stakeholders and authority
Identify classes by use, decision, operation, constraint, supply, and impact and record representation, influence, authority, participation method, and likely omissions.
Collect multiple forms of evidence
Combine interviews, observation, workshops, user research, operations data, support, audit, policy, contract, interface material, and incidents. The loudest meeting voice is not the sole source.
Develop scenarios and operational concepts
Have stakeholders explain normal, exceptional, insufficient-data, failure, support, change, and retirement contexts to expose hidden needs.
Separate need, expectation, constraint, and solution
Retain original wording and source, then ask why, when it applies, and what outcome is sufficient; translate controls and product names back into needed results.
Write atomic, verifiable statements
Name responsible subject, trigger, service or interaction, object, limits, and necessary quality in shared vocabulary. Assign owners and methods to unresolved values.
Play back, validate, and negotiate
Use typical, boundary, counterexample, and failure cases with originating stakeholders to check meaning, completeness, feasibility, conflict, and unintended effect.
Approve a common baseline and allocate
Business, customer, and constraint owners confirm within their authority, then allocate to system, people, process, interface, and enabling products. Developers do not choose between conflicting authorities.
How to decide when stakeholder requirements conflict
Conflict does not mean one party fails to understand the project. A requester may reasonably want speed, an approver needs evidence, and security may need to withhold sensitive logic. First establish whether the needs truly apply to the same context, then present non-negotiable constraints, alternatives, and effects to the person authorised to decide.
Confirm it is the same context
Show immediately and show only after approval may refer to draft guidance and formal decisions. Split role, scenario, data, and time before declaring a conflict.
Identify non-tradeable constraints
Applicable law, contract, safety, privacy, security, and formal policy may set mandatory bounds, while authorised roles still confirm applicability and interpretation.
Make evidence and impacts visible
Compare user outcome, business value, risk, operating burden, cost, schedule, fairness, and recoverability; technical limitation alone is not a complete decision record.
Seek layered or alternative satisfaction
Role access, stages, thresholds, review, notice, offline channels, or differentiated service levels can reconcile needs without silently reducing an approved necessary outcome.
Obtain a transparent authorised decision
The analyst organises evidence and options; the relevant business, risk, policy, or contract authority decides and records rationale, conditions, dissent, and review date.
Do not hide unresolved conflict in a false baseline
Keep an open state, impact, and owner and restrict scope or pause design when needed. Ambiguous prose merely postpones conflict until acceptance or production.
Checks before baselining stakeholder requirements
A common baseline will drive design, estimates, and acceptance; it is not a set of interview notes. Review the wording, but also whether the right people were found, representatives are credible, and conflicts were genuinely decided. Otherwise “stakeholders agreed” may only mean that the people carrying the consequences were absent.
- Adequate stakeholder coverage?
Direct users, operations, controls, external services, and affected groups are considered, with non-participation and representation limits recorded.
Check stakeholder map, recruitment, and authority.
- Necessary and sourced?
Each statement traces to a need, evidence, duty, or purpose and explains non-satisfaction, not merely preference or a suggested solution.
Check source, rationale, and counterexample.
- Clear context and boundary?
Role, lifecycle stage, trigger, object, location, channel, data state, and exclusion are sufficiently precise.
Check operational concept, scenarios, and scope.
- Singular, clear, and solution-independent?
Readers reach one interpretation, one statement has one obligation, and no unjustified control, supplier, or algorithm is frozen.
Check peer review, glossary, and design decisions.
- Complete, consistent, and feasible?
Normal, exception, operation, support, interface, and retirement needs are covered; conflicts are decided and conditions support delivery.
Check coverage, conflict matrix, and feasibility.
- Verifiable and confirmable?
A finite method names environment, sample, metric, expected result, tolerance, witness, and confirmation authority.
Check verification method and responsibility.
- Traceable and changeable?
It traces to stakeholder needs and down to allocation and evidence so affected people and components can be analysed on change.
Check bidirectional links, version, and state.
Constructed stakeholder requirements for a procurement service
This customer-independent procurement setting shows one service from the perspectives of requester, approver, compliance, operations, and an affected supplier. Their required outcomes differ and constrain one another. The important part is how those outcomes continue into access, rules, data, interfaces, and support processes.
SHR-01: requester
When a requester asks to submit a draft under current rules, before formal state changes the service shall identify each missing item, applicable basis, and correction route and retain entered content.
SHR-02: business approver
When viewing a pending decision, an approver shall see authorised source facts, applicable rule version, completed reviews, and unresolved exceptions; completeness shall not be presented as an approval recommendation.
SHR-03: compliance and audit
The service shall prevent the same accountable party from requesting and finally approving and retain operator, represented requester, decision, rule version, override reason, and time under approved access and retention rules.
SHR-04: operations and support
On unavailable authority or conflicting conclusions, operations shall identify affected work, pause automatic submission, route to the named role, and replay incomplete work after recovery without duplicate external actions.
SHR-05: affected supplier
When material is refused or supplementation requested, an authorised contact shall receive a publishable reason, next step, and appeal or human-contact route without exposing another supplier or anti-fraud controls.
The common set is not simple addition
Less requester input, sufficient approval evidence, and least access may pull in different directions. Context and authority must reconcile them rather than selecting one voice.
Allocation and verification
Allocate into identity, rules, data, interface, logs, workflow, and support and verify through user tasks, denied-access tests, audit inspection, failure exercise, and notice review.
How stakeholder requirements become a maintainable common baseline
Representatives, policy, external services, and affected populations can all change during a project. A common baseline does not freeze requirements forever. It preserves the links among original input, formal statement, approval authority, and downstream evidence so each change identifies the people who must participate again.
Maintain stakeholder and requirement registers
Connect class, representative, authority, and participation to requirement ID, source, statement, priority, verification, allocation, state, and version.
Separate raw input from formal requirement
Store interview words, meeting views, source provisions, and interpreted requirements distinctly so neither interpretation masquerades as an original promise nor a wish as scope.
Build bidirectional traceability and coverage
Trace need, business purpose, and constraint through stakeholder and system requirements to design, test, and acceptance; every feature can explain whom it serves and why.
Define approval and change authority
Business, user representatives, security, legal, operations, and customer confirm only within delegated authority; cross-authority conflict enters governance rather than relying on silence.
Make estimates and scope cite the baseline
State covered requirements, discovery still required, customer inputs, deferred needs, external ownership, and exclusions instead of packaging open expectations as fixed commitments.
Return verification evidence to stakeholders
Results aggregate version, environment, sample, outcome, and issue by requirement ID so the class or authorised representative can confirm the intended service.
Review through operation and retirement
Reassess representation and validity when organisation, policy, supplier, population, risk, or evidence changes; retirement includes data, continuity, notice, and handover parties.
Enterprise AI expands the stakeholder boundary beyond direct users
One person may operate an AI output while it affects someone who has never signed in. The service also depends on data providers, model vendors, knowledge owners, and human reviewers. Interviewing only the person at the chat interface misses data rights, supplier change, appeal, and incident-response requirements needed for accountable operation.
Identify lifecycle AI actors
Include data providers and annotators, model and knowledge owners, prompt and evaluation teams, tool and interface owners, deployment operations, reviewers, approvers, incident response, and suppliers.
Include people affected by decisions
Those ranked, screened, refused, priced, investigated, or described may need notice, explanation, correction, appeal, fairness, and protection without operating the system.
Distinguish direct evidence from proxy claims
Managers do not automatically represent frontline users and purchasers cannot waive data-subject rights. Record proxy authority, evidence, and groups not directly engaged.
Give human oversight a person, information, and an action
“Human in the loop” sounds reassuring but does not say who receives what or when. State which inputs, model and knowledge versions, rationale, and uncertainty the reviewer can see, and which step they may approve, reject, correct, take over, or stop. Without those conditions, the human exists in the diagram but may not be able to prevent an error.
Constrain the data and model supply chain
Data rights, model services, content policies, log use, region, retention, change notice, outage, and substitution originate with external parties and must flow into contracts and system requirements.
Reconcile transparency and security
Affected people need understandable reasons while security and anti-fraud may restrict details. Define public explanation, restricted audit evidence, and authorised review instead of model-selected disclosure.
Evaluate with multi-stakeholder evidence
Separate samples and measures for task completion, business outcome, human workload, unauthorised disclosure, group difference, appeal, and recovery; average accuracy cannot represent all requirements.
Re-engage after material change
Model, knowledge, prompt, tool, use, or population changes trigger participation by the affected stakeholder classes; old agreement does not automatically cover new behaviour.
Concepts commonly confused with stakeholder requirements
A stakeholder, an expectation they express, a reconciled formal requirement, and a contractual promise are four different levels. Mixing them can turn a casual suggestion into a scope commitment, or leave a genuine legal or operational constraint as a workshop comment.
| Related concept | How it differs from a stakeholder requirement |
|---|---|
| Stakeholder | A person or group affected by, interested in, or accountable for a system. A stakeholder requirement is the analysed and authorised normative service statement. |
| Stakeholder need or expectation | May be unquantified and unreconciled needs, wishes, capabilities, and constraints. A requirement is contextual, negotiated, traceable, and verifiable. |
| Stakeholder opinion or feedback | Evidence and discovery input without automatic scope, priority, or approval. Representation, rationale, and authority still require review. |
| Business requirement | Represents organisational capability, outcome, or high-level constraint. Stakeholder requirements express what different groups require from system services; their mapping is many-to-many. |
| User need | A prerequisite for a user outcome in context. Users are one stakeholder class, while regulators, operators, data subjects, and affected people may not be direct users. |
| User requirement | Specialises interactive-system use and use-related quality. Stakeholder requirements also cover acquisition, operations, support, interfaces, regulation, maintenance, and retirement. |
| System requirement | Transforms the common stakeholder set into complete functions, performance, interfaces, data, security, and constraints allocated to system elements. |
| Business rule | States approved definitions, obligations, prohibitions, and decisions. A stakeholder requirement states which service or protection a class needs and may cite many rules. |
| Project requirement | May constrain work method, schedule, reporting, documentation, or governance. Stakeholder requirements primarily concern lifecycle service and operational interaction. |
| Acceptance criterion | Applies a requirement to a deliverable, version, environment, and decision. The stakeholder requirement is the upstream necessary outcome. |
| Contract term | Creates legal and commercial rights and duties and may incorporate requirements. A requirements register is not automatically a contract and does not replace legal interpretation. |
Sources and scope
This entry explains stakeholder requirements in system and service projects: requirements analysed, reconciled, and authorised from the needs, expectations, responsibilities, and constraints of identified stakeholders or stakeholder classes, used to specify and validate system services and interaction with the operational environment. They are not casual opinions, wishes, preferences, or proposed solutions, nor merely a stakeholder register, engagement plan, business requirement, user need, user requirement, business rule, system requirement, project-management requirement, acceptance criterion, or contract clause. Standards and organisations use stakeholder needs and requirements, stakeholder requirements, and stakeholder expectations at different levels, so a project must declare its vocabulary and approval model. This entry is not legal advice and does not resolve competing rights or regulatory duties for authorised decision makers.
- ISO/IEC/IEEE 15288:2023: common system-lifecycle process framework involving stakeholders, acquisition and supply, and recursive application to system elements
- ISO/IEC/IEEE 29148:2018: requirements-engineering processes, stakeholder requirements specifications, information items, and content; confirmed current in 2024
- NASA Stakeholder Expectations Definition: identify customers and other stakeholders and build validated expectations from needs, objectives, constraints, scenarios, and operational concepts
- NASA Systems Engineering Handbook Appendix: definitions of stakeholder and stakeholder expectation and the boundary where expectations become requirements
- NASA Technical Requirements Definition: recursively transform expectations into clear, complete, feasible, verifiable, and bidirectionally traceable technical requirements
- NASA Requirements Management: baseline, allocation, bidirectional traceability, and change for expectations, customer requirements, and product requirements
- NASA SWE-055: validate that software requirements reflect stakeholder requirements and expectations across system, function, data, security, and performance
- UK Government GovS 002: stakeholder engagement, requirements, traceability, governance, business case, scope, risk, and change management
- GOV.UK Service Manual: engage policy, operations, legal, security, commercial, analytical, and leadership stakeholders and define affected people, outcomes, and measures
- NIST AI RMF Core: multidisciplinary AI actors, external and affected communities, system requirements, impacts, human oversight, evaluation, and continuing feedback