Abläufe bei der Anforderungsanalyse. Grundlagen des Software Engineerings

Transkript

1 Abläufe bei der Anforderungsanalyse Grundlagen des Software Engineerings

2 Lernziele } Die prinzipiellen Aufgaben bei der Anforderungsanalyse und deren Zusammenhänge verstehen } Mit einigen Techniken der Anforderungsbestimmung und Anforderungsanalyse vertraut sein } Die Wichtigkeit der Validierung von Anforderungen und die Durchführung von Anforderungs-Reviews in diesem Prozess verstehen } Wissen, warum das Anforderungsmanagement notwendig ist und wie es andere Aufgaben der Anforderungsanalyse unterstützt Folie 56

3 Gesamtablaufmodell Folie 57

4 Das Spiralmodell der Anforderungsanalyse Folie 58

5 Wiederholung: Struktur eines Pflichtenhefts Folie 59

6 Durchführbarkeitsstudien } Muss folgende Fragen 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? } Phasen: } Informationsbewertung (Infos zur Beantwortung der Fragen) } Informationssammlung } Erstellen eines Berichts } Zeitrahmen: } Zwei bis drei Wochen Folie 60

7 Fragen der Informationssammlung, z.b. } Wie würde es die Organisation verkraften, wenn das System nicht realisiert würde? } Wie lauten die Probleme bei den aktuellen Abläufen und wie würde ein neues System diese Probleme mindern? } Welchen direkten Beitrag wird das System zur Verwirklichung der wirtschaftlichen Ziele leisten? } Können Informationen zwischen den Systemen der Organisation übertragen werden? } Benötigt das System Technologie, die vorher in der Organisation noch nicht eingesetzt wurde? } Was muss und was muss nicht durch das System unterstützt werden? Folie 61

8 Informationsquellen der Durchführbarkeitsstudie, z.b. } Leiter der Abteilungen, in denen das System zu Einsatz kommt } Softwareentwickler } Technologieexperten } Endbenutzer des Systems Folie 62

9 Anforderungsbestimmung und -analyse } Zusammenarbeit von Softwareentwicklern, Kunden und Systembenutzern } Bestimmung von } Vom System zu leistenden Diensten } Erforderlicher Leistung des Systems } Hartwarebeschränkungen... } Probleme: } Projektbeteiligte kennen eigene Erwartungen an das System nicht } Projektbeteiligte stellen unrealistische Forderungen } Projektbeteiligte drücken sich mit eigenen Worten aus (implizites Wissen wird vorausgesetzt) Folie 63

10 Anforderungsbestimmungs- und -analyseprozess (1) } Anforderungssammlung } Sammlung von Problembereichsanforderungen und Dokumentationen } Klassifizierung und Organisation der Anforderungen } Gruppierung verwandter Anforderungen } Priorisierung und Verhandlung von Anforderungen } Finden und Lösen von Konflikten durch Verhandlungen } Dokumentation der Anforderungen } Dokumente zu formellen und informellen Anforderungen Folie 64

11 Anforderungsbestimmungs- und -analyseprozess (2) Folie 65

12 Anforderungssammlung } Prozess des Sammelns von Informationen über vorgeschlagene und vorhandene Systeme und des Herausarbeitens von: } Benutzeranforderungen } Systemanforderungen } Informationsquellen: } Dokumentationen } Projektbeteiligte des Systems } Spezifikationen ähnlicher Systeme } Techniken } Interviews, Szenarien, etwaige Prototypen Folie 66

13 Projektbeteiligte: Beispiel Geldautomat } Aktueller Bankkunde } Vertreter anderer Banken (CashGroup und Co.) } Manager der Bankzweigstelle } Schalterpersonal } Datenbankadministratoren } Sicherheitsbeauftragte der Bank } Marketingabteilung der Bank } Hard- und Softwareentwickler } Nationale Bankaufsichtsbehörde Folie 67

14 Viewpoint-orientierte Anforderungsanalys } Viewpoints zur Klassifizierung von Projektbeteiligten und anderen Anforderungsquellen } Interagierende Viewpoints } Personen oder Systeme die direkt mit dem System zusammenarbeiten } Indirekte Viewpoints } Projektbeteiligte ohne direkte Interaktion, die Anforderungen aber beeinflussen } Bereichs-Viewpoints } Eigenschaften eines Anwendungsbereichs und Beschränkungen Folie 68

15 Spezifischere Viewpoint-Typen } Anbieter von Systemdiensten und Empfänger von Diensten des Systems } Systeme, die unmittelbar mit dem angegebenen System zusammenarbeiten sollen } Für das System geltende Vorschriften und Standards } Viewpoints aus Entwicklungssicht } Spiegeln Anforderungen von Personen, die das System entwickeln, verwalten und warten müssen, wider } Marketing und andere Viewpoints, die Anforderungen erstellen, welche Produkteigenschaften von Kunden erwartet werden und wie das System das äußere Erscheinungsbild der Organisation widerspiegelt. Folie 69

16 Beispiel: Viewpoints in LIBSYS Folie 70

17 Interviews } Geschlossen vs. Offen } Probleme: } Spezifische Terminologie } Selbstverständlichkeiten } Theoretische vs. reale Entscheidungsprozesse im Unternehmen Folie 71

18 Szenarien } Oftmals einfacher Bezug zu realen Beispielen herzustellen als abstrakte Beschreibungen zu geben. } Szenarien sollten Folgendes enthalten: } Eine Beschreibung, was das System und die Benutzer erwartet, wenn das Szenario beginnt } Eine Beschreibung des normalen Ereignisablaufs im Szenario } Eine Beschreibung, was falsch laufen kann und wie damit umgegangen wird } Informationen über andere Aufgaben, die zur selben Zeit ablaufen können } Eine Beschreibung des Systems, wenn das Szenario endet Folie 72

19 Beispiel: Szenario für den Artikeldownload in LIBSYS Folie 73

20 Anwendungsfälle (use cases) } Grundlegendes Merkmal der UML-Notation zur Beschreibung objektorientierter Systemmodelle } Anwendungsfall bestimmt Interaktion sowie beteiligte Personen } Notation im Buch: } Person: Strichmännchen } Aktion: Oval } NICHT der UML-Standard! Folie 74

21 Beispiel: Anwendungsfälle für das Bibliothekssystem Folie 75

22 Sequenzdiagramm für den Artikeldruck Folie 76

23 Ethnografie } Softwaresysteme sind nicht isoliert sondern werden in einem gesellschaftlichen und wirtschaftlichen Umfeld eingesetzt. } Ethnographie ist beobachtende Technik, die zum Verständnis gesellschaftlicher und wirtschaftlicher Anforderungen eingesetzt wird. } Ergänzung zur Anwendungsfallanalyse Folie 77

24 Ethnografie besonders geeignet für... }... Anforderungen, die sich daraus ergeben, wie Menschen wirklich arbeiten }... und nicht, wie sie Arbeiten sollten (Vorgehensdefinition) }...Anforderungen, die sich aus der Zusammenarbeit mit anderen Menschen und dem Wissen über deren Aufgaben ergeben Folie 78

25 Validierung von Anforderungen } Überschneidung mit der Analyse da Probleme bei den Anforderungen aufgedeckt werden sollen } WICHTIG } Fehlerbehebung zur Entwicklungszeit oder gar zur Laufzeit ist teuer! } Grund: zu späte Veränderungen an den Anforderungen implizieren } Anpassung des Systementwurfs } Anpassungen der Systemimplementierung } Neue Systemtests Folie 79

26 Prüfung der Anforderungen im Pflichtenheft } Gültigkeitsprüfung } Entdecken von zusätzlichen oder anderen benötigten Funktionen } Konsistenzprüfung } Keine widersprüchlichen Beschränkungen oder unterschiedliche Beschreibungen für dieselbe Systemfunktion } Vollständigkeitsprüfung } Sind alle durch den Systembenutzer erwarteten Funktionen und Einschränkungen definiert? } Realisierbarkeitsprüfung } Ist das System technologisch, finanziell und zeitlich umsetzbar? } Verifizierbarkeitsprüfung } Sind Systemanforderungen nachprüfbar? Folie 80

27 Techniken zur Anforderungsvalidierung } Anforderungs-Reviews } Systematische Analyse der Anforderungen durch Gutachter } Prototypen } Testen an einem funktionsfähigen Modell } Testfallerzeugung Folie 81

28 Anforderungs-Reviews } Informell: } Über das System und die definierten Anforderungen reden } Formell: } Verifizierbarkeitsprüfung } Kann Anforderung überprüft werden? } Verständlichkeit } Verstehen Auftraggeber und Endbenutzer Anforderungen richtig? } Nachvollziehbarkeit } Ist der Ursprung der Anforderung klar dargelegt? } Anpassungsfähigkeit } Ist die Anforderung anpassungsfähig? } Konflikte, Widersprüche, Fehler, Versäumnisse à Review- Bericht Folie 82

29 Entwicklung von Anforderungen Folie 83

30 Anforderungsmanagement } Prozess des Verstehens und Kontrollierens von Veränderungen der Systemanforderungen } Notwendigkeit resultiert aus: } Notwendige Veränderung der Priorisierung unterschiedlicher Benutzeranforderungen } Beheben von Konflikten, die aus wirtschaftlichen und finanziellen Randbedingungen bei der Erstentwicklung resultieren } Reaktion auf wirtschaftliche und technische Änderungen } Dauerhafte vs. veränderliche Anforderungen Folie 84

31 Planung des Anforderungsmanagement } Anforderungsidentifikation } Vergabe von IDs à eindeutig identifizierbar, Nachvollziehbarkeit möglich } Ablauf des Änderungsmanagements } Menge von Aufgaben zur Auswirkungs- und Kostenabschätzung bei Änderungen } Richtlinien zur Nachvollziehbarkeit } Definieren Verbindungen zwischen Anforderungen und zwischen Anforderungen und Systementwurf } Unterstützung durch CASE-Werkzeuge } Spreadsheets, etc. Folie 85

32 Klassifizierung veränderlicher Anforderungen Folie 86

33 Verwaltbare Rückverfolgbarkeitsinformationen } Informationen zur Entwurfsnachvollziehbarkeit } Verbindungen zwischen Anforderungen und Projektbeteiligten } Informationen zur Anforderungsverfolgung } Verknüpfen Anforderungen mit dem Pflichtenheft } Informationen zur Entwurfsverfolgung } Verknüpfen Anforderungen mit den Entwurfsmodulen, in denen sie implementiert wurden Folie 87

34 Beispiel einer Nachvollziehbarkeitsmatrix Folie 88

35 Anforderungsänderungsmanagement Folie 89

36 Wochenaufgabe } Überarbeiten Sie Ihr Pflichtenheft. Benutzen Sie die Viewproint-Methode zur Strukturierung von Benutzerund Systemanforderungen. Ergänzen Sie die Anforderungen gegebenenfalls um Use-Case-Diagramme und Sequenzdiagramme. Verwenden Sie hierbei den UML1.4 oder den UML2-Standard } mit dem überarbeiteten Pflichtenheft bis kommenden Mittwoch an Hagen.Hoepfner@uni-weimar.de Folie 90