Mobility & Transport
From Requirements Spec to Plan
How a mobility provider got its next product generation ready for the steering committee.
Starting Point
A European mobility provider wants to build a new generation of connected vehicles in order to win public tenders. The previous generation still weighs on the team. They bought a ready-made complete solution, a black box with no access from the inside. Every new requirement was added on top afterwards: card reader, display, payment function, all backward compatible with the installed base. In the end they had a device that was supposed to do everything, was expensive, took years to develop and depended entirely on a single supplier.
For the new generation, the project proposal does not get through the committee: timeline too long, development too expensive. On the table is a requirements catalog with over 160 items. Almost every one already describes a solution, hardly any says what the contracting authority, users or the workshop actually need. Plenty of detail, but the fundamental questions are open. That is where we started.
What We Did
1. FIRST CLARIFY WHAT WINS: The workshops showed that contracting authorities decide based on customizability, references, demos and cost. High fleet availability is mandatory, but it does not win a tender, because nobody can measure it at the time of the tender. This distinction alone reshuffled the priorities.
2. NEEDS BEFORE TECHNOLOGY: We turned the catalog into solution-free needs and aligned them with product, hardware and embedded. The knowledge in the catalog is preserved. It just no longer fixes the technology in advance.
3. NO DEVICE THAT DOES EVERYTHING: Instead of a bought-in black box that gets one function after another bolted on, we cut the system into building blocks with clear interfaces. The electronics belong to the customer. If a requirement changes or a component drops out, you swap one building block instead of rebuilding the whole device. A supplier can be replaced without the product depending on them. Mechanics sat at the table too: where the electronics sit, how they are packaged and where cables break caused a lot of trouble with the predecessor. So we clarified these questions together instead of one after another.
4. ONE PLATFORM INSTEAD OF MANY VARIANTS: Each contracting authority gets its own configuration of the same hardware, via software and even after delivery. This directly supports customizability and cost, two of the four criteria that decide a tender.
5. MILESTONES AS LEARNING QUESTIONS: Instead of a phase plan, a milestone reads, for example: “Test three modem dev kits, pick one.” Every step reduces a specific risk. Prototype hardware arrives in three to four weeks here, so planning follows the same rhythm.
Result
A system model (SysML v2) with over 120 requirements on four levels, each assigned to a building block.
A clear interface between the two partner companies, so both can work in parallel at their own pace.
A milestone plan in short stages as the basis for the next proposal: decide step by step instead of approving one long block at once.
What You Can Take Away
Does your requirements spec already name components before it is clear what makes your product win? Then start there, not with the next detail. In the Accelerator Sprint we clarify exactly that with you and your experts and put it into a document you can take to the committee.
160+
items in the requirements catalog, almost all already phrased as a solution
120+
requirements in the system model, each assigned to a building block
3–4
weeks to prototype hardware, which sets the rhythm of the milestone plan