Requirements often look like progress.

Workshops are held.
Stakeholders contribute.
Lists grow.

What emerges is a catalogue of wishes.

One person is tasked with making sense of it.

Collect everything.
Structure it.
Find the solution that satisfies all.

This role is set up to fail.

Because the problem is not missing structure.

It is missing decisions.

Most requirements are not requirements.

They are:

• assumptions

• preferences

• unresolved conflicts

Written down instead of decided.

So the list grows.

And with it:

• complexity

• expectations

• cost

Without increasing clarity.

A better approach is uncomfortable.

Reduce the list.

Identify a limited set of meaningful requirements.

Not hundreds.

Often fewer than one hundred.

Each one must be:

• rooted in an actual problem

• clearly distinct

• relevant for decision-making

This forces alignment.

What matters stays.
What doesn’t, disappears.

At this point, evaluation becomes possible.

Not:

“Can this system do everything?”

But:

“How well does it match the characteristic requirements?”

If a solution covers these well,
it will likely cover the rest at reasonable cost.

In practice, this selection needs a place to live.

Not in slides.

It becomes a working set of reference requirements:

each requirement is:

• clearly formulated

• linked to a problem

• assigned a relative importance

When solutions are evaluated, they are not compared in general.

They are tested against this set.

Coverage becomes visible.
Gaps become explicit.
Trade-offs can be discussed.

This turns evaluation into a structured conversation.

Not a negotiation of opinions.

The difference is small.

The effect is not.