From Customer Needs to System Requirements: Closing the Gap

Customer needs rarely arrive as clean, testable engineering requirements. They arrive as goals, frustrations, market pressures, operational constraints, user stories, assumptions, and sometimes vague statements like “make it reliable,” “reduce downtime,” or “make it easy to maintain.”

The systems engineering challenge is not simply to write requirements. It is to translate stakeholder intent into a technical definition that engineers can design, verify, validate, and manage over the life of the system.

That translation is where many projects fail.

The Gap Between What Customers Say and What Systems Must Do

A customer need describes a desired outcome. A system requirement describes what the system must do, how well it must do it, under what conditions, and how success will be verified.

For example:

Customer need:
“The maintenance team needs to diagnose faults quickly.”

Better system requirement:
“The system shall display active fault codes and recommended corrective actions within 5 seconds of fault detection.”

The first statement explains value. The second statement gives engineering teams something they can design and test.

Standards such as ISO/IEC/IEEE 29148 emphasize that requirements engineering is a lifecycle activity, not a one-time writing task. Requirements must be developed, analyzed, attributed, managed, and iterated as understanding improves [1]. NASA’s systems engineering guidance similarly treats stakeholder expectations, technical requirements, logical decomposition, and design solutions as connected and iterative activities [2].

Start With Stakeholder Needs

Stakeholders are not only customers. They include users, operators, maintainers, regulators, manufacturing teams, support teams, business owners, safety engineers, cybersecurity teams, and anyone else affected by the system.

Each stakeholder sees the system differently.

A customer may care about cost and capability.
An operator may care about speed and usability.
A maintainer may care about diagnostics and accessibility.
A regulator may care about compliance.
A manufacturer may care about producibility.

Good requirements work begins by capturing these perspectives before jumping into design. The goal is to understand the problem space, not prematurely define the solution.

This is why stakeholder needs should capture:

• The mission or business objective
• The operational problem being solved
• User classes and their goals
• Constraints and assumptions
• Interfaces with people, systems, and environments
• Measures of effectiveness
• Risks and failure consequences

The Systems Engineering Body of Knowledge describes system requirements as design-input requirements transformed from stakeholder expectations, needs, constraints, risks, and lifecycle concept analysis [3].

Use Operational Concepts to Make Needs Concrete

Stakeholder needs become clearer when placed inside an operational concept.

An operational concept, or ConOps, explains how the system will be used in real situations. It describes the people, external systems, environments, states, scenarios, and workflows involved.

For example, instead of only saying:

“The system must support remote monitoring.”

A useful operational concept asks:

Who monitors it?
From where?
During normal operation or only during faults?
What information do they need?
How quickly do they need it?
What happens if communication is lost?
What authority does the remote user have?

Operational concepts expose hidden requirements. They reveal timing needs, interface needs, environmental constraints, abnormal scenarios, safety concerns, and maintenance expectations.

NASA’s systems engineering process explicitly connects stakeholder expectations, concepts of operation, technical requirements, logical decomposition, and design solutions as part of an iterative design process [2], [4].

Transform Needs Into System Requirements

Once stakeholder needs and operational concepts are understood, engineers can begin defining system requirements.

A strong system requirement should be:

• Necessary
• Clear
• Feasible
• Verifiable
• Unambiguous
• Traceable
• Consistent with other requirements
• Stated at the right level of abstraction

This is where many teams struggle. They either copy customer language directly into the system specification, or they jump too quickly into design decisions.

A customer need should not be blindly rewritten as a “shall” statement. It must be analyzed.

For example:

Customer need:
“The product should be lightweight.”

Weak requirement:
“The system shall be lightweight.”

Better requirement:
“The system shall have a total installed mass not exceeding 18 kg.”

The better requirement converts subjective language into an objective design constraint.

Derived Requirements: The Requirements Customers Did Not Say Out Loud

Not every requirement comes directly from the customer. Many requirements are derived through engineering analysis.

A derived requirement is a requirement that emerges from architecture, decomposition, risk analysis, interfaces, physics, regulations, safety, cybersecurity, manufacturing, maintainability, or verification needs.

For example, a customer may ask for:

“The system shall operate continuously for 24 hours.”

From that, engineers may derive requirements for:

• Power consumption
• Thermal management
• Data storage
• Fault handling
• Network availability
• Maintenance intervals
• Battery capacity or backup power
• Environmental limits

Derived requirements are not optional extras. They are often what make the original customer need achievable.

MIT’s systems engineering teaching material emphasizes that high-level requirements are decomposed into functional and performance requirements, allocated across the system, and validated against stakeholder expectations at each level of decomposition [5].

System Decomposition: Turning the Problem Into Buildable Pieces

System decomposition breaks the system into logical and physical parts.

At the top level, the system may be described by its major functions:

• Sense
• Process
• Decide
• Communicate
• Control
• Store
• Report
• Protect
• Recover

Those functions are then allocated to subsystems, software components, hardware elements, interfaces, procedures, or human roles.

This matters because most engineering failures do not occur because one requirement was badly written. They occur because the relationship between needs, requirements, architecture, interfaces, verification, and operations was not maintained.

A requirement allocated to a subsystem must still trace back to a stakeholder need. A derived requirement must still justify why it exists. A design decision must still connect to the requirement it satisfies.

Without decomposition and traceability, teams lose the thread.

The Common Failure Modes

The gap between customer needs and system requirements usually appears in predictable ways.

Teams capture needs but never convert them into measurable requirements.

They write system requirements but lose the original stakeholder rationale.

They derive lower-level requirements but fail to trace them back to parent needs.

They decompose the system but miss interfaces between subsystems.

They write requirements that are technically correct but operationally irrelevant.

They verify requirements but fail to validate whether the system actually solves the user’s problem.

This creates rework, late design changes, duplicated analysis, inconsistent documentation, and avoidable cost.

Where Automated Requirement Analysis Fits

Automated requirement analysis does not replace systems engineering judgment. It supports it.

Modern requirements work creates too much information for manual review alone: stakeholder notes, ConOps documents, requirements specifications, interface documents, test procedures, compliance matrices, change requests, and architecture models.

Research on automated requirements engineering and natural language processing shows growing interest in using automation to support requirement quality analysis, ambiguity detection, classification, traceability, and consistency checking [6], [7].

This is exactly the gap Ngenaire is designed to help close.

Ngenaire can help engineering teams move from stakeholder intent to structured system requirements by assisting with:

• Identifying vague or unverifiable requirement language
• Highlighting missing measures, conditions, or verification logic
• Connecting stakeholder needs to derived requirements
• Supporting traceability between needs, requirements, architecture, and verification
• Reducing duplicated documentation effort
• Helping teams maintain consistency as the system evolves

The point is not to let AI “own” the requirements. The point is to give engineers better visibility earlier, so ambiguity, missing logic, and broken traceability do not survive until design review, integration, or customer acceptance.

Closing the Gap

The journey from customer needs to system requirements is one of the most important transitions in engineering.

Customer needs define why the system matters.
Operational concepts define how the system will be used.
System requirements define what the system must do.
Derived requirements define what else must be true for the system to work.
Decomposition defines how the system becomes buildable.
Traceability keeps the whole chain connected.

When that chain is weak, teams build the wrong thing efficiently.

When that chain is strong, engineering teams can make better decisions, manage change more confidently, and deliver systems that actually satisfy stakeholder intent.

That is the real purpose of requirements engineering: not paperwork, but alignment between human need and technical execution.

References

[1] IEEE, “ISO/IEC/IEEE 29148-2018 — Systems and software engineering — Life cycle processes — Requirements engineering,” IEEE Standards Association, 2018.

[2] NASA, “NASA Systems Engineering Handbook,” NASA/SP-2016-6105 Rev. 2, 2016.

[3] SEBoK, “System Requirements Definition,” Systems Engineering Body of Knowledge, 2026.

[4] NASA, “4.0 System Design Processes,” NASA Systems Engineering Handbook Online, 2019.

[5] O. L. de Weck, “Fundamentals of Systems Engineering: Requirements Definition,” MIT OpenCourseWare, 2015.

[6] S.-C. Necula, F. Dumi, and V. Greavu-Serban, “A Systematic Literature Review on Using Natural Language Processing in Software Requirements Engineering,” Electronics, vol. 13, no. 11, 2024.

[7] M. A. Umar and C. Ferrari, “Advances in automated support for requirements engineering,” Requirements Engineering, 2024.