Einführung und Motivation

Größe: px

Ab Seite anzeigen:

Download "Einführung und Motivation"

Imke Kaiser
vor 8 Jahren
Abrufe

2 Einführung und Motivation iks-thementag: Requirements Engineering Autor Carsten Schädel

3 Motto Definiere oder Du wirst definiert. Seite 3 / 51

4 These Im Privatleben definiert jeder (seine) Anforderungen. Seite 4 / 51

5 Frage Wieso gibt es dann in Projekten oft Schwierigkeiten/ Missverständnisse? Seite 5 / 51

6 Zentrale Frage Braucht man Requirements Engineering (in allen Projekten)? Seite 6 / 51

7 Ein paar Aussagen Seite 7 / 51

8 Aussagen Können Sie jetzt nicht erst einmal anfangen? Seite 8 / 51

9 Aussagen Wir brauchen es aber schnell (richtig machen können wir es später noch) Seite 9 / 51

10 Aussagen Ich muss es erst sehen, bevor ich es beschreiben kann. Seite 10 / 51

11 Aussagen So habe ich mir das aber nicht vorgestellt! Seite 11 / 51

12 Aussagen Genauso haben Sie es aber beschrieben! Seite 12 / 51

13 Aussagen Ich glaube, da haben wir aneinander vorbei geredet. Seite 13 / 51

14 Aussagen Woher soll ich das alles so genau wissen? Seite 14 / 51

15 Aussagen Naja, aber das ist doch selbstverständlich. Seite 15 / 51

16 Aussagen Das hätten Sie eigentlich wissen müssen. Seite 16 / 51

17 Aussagen Seite 17 / 51

18 Mögliche Ursachen Lange Kommunikationswege Fehlendes Verständnis zwischen Projektbeteiligten Fehlende Möglichkeit einer Probefahrt Nicht die Richtigen werden gefragt Seite 18 / 51

19 Zentrale Frage Braucht man Requirements Engineering (in allen Projekten)? Seite 19 / 51

20 Braucht man RE? Man braucht kein Requirements Engineering Seite 20 / 51

21 Braucht man RE? wenn man mit allem zufrieden ist. Seite 21 / 51

22 Braucht man RE? JA, man braucht Requirements Engineering! Seite 22 / 51

23 Wie der Auftraggeber es beschrieben hat Seite 23 / 51

24 Wie der Projektleiter es verstanden hat Seite 24 / 51

25 Wie es der Systemanalytiker entworfen hat Seite 25 / 51

26 Wie es der Programmierer umgesetzt hat Seite 26 / 51

27 Was der Beta-Tester bekommen hat Seite 27 / 51

28 Was der Auftraggeber eigentlich wollte Seite 28 / 51

29 Was der Auftraggeber bezahlt hat Seite 29 / 51

30 Ungenaue Anforderungen haben Einfluss auf Qualität Termine Zufriedenheit Zusammenarbeit Kosten Seite 30 / 51

31 Studie von 2007 Quelle: Computerwoche Der Kostenfaktor: Wie Untersuchungen ergeben, fließen durchschnittlich etwa 40 Prozent eines vorgegebenen Projektbudgets in Nachbesserungen. Seite 31 / 51

32 Studie von 2007 Quelle: Computerwoche Jedes vierte Projekt verfehlte sein Ziel Seite 32 / 51

33 Anforderungen beziehen sich auf Fachlichkeit Software Architektur Entwicklung Umgebung Dokumentation Seite 33 / 51

34 Anforderungen haben zentrale Bedeutung für die Entwicklung sind von rechtlicher Relevanz sind komplex sollten für alle Beteiligten zentral verfügbar sein Seite 34 / 51

35 RE ist Kommunikation Vereinheitlichung von Sprache Schaffung von Verständnis Konfliktlösung Bereitstellung von Anforderungen die den Qualitätsansprüchen aller Adressaten genügen Seite 35 / 51

36 Nichts wirklich Neues Seite 36 / 51

37 Studie von 2008 Quelle: Computerwoche Das Requirements Engineering muss professioneller werden, denn es ist häufig die Ursache für Projektfehlschläge, so die FHS St. Gallen. Seite 37 / 51

38 Bestellt Seite 38 / 51

39 Bekommen Seite 39 / 51

40 Frage Wieso gibt es dann in Projekten oft Schwierigkeiten/ Missverständnisse? Seite 40 / 51

41 Bestellt Seite 41 / 51

42 Bekommen Seite 42 / 51

43 Schwierigkeiten? RE will gelernt sein Benötigte Zeit für RE wird unterschätzt Stakeholder haben unterschiedliche Ziele Eventuell möchte man zu viel Es gibt keinen Königsweg Seite 43 / 51

44 Studie von 2007 Quelle: Computerwoche McKinsey: Requirements Engineering. [ ] Wer diesen Prozess beherrscht, kann den Beratern zufolge Produktivitätsgewinne von 10 bis 15 Prozent erzielen. Seite 44 / 51

45 3 Definitionen Seite 45 / 51

46 Definition Eine Anforderung ist 1. Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. 2. Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen. 3. Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß (1) oder (2). [ Quelle: Basiswissen Requirements Engineering ] Seite 46 / 51

47 Definition Eine Stakeholder ist Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat. [ Quelle: Basiswissen Requirements Engineering ] Seite 47 / 51

48 Definition Requirements Engineering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass: 1. alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind, 2. die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen, 3. alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind. [ Quelle: Basiswissen Requirements Engineering ] Seite 48 / 51

49 Ziel des Thementages Seite 49 / 51

50 Motto Definiere oder Du wirst definiert. Seite 50 / 51

51 Ziel Definiere oder Du wirst definiert. Seite 51 / 51

Ä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