The Hidden Cost of Poor Requirements

Poor requirements rarely look expensive at the beginning of a project.

They often appear harmless: a vague statement, an assumption left unstated, a missing interface detail, a “we will clarify this later” note, or a requirement that sounds reasonable but cannot be verified.

The real cost appears later.

It appears when engineering teams build the wrong thing.
It appears when test teams cannot confirm whether the system works.
It appears when customers reject a delivered feature because it does not match their actual need.
It appears when schedules slip, budgets grow, and teams lose trust in the process.

Poor requirements do not just create documentation problems. They create business problems, engineering problems, integration problems, and customer-confidence problems.

Requirements Are Not Paperwork

In many organizations, requirements are treated as an administrative step before “real engineering” begins.

That is a mistake.

Requirements are the foundation for design, architecture, implementation, verification, validation, safety analysis, integration, acceptance, and product evolution. A weak requirement does not stay isolated in a document. It propagates through the entire system lifecycle.

A single unclear requirement can affect:

• System architecture
• Interface definitions
• Software design
• Hardware design
• Test procedures
• Acceptance criteria
• Supplier work packages
• Cost estimates
• Schedule commitments
• Customer expectations

This is why requirements quality matters. Good requirements reduce ambiguity. Poor requirements transfer ambiguity downstream, where it becomes more expensive to resolve.

A Brief History of Requirements Engineering

The discipline of requirements engineering did not appear overnight. It evolved as systems became more complex, software became more central to products, and organizations realized that many project failures were not caused by poor coding or poor testing alone, but by poor understanding of what needed to be built.

In the early decades of software and systems development, requirements were often captured in natural-language documents, customer statements, contract specifications, or system-level needs. This worked reasonably well for simpler systems, but as aerospace, defense, telecommunications, transportation, finance, healthcare, and enterprise software systems grew more complex, informal requirements became a serious source of risk.

By the 1970s and 1980s, software engineering researchers began studying the economics of software development more formally. Barry Boehm became one of the most influential figures in this area. His work on software engineering economics and the cost of change helped popularize the idea that defects become more expensive to fix the later they are discovered in the lifecycle [1].

During this period, organizations also began standardizing how software requirements should be documented. IEEE 830, first issued in the 1980s and later revised, became one of the most widely recognized standards for Software Requirements Specifications. It helped establish quality attributes for good requirements, including correctness, completeness, consistency, verifiability, modifiability, and traceability [2].

In the 1990s, requirements engineering matured as a research discipline. Scholars such as Pamela Zave and Michael Jackson helped clarify the relationship between the real world, the machine being built, and the requirements that connect the two. Their work emphasized that requirements are not just statements about software behavior, but statements about desired effects in the real world [3].

Other major contributors, including Axel van Lamsweerde, Klaus Pohl, Anthony Finkelstein, Bashar Nuseibeh, Al Davis, and Suzanne Robertson and James Robertson, helped advance areas such as goal-oriented requirements engineering, viewpoint-based requirements, requirements negotiation, traceability, and practical requirements discovery methods [4][5][6].

In systems engineering, organizations such as INCOSE, NASA, ISO, IEC, and IEEE further shaped modern requirements practices by connecting requirements to lifecycle processes, stakeholder needs, architecture, verification, validation, and system realization [7][8].

Today, requirements engineering is no longer just about writing a specification. It is about managing knowledge, reducing ambiguity, supporting trade decisions, enabling verification, and maintaining alignment between stakeholder intent and engineered reality.

Key Players Who Shaped Requirements Engineering

Several people and organizations have had a major influence on how requirements are written, analyzed, and managed today.

Barry Boehm

Barry Boehm is best known for his work on software engineering economics, COCOMO, risk-driven development, and the cost of fixing defects late in the lifecycle. His work helped engineering organizations understand that requirements defects are not just technical issues; they are economic risks.

Pamela Zave and Michael Jackson

Pamela Zave and Michael Jackson made important contributions to the foundations of requirements engineering. Their work helped distinguish between the world in which a system operates and the machine that is built to influence that world. This distinction is still important today because many poor requirements confuse implementation details with real stakeholder needs.

Axel van Lamsweerde

Axel van Lamsweerde is strongly associated with goal-oriented requirements engineering. His work helped show how stakeholder goals, obstacles, conflicts, and system responsibilities can be modeled and analyzed before jumping into design.

Klaus Pohl

Klaus Pohl contributed significantly to the structure and theory of requirements engineering, including requirements elicitation, negotiation, documentation, validation, and management. His work helped define requirements engineering as a disciplined process rather than a one-time documentation activity.

Anthony Finkelstein and Bashar Nuseibeh

Finkelstein and Nuseibeh contributed to viewpoint-oriented requirements engineering and requirements inconsistency management. Their work is important because complex systems often involve many stakeholders with different perspectives, assumptions, and priorities.

Suzanne Robertson and James Robertson

Suzanne and James Robertson are known for practical requirements discovery and specification methods, including the Volere approach. Their work helped make requirements practices more accessible to business analysts, engineers, and product teams.

IEEE, ISO, IEC, NASA, and INCOSE

Standards organizations and engineering institutions have played a major role in making requirements engineering practical and repeatable. IEEE 830 influenced software requirements specification. ISO/IEC/IEEE 29148 provides guidance for requirements engineering across systems and software. NASA and INCOSE have helped connect requirements to systems engineering lifecycle processes, stakeholder expectations, architecture, verification, and validation.

The Cost Multiplier Effect

A requirement defect found early may be corrected with a conversation, a document update, or a quick stakeholder review.

The same defect found during integration may require redesign, rework, retesting, contract updates, supplier coordination, and customer negotiation.

The same defect found after delivery may require field fixes, warranty cost, operational workarounds, loss of customer trust, or even safety and compliance consequences.

This is the hidden multiplier effect of poor requirements: the later the problem is found, the more people, artifacts, decisions, and dependencies it touches.

A vague requirement at the beginning can become a costly technical issue at the end.

What Poor Requirements Look Like

Poor requirements are not always obviously wrong. Many sound professional at first glance.

For example:

The system shall provide fast response time.

This sounds reasonable, but it is incomplete. What does “fast” mean? Under what operating conditions? For which user action? With how many concurrent users? How will it be verified?

A stronger version would be:

When the operator submits a search request, the system shall display the first page of results within 2 seconds under nominal network conditions and up to 500 concurrent users.

This version is clearer because it defines the trigger, system response, performance threshold, operating condition, and verification basis.

Poor requirements often contain words such as:

• Fast
• Easy
• Robust
• User-friendly
• Sufficient
• Appropriate
• As needed
• Minimize
• Maximize
• Support
• Handle

These words are not always wrong, but they become dangerous when they are not defined.

The Hidden Costs

1. Rework

Rework is one of the most obvious costs of poor requirements. Teams build something, discover it does not meet the real need, and then rebuild it.

But rework is not just the cost of changing code, drawings, models, or documents. It also includes the cost of re-planning, re-reviewing, re-testing, and re-aligning the team.

2. Schedule Slippage

Poor requirements create uncertainty. Uncertainty creates delays.

Teams spend time asking questions that should have been answered earlier. Engineers wait for stakeholder clarification. Testers wait for measurable acceptance criteria. Suppliers wait for interface definitions. Project managers revise schedules because hidden assumptions become visible too late.

3. Scope Creep

When requirements are vague, scope becomes negotiable.

Different stakeholders interpret the same words differently. A customer may believe a feature was included. The engineering team may believe it was out of scope. The result is conflict, change requests, and unplanned work.

Good requirements protect both the customer and the delivery team by making expectations explicit.

4. Verification Problems

A requirement that cannot be tested cannot be confidently accepted.

For example:

The system shall be intuitive.

How does a tester verify “intuitive”?

A better requirement may define measurable usability criteria, such as task completion time, maximum number of user actions, training assumptions, or user-error rate.

Verification should not be an afterthought. If a requirement cannot be verified, it is not ready.

5. Architecture Instability

Poor requirements can lead to poor architecture decisions.

If key performance, safety, scalability, cybersecurity, environmental, or interface requirements are missing, the architecture may be optimized for the wrong problem.

By the time the missing requirement appears, the design may already be difficult or expensive to change.

6. Supplier and Interface Risk

In complex engineering programs, poor requirements do not only affect the internal team. They affect suppliers, subcontractors, integration partners, and customers.

A poorly defined interface requirement can cause two teams to build components that technically satisfy their local specifications but fail when integrated together.

This is one of the most expensive forms of requirements failure because each team may believe it did its job correctly.

7. Loss of Trust

This cost is harder to measure but often more damaging.

When requirements are poor, teams lose confidence in the baseline. Engineers start relying on informal conversations instead of controlled requirements. Testers question the acceptance criteria. Customers question whether the team understood the mission. Managers question the estimates.

Once trust is lost, every decision becomes slower.

Why This Matters More as Systems Become More Complex

Modern systems are increasingly software-defined, AI-enabled, connected, configurable, and integrated across multiple domains.

A requirement is no longer just a statement of what one component must do. It may affect data models, interfaces, algorithms, safety cases, cybersecurity controls, cloud services, user workflows, regulatory obligations, and operational concepts.

In complex systems, poor requirements do not fail in simple ways. They create integration risk.

This is especially important for engineering teams working with:

• Model-Based Systems Engineering
• AI-enabled products
• Digital twins
• Safety-critical systems
• Cyber-physical systems
• Multi-supplier development
• Regulated industries
• Long-lifecycle products

The more complex the system, the more expensive ambiguity becomes.

The Role of Better Requirements Engineering

Better requirements engineering does not mean writing longer requirements.

It means writing clearer, testable, traceable, and decision-useful requirements.

Strong requirements should be:

• Necessary
• Clear
• Feasible
• Verifiable
• Unambiguous
• Traceable
• Consistent
• Complete enough for the lifecycle stage

Frameworks such as EARS, INCOSE guidance, operational scenarios, use cases, interface control documents, SysML models, verification matrices, and ISO/IEC/IEEE requirements standards can all help improve requirement quality.

The goal is not documentation for its own sake. The goal is shared understanding.

A Simple Test for Requirement Quality

Before accepting a requirement, ask:

1. Do all stakeholders interpret this requirement the same way?
2. Can engineering design against it?
3. Can verification prove it has been satisfied?
4. Is the operating condition clear?
5. Is the trigger or state clear?
6. Is the required system response clear?
7. Is the requirement traceable to a real stakeholder need?
8. Would a supplier understand what to deliver?
9. Would a tester know what evidence to collect?
10. Would this requirement still make sense six months from now?

If the answer is no, the requirement is not ready.

The Real Message

Poor requirements are expensive because they delay truth.

They allow teams to move forward before alignment has actually been achieved. That feels efficient early, but it creates hidden debt.

Good requirements expose uncertainty early, when it is still cheap to resolve.

That is why requirements are not just a systems-engineering artifact. They are a risk-management tool, a communication tool, a design input, a verification contract, and a business-protection mechanism.

The hidden cost of poor requirements is not just rework.

It is the cost of building confidence too late.

At Ngenaire, we believe engineering teams deserve better tools for writing, reviewing, validating, and managing requirements. As systems become more complex, requirements need to become clearer, smarter, and more connected to the engineering lifecycle.

Because the cheapest requirement defect is the one you catch before it becomes a design decision.

References

[1] Boehm, B. W. (1981). Software Engineering Economics. Prentice Hall.

[2] IEEE. (1998). IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998.

[3] Zave, P., & Jackson, M. (1997). “Four Dark Corners of Requirements Engineering.” ACM Transactions on Software Engineering and Methodology, 6(1), 1–30.

[4] van Lamsweerde, A. (2000). “Requirements Engineering in the Year 00: A Research Perspective.” Proceedings of the 22nd International Conference on Software Engineering, 5–19.

[5] Pohl, K. (1994). “The Three Dimensions of Requirements Engineering.” Advanced Information Systems Engineering, 275–292.

[6] Nuseibeh, B., & Easterbrook, S. (2000). “Requirements Engineering: A Roadmap.” Proceedings of the Conference on the Future of Software Engineering, 35–46.

[7] ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.

[8] NASA. (2007). NASA Systems Engineering Handbook. NASA/SP-2007-6105.

[9] Boehm, B., & Basili, V. R. (2001). “Software Defect Reduction Top 10 List.” Computer, 34(1), 135–137.

[10] PMI. (2014). Pulse of the Profession: Requirements Management — A Core Competency for Project and Program Success. Project Management Institute.