«Is this seat taken?» – How Uncertainty Became a Clear Statement

Our client needed a seat reservation system for public transport – specifically, a system that automatically indicates for each seat whether it is reserved or not.

Detailed requirements:

• Context-specific display of reservation data - dynamic and seat-specific
• Real-time updates: even last-minute changes must be visible immediately
• Integration with a proprietary display framework: no standard interfaces, but customer-specific APIs and workflows
• A system that not only works reliably but also adapts in real-time while on the move

The new reservation system is up and running – and remains flexible. The customer can assemble the system modularly, tailored to various public transport scenarios. It’s not a rigid setup, but a configurable solution that adapts to different use cases.

A full simulation was also developed for testing and development – allowing the system to be tested and improved without hundreds of physical displays. This saves not only hardware, but also time and stress.

The solution was cleanly integrated into the existing system via the customer’s proprietary framework. This keeps the customer independent of third-party vendors – whether for maintenance, enhancements, or future requirements.

Thanks to the modular architecture, even a future change in display hardware won’t be a problem: the software stays, the interface adapts.

The project was executed in two clearly structured phases – from concept to full integration:

Phase 1: Clarify Requirements, Document Thoroughly
Together with the client, we defined the foundation. This resulted in a requirements specification and a technical implementation specification – both reviewed and refined by the client. Technical clarifications, such as integration with the proprietary framework, were incorporated directly.

Phase 2: Implementation, Integration, Acceptance
Based on the specifications, we implemented the system and integrated it at the client’s site. The software was not only tested functionally, but also reviewed against coding guidelines and architectural standards. Final acceptance by the client followed immediately.

The project deliberately followed a classic waterfall model – a pragmatic choice, as the objectives and complexity were clearly defined from the start. Later extensions were added selectively – a solid stress test for the architecture: modular, scalable, and easy to maintain.