Author: Maik Pfingsten, The Troubleshooter<\/p>\n
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.<\/strong><\/p>\n 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.<\/p>\n 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."\u201e<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n As an example, I have included a system footprint for a smartphone from my seminar materials (see figure).,\u00a0PDF<\/a>-File).<\/p>\n The question of who the user actually is seems trivial \u2013 but often it isn't. For example, are the dealers the customers of a coffee machine manufacturer \u2013 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.<\/p>\n The product is developed for the end customer, i.e., for the buyers of the product or the users of the system \u2013 and that is accordingly the target group to be focused on.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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 \u2013 however, in my experience, the interfaces between systems very often remain poorly coordinated.<\/p>\n Systems can exchange information, energy, or substances via their interfaces \u2013 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.<\/p>\n 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.<\/p>\n The completed system footprint can serve as a basis for writing a requirements specification. But beware \u2013 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!".<\/p>\n 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.<\/p>\n If you want to know more about specifications, simply look at\u00a0https:\/\/lastenhefterstellen.de\/<\/a>\u00a0Over. There I give tips and tricks on creating requirements specifications and write about my agile approach.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of requirements\/embedded and real-time software development.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in the field of requirements\/embedded and real-time software development is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\nFrom mind map to version 4.0: The evolution of the System Footprint<\/h2>\n
Everything at a glance: Structure & content of the system footprint<\/h2>\n
The user<\/h2>\n
The core benefit of our product<\/h2>\n
Use cases<\/h2>\n
Delivery units<\/h2>\n
Core components<\/h2>\n
Core functions<\/h2>\n
System interfaces<\/h2>\n
Existing regulations<\/h2>\n
Visualization \u2013 and much more: System footprint and specifications<\/h2>\n
\nRequirements \u2013 MicroConsult Training & Coaching<\/h2>\n
\nRequirements \u2013 Expertise<\/h2>\n