AI Can Write a Requirement. But Does It Understand the System?

A requirement can be grammatically perfect and still be dangerously wrong.

Ask a large language model to improve this sentence:

The system shall alert the operator quickly when tracking is lost.

Within seconds, it may return:

When target tracking is lost, the system shall issue a visual and audible alert to the operator within two seconds.

It sounds measurable and ready for review.

But where did “two seconds” come from? Is an audible alert permitted during covert operation? What exactly constitutes loss of track? Does the timing start when confidence drops, when the tracker declares failure, or when another subsystem reports it?

The AI improved the sentence.

It may also have invented the system.

What LLMs Are Genuinely Good At

The useful case for AI in requirements engineering is already strong.

Large language models can turn rough notes into an initial draft, find vague terms, split compound requirements, summarize review comments, and propose acceptance criteria.

There is real evidence behind that claim. One empirical study found that GPT-4 could produce software requirements specification drafts comparable in quality to those of an entry-level software engineer for the use cases examined. It also identified defects and suggested corrections, although results varied by model [1].

That can give engineers a better starting point.

The mistake is confusing a better starting point with engineering authority.

Fluency Is Not System Understanding

An LLM generates a plausible continuation from the information available.

It does not automatically know which interface control document is current, which assumption was rejected, which operating mode disables a function, or why a particular threshold was selected.

When information is missing, the model may not stop. It may fill the gap with something that sounds reasonable.

NIST calls this risk confabulation: confidently presented but false or erroneous content. Its guidance recommends evaluating AI capabilities empirically, documenting how domain knowledge is incorporated, and verifying generated sources and citations [2].

More context does not make the problem disappear.

Give an LLM a 400-page specification and it still may not use every relevant detail reliably. Research on long-context language models found that performance could decline significantly when necessary information appeared in the middle of the provided material—even for models designed to process long contexts [3].

In engineering, the forgotten sentence in the middle may be the interface constraint that prevents damage to hardware.

A System Is Not a Pile of Documents

The knowledge behind a defensible requirement is distributed across:

Stakeholder needs

Operational scenarios

System architecture

Interface definitions

Hazards and risks

Design decisions

Assumptions

Verification evidence

Change history

That is why traceability matters.

NASA’s Systems Engineering Handbook describes requirements management as maintaining bidirectional traceability among stakeholder expectations, requirements at multiple levels, design documents, and test plans and procedures. It also calls for consistency between requirements, the concept of operations, and the system architecture [4].

An AI given only a prompt sees text.

An engineering AI needs to see relationships.

Retrieval Helps—but It Is Not Enough

Retrieval-augmented generation helps a model use explicit source material instead of relying only on knowledge stored in its parameters.

Foundational research on retrieval-augmented generation reported more factual outputs than a comparable model relying only on parametric knowledge [5].

But retrieval is not a seal of correctness.

The system still needs:

Approved and authoritative sources

Revision and baseline awareness

Appropriate access controls

A visible path back to the supporting evidence

Human review before changes are accepted

Otherwise, the AI can retrieve the wrong document faster.

What Responsible Engineering AI Should Do

A credible engineering AI should be able to answer more than:

Can you rewrite this requirement?

It should also help answer:

What stakeholder need is this requirement derived from?

Which architecture element owns it?

Which interfaces constrain it?

What assumptions and decisions support its values?

How will it be verified?

What else changes if the rewrite is accepted?

It should distinguish a suggestion from an approved engineering change. It should expose the sources behind its recommendations. It should preserve human review rather than hiding uncertainty behind polished language.

Where Ngenaire Fits

This is where Ngenaire is useful.

Ngenaire’s AI-assisted requirements analysis can identify issues involving testability, clarity, atomicity, and completeness. It can then propose an improved version for an engineer to review rather than silently replacing the original requirement [6].

More importantly, the requirement does not have to remain an isolated paragraph.

Within Ngenaire, it can be connected across the engineering lifecycle to architecture, risks, test procedures, verification results, and the Requirements Verification Traceability Matrix [7], [8].

AI should not make the engineering decision.

It should help the engineer see the decision—and its consequences—more clearly.

The Real Question

“Can AI write a requirement?” is no longer an interesting question.

It can.

The question worth asking is:

Can it show why the requirement is true, where it came from, what it affects, and how we will prove it?

If it cannot, you do not have an engineering copilot.

You have autocomplete wearing a hard hat.

References

[1] M. Krishna, B. Gaur, A. Verma, and P. Jalote, “Using LLMs in Software Requirements Specifications: An Empirical Evaluation,” in 2024 IEEE 32nd International Requirements Engineering Conference (RE), 2024, doi: 10.1109/RE59067.2024.00056. Available online.

[2] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, Jul. 2024. Available online.

[3] N. F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics, vol. 12, pp. 157–173, 2024, doi: 10.1162/tacl_a_00638. Available online.

[4] National Aeronautics and Space Administration, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2, 2016. Available online.

[5] P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” in Advances in Neural Information Processing Systems 33, 2020, pp. 9459–9474. Available online.

[6] Ngenaire, “Requirements: EARS Patterns, Quality, and Management,” Ngenaire Documentation. Accessed Sep. 7, 2026. Available online.

[7] Ngenaire, “The Engineering Lifecycle: Define, Model, Verify, Track, Report,” Ngenaire Documentation. Accessed Sep. 7, 2026. Available online.

[8] Ngenaire, “RVTM: Requirements Verification Traceability Matrix,” Ngenaire Documentation. Accessed Sep. 7, 2026. Available online.