Libeskind -
Share ZU:
23 September 2025 @ Andreas Kreß

Mehrfachbelegungsfelder für die Allokation von Architekturkomponenten – Teil 1

Anforderungsmanagement ist Attributierungsarbeit

Die Verwaltung von Attributen, die einzelnen Anforderungen zugeordnet sind bzw. deren Wertebelegungen gerade eine eindeutige Anforderung ausmachen, gehört wohl schon seit der Erfindung von Tabellen zur Arbeit und Niederschrift von Anforderungen in Anforderungssammlungen vulgo Lastenheften.

Wie alle Verwaltungstechniken konnte sich die Anforderungs-Spezifikationsarbeit auch nicht dem Wandel der Zeit von der analogen und physischen Papierwelt in das informatorische digitale Zeitalter entziehen.

Informationstechnische Evolution gilt auch für Anforderungen

Genauso wirkt die informationstechnische Evolution weiterhin fort. War es erst eine Digitalisierung im herkömmlichen Sinn, das physische Dokument wurde ein virtuelles, so wirken heute die Kräfte der digitalen Transformation und haben die Spezifikationsarbeit zu einem sehr viel agileren und kollaborativen Unterfangen gemacht. Die sogenannte Künstliche Intelligenz spielt dabei heute noch mehr die Rolle eines weiteren Stakeholders oder Entwicklungshelfers, der, wenn er als Ausfüllhilfe agiert, immer noch auf Halluzinationen überprüft werden muss.

Aufgrund dieser Tatsache ist eine Anforderungsspezifikation nicht mehr nur allein ein Kunstwerk, das von den erfahrensten alten Meistern, an kaum auffindbaren Stellen, erstellt und mit viel Liebe zum Detail, als mit LaTeX fein gesetztes PDF-Dokument, in den Umlauf gebracht wird. Nein – es ist ein transparenter “Online-Prozess” geworden!

Der Leim der alles zusammenhält

Über all diese Entwicklung hat sich nur eine Sache hartnäckig erhalten: Attribute, Felder – Metainformation. Mehr denn je spielen diese Feinstrukturen der Anforderungsdaten die maßgebliche Rolle im Tagesgeschäft des Requirement Engineers. Anforderungsattribute können wir als den Leim betrachten, der den Kernprozess RM (Requirements Management) mit allem verbinden kann, was der “große” Entwicklungsprozess “außen herum“ zu bieten hat.

Alle wollen einen “Leim”, der gut hält und ideal für das Material ist, Belastungsprofilen und Umwelteinflüssen gewachsen ist. So lohnt es sich, diesen Bereich bei RM-Werkzeugen detailliert kennenzulernen.

Wir nehmen uns im Teil 2 die Tools DOORS (IBM) und Polarion (Siemens) vor und konzentrieren uns auf die Kür in der Attributdefinition – die Multivalue-Attribute. Multivalue-Attribute sind Auswahlfelder, die mit mehreren Werten gleichzeitig belegt werden können.

Ohne multioptionale Attribute geht es nicht

Diese Felder die der RM Tool Nutzer über Mehrfachauswahl Dialog Elemente bearbeiten kann, sind in verschiedensten Anwendungsfällen sinnvoll. So könnte die Qualitätssicherung verlangen, dass einer Anforderung Absicherungsmaßnahmen zugeordnet werden. Dabei ist leicht denkbar, dass mehrere Absicherungsmaßnahmen in Frage kommen. Oft findet man Multivalue-Ansätze in der Variantenbildung. Eine Spezifikations-Datenbasis soll für eine Produktfamilie oder verschiedene Länderausprägungen Verwendung finden. In solchen Fällen ist der Gleichanteil von Anforderungstexten in der Regel hoch, da ist es sinnvoll, Anforderungen an Kombinationen der Varianten zu binden. Man erhält so eine, manchmal als “150% Spezifikation” bezeichnete Quelle für produktspezifisch ausgeprägte „100%“ Anforderungsdokumente.

Ein letztes, geradezu klassisches Beispiel für die Verwendung solcher, auch als multioptionale Attribute bezeichenbaren Anforderungsdaten, stellt die architekturelle “Allokation” dar. Verfolgt mein Anforderungsmanagement den Systembreakdown synchron, indem es systembestandteil-zugeordnete Anforderungssammlungen enthält, so ergibt sich auf übergeordneten Ebenen die zwingende Zuordnung, für welche Subsysteme die Anforderungen denn nun gültig sein sollen.

Am anschaulichsten werden die Vorgehensweisen in der beispielhaften Verwendung, diese stellen wir dir vergleichend mit den beiden oben erwähnten Werkzeugen im Teil 2 vor.

Gibt es in deinem Umfeld „Mehrfachauswahlfeld“ Herausforderungen? Kontaktiere uns gern und vereinbare mit unseren Experten ein unverbindliches Gespräch!

Dieser Blogbeitrag wurde von Andreas Kreß für HOOD geschrieben.

Series NavigationMehrfachbelegungsfelder für die Allokation von Architekturkomponenten – Teil 2 >>

Diskussion

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*dieses Feld ist erforderlich

Profile Picture

Andreas Kreß

Kontaktieren Sie Andreas Kreß

The Software Engineer Andreas Kreß has served in roles like start-up product owner and requirements team manager at critical customer projects in the tech industries. He is the inventor of a widely used SCADA tool and helped set up methods and engineering tool environments from Y2K IT projects over large federal fiscal software standardization programs to automotive autonomous driving components development. He is a connoisseur of many intimate secrets of the art of developing systems. His focus is on the more far-reaching methods and tools in regulated and security-oriented systems engineering.

Wissen, das bewegt!

Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.

Jetzt abonnieren und keine wichtigen Insights mehr verpassen!