Software Engineering 4) Definitionsphase und Requirements Engineering

Software Engineering 4) Definitionsphase und Requirements Engineering Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang WiBac 4 (Stand: 15.03.2014), Hochschule Augsburg, 2014

Gliederung 1. Überblick Definitionsphase 2. Pflichtenheft 3. Requirements Engineering 1. Anforderungen 2. Erhebung von Anforderungen 3. Anforderungsanalyse Notationen im Überblick 4. Validation von Anforderungen 5. Anforderungsmanagement 2

1. Überblick Definitionsphase Grundsätzliche Vorgehensweise Definieren der (Produkt-) Anforderungen Modellierung der fachlichen Lösung Anforderungsmanagement vieler Anforderungen iterativ Was ist eine Anforderung? Eine Anforderung spezifiziert die qualitativen und quantitativen Eigenschaften eines Produkts aus Sicht des Auftraggebers Eine Anforderung muss eindeutig und testbar sein Anforderungen sind die Grundlage für die Systemarchitektur 3

1. Überblick Definitionsphase Aufgabe: Requirements Engineering (Systemanalyse, Anforderungsanalyse) Anforderungen ermitteln Anforderungen analysieren Anforderungen beschreiben Anforderungen als fachliche Lösung modellieren Optional: Anforderungen animieren, simulieren, ausführen Anforderung verabschieden Woher kommen die Anforderungen? Auftraggeber Fachabteilung Benutzer oder Repräsentanten der Endbenutzer Marketingabteilung 4

1. Überblick Definitionsphase Requirements Engineering Prozess Input: Anwenderwissen, Dokumentation, Vorschriften,... Anf. ermitteln Anf. analysieren Anf. dokumentieren Anf. prüfen Output: Pflichtenheft 5

1. Überblick Definitionsphase Beteiligte Auftraggeber Projektleiter und... Schriftliches Ergebnis: Pflichtenheft (Balzert, SE, S.99) 6

2. Pflichtenheft Enthält alle fachlichen Anforderungen, die das SW-Produkt aus Sicht des Auftraggebers enthalten muss Beschreibung des WAS nicht des WIE Ist Vertragsbestandteil = Lieferumfang Gleiche Gliederung wie Lastenheft Unterschiede Lastenheft - Pflichtenheft Lastenheft: Problemspezifikation Sicht des Kunden für den SW-Produzent Pflichtenheft: Anforderungsspezifikation Sicht des SW-Produzent für den Kunden Input 7

2. Pflichtenheft Benutzer Pflichtenheft Anwendungsspezialist / Systemkunden Anforderungen festlegen Überprüfen ob Anforderung Erwartungen entspricht Anforderungsänderungen Projektmanager Erstellen des Angebots Planung des SW-Entwicklungsprozesses SW-Entwickler Aufgrund Anforderungen verstehen was für ein System entwickelt werden soll Systemtester Benutzung der Anforderungen für Validierungstests Wartungspersonal Systemintegration, Wartung, Pflege 8

3. Requirements Engineering 3.1 Anforderungen Inhalt einer Anforderung Fachlicher Inhalt Zusätzlicher Inhalt Die Art des Systems Verwendete Normen und Standards Die Kritikalität des Systems Systemumfang Komplexität der Systemabläufe Beobachtbarkeit der Arbeitsschritte Art der Anforderung Erfahrung im Fachgebiet Detaillierungsgrad der Anforderungen 9

3.1 Anforderungen Anforderungsarten Funktionale Anforderung Beschreibung Dienste die das System leisten soll Aktionen die das System selbstständig ausführen soll Oder allgemeine funktionale Vereinbarungen und Einschränkungen Beispiel: Sende Fehlermeldung XYZ zum Nachbarssystem wenn Ereignis ABC eingetreten ist Lese Datei XYZ in den Hauptspeicher ein 10

3.1 Anforderungen Anforderungsarten Nicht-funktionale Anforderung Beschreibung Technische Anforderungen, Anforderungen an die zu verarbeitenden Informationen, Qualitätsanforderungen... Beispiel: Eingabefelder die Pflicht für den Benutzer sind sollen mit einem Sternchen markiert werden Der Algorithmus XYZ muss in 2 Sec ausführbar sein 11

3.1 Anforderungen 12

3.1 Anforderungen Anforderungsarten Problembereichsanforderung Beschreibung Anforderungen die sich aus dem Anwendungsbereich ergeben Spezielle Bedürfnisse von Systembenutzern Beispiel: Es sollte eine Standardbenutzerschnittstelle zu allen beteiligten Datenbanken geben, die auf dem Z39.50-Standard basiert 13

3.1 Anforderungen Anforderungsarten Benutzeranforderung Beschreibung Anforderungen die das externe Verhalten des Systems betreffen (Ein-, Ausgaben) Anforderungen sollen verständlich für Systembenutzer geschrieben werden Beispiel: Es soll ein Report XYZ ausgedruckt werden, wenn der Button Drucken vom Benutzer gewählt wird 14

3.1 Anforderungen Anforderungsarten Systemanforderung Beschreibung Anforderungen die als genauere Beschreibung der Benutzeranforderungen dienen Beschreiben wie die Benutzeranforderungen umgesetzt werden sollen (nicht zu Verwechseln mit wie es implementiert werden soll!) Beispiel: Das Datenaustauschformat für die zu übertragende Datei der Benutzeranforderung A soll XML sein Das System soll eine Client-Server Architektur besitzen 15

3.1 Anforderungen Qualitätsmerkmale für Anforderungen Vollständigkeit Korrektheit Klassifizierbarkeit Konsistenz Prüfbar Eindeutigkeit Verständlichkeit Aktualität Realisierbarkeit Notwendigkeit Verfolgbarkeit Bewertbarkeit Redundanzfrei (nach Rupp et al. Requirment Engineering und Management, S. 21, 2004) 16

3.1 Anforderungen Sprache bei Anforderungen Natürlich sprachliche Anforderungen Methoden Standardformulare Vorlagen Beispiele Word/Excel Vorlagen Probleme Vorlagen oft zu wenig Strukturiert Mangel an Genauigkeit Verwirrung bei Anforderungen Verschmelzung von Anforderungen 17

3.1 Anforderungen Sprache bei Anforderungen Natürlich sprachliche Anforderungen Vollständige Schablone mit Bedingungen Wann? Unter welcher Bedingung? MUSS SOLL KANN DAS SYSTEM <wem> DIE MÖGLICHKEIT BIETEN FÄHIG SEIN <Objekt & Ergänzung des Objekts> <Prozesswort> (Rupp, RE, S.492) Beispiel: Das System A muss dem Administrator die Möglichkeit bieten, eine Fehlermeldung auf dem Netzwerkdrucker zu drucken 18

3.1 Anforderungen Sprache bei Anforderungen Anforderungen in strukturierter Sprache Methode Ähnlich wie Programmiersprache Definition eines Befehlssatzes Beispiele PDLs (engl. Program Description Languages) Eigenkreationen Pseudocode Probleme Befehlssatz nicht ausreichend / genau genug Nur für SW-Entwickler verständlich Anforderungen können für einen Entwurf gehalten werden 19

3.1 Anforderungen Sprache bei Anforderungen Anforderungen in graphischer Notation Methode Graphische Sprache Ergänzt durch Kommentare und Anwendungsfallbeschreibungen Beispiele SA (Structured Analysis) UML: Use-Case Diagramm Probleme Manchmal sagen Worte mehr als Bilder Kommentare werden oft zu spärlich eingesetzt Nur für SW-Designer/SW-Entwickler verständlich 20

3.1 Anforderungen Probleme bei der Anforderungsanalyse Unklare Zielvorstellungen Hohe Komplexität Sprachbarrieren Veränderliche Anforderungen Schlechte Qualität der Anforderungen Beschreibung unnötiger Merkmale Ungenaue Planung und Verfolgung des Projekts 21

3.2 Erhebung von Anforderungen Einige Ermittlungstechniken Kreativitätstechniken Brainstorming Ereignisse sammeln Methode 6-3-5 6 Teilnehmer entwickeln je 3 Ideen und geben diese auf je einem Kärtchen dem jeweiligen Nachbarn, der diese dann kommentiert. Karten weitergeben bis jeder Teilnehmer jede Karte besessen hat (5-mal) Beobachtungstechniken Feldbeobachtung Systemanalytiker beobachtet die Arbeitsabläufe von Stakeholdern während ihrer täglichen Arbeit Apprenticing ( in die Lehre gehen ) Systemanalytiker erlernt die Arbeitsabläufe der Stakeholder unter deren Anleitung 22

3.2 Erhebung von Anforderungen Einige Ermittlungstechniken Befragungstechniken Fragebogen Multiple-Choice Fragen, offene Fragen an Stakeholder Interview Systemanalytiker stellt Stakeholder mündliche Fragen On-Site Customer Ein Stakeholder ist als Vertreter beim SW-Entwickler vor Ort Vergangenheitsorientiert Techniken Systemarchäologie Analoge existierende Systeme und die dazugehörigen Dokumente werden beobachtet bzw. gelesen Reuse Anforderungen eines ähnlichen Systems werden wiederverwendet und abgeändert 23

3.2 Erhebung von Anforderungen Anwendbarkeit von Ermittlungstechniken (Rupp et al., RE, S.84) 24

3.3 Anforderungsanalyse Notationen im Überblick Use-Case Diagramm (Anwendungsfalldiagramm) UML-Diagrammtyp (engl. Unified Modelling Language) Eine Use-Case Diagramm eines Systems besteht aus Systemrahmen: Systemgrenzen Akteuren: Personen, Fremdsysteme Assoziationen: Wer tut was Use-Cases: Funktionen Verfeinerung durch andere Diagrammtypen aus UML 25

3.3 Anforderungsanalyse Notationen im Überblick Use-Case Diagramm Notationselemente Akteur Assoziation Use-Case (Beschreibung: Hauptwort + Verb!) Systemgrenze Wichtig: Alles wird beschriftet! 26

3.3 Anforderungsanalyse Notationen im Überblick Use-Case Diagramm Beispiel 27

3.3 Anforderungsanalyse Notationen im Überblick Use- Case Diagramm Beschreibung eines Use-Cases Use Case: Partner suchen 28

3.3 Anforderungsanalyse Notationen im Überblick Use-Case Diagramm Vorteile Möglichkeit zur Abbildung komplexer Systeme Leicht erlernbar Funktionale Anforderungen aus Sicht des Anwenders gut darstellbar Übersichtlichkeit durch Top-Down Vorgehen Durch Beschreibungen für natürliche Sprache geeignet Gut geeignet für OO SW-Entwicklung Nachteile Zeitliche Reihenfolge der Ereignisse nicht festgelegt Schwer lesbar für Nicht-Informatiker Nicht-funktionale Anforderungen nicht darstellbar 29

3.3 Anforderungsanalyse Notationen im Überblick (J.D. Schulz: Requirements-based Unified Modeling Language, A Borland White Paper, 2003) 30

3.4 Validation von Anforderungen Ziele guter Anforderungen Syntaktisch Verfolgbarkeit, Redundanzfreiheit, gute Struktur, angemessener Umfang, Eindeutigkeit, Notwendigkeit, rechtliche Verbindlichkeit Semantisch (inhaltlich fachliche Aspekte) Korrektheit, Gültigkeit, Vollständigkeit Weiterverwendung Realisierbarkeit, Bewertbarkeit, Verständlichkeit 33

3.4 Validation von Anforderungen Prüfung von Anforderungen Ziele Qualitätskriterien für die Anforderung erfüllen Aufdecken von Fehlern und Schwächen Fehlende Informationen (Lücken), Widersprüche, Redundanzen, Fehlerhaftes Systemverhalten Vorgehen Zeitpunkt: Nach Definition, vor Implementation Prüfer identifizieren Prüftechnik festlegen Prüfung durchführen 34

3.4 Validation von Anforderungen Prüfung von Anforderungen Potentielle Prüfer (Rupp et al., RE, S.293) 35

3.4 Validation von Anforderungen Prüftechniken Stellungnahmen von Stakeholdern Prototyp/Simulationsmodell Verhalten des Prototypen testen Analysemodell z.b. Mengengerüste für Daten aufstellen Reviews, Inspektion, Walkthrough Gemeinsames Verständnis aller Beteiligten suchen Manchmal: Kickoff-, Follow-up- und Exit-Meetings Sprachliche Schablonen prüfen Abnahmekriterien aufstellen und prüfen 36

3.4 Validation von Anforderungen Beispiel für Abnahmekriterien Aufbau von Entscheidungstabellen Abnahmekriterium AN3 Nutzer Kunde Neue Daten Alter: [0-17] nein Fehler auf-getreten semantisch syntaktisch n.a. - A1: Fehlermeldung Keine passenden Partner vorhanden X - - - Abnahmekriterium Nr Ergebnis Datum/ Uhrzeit Tester AN3: Fehlermeldung zu A1 OK 01.01.08 Schz 37

3.5Anforderungsmanagement Gruppierung von Anforderungen...Ordung ist das halbe Leben......Wer suchet der findet... Nach Anforderungsart Nach Merkmalen Beispiele: Zuverlässigkeit, Benutzbarkeit, Effizienz,... Nach Detailebenen des System Nach Priorität Nach Kritikalität Nach rechtlicher Verbindlichkeit: Muss, Kann,... 38

3.5 Anforderungsmanagement Requirement Management Tools Beispiele (Rupp et al., RE, S.391) (Auszug aus Wikipedia, http://de.wikipedia.org/wiki/anforderungsmanagement-software, 03/2014) 39

Lernziel 1. Was ist Requirements Engineering? Requirements Engineering umfasst die Anforderungsanalyse und das Anforderungs-management mit ingenieurmäßigem Vorgehen 2. Welche Eigenschaften haben gute Anforderungen? Vollständig, korrekt, klassifizierbar, konsistent, prüfbar, eindeutig, verständlich, aktuell, realisierbar, hat Notwendigkeit, verfolgbar, bewertbar 3. Wie findet man Anforderungen? Durch Kreativität, Beobachten (Vergangenheit oder aktuelles Vorgehen), Befragen und nutzen unterstützender Techniken 4. Wie testet man Anforderungen? Zeitpunkt: Nach Definition, vor Implementation, Prüfer identifizieren, Prüftechnik festlegen, Prüfung durchführen 40