LE 5: Richtigkeit Softwareanforderungen. Praktikum Softwaretechnik Sommersemester Stephan Salinger 1/52

Transkript

1 LE 5: Richtigkeit Softwareanforderungen Praktikum Softwaretechnik Sommersemester 2004 Stephan Salinger 1/52

2 Softwareanforderungen Quellen 1. Ian Sommerville: Software Engineering, 6. Auflage, Pearson Education Deutschland GmbH 2. Helmuth Balzert: Lehrbuch der Software-Technik Software-Entwicklung, 2. Auflage, Spektrum Akademischer Verlag Heidelberg Berlin Stephan Salinger 2/52

3 Softwareanforderungen Inhalt 1. Anforderungen und ihre Beschreibung (Darstellung der Dienste und Einschränkungen) Benutzeranforderungen vs. Systemanforderungen Lastenheft vs. Pflichtenheft Funktional vs. nichtfunktionale Anforderungen Beispielstruktur Lastenheft Beispielstruktur Pflichtenheft 2. Anforderungsanalyse Prozess des Herausfindens, Analysierens und Überprüfens der Dienste und Einschränkungen Stephan Salinger 3/52

4 Spezifikationsarten Anforderung: Teil 1 Kunde beschreibt in einem Lastenheft die Erfordernisse an ein Softwareentwicklungsprojekt Wir nennen die Inhalte des Lastenheftes Benutzeranforderungen (fachliche Anforderungen): Aussagen in natürlicher Sprache Evtl. Verwendung von Diagrammen (zur Beschreibung der Dienste) Angabe von Randbedingungen, unter denen das System betrieben wird Verwendung eines hohen Abstraktionsniveaus Der Lösung nicht vorgreifen. Im Lastenheft wird definiert, WAS WOFÜR zu lösen ist und nicht, WIE die Leistungen zu erbringen sind. Achtung: Es kann sein, dass kein konkreter Kunde existiert (Produktentwicklung) Stephan Salinger 4/52

5 Spezifikationsarten Anforderung: Teil 2 Auftragnehmer stellt in einem Pflichtenheft (funktionale Spezifikation) eine genaue Systemdefinition für den Kunden auf Wir nennen die Inhalte des Pflichtenheftes Systemanforderungen: Legen Dienste und Beschränkungen detailliert fest Kunde muss verstehen was das System tun wird Soll als Basis für die Spezifikation des Softwareentwurfs verwendet werden Eine Benutzeranforderung kann sich zu mehreren Systemanforderungen erweitern Im Pflichtenheft wird definiert, WIE und WOMIT die Anforderungen zu realisieren sind. Achtung: Oft wird die Zusammenführung der Dokumente mit den Benutzer- und Systemanforderungen als Pflichtenheft bezeichnet. Stephan Salinger 5/52

6 Spezifikationsarten: alternative Definitionen 1 Helmut Balzert: Lehrbuch der Softwaretechnik Das fachliche Dokument der der Planungsphase wird oft als Lastenheft oder grobes Pflichtenheft bezeichnet, ergänzt um ein Glossar Die detaillierte verbale Beschreibung der Anforderungen an ein neues Produkt wird oft als Pflichtenheft bezeichnet Das Pflichtenheft enthält eine Zusammenfassung aller fachlichen Anforderungen, die das zu entwickelnde Software-Produkt aus Sicht des Auftraggebers erfüllen muss. Außerdem werden Entwicklungsprioritäten aus Auftraggebersicht festgelegt. Die Inhalte stellen eine Konkretisierung und Detaillierung der Lastenheft-Inhalte dar. Das Lastenheft kann daher als Ausgangsdokument für das Pflichtenheft verwendet werden. Stephan Salinger 6/52

7 Spezifikationsarten: alternative Definitionen 2 DIN Das Lastenheft wird vom Auftraggeber erstellt. Es enthält es die "Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers". Gleichzeitig dient das Lastenheft auch als Grundlage zur Einholung von Angeboten. Konkret umfasst ein solches Heft die technischen und inhaltlichen Vorgaben, die an die Software gestellt werden. IT Dienstleister, die sich an einer Ausschreibung beteiligen, erstellen ein Pflichtenheft. Es enthält nach DIN die vom "Auftragnehmer erarbeiteten Realisierungsvorgaben" und beschreibt die "Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts". Stephan Salinger 7/52

8 Zielgruppen Spezifikationsarten Lastenheft/Benutzeranforderungen Manager des Kunden Endbenutzer des Systems Techniker des Kunden Manager des Softwareherstellers Pflichtenheft/Systemanforderungen Endbenutzer des Systems Techniker des Kunden Systemarchitekten Softwareentwickler Stephan Salinger 8/52

9 Aufteilung von Anforderungen Funktionale Anforderungen Funktionalitäten oder Dienste, die das System leisten soll Reaktion des Systems auf bestimmte Eingaben Verhalten des Systems in bestimmten Situationen Nichtfunktionale Anforderungen Beschränkungen der durch das System angebotenen Dienste und Funktionen Zeitbeschränkungen Einzuhaltende Standards Problembereichsanforderungen Anforderungen, die die Charakteristika des Problembereiches des Systems widerspiegeln (funktional oder nichtfunktional). Spiegeln nicht spezielle Bedürfnisse des Benutzers wieder. Sind meist von Fachexperten in einer anwendungssystemspezifischen Sprache ausgedrückt, so dass Softwareentwickler oft Problem haben, diese zu verstehen. Stephan Salinger 9/52

10 Beispiel funktionale Anforderungen Funktionale Benutzeranforderungen an ein Universitätsbibliothekssystem zur Bestellung von Büchern/Dokumenten von anderen Bibliotheken: Der Benutzer soll die gesamte anfängliche Menge der DB durchsuchen oder eine Teilmenge davon auswählen können. Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kann Jeder Bestellung soll ein geeigneter Bezeichner (ORDER_ID) zugeordnet werden. Stephan Salinger 10/52

11 Bedingungen an die Spezifikation funktionaler Anforderungen Vollständigkeit Alle vom Benutzer benötigten Dienste werden festgelegt Konsistenz Anforderungen enthalten keine widersprüchlichen Festlegungen Achtung: In der Praxis ist es für große, komplexe Systeme so gut wie unmöglich zu erreichen, dass Anforderungen sowohl komplett als auch konsistent sind. Stephan Salinger 11/52

12 Beispiele nichtfunktionale Anforderungen Produktanforderungen Effizienzanforderungen Leistungsanforderungen Speicherplatzanforderungen Portierbarkeitsanforderungen Benutzbarkeitsanforderungen Unternehmensanforderungen Lieferanforderungen Vorgehensanforderungen Externe Anforderungen Kompatibilitätsanforderungen Rechtliche Anforderungen Datenschutzanforderungen Sicherheitsanforderungen Stephan Salinger 12/52

13 Eigenschaften nichtfunktionaler Anforderungen Beziehen sich eher auf das System als Ganzes als auf einzelnen Funktionalitäten Sind somit oft entscheidender als einzelnen funktionale Anforderungen Nichteinhalten einer einzelnen funktionalen Anforderung macht System schlechter Ignorieren einer nichtfunktionalen Anforderung kann ganze System unbrauchbar machen Stehen oft mit anderen (funktionalen) Anforderungen im Konflikt Oft schwer zu überprüfen. Deshalb sollten Metriken für nichtfunktionale Anforderungen festgelegt werden. Stephan Salinger 13/52

14 Metriken für nichtfunktionale Anforderungen Eigenschaft Geschwindigkeit Größe Benutzerfreundlichkeit Zuverlässigkeit Stabilität Portierbarkeit Maßeinheit Ausgeführte Transaktionen/Sekunde Reaktionszeit auf Benutzereingaben oder Ereignis Bildschirmaktualisierungszeit Kilobytes Schulungsdauer Anzahl der Hilfeseiten Durchschnittliche Zeit bis zu einer Fehlfunktion Verfügbarkeit Zeit bis zum Neustart nach Fehlfunktion Anzahl der plattformabhängigen Zeilen In der Praxis ist die quantitative Festlegung von Anforderungen oft schwierig Keine Metriken Aufwand zur Verifizierung kann sehr hoch sein Deshalb enthalten Pflichtenhefte oft Darstellungen von Zielen vermischt mit Anforderungen Stephan Salinger 14/52

15 Benutzeranforderungen: Eigenschaften und Probleme Eigenschaften: Beschreibung funktionaler und nichtfunktionaler Anforderungen für den Systembenutzer (ohne detailliertes technischen Wissen/ Konzentration auf fundamentale Eigenschaften) Externes Verhalten des Systems festlegen Charakteristika des Systementwurfes so weit wie möglich vermeiden Natürliche Sprache, Formulare, einfache und intuitive Diagramme Probleme: Mangel an Genauigkeit Präzise und widerspruchsfrei Verwendung von natürlicher Sprache kann zu umfangreichen, schwer verständlichen Dokumenten führen Verwirrung bei Anforderungen Kein klares Auseinanderhalten von funktionalen Anforderungen, nichtfunktionalen Anforderung und Systemzielen. Verschmelzung von Anforderungen Verschiedene Anforderungen werden als eine einzige ausgedrückt Stephan Salinger 15/52

16 Systemanforderungen: Eigenschaften und Probleme Eigenschaften: Genauere Beschreibungen der Benutzeranforderungen Können als Basis für einen Vertrag über die Implementierung des System dienen Sollten eine komplette und widerspruchsfreie Spezifikation des gesamten Systems darstellen Startpunkt des Systementwurfes Probleme: Möglichst keine Angaben darüber, wie die Implementierung aussehen wird. Dies ist schwierig da: Anfängliche Architektur erleichtert Strukturierung der Anforderungsspezifikation Zusammenspiel mit bestehenden Systemen Probleme mit der Mehrdeutigkeit und Überflexibilität der natürlichen Sprache Stephan Salinger 16/52

17 Systemanforderungen: Notationen Notation Strukturierte natürliche Sprache Sprachen zu Entwurfsbeschreibung Graphische Notationen Mathematische Spezifikation Beschreibung Verwendung von Standardformularen oder Vorlagen, um die Spezifikation von Anforderungen auszudrücken Verwendung von einer programmiersprachenähnlichen Sprache, aber mit abstrakteren Funktionen zur Spezifikation der Anforderungen durch Definition eines Einsatzmodells des Systems. Zur Definition der funktionalen Anforderungen wird eine graphische Sprache, ergänzt durch Textvermerke, verwendet. Z.B.: SADT (Schomann und Ross, 1977) Anwendungsfallbeschreibungen (Jacobsen et al., 1993) Notationen, die auf mathematischen Konzepten aufbauen. Z.B. Zustandsmaschinen Mengen Viele Kunden verstehen formale Spezifikationen nicht und sind abgeneigt, sie als einen Vertrag über das System zu akzeptieren. Stephan Salinger 17/52

18 Systemanforderungen: Spezifikation in strukturierter Sprache Spezifikation in strukturierter natürlicher Sprache (Pseudocode): Ziele: Erzeugung einer eingeschränkten Form der natürlichen Sprache Erhalten der Ausdruckskraft und Verständlichkeit der natürlichen Sprache Sicherstellung, dass eine gewisse Einheitlichkeit erzwungen wird Einschränkung der benutzten Terminologie Mittel: Verwendung von Vorlagen Einbeziehen von aus Programmiersprachen abgeleiteten Steuerkonstrukten Verwendung von graphischen Hervorhebungen zur Unterteilung der Spezifikation Wege: Die Spezifikation kann unterschiedlich aufgebaut werden: Um die Objekte herum, die das System manipulieren Um die durch das System unterstützten Funktionen Um die durch das System verarbeiteten Ereignisse Stephan Salinger 18/52

19 Systemanforderungen: Spezifikation in strukturierter Sprache Ein Standardformular zur Spezifikation funktionaler Anforderungen sollte folgenden Informationen enthalten: Eine Beschreibung der spezifizierten Funktion oder Entität Eine Beschreibung ihrer Eingabedaten und deren Herkunft Eine Beschreibung ihrer Ausgaben und deren Ziel Ein Hinweis darauf, welche anderen Entitäten benutzt werden Bei funktionalen Methoden: Festlegung einer Vorbedingung und einer Nachbedingung Eine Beschreibung der Seiteneffekte Stephan Salinger 19/52

20 Schema eines Lastenheftes nach Balzert Kapitel Zielbestimmung Produkteinsatz Produktübersicht Produktfunktionen (Benutzeranforderungen) Produktdaten Produktleistungen Qualitätsanforderungen Ergänzungen Beschreibung Welche Ziele sollen durch den Einsatz des Produktes erreicht werden Festlegung der Anwendungsbereiche und der Zielgruppen, für die das Produkt vorgesehen ist Gibt einen meist graphischen Überblick über die Produktumgebung, z.b. durch ein Umweltdiagramm Hauptfunktionen des Produktes aus Auftraggebersicht Nennung typischer Arbeitsabläufe, die mit dem zu erstellenden Produkt durchgeführt werden sollen (Jede Funktionsanforderung ist durch eine vorangesetze Zahl und ein vorangesetzes LF (Lastenheft Funktion), eingeschlossen in Schrägstrichen (z.b. /LF 20/) zur späteren eindeutigen Referenzierung zu versehen.) Die Funktionalität kann mit Hilfe von Akteuren und Geschäftsprozessen oder mit Hilfe von Schnittstellen und Datenflüssen systematisch ermittelt werden. Grafiken können direkt oder im Anhang eingefügt werden. Langfristig zu speichernde Hauptdaten und deren voraussichtlicher Umfang aus Benutzersicht (/LDnn/) Gestellte Leistungsanforderungen an Hauptfunktionen u. Hauptdaten (z.b. Zeit und Genauigkeit) (/LLnn/) Wichtigste Qualitätsanforderungen und die jeweils geforderten Qualitätsstufen (z.b. Zuverlässigkeit, Benutzbarkeit etc.) Ergänzungen und spezielle Anforderungen (z.b. Spracheingabe erforderlich ) Stephan Salinger 20/52

21 Kapitel Vorwort Einleitung Begriffe Definition der Benutzeranforderungen Systemarchitektur Spezifikation der Systemanforderungen Systemmodelle Anhänge Index Schema eines Pflichtenhefts nach Sommerville, basierend auf IEEE-Standard Beschreibung Erwartete Leserschaft festlegen Versionsgeschichte beschreiben (Begründung für neue Version, Zusammenfassung der Änderungen) Notewendigkeit des Systems Kurz Funktionen und Zusammenarbeit mit anderen Systemen darlegen Kurz auf Übereinstimmung des Systems mit den gesamtwirtschaftliche oder strategische Ziele des Auft4raggebers eingehen Technische Fachbegriffe festlegen Darstellung der für die Benutzer bereitgestellten Dienste Darstellung der nichtfunktionalen Anforderungen Natürliche Sprache, Diagramme, für Kunden verständliche Notationen Festlegung Produkt- und Entwicklungsstandards Grober Überblick über die erwartete Systemarchitektur Wiederverwendete Komponenten kennzeichnen Genaue Beschreibung der funktionalen und nichtfunktionalen Anforderungen Definition von Schnittstellen zu anderen Systemen Festlegung von Systemmodellen, die die Beziehung zw. den Systemkomponenten und dem System und seiner Umgebung aufzeigen. Evtl. Klassen-, Datenfluss- und semantische Datenmodelle. Anwendungsspezifische Informationen. Z.B. Hardware- und Datenbankbeschreibungen. Ggf. mehrere Indizes (z.b. alphabethischer Index und Index von Diagrammen) Abnahmekriterien? Stephan Salinger 21/52

22 Softwareanforderungen Inhalt 1. Anforderungen und ihre Beschreibung (Darstellung der Dienste und Einschränkungen) Benutzeranforderungen vs. Systemanforderungen Lastenheft vs. Pflichtenheft Funktional vs. nichtfunktionale Anforderungen Beispielstruktur Lastenheft Beispielstruktur Pflichtenheft 2. Anforderungsanalyse Prozess des Herausfindens, Analysierens und Überprüfens der Dienste und Einschränkungen Stephan Salinger 22/52

23 Abläufe bei der Anforderungsanalyse Es gibt vier allgemeine, auf der obersten Ebene stattfindende Aktivitäten bei der Anforderungsanalyse: Systemdurchführbarkeitsstudie Bestimmung und Analyse der Anforderungen Spezifikation von Anforderungen und deren Dokumentation Validierung der Anforderungen Stephan Salinger 23/52

24 Abläufe bei der Anforderungsanalyse Durchführbarkeitsstudie Anforderungsbestimmung und -analyse Systemmodelle sind graphische Darstellungen, die das zu lösende Problem und das zu entwickelnde System beschreiben. Z.B.: Kontextmodelle, Verhaltensmodelle Objektmodelle Anforderungsspezifikation Anforderungsvalidierung Benutzer- und Systemanforderungen Durchführbarkeitsbericht Im weiteren liegt hier der Fokus auf der Anforderungsbestimmung Systemmodelle Pflichtenheft Stephan Salinger 24/52

25 Anforderungsbestimmung und -analyse Projektbeteiligte (stakeholder) mit direktem oder indirektem Einfluss auf die Systemanforderungen: Endbenutzer, die das System verwenden werden Technische Softwareentwickler Entwickler, die andere Systeme entwickeln oder warten Wirtschaftsmanager Experten des Anwendungsbereiches Gewerkschaftsvertreter Stephan Salinger 25/52

26 Anforderungsbestimmung und -analyse Schwierigkeiten: Projektbeteiligte wissen, abgesehen von den allgemeinsten Dingen oft nicht, was sie von dem (Computer-)System erwarten (Formulierungsschwierigkeiten, unrealistische Forderungen (z.b. bzgl. Kosten)) Projektbeteiligte verwenden bei der Formulierung implizites Wissen (ihrer eigenen Arbeit) Verschiedene Projektbeteiligte haben unterschiedliche Anforderungen und können sie auf verschiedene Weise ausdrücken. Anforderungsanalytiker müssen alle potentiellen Ursachen von Anforderungen finden und Übereinstimmungen und Konflikte herausarbeiten. Stephan Salinger 26/52

27 Anforderungsbestimmung und analyse: Ablauf Prozessbeginn Verstehen des Anwendungsbereiches Setzen von Prioritäten Pflichtenheft Anforderungsüberprüfung Anforderungsspezifikation Anforderungsammlung Konfliktlösung Klassifizierung Stephan Salinger 27/52

28 Anforderungsbestimmung und analyse: Techniken Techniken zur Anforderungsbestimmung Viewpoints Szenarien Ethnographie Strukturierte Analyse Prototypen Achtung: Es gibt keine perfekte, universell anwendbare Methode zur Anforderungsbestimmung und analyse. Man muss gewöhnlich mehrere verschiedene Methoden anwenden, um ein vollständiges Verständnis und eine vollständige Analyse entwickeln zu können. Stephan Salinger 28/52

29 Anforderungsbestimmung: Viewpoint-orientiert Verschiedenen Typen von Endbenutzern Die verschiedenen Typen haben unterschiedliche Blickwinkel (Viewpoints) auf das System Verschieden Viewpoints betrachten das Problem auf unterschiedliche Weise Perspektiven sind allerdings nicht total unabhängig (Überlappungen) Viewpoint-orientierte Methoden beachten die verschiedenen Sichtweisen und benutzen sie zur Strukturierung und Organisation sowohl des Bestimmungsprozesses als auch der Anforderungen selber Stephan Salinger 29/52

30 Anforderungsbestimmung: Viewpoint-orientiert Verschiedenen Methoden vertreten unterschiedliche Ansichten darüber, was mit einem Viewpoint gemeint ist Eine Datenquelle oder ein Datenfluß: Viewpoints sind für die Erzeugung oder Abnahme von Daten verantwortlich. Ein Darstellungsrahmen: In diesem Fall wird ein Viewpoint als eine bestimmte Art von Systemmodell angesehen. Verschiedene Entwickler könnten ein Entity- Relationship-Modell, ein Zustandsmodell usw. entwickeln. Jede Methode der Analyse deckt verschiedenen Dinge über das analysierte System auf. Ein Empfänger von Diensten: In diesem Fall liegen die Viewpoints außerhalb des Systems und empfangen Dienste vom System. Viewpoints können Daten für diese Dienste oder Steuersignale bereitstellen. Stephan Salinger 30/52

31 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen Vorteile des dienstorientierten Rahmen zur Anforderungsbestimmung und analyse: Natürliche Art der Strukturierung der Anforderungsbestimmung, da die Viewpoints außerhalb des Systems liegen Viewpointbestimmung ist einfach. Sie müssen auf eine bestimmte Weise mit dem System zusammenarbeiten. Stephan Salinger 31/52

32 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Beispiel für dienstorientierten Rahmen zur Anforderungsbestimmung und analyse: VORD- Methode (VORD Viewpoint-Oriented Requirements Definition; Kotonya und Sommerville) Viewpoint- Bestimmung Viewpoint- Strukturierung Viewpoint- Dokumentation Viewpoint- Systemzuordung Auffinden von VP für den Emp fang von SD, Bestim mung der jedem VP bereitgestellten SD Gruppierung verwandter VP, Hierarchisierung Verfeinerung der Beschreibung der gefundenen VP und SD Bestimmungder Objekte des objektorientierten Entwurfesunter Benutzung der Dienstinformationen Stephan Salinger VP: Viewpoint/SD: Systemdienst 32/52

33 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Viewpoint- und Dienstinformationen werden in VORD mit Hilfe von Standardformularen gesammelt: Viewpoint-Formular Bezeichnung Der Viewpoint-Name Beispiel Geldautomatensystem Kunde Attribute Ereignisse Dienste Attribute mit Viewpoint- Informationen Ein Verweis auf eine Menge von Ereignisszenarien, die die Reaktion des Systems auf Viewpoint-Ereignisse beschreiben Der Verweis auf einen Satz von Dienstbeschreibungen Kontonummer PIN Transaktion beginnen Dienst auswählen Transaktion abbrechen Transaktion beenden Bargeld abheben Kontostandabfrage Unter- Viewpoints Der Name von Unter- Viewpoints Kontoinhaber Fremdkunde Stephan Salinger 33/52

34 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Dienst-Formular Bezeichnung Begründung Spezifikation Viewpoints Nichtfunktionale Anforderungen Anbieter Der Dienstname Grund zur Bereitstellung des Dienstes Verweis auf eine Liste von Dienstspezifikationen. Diese können in verschiedenen Notationen dargestellt werden Liste der Namen von Viewpoints, die den Dienst in Anspruch nehmen Verweis auf einen Satz nichtfunktionaler Anforderungen, die den Dienst einschränken Verweis auf eine Liste von Systemobjekten, die den Dienst bereitstellen Beispiel Geldautomatensystem Bargeld abheben Zur Verbesserung des Kundendienstes und zur Verringerung des Schriftverkehrs Benutzer wählen diesen Dienst, indem sie den Barabhebungsknopf drücken. Dann geben sie den benötigten Betrag ein und bestätigen ihn. Wenn es der Bargeldbestand erlaubt, wird der Betrag ausgezahlt. Kunde Bestätigten Bargeldbetrag innerhalb einer Minute auszahlen Wird später ausgefüllt Stephan Salinger 34/52

35 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Erster Schritt die Bestimmung möglicher Viewpoints ist die schwierigste Etappe Lösungsmöglichkeit: Brainstorming bei Treffen aller Projektbeteiligten zur Ermittlung möglicher Potentieller Viewpoints Systemdienste Dateneingaben Nichtfunktionaler Anforderungen Steuerereignisse Ausnahmen Ergebnis Blasendiagramm Hier ist es noch nicht Angebracht, dem Diagramm eine Struktur zu verleihen. Informationsquellen: Dokumente über das Gesamtziel des Systems Wissen der SW-Entwickler aus früheren Projekten Erfahrungen des Kunden Stephan Salinger 35/52

36 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Beispiel Blasendiagramm zur Erkennung möglicher Viewpoints: Geldautomatensystem Kontostand abfragen Gestohlene Karte Systemkosten Transaktionen abfragen Manager Kontoauszug anfordern Drucker Fremdkunde Überweisung Barabhebung Sicherheit Kundendatenbank Transaktionsprotokoll Schecks anfordern Kassierer Upgrade der Steuerungssoftware Softwaregröße Zuverlässigkeit Hardwarewartung Ferndiagnose Kontoinhaber Kartenüberprüfung Weiterreichen von Nachrichten Stephan Salinger 36/52

37 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Nachfolgender Schritt: Zuordnung der Dienste zu den Viewpoints Dienstliste Kontoinhaber Bargeld abheben Kontostand abfragen Schecks anfordern Nachricht senden Transaktionsliste Kontoauszug anfordern Kontoauszug anfordern Dienstliste Fremdkunde Bargeld abheben Kontostand abfragen Dienstliste Kassierer Fehlerdiagnose anstellen Geld nachfüllen Papier nachfüllen Nachricht senden Stephan Salinger 37/52

38 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Viewpoints nehmen nicht nur Dienste entgegen, sondern stellen auch Eingaben für diese Dienste bereit. Außerdem liefern Viewpoints Steuerungsinformationen, um zu bestimmen, ob und wann Dienste geleistet werden. Daten und Steuerungsinformationen zu einem VP werden in der frühen Phase des Prozesses durch ihren Namen bestimmt. Z.B. für den Kontoinhaber: Steuerungseingaben Transaktion beginnen Transaktion abbrechen Transaktion beenden Dienst wählen Kartendetails PIN Benötigter Geldbetrag Nachricht Dateneingaben Stephan Salinger 38/52

39 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Die Viewpoint-Informationen werden dazu benutzt, Viewpoint-Formulare auszufüllen Viewpoints in einer Vererbungshierarchie anzuordnen Aufzeigen von Gemeinsamkeiten von Viewpoints Wiederverwendung von Viewpoint-Informationen Dienste Kontostand abfragen Bargeld abheben Alle Viewpoints Kunde Bankpersonal Dienste Schecks anfordern Nachrichten senden Transaktionsliste Kontoauszug anfordern Geld überweisen Kontoinhaber Fremdkunde Kassierer Manager Entwickler Stephan Salinger 39/52

40 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD Die Schritte des Prozesses dienen dem Auffinden detaillierter Informationen über die bereitgestellten Dienste die benötigten Daten und deren Steuerung Anforderungen werden durch die Projektbeteiligten bestimmt, die mit jedem Viewpoint verbunden sind. Viewpoint- und Dienstformulare sowie Ereignisszenarien werden für alle bestimmten Viewpoints und Dienste aufgestellt. Da hierbei eine große Menge von Informationen erzeugt wird, ist VORD wie andere Analysemethoden in der Praxis nur mit der Unterstützung von CASE-Werkzeugen Stephan Salinger 40/52

41 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD/Szenarien Szenarios Bei Viewpoints/VORD Ereignisszenarios: Dokumentation der Reaktion des Systems auf Viewpoint-Ereignisse Allgemein: Beschreibung der Rolle eines Subjektes im Zusammenhang mit einem Softwaresystem Szenarios eignen sich insbesondere zum Hinzufügen von Details zu einer groben Anforderungsbeschreibung Zusammenarbeit von Anforderungsentwicklern mit Projektbeteiligten Stephan Salinger 41/52

42 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD/Szenarien Im Allgemeinen sollte ein Szenario folgendes enthalten Systemzustandsbeschreibung zu Beginn des Szenarios Beschreibung des normalen Ereignisverlaufes im Szenario Beschreibung, was falsch laufen kann und wie damit umgegangen wird Informationen über andere Aufgaben, die zur selben Zeit ablaufen können Beschreibung des Systemzustandes nach dem Abschluss des Szenarios Stephan Salinger 42/52

43 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD/Szenarien Ereignisszenario: Beginn einer Transaktion Karte eingeführt Gültige Karte Steuerungsinformationen Karte PIN Durch einen Viewpoint gelieferte Daten PIN anfordern Zeit abgelaufen Karte Ausgeben Ungültige Karte Karte Ausgeben Gestohlene Karte Karte Ausgeben Konto- Nummer PIN Benutzer überprüfen Ungültige PIN PIN nochmals eingeben Ungültige PIN Karte ausgeben Konto- Nummer Benutzer OK Dienst auswählen Daten Name des nächsten erwarteten Ereignisses Ausnahmen und Fehler. Gibt es mehrere mögliche Ausnahmen, werden diese in einem Kasten dargestellt Stephan Salinger 43/52

44 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: VORD/Szenarien Zusammenfassung Konventionen für die Darstellung von Ereignisszenarien In Ellipsen werden durch einen Viewpoint oder zu einem Viewpoint gelieferte Daten dargestellt Steuerungsinformationen erreichen und verlassen jeden Kasten von und nach oben Daten verlassen jeden Kasten nach rechts. Ausnahmen und Fehler werden unterhalb des Kastens dargestellt. Gibt es mehrere mögliche Ausnahmen, werden diese in einem Kasten dargestellt. Der Name des nächsten erwarteten Ereignisses nach dem Abschluss des Szenarios wird in einem schattierten Kasten dargestellt. Jede Ausnahme kann durch die Erstellung eines eigenen Diagramms zur Daten- und Steuerungsanalyse genauer definiert werden. Stephan Salinger 44/52

45 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: Anwendungsfälle Anwendungsfälle (use cases) sind eine szenariobasierte Technik, die erstmals in der Objectory- Methode (Jacobsen et. al., 1993) Verwendung fand. Merkmal der UML-Notation zur Beschreibung objektorientierter Systemmodelle use cases werden im deutschen oft auch als Geschäftsprozesse übersetzt: Balzert: Ein Geschäftsprozess (use case) auch Arbeitsablauf genannt besteht aus mehreren zusammenhängenden Aufgaben, die von einem Akteur durchgeführt werden, um ein Ziel zu erreichen bzw. ein Gewünschtes Ergebnis zu erstellen. Genau genommen sollte unterschieden werden: use case: bzgl. UML/Objektorientierung und Benutzerkommunikation mit Softwaresystem Geschäftsprozess: Unternehmensprozess oder Arbeitsablauf der mit Hilfe einer Software durchgeführt wird Stephan Salinger 45/52

46 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: Anwendungsfälle Ein Geschäftsprozess wird formal, semiformal (use case templates) oder informal (umgangssprachlich) beschrieben. Beispiel für Grundlagen der Notation von Geschäftsprozessdiagrammen: Ausleihen eines Buche (Akteur als Strichmännchen/Interaktionen als bezeichnete Ellipsen): Ausleihdienste Die Menge der Anwendungsfälle repräsentiert alle möglichen Interaktionen, die in den Systemanforderungen festgehalten sind. Stephan Salinger 46/52

47 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: Anwendungsfälle Achtung: Es gibt unterschiedliche Auffassungen darüber, ob ein Anwendungsfall selbst ein Szenario ist oder ob ein Anwendungsfall eine Reihe von Szenarien einschließt, die im Anwendungsfall eigene Handlungsstränge verfolgen. Im allgemeinen können Anwendungsfalldiagramme in UML aus folgenden Elementen bestehen: Akteure Namen von Geschäftsprozessen Generalisierung zw. Akteuren Assoziationen (zw. Akteuren und Geschäftsprozessen) Strukturierungen von Geschäftsprozessen include-beziehung extend-beziehung Generalisierungen Stephan Salinger 47/52

48 Anforderungsbestimmung: Viewpoint-orientiert: dienstorientierter Rahmen: Geschäftsprozessdiagramm Geschäftsprozessdiagramm UML (aus Balzert) Ggf. um Sequenzdiagramme etc. erweitern. Stephan Salinger 48/52

49 Anforderungsbestimmung: Validierung Die Validierung soll zeigen, dass die Anforderungen wirklich das System definieren, das der Kunde erwartet. Ziel: Vermeidung von evtl. immensen Nachbereitungskosten durch falsche Anforderungen Verschieden Arten von Prüfungen Gültigkeitsprüfungen Gültigkeit des (zwangsläufigen) Kompromisses zw. Anforderungen unterschiedlicher Benutzer(gruppen) Konsistenzprüfungen Keine sich widersprechenden Anforderungen, Beschränkungen oder Beschreibungen für die selbe Systemfunktion Vollständigkeitsprüfungen Enthaltensein von allen durch den Systembenutzer erwarteten Funktionen und Beschreibungen Realisierbarkeitsprüfungen Prüfung der Anforderungen gegen vorhandene Technologie, Budget und Zeitplan. Verifizierbarkeitsprüfungen Die Anforderungen sollten so definiert sein, dass ihre Erfüllung (durch Tests) verifizierbar wird. Stephan Salinger 49/52

50 Anforderungsbestimmung: Validierung Techniken zur Anforderungsvalidierung: Anforderungsreviews Analyse durch ein Team von Gutachtern Prototypen Den Endbenutzern und Kunden wird ein funktionsfähiges Modell des Systems zur Verfügung gestellt Testfallerzeugung Anforderungen sollten Idealerweise gestestet werden können. Werden die Tests für die Anforderungen als ein Teil des Validierungsprozesses erarbeitet, eröffnet dies oft Probleme bei den Anforderungen. Automatische Konsistenzanalyse Bei der Formulierung von Anforderungen als Systemmodell in einer strukturierten oder formalen Notation (durch CASE- Werkzeuge). Stephan Salinger 50/52

51 Anforderungsbestimmung: Validierung: Anforderungs- Reviews Anforderungs-Review Von Hand durchgeführter Prozess Beteiligte von Kunden- sowie von Anbieterseite Überprüfung des Pflichtenheftes Kann auf die selbe Weise wie Programminspektionen durchgeführt werden Entwicklungsteam führt Kunden durch die Systemanforderungen. Das Review-Team untersucht jede Anforderung auf Konsistenz Verifizierbarkeit Verständlichkeit Nachvollziehbarkeit Anpassungsfähigkeit Stephan Salinger 51/52

52 Danke Stephan Salinger 52/52