Vorlesung Software Engineering I

Präsentation zum Thema: "Vorlesung Software Engineering I"—  Präsentation transkript:

1 Vorlesung Software Engineering I
Requirements Engineering Software Engineering I VE 03: Requirements Engineering Version

2 Der Systemanalytiker (Requirements Engineer) ist dafür zuständig.
Definition Die Anforderungsanalyse ist üblicherweise die Startphase im Software-Lebenszyklus. Requirements Engineering steht für das systematische Vorgehen bei der Erfassung, Beschreibung, Prüfung und Verfolgung von Anforderungen für ein zu entwickelndes (Software-) System. Der Systemanalytiker (Requirements Engineer) ist dafür zuständig. Software Engineering I VE 03: Requirements Engineering Version

3 Pohl, Klaus; Rupp, Chris: Basiswissen Requirements Engineering
Literatur Pohl, Klaus; Rupp, Chris: Basiswissen Requirements Engineering Aus und Weiterbildung zum Certified Professional for Requirements Engineering Foundation Level nach IREB-Standard. dpunkt, Heidelberg, 2009. Software Engineering I VE 03: Requirements Engineering Version

4  Lastenheft Pflichtenheft Kundenanforderungen Systemanforderungen
Anforderungsphasen Kundenanforderungen Definition der Systemeigenschaften (WAS)  Lastenheft Systemanforderungen Technische Spezifikation des Systems (WIE) Pflichtenheft Pflichtenheft wird Vertragsgrundlage! Software Engineering I VE 03: Requirements Engineering Version

5 Analysephase  Designphase
Anforderungs- Spezifikation (Lastenheft) Anforderungs-Ermittlung Produkt- Spezifikation (Pflichtenheft) Anforderungsanalyse, Systemmodellierung Design Architektur- Spezifikation “Projektstart“ Architekturentwurf WAS für ein System sollen wir bauen, bzw. WAS für Aspekte eines Systems sollen verändert werden? WAS sind die Anforderungen des Kunden? Ist es möglich, das geforderte System zu realisieren ? Nach Balzert: - Anforderungsspezifikation - Modell = „Fachliche Lösung“ - Architektur = „Technische Lösung“ - Implementierung = „System/Produkt“  Sind strikt getrennt zu halten! Detailentwurf Modul-/Klassen- Spezifikationen Software Engineering I VE 03: Requirements Engineering Version

6 Relevanz von RE Requirements Engineering (RE) ist eine Schlüsseldisziplin der Systementwicklung und entscheidet maßgeblich über den Erfolg oder Misserfolg eines Projekts. Die perfekte Analyse ist nicht möglich, aber sie muss das Ziel sein !!! Ein guter Requirements-Engineer benötigt bestimmte persönliche Eigenschaften: Analytisch, Selbstbewusst, Emphatisch, Abstraktes Denken, Neugierig, Kommunikativ, Penetrant, präziser schriftlicher Ausdruck. Analytisch, Selbstbewusst, Emphatisch, Abstraktes Denken, Neugierig, Kommunikativ, Penetrant, präziser schriftlicher Ausdruck. Software Engineering I VE 03: Requirements Engineering Version

7 Definition Eine Anforderung (Requirement) ist eine funktionale oder nichtfunktionale Vorgabe, die ein System erfüllen soll bzw. eine technische oder formale Restriktion, die von außen vorgegeben und zu beachten ist. Die Definition der Anforderung muss als Übereinkunft zwischen Auftraggeber und Auftragnehmer formuliert sein. Eindeutigkeit ist dabei ein wesentliches Kriterium. Software Engineering I VE 03: Requirements Engineering Version

8 Anforderungen an Anforderungen
Software Engineering I VE 03: Requirements Engineering Version

9 Problem: Widersprüchliche Anforderungen
Vexierbild Nicht realisierbar ! Software Engineering I VE 03: Requirements Engineering Version

10 Problem: Mehrdeutige Anforderungen
Vexierbild Software Engineering I VE 03: Requirements Engineering Version

11 Problem: Mehrdeutige Anforderungen
Mehrere Interpretationen möglich Was ist richtig ? Software Engineering I VE 03: Requirements Engineering Version

12 Problem: Unscharfe Anforderungen
Nicht interpretierbar ! Software Engineering I VE 03: Requirements Engineering Version

13 Prägnant Schlecht: Das geplante System soll sowohl von Experten als auch von unerfahrenen Personen (Nutzerinnen und Nutzern) benutzbar sein. Unerfahrene User sollen auch ohne große Vorkenntnisse der Bedienerführung oder des Vorgängersystems die vorgesehene Systemfunktionalität nutzen können. Zur Benutzung des Systems sollen die Anwender also keinerlei Schulungen oder spezielle Hilfestellungen benötigen. Der Umgang mit dem System muss daher leicht verständlich sein und ohne große Erfahrung mit dem Vorgängersystem oder vergleichbaren Systemen erfolgen können. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Ein unerfahrener Benutzer soll das System ohne spezielle Schulung verwenden können Software Engineering I VE 03: Requirements Engineering Version

14 Aktiv Schlecht: Die Dauer für die Erfassung und Verarbeitung der Messdaten soll halbiert werden. Dadurch soll die Wartezeit bis zum Vorliegen von Ergebnissen verkürzt werden. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System erfasst und verarbeitet die Messdaten im Vergleich zum System xy doppelt so schnell. Dadurch muss der Nutzer kürzer auf das Vorliegen von Ergebnissen warten Software Engineering I VE 03: Requirements Engineering Version

15 Überprüfbar (Quantitativ)
Schlecht: Das System soll besser sein als das Vorgängersystem. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll folgende Verbesserungen gegenüber dem System xy bieten: … Software Engineering I VE 03: Requirements Engineering Version

16 Verfeinerung von Zielen
Schlecht: Die Benutzung des Systems soll selbsterklärend sein Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll selbsterklärend sein, d.h. ein durchschnittlicher Nutzer soll durchschnittlich nach 2 Min. folgende Funktionen aufrufen können: … Das System soll selbsterklärend sein, d.h. den Vorgaben nach W3C… in Bezug auf … folgen Software Engineering I VE 03: Requirements Engineering Version

17 Schlecht: Das System soll leicht benutzbar sein.
Mehrwertbildung Schlecht: Das System soll leicht benutzbar sein. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll … so dass sich die Nutzer auf andere Aufgaben konzentrieren können Software Engineering I VE 03: Requirements Engineering Version

18 Nachvollziehbare Begründungen
Schlecht: Das System soll auch von ungeschulten Benutzern intuitiv benutzbar sein. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: … weil es auch in Mietfahrzeugen einsetzbar sein soll Software Engineering I VE 03: Requirements Engineering Version

19 Keine Lösungsvorwegnahme
Schlecht: Durch komprimierte Datenübertragung im Cache soll das geplante System um 10% kürzere Antwortzeiten aufweisen Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll um 10% kürzere Antwortzeiten aufweisen als System xy. Software Engineering I VE 03: Requirements Engineering Version

20 Problem: Trennung von Anforderung und Lösung
WAS = Spezifikation, WIE = Entwurf /REQ 1/ „Das System druckt eine wahlweise nach Namen oder Land alphabetisch sortierte Liste von Teilnehmern mit Nummer, Name, Vorname, Affiliation und Land. Auf jeder Seite sind unten links das Erstellungsdatum und unten rechts die Seitenzahl aufgedruckt.“ Ist dieser Satz eine Anforderung oder eine Entwurfsentscheidung? ➜ WAS vs. WIE ist kontextabhängig und liefert keine brauchbare Abgrenzung zwischen Anforderungen und Entwurfsentscheidungen. Die gleiche Sache kann je nach Kontext beides sein. Probleme (beschrieben als Anforderungen) und Lösungen (das Ergebnis von Entwurfsentscheidungen) sind hierarchisch miteinander verzahnt! ➜ WAS vs. WIE ist stufenabhängig: Eine Entwurfsentscheidung auf Stufe n wird zur Aufgabe (=Anforderung) auf Stufe n+1 Top-Down! Software Engineering I VE 03: Requirements Engineering Version

21 Problembeispiel: WAS versus WIE
Problem: Julia Meier hat ihr Studium abgeschlossen und erhält keine Unterstützung von ihren Eltern mehr. Sie ist daher mit der Anforderung konfrontiert, ihren Lebensunterhalt zu sichern. Sie wohnt in Adorf und hat ein Stellenangebot bei einer Firma in Befingen. Ferner hat sie einen reichen Freund und eine ebenso reiche Erbtante. Hierarchische Verzahnung von Problem und Lösung ! Übergeordnete Entwurfsentscheidungen beeinflussen untergeordnete Anforderungen ! Software Engineering I VE 03: Requirements Engineering Version

22 Ja, mit operationaler Abgrenzung:
Lösung: WAS versus WIE Sind Spezifikation von Anforderungen und Entwurf von Lösungen voneinander trennbar? Ja, mit operationaler Abgrenzung: Anforderungsänderungen brauchen die Zustimmung des Auftraggebers Entwurfsänderungen kann der Auftragnehmer autonom vornehmen Braucht eine Veränderung eines Satzes, eines Modellelements, eines Konstrukts, etc. die Zustimmung des Auftraggebers/Kunden? ja ➜ Anforderung nein ➜ Entwurfsentscheidung Software Engineering I VE 03: Requirements Engineering Version

23 Ist die Trennung zwischen Anforderungen und Lösungen notwendig ?
WAS versus WIE Ist die Trennung zwischen Anforderungen und Lösungen notwendig ? Ja ! Die Kompetenz zur Festlegung von Anforderungen liegt fast immer bei anderen Personen als die Kompetenz zum Treffen von Entwurfsentscheidungen Anforderungen und Entwürfe sind daher getrennt zu dokumentieren ! Software Engineering I VE 03: Requirements Engineering Version

24 Prozesse im Requirements Engineering
Kennen lernen der Anwendungsdomäne Identifikation von Konzepten, Beziehungen, grundlegendem Verhalten Bestimmung der Anforderungen an das System Identifikation der Geschäftsprozesse, die das System unterstützen soll Identifikation der Funktionen die das System dafür bieten soll  Das Ganze geschieht auf zwei Ebenen, aus denen sich die zwei verschiedenen "Workflows" des RE-Prozesses ergeben: Anforderungserhebung („Requirements Elicitation“): Definition des Systems in einer Form, die Kunden und Entwickler verstehen Anforderungsanalyse („Requirements Analysis“): Technische Spezifikation des Systems in einer für die Entwickler verständlichen und umsetzbaren Form. Software Engineering I VE 03: Requirements Engineering Version

25 Wie komme ich zu den richtigen Anforderungen?
Teilgebiete Wie komme ich zu den richtigen Anforderungen? Wie dokumentiere ich Anforderungen verständlich? Wie vermeide ich inkonsistente, unvollständige Anforderungen? Wie manage ich Änderungen der Anforderungen? Wie beschleunige ich mit Templates und Patterns den Analyseprozess? Wie sichere ich die Testbarkeit der Anforderungen? Wie messe ich den Projektfortschritt? Welchen Faktor spielt der Mensch im Analyseprozess? Wie verwalte ich Anforderungen? Software Engineering I VE 03: Requirements Engineering Version

26 Standards Standards für das Requirements Management
Ein sehr bekannter Standard zum Requirements Management ist der IEEE 830 (Recommended Practice for Software Requirements Specifications). Er ist ein konkreter praxisnaher Standard für die Beschreibung und die Definition von Softwareanforderungen. Es werden Strukturen vorgeben für den Aufbau der Dokumentation, den Aufbau der einzelnen Anforderungen und sogar zur Formulierung der Anforderungen. Eine gute Ergänzung hierzu ist der Standard IEEE 1362 (Guide for Information Technology – System Definition, Definition - Concept of Operations Document), der letztendlich ein Standard für Anforderungsdokumente (Lastenhefte) darstellt. Eine weitere sinnvolle Ergänzung zu den beiden genannten Standards sind die Spezifikationen aus VDI 2519 – Blatt 1 (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften). Hier wird definiert was Lasten- und Pflichtenhefte sind, was sie enthalten sollten und wie sie erstellt werden sollten. Software Engineering I VE 03: Requirements Engineering Version

27 Anforderungsermittlung: Methoden
engl. „Requirements Elicitation“ Software Engineering I VE 03: Requirements Engineering Version

28 Beobachtungstechniken
Der Systemanalytiker beobachtet, welche Prozesse die Stakeholder während ihrer Arbeit ausführen. Er erfasst diese Abläufe und ermittelt daraus die Vorgänge sowie Verbesserungsansätze für das zu entwickelnde System. Beobachtungstechniken eignen sich dazu, sowohl Anforderungen auf sehr detailliertem Niveau als auch unterbewusste Anforderungen zu ermitteln. Beispiele hierfür sind Feldbeobachtung und Apprenticing. Die Apprenticing-Technik ("in die Lehre gehen") ist eine Beobachtungstechnik bei der Anforderungsermittlung. Dabei erlernt der Systemanalytiker die Tätigkeiten der Stakeholder unter deren Anleitung, um sich ein genaues Bild von den Arbeitsabläufen zu machen. Diese Stakeholder sind meistens die Mitarbeiter, die wichtiges fachliches Know-how besitzen und nicht die Zeit haben, bei der Anforderungsermittlung mitzuarbeiten. Software Engineering I VE 03: Requirements Engineering Version

29 Befragungstechniken Diese Ermittlungstechniken basieren darauf, Stakeholder nach ihren Wünschen und Bedürfnissen zu befragen. Hierbei stellt ein Systemanalytiker dem Stakeholder gezielte Fragen und lässt sich Sachverhalte, Abläufe und Wünsche schildern. Die Befragungstechniken Fragebogen, Interview, Selbstaufschreibung und On-Site-Customer sind zur Ermittlung von Anforderungen beliebiger Detaillierungsgrade geeignet. Software Engineering I VE 03: Requirements Engineering Version

30 Vergangenheitsorientierte Techniken
Um bestehende Lösungen in ein neues System zu integrieren, sind vergangenheitsorientierte Techniken geeignet. Durch diese Techniken wird die Möglichkeit geschaffen Erfahrungen aus bereits erfolgreich abgeschlossenen Systementwicklungen wiederzuverwenden. Beispiele hierfür sind Systemarchäologie und Reuse. Software Engineering I VE 03: Requirements Engineering Version

31 Feedback-Techniken Missverständnisse, Fehlinterpretationen oder Fehler bei der Formulierung können bei der Ermittlung der Anforderungen durch einen Systemanalytiker auftreten. Um die Qualität der Anforderungen sicherzustellen, muss der Stakeholder das Ergebnis überprüfen. Hierzu verwendet er Feedback-Techniken wie Simulationsmodelle und Anforderungsreview (Anforderungsprüfung und Akzeptanz). Software Engineering I VE 03: Requirements Engineering Version

32 Unterstützende Techniken
Es gibt unterstützende Techniken, die in Kombination mit den bisher beschriebenen Ermittlungstechniken eingesetzt werden. Zu diesen unterstützenden Techniken gehören z.B. Workshops, Snowcards, CRC-Karten, Modellierung etc. Diese Techniken dienen nicht primär der Ermittlung von Anforderungen, sondern der Optimierung der Ergebnisse. Software Engineering I VE 03: Requirements Engineering Version

33 Kundenorientierung im RE
Software Engineering I VE 03: Requirements Engineering Version

34 Nichtfunktionale Anforderungen Funktionale Anforderungen
Anforderungsarten Visionen und Ziele Rahmenbedingungen z.B. Juristische Vorgaben Kontext und Überblick Systemumgebung Nichtfunktionale Anforderungen Qualitätsmerkmale Funktionale Anforderungen Funktionen Bevor funktionale und nichtfunktionale Anforderungen sowie Rahmenbedingungen festgelegt werden, sollten die Visionen und Ziele des Systems aufgestellt werden. Software Engineering I VE 03: Requirements Engineering Version

35 Funktionale und nichtfunktionale Anforderungen
Beschreibung der Dienste des Systems, z.B. wie es auf bestimmte Eingaben reagiert oder sich in bestimmten Situationen verhält z.B. was passiert wenn ein bestimmter Knopf gedrückt wird Nicht-funktionale Anforderungen Randbedingungen für die Dienste, z.B. zeitliche Einschränkungen, Entwicklungseinschränkungen, usw. z.B. Lebensdauer oder Leistung Domänen-Anforderungen allgemeine Anforderungen für alle Systeme einer bestimmten Anwendungsdomäne (Medizintechnik, Schienenverkehr...) z.B. anwendbare Standards Software Engineering I VE 03: Requirements Engineering Version

36 Funktionale Anforderungen
Funktionalität oder Dienste des Systems Funktionale Nutzeranforderungen: Abstrakte Außensicht Funktionale Systemanforderungen: Abstrakte Innensicht Formulierung hängt ab von der zu erwartenden Nutzung und dem Einsatzbereich des Systems BLACK BOX VIEW! Software Engineering I VE 03: Requirements Engineering Version

37 Nichtfunktionale Anforderungen
Software Engineering I VE 03: Requirements Engineering Version

38 Struktur einer Anforderung
Typischerweise besteht eine Anforderung aus folgenden Attributen: Identifikator (Requirement Number): Identifiziert die Anforderung eindeutig. Beschreibung (Description) Problembeschreibung (Rationale): Beschreibt das die Anforderung verursachende Problem. Priorität (Priority): Ein numerischer Wert, der die Priorität dieser Anwendung definiert und dann wichtig wird, wenn nicht alle Anforderungen erfüllt werden können. Quelle (Originator): Identifiziert die anfordernde Person oder ein Dokument, aus dem sich die Anforderung ergibt, beispielsweise eine Rechtsvorschrift. Abnahmekriterium (Fit Criterion): Beschreibt eine messbare Bedingung, mit der später geprüft wird, ob die Anforderung erfüllt wurde. Konflikte (Conflicts): Hier können Anforderungen aufgeführt werden, die dieser Anforderung widersprechen, sodass zwischen ihnen abgewägt werden muss. Informationen zum Lebenszyklus: Status: Identifiziert den aktuellen Zustand der Anforderung, beispielsweise ob sie vom Auftragnehmer bereits akzeptiert wurde. Offene Punkte: Bietet Platz für noch zu klärende Sachverhalte. History: Versionsgeschichte der Anforderung: Wann wurde sie von wem erstmals formuliert, wann von wem geändert usw. I Produktrelease: Identifiziert die Version des zu erstellenden Produkts, in dem die Anforderung erfüllt werden soll. Da Anforderungen nicht konstant bleiben, sondern sich im Verlauf eines Projektes weiterentwickeln, werden auch Informationen zu ihrem Lebenszyklus benötigt. Software Engineering I VE 03: Requirements Engineering Version

39 Anforderungsbeschreibung
Verbal Fließtext, strukturierte Texte Non-Verbal Grafische Notationen Formale Sprachen Ich nutze gerne UML. Vielleicht liegt es daran, dass ich bei Sophist viele viele UML-Trainings gehalten habe. Typischerweise verwende ich UML als Ergänzung zu sprachlichen Spezifikationen, z. B. für - Zusammenhänge von Dingen (Objekten), z. B. Eine Organisationsstruktur im Klassendiagramm - Lebenszyklus von Dingen im System, z. B. ein Dokument im Knowledge Management System im Zustandsdiagram - Kommunikation zwischen Systemen im Sequenzdiagramm - Natürlich das Use-Case-Diagamm als Übersicht der Dienstleistung des Systems Selten, aber es kommt auch vor: eine vollständige objektorientierte Analyse habe ich bisher in einem Projekt durchgeführt. Alle Use-Cases habe ich vollständig durch Zustandsdiagramme spezifiziert. Die Besonderheit war, dass der Kunde UML liebte und ich mit ihm zusammen die Diagramme entworfen habe, die alle Funktionen definierten. Es war phantastisch. Präzise, vollständig, Klar. Die meisten Kunden würden diese Diagramme allerdings nicht verstehen. Daher spezifiziere ich meist mit Sprache und ergänze wo sinnvoll durch Diagramme. Mein Ziel ist, einerseits den Kunden eine verständliche Spezifikation zu liefern und andererseits präzise und eindeutig zu definieren. Kunden verstehen Sprache (fast :) immer, allerdings sind komplexe Zusammenhänge schwer beschreibbar. Diese fasse ich in ein Diagramm und ergänze die sprachliche Beschreibung. Software Engineering I VE 03: Requirements Engineering Version

40 Natürlichsprachliche Anforderungen
Anforderungen werden meist in natürlicher Sprache beschrieben Vorteil: Einfach, flexibel, universell Nachteil: Gefahr der Mehrdeutigkeit, Vermischung etc.  Erstellung eines Glossars  Verwendung von Schablonen Software Engineering I VE 03: Requirements Engineering Version

41 Natürlichsprachliche Anforderungen
Die Anforderungsschablone der SOPHISTen <When?> The SYSTEM SHALL SHOULD WILL <process> PROVIDE <whom?> THE ABILITY TO BE ABLE TO <process> <thing to be processed> <process detail> <Under what conditions?> Darstellung der englischen Version Software Engineering I VE 03: Requirements Engineering Version

42 Sprachliche Abhängigkeiten…
Software Engineering I VE 03: Requirements Engineering Version

43 Vor- und Nachteile der Sprachschablone
Vorteile: Einfach lesbar Übersichtlich Sehr genau Einfach zu erstellen Semiformal, daher maschinell analysierbar Nachteile: Muss der Grammatik der verwendeten Sprache angepasst werden Möglicherweise Akzeptanzprobleme Software Engineering I VE 03: Requirements Engineering Version

44 (Semi-) Formale Konzepte
Anwendung von Modellierungskonzepten zur Anforderungsspezifikation, die das System aus verschiedenen Sichten beschreiben (Statik, Dynamik, Logik) Nachteil: Auftraggeber und Auftragnehmer müssen diese Notationen verstehen. Weitverbreitet: UML-Diagramme  Nächste Vorlesung Software Engineering I VE 03: Requirements Engineering Version

45 Requirements Management
Software Engineering I VE 03: Requirements Engineering Version

46 Requirements Coverage & Traceability
Software Engineering I VE 03: Requirements Engineering Version