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

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 Gütl

Inhaltsverzeichnis 1. EINLEITUNG...3 2. 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 dazugehöriger Systemanforderungen...7 3. EINTEILUNG DER ANFORDERUNGEN...8 3.1. Funktionale Anforderungen...8 3.1.1. Beispiele für Funktionale Anforderungen...8 3.2. Nichtfunktionale Anforderungen...9 3.2.1. Beispiele für Nichtfunktionale Anforderungen...9 3.3. Problembereichsanforderungen...10 3.3.1. Beispiele für 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. Durchführbarkeitsstudien...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. Architekturmodell...17 6.2. Datenflussmodell...18 6.3. Entity-Relationship-Modell...18 6.4. Klassifikationsmodell...19 6.5. Stimulus/Response-Modell...19 7. LITERATURVERZEICHNIS...20 Seite 2 von 20

1. EINLEITUNG In diesem Kapitel soll erläutert werden, wie Anforderungen an ein Softwaresystem zum Ausdruck gebracht werden können. Dabei werden unterschiedliche Arten von Softwareanforderungen definiert und Techniken zur Beschreibung vorgestellt. Der Prozess des Herausfindens, Analysierens, Dokumentierens und Überprüfens der Anforderungen wird durch die Beschreibung der sogenannten Anforderungsanalyse erläutert. Abschließend wird ein möglicher Aufbau eines Pflichtenheftes nach dem IEEE-Standard dargestellt. Die Basis für 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 Softwareengineering- Prozesses. In der Praxis herrscht ein Spannungsfeld zwischen der notwendigen Festlegung der Anforderungen und der zur Verfügung 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 fließen in das Lasten- bzw. Pflichtenheft ein, das für einen großen Leserkreis verständlich sein soll. Die Anforderungen können in Benutzer- und Systemanforderungen getrennt werden. Durch diese Trennung in zwei Genauigkeitsgrade kann eine noch detailliertere Spezifikation des Softwareentwurfs für 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

2.1. Benutzeranforderungen Benutzeranforderungen sollen funktionale und nichtfunktionale Anforderungen auf einer hohen Abstraktionsebene beschreiben. Benutzeranforderungen sind Aussagen in natürlicher 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 für Manager beim Kunden als auch für Manager beim Softwarehersteller erstellt werden, die kein genaues technisches Wissen über das System haben. Benutzeranforderungen sind für Menschen geschrieben, die an der Verwendung und Beschaffung des Systems beteiligt sind. Die Benutzeranforderungen für ein System sollten die funktionalen und nichtfunktionalen Anforderungen so beschreiben, dass sie für jene Systembenutzer verständlich sind, die kein detailliertes technisches Wissen haben. Sie sollten nur das externe Verhalten des Systems festlegen und Charakteristika des Systementwurfs so weit wie möglich vermeiden. Daher sollten Benutzeranforderungen nicht mittels eines Implementierungsmodells, sondern unter Benutzung natürlicher Sprache, gezeichneter Formulare und einfacher intuitiver Diagramme verfasst werden. Zu viele Informationen schränken die Freiheit des Systementwicklers ein, um innovative Lösungen zu finden. Anmerkungen und Hinweise zur Definition von Benutzeranforderungen: - Die Nutzung eines Standardformates ist sinnvoll, da Versäumnissen vorgebeugt und die Überprüfbarkeit erleichtert werden kann. - Wichtige Aussagen sollten durch entsprechende Formatierungen hervorgehoben werden. Begründungen sind vor allem für Systementwickler und Systemwarter hilfreich, da somit eine bessere Nachvollziehbarkeit von Entscheidungen gewährleistet wird. - Einheitliche Ausdrucksweisen (z.b. sollen für verbindliche Anforderungen, sollten für wünschenswerte Anforderungen) wirken Missverständnissen entgegen. - Computerjargon sollte man im allgemeinen vermeiden, jedoch kann auf Ausdrücke des Fachbereiches in manchen Fällen nicht verzichtet werden. Es ist eine gute Methode, im Pflichtenheft Benutzeranforderungen von detaillierteren Systemanforderungen zu trennen. 2.1.1. Beispiel einer Benutzeranforderung 3.5.1. Hinzufügen von Knoten zu einem Entwurf 3.5.1.1. Der Editor soll dem Benutzer die Möglichkeit bieten, Knoten eines bestimmten Typs zu ihrem Entwurf hinzuzufügen 3.5.1.2. Beim Hinzufügen von Knoten sollen folgende Vorgänge stattfinden: - Der Benutzer soll den hinzuzufügenden Knotentyp auswählen. - Der Benutzer soll den Cursor in die Nähe der Knotenposition im Diagramm bewegen, um die ungefähre Position festzulegen. - Der Benutzer soll dann das Knotensymbol auf die endgültige Position ziehen. Begründung: 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

2.2. Systemanforderungen Systemanforderungen sind genauere Beschreibungen der Benutzeranforderungen. Sie dienen den Softwareentwicklern als Basis für den Systementwurf und können auch als Basis für einen Vertrag über die Systemimplementierung dienen. Systemanforderungen legen die Dienste und Beschränkungen detailliert fest. Die Spezifikation der Systemanforderungen sollte an das höhere 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 können beide Dokumente lesen. Systemanforderungen sind zur präzisen Beschreibung der Funktionen bestimmt, die das System bereitstellen soll. Um Mehrdeutigkeiten zu vermeiden, können sie in einer Art strukturierten Sprache verfasst werden. Dies könnte ein strukturierte Form natürlicher Sprache (Pseudocode), eine auf einer höheren Programmiersprache basierte oder eine spezielle Sprache für die Anforderungsspezifikation sein. Systemanforderungen können als Basis für 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 für einen exakteren Entwurf und dessen Umsetzung dient. Diese Spezifikation fügt weitere Details zur Spezifikation dieser Systemsanforderungen hinzu. Die Spezifikation des Softwareentwurfs ist ein programmiererorientiertes Dokument. Es sollte für die Softwareentwickler geschrieben werden, die das System entwickeln werden. 2.1.2. Notationen der Systemanforderungen Systemanforderungen können auf folgende Arten verfasst werden: a) Natürliche Sprache Hierbei kann es zu Missverständnissen wegen der Mehrdeutigkeit der natürlichen Sprache kommen. Es gibt keine einheitliche Darstellungsart und diese Notation ist schwierig zu modularisieren (Erschwertes Finden von Abhängigkeiten). b) Strukturierte natürliche Sprache Bei dieser Notation wird eine Einheitlichkeit in der Spezifikation durch Standardformulare erzwungen (Abbildung 3). Wichtige Informationen werden nicht übersehen und die Prüfbarkeit der Anforderungen wird erleichtert. Die Ausdruckskraft und die Verständlichkeit der natürlichen Sprache bleibt jedoch auf jeden Fall erhalten. ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Funktion Knoten hinzufügen Beschreibung Fügt einen Knoten zu einem vorhandenen Entwurf hinzu. Der Benutzer wählt den Typ des Knotens und seine Position aus. Nachdem der Knoten zum Entwurf hinzugefügt wurde, wird er zur aktuellen Auswahl. Der Benutzer wählt die Knotenposition, indem er den Cursor an die Stelle bewegt, an welcher der Knoten hinzugefügt 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

Ziel Die Entwurfsdatenbank. Nach Abschluss der Operation wird der Entwurf in die Datenbank eingetragen. Benötigt Einen Entwurfsgraphen, gekennzeichnet durch die Entwurfskennung seines Wurzelknotens. Vorbedingung Der Entwurf ist geöffnet und wird auf dem Bildschirm des Benutzers angezeigt. Nachbedingung Der Entwurf bleibt abgesehen vom Hinzufügen eines Knotens des ausgewählten Typs an der gewählten Position unverändert. Seiteneffekte Keine Definition: ECLIPSE/Workstaton/Tools/DE/RD/3.5.1 Abbildung 3: Beispiel eines Standardformulars für die Spezifikation von Anforderungen in natürlicher strukturierter Sprache (nach [Sommerville 2001]) c) Sprachen zur Entwurfsbeschreibung (PDL) Sprachen der Entwurfsbeschreibung bzw. Program Description Languages (PDLs) sind an Programmiersprachen angelehnte Sprachen mit zusätzlichen abstrakten Konstrukten. Es kann somit Mehrdeutigkeiten der natürlichen Sprache entgegengewirkt werden. Ergänzend zu formularbasierten Spezifikationen können komplexere Abläufe von Vorgängen 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 für Menschen mit programmiersprachlichen Kenntnissen verständlich. Weiters kann diese Notation zu ausdrucksschwach sein, um alle Systemfunktionen zu beschreiben. Einzelne Projektbeteiligten könnten diese Beschreibung fälschlicherweise auch als Entwurfsspezifikation interpretieren. In der Praxis ist daher eine Kombination einer PDL (Abbildung 4) mit der Beschreibung in strukturierter natürlicher Sprache empfehlenswert. class ATM { // Deklarationen public static void main (String args[]) throws InvalidCard { try { thiscard.read(); // Kann die Exception Invalid Card auslösen 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

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 ergänzt (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 dazugehöriger Systemanforderungen Der Zusammenhang zwischen einer Benutzer- und der dazugehörigen 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 verfügen und auf sie zugreifen können. Definition einer Systemanforderung (im Pflichtenheft) 1.1 Der Benutzer sollte über Möglichkeiten zur Definition externer Datentypen verfügen. 1.2 Jeder externe Dateityp kann eine damit verknüpfte Anwendung besitzen, mit der die Datei bearbeitet wird. 1.3 Jeder externe Dateityp kann als bestimmtes Symbol auf dem Bildschirm des Anwenders dargestellt werden. 1.4 Es sollten Möglichkeiten zur Definition des Symbols für externe Dateitypen durch den Benutzer dargestellt werden. 1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei repräsentiert, so soll die durch dieses Symbol dargestellte Datei mit der Anwendung geöffnet werden, die mit dem entsprechenden externen Dateityp verknüpft ist. Abbildung 5: Beispiel von Benutzer- und Systemanforderungen (nach [Sommerville 2001]) Seite 7 von 20

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 Fällen können die funktionalen Anforderungen auch explizit ausdrücken, was das System nicht tun soll. Die funktionalen Anforderungen an ein System beschreiben die Funktionalität oder die Dienste, die von einem System erwartet werden. Diese Anforderungen hängen vom Wesen der Software, den erwarteten Benutzern und der Art des entwickelten Systems ab. Als Benutzeranforderungen ausgedrückt werden sie gewöhnlich auf eine ziemlich allgemeine Weise beschrieben, funktionale Systemanforderungen jedoch beschreiben die Systemfunktion im Detail, seine Eingaben und Ausgaben sowie Ausnahmen. Alle vom Benutzer benötigten Funktionen müssen festgelegt werden und die Anforderungen dürfen keine widersprüchlichen Festlegungen enthalten. In der Praxis können größere und komplexe Systeme meist nie diese Vollständigkeit und Konsistenz aufweisen. Viele Probleme entstehen aus der ungenauen Festlegung der Anforderungen, vor allem wenn eine mehrdeutige Interpretation möglich ist. 3.1.1. Beispiele für Funktionale Anforderungen 1. Der Benutzer soll die gesamte Menge der Dokumente oder eine ausgewählte Teilmenge durchsuchen können. 2. Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentkorpus lesen kann. 3. Jeder Bestellung soll ein eindeutiger Bezeichner (Order ID) zugeordnet werden, und der Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können. Abbildung 7: Beispiele von Funktionalen Anforderungen an ein Bibliothekssystem Seite 8 von 20

3.2. Nichtfunktionale Anforderungen Nichtfunktionale Anforderungen sind Anforderungen, welche die durch das System zu leistenden speziellen Funktionen nicht direkt betreffen. Sie können sich auf wichtige Softwareeigenschaften wie Zuverlässigkeit, Reaktionszeit und Speicherbedarf beziehen. Alternativ können sie auch Beschränkungen des Systems definieren, wie z.b. die Leistungsfähigkeit von E/A-Geräten und die durch die Systemschnittstelle benutzten Datendarstellungen. Nichtfunktionale Anforderungen können in Produktanforderungen, Unternehmensanforderungen und Externe Anforderungen eingeteilt werden (Abbildung 8). Abbildung 8: Unterteilung für nichtfunktionale Anforderungen (nach [Sommerville 2001]) Nichtfunktionale Anforderungen beziehen sich im allgemeinen auf das ganze System und wirken einschränkend auf das System und die Systemfunktionen. Das Nichteinhalten von Nichtfunktionalen Anforderungen wirkt sich stärker aus als das Nichteinhalten einzelner Funktionaler Anforderungen. 3.2.1. Beispiele für Nichtfunktionale Anforderungen 1. Produktanforderungen (beschreiben das Verhalten des Produktes) z.b. Performance, Zuverlässigkeit, Portierbarkeit und Benutzbarkeit 2. Unternehmensanforderungen (bestimmt durch Unternehmenspolitik und Arbeitsweisen von Auftragenehmer und Auftraggeber) z.b. Lieferanforderungen, Umsetzung, Vorgehensweisen 3. Externe Anforderungen (alles außerhalb des Systems und seines Entwicklungsprozesses) z.b. Kompatibilität zu anderen Systemen, Rechtliche Anforderungen (Einhaltung von Gesetzen), Ethnische Anforderungen Abbildung 9: Beispiele für Nichtfunktionale Anforderungen Seite 9 von 20

3.3. Problembereichsanforderungen Problembereichsanforderungen ergeben sich eher aus dem Anwendungsbereich des Systems als aus speziellen Bedürfnissen von Systembenutzern. Sie können selbst neue funktionale Anforderungen sein, vorhandene funktionale Anforderungen einschränken oder festlegen, wie bestimmte Berechnungen durchgeführt werden müssen. Problembereichsanforderungen sind wichtig, da sie allgemeine Arbeitsweisen des Bereiches, Standards, Vorschriften und Regulierungen widerspiegeln. In der Praxis kann das System bei Nichtberücksichtigung von Problembereichsanforderungen unbrauchbar sein bzw. nicht zufriedenstellend arbeiten. Problembereichsanforderungen können wiederum in funktionale und nichtfunktionale Anforderungen eingeteilt werden. 3.3.1. Beispiele für Problembereichsanforderungen Bibliothekssystem - Funktional: Vormerkfunktion (zur Verfügung gestellt, wenn Buch verborgt ist) - Nichtfunktional: Unterstützung von Klassifikationssystem (z.b. Dewey Decimal Classification) Buchhaltungsprogramm - Funktional: Splitbuchung (Aufteilung des Rechnungsbetrages auf verschiedene Konten) - Nichtfunktional: Buchungssätze dürfen nachträglich nicht mehr editierbar sein; Gelöschte Buchungen müssen sichtbar bleiben Abbildung 10: Beispiele für Problembereichsanforderungen 4. DAS PFLICHTENHEFT Das Pflichtenheft ist die offizielle Aufstellung darüber, 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 Fällen werden die Benutzer- und Systemanforderungen zu einer einzigen Beschreibung zusammengefasst. In anderen Fällen werden die Benutzeranforderungen in einer Einleitung der Spezifikation der Systemanforderungen definiert. Gibt es eine Vielzahl von Anforderungen, können die genauen Systemanforderungen in verschiedenen Dokumenten dargelegt werden. Jedenfalls sollte die Verknüpfung zwischen den Benutzeranforderungen und den zugehörigen Systemanforderungen leicht möglich sein. Ein Softwareanforderungsdokument sollte folgende Bedingungen erfüllen: - Es sollte nur das äußere Systemverhalten festlegen. - Es sollte Beschränkungen bezüglich der Implementierung vorgeben. - Es sollte leicht zu verändern sein. - Es sollte als Referenz für Systemwarter dienen. - Es sollte Vorüberlegungen 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, prüft das Dokument auf den gewünschten Umfang und kann Änderungen veranlassen. Manager sind für die Angebotserstellung und die Planung des Systementwicklungsprozesses zuständig. Entwickler sind für die Softwareerstellung bzw. Systementwicklung verantwortlich. Systemtester verifizieren und validieren das System. Seite 10 von 20

Systemwarter eignen sich mit Hilfe des Pflichtenheftes ein entsprechendes Verständnis für das System an. Abbildung 11: Personenkreise eines Pflichtenheftes 4.1. Aufbau eines Pflichtenhefts Nachfolgend wird ein möglicher Aufbau für 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 Begründung für die Entwicklung einer neuen Version und eine Zusammenfassung über die Veränderungen bei jeder Version beinhalten sollte. Einleitung - Dieses Kapitel sollte die Notwendigkeit des Systems beschreiben. Es sollte kurz seine Funktionen darlegen und erklären, wie es mit anderen Systemen zusammenarbeiten wird. Außerdem sollte erläutert werden, wie das System mit den gesamtwirtschaftlichen oder strategischen Zielen des Unternehmens übereinstimmt, welches die Software in Auftrag gibt. Begriffe und Abkürzungen - Dieser Teil sollte die im Dokument verwendeten technischen Fachbegriffe und Abkürzungen festlegen. Dabei sollte keine Erfahrung oder Fachwissen beim Leser vorausgesetzt werden. Verweise auf referenzierte Literatur - In diesem Abschnitt sollten die Quellen für verwendete Literatur bzw. andere Ressourcen aufgelistet werden. 4.1.2. Abschnitt 2: Anforderungsbeschreibung Definition der Benutzeranforderungen - Die für den Benutzer bereitgestellten Dienste und die nichtfunktionalen Anforderungen sollten in diesem Abschnitt beschrieben werden. Diese Beschreibung kann natürliche Sprache, Diagramme oder andere für die Kunden verständliche Notationen benutzen. Produkt- und Entwicklungsstandards, die befolgt werden müssen, sollten ebenfalls festgelegt werden. Seite 11 von 20

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 können auch weitere Einzelheiten zu den nichtfunktionalen Anforderungen hinzugefügt 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 können Klassen-, Datenfluss und semantische Datenmodelle sein. Systementwicklung - Dieser Teil sollte die grundlegenden Voraussetzungen, auf denen das System basiert, und erwartete Veränderungen aufgrund der Hardwareentwicklung, Veränderungen der Benutzeranforderungen usw. beschreiben. 4.1.3. Abschnitt 3: Anhang Anhänge - Diese sollten genauere spezifische Informationen beinhalten, die sich auf die entwickelte Anwendung beziehen. Beispiele von möglichen Anhängen 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. Widersprüche und Konflikte müssen an dieser Stelle aufgelöst 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 verständlich und beschreibt nur das äußere Systemverhalten. Veränderungen sollen leicht durchführbar und nachvollziehbar sein. Die Erstellung einer ausgereiften Spezifikation ist oft mit Aufwand und Kosten für den Kunden verbunden. Jedoch kann ein gut erstelltes Pflichtenheft nachträglich 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 höheren Ebene stattfindende Aktivitäten der Anforderungsanalyse: 1. Durchführbarkeitsstudie 2. Anforderungsbestimmung und -analyse 3. Anforderungsspezifikation 4. Anforderungsvalidierung Abbildung 12 stellt den Ablauf und die Phasen einer typischen Anforderungsanalyse dar. Seite 12 von 20

Abbildung 12: Der Ablauf der Anforderungsanalyse (nach [Sommerville 2001]) 5.1. Durchführbarkeitsstudien Bei allen neuen Systemen sollte der Prozess der Anforderungsanalyse mit einer Durchführbarkeitsstudie beginnen. Das Eingangsmaterial für die Durchführbarkeitsstudie 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 Durchführbarkeitsstudie 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 Zeitbeschränkungen realisiert werden? - Kann das System mit anderen Systemen zusammenarbeiten, die bereits in Betrieb sind? Nach der Einholung dieser Informationen wird der Bericht zur Durchführbarkeitsstudie angefertigt. Dieser sollte eine Empfehlung darüber aussprechen, ob die Entwicklung des Systems fortgesetzt werden soll. Er kann Veränderungen 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 Durchführbarkeitsstudie sind der Startpunkt für die Anforderungsbestimmung und analyse. Auftragnehmer und Kunden/Systembenutzer arbeiten eng zusammen, um den Anwendungsbereich, die vom System zu leistenden Dienste, erforderliche Funktionen und Einschränkungen zu bestimmen. In der Praxis können folgende Probleme bei der Anforderungsbestimmung und analyse auftreten: - Stakeholder können Erwartungen an System schwer ausdrücken, meist mit impliziten Wissen ihrer Tätigkeiten; dabei ist Fachbereichswissen notwendig - Stakeholder haben zum Teil unrealistische Forderungen im Hinblick auf die Ressourcen Seite 13 von 20

- Verschiedene Stakeholder haben unterschiedliche Anforderungen (andere Ausdrucksweise vs. Übereinstimmung und Konflikte) - Interne und externe Unternehmensumwelt ist veränderlich (Bedeutungen von Anforderungen können sich verändern) - 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 gewährleisten. Systemanalytiker benötigen 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 aufgelöst. Das Setzen von Prioritäten ermöglicht die Trennung von wichtigen und unwichtigen Anforderungen. Die Anforderungsüberprüfung wird im Rahmen der Anforderungsvalidierung durchgeführt. 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 für die Anforderungsbestimmung dienen Dokumentationen/Dokumente, Stakeholder und Beschreibungen ähnlicher Systeme. Folgende Techniken können bei der Anforderungsbestimmung eingesetzt werden: - Viewpoint-orientierte Bestimmung - Interviews - Szenarien - Use-cases - Ethnografie Seite 14 von 20

a) Viewpoint-orientierte Anforderungsbestimmung Bei der Viewpoint-orientierten Anforderungsbestimmung werden verschiedene Sichtweisen auf das System betrachtet. Die einzelnen Perspektiven können sich überlappen, ergänzen oder auch widersprechen. Durch die Betrachtung vieler Sichtweisen können Anforderungen besser identifiziert und Konflikte bzw. Widersprüche 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. - Fachbereichseinflüsse, die sich auf die Anforderungen auswirken, werden als Domain Viewpoints beschrieben. Mögliche Vorgehensweise für 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. Ausfüllen 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 benötigten Dienste und Daten b) Interviews Bei der Anforderungsbestimmung mit Hilfe von Interviews werden ausgewählte Stakeholder befragt, um einen Überblick bezüglich der Arbeitsweise und dem Umgang mit dem System zu bekommen. Dabei werden kontrollierte Interviews mit vordefinierten Fragestellungen und offene Interviews mit Erörterung verschiedener Themen durchgeführt. In der Praxis wird meist ein Mix aus offenen und kontrollierten Interviews durchgeführt, 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 für Organisatorische Anforderungen geeignet. c) Szenarien Menschen finden es gewöhnlich einfacher, einen Bezug zu realen Beispielen herzustellen als zu abstrakten Beschreibungen. Sie können 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 möglichen Fehlern und deren Behandlung Seite 15 von 20

4. Hinweis auf anderen Aufgaben, die parallel ablaufen können 5. Beschreibung des Systemzustandes nach Abschluss des Szenarios Die szenariobasierte Bestimmung kann durch eine informelle Zusammenarbeit von Projektbeteiligten (z.b. Entwickler und Anwender) durchgeführt werden. d) Use-cases Use-cases (Anwendungsfälle) sind eine szenariobasierte Technik. Sie sind Bestandteile der UML- Notation zur Beschreibung objektorientierter Systemmodelle. Akteure und die verfügbaren Anwendungsfälle werden mit Hilfe von Textbeschreibungen oder Sequenzdiagrammen dargestellt (Abbildung 14). Artikelsuche Bibliotheksbenutzer Artikelausdruck Benutzerverwaltung Bibliotheksbenutzer Abbildung 14: Einfache Darstellung von Use-cases für eine Bibliotheksanwendung e) Ethnografie Softwaresysteme sind keine isolierten Systeme, sondern vielmehr in ein soziales und wirtschaftliches Umfeld eingebettet. Die Berücksichtigung von sozialen und wirtschaftlichen Anforderungen ist wesentlich für den Projekterfolg. Ethnografie bezeichnet eine beobachtende Technik, um einen Einblick über die tägliche Arbeit der Stakeholder und ihre Zusammenarbeit zu gewinnen. Implizite Systemanforderungen werden aufgedeckt und spiegeln die tatsächlichen Prozesse wider, an denen Menschen beteiligt sind. Beispiel Büroautomatisierungssysteme: Die tatsächliche Arbeit ist viel reichhaltiger und komplexer als durch die Systeme abgedeckt. Das kann eine mögliche Ursache dafür sein, dass solche Systeme keine Effizienzsteigerung bringen. 5.3. Anforderungsvalidierung Die Validierung der Anforderungen umfasst verschiedene Arten der Prüfung: - Gültigkeitsprüfungen (Gültigkeit für alle Nutzer des Systems? Kompromisse) - Konsistenzprüfungen (Auflösung von Widersprüchen) - Vollständigkeitsprüfungen (Berücksichtigung aller erwarteten Anforderungen) - Realisierbarkeitsprüfungen (Berücksichtigung von Technologie, Budget und Zeitressourcen) - Verifizierbarkeitsprüfung (Möglichkeit der Überprüfbarkeit der Anforderungen mögliches Problempotential bei der Abnahme) Seite 16 von 20

Zu den Techniken der Anforderungsvalidierung zählen unter anderem Reviews, die Prototypenerzeugung sowie die Generierung von Testfällen. a) Anforderungsreviews Bei einem Anforderungsreview prüfen mehrere Personen das Pflichtenheft auf Abweichungen und Versäumnisse. Anforderungsreviews können formell oder informell sein. Informelle Reviews betreffen nur das Entwicklungsteam bzw. den Anbieter, der die Anforderungen mit so vielen Projektbeteiligten wie möglich diskutiert. In einem formellen Anforderungsreview führt das Entwicklungsteam den Kunden durch die Systemanforderungen, indem die Auswirkungen jeder Anforderung erklärt werden. Jede Anforderung wird auf Verifizierbarkeit, Verständlichkeit, Nachvollziehbarkeit und Anpassungsfähigkeit geprüft. b) Prototypen Mit Hilfe eines Prototypen wird dem Kunden ein Systementwurf zum Experimentieren zur Verfügung gestellt. Somit kann ein Einblick gegeben werden, ob das System die tatsächlichen Bedürfnisse und Anforderungen erfüllt. c) Testfallerzeugung Anforderungen sollten durch entsprechende Testfälle verifizierbar sein. Treten bereits bei der Erstellung von Testfällen Probleme auf, kann somit bereits auf Anforderungsprobleme geschlossen werden. 6. SYSTEMMODELLE Im Rahmen der Anforderungsanalyse können eine Reihe verschiedener Arten von Systemmodellen erstellt werden. Ein Modell ist die abstrakte Sichtweise eines Systems, die einige Systemdetails ignoriert. Es können ergänzende Systemmodelle erstellt werden, die andere Informationen über das System darstellen. Der wichtigste Aspekt eines Systemmodells ist, dass es Details auslässt. Ein Systemmodell ist eher eine Abstraktion des untersuchten Systems als eine alternative Darstellungsform. Idealerweise sollte die Darstellung eines Systems alle Informationen über die dargestellte Entität beibehalten. Eine Abstraktion vereinfacht willkürlich und wählt die hervorstechendsten Merkmale aus. Eine Auswahl von Arten von Systemmodellen, die während des Prozesses der Anforderungsanalyse erstellt werden können, werden im folgenden kurz vorgestellt. 6.1. Architekturmodell Architekturmodelle zeigen die wichtigsten Systeme bzw. Subsysteme und dienen der Veranschaulichung sowie einem gemeinsamen Verständnis (Abbildung 15). Abbildung 15: Illustrierdendes Beispiel einer Systemarchitektur (entnommen aus [Krueger 2000]) Seite 17 von 20

6.2. Datenflussmodell Datenflussdiagramme (Abbildung 16) zeigen, wie Daten auf verschiedenen Stufen des Systems verarbeitet werden, und sind gut geeignet zur Darstellung von Abläufen (Prozessen). Sie ähneln einem Aktivitätsdiagramm, stellen aber den Informationsfluss während des Prozesses in den Vordergrund. Verzweigungen werden mit Rauten dargestellt. Die Richtung des weiteren Datenflusses hängt 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 Entitäten des Systems aus anderen Entitäten zusammengesetzt sind (Abbildung 17). Dieses Modell wird häufig beim Datenbankentwurf verwendet. Abbildung 17: Beispiel eines Entity-Relationship-Modells (entnommen aus [Rosenfeld et all. 2002]) Seite 18 von 20

6.4. Klassifikationsmodell Objektklassen-/Vererbungsdiagramme (Abbildung 18) veranschaulichen, welche gemeinsamen Merkmale Entitäten 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

7. LITERATURVERZEICHNIS [Krueger 2000] Krüger, Gerhard: Web Engineering, Fakultät für Informatik, Universität Karlsruhe, 2000. [Mueller 1997] Müller, 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. München, 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