How Do You Write Requirements for AI and Machine Learning Components?

The standard requirement template — The system shall [action] [condition] [constraint] — was designed for deterministic systems. A power supply shall regulate output voltage to 5V ±0.1V. A braking controller shall apply maximum pressure within 150 milliseconds. These are binary pass/fail statements verifiable on a single unit test run.

Now apply the same template to a pedestrian detection model: The system shall detect all pedestrians within 50 meters. Every word in that sentence creates a problem. “Shall detect” implies certainty. “All” implies 100% recall. There is no reference to lighting conditions, occlusion, sensor configuration, or training distribution. It is simultaneously overspecified (100% recall is unachievable) and underspecified (which pedestrians, under what conditions, validated on what data?). The team will spend six months arguing about whether the requirement was met, then ship a system whose failure modes were never formally captured.

This is the core problem writing requirements for AI and machine learning components. The tools, the templates, and the organizational habits that work for conventional software and hardware were not built for systems whose behavior is statistical, emergent, and inseparable from the data used to train them. Getting this right is not an academic exercise. It directly determines whether you can certify the system, debug failures in deployment, and demonstrate to a customer or regulator that you know what your system will and will not do.

Why Deterministic Requirements Fail for ML Systems

A trained model is a function approximator. Its outputs are probabilistic estimates derived from patterns in training data. This creates four structural problems for classical requirements:

Behavior cannot be fully specified in advance. Traditional requirements enumerate what the system does in all significant states. For an ML model, the input space is effectively infinite, and the output for any given input depends on learned weights that the requirements author never directly controls.

Performance is distributional, not absolute. The model may achieve 98.3% recall across a held-out test set and miss every instance of a specific subclass. An aggregate accuracy figure is not a behavioral guarantee — it is a statistical summary. Requirements need to reflect this by specifying performance bounds, not point targets.

Context determines validity. The model’s test performance is only meaningful relative to the distribution it was trained and tested on. Deploy it outside that distribution and performance can degrade arbitrarily. Requirements must be scoped to a defined operational context.

The artifact being specified is not static. When you write a requirement for a resistor, the resistor does not change. When you retrain a model, its behavior changes. Requirements must version-lock to model artifacts and account for the update cycle.

None of this means ML components cannot be properly specified. It means the requirement structure needs to be fundamentally different.

Performance-Based Requirements: Beyond Accuracy

The first move is replacing binary-outcome requirements with bounded statistical requirements tied to explicit metrics and explicit datasets.

Accuracy is insufficient on its own. A model that correctly classifies 99% of inputs in a class-imbalanced dataset may achieve that score by never predicting the minority class. For safety-relevant ML components, requirements must specify the full confusion-matrix-derived metric set appropriate to the application:

• Precision: Of the detections the model reports, what fraction are correct? Governs false alarm rate.
• Recall (sensitivity): Of the actual positive instances, what fraction does the model find? Governs miss rate.
• F1 or F-beta: Weighted combination, where beta > 1 weights recall more heavily — appropriate when misses are more costly than false alarms.
• Calibration: Do the model’s confidence scores match empirical probabilities? A model that reports 90% confidence should be correct approximately 90% of the time.

A well-formed performance requirement looks like: The pedestrian detection model shall achieve recall ≥ 0.97 and precision ≥ 0.90 on the nominal validation dataset (defined in Dataset Specification DS-PED-001), under daylight, unoccluded conditions, at ranges of 10–60 meters, with false negative rate not exceeding 0.03 per 1000 frames.

Notice what this does: it names a specific dataset, constrains the operating conditions, specifies multiple complementary metrics, and sets a per-frame false negative budget that engineering can actually trace to a safety analysis.

Distribution shift bounds are a separate requirement class that most teams skip to their detriment. The model will encounter inputs that drift from the training distribution. Requirements should specify the tolerable magnitude of distribution shift before the system is required to flag uncertainty, escalate to a backup system, or refuse to output. Metrics like Maximum Mean Discrepancy or covariate shift detection thresholds can be operationalized as pass/fail criteria with defined measurement procedures.

Operational Design Domain Requirements

The Operational Design Domain (ODD) — borrowed directly from autonomous vehicle standards like ISO 22737 and SAE J3016 — is the structured specification of the conditions under which a system is designed to operate and under which its performance requirements are valid. Every ML performance requirement must be tethered to an ODD.

An ODD specification covers:

• Environmental conditions: illumination range (lux), precipitation state, temperature range, sensor obstruction levels
• Geographic and infrastructure constraints: road types, lane configurations, geofenced areas
• Object and scenario characteristics: object size ranges, speed ranges, occlusion levels, density thresholds
• Sensor configuration: specific sensor hardware version, calibration state, mounting configuration

The requirement structure becomes: Performance bound X applies when operating within ODD Y. This is not hedging — it is precision. A requirement that says “recall ≥ 0.97 in clear daytime conditions” is more honest and more testable than “recall ≥ 0.97” with no conditions. It also forces the systems engineer to specify what happens outside ODD bounds, which is where most ML failures actually occur.

ODD-boundary behavior itself becomes a requirement category: When operating conditions exceed ODD bounds [as detected by monitoring function M], the system shall [escalate / reduce confidence output / transfer control] within [time bound]. This links the ML performance requirements directly to the system-level safety architecture.

Requirements for Explainability and Monitoring

These are not optional features to add later. They are requirements that must live in the requirement baseline with acceptance criteria attached.

Explainability requirements specify what the system must produce alongside its outputs to allow operators, maintainers, and safety analysts to understand and audit decisions. Depending on the application:

• Attribution outputs: The model shall provide per-input feature importance scores (e.g., SHAP values) for all outputs above confidence threshold T, with computation latency not exceeding L milliseconds.
• Uncertainty quantification: The model shall output a calibrated confidence interval alongside each classification, with empirical coverage matching stated confidence at p ≥ 0.95 across the validation set.
• Counterfactual explanations: For flagged anomalies, the system shall generate a minimal counterfactual description specifying which input features, if changed, would have altered the output.

Monitoring requirements define what the fielded system must observe and report to maintain validated-state awareness. This is where ML systems diverge sharply from conventional software: a model that passed acceptance testing can degrade in production without any code change. Monitoring requirements should specify:

• Input distribution metrics and thresholds for drift alarms
• Output distribution monitoring (prediction class frequency, confidence score histograms)
• Ground truth comparison pipelines where labels can be obtained post-deployment
• Model performance SLAs with defined escalation paths when thresholds are breached

Both explainability and monitoring requirements must have acceptance criteria. “The system shall provide explainability” is not a requirement. “The system shall produce SHAP-based attribution outputs for all detections, verified by test procedure TP-XAI-003 on the ML validation bench, with attribute generation latency ≤ 200ms at p99” is a requirement.

What the Standards Are Saying

Two emerging frameworks are directly relevant to teams writing ML component requirements today.

EASA’s Artificial Intelligence Roadmap (current at v2.0, with ongoing updates to associated acceptable means of compliance) frames ML system assurance around a concept hierarchy: Learning Assurance, in which the quality of training data, training process, and resulting model behavior are each subject to formal requirements and review. The framework emphasizes that requirements must cover the full ML pipeline — not just the deployed model — and introduces explicit guidance on dataset requirements, bias analysis, and performance monitoring. The EASA approach maps naturally onto a layered requirement structure: mission requirements → system-level safety objectives → ML component performance requirements → dataset quality requirements → training process requirements.

UL 4600 (Standard for Safety for the Evaluation of Autonomous Products) provides one of the most operationally complete frameworks for ML safety cases. It requires that each ML component have an explicit performance specification tied to the operational domain, that uncertainty be quantified and managed, and that the safety case include an argument connecting training data provenance to operational safety claims. UL 4600 also requires that monitoring be part of the system safety architecture, not a post-deployment addition.

Both frameworks reinforce the same structural conclusion: ML requirements are not a single layer but a stack, and every layer needs requirements, not just the top.

Writing the Layered Requirement Structure

The practical output of everything above is a requirement hierarchy that descends from mission intent to model behavior to data specifications. In outline:

1. Mission/stakeholder requirements: What the system must achieve operationally. Not ML-specific. “The surveillance system shall detect unauthorized personnel entry with probability ≥ 0.999 across all defined facility zones.”

2. System-level functional requirements: Allocated to subsystems. “The vision processing subsystem shall detect human figures within zone coverage areas with recall ≥ 0.98 under ODD-SURV-001 conditions.”

3. ML component performance requirements: Specific to the model. Precision, recall, calibration, latency, ODD bounds, confidence output format, distribution shift thresholds.

4. Explainability and monitoring requirements: Attribution method, uncertainty format, monitoring cadence, drift alarm thresholds.

5. Dataset and training process requirements: Minimum training set size, class balance specifications, data provenance and labeling quality standards, augmentation constraints, validation split methodology.

6. Model artifact requirements: Version control policy, retraining triggers, regression test requirements for model updates.

Each level traces bidirectionally to the level above and below. A change at the dataset level (new data source added) triggers review of model performance requirements. A change in the mission requirement (extended ODD) triggers re-derivation of every dependent layer.

How Modern Tools Handle This Structure

This layered, trace-intensive structure breaks down quickly in document-based tools. Requirements spread across spreadsheets and Word documents cannot maintain live bidirectional traceability across six levels of a hierarchy. When a dataset requirement changes, there is no automated path to identify which system-level safety objectives depend on it.

This is the domain where graph-based requirements management genuinely earns its value. Flow Engineering, built specifically for systems and hardware engineering teams managing complex requirement structures, models requirement relationships as a native graph. Each node — whether a mission requirement, an ODD specification, a dataset quality criterion, or a model performance bound — is a first-class entity with attributes, owners, and explicit relationship types. The graph structure means that when an ODD boundary is revised, the impact path up through ML component requirements to system-level functional requirements is traversable and auditable.

Flow Engineering’s AI-native interface allows teams to decompose high-level mission requirements into ML-appropriate performance specifications with traceability maintained automatically. Engineers can query the requirement graph — “which dataset requirements support recall requirement REQ-ML-042?” — and get a direct answer without manually reconstructing trace matrices. For teams working under EASA Learning Assurance or UL 4600 safety case requirements, this kind of structural traceability is not a convenience feature; it is part of the evidentiary record.

The limitation to name honestly: Flow Engineering is purpose-built for this kind of connected, model-centric requirement work. Teams that need deep integration with legacy PLM systems or established document-approval workflows may face an adaptation period. That focus is a deliberate trade-off for teams doing serious ML systems engineering rather than a gap in general capability.

Where to Start

If your team is writing requirements for ML components today:

1. Audit your existing ML requirements for deterministic language. Every “shall always” or “shall detect all” is a flag. Replace with bounded statistical requirements tied to named datasets and defined operating conditions.

2. Write your ODD specification before writing performance requirements. Performance without domain context is not a requirement.

3. Add explainability and monitoring to the requirement baseline now, not after integration testing. Define acceptance criteria for both.

4. Map your requirement hierarchy. Identify all six layers. If you don’t have dataset quality requirements, you have an incomplete specification.

5. Evaluate whether your tooling can maintain bidirectional trace across the hierarchy. If the answer involves manually updating spreadsheets, your traceability will not survive the first ODD revision.

ML components are harder to specify than deterministic ones. That difficulty does not go away by ignoring it — it relocates to the certification phase, the accident investigation, or the customer complaint. Getting the requirement structure right before training starts is the highest-leverage intervention available to a systems engineering team working on AI-enabled products.