PROJEKTMANAGEMENT

LV Nr. 706.028 (2VU) LV Nr. 706.038 (1VU)

Lehrbehelf Kapitel 5

SOFTWAREANFORDERUNGEN
Von der Anforderungsanalyse zum Pflichtenheft

Autoren: Petra Korica Mensur Celikovic Andreas Ortner

Lehrveranstaltungsleiter: Dipl.-Ing. Dr.techn. Christian Gtl

SOFTWAREANFORDERUNGEN

Inhaltsverzeichnis
1. 2. EINLEITUNG ....................................................................................................................3 ARTEN VON ANFORDERUNGEN .........................................................................................3 2.1. Benutzeranforderungen ..........................................................................................4 2.1.1. Beispiel einer Benutzeranforderung .................................................................4 2.2. Systemanforderungen ............................................................................................5 2.1.2. Notationen der Systemanforderungen .............................................................5 2.3. Beispiel von Benutzer- und dazugehriger Systemanforderungen .........................7 3. EINTEILUNG DER ANFORDERUNGEN..................................................................................8 3.1. Funktionale Anforderungen ....................................................................................8 3.1.1. Beispiele fr Funktionale Anforderungen .........................................................8 3.2. Nichtfunktionale Anforderungen..............................................................................9 3.2.1. Beispiele fr Nichtfunktionale Anforderungen ..................................................9 3.3. Problembereichsanforderungen............................................................................10 3.3.1. Beispiele fr Problembereichsanforderungen ................................................10 4. DAS PFLICHTENHEFT ....................................................................................................10 4.1. Aufbau eines Pflichtenhefts ..................................................................................11 4.1.1. Abschnitt 1: Allgemeines ................................................................................11 4.1.2. Abschnitt 2: Anforderungsbeschreibung ........................................................11 4.1.3. Abschnitt 3: Anhang .......................................................................................12 5. ANFORDERUNGSANALYSE .............................................................................................12 5.1. Durchfhrbarkeitsstudien ......................................................................................13 5.2. Anforderungsbestimmung und -analyse ...............................................................13 5.2.1. Ablauf- und Analysemodell ............................................................................14 5.2.2. Anforderungsbestimmung ..............................................................................14 5.3. Anforderungsvalidierung.......................................................................................16 6. SYSTEMMODELLE..........................................................................................................17 6.1. 6.2. 6.3. 6.4. 6.5. 7. Architekturmodell ..................................................................................................17 Datenflussmodell ..................................................................................................18 Entity-Relationship-Modell ....................................................................................18 Klassifikationsmodell ............................................................................................19 Stimulus/Response-Modell ...................................................................................19

LITERATURVERZEICHNIS ................................................................................................20

Seite 2 von 20

SOFTWAREANFORDERUNGEN

1. EINLEITUNG
In diesem Kapitel soll erlutert werden, wie Anforderungen an ein Softwaresystem zum Ausdruck gebracht werden knnen. Dabei werden unterschiedliche Arten von Softwareanforderungen definiert und Techniken zur Beschreibung vorgestellt. Der Prozess des Herausfindens, Analysierens, Dokumentierens und berprfens der Anforderungen wird durch die Beschreibung der sogenannten Anforderungsanalyse erlutert. Abschlieend wird ein mglicher Aufbau eines Pflichtenheftes nach dem IEEE-Standard dargestellt. Die Basis fr die Inhalte dieses Kapitels bilden die Quellen [Sommerville 2005] und [Sommerville 2001].

2. ARTEN VON ANFORDERUNGEN

Die Bestimmung der Softwareanforderungen sind ein zentraler Punkt des SoftwareengineeringProzesses. In der Praxis herrscht ein Spannungsfeld zwischen der notwendigen Festlegung der Anforderungen und der zur Verfgung stehenden Ressourcen. Das Identifizieren und Beschreiben der Anforderungen ist ein komplexer Prozess, da verschiedenste Stakeholder (z.B. Manager, Entwickler, Kunde) bei der Anforderungsbestimmung involviert sind. Die Ergebnisse der Anforderungsanalyse flieen in das Lasten- bzw. Pflichtenheft ein, das fr einen groen Leserkreis verstndlich sein soll. Die Anforderungen knnen in Benutzer- und Systemanforderungen getrennt werden. Durch diese Trennung in zwei Genauigkeitsgrade kann eine noch detailliertere Spezifikation des Softwareentwurfs fr die jeweiligen Zielgruppen erstellt werden (Abbildung 1).

Abbildung 1: Zielgruppen vs. Spezifikationsarten (nach [Sommerville 2001])

In der Praxis werden oft beide Anforderungsgruppen vermischt bzw. wird keine Trennung vorgenommen.
Seite 3 von 20

SOFTWAREANFORDERUNGEN

2.1.

Benutzeranforderungen

Benutzeranforderungen sollen funktionale und nichtfunktionale Anforderungen auf einer hohen Abstraktionsebene beschreiben. Benutzeranforderungen sind Aussagen in natrlicher Sprache, Diagramme und Tabellen zur Beschreibung der Dienste, die das System leisten sollte, und der Randbedingungen, unter denen es betrieben wird. Die Benutzeranforderungen sollten sowohl fr Manager beim Kunden als auch fr Manager beim Softwarehersteller erstellt werden, die kein genaues technisches Wissen ber das System haben. Benutzeranforderungen sind fr Menschen geschrieben, die an der Verwendung und Beschaffung des Systems beteiligt sind. Die Benutzeranforderungen fr ein System sollten die funktionalen und nichtfunktionalen Anforderungen so beschreiben, dass sie fr jene Systembenutzer verstndlich sind, die kein detailliertes technisches Wissen haben. Sie sollten nur das externe Verhalten des Systems festlegen und Charakteristika des Systementwurfs so weit wie mglich vermeiden. Daher sollten Benutzeranforderungen nicht mittels eines Implementierungsmodells, sondern unter Benutzung natrlicher Sprache, gezeichneter Formulare und einfacher intuitiver Diagramme verfasst werden. Zu viele Informationen schrnken die Freiheit des Systementwicklers ein, um innovative Lsungen zu finden. Anmerkungen und Hinweise zur Definition von Benutzeranforderungen: Die Nutzung eines Standardformates ist sinnvoll, da Versumnissen vorgebeugt und die berprfbarkeit erleichtert werden kann. Wichtige Aussagen sollten durch entsprechende Formatierungen hervorgehoben werden. Begrndungen sind vor allem fr Systementwickler und Systemwarter hilfreich, da somit eine bessere Nachvollziehbarkeit von Entscheidungen gewhrleistet wird. Einheitliche Ausdrucksweisen (z.B. sollen fr verbindliche Anforderungen, sollten fr wnschenswerte Anforderungen) wirken Missverstndnissen entgegen. Computerjargon sollte man im allgemeinen vermeiden, jedoch kann auf Ausdrcke des Fachbereiches in manchen Fllen nicht verzichtet werden. detaillierteren

Es ist eine gute Methode, im Pflichtenheft Benutzeranforderungen von Systemanforderungen zu trennen. 2.1.1. Beispiel einer Benutzeranforderung

3.5.1.

Hinzufgen von Knoten zu einem Entwurf

3.5.1.1. Der Editor soll dem Benutzer die Mglichkeit bieten, Knoten eines bestimmten Typs zu ihrem Entwurf hinzuzufgen 3.5.1.2. Beim Hinzufgen von Knoten sollen folgende Vorgnge stattfinden: - Der Benutzer soll den hinzuzufgenden Knotentyp auswhlen. - Der Benutzer soll den Cursor in die Nhe der Knotenposition im Diagramm bewegen, um die ungefhre Position festzulegen. - Der Benutzer soll dann das Knotensymbol auf die endgltige Position ziehen. Begrndung: Der Benutzer kann am besten entscheiden, wo der Knoten im Diagramm zu platzieren ist. Diese Methode gibt dem Benutzer die direkte Kontrolle. Spezifikation: Mytool/DE/SA/Abschnitt 3.5.1

Abbildung 2: Beispiel einer Benutzeranforderung (nach [Sommerville 2001]) Seite 4 von 20

SOFTWAREANFORDERUNGEN

2.2.

Systemanforderungen

Systemanforderungen sind genauere Beschreibungen der Benutzeranforderungen. Sie dienen den Softwareentwicklern als Basis fr den Systementwurf und knnen auch als Basis fr einen Vertrag ber die Systemimplementierung dienen. Systemanforderungen legen die Dienste und Beschrnkungen detailliert fest. Die Spezifikation der Systemanforderungen sollte an das hhere technische Personal und an die Projektmanager gerichtet sein. Diese Spezifikation wird wiederum sowohl vom Personal des Kunden als auch von dem des Softwareherstellers verwendet. Endbenutzer des Systems knnen beide Dokumente lesen. Systemanforderungen sind zur przisen Beschreibung der Funktionen bestimmt, die das System bereitstellen soll. Um Mehrdeutigkeiten zu vermeiden, knnen sie in einer Art strukturierten Sprache verfasst werden. Dies knnte ein strukturierte Form natrlicher Sprache (Pseudocode), eine auf einer hheren Programmiersprache basierte oder eine spezielle Sprache fr die Anforderungsspezifikation sein. Systemanforderungen knnen als Basis fr einen Vertrag ber die Implementierung des Systems dienen und sollten daher eine komplette und widerspruchfreie Spezifikation des gesamten Systems darstellen. Sie werden von Softwareentwicklern als Startpunkt des Systementwurfs verwendet. Die Spezifikation der Systemanforderungen kann verschiedene Modelle des Systems enthalten, wie zum Beispiel ein Klassen- oder ein Datenflussmodell. Prinzipiell sollten die Systemanforderungen aussagen, was das System tun soll, und nicht, wie dieses zu implementieren ist. Eine Spezifikation des Softwareentwurfs ist eine abstrakte Beschreibung des Softwareentwurfs, die als Grundlage fr einen exakteren Entwurf und dessen Umsetzung dient. Diese Spezifikation fgt weitere Details zur Spezifikation dieser Systemsanforderungen hinzu. Die Spezifikation des Softwareentwurfs ist ein programmiererorientiertes Dokument. Es sollte fr die Softwareentwickler geschrieben werden, die das System entwickeln werden. 2.1.2. Notationen der Systemanforderungen Systemanforderungen knnen auf folgende Arten verfasst werden: a) Natrliche Sprache Hierbei kann es zu Missverstndnissen wegen der Mehrdeutigkeit der natrlichen Sprache kommen. Es gibt keine einheitliche Darstellungsart und diese Notation ist schwierig zu modularisieren (Erschwertes Finden von Abhngigkeiten). b) Strukturierte natrliche Sprache Bei dieser Notation wird eine Einheitlichkeit in der Spezifikation durch Standardformulare erzwungen (Abbildung 3). Wichtige Informationen werden nicht bersehen und die Prfbarkeit der Anforderungen wird erleichtert. Die Ausdruckskraft und die Verstndlichkeit der natrlichen Sprache bleibt jedoch auf jeden Fall erhalten.

ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Funktion Knoten hinzufgen Beschreibung Fgt einen Knoten zu einem vorhandenen Entwurf hinzu. Der Benutzer whlt den Typ des Knotens und seine Position aus. Nachdem der Knoten zum Entwurf hinzugefgt wurde, wird er zur aktuellen Auswahl. Der Benutzer whlt die Knotenposition, indem er den Cursor an die Stelle bewegt, an welcher der Knoten hinzugefgt werden soll. Eingaben Knotentyp, Knotenposition, Entwurfskennung Herkunft Knotentyp und position werden durch den Benutzer eingegeben, die Entwurfskennung durch die Datenbank. Ausgabe Entwurfskennung Seite 5 von 20

SOFTWAREANFORDERUNGEN Ziel Die Entwurfsdatenbank. Nach Abschluss der Operation wird der Entwurf in die Datenbank eingetragen. Bentigt Einen Entwurfsgraphen, gekennzeichnet durch die Entwurfskennung seines Wurzelknotens. Vorbedingung Der Entwurf ist geffnet und wird auf dem Bildschirm des Benutzers angezeigt. Nachbedingung Der Entwurf bleibt abgesehen vom Hinzufgen eines Knotens des ausgewhlten Typs an der gewhlten Position unverndert. Seiteneffekte Keine Definition: ECLIPSE/Workstaton/Tools/DE/RD/3.5.1 Abbildung 3: Beispiel eines Standardformulars fr die Spezifikation von Anforderungen in natrlicher strukturierter Sprache (nach [Sommerville 2001])

c) Sprachen zur Entwurfsbeschreibung (PDL) Sprachen der Entwurfsbeschreibung bzw. Program Description Languages (PDLs) sind an Programmiersprachen angelehnte Sprachen mit zustzlichen abstrakten Konstrukten. Es kann somit Mehrdeutigkeiten der natrlichen Sprache entgegengewirkt werden. Ergnzend zu formularbasierten Spezifikationen knnen komplexere Ablufe von Vorgngen beschrieben werden. Eine weitere Anwendung dieser Notation ist bei der Festlegung von Hard- und Softwareschnittstellen empfehlenswert (Schnittstellenobjekte und typen). Eine PDL-basierte Notation ist jedoch nur fr Menschen mit programmiersprachlichen Kenntnissen verstndlich. Weiters kann diese Notation zu ausdrucksschwach sein, um alle Systemfunktionen zu beschreiben. Einzelne Projektbeteiligten knnten diese Beschreibung flschlicherweise auch als Entwurfsspezifikation interpretieren. In der Praxis ist daher eine Kombination einer PDL (Abbildung 4) mit der Beschreibung in strukturierter natrlicher Sprache empfehlenswert. class ATM { // Deklarationen public static void main (String args[]) throws InvalidCard { try { thisCard.read(); // Kann die Exception Invalid Card auslsen pin = KeyPad.readPIn(); attempts = 1; while (!thisCard.pin.equals (pin) & attempts < 4) { pin = KeyPad.readPin(); attempts = attempts + 1; } if (!thisCard.pin.equals (pin)) throw new InvalidCard (Bad PIN); thisBalance = thisCard.getBalance(); do { Screen.prompt(Please select a service ); service = Screen.touchKey(); switch (service) { case Services.withdrawalWithReceipt: receiptRequired = true; case Services.withdrawalNoReceipt: amount = KeyPad.readAmount(); if (amount > thisBalance) { Screen.printmsg(Balance insufficient); Break; } Dispenser.deliver(amount);
Seite 6 von 20

SOFTWAREANFORDERUNGEN

newbalance = thisBalance amount; if (receiptRequired) Receipt.print(amount, newBalance); break; // Andere Funktionsbeschreibungen default break; } } while (service != Services.quit); thisCard.retournToUser(Please take your card); } catch (InvalidCard e) { Screen.printmsg(Invalid card or PIN); } // Andere Exception-Handler } // main() } // ATM
Abbildung 4: Beispiel einer PDL-Beschreibung (ATM) (aus [Sommerville 2001])

d) Grafische Notationen Hierbei werden grafische Sprachen mit Textvermerken ergnzt (z.B. Use Cases (siehe Kapitel 5.2.2.) oder SADT). e) Mathematische Notationen Bei diesen Notationen werden mathematische Konzepte wie endliche Zustandsmaschinen oder Mengen angewendet.

2.3.

Beispiel von Benutzer- und dazugehriger Systemanforderungen

Der Zusammenhang zwischen einer Benutzer- und der dazugehrigen Systemanforderungen mu klar ersichtlich sein und sollte durch eine entsprechende Nummerierung gekennzeichnet werden. Abbildung 5 zeigt, wie eine Benutzeranforderung auf mehrere Systemanforderungen erweitert werden kann.
Definition einer Benutzeranforderung (im Lastenheft) 1. Die Software muss ber Mittel zur Darstellung externer, von anderen Werkzeugen erzeugter Dateien verfgen und auf sie zugreifen knnen.

Definition einer Systemanforderung (im Pflichtenheft) 1.1 1.2 1.3 1.4 1.5 Der Benutzer sollte ber Mglichkeiten zur Definition externer Datentypen verfgen. Jeder externe Dateityp kann eine damit verknpfte Anwendung besitzen, mit der die Datei bearbeitet wird. Jeder externe Dateityp kann als bestimmtes Symbol auf dem Bildschirm des Anwenders dargestellt werden. Es sollten Mglichkeiten zur Definition des Symbols fr externe Dateitypen durch den Benutzer dargestellt werden. Wenn ein Benutzer ein Symbol auswhlt, das eine externe Datei reprsentiert, so soll die durch dieses Symbol dargestellte Datei mit der Anwendung geffnet werden, die mit dem entsprechenden externen Dateityp verknpft ist.

Abbildung 5: Beispiel von Benutzer- und Systemanforderungen (nach [Sommerville 2001]) Seite 7 von 20

SOFTWAREANFORDERUNGEN

3. EINTEILUNG DER ANFORDERUNGEN

Die Anforderungen an Softwaresysteme werden oft in funktionale und nichtfunktionale Anforderungen sowie in Anforderungen des Problembereichs unterteilt (Abbildung 6).

Abbildung 6: Einteilung der Anforderungen an ein System

3.1.

Funktionale Anforderungen

Funktionale Anforderungen sind Aussagen zu den Diensten, die das System leisten sollte, zur Reaktion des Systems auf bestimmte Eingaben und zum Verhalten des Systems in bestimmten Situationen. In manchen Fllen knnen die funktionalen Anforderungen auch explizit ausdrcken, was das System nicht tun soll. Die funktionalen Anforderungen an ein System beschreiben die Funktionalitt oder die Dienste, die von einem System erwartet werden. Diese Anforderungen hngen vom Wesen der Software, den erwarteten Benutzern und der Art des entwickelten Systems ab. Als Benutzeranforderungen ausgedrckt werden sie gewhnlich auf eine ziemlich allgemeine Weise beschrieben, funktionale Systemanforderungen jedoch beschreiben die Systemfunktion im Detail, seine Eingaben und Ausgaben sowie Ausnahmen. Alle vom Benutzer bentigten Funktionen mssen festgelegt werden und die Anforderungen drfen keine widersprchlichen Festlegungen enthalten. In der Praxis knnen grere und komplexe Systeme meist nie diese Vollstndigkeit und Konsistenz aufweisen. Viele Probleme entstehen aus der ungenauen Festlegung der Anforderungen, vor allem wenn eine mehrdeutige Interpretation mglich ist. 3.1.1. Beispiele fr Funktionale Anforderungen

1.

Der Benutzer soll die gesamte Menge der Dokumente oder eine ausgewhlte Teilmenge durchsuchen knnen. Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentkorpus lesen kann. Jeder Bestellung soll ein eindeutiger Bezeichner (Order ID) zugeordnet werden, und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren knnen.

2.

3.

Abbildung 7: Beispiele von Funktionalen Anforderungen an ein Bibliothekssystem

Seite 8 von 20

SOFTWAREANFORDERUNGEN

3.2.

Nichtfunktionale Anforderungen

Nichtfunktionale Anforderungen sind Anforderungen, welche die durch das System zu leistenden speziellen Funktionen nicht direkt betreffen. Sie knnen sich auf wichtige Softwareeigenschaften wie Zuverlssigkeit, Reaktionszeit und Speicherbedarf beziehen. Alternativ knnen sie auch Beschrnkungen des Systems definieren, wie z.B. die Leistungsfhigkeit von E/A-Gerten und die durch die Systemschnittstelle benutzten Datendarstellungen. Nichtfunktionale Anforderungen knnen in Produktanforderungen, Unternehmensanforderungen und Externe Anforderungen eingeteilt werden (Abbildung 8).

Abbildung 8: Unterteilung fr nichtfunktionale Anforderungen (nach [Sommerville 2001])

Nichtfunktionale Anforderungen beziehen sich im allgemeinen auf das ganze System und wirken einschrnkend auf das System und die Systemfunktionen. Das Nichteinhalten von Nichtfunktionalen Anforderungen wirkt sich strker aus als das Nichteinhalten einzelner Funktionaler Anforderungen. 3.2.1. Beispiele fr Nichtfunktionale Anforderungen

1.

Produktanforderungen (beschreiben das Verhalten des Produktes) z.B. Performance, Zuverlssigkeit, Portierbarkeit und Benutzbarkeit Unternehmensanforderungen (bestimmt durch Unternehmenspolitik und Arbeitsweisen von Auftragenehmer und Auftraggeber) z.B. Lieferanforderungen, Umsetzung, Vorgehensweisen Externe Anforderungen (alles auerhalb des Systems und seines Entwicklungsprozesses) z.B. Kompatibilitt zu anderen Systemen, Rechtliche Anforderungen (Einhaltung von Gesetzen), Ethnische Anforderungen

2.

3.

Abbildung 9: Beispiele fr Nichtfunktionale Anforderungen

Seite 9 von 20

SOFTWAREANFORDERUNGEN

3.3.

Problembereichsanforderungen

Problembereichsanforderungen ergeben sich eher aus dem Anwendungsbereich des Systems als aus speziellen Bedrfnissen von Systembenutzern. Sie knnen selbst neue funktionale Anforderungen sein, vorhandene funktionale Anforderungen einschrnken oder festlegen, wie bestimmte Berechnungen durchgefhrt werden mssen. Problembereichsanforderungen sind wichtig, da sie allgemeine Arbeitsweisen des Bereiches, Standards, Vorschriften und Regulierungen widerspiegeln. In der Praxis kann das System bei Nichtbercksichtigung von Problembereichsanforderungen unbrauchbar sein bzw. nicht zufriedenstellend arbeiten. Problembereichsanforderungen knnen wiederum in funktionale und nichtfunktionale Anforderungen eingeteilt werden. 3.3.1. Beispiele fr Problembereichsanforderungen

Bibliothekssystem - Funktional: Vormerkfunktion (zur Verfgung gestellt, wenn Buch verborgt ist) - Nichtfunktional: Untersttzung von Klassifikationssystem (z.B. Dewey Decimal Classification) Buchhaltungsprogramm - Funktional: Splitbuchung (Aufteilung des Rechnungsbetrages auf verschiedene Konten) - Nichtfunktional: Buchungsstze drfen nachtrglich nicht mehr editierbar sein; Gelschte Buchungen mssen sichtbar bleiben

Abbildung 10: Beispiele fr Problembereichsanforderungen

4. DAS PFLICHTENHEFT
Das Pflichtenheft ist die offizielle Aufstellung darber, was von den Softwareentwicklern implementiert werden soll. Es sollte sowohl die Benutzeranforderungen an das System als auch eine detaillierte Spezifikation der Systemanforderungen enthalten. In manchen Fllen werden die Benutzer- und Systemanforderungen zu einer einzigen Beschreibung zusammengefasst. In anderen Fllen werden die Benutzeranforderungen in einer Einleitung der Spezifikation der Systemanforderungen definiert. Gibt es eine Vielzahl von Anforderungen, knnen die genauen Systemanforderungen in verschiedenen Dokumenten dargelegt werden. Jedenfalls sollte die Verknpfung zwischen den Benutzeranforderungen und den zugehrigen Systemanforderungen leicht mglich sein. Ein Softwareanforderungsdokument sollte folgende Bedingungen erfllen: Es sollte nur das uere Systemverhalten festlegen. Es sollte Beschrnkungen bezglich der Implementierung vorgeben. Es sollte leicht zu verndern sein. Es sollte als Referenz fr Systemwarter dienen. Es sollte Vorberlegungen zum Lebenszyklus des Systems enthalten. Es sollte akzeptable Reaktionen auf potenzielle Systemfehler beschreiben.

Das Pflichtenheft wird von unterschiedlichen Personenkreisen eingesetzt. Der Kunde legt die Anforderungen fest, prft das Dokument auf den gewnschten Umfang und kann nderungen veranlassen. Manager sind fr die Angebotserstellung und die Planung des Systementwicklungsprozesses zustndig. Entwickler sind fr die Softwareerstellung bzw. Systementwicklung verantwortlich. Systemtester verifizieren und validieren das System.
Seite 10 von 20

SOFTWAREANFORDERUNGEN

Systemwarter eignen sich mit Hilfe des Pflichtenheftes ein entsprechendes Verstndnis fr das System an.

Abbildung 11: Personenkreise eines Pflichtenheftes

4.1.

Aufbau eines Pflichtenhefts

Nachfolgend wird ein mglicher Aufbau fr ein auf dem IEEE-Standard basierendes Pflichtenheft beschrieben. 4.1.1. Abschnitt 1: Allgemeines Vorwort - Dieses Kapitel sollte die erwartete Leserschaft des Dokuments festlegen und eine Versionsgeschichte beschreiben, die eine Begrndung fr die Entwicklung einer neuen Version und eine Zusammenfassung ber die Vernderungen bei jeder Version beinhalten sollte. Einleitung - Dieses Kapitel sollte die Notwendigkeit des Systems beschreiben. Es sollte kurz seine Funktionen darlegen und erklren, wie es mit anderen Systemen zusammenarbeiten wird. Auerdem sollte erlutert werden, wie das System mit den gesamtwirtschaftlichen oder strategischen Zielen des Unternehmens bereinstimmt, welches die Software in Auftrag gibt. Begriffe und Abkrzungen - Dieser Teil sollte die im Dokument verwendeten technischen Fachbegriffe und Abkrzungen festlegen. Dabei sollte keine Erfahrung oder Fachwissen beim Leser vorausgesetzt werden. Verweise auf referenzierte Literatur - In diesem Abschnitt sollten die Quellen fr verwendete Literatur bzw. andere Ressourcen aufgelistet werden.

4.1.2. Abschnitt 2: Anforderungsbeschreibung Definition der Benutzeranforderungen - Die fr den Benutzer bereitgestellten Dienste und die nichtfunktionalen Anforderungen sollten in diesem Abschnitt beschrieben werden. Diese Beschreibung kann natrliche Sprache, Diagramme oder andere fr die Kunden verstndliche Notationen benutzen. Produkt- und Entwicklungsstandards, die befolgt werden mssen, sollten ebenfalls festgelegt werden.
Seite 11 von 20

SOFTWAREANFORDERUNGEN

Systemarchitektur - Dieses Kapitel sollte einen groben berblick ber die erwartete Systemarchitektur geben, der die Verteilung der Funktionen auf die Systemmodule zeigt. Wiederverwendete Komponenten sollten gekennzeichnet werden. Spezifikation der Systemanforderungen - Dieses Kapitel sollte die funktionalen und nichtfunktionalen Anforderungen genauer beschreiben. Gegebenfalls knnen auch weitere Einzelheiten zu den nichtfunktionalen Anforderungen hinzugefgt werden, wie zum Beispiel die Definition von Schnittstellen zu anderen Systemen. Systemmodelle - Dieses Kapitel sollte eines oder mehrere Systemmodelle festlegend die die Beziehungen zwischen den Systemkomponenten und dem System und seiner Umgebung aufzeigen. Dies knnen Klassen-, Datenfluss und semantische Datenmodelle sein. Systementwicklung - Dieser Teil sollte die grundlegenden Voraussetzungen, auf denen das System basiert, und erwartete Vernderungen aufgrund der Hardwareentwicklung, Vernderungen der Benutzeranforderungen usw. beschreiben.

4.1.3. Abschnitt 3: Anhang Anhnge - Diese sollten genauere spezifische Informationen beinhalten, die sich auf die entwickelte Anwendung beziehen. Beispiele von mglichen Anhngen sind Hardware- und Datenbankbeschreibungen. Hardwareanforderungen legen die minimale und die optimale Konfiguration des Systems fest. Datenbankanforderungen definieren die logische Verwaltung der vom System verwendeten Daten und die Beziehungen zwischen den Daten. Projektbeteiligte bzw. Stakeholder - Hier werden spezifische Anforderungen der Projektbeteiligten beschrieben. Widersprche und Konflikte mssen an dieser Stelle aufgelst werden. Die Vereinbarung von Kompromissen sollte ebenfalls festgehalten werden. Index - Das Dokument kann mehrere Indizes enthalten (neben einem normalen alphabetischen Index z.B. auch Indizes zu Diagrammen, Funktionen usw.).

Ein gutes Pflichtenheft ist leicht verstndlich und beschreibt nur das uere Systemverhalten. Vernderungen sollen leicht durchfhrbar und nachvollziehbar sein. Die Erstellung einer ausgereiften Spezifikation ist oft mit Aufwand und Kosten fr den Kunden verbunden. Jedoch kann ein gut erstelltes Pflichtenheft nachtrglich viel rger und Kosten vermeiden.

5. ANFORDERUNGSANALYSE
Die Anforderungsanalyse ist ein Vorgang, der alle notwendigen Aufgaben der Erstellung und Wartung eines Pflichtenhefts umfasst. Es gibt vier auf einer hheren Ebene stattfindende Aktivitten der Anforderungsanalyse: 1. Durchfhrbarkeitsstudie 2. Anforderungsbestimmung und -analyse 3. Anforderungsspezifikation 4. Anforderungsvalidierung Abbildung 12 stellt den Ablauf und die Phasen einer typischen Anforderungsanalyse dar.

Seite 12 von 20

SOFTWAREANFORDERUNGEN

Abbildung 12: Der Ablauf der Anforderungsanalyse (nach [Sommerville 2001])

5.1.

Durchfhrbarkeitsstudien

Bei allen neuen Systemen sollte der Prozess der Anforderungsanalyse mit einer Durchfhrbarkeitsstudie beginnen. Das Eingangsmaterial fr die Durchfhrbarkeitsstudie ist eine grobe Beschreibung des Systems und der Art und Weise, wie es innerhalb des Unternehmens verwendet werden soll. Das Resultat der Anforderungsanalyse sollte ein Bericht sein, der empfiehlt, ob mit der Anforderungsanalyse und dem Systementwicklungsprozess fortgefahren werden sollte. Eine Durchfhrbarkeitsstudie ist eine kurze, konzentrierte Studie, die darauf abzielt, eine Reihe von Fragen zu beantworten: Leistet das System einen Beitrag zur Verwirklichung der Gesamtziele des Unternehmens? Kann das System unter Benutzung der derzeitigen Technologie und innerhalb der Kosten- und Zeitbeschrnkungen realisiert werden? Kann das System mit anderen Systemen zusammenarbeiten, die bereits in Betrieb sind?

Nach der Einholung dieser Informationen wird der Bericht zur Durchfhrbarkeitsstudie angefertigt. Dieser sollte eine Empfehlung darber aussprechen, ob die Entwicklung des Systems fortgesetzt werden soll. Er kann Vernderungen am Anwendungsbereich, dem Budget und dem Zeitplan des Systems vorschlagen und weitere allgemeine Anforderungen an das System nahe legen.

5.2.

Anforderungsbestimmung und -analyse

Die Ergebnisse einer Durchfhrbarkeitsstudie sind der Startpunkt fr die Anforderungsbestimmung und analyse. Auftragnehmer und Kunden/Systembenutzer arbeiten eng zusammen, um den Anwendungsbereich, die vom System zu leistenden Dienste, erforderliche Funktionen und Einschrnkungen zu bestimmen. In der Praxis knnen folgende Probleme bei der Anforderungsbestimmung und analyse auftreten: Stakeholder knnen Erwartungen an System schwer ausdrcken, meist mit impliziten Wissen ihrer Ttigkeiten; dabei ist Fachbereichswissen notwendig Stakeholder haben zum Teil unrealistische Forderungen im Hinblick auf die Ressourcen
Seite 13 von 20

SOFTWAREANFORDERUNGEN

Verschiedene Stakeholder haben unterschiedliche Anforderungen (andere Ausdrucksweise vs. bereinstimmung und Konflikte) Interne und externe Unternehmensumwelt ist vernderlich (Bedeutungen von Anforderungen knnen sich verndern) Auswirkung von politischen Faktoren auf Anforderungen (Manager wollen ihre Macht erhalten oder ausbauen)

5.2.1. Ablauf- und Analysemodell Ein allgemeines Ablauf- und Analysemodell (Abbildung 13) soll das Verstehen des Anwendungsbereiches gewhrleisten. Systemanalytiker bentigen einen Einblick in den Fachbereich. Mit Hilfe einer Anforderungssammlung werden Anforderungen gesammelt und erweitertes Wissen ber den Anwendungsbereich erlangt. Durch eine Klassifizierung werden alle Anforderungen in Gruppen geordnet. Die verschiedenen Anforderungen seitens aller Projektbeteiligten werden in einer weiteren Phase gefunden und aufgelst. Das Setzen von Prioritten ermglicht die Trennung von wichtigen und unwichtigen Anforderungen. Die Anforderungsberprfung wird im Rahmen der Anforderungsvalidierung durchgefhrt.

Abbildung 13: Das Ablauf- und Analysemodell (nach [Sommerville 2001])

5.2.2. Anforderungsbestimmung Die Anforderungsbestimmung ist der Prozess der Informationssammlung von vorgeschlagenen und vorhandenen Systemen. Als Informationsquellen fr die Anforderungsbestimmung dienen Dokumentationen/Dokumente, Stakeholder und Beschreibungen hnlicher Systeme. Folgende Techniken knnen bei der Anforderungsbestimmung eingesetzt werden: Viewpoint-orientierte Bestimmung Interviews Szenarien Use-cases Ethnografie

Seite 14 von 20

SOFTWAREANFORDERUNGEN

a) Viewpoint-orientierte Anforderungsbestimmung Bei der Viewpoint-orientierten Anforderungsbestimmung werden verschiedene Sichtweisen auf das System betrachtet. Die einzelnen Perspektiven knnen sich berlappen, ergnzen oder auch widersprechen. Durch die Betrachtung vieler Sichtweisen knnen Anforderungen besser identifiziert und Konflikte bzw. Widersprche aufgedeckt werden. Die verschiedenen Arten von Viewpoints werden in Hierarchien organisiert und der Prozess und die Anforderungen nach den Sichtweisen strukturiert: Bei Interactor Viewpoints handelt es sich um Personen oder andere Systeme, die direkt mit dem System interagieren. Indirect Viewpoints sind Stakeholders, welche das System nicht selbst benutzen, aber die Anforderungen beeinflussen. Fachbereichseinflsse, die sich auf die Anforderungen auswirken, werden als Domain Viewpoints beschrieben.

Mgliche Vorgehensweise fr eine Viewpoint-orientierte Anforderungsbestimmung: 1. Identifizieren von Viewpoints, Diensten, Dateneingaben und nichtfunktionalen Anforderungen (Brainstorming) 2. Bestimmung der Viewpoints - Zuordnung von Diensten und Eingaben zu Viewpoints - Nicht zugeordnete Dienste ergeben einen neuen Viewpoint 3. Ausfllen von Viewpoint-Formularen und Dienst-Formularen 4. Bilden von Viewpoint-Hierarchien - Identifikation allgemeiner Dienste, Vererbung nach unten - Spezifische Dienste darunter vs. Konflikte 5. Beschreiben detaillierter Informationen ber die bentigten Dienste und Daten

b) Interviews Bei der Anforderungsbestimmung mit Hilfe von Interviews werden ausgewhlte Stakeholder befragt, um einen berblick bezglich der Arbeitsweise und dem Umgang mit dem System zu bekommen. Dabei werden kontrollierte Interviews mit vordefinierten Fragestellungen und offene Interviews mit Errterung verschiedener Themen durchgefhrt. In der Praxis wird meist ein Mix aus offenen und kontrollierten Interviews durchgefhrt, da ein rein offenes Interview oft wenig erfolgreich sein kann. Interviews sind gut geeignet, um einen berblick der Arbeitsweisen der Stakeholder zu bekommmen und wie diese mit dem System umgehen. Interviews sind weniger fr Organisatorische Anforderungen geeignet.

c) Szenarien Menschen finden es gewhnlich einfacher, einen Bezug zu realen Beispielen herzustellen als zu abstrakten Beschreibungen. Sie knnen durch ein Szenario (Drehbuch oder Ablaufbeschreibung) ihre Rolle im Zusammenhang mit einem Softwaresystem und den Umgang mit diesem leichter verstehen. Szenarien beschreiben anhand von Beispielsitzungen den Ablauf von Benutzerinteraktionen. Ein Szenario sollte folgende Punkte enthalten: 1. Systemzustand zu Beginn des Szenarios 2. Beschreibung des normalen Ereignisablaufs 3. Beschreibung von mglichen Fehlern und deren Behandlung
Seite 15 von 20

SOFTWAREANFORDERUNGEN

4. Hinweis auf anderen Aufgaben, die parallel ablaufen knnen 5. Beschreibung des Systemzustandes nach Abschluss des Szenarios Die szenariobasierte Bestimmung kann durch eine informelle Projektbeteiligten (z.B. Entwickler und Anwender) durchgefhrt werden. Zusammenarbeit von

d) Use-cases Use-cases (Anwendungsflle) sind eine szenariobasierte Technik. Sie sind Bestandteile der UMLNotation zur Beschreibung objektorientierter Systemmodelle. Akteure und die verfgbaren Anwendungsflle werden mit Hilfe von Textbeschreibungen oder Sequenzdiagrammen dargestellt (Abbildung 14).

Artikelsuche

Artikelausdruck Bibliotheksbenutzer

Benutzerverwaltung Bibliotheksbenutzer

Abbildung 14: Einfache Darstellung von Use-cases fr eine Bibliotheksanwendung

e) Ethnografie Softwaresysteme sind keine isolierten Systeme, sondern vielmehr in ein soziales und wirtschaftliches Umfeld eingebettet. Die Bercksichtigung von sozialen und wirtschaftlichen Anforderungen ist wesentlich fr den Projekterfolg. Ethnografie bezeichnet eine beobachtende Technik, um einen Einblick ber die tgliche Arbeit der Stakeholder und ihre Zusammenarbeit zu gewinnen. Implizite Systemanforderungen werden aufgedeckt und spiegeln die tatschlichen Prozesse wider, an denen Menschen beteiligt sind. Beispiel Broautomatisierungssysteme: Die tatschliche Arbeit ist viel reichhaltiger und komplexer als durch die Systeme abgedeckt. Das kann eine mgliche Ursache dafr sein, dass solche Systeme keine Effizienzsteigerung bringen.

5.3.

Anforderungsvalidierung

Die Validierung der Anforderungen umfasst verschiedene Arten der Prfung: Gltigkeitsprfungen (Gltigkeit fr alle Nutzer des Systems? Kompromisse) Konsistenzprfungen (Auflsung von Widersprchen) Vollstndigkeitsprfungen (Bercksichtigung aller erwarteten Anforderungen) Realisierbarkeitsprfungen (Bercksichtigung von Technologie, Budget und Zeitressourcen) Verifizierbarkeitsprfung (Mglichkeit der berprfbarkeit der Anforderungen mgliches Problempotential bei der Abnahme)
Seite 16 von 20

SOFTWAREANFORDERUNGEN

Zu den Techniken der Anforderungsvalidierung zhlen Prototypenerzeugung sowie die Generierung von Testfllen.

unter

anderem

Reviews,

die

a) Anforderungsreviews Bei einem Anforderungsreview prfen mehrere Personen das Pflichtenheft auf Abweichungen und Versumnisse. Anforderungsreviews knnen formell oder informell sein. Informelle Reviews betreffen nur das Entwicklungsteam bzw. den Anbieter, der die Anforderungen mit so vielen Projektbeteiligten wie mglich diskutiert. In einem formellen Anforderungsreview fhrt das Entwicklungsteam den Kunden durch die Systemanforderungen, indem die Auswirkungen jeder Anforderung erklrt werden. Jede Anforderung wird auf Verifizierbarkeit, Verstndlichkeit, Nachvollziehbarkeit und Anpassungsfhigkeit geprft. b) Prototypen Mit Hilfe eines Prototypen wird dem Kunden ein Systementwurf zum Experimentieren zur Verfgung gestellt. Somit kann ein Einblick gegeben werden, ob das System die tatschlichen Bedrfnisse und Anforderungen erfllt. c) Testfallerzeugung Anforderungen sollten durch entsprechende Testflle verifizierbar sein. Treten bereits bei der Erstellung von Testfllen Probleme auf, kann somit bereits auf Anforderungsprobleme geschlossen werden.

6. SYSTEMMODELLE
Im Rahmen der Anforderungsanalyse knnen eine Reihe verschiedener Arten von Systemmodellen erstellt werden. Ein Modell ist die abstrakte Sichtweise eines Systems, die einige Systemdetails ignoriert. Es knnen ergnzende Systemmodelle erstellt werden, die andere Informationen ber das System darstellen. Der wichtigste Aspekt eines Systemmodells ist, dass es Details auslsst. Ein Systemmodell ist eher eine Abstraktion des untersuchten Systems als eine alternative Darstellungsform. Idealerweise sollte die Darstellung eines Systems alle Informationen ber die dargestellte Entitt beibehalten. Eine Abstraktion vereinfacht willkrlich und whlt die hervorstechendsten Merkmale aus. Eine Auswahl von Arten von Systemmodellen, die whrend des Prozesses der Anforderungsanalyse erstellt werden knnen, werden im folgenden kurz vorgestellt.

6.1.

Architekturmodell

Architekturmodelle zeigen die wichtigsten Systeme bzw. Subsysteme und dienen der Veranschaulichung sowie einem gemeinsamen Verstndnis (Abbildung 15).

Abbildung 15: Illustrierdendes Beispiel einer Systemarchitektur (entnommen aus [Krueger 2000]) Seite 17 von 20

SOFTWAREANFORDERUNGEN

6.2.

Datenflussmodell

Datenflussdiagramme (Abbildung 16) zeigen, wie Daten auf verschiedenen Stufen des Systems verarbeitet werden, und sind gut geeignet zur Darstellung von Ablufen (Prozessen). Sie hneln einem Aktivittsdiagramm, stellen aber den Informationsfluss whrend des Prozesses in den Vordergrund. Verzweigungen werden mit Rauten dargestellt. Die Richtung des weiteren Datenflusses hngt dabei vom Wahrheitsgehalt einer Aussage ab.

Abbildung 16: Illustrierendes Beispiel eines Datenverarbeitungsmodells (entnommen aus [RSB])

6.3.

Entity-Relationship-Modell

Entity-Relationship-Diagramme stellen dar, wie die Entitten des Systems aus anderen Entitten zusammengesetzt sind (Abbildung 17). Dieses Modell wird hufig beim Datenbankentwurf verwendet.

Abbildung 17: Beispiel eines Entity-Relationship-Modells (entnommen aus [Rosenfeld et all. 2002]) Seite 18 von 20

SOFTWAREANFORDERUNGEN

6.4.

Klassifikationsmodell

Objektklassen-/Vererbungsdiagramme (Abbildung 18) veranschaulichen, welche gemeinsamen Merkmale Entitten haben.

Abbildung 18: Illustrierendes Beispiel eines Klassifikationsmodells (entnommen aus [WIKIPEDIA])

6.5.

Stimulus/Response-Modell

Ein Zustandsdiagramm (Abbildung 19) zeigt, wie das System auf interne und externe Ereignisse reagiert.

Abbildung 19: Illustrierendes Beispiel eines Stimulus/Response-Modells (entnommen aus [Mueller 1997])

Seite 19 von 20

SOFTWAREANFORDERUNGEN

7. LITERATURVERZEICHNIS
[Krueger 2000] Krger, Gerhard: Web Engineering, Fakultt fr Informatik, Universitt Karlsruhe, 2000. [Mueller 1997] Mller, Oliver: Objektorientiertes Entwerfen - Teil 2; Linux Magazin, 02/1997, und http://www.linux-magazin.de/Artikel/ausgabe/1997/02/OOP/oop.html [Sommerville 2001] Sommerville, Ian: Software Engineering. 6th edition. Mnchen, Germany, 2001. [Sommerville 2005] Sommerville, Ian: Software Engineering 7, Addison-Wesley, Boston, USA, 2005. [Rosenfeld et all. 2002] Rosenfeld, Louis; Morville, Peter: Information Architecture , Oreilly, August 2002. [RSB] Realschule Bayern: Daten- und Ablaufmodellierung; http://www.realschule.bayern.de/lehrer/dokumente/untmat/inf/ak-inf/modell-t/modt1/modt1.htm [WIKIPEDIA] WIKIPEDIA: Zustand (Entwurfsmuster); http://de.wikipedia.org/wiki/Zustand_(Entwurfsmuster)

Seite 20 von 20