Während eines Projektes im Umfeld der Systemanalyse eines eingebetteten Systems für die Automobilindustrie erlebte ich es als eine der Hauptherausforderungen, bei der Systemspezifikation die Problem-Ebene von der Lösungs-Ebene zu trennen.
In diesem Projekt nutzten wir sowohl zur Darstellung des Problems als auch zur Darstellung der Lösung jeweils Datenflussmodelle, die unsere Spezifikationen strukturell zusammenhielten. Um in der Kommunikation mit den Stakeholdern und Entwicklern besser auf die unterschiedliche Bedeutung der Datenflüsse für die Problembeschreibung und der Datenflüsse für die Lösungsbeschreibung aufmerksam zu machen, entschieden wir uns, diese in „physische“ (engl. physical) und „logische“ (engl. logical) Informationsflüsse zu unterteilen. Jeder, mit dem ich über diese Klassifikation der Datenflüsse sprach, empfand diese Unterscheidung sofort als einleuchtend und sinnvoll. Als ich jedoch mit den Entwicklern zusammen versuchte, diese Informationsflüsse zu identifizieren und zu klassifizieren, hatte ich plötzlich den Eindruck, dass wir ständig aneinander vorbeiredeten und völlig unterschiedliche Vorstellungen davon hatten, welches denn nun die „logischen“ und welches die „physischen“ Informationsflüsse seien. Es kristallisierten sich offensichtlich zwei völlig verschiedene Vorstellungen heraus. Hardware-Entwickler schienen tendenziell die Realität, also das Problem, als „physisch“ zu betrachten, während sie Informationen über die Realität, die beispielsweise über einen Datenbus gesendet wurden, als „logisch“ empfanden. Ich dagegen, sowie der Großteil der Software-Entwickler, war der Meinung, dass Informationen, die die Realität beschrieben, „logisch“ seien und die technische Abbildung dieser Informationen im Speicher oder auf Datenbussen deren „physische“ Repräsentation darstelle.
Je mehr ich versuchte, mich mit den Entwicklern auf die eine oder andere Definition zu einigen, desto mehr wurde mir von der jeweils anderen Partei klar gemacht, ich würde ihre Welt einfach nicht verstehen. Letztendlich musste ich dafür sorgen, dass für die Unterscheidung unserer Informationsflussarten neutrale Bezeichnungen geschaffen wurden, die nicht mit vorhandenen Betrachtungsweisen kollidierten und deren Bezeichnungen idealerweise unmissverständlich den Zweck der jeweiligen Informationsart kennzeichnete.
Nach vielen Diskussionen und Erwägungen haben wir uns für die Bezeichnungen „informative“ Informationsflüsse (engl. informative) und „technische“ Informationsflüsse (engl. technical) geeinigt. Dabei bezeichnete „informativ“ diejenigen Informationen, die die Realität (das Problem) beschrieben, während „technisch“ die Repräsentation von Informationen durch das System (die Lösung) bezeichnete, z.B. auf Datenbussen oder in Speichertabellen.
Ich will zwar nicht völlig ausschließen, dass die zuletzt gewählten Begrifflichkeiten auch gegensätzlich interpretiert werden könnten, dies ist in dem erwähnten Projekt jedoch nicht vorgekommen.

Hinweise:

  • Das hier beschriebene Missverständnis wurde dadurch verstärkt, dass unsere Begrifflichkeiten englisch waren. Das Wort „physical“ bedeutet auf deutsch sowohl „physisch“ als auch „physikalisch“.
  • Falls Sie mehr über das Vermeiden von Missverständnissen in Anforderungen und das Trennen von Problem und Lösung erfahren möchten, empfehle ich Ihnen, sich unser Kursangebot einmal näher anzusehen z.B.: