EN 
DE How can I capture wild customer demands?
Author: Maik Pfingsten, The Troubleshooter
Contribution – Embedded Software Engineering Congress 2016
During my time as a troubleshooter, I spent over 10 years rescuing international development projects. The goal was always to get a project back on track and successfully completed within the next six months. To achieve this, I first rebuilt the team and assessed the load on the system under development. Finally, to develop a sound strategy for the subsequent, tough negotiations with stakeholders, I needed clarity regarding the requirements.
In most projects, there was essentially no requirements specification before my arrival, neither from the manufacturer nor from the supplier or development service provider. Consequently, everyone was working with various PowerPoint slides, emails, and other documents, but not with a real requirements specification.
In these situations, it was crucial for me to have something tangible that would allow me to quickly create a comprehensive picture of the system requirements. Only then could I decide what was realistically and practically achievable in the coming months. This is how the system footprint came about. To quote a component manager at Daimler: "This is finally a meta-image of our system and its requirements."„
From mind map to version 4.0: The evolution of the System Footprint
The development of the System Footprint began in 2005 with a mind map. When I joined a project as a troubleshooter, I used this mind map to compile the various system requirements. While this generally worked well, it wasn't yet ideally suited for use in workshops. In 2007, I stumbled upon the idea of visualization using a canvas and numerous Post-it notes, and I incorporated the mind map into the second generation of the System Footprint. This version proved significantly more effective in workshops.
Intensive discussions with the listener community of my podcast led to the third generation, which I successfully ran until 2015. In that same year, I finally took the time to incorporate my experiences from over one hundred moderated workshops into the fourth generation of the System Footprint.
Everything at a glance: Structure & content of the system footprint
When we create a requirements specification and describe requirements within it, at a certain point it is essential to decide whether a requirement makes sense for the system or not. We can make these decisions more easily if we keep the core benefits of the system and its essential components in mind. This can be visualized very effectively on a "canvas" as a system footprint: On a large, white surface divided into different areas, sections can be filled with content, for example, during a workshop.
As an example, I have included a system footprint for a smartphone from my seminar materials (see figure)., PDF-File).
The user
The question of who the user actually is seems trivial – but often it isn't. For example, are the dealers the customers of a coffee machine manufacturer – or are they the users of the coffee machine? Is the railway company the customer of a ticket manufacturer? Or the passenger who uses the system to buy a ticket? In the automotive industry, is the supplier's customer always the car manufacturer? Ultimately, the real user is the driver; they use the system and decide whether to buy the car.
The product is developed for the end customer, i.e., for the buyers of the product or the users of the system – and that is accordingly the target group to be focused on.
The core benefit of our product
The core benefit of a coffee machine is not always just making coffee: there are, for example, a few crucial reasons why customers buy a premium coffee machine, namely quality, status, design, etc. This is the product's value proposition and leads to a very emotional purchase decision that must not be undermined under any circumstances.
Use cases
Use cases describe how the customer uses the system. This concept originates from SysML, where it's referred to as "use cases." Understanding these use cases helps us later define the customer's requirements, ensuring the system delivers on its promise in each of these scenarios.
Delivery units
When we deliver a product, we have different variants and also different prototypes that we have to consider in a development project. In the case of the coffee machine, these could be the variants "Premium Classic", "Premium Gold", and "Premium Future". All three are coffee machines based on the same system design, but with different functional features.
Core components
Nowadays, a system is rarely developed from scratch and is entirely new in itself. Instead, companies consciously or unconsciously work with a modular system, allowing systems engineers to repeatedly define a basic system architecture. Because tested components are used, time and risk are reduced.
Core functions
To generate core value with our system, the project must identify and describe its key core functions. These core functions can be distributed across one or more components and should therefore be explicitly considered in the system footprint. Intensive discussions with the developers on these topics are highly beneficial, as they lead to a better understanding of the system for everyone involved.
System interfaces
When we talk about products, defining the system boundaries is crucial. Only then can everyone involved clearly agree on which system we're discussing. At the same time, interfaces are typically where most errors occur. Developers have a strong interest in the implemented components and want to achieve a positive result – however, in my experience, the interfaces between systems very often remain poorly coordinated.
Systems can exchange information, energy, or substances via their interfaces – interfaces are therefore essential: In our coffee machine, not only the power plug and energy transfer are interfaces. We also have the interface to the water line, through which water is exchanged. And finally, there are also interfaces with people: Control buttons are an interface in the form of pressure energy, and the display also represents an interface through which information is exchanged. It is often precisely these interfaces with people that are frequently overlooked.
Existing regulations
System requirements must also be clearly defined. These can include specifications for the supply voltage, but also requirements relating to standards and norms, climatic conditions, weight, size, (software) architecture, haptics, ergonomics, packaging, etc. Constraints are generally non-functional requirements that can be further divided into technical specifications and stakeholder specifications for better differentiation.
Visualization – and much more: System footprint and specifications
The completed system footprint can serve as a basis for writing a requirements specification. But beware – I've repeatedly heard the following statements at this point: "We've already documented much of this. Here are Word documents, PowerPoint slides, meeting minutes, etc. Just dump them in there and everything's done!".
But that's far from the truth. In my experience, on average, only 20% of the system footprint sticky notes are actually used when we "dum everything in"; the other 80% remain more or less empty. However, the system footprint is also useful for filling out the requirements specification in a meaningful and efficient way: thanks to its visualizations, everyone can quickly see where requirements are still missing or not clearly described.
If you want to know more about specifications, simply look at https://lastenhefterstellen.de/ Over. There I give tips and tricks on creating requirements specifications and write about my agile approach.
Requirements – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of requirements/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Requirements – Expertise
Valuable expertise in the field of requirements/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
