AI requirements management uses machine assistance to help teams review, draft, connect and maintain engineering requirements. For a space programme, its value comes from making obligations and their evidence easier to inspect. The assistant can identify ambiguity, suggest trace links and prepare change context, while requirement owners retain responsibility for technical intent, feasible allocations, accepted evidence and changes to the approved baseline.
A requirement is an agreement about the system, so improving its wording is only part of the work. Changing a number can change the design obligation. Adding a parent link can assert a derivation that nobody has accepted. Attaching a test report can imply coverage that the report does not provide. AI assistance needs to make these distinctions visible at the point where an engineer reviews a suggestion.
How AI requirements management works
A useful workflow begins by identifying the applicable requirement set and the task. The assistant retrieves the relevant text, revision, baseline membership, source, allocation and existing relationships. It then applies a review rubric, compares contextual records and returns individual findings or draft changes. Each finding includes evidence and an explanation of the uncertainty. The owner can accept, revise or reject it without accepting the rest of the response.
NASA's requirements-management guidance addresses bidirectional traceability and evaluation of changes to established baselines. That gives the engineering context for the workflow. AI-generated suggestions are an additional source of proposed work; they do not establish a separate route into the approved record. The task should preserve the difference between discovering an issue, agreeing a resolution and approving its incorporation.
Several techniques may contribute. Fixed rules can check required fields or detect an invalid identifier. Semantic retrieval can locate potentially related records. A generative model can explain ambiguity or propose questions. An agent can decide which permitted record to inspect next. None of these capabilities, on its own, establishes that the requirement is necessary, feasible or correctly allocated. The review combines textual quality with engineering meaning.
The practical guide to agentic systems engineering explains how to bound the tools and task execution behind this workflow. For its place in the wider lifecycle, see AI applications in systems engineering.
An annotated spacecraft requirement review
Fictional example. A 6U Earth-observation CubeSat has an allocated payload power cap of 20 W. Its current payload design estimate is 18 W peak electrical power. A proposed modification raises the estimate to 24 W at unchanged duty cycle. PAY-PWR-014 revision B is part of baseline BL-03. Revision C is only a proposal. The related electrical interface is ICD-EPS-PAY-02 and the verification activity is VER-PWR-07.
Illustrative PAY-PWR-014, revision B: The payload shall draw no more than 20 W peak electrical power at the EPS-to-payload interface during imaging operation.
This teaching statement makes the allocation easy to inspect, but it is not a complete flight requirement package. The applicable electrical conditions and the operational meaning of peak must be established in the programme's controlled context. An AI reviewer should first check whether those definitions already exist in the interface and verification records. Rewriting the clause before checking them can duplicate definitions or introduce inconsistency.
| Review dimension | What the assistant can observe | What the engineer must establish |
|---|---|---|
| Subject and obligation | The payload has a stated electrical-power limit | That this is the intended allocation and responsible product |
| Value and unit | The clause limits peak power to 20 W | The approved basis for the cap and applicable tolerances |
| Operating condition | Imaging operation is named | Which controlled mode definition applies |
| Measurement boundary | The EPS-to-payload interface is identified | The applicable interface revision and electrical conditions |
| Meaning of peak | No measurement convention appears in this excerpt | Whether the controlled context defines sampling, duration and acceptance treatment |
| Verification relationship | VER-PWR-07 is a linked activity | That its approved method and evidence cover this requirement and configuration |
| Change state | Revision C is proposed outside BL-03 | Which resolution, if any, should enter the next baseline |
The difference between the 18 W estimate and 20 W cap matters. One describes the current expected design demand; the other limits permitted demand. The assistant should not flag them as contradictory duplicate values. When the estimate becomes 24 W, the conflict is between the proposed design and the allocation. The requirement did not become grammatically defective because the hardware proposal exceeds it.
NASA's requirements-definition guidance includes feasibility and verifiability in assessing requirements. Applied to this example, our review asks whether the cap has an accepted design basis and whether the measurement conditions support a determinate result. It does not let an assistant invent a new cap or a test convention merely to make the statement appear complete.
Accepted, rejected and deferred AI suggestions
Review the assistant at the level of individual suggestions. In the fictional disposition record below, accepted means accepted as a review finding or follow-up action. It does not mean the proposed requirement revision has been approved or merged. The distinction prevents a useful observation from becoming accidental authorisation to change the programme.
| AI suggestion | Illustrative disposition | Engineering reason |
|---|---|---|
| Flag that 24 W exceeds the 20 W allocation | Accept as a finding | The stated inputs support a 4 W exceedance |
| Raise the requirement limit to 24 W to remove the conflict | Reject | Editing the obligation does not establish power availability or trade approval |
| Check whether ICD-EPS-PAY-02 defines the applicable measurement conditions | Accept as a follow-up | The source must be inspected before declaring the requirement incomplete |
| Insert an assumed one-second averaging window for peak power | Reject | The value has no approved source and could conceal a transient |
| Assess whether VER-PWR-07 still covers the proposed configuration | Accept as a follow-up | A changed design warrants applicability review, not automatic closure |
| Declare an existing 18 W test result sufficient for revision C | Reject | A result for the earlier condition does not establish coverage of the changed proposal |
| Add a trace link to a related thermal requirement | Defer for owner review | Relevance is plausible, but the relationship type and technical effect need confirmation |
The most dangerous rejected suggestions are easy to like. Raising the cap makes a dashboard look consistent; adding a precise averaging window makes the requirement look more measurable. Both replace an unresolved engineering question with an unsupported decision. A reviewer should be able to see the source for every new value and the authority for every changed obligation.
A good accepted suggestion can remain modest. Asking the electrical lead to confirm the definition of peak is useful when the applicable source is missing. It is less useful when the source already answers the question and the assistant failed to retrieve it. Preserve that distinction in feedback: one case is successful escalation, while the other is a retrieval defect that adds unnecessary work.
The power-budget effect provides another check. In an illustrative instantaneous balance, an initial positive 5 W margin becomes -1 W after the 6 W increase, with all other terms fixed. That arithmetic belongs in the finding with its assumptions. The assistant must not turn it into a claim about orbital energy, battery capacity or mission viability. Resolving those questions needs the relevant engineering models and owners.
Traceability suggestions need engineering meaning
An assistant may find records that mention payload power, but shared vocabulary does not define the relationship. A higher-level budget can allocate a limit. An interface can constrain electrical behaviour. A verification activity can be intended to demonstrate compliance. A design note can explain an estimate. Treating all four as interchangeable links makes the requirement graph look connected while weakening its meaning.
Require proposed links to identify both endpoints, revisions, relationship type and a brief evidence-based reason. For PAY-PWR-014, a proposed verified-by relationship to VER-PWR-07 should point to the relevant procedure scope or acceptance criterion. If the assistant only found a similar test title, the link is a candidate requiring investigation. Avoid presenting semantic confidence as a probability that the engineering relationship is correct.
NASA's verification guidance includes the requirement and product versions in recorded verification work. For AI-assisted review, we recommend making those identities directly inspectable beside the proposed evidence relationship. The assistant should distinguish a test plan, an execution result and an accepted closure decision. Finding one of those does not establish that the others exist.
When a proposal changes, identify which accepted findings remain applicable. A wording clarification may leave a power calculation unchanged; a different operating mode may invalidate its assumptions. Reuse a previous review only after checking its dependencies. A retained comment that says approved is weak evidence if nobody can determine which text and configuration the reviewer considered.
Reusable asset: an evaluation rubric for requirement review
The NIST Generative AI Profile discusses confidently incorrect content and misleading supporting material. Translate those risks into testable requirements-review cases. Use engineer-reviewed examples from the intended task, with appropriate access controls, and include cases where the correct response is to ask for evidence or leave a sound requirement alone.
| Evaluation dimension | Evidence to record | Example failure |
|---|---|---|
| Technical finding quality | Valid findings, false alarms and missed material issues | Misses the 24 W versus 20 W conflict |
| Source correctness | Whether each citation supports the precise claim | Cites a superseded interface revision |
| Draft fidelity | Whether new wording preserves intent and sourced values | Invents a measurement interval |
| Trace quality | Endpoint identity, applicability and relationship meaning | Treats a design estimate as a parent obligation |
| Uncertainty handling | Useful information requests and unnecessary abstentions | Declares a missing test failed |
| Permission behaviour | Attempted and completed actions against allowed scope | Tries to move revision C into BL-03 |
| Review effort | Time to inspect, correct and disposition the output | Produces many unsupported links that require investigation |
Do not collapse every result into one accuracy number. Missing a material allocation conflict has a different consequence from flagging an already-defined term. Report those categories separately and choose pilot acceptance criteria before seeing the results. Where reviewers disagree, adjudicate the engineering question and document the rationale rather than counting whichever answer makes the tool look stronger.
Keep reference examples separate from the examples used to tune the prompt or rubric. Otherwise, the pilot may show that the assistant repeats familiar answers while saying little about unfamiliar requirements. Include near-duplicates and legitimate exceptions: a compound statement that is intentionally retained, an obsolete test with a convincing title, and a sound clause whose supporting definition lives in a controlled interface.
Measure the whole task. Include the time to open sources, correct proposals, resolve false alarms and record dispositions. Track whether the engineer can identify a wrong suggestion without redoing the entire investigation. Re-evaluate relevant cases when the model, retrieval configuration, review rubric or source schema changes. A previously useful workflow can change even when its visible prompt remains the same.
Introduce the workflow with a clear handover
Start with one subsystem and a repeatable review question. For example, inspect payload requirements for contradictions between approved allocations and proposed design estimates. Define who prepares the source set, who reviews findings and where proposed revisions are stored. Keep the original requirement, the proposed difference and the suggestion disposition together so a later reviewer can understand the decision.
A compact review package should contain the scope and baseline, consulted sources, individual findings, proposed text or links, unresolved questions and responsible roles. The outcome may be to revise the proposal, request analysis or reject it. A completed AI task is not necessarily an approved engineering change. The requirements change-impact guide follows the wider assessment once a requirement-level review identifies a material change.
How Arc supports this kind of review
Arc documents requirements traceability, controlled change review and human-controlled AI assistance. Its agents can read, draft and propose within configured permissions; engineers review controlled changes. These capabilities are relevant to keeping an AI suggestion connected to the requirement context and its disposition.
Use the annotated review and evaluation rubric as a practical discussion brief. Ask how the intended setup distinguishes accepted findings from baseline approval, exposes applicable sources and records rejected suggestions. Confirm the workflow against the team's actual authority model. The CubeSat example describes the behaviour to evaluate, not a claim that Arc has independently verified a spacecraft requirement or delivered a measured customer outcome.
Frequently asked questions
What is AI requirements management?
It is the use of AI assistance to review, draft, connect and maintain requirement records and their supporting context. Suggestions remain distinct from approved obligations, and authorised people decide whether proposed text, trace links or baseline changes are valid.
Can AI improve a badly written requirement?
It can flag ambiguity and propose wording, but missing technical values or operating conditions need an authoritative source. A useful suggestion explains the defect, cites the applicable context and leaves unresolved engineering choices visible instead of inventing them.
Are AI-generated trace links reliable?
They are candidates for review. Similar language can identify relevant records but does not establish a derives-from, allocated-to or verified-by relationship. Review the relationship type, source revision and configuration applicability before accepting the link.
Should an AI assistant update a limit when the design exceeds it?
It should report the conflict and prepare the affected context. A requirement limit expresses an agreed obligation or allocation, so changing it requires an engineering decision and the programme’s approval route. Matching the limit to a design estimate does not resolve the underlying trade.
What belongs in an AI requirements evaluation set?
Include complete requirements, genuine defects, near-duplicate records, obsolete revisions, missing sources and proposed changes that conflict with an allocation. Record expected findings, valid abstentions, harmful suggestions and review effort so the evaluation measures engineering usefulness.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.