Your Requirements Are Complete. So Why Is the Design Still Wrong?

A specification can pass every review, trace cleanly to every test, and still describe the wrong system.

The requirements are baselined.

Every “shall” has an ID. The traceability matrix is populated. Verification methods have been assigned. The specification has been through three reviews, two hundred comments, and enough redlines to make everyone involved tired of looking at it.

Then the system reaches a real user.

And something is wrong.

Not necessarily broken. Not necessarily non-compliant.

Just… wrong.

The operator has to perform six steps for something they expected to take one. A subsystem works perfectly until another system connects to it. The product meets its response-time requirement, but only under conditions that almost never exist in actual operation. A maintenance task requires access to a component that cannot be reached once the system is installed.

Then someone says the sentence every systems engineer dreads:

“That’s not what we meant.”

The uncomfortable part is that the engineering team may be able to prove that the design satisfies the specification.

The customer may even agree.

And the design can still be wrong.

That is because a requirements specification is only as complete as the understanding behind it.

“Complete” According to What?

Requirements engineers spend a lot of time worrying about requirement quality—and rightly so.

Is the requirement clear?

Is it testable?

Is it feasible?

Is it necessary?

Is it unambiguous?

Is it traceable?

ISO/IEC/IEEE 29148 establishes requirements engineering as a disciplined life-cycle process rather than simply the act of writing specification statements [1]. NASA guidance goes further: its requirements-validation guidance asks whether requirements cover areas such as interfaces, operating environments, personnel, operability, transportation, safety, security, support, assumptions, and other system concerns—not simply whether each individual statement is grammatically complete. [2]

That distinction matters.

A requirement can be perfectly written and still be the wrong requirement.

A specification can contain everything the team knows it needs to contain while completely missing something nobody thought to ask about.

That is the dangerous form of incompleteness.

It does not look incomplete.

It looks finished.

A Specification Is a Model of the Problem

Engineers sometimes treat requirements as though they are the problem itself.

They are not.

They are a representation of the problem.

Somewhere before the specification existed, there was a person trying to accomplish something.

An operator had a task.

A customer had an objective.

A maintainer had a constraint.

A business had a reason for spending money.

A regulator had a concern.

Another system had to exchange something with yours.

Those messy realities were eventually converted into structured engineering language.

That conversion is necessary. But information can be lost along the way.

NASA's systems-engineering process explicitly starts with stakeholder expectations, operational objectives, constraints, design drivers, and criteria for success. From there, the architecture, Concept of Operations (ConOps), and derived requirements are developed iteratively—not as independent artifacts, but as things that must remain consistent with one another. [2], [3]

That is a fundamentally different mindset from:

“We have 437 requirements, therefore the requirements are complete.”

The number tells you almost nothing.

What matters is whether those 437 requirements adequately represent the system that people actually need.

The First Thing That Gets Lost Is Usually Intent

Consider a simple requirement:

The system shall display an alert within two seconds of detecting a fault.

It is measurable.

It is testable.

It is reasonably clear.

It might pass every automated quality check you run against it.

But why does the stakeholder need the alert within two seconds?

Perhaps the operator must take immediate action.

Perhaps the alert is informational only.

Perhaps two seconds was copied from an older system.

Perhaps displaying the alert is not actually the important part—the important part is ensuring the operator notices it while concentrating on another task.

Perhaps there are five different fault severities and only one of them requires immediate intervention.

The sentence tells us what the system should do.

It may not tell us why.

And when the “why” disappears, engineers are forced to make design decisions without knowing which parts of the problem are negotiable.

This becomes especially dangerous during trade studies and change requests.

Imagine that displaying the alert within two seconds becomes technically expensive.

Can we relax it to five seconds?

Without the stakeholder rationale, nobody knows.

So the number survives.

Not because five seconds would actually fail the mission.

Because the organization has forgotten why two seconds was chosen in the first place.

Stakeholders Rarely Tell You Everything They Know

There is another problem: people do not naturally communicate every assumption behind a request.

If you ask an experienced technician how a process works, they will often skip steps—not because they are hiding information, but because those steps are obvious to them.

That is tacit knowledge.

Research in requirements engineering has specifically examined the difficulty of capturing tacit knowledge during functional-requirements development [4]. A broader systematic mapping of empirical requirements-quality research also identifies completeness, correctness, consistency, and ambiguity as recurring quality concerns across the literature [5].

You can see the problem in almost any engineering domain.

Ask someone:

“What does the system need to do?”

They might answer:

“It needs to automatically upload the inspection results.”

Good. That becomes a requirement.

But several assumptions may be hiding behind that sentence:

The system normally has network connectivity.

The operator already has permission to upload.

The destination server is reachable.

The files are below a certain size.

The inspection occurs at one facility.

Only one operator uses the system at a time.

The correct project has already been selected.

The server has enough storage.

The upload can fail safely.

None of those things were intentionally omitted.

They simply lived in someone's head.

Until one of them stopped being true.

Operational Context Changes the Meaning of a Requirement

This is where the Concept of Operations becomes much more than another document needed for a review.

A useful ConOps explains how the system is actually expected to live.

Who uses it?

Where?

Under what conditions?

In which operating modes?

What happens before normal operation?

What happens after it?

What other people or systems are involved?

What does failure look like?

What does degraded operation look like?

NASA specifically describes the ConOps as a way to understand stakeholder expectations from an operational perspective and notes that developing scenarios can reveal gaps and ambiguous expectations before they become baked into the design. [2], [3]

Take a hypothetical autonomous inspection cart.

Its specification might contain requirements for:

• speed,
• payload,
• obstacle detection,
• battery life,
• localization accuracy,
• charging time,
• communications,
• sensor performance,
• data storage, and
• environmental limits.

It may look impressively complete.

Then put it into the building where it will actually operate.

There are badge-controlled doors.

Cleaning crews leave equipment in corridors.

Wi-Fi coverage disappears in one stairwell.

Forklifts temporarily block its route.

Someone parks another cart in front of its charger.

A fire door closes at night.

Its inspection route changes every Wednesday because production uses the area differently.

None of these necessarily contradict the specification.

The system could satisfy every written requirement and still fail operationally.

That is not primarily a requirement-writing problem.

It is a context-capture problem.

Assumptions Are Requirements Waiting to Become Problems

Every design contains assumptions.

The dangerous ones are the assumptions nobody wrote down.

“We assumed the power would always be available.”

“We assumed the user would already know which mode the system was in.”

“We assumed both systems used the same coordinate convention.”

“We assumed that message would never arrive before initialization completed.”

“We assumed maintenance would be performed indoors.”

“We assumed only one device would connect at a time.”

The phrase we assumed appears surprisingly often after something goes wrong.

NASA's requirements-validation checklist explicitly asks whether assumptions have been stated and whether those assumptions are correct before requirements are baselined. [2]

That is a useful discipline because an assumption hidden in someone's head cannot be reviewed.

An assumption written down can be challenged.

What if that isn't true?

That single question can uncover an enormous amount of missing engineering work.

Interfaces Are Where “Complete” Systems Meet Reality

A subsystem team can produce a beautiful specification.

Another subsystem team can do exactly the same thing.

Then the two systems are connected.

And suddenly everybody is in a meeting.

Interfaces create problems because they sit between ownership boundaries.

Who owns message timing?

Who defines invalid data behavior?

What happens during startup?

Which system is authoritative?

Who retries after communication is lost?

What coordinate frame is being used?

What happens when one side updates its software and the other does not?

Who provides power during a fault?

What does “ready” actually mean?

NASA's validation guidance explicitly asks whether external and internal interfaces are clearly defined and whether those interfaces are sufficient and mutually consistent. [2]

The interesting word there is consistent.

Two interface requirements can each be perfectly clear individually and still disagree with each other.

Completeness therefore cannot be evaluated only one requirement at a time.

Sometimes the defect exists in the relationship between requirements.

Edge Cases Do Not Feel Important Until You Are Living in One

Most requirements describe nominal operation.

Real systems spend an uncomfortable amount of time outside it.

What happens when the user presses the button twice?

What happens when the sensor becomes unavailable halfway through an operation?

What happens when the database is full?

What happens after an unexpected restart?

What happens if two legitimate commands arrive simultaneously?

What happens when the operator enters a valid value at exactly the maximum allowed boundary?

What happens when the external system sends yesterday's perfectly valid message today?

These scenarios are easy to miss because requirements discussions naturally gravitate toward what the system is supposed to do.

But resilient engineering also asks:

What is the system supposed to do when the expected sequence does not happen?

This is one reason scenario-based analysis is so valuable. It forces teams to stop reviewing isolated statements and start mentally operating the system.

The requirement suddenly has a before, an after, an environment, an operator, and consequences.

That is often where the missing requirements appear.

Traceability Can Give You False Confidence Too

Traceability is essential.

But traceability only proves that relationships exist between the things you captured.

Imagine this chain:

Stakeholder Need → System Requirement → Subsystem Requirement → Design Element → Test Case → Passing Test Result

Beautiful.

Everything is connected.

Except the original stakeholder need was misunderstood.

You now have an exceptionally well-documented path to the wrong solution.

This is why backward traceability matters as much as forward traceability.

Do not only ask:

“What design and test satisfy this requirement?”

Ask:

“What stakeholder need or operational objective justifies this requirement?”

If nobody can answer that question, the requirement deserves attention.

Traceability should preserve intent—not merely document decomposition.

Recent Industrial Evidence Points to Context, Not Just Wording

This distinction is not theoretical.

A 2026 industrial study analyzing thousands of stakeholder and product requirements from the automotive industry found that refinement difficulty was driven primarily by architectural scope and missing contextual information rather than simply by linguistic verbosity. The dataset included 8,082 stakeholder requirements and 5,870 product requirements, along with traceability links, decisions, rationales, and domain references. [6]

That result is worth paying attention to.

Requirements quality is often discussed as a writing problem:

Remove ambiguous words.

Use shall statements.

Avoid passive voice.

Make the statement atomic.

Define measurable thresholds.

All of those things are valuable.

But beautifully structured English cannot compensate for missing engineering context.

A perfectly written requirement about the wrong thing is still wrong.

So How Do You Know Whether the Requirements Are Actually Complete?

You probably never know with absolute certainty.

But you can make it much harder for important information to remain invisible.

Trace requirements back to stakeholder intent

Every important requirement should have a reason to exist.

That reason might come from:

• a stakeholder need,
• an operational objective,
• a safety constraint,
• a regulation,
• an external interface,
• a business constraint,
• a higher-level requirement, or
• an architectural decision.

If the origin has disappeared, recover it.

Review scenarios, not just sentences

Do not conduct every requirements review by scrolling through a spreadsheet row by row.

Walk through the system.

Startup.

Normal operation.

Shutdown.

Maintenance.

Configuration.

Degraded operation.

Communication loss.

Recovery.

Updates.

Unexpected inputs.

End-of-life activities.

Ask different stakeholders to walk through the same scenario. Their disagreements are useful. They are showing you where shared understanding does not yet exist.

Make assumptions visible

Create an assumption register if necessary.

Then attack it.

For every significant assumption, ask:

What happens if this becomes false?

Some assumptions will be safe.

Some will become requirements.

Some will become risks.

Some will change the architecture.

That is exactly why they need to be visible.

Treat interfaces as first-class engineering objects

Do not leave interface behavior distributed across meeting notes and subsystem specifications.

Define ownership, data, timing, states, units, coordinate conventions, startup behavior, fault behavior, limits, and versioning explicitly.

Then test the interface behavior—not merely each subsystem independently.

Validate before you celebrate verification

Passing every verification test proves that the implemented system satisfies the requirements being tested.

It does not automatically prove that those requirements represent what stakeholders actually needed.

NASA's requirements process explicitly calls for validating technical requirements against stakeholder expectations, operational concepts, objectives, constraints, and success criteria. [3]

That validation needs to happen early.

Discovering that a requirement is wrong during a document review is uncomfortable.

Discovering it after hardware, software, tooling, test equipment, training material, and production processes have been built around it is much worse.

Where AI Can Actually Help

This is one area where AI-assisted engineering can be genuinely useful—but only if we are clear about the role AI should play.

AI cannot know with certainty what a stakeholder never told anyone.

It cannot manufacture ground truth.

What it can do is make it much easier to interrogate the engineering information you already have.

A 2026 empirical study involving 26 participants and 130 requirement statements found that participants generally rated LLM-assisted requirement revisions higher for alignment with intent, readability, reasoning, and unambiguity. The researchers also found examples where AI surfaced additional details stakeholders had not originally articulated. But there were occasional factual or semantic errors, leading the authors to emphasize keeping stakeholders inside the validation loop. [7]

That is exactly the balance engineering organizations should be pursuing.

Not:

“Let AI write the specification.”

But:

“Let AI help us interrogate the specification.”

Ask:

• Which requirements appear to have no clear stakeholder driver?
• What assumptions are implied but not explicitly captured?
• Which operating modes have requirements but no off-nominal behavior?
• What happens if this interface becomes unavailable?
• Are there requirements describing normal operation but nothing covering recovery?
• Do the ConOps and system requirements describe the same behavior?
• Which requirements use terminology differently?
• Which stakeholder concerns have no downstream requirements?
• Which requirements have no verification?
• What changed when this requirement was modified?
• Which other artifacts might now need review?

Those are much more interesting applications of AI than simply generating more text.

How Ngenaire Helps Close the Gap

This is the philosophy behind how we are building Ngenaire.

A requirements tool should not treat requirements as isolated rows in a database.

The surrounding context matters.

In Ngenaire, a Concept of Operations can capture stakeholders, environments, modes, scenarios, constraints, and assumptions. Portions of that operational narrative can become traceable objects and link directly to requirements, helping preserve the connection between what someone needs to accomplish and the requirement created from that need. [8]

Requirements can then be analyzed for qualities such as clarity, testability, atomicity, and completeness. Engineers can inspect upstream drivers and downstream dependents, maintain history, compare baselines, and flag suspect links when connected requirements change. [9]

But the more important capability is the connected engineering context.

Ngenaire's traceability model can connect requirements to ConOps elements, subordinate requirements, risks, diagrams, test cases, procedures, and other project artifacts. Its Network View lets engineers visually explore those relationships and inspect what depends on a requirement before changing it. [10]

Project Memory can also preserve durable project facts such as decisions, constraints, and stakeholder concerns so that important context does not disappear every time another engineer starts working on the problem. [11]

The AI Assistant can operate against that connected project context—reviewing requirements, helping draft ConOps content, identifying possible gaps, supporting verification planning, and helping engineers interrogate the relationships among artifacts. [12]

The objective is not to replace the systems engineer.

It is to make questions that used to require hours of document hunting easier to ask.

What are we missing?

Why does this requirement exist?

What depends on it?

What assumption is this design making?

Have we considered what happens when this scenario goes wrong?

Those are engineering questions.

AI simply gives us another way to ask them at scale.

The Specification Is Not the Finish Line

There is a dangerous moment in many programs when the requirements are declared complete.

The spreadsheet looks clean.

The open comments are closed.

The review is over.

Everyone is ready to move on.

That should not mean we stop questioning the requirements.

It should mean we now have a controlled representation of our best current understanding of the problem.

That understanding will be challenged.

By the architecture.

By prototypes.

By integration.

By operators.

By suppliers.

By tests.

By manufacturing.

By maintainers.

And eventually by reality.

Good systems engineering leaves room for those challenges.

Because the goal was never to produce a complete specification.

The goal was to build the right system.

Those are not the same thing.

References

[1] ISO/IEC/IEEE, ISO/IEC/IEEE 29148:2018—Systems and Software Engineering—Life Cycle Processes—Requirements Engineering, 2nd ed., International Organization for Standardization, Geneva, Switzerland, 2018. Confirmed current in 2024.

[2] National Aeronautics and Space Administration, NASA Systems Engineering Handbook, Rev. 2, NASA/SP-2016-6105, Washington, DC, USA, 2016; see also “Requirements Validation Checklist,” NASA Systems Engineering Handbook Appendix.

[3] National Aeronautics and Space Administration, “System Design Processes” and “Stakeholder Expectations Definition,” NASA Systems Engineering Handbook, NASA, Washington, DC, USA. Accessed: Aug. 12, 2026.

[4] A. Benfell, “Modeling functional requirements using tacit knowledge: A design science research methodology informed approach,” Requirements Engineering, vol. 26, pp. 25–42, 2021, doi: 10.1007/s00766-020-00330-4.

[5] L. Montgomery, D. Fucci, A. Bouraffa, L. Scholz, and W. Maalej, “Empirical research on requirements quality: A systematic mapping study,” Requirements Engineering, vol. 27, pp. 183–209, 2022, doi: 10.1007/s00766-021-00367-z.

[6] Z. Wang, S. Yu, Z. Xing, T. Wenzel, and C. Chen, “Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry,” accepted to the 41st IEEE/ACM International Conference on Automated Software Engineering (ASE 2026), Industry Showcase Track, arXiv:2607.05632, 2026.

[7] M. Mircea, E. Gevrek, E. Schmid, and K. Schneider, “Supporting Stakeholder Requirements Expression with LLM Revisions: An Empirical Evaluation,” arXiv:2601.16699, 2026.

[8] Ngenaire, “Concept of Operations (CONOPS),” Ngenaire Documentation, 2026. Accessed: Aug. 12, 2026.

[9] Ngenaire, “Requirements: EARS Patterns, Quality, and Management,” Ngenaire Documentation, 2026. Accessed: Aug. 12, 2026.

[10] Ngenaire, “Traceability” and “Network View,” Ngenaire Documentation, 2026. Accessed: Aug. 12, 2026.

[11] Ngenaire, “Project Memory: Durable Notes the AI Assistant Reads,” Ngenaire Documentation, 2026. Accessed: Aug. 12, 2026.

[12] Ngenaire, “AI Assistant Overview,” Ngenaire Documentation, 2026. Accessed: Aug. 12, 2026.