[EN] Dein Code ist gut, aber das Feature ist falsch: Ein Plädoyer für Requirements Engineering

The two pillars of requirements

It’s Friday afternoon, 4:00 p.m. You’ve just merged the feature, the pipeline is green, and you feel invincible. Then the Slack message comes from the product owner: “Hey, looks good, but why does X happen when I do Y? That was discussed completely differently.”

Your weekend is just disappearing into thin air. Not because your code is bad - technically it’s probably brilliant. But because you solved a problem that no one had or understood a requirement differently than it was intended.

This is exactly where Requirements Engineering (RE) comes into play.

I recently completed my IREB CPRE FL certificate (Certified Professional for Requirements Engineering Foundation Level). Sounds dry? I thought so too at first. But actually it’s self-defense for developers. RE is not the paperwork we have to do before we can code. It’s the tool that ensures we don’t throw months of work into the trash.

Let’s put the theory aside and look at what you really need in your everyday code.

“It works!” – The fallacy (functional vs. non-functional requirements)

We developers love functional requirements. That’s the logic, the what.

• “The user can log in.”
• “The system calculates VAT.”
• “The shopping cart can be emptied.”

This can be perfectly cast into if/else blocks. Check it. But why do projects still fail even though all functional requirements are met? Because we forgot the Quality Requirements (Non-Functional Requirements, NFRs) and Constraints.

In the IREB context we make a strict distinction:

• Functional Requirement: What the system does.
• Quality requirement: How well the system does it (performance, security, usability).
• Condition: What limits us (GDPR, legacy interfaces, budget).

The practical example: You build a “Search” button. Functionally, it does exactly that: it finds results. But if the search takes 15 seconds, the feature is broken for the user. If the search works but brings the database to its knees in the process, the system is broken.

As an engineer, you have to be the one to raise your hand and ask: “Okay, I can build this. But how many users need to be able to do this at the same time? And how quickly does the answer need to be there?” If you don’t clear these NFRs, they are implicit - and implicit expectations are the mother of all hotfixes.

Great, then we’ll keep the pace up. Now we come to perhaps the most important part of a developer’s mindset: prioritization. We tend to jump into the cool, technical challenges. The IREB knowledge helps to take off the rose-colored glasses.

Here is the draft for the main part (Kano & Communication).

The Kano Model: Why “Dark Mode” has to wait

One of the biggest mistakes we can make: We invest days in a cool feature (aka “gold plating”) while the basics are shaky. The Kano model from requirements engineering is the best compass for classifying features. It divides requirements into three categories:

1. Basic factors (must-haves): These are the things that no one thanks you for when they work. But if they’re missing or broken, all hell breaks loose.
   • Example: A password reset. Nobody says: “Wow, great reset flow!”. But if the email doesn’t arrive, your app is dead for the user.
2. Performance Factors (More is better): The following applies here: the more/better, the happier the user. These are often the things we compare in specs.
   • Example: Charging times, storage space, battery life.
3. Delighters: The user doesn’t expect that. If it’s missing: doesn’t matter. If it’s there: party.
   • Example: Dark mode, funny loading animations, confetti when submitting a form.

The learning for us Devs: We love building excitement factors. That is fun. But in the spirit of requirements engineering, we have to be disciplined: Complete the basics 100% before you start the excitement.

A dark mode won’t save you from 1-star reviews in the App Store if the login (basic factor) throws sporadic timeouts. Next time you pick a ticket, ask yourself: Is this basis, performance or excitement? And do we really have the basis under control yet?

Away from “stakeholderish”, towards code: the common language

A huge part of the IREB curriculum revolves around making requirements clear. Misunderstandings are expensive.

In theory (IREB) we learn sentence templates. That sounds very German and bureaucratic, but it has a kernel of truth. Instead of saying: “The system should inform the user in the event of errors.” (What errors? How to inform? SMS? Pop-up?), a template forces us to be precise:

“The system must provide the [role: administrator] with the ability to [process: view error logs] in order to [benefit: resolve the issue].”

The Bridge to Practice: Gherkin & BDD

As developers, we can take this principle one step further - and here we leave the strict IREB path and turn towards Modern Engineering. We use the precision of the requirement directly for our tests.

Instead of poring over Word documents, we often translate requirements into Gherkin (Given-When-Then). This is basically the programmable version of an IREB sentence template.

Vague requirement: “The shopping cart discount should work.”

Precise RE (Gherkin style):

Feature: Warenkorb Rabatte

  Scenario: 10% Rabatt ab 100 Euro Bestellwert
    GIVEN der Warenkorb enthält Artikel im Wert von 95 Euro
    WHEN ich einen Artikel für 10 Euro hinzufüge
    THEN soll die Gesamtsumme 105 Euro betragen
    AND ein Rabatt von 10% abgezogen werden

The brilliant thing about it: This requirement is both your documentation AND your automated test. If the test is green, the requirement is met. Point. This is the moment where requirements engineering stops being “paperwork” and becomes an integral part of your CI/CD pipeline.