Breaking the Requirement Engineering Deadlock: 3 Practical Strategies for Software Teams

Problem Overview

Requirements that appear as concrete solutions (e.g., “add a flashy popup ad on the app home page”) often hide the real business or user problem. Teams that accept such requests jump straight to design and implementation, causing scope creep, budget overruns, and later‑stage defects.

First Gate – Do Not Treat a Solution as a Requirement

The article introduces the Y‑model to uncover the true need behind any request. The model proceeds in three layers:

Identify the user’s scenario (Who, When, Where, What).

Clarify the user’s goal and motivation.

Trace the goal back to a fundamental human or business need (e.g., Maslow’s hierarchy).

Applying the model requires answering three concrete questions for every request:

What problem or pain point does the user face?

Who benefits and by how much if the feature succeeds?

Which business metric will improve and to what extent?

In the popup‑ad example, the product manager is asked to specify the metric (e.g., “increase activity‑participation rate by 5 %”) and the expected impact on users. Requests that cannot provide clear answers are rejected, which the author claims eliminates at least 50 % of low‑value work.

Second Gate – Replace “I Think” with Evidence

Vague requirement statements such as “the system should support password reset” lead to divergent implementations. The article proposes “instantiating requirements” by writing a scenario script in Given‑When‑Then format. The transformation looks like this:

Scenario: User Zhang San forgets password and resets it
Given Zhang San is a registered user but his phone is lost
When he chooses the security‑question reset path
Then the system presents the preset question, validates the answer, and allows a new password to be set

This script is directly testable and removes personal judgment. The author demonstrates that a large language model can ingest meeting notes and automatically generate multiple such scripts (covering edge cases like lost phones or wrong answers) in under a minute, producing a comprehensive “script set” for the requirement.

Third Gate – Keep the System Fit, Not Fat

Even after delivering a solid MVP, systems tend to accumulate “zombie features” that are never used but still require maintenance. Two complementary practices are suggested:

Feature Gym : Every new feature receives a “fitness card” and enters an observation period. Data‑tracking records usage and feedback. Quarterly “feature health checks” surface low‑usage or high‑maintenance items, which are then retired in a formal “feature pruning” ceremony.

Value Cafeteria : The backlog is treated like a menu. Items are classified as “value desserts” (new growth‑driving features) or “healthy staples” (bug fixes, refactoring, technical debt). Each iteration must maintain a balanced ratio of desserts to staples, a decision made jointly by product and technical leads to preserve long‑term system stability.

The combined approach turns the team from passive implementers into proactive value explorers, scenario playwrights, and system‑fitness coaches.