Guest Post by

Visualized Understanding: The System Footprint

In my time as a troubleshooter I have spent over ten years rescuing international development projects. The goal is to salvage the project within 6 months and nurture it back to success. I always start by building the team and ascertaining what the strains on the system are. I need clarity about the requirements if I am going to develop a strategy for the difficult negotiations I am about to face.

In most of the projects teams don’t even have requirements specifications by the time I get there, neither from the manufacturers nor from the developers. As a result everyone fumbles around with power point slides, emails and other documents – without actually showing me requirement specifications. The most important for me is to be able to get a broad overview of the system requirements quickly. Based on that assessment I can figure out what is realistic and achievable in the next few months. That’s how the system footprint was born. In the words of a Daimler component manager: “Finally, a meta-picture of our system and its requirements.”

From the Mind Map Stage to Version 4.0: Developing a System Footprint

I really got into developing the system footprint while using a mind map in 2005. Whenever I entered a project as a troubleshooter I used the mind map I had created to summarize the system requirements. That generally worked quite well, but it was not universally applicable in my workshops. In 2007 I stumbled upon a visualization tool that used “canvas” and other kinds of post-its, which helped me to push the mind map into the second system footprint generation. It was much easier to work with them in the workshops.

A third generation was born out of intensive discussions with listener communities from my podcast, which I used successfully until 2015. Simultaneously I took the time to gather the experiences I gained in the hundreds of workshops I moderated into the fourth system footprints generation.

A Broad Overview – Developing the System Footprint Content

When we create requirements specifications and describe requirements, at some point it becomes essential to decide whether a requirement is useful or not. We can make these decisions a lot more easily if we keep the core use of the system and its significant components in mind. This can be visualized very effectively on a canvas as a system footprint. Divide a large white surface into parts, some of those parts can then be filled with content in the context of a workshop.

I took a picture of a system footprint with my phone after a workshop.

System footprint in workshop

System footprint example from a workshop

System footprint version 3.0 is the basis of this visualization. The following are system footprint sections, as seen in the example:

The User

The question of who the user really is seems to be trivial, but it often is not. If you are a coffee machine producer then retailers are your customers – or consumers your real customers? Is a ticket manufacturer’s client the train companies out there? Or is perhaps the ordinary passengers who use the system in order to buy a ticket? Motorist are the final users in the auto-industry. They are the ones who use the system and decide whether or not to buy the car. Products are developed for the end user – that is, the buyers of the product, i.e. the users of the system – they are the target audience.

Our Product’s Core Value

A coffee machine’s core value is not always just the production of coffee. There are a few other significant reasons why customers buy a premium coffee machine: e.g. quality, status, design etc. That is the true value proposition that leads consumers very emotionally driven purchasing decisions.

Use Cases

Use Cases describe how the users are supposed to use the system. The idea stems from SysML. This knowledge helps us to develop a system design that fulfills the value proposition in all cases.

Delivery Units

When we deliver a product, we have different variations and different patterns that we need to consider in our development projects. In the coffee machine example those could be the “premium classic”, “premium gold” and “premium future” variations. All three are coffee machines, and all of them are based on the same system design yet they all have different functional focuses.

Core Components

Systems don’t appear out of nothing and they are rarely completely new. Companies tend instead to work according to a stacking system in which system engineers can always define a new kind of fundamental system architecture. Because they use tested components time can be saved and risks avoided.

Core Functions

In order to create core value within our system the project must be able to describe the core functions. These functions can be divided among several components and should therefore be explicitly examined in the system footprint. There are many advantages to having broad discussions among developers about these kinds of topics – it gives everyone a chance to develop a better understanding of the system.

Interfaces are vital. They are the site at which systems exchange energy, information or materials. In the coffee machine example the plug is not the only interface necessary for transferring energy. We also have an interface that deals with the exchange of water. And then there are interfaces with people. Buttons are an interface in the form of physical pressure, then the display is an interface through which information is exchanged. Often the interfaces with people are the ones that are forgotten.

System-Interfaces

Interfaces are vital. They are the site at which systems exchange energy, information or materials. In the coffee machine example the plug is not the only interface necessary for transferring energy. We also have an interface that deals with the exchange of water. And then there are interfaces with people. Buttons are an interface in the form of physical pressure, then the display is an interface through which information is exchanged. Often the interfaces with people are the ones that are forgotten.

Existing Specifications

System specifications also need to be clearly defined. Those can be specifications pertaining to water pressure, or they could include standards and norms, temperature, weight, height, (software) architecture, texture, ergonomics, packaging etc. All of them need to be described here. Generally constraints are non-functional requirements that can be defined in more detail in terms of their technical and stakeholder specifications, allowing us to distinguish them better from each other.

The system footprint 4.0 in action

Working with the system footprint 4.0

Visualization – and Much More: System Footprints and Requirements Specifications

The final system footprint can be used to write requirements specifications. But beware – I always hear the following objections when people take this step: “We’ve already documented a lot of this stuff. We have word documents, power point slides, meeting minutes etc. Just throw those in there and we’re done!”

Nothing could be further from the truth. In my experience on average only 20% of system footprint post-its would be addressed if we simply “threw everything in there”. The other 80% is left untouched. The system footprint is useful for filling in the requirements specifications correctly. Its visualization allows everyone to see which requirements are still missing and which need to be described clearly.

Example of System Footprint 4.0

Example of System Footprint 4.0

 

Dipl.-Ing. Maik Pfingsten is a speaker, mentor and troubleshooter with a focus on Systems Engineering. His 14 years of experience have made him one of the masterminds in the area of systems engineering.

Tags: ,
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *