Software-Analyse und Requirements Engineering Grundlagen

1. Einführung in die Analyse

1.1 Allgemeines

Die Analyse ist ein entscheidender Schritt im Software-Lebenszyklus.

• Die Analyse des Systems beginnt mit der Anforderungsanalyse.
• Um die Anforderungen zu analysieren, müssen diese zuvor ermittelt und dokumentiert werden (Bestimmung der Anforderungen).
• Dieser Prozess wird als Requirements Engineering bezeichnet.

1.2 Definition der Analyse

Die Analyse ist der Prozess, bei dem die Anforderungen des Benutzers an das System (Hardware oder Software) untersucht werden, um eine klare Definition der Systemanforderungen zu erhalten. Dies beinhaltet das Studium und die Verfeinerung dieser Anforderungen.

1.3 Requirements Engineering (Anforderungsmanagement)

Requirements Engineering ist die erste Phase des Software-Lebenszyklus, in der die Spezifikation erstellt wird.

Informelle Ideen müssen erfasst und dokumentiert werden:

• Funktionale Anforderungen: Was soll das System tun?
• Nicht-funktionale Anforderungen: Kriterien zur Messung des Leistungsgrads.

Der Prozess der Entwicklung der Anforderungsspezifikation wird als Requirements Engineering bezeichnet. Seine Bedeutung wächst aufgrund:

• Des richtigen Verständnisses (Erfassung), der Dokumentation (Spezifikation) und der Validierung der Bedürfnisse von Nutzern und Kunden.
• Der Notwendigkeit von Qualitätsmesssystemen, die auf dem Grad der Nutzerzufriedenheit basieren.

1.4 Was sind Anforderungen (Requirements)?

Eine Anforderung ist eine Bedingung oder Fähigkeit, die der Benutzer benötigt, um ein Problem zu lösen oder ein bestimmtes Ziel zu erreichen. Trotz der scheinbaren Einfachheit des Begriffs Anforderung kann die Klassifizierung mit Adjektiven verwirrend sein.

Klassifikation von Anforderungen

Geltungsbereich (Scope)

Der Geltungsbereich gibt an, auf welche Ebene sich die Anforderung bezieht:

• System-Ebene: Die Anforderung muss auf Systemebene erfüllt werden (d.h. eine Kombination aus Hardware und Software).
• Software-Ebene: Die Anforderung betrifft nur die System-Software.
• Hardware-Ebene: Die Anforderung betrifft nur die Hardware.

Wesensmerkmal einer Anforderung

Die häufigste Klassifikation unterscheidet zwischen:

• Funktionalen Anforderungen: Welche Funktionen soll das System ausführen?
• Nicht-funktionalen Anforderungen: Weitere Merkmale des Systems (z. B. Performance, Sicherheit).

Diese Klassifizierung ist nicht immer eindeutig, da eine Anforderung in mehreren Kategorien gleichzeitig klassifiziert werden kann.

Zielgruppe (Publikum)

Diese Dimension gibt an, für wen die Anforderung bestimmt ist und wer sie verstehen sollte. Im Allgemeinen gibt es zwei Hauptzielgruppen:

• Kunden und Benutzer: Sie sind in der Regel nicht im Software-Engineering geschult.
• Software-Entwickler: Sie sind im Software-Engineering geschult.

In dieser Dimension wird oft eine Nomenklatur verwendet, die nach der Zielgruppe ausgerichtet ist:

• Kundenorientierte Anforderungen (C-Anforderungen): Anforderungen aus der Sicht der Kunden und Nutzer.
• Entwicklerorientierte Anforderungen (D-Anforderungen): Anforderungen aus der Sicht der Entwickler.

Darstellung (Repräsentation)

Diese Dimension wird verwendet, um festzustellen, wie die Anforderungen definiert werden. Die Kategorien sind in der Regel:

• Formale Darstellungen: Haben eine strenge Semantik und Syntax.
• Semi-formale Darstellungen: Modelle, die das Verständnis unter den Beteiligten erleichtern.
• Informelle Darstellungen: Ausdrücke in natürlicher Sprache, Texte, Videos, Bilder, Stimme und Klänge, die das zu bauende System beschreiben.

1.5 Ziel der Analyse und Spezifikation

Das Hauptziel ist die Erstellung einer genauen Spezifikation der Software-Anforderungen, die beschreibt, was das System tun soll, jedoch ohne Details, wie es gemacht werden soll.

Software-Requirements Specification (SRS)

Die SRS ist das Dokument, das die Anforderungen enthält. Es sollte idealerweise sowohl C-Anforderungen als auch D-Anforderungen abdecken.

Manche Methoden befürworten jedoch die Trennung dieser Darstellungen in zwei verschiedene Dokumente:

• DRS (Requirements Document System): Auch bekannt als Anforderungskatalog, enthält die C-Anforderungen (kundenorientiert).
• LRA (Lastenheft/Pflichtenheft): Enthält die D-Anforderungen (entwicklerorientiert).

An der Erstellung einer SRS sind beteiligt:

• Software Engineers (Analysten)
• Kunden und Anwender

1.6 Die Prinzipien der Analyse

• Die Tragweite des Problems muss dargestellt und die relevanten Informationen verstanden werden.
• Es sollten Informationsmodelle entwickelt werden, um die funktionale Komponente und die System-Performance darzustellen.
• Modelle müssen unterteilt werden, um Details progressiv oder hierarchisch darzustellen.
• Der Analyseprozess muss detailliert sein, um die wesentlichen Informationen zu erfassen.

1.6.1 Informationsdarstellung

Informationen können auf drei Arten dargestellt werden:

1. Informationsfluss
2. Informationsgehalt
3. Informationsstruktur

1.6.2 Modellbildung (Modeling)

Modellbildung dient dazu, die Komplexität zu reduzieren und zu bekämpfen. Der Fokus liegt darauf, was das System leistet.

Grafische Darstellungen ergänzen Textinformationen. Typen von Modellen:

• Logische Modelle
• Physikalische Modelle

Warum Modelle erstellen?

Im wirklichen Leben werden viele Arten von Modellen für verschiedene Zwecke erstellt. Die Hauptziele der Modellbildung sind:

• Prüfung einer physischen Einheit vor dem Bau.
• Kommunikation mit den Kunden.
• Visualisierung.
• Reduzierte Komplexität.
• Strukturierung von Ideen.