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.

II

Inhaltsverzeichnis

Zusammenfassung.   II

Abstract.   II

Inhaltsverzeichnis   III

Abbildungsverzeichnis   IV

Tabellenverzeichnis   V

Abk  ürzungsverzeichnis  V

1  Einleitung.  1

1.1  Ausgangssituation.  1

1.2  Aufgabenstellung  1

1.3  Ziel der Arbeit.  1

2  Der Begriff des Requirements Engineering  2

2.1  Aufgaben des Requirements Engineering.  2

2.2  Qualitätskriterien für jede einzelne Anforderung  3

2.3  Folge von unzureichendem Requirements Engineering.  6

2.4  Risiken  7

3  Modelltechniken  8

3.1  Datenflussmodelle - Use-Case-Diagramme  8

3.2  Zustandübergangsmodell.  10

3.3  Entscheidungstabellen  11

3.4  Entity Relationship Attribute Modell.  13

3.5  Strukturierte Sprache  13

3.6  Aktivitätsdiagramme.  14

3.7  Klassendiagramme  15

4  Prüfen von Anforderungen.  16

4.1  Prüftechniken - das Review.  17

4.2  Die Reviewbeteiligten.  18

4.3  Nicht-Funktionale Anforderungen  19

4.4  Testorientiertes Requirements Management - das V-Modell  20

4.5  Checklisten für die Testbarkeit.  22

5  Schlussfolgerung.  23

Literaturverzeichnis   24

III

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  

IV

Tabellenverzeichnis

Tabelle 1: Textuelle Use-Case Beschreibung ...........................................................10 Tabelle 2: Beispiel Entscheidungstabelle ..................................................................12 Tabelle 3: Beispiel Strukturierte Sprache ..................................................................14 Tabelle 4: Prüfende Personen...................................................................................18

Abkürzungsverzeichnis

UML = Unified Modeling Language RE = Requirements Engineering tbd = „to be determinded“ oder „to be done“

V

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.

1

2 Der Begriff des Requirements Engineering

Unter „Requirements Management/Engineering“ (RE) wird allgemein die geordnete, methodische Behandlung von Anforderungen in einem Projekt verstanden. ¹ Requirements Engineering ist innerhalb des Software Engineering bzw. des Systems Engineering ² die Disziplin, die sich mit den gewünschten Eigenschaften bzw. Einschränkungen von Softwaresystemen befasst. ³ 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. ⁵ 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.

¹ vgl. o.V. Siemens AG, Stand 2007-04-21

² Systems Engineering ist ein Ansatz in der Systementwicklung. Hierbei stehen die Kundenwün-

sche, bzw. die gewünschten Funktionalitäten, sowie, Design und Systemüberprüfung im Mittel-

punkt

³ vgl. Ebert 2005, S. 14

⁴ vgl. Ebert 2005, S.16

⁵ vgl. Rupp 2007a, S.14f

2

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?“ ⁶ 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.

⁶ vgl. Rupp 2007a, S. 27ff

3