A few years ago, I found myself in a workshop preparing for a major IT procurement process. Within minutes, the flip chart was filling up with requirements:

“The software must have an Excel export,”
“We need a dashboard,”
“The solution must work on mobile devices,”
“AI support would also be important,”
“We need a mobile app.”

After about an hour, several flip chart pages were filled. Every department had contributed its wishes. Procurement added contract-relevant requirements, and IT was already discussing potential vendors and initial implementation considerations.

I asked only one question:

“Why do you actually need an Excel export?”

The room fell silent. After a moment of reflection, someone finally answered:
“Actually, we just want to share the evaluations easily with other departments.”

At that moment, the discussion shifted. Suddenly, it wasn’t about Excel exports anymore. It was about making information easier to share. For the first time, we weren’t talking about features—we were talking about the actual need.

Whether this goal was later achieved through an Excel export, a dashboard, an automated report, or an interface no longer mattered.

The Real Problem

I encounter this situation surprisingly often. Many requirements describe a solution before the actual problem has been sufficiently understood.

A dashboard is not a requirement. A mobile app is not a requirement. Even artificial intelligence is not a requirement—at least not initially.

They are all possible answers to a question that is often not even asked:

What problem do we want to solve?

AI Is a Prime Example

This phenomenon is especially clear in the context of artificial intelligence. In many projects, I hear statements like:

“We need AI-powered search.”
“The new solution should have an intelligent chatbot.”
“The software must support generative AI.”
“The AI should analyze the data.”

My usual response is: “What problem is the AI supposed to solve?”

Desired Feature	Actual Benefit
AI-powered search	Find information within one minute
Chatbot	Automatically answer standard questions
Generative AI	Complete routine tasks faster
AI analyzes data	Make decisions faster and with better insights

Depending on the answer, the technical solution may look entirely different.

AI is not a requirement.
AI is a possible solution.

Sometimes it’s the best solution. Sometimes, however, simpler, cheaper, or more robust alternatives exist. That’s why technology should not come first—benefit should.

Good Requirements Don’t Start with Features

The longer I work on projects, the more convinced I become:
A good requirement first describes the desired benefit. The feature comes later.

Only when the benefit is clear can different solution paths be evaluated.

Perhaps the Excel export or the intelligent chatbot is indeed the best solution. Perhaps not. What matters, however, is that we make this decision consciously—not unconsciously by predetermining it in our requirements.

Why This Mindset Is Well-Founded

Interestingly, research has been addressing this question for decades.

Barry Boehm’s Value-Based Software Engineering places stakeholder value at the center of software projects.

Goal-Oriented Requirements Engineering derives requirements from overarching goals—not the other way around.

As early as the late 1990s, Karlsson and Ryan demonstrated that requirements should be evaluated not only by effort but also by expected value.

All these approaches share the same idea:

Not every feature automatically creates value.

Every additional feature incurs effort and cost: development, testing, documentation, training, and later maintenance. A feature is only meaningful if it contributes to project success.

Therefore, every requirement should answer a simple question:
What specific benefit does it create?

If no convincing answer can be given, it’s worth taking a second look at that requirement.

What Does This Mean for Tenders?

A tender process should describe what goal is to be achieved as precisely as possible. It should only specify a concrete solution where absolutely necessary.

The earlier we commit to a particular feature, the smaller the solution space becomes. And sometimes, we rule out the very innovation we were seeking.

My Experience

In many projects, I now ask a simple question:

“What actually happens if we don’t have this feature?”

Only when a convincing answer is given does a desired feature become a truly justified requirement.

Often, it turns out that a feature hides a completely different goal.

And that’s where good business analysis and structured requirements engineering begin.

Conclusion

Software doesn’t succeed because it has many features.

That’s why, in future workshops, I’ll likely ask less:

“What features do we need?”

And more:
“What problem do we actually want to solve?”

And then:
“What benefit do we want to achieve?”

Because those who confuse features with benefits often buy the wrong software.

Further Reading

Barry Boehm: Value-Based Software Engineering, ACM SIGSOFT Software Engineering Notes, 2003.
Karlsson, J.; Ryan, K.: A Cost-Value Approach for Prioritizing Requirements, IEEE Software, 1997.
Ellis-Braithwaite, M.: Goal-Oriented Requirements Engineering and the Contribution of Requirements to Business Goals, University of Toronto, 2013.
IREB e.V.: CPRE Foundation Level – Requirements Engineering Syllabus (chapters on stakeholders, goals, and solution-neutral requirements).
HM Treasury: The Green Book – Appraisal and Evaluation in Central Government