System-Analyse und System-Spezifikation (Requirements Engineering)

Im deutschen Sprachgebrauch wird dieser Bereich häufig mit Anforderungsmanagement bezeichnet, was nicht ganz richtig ist. Im Englischen wird der Begriff Requirements Engineering verwendet, was schon etwas besser passt.  

System-Analyse und -Spezifikation gehen jedoch noch weit darüber hinaus und beinhalten z.B. auch Risiko-Abschätzungen (Risk Management) oder FMEA (Failure Mode and Effects Analysis). In Embedded Systemen sind dies in sicherheitsrelevanten Bereichen vorgeschriebene Tätigkeiten. Ein Embedded System besteht immer aus Software und Hardware. Damit verbunden gibt es neben dem Software Engineering weitere Fachdomänen wie Elektrotechnik oder Maschinenbau.

Klassisch sollten die ersten Schritte eines Projektes darin bestehen, dass die Anforderungen an das System definiert und analysiert werden. Auf Basis dieser System-Analyse wird dann eine System-Spezifikation erstellt. Diese ist dann die Basis und Zielvorgabe für die Entwicklung, Produktion, Inbetriebnahme, Service und Entsorgung - also den gesamten Lifecycle des Systems. Hier sehen wir schon einige Unterschiede im Bereich der Entwicklung von Embedded Systemen gegenüber der klassischen Informatik und in der Anwendungsprogrammierung. 

In den ersten Phasen der System-Analyse sprechen wir auch von Systems-Engineering. Mit Systems-Engineering ist das domänenübergeordnete Engineering gemeint. In späteren Phasen werden die Anforderungen dann den Fachdomänen zugeordnet (auch als Hand Of bezeichnet).  

Somit beschreibt die System-Spezifikation das gesamte System - unabhängig durch welche Domäne die Anforderungen später einmal entwickelt und produziert werden. Das ist ein nicht unerheblicher Unterschied zum Requirements Engineering im Bereich der klassischen Informatik, da auch die Fachsprachen außerhalb des Software-Engineering angesiedelt werden.  

Systemanalyse und Systemspezifikation beinhaltet folgende Bereiche:

  • Anforderungsspezifikation (Req. Capture)
    Anforderungsspezifikation bezeichnet das Finden, Definieren und Dokumentieren von Anforderungen. Hier gibt es verschiedene hilfreiche Vorgehen und Regeln - z.B. über die Definition von Anforderungen (Eindeutig, Vollständig, Verstehbar ...), die Sprache (natürliche Sprache, UML, MSCs ...) und Vorgehen (Req. Capture, Stakeholder Analyse, Brainstorming ...), die die Qualität und effizientes Vorgehen bei der Anforderungsspezifikation sicherstellen.       
  • Anforderungsanalyse (FMEA, Risk Management ...)
    Die in der Anforderungsspezifikation erarbeiteten Anforderungen sollten nun analysiert werden, z.B. auf Konsistenz (sich widersprechende Anforderungen). Eine der häufigsten Widersprechungen entsteht schon, wenn die grundlegenden Qualitätsattribute (Kosten, Wartbarkeit, Erweiterbarkeit, Änderbarkeit ...) nicht hinreichend definiert wurden. So können sich beispielsweise geringes Gewicht und Stabilität widersprechen. Außerdem müssen bei sicherheitsrelevanten Systemen Risiko-Abschätzungen und Risiko-Eingrenzungen durchgeführt werden.
  • System-Spezifikation
    Mit den Ergebnissen der Anforderungsanalyse wird die System-Spezifikation definiert und bildet damit die Vorgabe für die Entwicklung und Produktion. Fehler in der System-Spezifikation werden meist sehr teuer, wenn sie spät erkannt werden.       
  • Anforderungsmanagement
    Je nach Situation sind die entstehenden Tätigkeiten, Rollen und Dokumente unterschiedlich. Häufig werden Systeme nicht mehr von einem Unternehmen allein entwickelt und produziert. Es gibt dann einen so genannten OEM (Original Equipment Manufacturer), der mit seinem Namen das System am Markt positioniert, zum Beispiel ein Automobilhersteller wie VW. Dieser bezieht jedoch heute den größten Teil der Komponenten von Zulieferern. Oft gibt es also ein komplexes Beziehungsgeflecht zwischen Firmen und deren Produkten, die dann zu einem System zusammengefügt werden müssen.

    Dann müssen die Anforderungen des Gesamtsystems auf die Teilkomponenten heruntergebrochen werden. Es entstehen Auftrag-Geber und Auftrag-Nehmer- Beziehungen, in denen die Anforderungen sehr häufig die Grundlage der Verträge bilden (In Deutschland werden die Anforderungen häufig in Form von Lasten- und Pflichtenheften definiert). Bei heutigen Systemen (zum Beispiel einem PKW) entstehen extrem komplexe Geflechte an Beziehungen zwischen den einzelnen Anforderungen. Das Managen dieser Beziehungen wird auch als Anforderungsmanagement bezeichnet.

    Anforderungsmanagement von komplexen Systemen ist ohne Unterstützung von Datenbanken (Repositorys) nicht mehr effizient und fehlerfrei möglich. Aus diesem Grund werden zunehmend Anforderungsmanagement-Werkzeuge (IBM Rational DOORS, Polarion Requirement, IRQA ...) eingesetzt.

    Vor allem über Linkbeziehungen können mit Hilfe der Werkzeuge die Beziehungen zwischen Anforderungen definiert werden. Auf dieser Basis können dann die Traceability-Analysen durchgeführt werden, z.B. um abzusichern, dass bei Änderungen alle Aspekte im System berücksichtig wurden. Auch das Managen von Anforderungen hinsichtlich Versionen oder Varianten fällt in den Bereich Anforderungsmanagement.  


    Abbildung für Anforderungsmanagement


Newsletter abonnieren



Empfehlung an diese E-Mail-Adresse senden:


 

 

 

Ihre eigenen Angaben:

 

 

 

 

Diese Seite empfehlen Sie weiter: