Requirements Engineering Ein Überblick

Transkript

1 Requirements Engineering Ein Überblick Martin Glinz Institut für Informatik der Universität Zürich Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den persönlichen, nicht kommerziellen Gebrauch gestattet, wobei bei auszugsweiser Verwendung Quelle und Copyright zu nennen sind. Die Verwendung für Unterrichtszwecke oder für kommerziellen Gebrauch ist nur mit vorheriger schriftlicher Genehmigung des Autors gestattet.

2 Was ist Requirements Engineering? Requirements Engineering Ein Überblick 2006 Martin Glinz 2

3 Erste Näherung: technisch Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare Vorgehen beim Spezifizieren (d.h. Erfassen, Beschreiben und Prüfen) sowie beim Verwalten von Anforderungen an Software. Ziel ist eine vollständige, eindeutige, widerspruchsfreie Spezifikation aller Anforderungen Typisch als erste Phase eines Projekts Riecht nach Papier und Bürokratie Wo sind die Menschen in diesem Prozess? Ist das Ziel überhaupt realistisch? Requirements Engineering Ein Überblick 2006 Martin Glinz 3

4 Zweite Näherung: kundenorientiert Requirements Engineering (Anforderungstechnik) Verstehen und Beschreiben, was die Kunden wünschen oder brauchen. Eine menschenzentrierte Sicht Ziel: zufriedene Kunden Was sind Kunden? Warum wünschen oder brauchen? Warum nicht gleich programmieren? Requirements Engineering Ein Überblick 2006 Martin Glinz 4

5 Dritte Näherung: risikoorientiert Requirements Engineering (Anforderungstechnik) Spezifikation und Verwaltung von Anforderungen mit dem Ziel, das Risiko zu minimieren, dass Software entwickelt wird, welche den Kunden nicht nützt oder gefällt. Anforderungen schon bekannt? nein ja nicht spezifizieren Risiko tolerabel gering, dass der Kunde das entwickelte System nicht akzeptiert? ja nein nicht spezifizieren Anforderungsspezifikation notwendig Requirements Engineering Ein Überblick 2006 Martin Glinz 5

6 Anforderungsspezifikation als Risikominimierung Wir haben keine Zeit für eine vollständige Spezifikation. Ist uns zu teuer! Bei agilem Vorgehen genügen grobe Stories vollständig. falscher Ansatz Richtige Frage: Wie viel müssen wir tun, damit das Risiko eine Größe annimmt, die wir bereit sind zu akzeptieren? Merkregel: Der Aufwand für das Requirements Engineering soll umgekehrt proportional zum Risiko sein, das man bereit ist, einzugehen. Requirements Engineering Ein Überblick 2006 Martin Glinz 6

7 Qualität von Anforderungen Adäquat beschreibt das, was der Kunde will bzw. braucht Vollständig beschreibt alles, was der Kunde will bzw. braucht Widerspruchsfrei sonst ist die Spezifikation nicht realisierbar Verständlich für alle Beteiligten, Kunden wie Informatiker Eindeutig vermeidet Fehler durch Fehlinterpretationen Prüfbar feststellen können, ob das realisierte System die Anforderungen erfüllt Risikogerecht Umfang umgekehrt proportional zum Risiko, das man eingehen will Requirements Engineering Ein Überblick 2006 Martin Glinz 7

8 Anforderungen haben einen Kontext Bibliothekarin Verbundkatalog Bibliothekssystem Benutzer Schleuse Wie ist das zu erstellende System in sein Umfeld eingebettet? Welche Akteure interagieren mit dem System Auf welcher Betrachtungsebene befinden wir uns? Requirements Engineering Ein Überblick 2006 Martin Glinz 8

9 Mehrere Betrachtungsebnen Das System soll längere Öffnungszeiten bei geringeren Kosten für die Bibliothekarinnen ermöglichen. Die Schleuse erkennt nicht deaktivierte Sicherungsetiketten und schickt eine Alarmmeldung an das Bibliothekssystem. Bei erfolgreicher Ausleihe schickt das System ein Kommando zur Deaktivierung des Sicherungsetiketts an den Etikettenleser. Mehrere Betrachtungsebenen mit unterschiedlichem Kontext, typisch Geschäftsebene Systemebene Softwareebene Oft weitere Ebenen, z. B. Komponentenebene Verzahnung von Anforderungen und Entwurf Requirements Engineering Ein Überblick 2006 Martin Glinz 9

10 Jeder braucht es, aber nur wenige tun es wirklich Warum? Requirements Engineering Ein Überblick 2006 Martin Glinz 10

11 Warum Anforderungen spezifizieren? Kosten senken Geringere Herstellungskosten durch Senken der Fehlerkosten Weniger Reklamationen und Nachbesserungen Geringere Pflegekosten Risiken verkleinern Kundenerwartungen besser erfüllen Zuverlässigere Prognosen für Termine und Kosten Mehr verdienen! Zufriedenere Kunden! Die wirtschaftliche Wirkung von Requirements Engineering ist immer indirekt; das RE selbst kostet nur! Requirements Engineering Ein Überblick 2006 Martin Glinz 11

12 Was gibt es zu tun im Requirements Engineering? Requirements Engineering Ein Überblick 2006 Martin Glinz 12

13 Prozesse im Requirements Engineering Anforderungen spezifizieren (requirements specification) gewinnen (elicitation) analysieren und dokumentieren (analysis, documentation) prüfen (validation) Anforderungen verwalten (requirements management) freigeben ändern verfolgen (traceability) Requirements Engineering Ein Überblick 2006 Martin Glinz 13

14 Keine Einheitsgröße für alles Es gibt keinen idealen RE-Prozess zuschneiden auf konkrete Projektsituation zu berücksichtigende Faktoren: lineares oder inkrementelles Vorgehen im Projekt? muss die Spezifikation wasserdicht sein (Vertrag; Realisierung durch Dritte)? sind die Kunden/Benutzer bekannt und können sie in die Erstellung der Spezifikation einbezogen werden? wird das zu spezifizierende System im Kundenauftrag oder für den Markt entwickelt? soll Standardsoftware zum Einsatz kommen? Requirements Engineering Ein Überblick 2006 Martin Glinz 14

15 Spezifikationsprozess: Einbettung Lineares Modell Inkrementelles Modell Requirements Engineering Ein Überblick 2006 Martin Glinz 15

16 Gewinnung von Anforderungen Anforderungsgewinnung durch... Interviews Umfragen/Fragebogen Beobachtung Gemeinsame Arbeitstagungen Prototypen Requirements Engineering Ein Überblick 2006 Martin Glinz 16

17 Gewinnung und Analyse: Methodische Ansätze Begriffe klären und Glossar aufbauen Prozessabläufe analysieren Geschäfts- und Datenobjekte analysieren Problemstellung Dynamisches Systemverhalten untersuchen Problem in Teilprobleme zerlegen Anwendungsszenarien bilden und durchspielen Strukturorientierte Methoden Prozessorientierte Methoden Requirements Engineering Ein Überblick 2006 Martin Glinz 17

18 Regeln Informationen über den Anwendungsbereich gewinnen und analysieren Begriffswelt Gegenstände und Prozesse Konkrete Bedürfnisse und Wünsche erfassen und analysieren Anforderungsspezifikation fortlaufend inkrementell aufbauen Keine großen Materialsammlungen Gewinnung, Analyse und Darstellung miteinander verzahnen Rückkopplung ist wichtig Anforderungen betreffen einen SOLL-Zustand Den IST-Zustand nur analysieren, wenn dies notwendig ist Requirements Engineering Ein Überblick 2006 Martin Glinz 18

19 Risiken und Probleme Erwartungs- und Begriffsdiskrepanzen bei den Beteiligten Beteiligte wissen zwar, was sie wollen, können ihre Vorstellungen aber nicht formulieren Beteiligte wissen nicht, was sie wollen Beteiligte haben verdeckte Ziele, die sie absichtlich nicht offen legen Beteiligte sind auf bestimmte Lösungen fixiert Requirements Engineering ist immer auch Aufgabenklärung Risikoanalyse Konsensbildung Konflikterkennung und -auflösung Anregung von Kreativität bei den Beteiligten Requirements Engineering Ein Überblick 2006 Martin Glinz 19

20 Anforderungen priorisieren Nicht alle Anforderungen sind gleich wichtig: Muss-Anforderungen unverzichtbar Soll-Anforderungen wichtig, aber bei zu hohen Kosten verzichtbar Wunsch-Anforderungen schön zu haben, aber nicht essenziell Priorisierung nötig bei harten Terminen harten Preisobergrenzen Beschaffung Priorisierung nützlich bei Festlegung von Inhalt und Umfang der Inkremente bei inkrementeller Entwicklung Releaseplanung bei der Weiterentwicklung bestehender Systeme Requirements Engineering Ein Überblick 2006 Martin Glinz 20

21 Wie schreib ichs auf? Requirements Engineering Ein Überblick 2006 Martin Glinz 21

22 Darstellung von Anforderungen Viele Freiheitsgrade: Wahl der sprachlichen Mittel Formalitätsgrad Art der Gliederung / Strukturierung Präzision Tiefe Auswahl dem Risiko anpassen Requirements Engineering Ein Überblick 2006 Martin Glinz 22

23 Risikogerechte Detaillierung Welche Variante ist besser: A. «Die Teilnehmer-Eingabemaske enthält Felder für Name, Vorname, Geschlecht und Adresse des Teilnehmers.» B. «Die Teilnehmer-Eingabemaske enthält Felder für Name, Vorname, Geschlecht und Adresse des Teilnehmers. Namen- und Vornamenfelder sind je maximal 32 Zeichen lang und obligatorisch. Das System verwendet Unicode als Zeichensatz. Für die Eingabe des Geschlechts enthält die Maske zwei Ankreuzfelder, beschriftet mit männlich und weiblich. Die Voreinstellung ist männlich, Ankreuzungen schließen sich gegenseitig aus, eine Ankreuzung ist erforderlich....» Der notwendige Detaillierungsgrad wird bestimmt durch Abwägung der Kosten des Risikos, unbrauchbare Systeme zu erhalten des Entscheidungsspielraums für die Entwickler Requirements Engineering Ein Überblick 2006 Martin Glinz 23

24 Techniken und Sprachen Natürliche Sprache Teilformale Modelle Anwendungsfälle und Szenarien Strukturmodelle Verhaltensmodelle UML Formale Spezifikation Requirements Engineering Ein Überblick 2006 Martin Glinz 24

25 Anforderungsspezifikation mit natürlicher Sprache Weit verbreitet Nummerierung und Gliederungsschemata als Strukturierungsmittel Linguistische Methoden zur Verbesserung der Qualität + Leicht zu schreiben und zu lesen + Ausdrucksmächtig Unübersichtlich Fehlerträchtig Schwierig zu prüfen Weniger geeignet als alleiniges Mittel zur Beschreibung von Spezifikationen Requirements Engineering Ein Überblick 2006 Martin Glinz 25

26 Anwendungsfälle / Szenarien Modellieren die Interaktion zwischen systemexternen Akteuren und dem System Pro Interaktionssequenz ein Anwendungsfall / Szenario Buch ausleihen 1. Ausweiskarte der Benutzerin lesen und Angaben überprüfen 2. Signatur eines Buchs lesen und zugehörigen Katalogeintrag ermitteln 3. Ausleihe registrieren und Diebstahlsicherungsetikett deaktivieren Modellierung aus Benutzersicht: leicht verstehbar und überprüfbar + Hilft bei der Abgrenzung zwischen System und Kontext + Dekomposition möglich Zusammenhänge / Abhängigkeiten zwischen Szenarien nicht modelliert Statische Struktur nicht modelliert Requirements Engineering Ein Überblick 2006 Martin Glinz 26

27 Strukturmodelle Mitarbeiter Stamm Nr Name Vorname 0..* Position Stufe Hierarchie 1 Hierarchiestufe Ferienanspruch Einstellen Entlassen Individuallohn ändern 1..* beschäftigt in beschäftigt Lohnklasse Modellieren die statische Struktur eines Systems mit Hilfe von Objekt- oder Klassendiagrammen Objekte/Klassen beschreiben Daten, Funktionen und zeitliches Verhalten Mitarbeiter im Stundenlohn Stundensatz Arbeitszeit erfassen Lohn zahlen bezahlt mit zugunsten von 0..* 0..* Mitarbeiter im Monatslohn Überzeitsaldo Ferienguthaben Lohn zahlen Lohn- Zahlungsauftrag Erteilen Stornieren eingestuft in Klasse 1 1 Abteilung Name Sitz Nr Grundlohn + Gut geeignet zur Beschreibung der Systemstruktur + Unterstützt Lokalität von Daten und Einkapselung von Eigenschaften + Erlaubt strukturähnliche Implementierungen + Systemdekomposition möglich Funktionalität aus Benutzersicht schlecht modellierbar Keine speziellen Verfahren/Darstellungsmittel für nicht-funktionale Anforderungen Dekomposition häufig nicht unterstützt Requirements Engineering Ein Überblick 2006 Martin Glinz 27

28 Verhaltensmodelle Modellieren das zeitlichdynamische Systemverhalten Basis: Zustandsautomaten ckt hen, gi- Gewählt Preis anzeigen + Leicht nachvollziehbar und simulierbar + Dekomposition möglich Aktionen meist nur genant, aber nicht modelliert Statische Struktur nicht modelliert eigen me + wert, gen Geldannahme Münze eingegeben Summe := Münzwert, Preis - Summe anzeigen Annullie Anzeige Eingewo zurückge Auswah Summe Preis Anzeige löschen, Getränk ausgeben, Wechselgeld := Wechselgeld ausgeben Requirements Engineering Ein Überblick 2006 Martin Glinz 28

29 Anforderungsspezifikation mit UML UML = Sammlung vorwiegend grafischer Modellierungssprachen Enthält Sprachen, die für die Modellierung von Anforderungen verwendbar sind: Übersicht über die Anwendungsfälle: Anwendungsfalldiagramm Geschäftsobjektmodelle, Modelle des Anwendungsbereichs: Klassendiagramm Verhaltensmodelle: Zustandsmaschinen Vorgeschriebene Abläufe: Sequenzdiagramme, Aktivitätsdiagramme Wenig bis keine Unterstützung für Beschreibung von Anwendungsfällen Nicht-funktionale Anforderungen Zusammenhänge zwischen den Anforderungen Requirements Engineering Ein Überblick 2006 Martin Glinz 29

30 Formale Spezifikation 1 Modelle auf der Grundlage mathematisch-logischer Formalismen Spielt trotz theoretischer Vorteile nur marginale Rolle in der Praxis Einsatz punktuell sinnvoll und möglich, vor allem für sicherheitskritische Komponenten Beweis / automatisierter Test wichtiger Eigenschaften möglich Berechtigung erteilen Autorisierung einzusehendesdokument?: Dokument Autorisierter?: Person einzusehendesdokument? Bestand \ dom gesperrt Autorisierter? Mitarbeiter autorisiert' = autorisiert {(einzusehendesdokument?, Autorisierter?)} Bestand' = Bestand Mitarbeiter' = Mitarbeiter gesperrt' = gesperrt Requirements Engineering Ein Überblick 2006 Martin Glinz 30

31 Formale Spezifikation 2 + Immer eindeutig + Widerspruchsfreiheit formal prüfbar + Erfüllung wichtiger Eigenschaften beweisbar + Lösungsneutral + Formale Verifikation von Programmen möglich Erstellung sehr aufwendig Beurteilung der Vollständigkeit schwierig Schwer lesbar Prüfung auf Adäquatheit schwierig Requirements Engineering Ein Überblick 2006 Martin Glinz 31

32 Prüfen und verwalten mühsam, aber nötig Requirements Engineering Ein Überblick 2006 Martin Glinz 32

33 Prüfen von Anforderungen Anforderungen adäquat, vollständig, eindeutig, widerspruchsfrei...? Möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten, etc. so früh wie möglich finden und beheben Mittel Review Simulation Abnahmetestfälle Prototypen Wann? (1) Fortlaufend, d.h. begleitend zur Erstellung der Spezifikation, z. B. Autor-Kritiker-Zyklus (2) Nach Fertigstellung der Anforderungsspezifikation Requirements Engineering Ein Überblick 2006 Martin Glinz 33

34 Requirements Management Beherrschen der Evolution von Anforderungen: Anforderungen stabil halten und Veränderung kontrolliert zulassen Konfigurationsmanagement für Anforderungen Anforderungen einzeln identifizierbar Geordneter Änderungsprozess Klare Zuständigkeiten und Verantwortlichkeiten Rückverfolgbarkeit aller Entscheide und Änderungen Verfolgbarkeit (traceability) Rückwärts: Wo kommt welche Anforderung her? Vorwärts: Wo ist welche Anforderung entworfen bzw. implementiert? Wie hängen Anforderungen voneinander ab? Requirements Engineering Ein Überblick 2006 Martin Glinz 34

35 Und wenn wir zu wenig Zeit haben? Requirements Engineering Ein Überblick 2006 Martin Glinz 35

36 Was ist (fast immer) unverzichtbar? Die wichtigen Beteiligten (stakeholders) kennen und einbeziehen Das Problem kennen Übergeordnete Geschäftsziele kennen Die wichtigsten Systemziele identifizieren und aufschreiben Die Schlüsselbegriffe des Systems und des Anwendungsbereichs in einem Glossar definieren Die Hauptfunktionen identifizieren und dokumentieren Kritische Randbedingungen und Risiken identifizieren Requirements Engineering Ein Überblick 2006 Martin Glinz 36

37 Erschwerende Faktoren ( Mehraufwand notwendig) Hohe Komplexität des Anwendungsbereichs Entwicklungsteam mit dem Anwendungsbereich nicht vertraut Viele Beteiligte Verteilte Entwicklung und/oder Beteiligte Lange Durchlaufzeit Sicherheitskritische Anforderungen Hohe Projektrisiken Requirements Engineering Ein Überblick 2006 Martin Glinz 37

38 Zusammenfassung Requirements Engineering heißt Anforderungen gewinnen aufschreiben prüfen verwalten legt den Grundstein für die Qualität des Produkt Requirements Engineering Es von Anfang an richtig machen. Requirements Engineering Ein Überblick 2006 Martin Glinz 38