Requirements Engineering in der Softwareentwicklung

Inhaltsverzeichnis

Zusammenfassung

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Ausgangssituation
1.2 Aufgabenstellung
1.3 Ziel der Arbeit

2 Der Begriff des Requirements Engineering
2.1 Aufgaben des Requirements Engineering
2.2 Qualitätskriterien für jede einzelne Anforderung
2.3 Folge von unzureichendem Requirements Engineering
2.4 Risiken

3 Modelltechniken
3.1 Datenflussmodelle – Use-Case-Diagramme
3.2 Zustandübergangsmodell
3.3 Entscheidungstabellen
3.4 Entity Relationship Attribute Modell
3.5 Strukturierte Sprache
3.6 Aktivitätsdiagramme
3.7 Klassendiagramme

4 Prüfen von Anforderungen
4.1 Prüftechniken – das Review
4.2 Die Reviewbeteiligten
4.3 Nicht-Funktionale Anforderungen
4.4 Testorientiertes Requirements Management – das V-Modell
4.5 Checklisten für die Testbarkeit

5 Schlussfolgerung

Literaturverzeichnis

Zusammenfassung

Die vorliegende Arbeit beschäftigt sich mit dem Thema Requirements Engineering in der Softwareentwicklung. Zuerst wird ein Überblick gegeben, welche Aufgaben das Requirements Engineering wahrnimmt, sowie welche Qualitätskriterien beim Erstellen von Anforderungen an diese gestellt werden sollten. Weiters wird erläutert, welche Gefahren und Risiken drohen, wenn sich dieser Thematik nicht näher angenommen wird. Ferner wird auf die verschiedensten Arten von Modelltechniken eingegangen. Aufgrund der Vielzahl von verschiedenster Modellierungstechniken wird auf ausgewählte Techniken eingegangen. Verstärkt wird jedoch der Punkt des Prüfens von Anforderungen behandelt und hierbei auch die Notwendigkeit der abteilungsübergreifenden Zusammenarbeit.

Abstract

This thesis will deal with the topic of requirements engineering in software development. First, an overview will be given of the purpose of requirements engineering, As well as the quality criteria which should be observed when requirements are prepared. Moreover, the risks and dangers which can occur when software producing companies do not pay adequate attention to this subject matter will be explained. Further there are a lot of different techniques how to describe requirements. Due to the fact that this topic is very large, this thesis will only give a short overview of some modelling techniques. The necessity of a good cooperation between departments and also a regular review of requirements will be the last and most important part of this paper.

Abbildungsverzeichnis

Abbildung 1: Tätigkeiten und Methoden im Rahmen des RE

Abbildung 2: Unzureichendes RE

Abbildung 3: Use-Case-Diagramm

Abbildung 4: Zustandsübergangsmodell

Abbildung 5: ERA-Modell

Abbildung 6: Aktivitätsdiagramm

Abbildung 7: Klassendiagramm

Abbildung 8: V-Modell

Tabellenverzeichnis

Tabelle 1: Textuelle Use-Case Beschreibung

Tabelle 2: Beispiel Entscheidungstabelle

Tabelle 3: Beispiel Strukturierte Sprache

Tabelle 4: Prüfende Personen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

In folgenden 3 Punkten wird die Ausgangssituation, Aufgabenstellung und das Ziel dieser Arbeit beschrieben.

1.1 Ausgangssituation

Unternehmen jeglicher Art, egal ob sie Produkte entwickeln oder Dienstleistungen anbieten, haben mit einem ständig wachsenden Berg von Anforderungen zur Produktentwicklung zu kämpfen. Im Sektor der Softwareentwicklung wird Requirements Engineering noch mangelhaft betrieben. Es ist daher für ein Unternehmen von Wichtigkeit, dass Anforderungen strukturiert behandelt und analysiert werden. Diese Aufgabe wird, wenn überhaupt, oft von einer einzelnen Abteilung wahrgenommen, welche recht autark von der restlichen Firmenstruktur agiert.

1.2 Aufgabenstellung

In dieser Arbeit soll die Wichtigkeit des Requirements Engineering in der Software produzierenden Industrie erläutert werden. Es soll auch dargestellt werden, mit welchen Mitteln agiert werden kann und wie diese eingesetzt werden sollten. Da die ganze Thematik des Requirements Engineerings jedoch umfangreich ist, wird sich diese Arbeit damit befassen, einen fokussierten Überblick über Teilgebiete der Qualität und des Prüfens von Anforderungen zu geben.

1.3 Ziel der Arbeit

Ziel dieser Arbeit ist eine Übersicht über die heutzutage gängigsten Modelltechniken zur Erstellung von Anforderungen in der Softwareentwicklung zu geben, sowie eine Darlegung in welcher Qualität diese geliefert werden müssen. Hierzu werden auch der Entstehungsprozess von Anforderungen und die dabei wichtige Rolle des Softwaretests beleuchtet.

2 Der Begriff des Requirements Engineering

Unter „Requirements Management/Engineering“ (RE) wird allgemein die geordnete, methodische Behandlung von Anforderungen in einem Projekt verstanden.^[1]

Requirements Engineering ist innerhalb des Software Engineering bzw. des Systems Engineering^[2] die Disziplin, die sich mit den gewünschten Eigenschaften bzw. Einschränkungen von Softwaresystemen befasst.^[3] Wird Requirements Engineering als Querschnittsprozess betrachtet, so erstreckt sich RE über die Fragestellung der Ziele und Zielerrechnung eines Softwaresystems von Beginn des Marketing und Produktmanagements, über die Projektplanung bis hin zur Ausführung, Implementierung, Test und Wartung.^[4]

2.1 Aufgaben des Requirements Engineering

Die vier Haupttätigkeiten des RE (Abbildung 1) sind das Erheben, Dokumentieren, Prüfen und Verwalten.^[5] Der Part des Prüfens bezieht sich jedoch hierbei nur auf den Teil der inhaltlichen Überprüfung. Dies kann zum Beispiel über Reviews wie in Kapitel 4 beschrieben geschehen. Der Abnahmetest bzw. Systemtest (gezieltes abtesten des Gesamtsystems) wird hierbei meist von den eigenen Testabteilungen übernommen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Tätigkeiten und Methoden im Rahmen des RE

Quelle: Rupp 2007a, S. 14

2.2 Qualitätskriterien für jede einzelne Anforderung

„Woran kann erkannt werden, dass die Anforderungen, die beschrieben werden, wirklich gut sind? “^[6] Alles in allem gibt es elf markante Qualitätskriterien die möglichst alle von jeder einzelnen Anforderung erfüllt werden sollten. Für einen Requirements Engineer ist es besonders schwer, den Spagat zwischen den unterschiedlichsten Stakeholdern (projektbeteiligte Personen) zu schaffen. Entwickler zum Beispiel können in einem Review kaum bis gar nicht die Richtigkeit gesetzlicher Vorgaben kontrollieren. Genauso wenig haben wie Produktmanager die Möglichkeit den Inhalt auf technischer Eben zu beurteilen. Der Requirements Engineer sollte die Fähigkeit besitzen, alle Vorgaben in möglichst einfacher aber dennoch in deutlicher Sprache zu formulieren. Im Folgenden werden die elf Qualitätskriterien kurz erläutert.

- Vollständigkeit:

Jede Anforderung muss die zu liefernde und geforderte Funktionalität vollkommen beschreiben. Anforderungen, die dies nicht tun, sollten unbedingt als solche gekennzeichnet werden. Dies kann beispielsweise durch die Verwendungen des Ausdruckes tbd („to be determinded“ oder „to be done“) erfolgen. Es sollten dann auch möglich sein, die Anforderungen entsprechend nach diesen verwendeten Markern zu suchen.^[7]

- Korrektheit:

Jede Anforderung ist nur dann korrekt, wenn es zu 100% die Vorstellungen des Stakeholders wiedergibt. Um dies zu gewährleisten, muss der Stakeholder das Requirement lesen und verstehen können.^[8]

- Klassifizierbarkeit bezüglich juristischen Verbindlichkeiten:

Es sollte für jedes Requirement festgelegt sein, welche rechtliche Relevanz es hat. Es wird dem Vertragspartner klar gemacht, welche Bedeutung dieses Requirement für sie hat.^[9] Dieser Punkt entfällt jedoch, wenn es sich um ein firmeninternes Softwareprojekt handelt.

- Konsistenz der Anforderung:

Requirements müssen gegenüber allen anderen Requirements widerspruchsfrei sein, egal auf welchen Abstraktionslevel gearbeitet wird. Weiters ist es nötig, dass jedes Requirement so formuliert wird, dass es in sich schon widerspruchsfrei ist.^[10]

- Prüfbarkeit:

Requirements müssen nach ihrer Umsetzung unabhängig von jeder Methode nachweisbar/testbar sein.^[11]

- Eindeutigkeit:

Jeder Leser eines Requirements sollte nur zu einer einzigen Interpretation des geschriebenen/dargestellten Sachverhalts kommen. Es ist daher nötig Requirements einfach, kurz und präzise zu beschreiben. Sollten unbekannte Ausdrücke oder Spezialwörter verwendet werden müssen, so sollten diese explizit erläutert werden.^[12]

- Gültigkeit – Aktualität:

Es muss mit den Requirements die Realität des Systems beschrieben werden. Ändert sich auch nur eine Variable im System, ist dies entsprechend zu dokumentieren und die Requirements müssen dementsprechend angepasst werden.^[13]

- Umsetzbarkeit:

Jedes Requirement muss innerhalb der Grenzen des Systems liegen. Dies setzt voraus, dass der Verfasser der Requirements das System an dem er arbeitet sehr gut kennt bzw. ein Mitarbeiter aus der Entwicklung an der Bewertung oder schon vorab an der Erstellung des Requirements beteiligt ist. Weiters sollten die Kosten für die Umsetzung mit einbezogen werden. Stakeholder können von einzelnen Requirements absehen, wenn sich durch diese Anforderungen zu hohe Projektosten ergeben würden.^[14]

- Notwendigkeit:

Es muss die Leistung bzw. die Eigenschaft beschrieben werden, die der Kunde tatsächlich benötigt oder fordert. Zudem muss darauf geachtet werden, das die Anforderungen erfüllt sind, die ein externes System oder einen speziellen Standard vorschreibt. Jedes Requirement sollte bis an die Anfänge des Projekts zurückverfolgbar sein, um kontrollieren zu können, ob dieses Requirement wirklich nötig ist, um das Systemziel zu erreichen.^[15]

- Verfolgbarkeit:

Bei einem verfolgbaren Requirement ist es möglich dieses rückwärts bis zu seinem „Original“ und vorwärts bis zu den Designelementen und Source Code zu verfolgen, sowie bis hin in die Testfälle mit denen es verifiziert wurde. Sichergestellt wird ein solches Verhalten mit einer eindeutigen Requirementnummer, die sich für das eine spezielle Requirement nie ändert. Über diesen Identifikator kann man alle Ebenen des Requirements verfolgen.^[16]

- Bewertbarkeit:

Wenn das zu entwickelnde System eine gewisse Größe übersteigt wird es nötig die Requirements nach ihrer Wichtigkeit zu bewerten. Es können oft nicht alle Spezifikationen in einer Softwarevariante erfüllt werden. Diese Gewichtung der Requirements ist von den Stakeholdern durchzuführen.^[17]

2.3 Folge von unzureichendem Requirements Engineering

Was passiert mit Projekten, bei denen RE vernachlässigt wird? Wie in Abbildung 2 zu sehen reduziert es den Projekterfolg. Unzureichendes Requirements Engineering führt dazu dass 15% aller Softwareprojekte abgebrochen werden bzw. 51% zu spät oder über Budget fertiggestellt werden. In folgendem Diagramm wird nochmals grafisch dargestellt, wie wichtig es ist gutes RE zu betreiben, da sonst ein wenig mehr als ein Drittel aller Projekte wirklich erfolgreich ist.^[18]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Unzureichendes RE

Quelle: in Anlehnung an; Ebert 2005, S.24

Folgende Liste veranschaulicht am deutlichsten die Wichtigkeit von konsequent betriebenem Requirements Engineering, wobei die anforderungsbezogenen Gründe hervorgehen sind.

Gründe für abgebrochene Projekte:^[19]

Abbildung in dieser Leseprobe nicht enthalten

2.4 Risiken

Die fünf im Folgenden beschriebenen Risiken bilden nur einen groben Querschnitt der Gefahren und Folgen, wenn RE falsch oder nicht angewandt wird.

Risiko 1: Kritische Anforderungen werden übersehen. Eine ungeschriebene Regel besagt, dass man dem Kunden das liefern muss was er will und nicht was er braucht. Letztendlich zählt nur das, was vertraglich gefordert wurde und nicht was der Kunde vielleicht gerne hätte. Es ist daher unerlässlich schon im Vorfeld des Projektes sich mit dem Kunden abzustimmen, welchen Funktionsumfang die Software beinhalten muss.^[20]

Risiko 2: Nur funktionale Anforderungen werden berücksichtigt. Neben diesen gibt es auch nicht-funktionale (siehe 4.3) Produkt- und Prozessanforderungen. Nur wenn alle diese Typen hinterfragt werden, bekommt man eine vollständige Requirementsspezifikation des zu liefernden Produktes. Besonders wichtig ist dieser Aspekt zu einem späteren Zeitpunkt (Testspezifikation), da die Testfälle all diese Kategorien abdecken müssen.^[21]

Risiko 3: Kunden sind unzureichend präsent. Nur der Kunde kann wirklich sagen was er benötigt, daher ist es von Nöten, dass er von Anfang an in dem Entwicklungsprozess eingebunden ist. Vorabtestversionen ermöglichen noch eine schnellere Nachkorrektur der Endversion.^[22] Dieses Risiko kann dazu führen, dass das gesamte Projekt zum Erliegen kommt.^[23]

Risiko 4: Anforderungen werden nicht geprüft. Aufgrund von Zeit und Ressourcenmangel wird oft auf das Prüfen von Requirements verzichtet. Dies führt dazu, dass oft der Erstentwurf in die Entwicklung geht. Es ist beinahe ein Muss Inspektionen der Requirements durchzuführen, da wie bereits unter 2.3 gezeigt viele Projekte durch mangelhaftes RE nicht korrekt beendet werden. Gerade Tester finden sehr viele Diskrepanzen, die sonst erst sehr viel später entdeckt werden würden.^[24]

Risiko 5: Inflation der Anforderungen. Bereits durch das spätere Entfernen einer zum Teil bereits implementierten Anforderung bzw. dem nachträglichen hinzufügen eines Elementes erhöht sich die Zusatzarbeit für das Projekt. Für Projektmanager ist es daher oft problematisch einen geeigneten Puffer zu schaffen, um solche Eventualitäten abzufangen. Dies erhöht das Risiko der Projekteinstellung.^[25]

3 Modelltechniken

Modelltechniken können am besten als spezielle Sprache charakterisiert werden. Mit ihr ist es möglich, einen genaueren Blick auf ein System zu werfen, welches softwaretechnisch entwickelt werden soll. Es gibt verschiedenste Techniken ein System zu beschreiben. Von einfacher formalen Sprache bis hin zu recht komplexen grafischen Darstellungen.^[26] In diesem Kapitel werden einige der häufigsten Modelltechniken kurz erklärt.

3.1 Datenflussmodelle – Use-Case-Diagramme

Aufgabe des Use-Case-Diagrammes ist es, eine grobe Ordnung in die zum Teil sehr detaillierten textlichen bzw. grafischen Anforderungen zu bringen. Das Use-Case-Diagramm soll uns einen Überblick verschaffen, was die zu entwickelnde Software eigentlich im Wesentlichen können muss. Es werden wichtige Funktionen der Software zueinander in Beziehung gesetzt. Die technische Implementierung spielt bei dieser Darstellungsform keine Rolle. Es geht um das „Was“, nicht um das „Wie“.^[27] Das Use-Case-Diagramm ist ein recht einfacher Diagrammtyp, der sehr anschaulich ist. Er kann auch zu Verwirrungen führen, wenn zu viele Funktionen, die in Beziehung stehen, grafisch dargestellt werden.

[...]

---

^[1] vgl. o.V. Siemens AG, Stand 2007-04-21

^[2] Systems Engineering ist ein Ansatz in der Systementwicklung. Hierbei stehen die Kundenwünsche, bzw. die gewünschten Funktionalitäten, sowie, Design und Systemüberprüfung im Mittelpunkt

^[3] vgl. Ebert 2005, S. 14

^[4] vgl. Ebert 2005, S.16

^[5] vgl. Rupp 2007a, S.14f

^[6] vgl. Rupp 2007a, S. 27ff

^[7] vgl. Wiegers 2003, S. 22

^[8] vgl. Wiegers 2003, S. 22

^[9] vgl. Rupp 2007a, S.28

^[10] AAO, S.28

^[11] AAO, S.28

^[12] vgl. Wiegers 2003, S. 23

^[13] vgl. Rupp 2007a, S. 29

^[14] vgl. Rupp 2007a, S. 29

^[15] vgl. Wiegers 2003, S. 23

^[16] vgl. Wiegers 2003, S. 24f

^[17] vgl. Rupp 2007a, S.30

^[18] vgl. Ebert 2005, S.23ff

^[19] vgl. Ebert 2005, S.24f

^[20] vgl. Ebert 2005, S.27

^[21] vgl. Ebert 2005, S.27

^[22] vgl. Ebert 2005, S.27f

^[23] vgl. DeMarco, Lister 2003, S. 116ff

^[24] vgl. Ebert 2005, S.27f

^[25] vgl. DeMarco, Lister 2003, S. 112ff

^[26] vgl. Broy, Rumpe 1998, S. 51

^[27] vgl. Buhr, Casselman1996, S.34