3 Reasons for Inadequate Requirements

Posted on March 4, 2021  •  2 minutes  • 392 words

Requirements engineering aims to understand client and stakeholder needs and translate them into clear, understandable language. Throughout this process, several factors can lead to inadequate requirements.

Defining a Stakeholder

According to the IREB Glossary , a stakeholder is “a person or organization that influences the requirements of a system or is affected by it.”

Each time requirements are gathered, misunderstandings can happen. One side describes something; the other side interprets it differently.

Source: Project Cartoon

📣 Communication

Language is one of the biggest challenges. When Person A explains something to Person B, information loss is common.

Steps in Verbal Communication:

• A’s Thought ➔ Words ➔ B’s Understanding ➔ Documentation

At each step, information can be lost. The process involves physical and cognitive filtering as Person A translates thoughts into words, and Person B interprets and records them.

If two parties share a similar cultural or professional background, verbal communication may be more effective. Redundancies like tone, gestures, and feedback can help verify that the message is understood correctly.

⏱ Time and Budget Constraints

“We need feature X.” – “When?” – “Yesterday.”

This exaggerated exchange highlights a common issue: fast-paced development often means visible results are prioritized over quality. A rush to implement a feature can backfire if the client essentially becomes a tester. During reviews, a list of bugs or missed requirements often surfaces, resulting in client dissatisfaction and developer stress—a lose-lose scenario.

The effects of requirements engineering are indirect and hard to measure. Without it, costs from errors and rework escalate, impacting the overall budget.

This graphic shows the relationship between error costs, requirements engineering costs, and total costs.

👍 Assumptions

Right-click opens a context menu. The smartphone home button is centered at the bottom. It’s obvious, right?

Implicit requirements are unstated or undocumented because they seem “obvious.” However, perceptions vary greatly depending on each stakeholder’s expertise.

• Client-side stakeholders describe the “what” based on their domain knowledge.
• Vendor-side stakeholders focus on the technical “how.”

Implicit requirements are risky because they are only validated at the final approval stage. The Kano Model of Customer Satisfaction explains the connection between achieving certain product features and customer satisfaction:

Source: Wikipedia Kano Model

• Basic Factors: Expected by the user and, if absent, cause dissatisfaction.
• Performance Factors: Contribute to satisfaction or prevent dissatisfaction.
• Excitement Factors: Create high satisfaction by exceeding expectations, distinguishing the product from competitors.