Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Größe: px

Ab Seite anzeigen:

Download "Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG"

Guido Bergmann
vor 8 Jahren
Abrufe

1 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

2 "If you don't know where you are going, you are unlikely to end up there." Forrest Gump 2

3 Anforderungen bilden die Grundlage für jedes (Software-)Projekt sind die Vorgabe für den Entwurf und die Entwicklung und andererseits auch die Basis für die Validierung und Verifikation des Ergebnisses der Entwicklung sind in der Praxis oft - ungenau - unzureichend dokumentiert - widersprüchlich - wenig stabil über die Projektlaufzeit gesehen 3

und Verifikation des Ergebnisses der Entwicklung sind in der Praxis oft - ungenau -

4 Begriffe: Anforderung Definition 1 - Eine Bedingung oder Eigenschaft, die ein System oder eine Person benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. - Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkomponente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard, einer Spezifikation oder einem anderen formell auferlegten Dokument zu genügen. - Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft wie in 1. oder 2. definiert. Anforderungen beschreiben somit die Bedürfnisse von Benutzern an ein System, aber auch Eigenschaften, die durch Rahmenbedingungen, z. B. gesetzliche Regelungen, definiert sind. Aus Position 3 der Definition folgt, dass sowohl nicht dokumentierte Bedingungen und Eigenschaften im Sinne von Position 1 und 2 als auch deren dokumentierte Form als Anforderung bezeichnet werden. 1 K. Pohl: Requirements Engineering. dpunkt.verlag, Heidelberg, 1. Auflage

auferlegten Dokument zu genügen. - Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft wie in 1. oder 2. definiert.

5 Stakeholder als Anforderungsquellen Ein Stakeholder ist nach PMBOK 1 - eine Person oder eine Organisation - die ein begründetes Interesse am Projekt-Erfolg und/oder am Projektnutzen hat - welche aktiv am Projekt beteiligt ist oder durch den Projektverlauf oder das Projektergebnis beeinflusst wird, respektive ihn beeinflussen kann Stakeholder sind wichtige Anforderungsquellen - Frühzeitige Integration aller Gruppen von Stakeholdern bereits in der Analysephase eines Projekts minimiert das Risiko später (und somit teurer) Änderungen am System Probleme - Interessenskonflikte Priorisierung von Anforderungen - Interessen von Stakeholdern ändern sich während der Projektlaufzeit Anforderungsmanagement notwendig 1 Der Guide to the Project Management Body of Knowledge (PMBOK Guide) ist ein weit verbreiteter Projektmanagement-Standard und zentrale Referenz des US-amerikanischen Project Management Institute, von dem er auch herausgegeben und unterhalten wird. 5

Integration aller Gruppen von Stakeholdern bereits in der Analysephase eines Projekts minimiert das Risiko später (und somit teurer) Änderungen am System Probleme - Interessenskonflikte Priorisierung

6 Quelle: 6

7 Stakeholder in einem mittelgroßen Softwareprojekt Kunde/Auftraggeber Geschäftsführung/Abteilungsleiter (Auftraggeber- und Auftragnehmerseite) Promotor Legacy Owner (Besitzer des Altsystems oder der Altdaten) Betreiber/Entwickler von Schnittstellensystemen (Systemen, mit denen integriert wird) Benutzer/Benutzervertreter (pro Benutzergruppe) Projektleiter Projektsteuergruppe Systemarchitekten/IT-Stratege Softwareentwickler Qualitätssicherung und Test Betrieb Wartung Frühzeitige Beteiligung reduziert notwendige Anpassungen bei Inbetriebnahme 7

(Systemen, mit denen integriert wird) Benutzer/Benutzervertreter (pro Benutzergruppe) Projektleiter Projektsteuergruppe

8 Weitere Anforderungsquellen Standards und Normen Datenschutz Gesetze Anforderungen und Funktionsweisen von alternativen Systemen (z. B. von Konkurrenzanbietern oder Altsysteme) Verdeckte Regeln - Tabus - Macht - Werte - Einstellungen - Status - 8

9 Anforderungsvolatilität Anforderungen ändern sich ständig Notwendigkeit, auf Anforderungsänderungen zu reagieren und später im Softwareprojekt Änderungen mit geringen Kosten durchführen zu können Strategisches Vorgehen Unterteilung der Anforderungen in zwei Klassen - Stabile Anforderungen Anforderungen, die sich voraussichtlich nicht oder nur geringfügig ändern werden - Volatile Anforderungen Anforderungen, die sich voraussichtlich während der Anforderungsanalyse oder während des Betriebes des Systems ändern werden Direkte Auswirkung auf das Systemdesign - Stabile Anforderungen können mit einfachen Designs bzw. "hard-wired" implementiert werden - Umsetzung volatiler Anforderungen erfordert ein adaptives Systemdesign ("softwired") - Stabile Anforderungen können früher und detaillierter dokumentiert bzw. modelliert werden - Stabile Anforderungen können früher im Entwicklungsprozess realisiert werden 9

Anforderungen, die sich voraussichtlich während der Anforderungsanalyse oder während des Betriebes des Systems ändern werden Direkte Auswirkung auf das Systemdesign - Stabile Anforderungen können mit

10 Klassifikation von Anforderungen Funktionale Anforderungen - Beschreibung der Funktionen/Services, die das System zur Verfügung stellen soll - Klärung, wie das System auf bestimmte Eingaben und spezielle Situationen reagieren soll Nichtfunktionale Anforderungen - Anforderungen an die Funktionen/Services, die nicht deren Verhalten, sondern Vorgaben z. B. an Qualitätseigenschaften, den Entwicklungsprozess, einzuhaltende Standards und Normen und gesetzliche Rahmenbedingungen beschreiben Fachliche Anforderungen (Domänenanforderungen 1 ) - Funktionale oder nichtfunktionale Anforderungen, die von der Domäne des Systems definiert werden und die besonderen Eigenschaften/Einschränkungen dieses Gebietes darstellen Domänenanforderungen sind oft inhärent und nicht explizit pro Projekt definiert. 1 Eine Domäne bezeichnet im Systems Engineering und in der Softwaretechnik ein abgrenzbares Problemfeld oder einen bestimmten Einsatzbereich für Computersysteme oder Software. 10

an Qualitätseigenschaften, den Entwicklungsprozess, einzuhaltende Standards und Normen und gesetzliche Rahmenbedingungen beschreiben Fachliche Anforderungen (Domänenanforderungen 1 ) - Funktionale

11 Was sind gute Anforderungen? Theorie - Vollständigkeit - Konsistenz Probleme in der Praxis - Verständlichkeit Jede Domäne hat ihre eigene "Sprache" wird von Softwareingenieuren häufig nicht verstanden - Selbstverständlichkeit Domänen-Spezialisten sind mit der Domäne so vertraut, dass sie bestimmte Anforderungen als selbstverständlich ansehen und nicht explizit kommunizieren - Unzureichende Präzision Präzise Definition von Anforderungen ist schwierig, ohne die Lesbarkeit zu beeinträchtigen - Vermischung Funktionale und nichtfunktionale Anforderungen werden häufig vermischt - Zusammenführung Verschiedene Anforderungen werden gemeinsam beschrieben, ohne diese genau voneinander abzugrenzen - Mehrdeutigkeit Spezifikationen in natürlicher Sprache sind oft mehrdeutig 11

Selbstverständlichkeit Domänen-Spezialisten sind mit der Domäne so vertraut, dass sie bestimmte Anforderungen als selbstverständlich ansehen und nicht explizit kommunizieren - Unzureichende

12 Qualitätsattribute von Anforderungen (1) Vollständig - Explizite Beschreibung aller Anforderungen - Keine impliziten Annahmen der Stakeholder über das zu entwickelnde System Eindeutig definiert/abgegrenzt - Präzise Definitionen helfen, Missverständnisse zwischen Stakeholdern zu vermeiden Verständlich beschrieben - Stakeholder müssen die gesamte Anforderung unter vertretbarem Aufwand lesen und verstehen können Identifizierbar - Eindeutige Identifizierbarkeit jeder Anforderung (z. B. über Anforderungs-ID) Atomar - Nur eine Anforderung pro Anforderungs-ID 12

Stakeholdern zu vermeiden Verständlich beschrieben - Stakeholder müssen die gesamte Anforderung unter vertretbarem Aufwand lesen und

13 Qualitätsattribute von Anforderungen (2) Einheitlich dokumentiert - Ein Dokument mit allen Anforderungen, gleiche Struktur für alle Beschreibungen Notwendig - Klärung, ob alle Anforderungen unabdingbar sind Nachprüfbar - Verknüpfung der Anforderungen mit Abnahmetestfällen, damit bei der Abnahme geprüft werden kann, ob alle Anforderungen erfüllt wurden Vorwärts- und Rückwärtsverfolgbarkeit - Erkennbar, ob jede Anforderung vollständig erfüllt wurde - Für jede implementierte Funktion ist ersichtlich, aus welcher Anforderung sie resultiert keine überflüssigen Systemeigenschaften Priorisiert - Berücksichtigung der Priorität im Entwicklungsprozess (z. B. durch die Reihenfolge der Realisierung) 13

erfüllt wurden Vorwärts- und Rückwärtsverfolgbarkeit - Erkennbar, ob jede Anforderung vollständig erfüllt wurde - Für jede implementierte Funktion ist ersichtlich, aus

14 Was sonst noch zu klären ist Nach der ersten Erhebung der Anforderungen stellen sich evtl. zwei entscheidende Fragen: - Muss man "das Rad nochmals erfinden" oder können (Teil-)Systeme fertig gekauft werden?? - Ist das Projekt überhaupt realisierbar bzw. Erfolg versprechend oder sollte es rechtzeitig bevor es richtig begonnen hat gestoppt werden? 14

(Teil-)Systeme fertig gekauft werden?? - Ist das Projekt überhaupt realisierbar bzw.

15 Make or Buy Wichtige Fragestellung in Softwareprojekten - Individuelle Entwicklung der technischen Komponenten (make) oder - Einsatz von COTS- (Commercial of the Shelf-) Systemen (buy) Entscheidung beeinflusst die weitere Analyse, den Entwicklungsprozess, die Wartung Wichtige zu berücksichtigende Aspekte - Abdeckung des aktuellen und des antizipierten Projekt-Scopes - Entwicklungskosten - Lizenzkosten (Anschaffung und laufender Betrieb) - Anpassungsmöglichkeiten und Anpassungsaufwand - Schulungsaufwand für Entwickler und Betreiber - Hardwareanforderungen - Support und Wartung - Nutzung von offenen oder proprietären Protokollen oder Formaten - Herstellerabhängigkeit (Vendor Lock-In) - Besitzverhältnisse - Weitere strategische Elemente, z. B. Weiterverkaufsmöglichkeit einer Neuentwicklung 15

Lizenzkosten (Anschaffung und laufender Betrieb) - Anpassungsmöglichkeiten und Anpassungsaufwand - Schulungsaufwand für Entwickler und Betreiber - Hardwareanforderungen - Support und Wartung -

16 Machbarkeit und Machbarkeitsstudie Umsetzbarkeit des Vorhabens muss ggf. geprüft werden, wenn es technisch oder organisatorisch sehr neuartig ist In diesen Fällen: Machbarkeitsstudie - Analytisch oder - Prototypische Umsetzung kritischer Systemteile - Inhalte einer Machbarkeitsstudie können sein: Identifikation des Inventionsanteils Identifikation von ähnlichen Systemen Technische Modellierung Technische Prototypen Rechtliche Prüfung Akzeptanzanalyse bei den zukünftigen Benutzern Identifizierung der wesentlichen Kostentreiber Kostenanalyse Ergebnis: Go / No-Go-Entscheidung 16

Umsetzung kritischer Systemteile - Inhalte einer Machbarkeitsstudie können sein: Identifikation des Inventionsanteils Identifikation von

Ähnliche Dokumente

Requirements Engineering für IT Systeme

Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein