Modern RE keynote: Requirements specification or project grave? Lessons learned from the perspective of an IT expert

Register quickly: Today at 16:00, free webinar with Michael on interfaces with SysML and Rhapsody.

We can learn a lot from failure. Experts are the ones who look at the shambles and analyze why projects go off the rails. Few will be surprised that the problems almost always arise at the beginning, before the actual work begins.

The keynote speech "Requirements specification or project grave?" at Modern RE was given by Prof. Dr.-Ing. As an IT expert, he regularly analyzes failed projects and shows how to recognize early on whether a project is viable or not. A perfect topic for a keynote speech at a conference on requirements management.

As IT experts, we ensure that we act as a neutral authority in court proceedings and disputes regarding the quality assessment of software products."

Prof. Dr.-Ing. Stefan Wagenpfeil

Modern RE 2025

The This year's Modern RE took place from September 17-18, 2025 in Leibzig. The conference was well attended with around 130 participants and covered a wide range of content in various formats, from lectures to workshops. On the following day, I had the pleasure of second keynote on Product Velocity hold.

Why planning is so difficult

The theory sounds simple: Write clear requirementsthen implement it. But practice is complicated. Requirements are often unclear, contradictory and incomplete. What's more, they often change during the course of the project. But even carefully written requirements are rarely as clear as the client would have expected. Here is an example from the keynote speech that illustrates how difficult planning can be.

A company put an SAP project out to tender with over 1000 pages of detailed requirements. The bidders' offers ranged between 13 and 43 million euros - a deviation of 300 percent. Despite the great effort put into the preparation, there was no comparability.

It doesn't work without contracts

Contracts are the basis of cooperation. Contracts should actually facilitate good cooperation, but they are often the cause of problems. Wagenpfeil describes cases in which IT contracts were in fact immoral. Many contracts also contain deliberate loopholes or unfair clauses. One problem is that technical people and lawyers tick completely differently.

There, the service provider obliged the client for whom it was to program to pay a surcharge for the extended provision of resources in the event of delays in development. So I, as a service provider, take too long and then get even more money.

Prof. Dr.-Ing. Stefan Wagenpfeil

Contracts can be structured in different ways. The most important types of IT contracts are

• Contract for workDelivery of a clearly described result. Advantage: clear acceptance. Disadvantage: requires extremely precise requirements.
• Service contractBilling by time. Advantage: flexible. Disadvantage: no clear entitlement to results.
• Agile contractEach sprint is considered a small piece of work. Advantage: fits in with agile methods. Disadvantage: high documentation effort, often unclear acceptance criteria.
• Service contractMaintenance or operation. Advantage: clear support. Disadvantage: further developments quickly blur with maintenance.

Example: Documentation against source code

A second case shows how absurd the conflicts can be: A client refused to accept a correctly functioning piece of software. Why? Because the original specification deviated from the implementation. Specifically, the specification defined 14 states. The analysis of the source code showed that only 8 were implemented because the remaining states were not necessary for the functionality.

Formally, the client was right: the system was not implemented as specified. But the result was absurd, especially because the client could not really explain who exactly had defined these 14 states, or for what reason.

5 points to avoid contractual conflicts at an early stage

Although the following points are not a panacea, they can help to defuse contractual problems at an early stage. As a side effect, they generally contribute to the quality of the result. The points are:

1. Suitable contractThe contract type must match the project. The contract type is often selected "because we have always advertised it this way".
2. Quality GatesRegular, independent audits to detect deviations at an early stage.
3. Acceptance criteriaDefine clear, documented and binding criteria from the outset.
4. Liability for deliverablesEverything is a deliverable - including project plans, tests and contracts - and should be treated accordingly.
5. Realistically evaluate time and moneyAlmost never both. Accordingly, priorities must be set and expectations managed.

Quality starts at the beginning. Even though we know that fast is not necessarily cheap, the rule remains: crap in, crap out.

Prof. Dr.-Ing. Stefan Wagenpfeil

Conclusion

Projects don't fail at the end, but at the beginning. The combination of unclear requirements, poor contracts and a lack of quality assurance inevitably leads to disputes. Time or money are almost always in short supply, both at the same time are rare.

And this is another important lesson: we are not lawyers. Contracts are part of the reality of projects, but they follow a different logic. Those who accept this and still ensure clarity have the best chance of successfully completing the project rather than burying it in the specifications.