Date post: | 06-Apr-2016 |
Category: |
Documents |
Upload: | joachim-schuster |
View: | 226 times |
Download: | 4 times |
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 1
Dozenten:Markus RentschlerAndreas Stuckert
Vorlesung
Software Engineering I
Requirements Engineering
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 2
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 3
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 4
Dozenten:Markus RentschlerAndreas Stuckert
Anforderungsphasen
• Kundenanforderungen– Definition der Systemeigenschaften (WAS)
Lastenheft
• Systemanforderungen– Technische Spezifikation des Systems (WIE)
Pflichtenheft
• Pflichtenheft wird Vertragsgrundlage!
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 5
Dozenten:Markus RentschlerAndreas Stuckert
Analyse
Anforderungs-Ermittlung
Produkt-Spezifikation(Pflichtenheft)
“Projektstart“
Analysephase Designphase
Anforderungs-Spezifikation(Lastenheft)
Design
Architekturentwurf
Detailentwurf
Architektur-Spezifikation
Modul-/Klassen-Spezifikationen
- 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 ?
Anforderungsanalyse, Systemmodellierung
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 6
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 7
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 8
Dozenten:Markus RentschlerAndreas Stuckert
Anforderungen an Anforderungen
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 9
Dozenten:Markus RentschlerAndreas Stuckert
Problem: Widersprüchliche Anforderungen
Nicht realisierbar !
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 10
Dozenten:Markus RentschlerAndreas Stuckert
Problem: Mehrdeutige Anforderungen
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 11
Dozenten:Markus RentschlerAndreas Stuckert
Problem: Mehrdeutige Anforderungen
• Mehrere Interpretationen möglich
Was ist richtig ?
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 12
Dozenten:Markus RentschlerAndreas Stuckert
Problem: Unscharfe Anforderungen
Nicht interpretierbar !
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 13
Dozenten:Markus RentschlerAndreas Stuckert
Prägnant
• Besser: Ein unerfahrener Benutzer soll das System ohne spezielle Schulung verwenden können
1. Prägnant2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
• 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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 14
Dozenten:Markus RentschlerAndreas Stuckert
Aktiv
• 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
1. Prägnant2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
• 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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 15
Dozenten:Markus RentschlerAndreas Stuckert
Überprüfbar (Quantitativ)
• Besser: Das System soll folgende Verbesserungen gegenüber dem System xy bieten:– …– …
•Schlecht: Das System soll besser sein als das Vorgängersystem.
1. Prägnant2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 16
Dozenten:Markus RentschlerAndreas Stuckert
Verfeinerung von Zielen
• 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
• Schlecht: Die Benutzung des Systems soll selbsterklärend sein 1. Prägnant
2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 17
Dozenten:Markus RentschlerAndreas Stuckert
Mehrwertbildung
• Besser: Das System soll … so dass sich die Nutzer auf andere Aufgaben konzentrieren können
• Schlecht: Das System soll leicht benutzbar sein.
1. Prägnant2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 18
Dozenten:Markus RentschlerAndreas Stuckert
Nachvollziehbare Begründungen
• Besser: … weil es auch in Mietfahrzeugen einsetzbar sein soll
• Schlecht: Das System soll auch von ungeschulten Benutzern intuitiv benutzbar sein.
1. Prägnant2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 19
Dozenten:Markus RentschlerAndreas Stuckert
Keine Lösungsvorwegnahme
• Besser: Das System soll um 10% kürzere Antwortzeiten aufweisen als System xy.
• Schlecht: Durch komprimierte Datenübertragung im Cache soll das geplante System um 10% kürzere Antwortzeiten aufweisen
1. Prägnant2. Aktiv3. Überprüfbar4. Verfeinerbar5. Wertschöpfe
nd6. Begründbar7. Deklarativ
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 20
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 21
Dozenten:Markus RentschlerAndreas Stuckert
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 !
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 22
Dozenten:Markus RentschlerAndreas Stuckert
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➜
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 23
Dozenten:Markus RentschlerAndreas Stuckert
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 !
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 24
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 25
Dozenten:Markus RentschlerAndreas Stuckert
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?
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 26
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 27
Dozenten:Markus RentschlerAndreas Stuckert
Anforderungsermittlung: Methoden
• engl. „Requirements Elicitation“• http://www.software-kompetenz.de/?6926
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 28
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 29
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 30
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 31
Dozenten:Markus RentschlerAndreas Stuckert
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).
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 32
Dozenten:Markus RentschlerAndreas Stuckert
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.
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 33
Dozenten:Markus RentschlerAndreas Stuckert
Kundenorientierung im RE
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 34
Dozenten:Markus RentschlerAndreas Stuckert
Anforderungsarten
• Visionen und Ziele• Rahmenbedingungen
– z.B. Juristische Vorgaben• Kontext und Überblick
– Systemumgebung• Nichtfunktionale Anforderungen
– Qualitätsmerkmale• Funktionale Anforderungen
– Funktionen
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 35
Dozenten:Markus RentschlerAndreas Stuckert
Funktionale und nichtfunktionale Anforderungen
• Funktionale 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
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 36
Dozenten:Markus RentschlerAndreas Stuckert
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!
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 37
Dozenten:Markus RentschlerAndreas Stuckert
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organisationalrequirements
Externalrequirements
Non-functionalrequirements
Nichtfunktionale Anforderungen
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 38
Dozenten:Markus RentschlerAndreas Stuckert
Struktur einer AnforderungTypischerweise 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
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 39
Dozenten:Markus RentschlerAndreas Stuckert
Anforderungsbeschreibung
• Verbal– Fließtext, strukturierte Texte
• Non-Verbal– Grafische Notationen– Formale Sprachen
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 40
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 41
Dozenten:Markus RentschlerAndreas Stuckert
Natürlichsprachliche Anforderungen
• Die Anforderungsschablone der SOPHISTen
Darstellung der englischen Version
<When?>
The SYSTEM
SHALL
SHOULD
WILL
<process>
PROVIDE<whom?> THEABILITY TO <process>
BE ABLE TO<process>
<thing to be processed><process detail>
<Under whatconditions?>
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 42
Dozenten:Markus RentschlerAndreas Stuckert
Sprachliche Abhängigkeiten…
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 43
Dozenten:Markus RentschlerAndreas Stuckert
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
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 44
Dozenten:Markus RentschlerAndreas Stuckert
(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
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 45
Dozenten:Markus RentschlerAndreas Stuckert
Requirements Management
Version 04/26/23
Software Engineering I VE 03: Requirements Engineering 46
Dozenten:Markus RentschlerAndreas Stuckert
Requirements Coverage & Traceability