In the first part, we talked about the vertical slice – the first narrow path through the system is in place, the technology works.
Now what? Just code the rest?
If only it were that simple.
The reality is: Requirements change the moment users click for the first time. What sounded logical on paper yesterday feels wrong in the app today.
That's why Requirements Engineering isn't a one-time event at the start of a project. It's a continuous cycle that only stops when the project goes live (and often not even then).
The Cycle: Discover, Build, Learn
Classically, you learn models like: Elicit -> Analyze -> Specify -> Validate.
That sounds clean and linear, but in practice it's often messier. And that's okay.
We see it more like this:
- Understand the problem (Elicit & Analyze)
- Build a solution (Specify & Implement)
- Show it to the user (Validate)
And then? Start over.
Each round sharpens the picture. At the beginning, everything is foggy. After three rounds, you see the contours. After ten rounds, the details.
If you try to get everything perfect on the first pass, you'll be stuck in theory forever.
Implicit Knowledge: What Nobody Tells You
The biggest risk in the "Elicit" phase: People don't tell you everything.
Not out of malice. But because many processes are second nature to them. "Of course the invoice needs to be approved – Karen always does that on Fridays." – That's not in any process document. Everyone just knows. Except you.
That's why it's often not enough to just interview people or read documentation.
Our tip: Go where the work happens.
Spend a morning sitting next to the clerk who reviews applications. Look over the warehouse worker's shoulder. We call this "shadowing."
You'll discover things that were never mentioned in any meeting. Workarounds ("I always click Back three times, otherwise it doesn't work"), sticky notes on monitors, or informal agreements.
This implicit knowledge is often the difference between software that "technically works" and software that truly helps people.
Beware of "Big Design Up Front"
Even with the cycle in place, the temptation is huge to plan everything up front again.
"We need to finalize the complete data model before we continue building."
No, you don't.
You only need to know enough to take the next step.
Planning provides security. But too much planning upfront is often an illusion of security. You're planning based on assumptions, not knowledge.
Have the courage to leave gaps. Consciously mark areas as "Unclear" instead of filling them with made-up requirements just to close a ticket.
A gap ("We don't know yet how cancellation works") is honest. A wrong specification ("Cancellation always goes through the manager") is expensive when you have to rip it out later.
This cycle of understanding, building, and learning is demanding. It forces you to constantly make decisions and question your own assumptions.
But it's the only way to build software that isn't just done, but actually right.
Need Support?
The cycle sounds good, but day-to-day business keeps getting in the way? We help your team establish this iterative process – pragmatically and without theoretical overhead. Let's talk.
In the final part, we'll look at how AI tools and the specific challenges in small and medium-sized enterprises (SMEs) are influencing this process today.