Serie „Requirements Engineering für KMU“ – Teil 8 Requirements Engineering – Zusammenhang von Anforderungen und Architektur

Anbieter zum Thema

Heitec AG

MicroConsult Academy GmbH

emlix GmbH

Wie lassen sich im Requirements Engineerung Anforderungen und Architektur jeweils ermitteln anschließend vereinen? Denn diese repräsentieren in der Regel die Interessen und Rollen verschiedener Interessensgruppen: Die Kunden und Stakeholder auf der einen, das Projektteam auf der anderen Seite.

Diese Serie beschäftigt sich mit der Frage, warum gründliches Requirements-Engineering insbesondere für kleinere und mittlere Unternehmen in der Elektronikindustrie vorteilhaft sein kann. Bisher haben wir schon viele Aspekte erörtert, darunter Grundlagen, Abstraktionsebenen, funktionale und nicht-funktionalen Systemanforderungen sowie Randbedingungen. Wir haben erläutert, wie Anforderungen erhoben und dokumentiert werden können, und welche Aspekte zu beachten sind, um sie günstig effektiv und zielführend zu formulieren.

Heute wird es besonders spannend, denn wir diskutieren die Frage, wie sich Anforderungen und Architektur jeweils ermitteln und anschließend vereinen lassen, zumal sie die Interessen und Rollen verschiedener Interessensgruppen repräsentieren: Die Kunden und Stakeholder auf der einen, das Projektteam auf der anderen Seite. Der Requirements-Engineer möchte das Problem aufgreifen, der Systemdesigner versucht, die Lösung zu definieren. Je komplexer ein System und je mehr Beteiligte, wie etwa Lieferanten, involviert sind, umso detaillierter sollte die Erfassung von Problem- und Lösungsraum ausfallen.

Des Weiteren verfeinern sich Anforderungen und Architektur immer mehr, je tiefer man in die Elemente des Systems hinabsteigt. Das in Bild 1 gezeigte "Twin Peaks Modell" verdeutlicht dies.

Problem- und Lösungsraum: Teile und herrsche?

Probleme, die damit verbundenen Anforderungen und Lösungen sind unausweichlich miteinander verbunden. Eine strikte Trennung der Anforderungen von den Systemdesign- und Implementierungsaktivitäten gestaltet sich daher schwierig, weshalb Entwicklungsprozesse in einem strikten Wasserfallmodell oft nicht optimal funktionieren.

Dennoch sind Requirements-Engineers angehalten – und erfahrene Experten bestrebt – Anforderungen und Lösungen bei deren Analyse, Kommunikation und Dokumentation weitestgehend voneinander zu trennen. Diese Abgrenzung macht es leichter, die mit den Anforderungen verbundenen Aufgaben zu bewältigen und Projekttransparenz sowie Nachvollziehbarkeit zu erreichen.

Wo dokumentieren?

Anforderungen von System, Subsystemen und Komponenten können in einer oder mehreren der Struktur des Systems folgenden Anforderungsspezifikationen dokumentiert werden. Auch eine Trennung nach Domänen (z.B. Software, Hardware, Mechanik) kann je nach Struktur des Systems sinnvoll sein. Bei einer Tool-gestützten Anforderungsdokumentation können den Anforderungen zugehörige Hierarchieebenen über Flags oder Parameter zugewiesen werden.

Wir erinnern uns an Teil 2 dieser Artikelserie, in dem es um Abstraktionsebenen von Anforderungen ging. Auch diese Abstraktionsebenen können sinnig zur Strukturierung der Anforderungs- und Architekturdokumente herangezogen werden.

Im deutschsprachigen Raum sind die Dokumente Lastenheft und Pflichtenheft sehr verbreitet, im englischsprachigen Raum wird meist von unterschiedlichen „Specifications” gesprochen. Bild 3 illustriert beispielhaft unterschiedliche Anforderungs- und Architekturdokumente auf verschiedenen Abstraktionsebenen.

In Germany: Lasten- und Pflichtenheft

Lasten- und Pflichtenheft differenzieren sich nach der DIN-69901-5 wie folgt:

Lastenhefte beinhalten die vom Auftraggeber festgelegte Gesamtheit der Anforderungen an die Lieferung und Leistung eines Auftragnehmers innerhalb eines Auftrags.

Das Pflichtenheft umfasst zwei Bereiche: Zum einen vom Lastenheft abgeleitete Anforderungen, zum anderen die Systemarchitektur, d. h. die Lösungssicht.

Im angelsächsischen Raum wird auf Business- und Systemebene mit unterschiedlich benannten Requirement Specifications gearbeitet. Auf Systemebene werden Anforderungen und Architektur typischerweise in unterschiedlichen Dokumenten dargestellt. Verbreitete Begriffe sind „System Requirements Specification“ und „System Architecture Specification“.

Auf Subsystem- und Domänenebene existieren weder im deutschsprachigen noch im angelsächsischen Raum feste Konventionen. Hier überwiegen Organisations- und System-spezifische Strukturen und Nomenklaturen für die Dokumente.

Die Mitarbeiter der HEITEC AG sind mit unterschiedlichen Prozessen und Arten der Anforderungs- und Architekturdokumentation vertraut. Sie passen sich flexibel den kundenseitigen Vorgehensweisen an und unterstützen den Kunden wo nötig.

Im nächsten Teil spielen die weitverbreiteten Begriffe Verifikation und Validierung die Hauptrolle.  (sg)

Serie „Requirements Engineering für KMU“ – Teil 2

Anforderungstypen im Requirements Engineering

Serie „Requirements Engineering für KMU“ – Teil 7

Requirements Engineering – Modellbasierte Anforderungen

* Stefan Lange ist Teamleiter Systems Engineering im HEITEC Geschäftsgebiet Elektronik und Dozent für Systems Engineering an der Hochschule Augsburg.

* Moises Lorenzo-Leon ist Systemingenieur im HEITEC Geschäftsgebiet Elektronik und Certified Professional für Requirements Engineering.

(ID:50662453)