AKARA Launchpad

Every software project starts with the same question: What exactly should be built?

Requirements engineering is the systematic process of gathering, documenting, and validating requirements. It is the most critical phase of any software project. Decades of research confirm: the costliest mistakes don't happen during coding — they happen when requirements are incomplete, contradictory, or misunderstood.

The traditional process looks like this: a week of workshops with stakeholders, whiteboards covered in Post-its, design thinking sessions, meeting notes nobody reads, and at the end a 40-page requirements document that's already outdated by the time it's finished.

What makes this genuinely hard

The problem isn't the effort — it's the uncertainty. Clients often don't know what they want. They can describe problems but can't specify solutions. A stakeholder says: "We need a dashboard" — but means three different things depending on whether you ask the CEO, the sales director, or the developer.

Traditional requirements engineering tries to resolve this uncertainty through conversations. It works, but it takes weeks, costs €10,000 to €50,000 in consulting fees, and the result is a document the client can't touch. No prototype. No clickable interface. Just text.

The alternative — "just start building and see what happens" — is more expensive. Every iteration based on wrong assumptions costs multiples of what a proper specification would have cost.

The service provider's dilemma

For a software agency like AKARA Solutions, this is a business problem. Invest a week in workshops before a single line of code is written, and margins shrink. Skip the requirements analysis, and the risk of building the wrong thing goes up. Neither option scales.

What's missing: a way to confront clients within minutes with a tangible, testable result — not a document, but a working prototype. Not to replace the conversation, but to elevate it: away from "What do you mean by that?" toward "Click here — is this what you need?"

Example: The design phase of the Apollo program

There is a fundamental problem in requirements gathering that persists across projects of every scale: the assumption that a complete, formally correct specification is enough to ensure the right thing gets built. An episode from the Apollo program illustrates why that's wrong — and what works instead.

During the design phase of the Apollo capsule, engineers worked on the window specifications. The requirements were in exactly the form you'd expect: dimensions, position coordinates, material thickness, tolerances, thermal stress values. Every line was technically correct, reviewed, and approved.

One engineer decided to validate the specification a different way. He built a simple cardboard mockup of the capsule wall with the window cutout at exactly the specified dimensions and position. Then he asked the astronauts to sit inside.

The result was clear: the field of vision was insufficient. For docking maneuvers, visual attitude control, and navigation, the overview was missing. The astronauts could immediately point out where the problems were — something they couldn't do when reading the specification. Position, size, and angle of the windows had to be fundamentally redesigned.