Enterprise AI Project Wiki · Requirements and business scenarios
System requirement
Also calledSystem requirements · System-level requirement · System technical requirement · SyRS
A system requirement is a necessary, unambiguous, feasible, verifiable, and traceable normative statement allocated to a clearly bounded system of interest, defining a behaviour, performance level, interface, information need, quality, or constraint that the system must satisfy under stated conditions. The approved set forms the baseline used for design allocation, implementation verification, change control, and delivery evidence.
A system requirement defines what the whole system must satisfy, not merely a software feature list
System requirements translate validated stakeholder requirements, the concept of operations, business rules, risks, and constraints into a specification that can be designed, allocated, and verified at system level. One requirement states a behaviour, performance, interaction, quality, or constraint under stated conditions; the complete set also covers exceptions, support, retirement, and consistency.
The system of interest may be an end-to-end service rather than an application. Applicants and approvers, identity services, rules, data, an AI model, communication channels, cloud infrastructure, human escalation, monitoring, and support can be system elements or actors in its environment. The boundary must be explicit.
Requirements answer what must be satisfied; architecture and design select the elements and means. Requirements should remain solution-independent where practical, while approved interfaces, regulations, and architecture decisions may create justified derived requirements whose sources are recorded.
Define the system of interest, environment, and lifecycle first
The phrase “the system reviews the request” may mean application code to one person and include human approval, third-party interfaces, operations, and data sources to another. Without an explicit boundary, apparently agreed requirements leave responsibility outside the system. Map the interactions first so each obligation has an owner.
System and mission
State whether the specification governs an entire service, platform, subsystem, or procured product, and connect it to approved stakeholder outcomes. Different levels should not share an undifferentiated list.
System elements
Identify software, hardware or cloud resources, data, models, people, processes, communications, and support capabilities that may bear allocated requirements without freezing detailed design.
External actors and systems
Identify users, operators, identity platforms, payment or messaging services, regulators, and supplier APIs, including exchanged service, information, control, and responsibility.
Enabling systems
Development, deployment, monitoring, backup, service desk, training, secrets, and configuration management determine whether the system can be built, verified, operated, and retired.
Operating modes
Describe normal, degraded, offline, maintenance, emergency, migration, and retirement modes and how people and external systems use, supervise, and support them.
Physical and organisational boundary
Record deployment and network zones, accountable organisations, service hours, data location, retention, and lifecycle stages so secure, real-time, or long-term are not unconditional promises.
Assumptions and dependencies
Record assumptions about capacity, data quality, external availability, staffing, and policy stability with owners and validation. An exclusion may still impose an interface or constraint.
Requirement classes a complete baseline normally covers
A feature list says what a system does, but not how quickly, with whom it exchanges data, how it recovers, or who maintains it. The categories below act as an omission map for looking at one system from several directions. They do not justify combining several obligations in one statement.
Functions and states
What the system receives, calculates, decides, records, notifies, prevents, recovers, or hands off under triggers and modes, including permitted transitions and failure outcomes.
Performance and capacity
Response, throughput, concurrency, scale, accuracy, and resource limits with workload, measurement point, statistic, duration, and threshold—not merely fast.
Interfaces
Parties, medium or protocol, semantics, sequence, authentication, timing, errors, retries, idempotency, version compatibility, and responsibility—not only an endpoint URL.
Data and information
Inputs, outputs, quality, provenance, ownership, classification, access, retention, deletion, lineage, migration, audit, and master-data consistency.
Security, privacy, and safety
Protection needs translated into identity, access, separation of duties, confidentiality, integrity, availability, privacy, incident response, and fail-safe behaviour.
Usability and human factors
Effectiveness, efficiency, accessibility, error prevention and recovery, cognitive load, training, and human-supervision conditions for defined users and contexts.
Reliability and resilience
Permitted failures, recovery objectives, redundancy, data recovery, graceful degradation, continuity, disaster recovery, and supplier-failure behaviour with measurement windows.
Operations and support
Deployment, configuration, observability, logs, alerts, backup, diagnostics, patching, capacity, service desk, knowledge updates, and handover.
Modifiability and interoperability
Necessary boundaries for upgrades, replacement, migration, standard formats, compatibility periods, supplier exit, and technical debt.
Environmental and regulatory constraints
Applicable standards, deployment conditions, licences, prohibited technologies, procurement constraints, and mandated enterprise services, each with an authoritative source.
What to record in a verifiable system requirement
“The system shall process requests securely and reliably” gives neither design boundaries nor a testable outcome. A verifiable requirement names the trigger, object, behaviour, performance, or constraint and retains its source, allocation, and verification method. If it fails, the team can then identify the unmet obligation.
Identifier, level, and class
Give each item a durable ID, system or subsystem level, category, and baseline so allocation and change do not depend on document position.
Normative subject and obligation
Name the system bearing the obligation and use the controlled shall or equivalent convention; keep explanation, rationale, goals, and advice distinguishable.
Trigger, precondition, mode, and state
State when it applies, including actor, event, data condition, operating mode, and authority. Unconditional wording can extend normal behaviour into unsafe cases.
One observable behaviour or constraint
Carry one principal obligation and name input, processing boundary, output, state, or prohibited result. Split compounds, vague pronouns, and implementation commentary.
Measure and tolerance
A value needs measurement object and point, sample, load, window, percentile or confidence basis, tolerance, and exceptions. An unapproved threshold remains a governed TBD.
Interface, data, and failure behaviour
Specify semantics, authorisation, error, timeout, retry, degradation, alert, and recovery, especially what must not happen with insufficient evidence or unavailable dependencies.
Source, rationale, and risk
Trace to stakeholder requirements, rules, standards, risks, or architecture decisions, preserving why it is necessary and the consequence of failure.
Verification method and criteria
Preselect inspection, analysis, demonstration, or test with environment, sample, instrument, expected result, and responsibility. Testable is not the same as verified.
Allocation, trace, owner, and status
Connect responsible elements, lower requirements, design, interfaces, tests, and results; record owner, priority, version, approval, deferment, waiver, and changes.
How to derive a complete set of system requirements
Derivation is not a translation of stakeholder language into technical vocabulary. The team understands the observable service result first, then uses scenarios, risk, and architecture analysis to allocate responsibility across software, people, processes, data, and external services. New constraints discovered on the way need an explicit rationale rather than a hiding place in design.
Confirm upstream authority
Check that business objectives, stakeholder and user requirements, rules, risks, and constraints have sources, states, and approvers. Engineers must not silently resolve stakeholder conflicts.
Establish operations and boundary
Use normal, exceptional, insufficient-information, failure, maintenance, and retirement scenarios to map people, external systems, inputs, outputs, states, and responsibilities.
Analyse functions and information
Decompose outcomes into functions, decisions, transformations, records, and hand-offs, identifying inputs, outputs, controls, failure modes, and consequences.
Identify interfaces and elements
Analyse human, service, data, model, operations, and support interfaces, creating enough logical architecture for allocation without fixing detailed implementation.
Add qualities and lifecycle constraints
Inspect performance, security, privacy, human factors, reliability, resilience, maintainability, monitoring, migration, and retirement by risk.
Decompose, derive, and allocate
Break upper obligations into system and element requirements, retain engineering rationale, and test joint sufficiency without adding source-free gold plating.
Verify quality and validate the set
Review every statement, then use scenarios, models, prototypes, analysis, and stakeholder playback to establish that the complete set represents the right need.
Approve baseline and change control
Control a named version of requirements, interfaces, assumptions, and traces with impact analysis and evidence-update rules. A baseline may change only visibly and with authority.
Quality gates before baseline approval
Once approved, the baseline drives design, procurement, interface coordination, and testing. Finding an unverifiable requirement later can affect several components and contractual responsibilities, not just wording. Review each statement and the set as a whole for gaps, conflicts, and allocations with no owner.
- Necessary, correctly levelled, and sourced?
Each obligation traces to an upstream need, risk, standard, or recorded derivation and belongs at this level.
Inspect source, rationale, level, and approval.
- Atomic, clear, and loophole-free?
Subject, condition, action, object, outcome, and prohibited behaviour have one meaning without appropriate, intelligent, rapid, etcetera, or normally.
Use independent paraphrase, counterexamples, and glossary.
- Complete and consistent?
Scenarios cover functions, performance, interfaces, data, qualities, operations, and retirement; states, units, terminology, and requirements do not conflict.
Review class coverage and scenario matrix.
- Feasible without accidental design?
It is achievable within technical, data, people, legal, budget, and schedule conditions and does not mandate an unapproved supplier or algorithm.
Review feasibility, prototypes, and design decisions.
- Verifiable with sufficient criteria?
A finite repeatable method can judge compliance with environment, sample, load, expectation, tolerance, and failure criteria defined.
Inspect the verification matrix and plan.
- Bidirectionally traced and allocated?
Every necessary upstream outcome has coverage; each system requirement has a source and links to elements, design, and evidence.
Inspect upward, downward, and orphan reports.
- Risks, assumptions, and change controlled?
Dependencies, waivers, and TBDs have owners and dates; a component or interface change reveals all affected objects.
Inspect risk, issue, configuration, and change records.
Constructed requirements for a procurement-request service
This customer-independent procurement service shows one upstream outcome decomposed into validation, access, explanation, failure-handling, and record requirements. The identifiers and criteria illustrate structure only; real conditions must come from approved rules, risk decisions, and the operational environment.
SYS-101: pre-submission completeness
When an authorised applicant requests draft submission, the system shall use the approved rule version effective for that request to inspect required fields and evidence and, before changing formal status, return every missing item, rule ID, and correction location.
SYS-102: no false approval
The check and any AI explanation shall not issue approval, reserve budget, or mark a request approved; only an authorised actor satisfying separation of duties through the formal decision interface may create those effects.
SYS-103: access and separation
Before display, submission, and approval, the system shall independently evaluate approved identity and business permissions, block self-approval, and record the policy version behind refusal.
SYS-104: stop on missing evidence
If evidence cannot be read, the rule version cannot be established, or authoritative sources conflict, the system shall stop automated submission and decision, preserve state, explain the blocker, and route to the designated human queue.
SYS-105: decision trace
Under approved retention, the system shall record the request, input facts, rule and knowledge versions, execution path, acting and represented identities, decision, override rationale, and time for linked authorised audit retrieval.
SYS-106: performance TBD
The response target must be approved against representative size, concurrency, observation point, percentile, and window. Until evidence exists it remains a governed TBD, not an invented two-second promise.
How the baseline governs design, verification, change, and handover
System requirements are not a document developers read once. Design explains how each is satisfied, tests return evidence, changes analyse impact, and handover tells the receiving team which version and limitations remain current. Keeping that chain intact connects production behaviour to the responsibility originally approved.
Specification and register
Maintain the approved set, glossary, assumptions, TBDs, sources, rationale, owners, and status. Stable identifiers and controlled records sustain management beyond document sections.
Allocation and trace matrix
Connect stakeholder to system requirements and then elements, interfaces, design, verification, results, defects, and waivers; find uncovered upstream and source-free downstream items.
Interface and configuration baselines
Align requirement versions with interfaces, schemas, rules, models, knowledge, configuration, and deployment. 'Latest requirements' does not identify the object tested.
Change impact and authority
Analyse stakeholder, architecture, data, security, supplier, test, cost, schedule, and operation effects; use matching authority and update the evidence chain.
Verification and validation
Verification shows a named implementation satisfies requirements; validation shows the integrated system serves stakeholder needs in context. Record object, environment, result, deviation, and authority.
Operation and handover
Transfer the baseline, architecture, interfaces, configuration, results, known limits, monitoring, recovery, runbooks, dependencies, open issues, and change method so the receiving team can sustain it.
Enterprise AI requirements must cover the composite system and variable behaviour
Users encounter a complete service, not an isolated model. A change in prompts, knowledge, retrieval, tools, access, or human workflow can alter the result for the same input. Requirements therefore identify a reproducible combination and define how the system remains safe under change, insufficient evidence, and high risk.
Identify the versioned composite
Separate application, orchestration, model, prompts, knowledge and retrieval, rules, tools, filters, and human workflow. Evidence must name a reproducible combination, not just a model brand.
Define intended and prohibited uses
State permitted assistance, recommendation, and automation tasks, users, and environments, plus decisions, data, and situations outside the capability boundary.
Govern evidence and knowledge
Specify authoritative sources, permissions, version, freshness, citation, and conflict handling. Retrieved content is not automatically correct, applicable, or disclosable.
Stop under insufficiency or high risk
Define missing input, low confidence, conflict, uncertain permission, and risk classes requiring refusal, preserved state, and human routing; deterministic controls should enforce hard stops.
Control tools and side effects
For read, write, send, approve, delete, and pay, define least privilege, parameter checks, confirmation, idempotency, timeout, rollback, and audit. Text generation is not authority to act.
Oversight is real only when a person can actually take over
At the right moment, the system must place source facts, cited rationale, and current state in front of an authorised person and let that person pause, correct, reject, or take over. It also defines the safe state when nobody responds. “Human review when needed” may otherwise have neither a recipient nor a waiting mechanism.
Evaluate by risk stratum
Define samples, repetitions, statistics, minimums, severe failures, and hard stops separately for normal, exceptional, insufficient, adversarial, and affected-group conditions.
Monitor component and supplier change
Require notification, impact analysis, regression evaluation, staged release, rollback, incident response, and reapproval when models, knowledge, prompts, policy, data, or APIs change.
Retain a non-AI path
When AI is unavailable, unsuitable, or suspended, critical work needs a deterministic or human fallback with capacity, timing, records, and recovery-verification requirements.
How system requirements differ from neighbouring concepts
From business need to test case, every level discusses something that must be satisfied, but the subject and precision differ. System requirements constrain the whole system of interest. They integrate upstream stakeholder outcomes and allocate responsibility downstream, but neither a design nor a collection of tests replaces them.
| Concept | Boundary from a system requirement |
|---|---|
| Business requirement | States an organisational capability, result, or high-level constraint; system requirements translate approved outcomes into verifiable obligations at system level. |
| Stakeholder requirement | Centres on services, interactions, and constraints needed by a stakeholder class; system requirements integrate and allocate the agreed upstream set. |
| User requirement | Supports interactive-system design and evaluation from user needs and capabilities; it does not cover every interface, operation, or engineering constraint. |
| Business rule | Defines business-governed meanings, permissions, obligations, prohibitions, and decisions; a system requirement governs how the system supports or enforces it. |
| Functional requirement | Specifies behaviour and is one class of system requirement; the baseline also covers performance, interfaces, qualities, operations, and constraints. |
| Non-functional requirement | Often groups performance, security, reliability, and usability; these remain measurable formal system requirements, not aspirations. |
| Software requirement | Is allocated to software; the wider system baseline can allocate obligations to hardware, data, people, processes, and external services. |
| Interface requirement | Governs interaction across a boundary and may live in the baseline or an interface specification. An endpoint alone is incomplete. |
| Architecture and design | Select elements and means of realisation. They are constrained by requirements and can justify derived requirements, but do not replace what must be satisfied. |
| Project requirement | Constrains delivery work—budget, schedule, reporting, resources, or process—whereas a system requirement constrains the delivered system. |
| Acceptance criterion and test case | A criterion gives a pass rule and a test case gives inputs, procedure, and expected result. They verify requirements but do not replace the baseline. |
| Contract specification | May select requirements as legal obligations and add precedence, change, and liability terms. An internal register does not automatically become contract content. |
Sources and scope
This entry explains a system requirement in the systems-engineering sense: a requirement assigned to a clearly bounded system of interest that states the functions, performance, interfaces, data and information handling, quality attributes, protections, operational support, or lifecycle constraints it must satisfy, as part of an allocatable, verifiable, bidirectionally traceable, change-controlled baseline. A system is not necessarily software alone; it may include hardware or cloud resources, data, models, people, processes, communications, external services, and enabling systems. This entry does not fully define business, stakeholder, user, business-rule, functional, non-functional, software, interface, architecture and design, project, acceptance-criteria, test-case, or contractual specifications, and it does not replace project-specific safety, privacy, regulatory, or engineering review.
- ISO/IEC/IEEE 15288:2023: system lifecycle processes, the system of interest, system elements, and shared technical and management processes
- ISO/IEC/IEEE 29148:2018: requirements-engineering processes, system requirements specifications, requirement characteristics, and information items; confirmed current in 2024
- NASA Technical Requirements Definition: a complete set spanning functional, performance, interface, environmental, safety, human-factors, and quality requirements
- NASA Logical Decomposition: decomposing requirements and functions, analysing inputs, outputs, and failures, and allocating derived requirements through logical architecture
- NASA System Design Processes: iteration among stakeholder expectations, technical requirements, and logical decomposition, with validation against the right problem
- NASA Requirements Management: baselines, allocation, bidirectional traceability, status, and change control across requirement levels
- NASA SWE-050: deriving clear, complete, feasible, verifiable, and bidirectionally traceable software requirements from customer, system, and operational inputs
- NASA SWE-055: lifecycle validation that requirements reflect stakeholder needs, distinct from verifying implementation compliance
- NIST SP 800-160 Vol. 1 Rev. 1: protection needs and trustworthy secure systems engineering throughout the lifecycle
- NIST AI RMF Core: intended use, roles, risk tolerance, data and components, human oversight, measurement, monitoring, and lifecycle governance