Enterprise AI Project Wiki · Requirements and business scenarios
Software requirement
Also calledSoftware requirements · Software system requirement · Software item requirement · Software technical requirement
A software requirement is a normative statement of a function, performance level, data obligation, quality, protection, or constraint that a named software object must satisfy under explicit operating, state, input, interface, resource, and failure conditions. The approved set translates system and stakeholder intent into a software delivery baseline that can be assigned, verified, traced, and maintained.
Software requirements state what software must carry, not merely rename system requirements
An enterprise system commonly combines software, cloud or hardware resources, data, external services, people, and business procedures. System requirements constrain the combination; software requirements own only the obligations explicitly allocated to software. If an authorized person must make the final approval, the software must not be made an automatic approver merely to create a complete list. It can present evidence, accept the decision, enforce authority, and record the outcome.
Software requirements form a complete set, not a synonym for functional requirements. The set includes states and modes, internal and external interfaces, data, performance, security and privacy, dependability and recovery, resources, operating environment, adaptation, installation, upgrade, maintenance, support, and sourced implementation constraints. Omitted classes tend to return later as integration, production, or handover failures.
NASA derives flowed-down and derived software requirements from systems-engineering requirements, safety and reliability analysis, hardware specifications, and design, and expects the set to be clear, complete, consistent, feasible, verifiable, and traceable upward. Software teams can clarify a parent requirement but cannot create business obligations from technical preference alone.
Establish the software object, operating context, and responsibility boundary first
A system may depend on a business application, identity platform, database, supplier service, and human process. Software requirements constrain only the named software item. A clear boundary prevents the team promising an external capability as its own or pushing protection that software should provide onto operators.
Software of interest
Identify a complete software system, business application, backend, mobile client, embedded program, model orchestrator, or configuration item and label the allocation level of each requirement.
Internally controlled items
List code, configuration, rules, scripts, schemas, models, or prompts governed by the baseline. Whether model and data artifacts are software configuration items is a project decision, not a universal assumption.
Hosting and enabling environment
Distinguish operating system, runtime, database, network, hardware, cloud, and operations platform dependencies from software deliverables and customer- or supplier-provided capabilities.
External people and systems
Identify users, operators, administrators, maintainers, devices, upstream and downstream systems, suppliers, and human procedures, including authoritative sources and owners.
Modes and lifecycle
Cover initialization, normal, peak, maintenance, degraded, disconnected, recovery, migration, upgrade, and retirement. Software obligations can change by mode.
Results software cannot assure alone
Business benefit, human response, external-service availability, hardware reliability, and organisational compliance usually require shared accountability. Allocate only the software-verifiable part.
- Does the boundary support estimate and ownership?
Separate current development, configuration, integration, customer preparation, and recurring cost instead of treating the enterprise operating environment as software development.
Check context, software decomposition, scope, and responsibility matrix.
- Has every system requirement been allocated?
Allocate to software, hardware, people, process, or services, including shared obligations. Assign an owner and closure decision to gaps.
Check the system-to-software allocation and open-item register.
- Does boundary change trigger review?
Moving rules out of code, changing a model provider, or adding human review changes responsibility, interfaces, verification, and handover.
Check the configuration baseline and change triggers.
What a complete set of software requirements commonly covers
Software does more than respond to a screen. It manages state, stores data, calls interfaces, records exceptions, and supports installation and maintenance. A feature-only backlog leaves security, resources, upgrade, and recovery to implementation defaults; complete coverage makes those responsibilities designable and verifiable.
Functions, states, and modes
Required reception, validation, calculation, decision, storage, presentation, transmission, prevention, and recovery under triggers and preconditions, plus transitions across startup, normal, maintenance, degraded, and fault modes.
External and internal interfaces
Interaction with users, hardware, software, data, and operations tooling, plus internal software boundaries that must be constrained at requirements time, using approved interface contracts.
Data and information handling
Object definitions, identifiers, sources, integrity, precision, time, state, retention, migration, deletion, audit, and authoritative stores, with controlled references to data dictionaries.
Performance, timing, and capacity
Response, latency, throughput, concurrency, batch, storage, and resources under stated load, data, hardware, and network conditions, traced to reproducible performance requirements.
Security, privacy, and safety
Identity, authorization, isolation, validation, confidentiality, integrity, logs, incident response, privacy, safe states, hazard controls, and protections that cannot be bypassed.
Dependability and recovery
Fault detection and isolation, retry, degradation, consistency, restart, checkpoint, backup coordination, and post-recovery reconciliation rather than a vague ‘stable system.’
Quality and maintainability
Applicable analyzability, modifiability, testability, observability, portability, compatibility, accessibility, and supportability expressed through measurable scenarios.
Environment and computing resources
Supported operating systems, runtimes, processors, memory, storage, communication, devices, regions, environmental limits, and the resource assumptions required for conformity.
Configuration, adaptation, installation, and upgrade
Site or tenant configuration, feature controls, initialization, deployment, migration, update, rollback, removal, and compatibility.
Operation, maintenance, training, and support
Diagnostics, permissions, tools, manuals, training, support interfaces, export, and retirement capabilities that are product obligations.
Design and implementation constraints
Only necessary restrictions from standards, compatibility, safety, licensing, or approved architecture, with rationale; ordinary preferences remain design decisions.
Acquired, open-source, and reused components
COTS, SaaS, OSS, legacy, and reused code need function, configuration, interface, quality, security, licence, support, defect, update, and exit requirements too.
Write each software requirement for implementation, verification, and maintenance
A software requirement gives implementation enough information without turning today's code structure into a permanent constraint. Describe observable obligations through input, state, behaviour, output, and exception, and retain source and verification method so a new internal design can still prove the same responsibility.
Stable ID, subject, and level
Identify the obligated software system, item, or service with an ID independent of current implementation names; do not mix system, software, and component subjects at one level.
Condition, trigger, state, and mode
State applicable role, authority, data state, mode, dependency, time, and environment. Unconditional wording is reserved for constraints that truly always apply.
One normative obligation
Specify one observable action, result, preserved state, or prohibition. Split separately verifiable obligations while retaining their parent or scenario relationship.
Input, output, data, and interface
Reference controlled objects, sources, schemas, rules, and interface versions and cover missing, invalid, conflicting, duplicate, and unauthorized inputs.
Quantified quality and resources
Attach workload, environment, measurement, statistic, threshold, and severity to performance, dependability, security, or maintenance objectives.
Exception, safe state, and forbidden effect
Define stop, rollback, preservation, notification, and human intervention during dependency failure, partial work, restart, missing evidence, or risk.
Source, rationale, and derivation
Trace system requirements, stakeholder intent, interfaces, safety analysis, law, or architecture and identify direct allocation versus derived requirement and its approval.
Verification, acceptance, and priority
Select inspection, analysis, demonstration, or test, representative environment and evidence, and record criticality, version, status, and acceptance applicability.
Bidirectional trace and change trigger
Trace upward to source and downward to design, code or configuration, verification, non-conformance, and release so dependent change can be found in either direction.
Derive software requirements from system allocation and engineering analysis
Not every system requirement should be copied into software. Architecture allocation determines which obligations software carries alone and which it shares with people or equipment. Security, failure, resource, and external-component analysis can add software constraints, each linked to its rationale.
Freeze current inputs and the software boundary
Use approved system requirements, scenarios, operational concept, interfaces, scope, and assumptions with version and open issues; do not declare a baseline from screens or existing code.
Allocate functions and responsibility
Decide what software, hardware, people, procedures, and services carry. Shared system outcomes need allocation relationships and end-to-end verification ownership.
Analyse normal, exceptional, and lifecycle scenarios
Trace input, processing, output, state, data, and interfaces through normal, boundary, failure, maintenance, recovery, and retirement paths.
Incorporate safety, reliability, hardware, and environment analyses
Derive detection, prevention, recording, degradation, and preservation obligations from hazards, threats, privacy, faults, resources, and devices, retaining rationale.
Decompose to assignable and verifiable levels
Preserve sufficient and necessary parent-child relationships. Do not mechanically split by page, microservice, or function before design allocation exists.
Check consistency across classes
Review functions with state, data, interface, performance, security, and recovery so one class does not defeat another, such as caching defeating authority or freshness.
Validate with both authorities and specialists
Business, systems, software, test, operations, security, data, and interface parties confirm necessity, sufficiency, feasibility, intended context, conflicts, and TBD closure.
Approve and change-control the baseline
Record version, owner, traceability, verification, deviations, and decision evidence. Iterative development can mature incrementally while each delivery increment keeps an identifiable baseline.
Review each statement and the software requirement set as a whole
Clear individual requirements do not guarantee a complete set. Two sensible state rules may conflict, several functions may compete for one resource, or an error state may have no owner. Review sentence quality and whether the complete software behaviour can coexist.
- Correct and necessary?
The obligation supports an approved parent outcome or risk control and does not disguise preference, legacy behaviour, or unapproved scope.
Check source, rationale, allocation, and authority.
- Clear, singular, and atomic?
Subject, condition, action, and result have one reasonable interpretation, and one identifier can be statused and verified independently.
Check peer review, vocabulary, and counterexamples.
- Feasible, quantified, and verifiable?
Thresholds have business and engineering evidence, and the environment and method are obtainable; vague adjectives have become criteria.
Check prototypes, baselines, budget, verification, and device assumptions.
- Traceable both ways?
The team knows why it exists, who realizes it, how it is proved, and which deviations affect it; orphan parents and children are resolved.
Check a bidirectional matrix or equivalent graph.
- Complete as a set?
Modes, roles, data, interfaces, quality, exceptions, resources, installation, operations, maintenance, acquired components, and retirement are covered, not only sentence form.
Check class matrix, scenario coverage, and interface inventory.
- Consistent and jointly feasible?
State, field, unit, timezone, authority, error, performance, and retention definitions agree and resources and suppliers can support them together.
Check model analysis, cross-review, capacity, and risk evidence.
- Controlled assumptions and TBDs?
Each unknown has source, owner, deadline, and impact; design assumptions do not masquerade as customer obligations.
Check issue and assumption closure records.
How software requirements, an SRS, a backlog, and the delivery baseline fit together
An SRS is one container for requirements, a backlog organises work, and a delivery baseline identifies the version actually committed. They can reference one another but cannot impersonate one another: closing a task card does not prove the complete software obligation was verified.
A Software Requirements Specification is a controlled information item that organizes and communicates software requirements. It can be one document or a governed combination of repository, models, dictionary, interface specifications, and links. NASA notes that requirements and design need not all be textual and can use rigorous languages, graphics, or analysis tools. Identifiable version, complete content, and preserved relationships matter more than the filename.
A backlog schedules implementation, and user stories can express incremental user value, but they do not automatically cover every state, interface, quality, security, operations, and reused-component obligation. Agile teams can link requirements to epics, stories, and tasks without abandoning a product baseline, verification, or bidirectional traceability.
At handover, the applicable set must be reconstructable: approved requirements, data and interface references, closed TBDs, deviations, design and code configuration, results, known limitations, and operating information. An outdated SRS PDF or current board alone cannot prove what governed the delivered version.
Content baseline
Stable ID, text or model, applicable object, version, status, source, priority, criticality, rationale, and approval.
Relationship baseline
Links among system requirements, interfaces and data, risks and hazards, design, implementation configuration, verification, deviations, and releases.
Change record
Proposal, impact, bilateral comments, approval or rejection, migration, implementation, regression, and effective time with old-version traceability.
Access and authority
Who proposes, edits, reviews, approves, and closes; how parties obtain the same version; and how sensitive requirements are shared.
Constructed procurement software requirements
This customer-independent procurement application shows system responsibility allocated into executable software state, access, record, and failure behaviours. Identifiers and variables explain structure, not actual features, controls, or performance commitments.
SWR-FUN-101: pre-submission check
When an authorized applicant requests a check in draft state, the software shall return each missing or conflicting item, applicable rule ID, and correction location under the approved rule version, without creating a formal application or changing approval state.
SWR-STATE-102: atomic submission
After a valid draft and applicant confirmation, the software shall atomically create the formal application and initial audit record under a unique request ID. Failure of a required write preserves a recoverable draft and creates no partial formal state.
SWR-SEC-103: separation of duties
The software independently verifies organisation, object, and action authority and does not trust a client role string. A subject cannot self-approve when the approved rule forbids it.
SWR-IF-104: ERP creation intent
At awaiting-ERP state, the software sends, queries, and reconciles under IF-101 through IF-108 and must not treat a network timeout as proof that ERP did not create the document.
SWR-PERF-105: submission performance
Under approved environment, W1, and D1, execution of SWR-FUN-101 and SWR-STATE-102 meets associated performance requirement P1 for time, throughput, errors, and resources. No seconds are invented before P1 approval.
SWR-REL-106: unavailable dependency
When rules, identity, or ERP are unavailable or uncertain, the software stops irreversible effects, preserves request, dependency state, correlation, and completed stage, and presents an actionable status to authorized roles.
SWR-OPS-107: diagnosis and reconciliation
Authorized operations can inspect controlled stage, rule and interface versions, failure class, and reconciliation by application and correlation, without exposing credentials or data beyond the support purpose.
Acquired, SaaS, open-source, and reused software still need requirements
Not writing a component does not remove the need to govern it. Third-party software still affects data, availability, security, versions, and exit capability. Specify selection, configuration, monitoring, and replacement, then combine supplier evidence with the project's own verification.
Applicable and prohibited use
Define functions, data, and risk levels assigned to the component and forbidden uses. Marketing or a README is not a project requirement.
Version, configuration, and dependencies
Constrain version, configuration, plugins, environment, and transitive dependencies; govern updates, compatibility, and known defects.
Quality, security, and evidence
Specify performance, availability, vulnerabilities, patches, data use, logging, tests, and evidence. Where internals are unavailable, use black-box verification and compensating controls.
Licence, rights, and delivery
Review use, modification, distribution, data, models, outputs, ownership, warranty, and transfer. Authorized roles make legal conclusions.
Support, change, and incident
Define notice, maintenance, deprecation, defect response, major change, incident cooperation, and contacts, with change-triggered impact and regression.
Replacement, export, and retirement
Define export of configuration, data, and audit, replacement interfaces, migration verification, cessation, and deletion evidence.
Enterprise AI software requirements govern composite versions, probabilistic output, and deterministic controls
In an AI application, code alone does not determine behaviour. Model, prompt, knowledge index, and tool configuration can all change outcomes. Requirements identify that composite while keeping access, state, and consequential actions inside repeatably verifiable controls.
Define software and AI configuration objects
Identify application code, provider and model version, prompts, retrieval configuration, knowledge index, rules, tool schemas, and safety policy in a reproducible combination versus external controlled dependencies.
Specify intended and prohibited behaviour
By role, task, evidence state, and risk, define generation, retrieval, classification, advice, refusal, and handoff instead of ‘intelligent answers’ or ‘automatic understanding.’
Enclose probability with deterministic controls
Identity, authority, isolation, business rules, tool validation, consequential-action confirmation, stop conditions, and audit are verifiable controls. Model output grants no authority.
Handle missing, conflicting, and uncertain evidence
Define labeling, limitation, clarification, stopping, or human handoff when authoritative evidence is missing or conflicting, support is weak, or the model refuses.
Connect quality requirements to representative evaluation
Stratify correctness, relevance, evidence, robustness, fairness, and safety by task, language, role, evidence state, and severe failure with samples, labels, repeats, and statistics.
Govern model, knowledge, and tool interfaces
Specify schema, authority, version, timeout, quota, errors, idempotency, data purpose, and supplier change in interface requirements instead of treating an SDK as the contract.
The software must deliver work to a person, not just display ‘human review required’
Handoff creates a claimable task with source material, system rationale, and current state, and locks any action that must not continue while waiting. It also handles no recipient, timeout, and return of the human decision. A message without a queue, role, and audit record is not human oversight.
Regress and approve continuous change
Identify composite versions and run suitable regression, staged release, rollback, and reapproval after model, prompt, knowledge, rule, data, tool, purpose, or risk changes.
Retain non-AI or safe degradation
Define traditional rules, read-only access, queueing, or human processing when AI is unavailable, insufficient, or withdrawn, especially for consequential work.
Software requirements and neighbouring concepts
System requirements can allocate responsibility to people, equipment, and external services; software requirements take only the software share, and design and code explain how it is realised. This boundary prevents software owning results it cannot control and prevents one current implementation replacing a durable obligation.
| Concept | Boundary from software requirements |
|---|---|
| System requirement | Constrains the broader system and can allocate to software, hardware, data, people, process, and services. Software requirements own the allocated or derived software part. |
| Functional requirement | States required behaviour and outcomes and is a major software-requirement class. The full set also covers state, data, interface, performance, security, quality, resources, and lifecycle. |
| Non-functional requirement | States quality or a sourced constraint that can be allocated to software. It is neither a remainder bucket nor the complete software baseline. |
| Performance requirement | Quantifies how fast, how much, and how efficiently under load and environment and is one class of the software requirement set. |
| Interface requirement | Defines a bilateral boundary contract and can allocate duties to software and an external entity. The software baseline owns its side and controlled references. |
| SRS | A controlled information item that organizes requirements and context. Requirements can live in documents, repositories, or models; a file does not prove completeness. |
| User story and backlog | Express incremental value and schedule work and can link to requirements, but do not automatically cover every quality, security, interface, operation, and traceability obligation. |
| Software architecture and design | Explain how structures and components realize requirements. Design is constrained by requirements and can derive new ones, but an implementation choice is not automatically a parent obligation. |
| Code and configuration | Implement requirements and represent configuration state. Current behaviour cannot define correctness without source and authorized confirmation. |
| Test case | Defines conditions, data, steps, and expected result to verify a requirement. Testing may expose a gap, but a tool default does not create a need. |
| Acceptance criteria | Apply approved requirements to a delivery version, environment, and sample. Long-term software obligations may extend beyond one acceptance event. |
| Project requirement | Constrains process, schedule, review, reporting, or delivery. Only constraints on the software product become software requirements. |
Sources and scope
This entry explains a software requirement in systems and software engineering: a requirement allocated to a clearly bounded software system, item, service, or configuration item that states its required behaviour, states, data handling, interfaces, performance, quality, protection, operational adaptation, or lifecycle constraints and forms a designable, implementable, verifiable, bidirectionally traceable, and change-controlled software baseline. Software requirements are more than a function list and do not mean every project requirement. This entry does not fully define system, functional, non-functional, performance, or interface requirements, user stories, a product backlog, an SRS information item, architecture, design, code, test cases, acceptance criteria, project requirements, or supplier contracts. Authorised project roles must approve the software boundary, allocation, criticality, use of acquired and open-source components, thresholds, and decisions.
- ISO/IEC/IEEE 29148:2018: systems and software requirements engineering, SRS content, good requirements, verification, traceability, and change; confirmed current in 2024
- ISO/IEC/IEEE 12207:2026: lifecycle processes for software systems, products, and services across conception, acquisition, supply, development, operation, maintenance, and retirement
- NASA SWE-050: establish, record, approve, and maintain software requirements, including COTS, GOTS, MOTS, OSS, and reused components
- NASA SWE-051: flow down and derive from systems engineering, safety and reliability analysis, and hardware, then assess correctness, completeness, consistency, feasibility, verifiability, and maintainability
- NASA SWE-052: bidirectional traceability among higher requirements, hazards, software requirements, design, code, verification, and non-conformances
- NASA SWE-055: lifecycle validation that software requirements are necessary, sufficient, feasible, and reflect stakeholder intent in the target environment
- NASA SWE-109: SRS coverage of functions, states and modes, interfaces, data, adaptation, safety, performance, environment, resources, quality, constraints, and rationale
- NASA SWE-027: requirements, licensing and rights, support, defects, risk, and lifecycle governance for acquired, open-source, legacy, and reused software
- NIST SP 800-160 Vol. 1: engineering trustworthy and secure systems and software from stakeholder protection needs and lifecycle risk
- NIST AI RMF Core: AI system requirements, components and third parties, actor responsibility, data, human oversight, measurement, supplier change, and monitoring