Seminar Softwaretechnik Requirements Management. 23. Juli 2007 Andreas Bäuml, Marcus Mews

Transkript

1 Seminar Softwaretechnik Requirements Management 23. Juli 2007 Andreas Bäuml, Marcus Mews

2 Requirements Management : Gliederung Gliederung Seite 2 Einführung Beobachtung des Systemkontext Management der Aktivitäten Inspektion und Review Priorisierung von Anforderungen Änderungsmanagement

3 Requirements Management : Einführung Seite 3

4 Requirements Management : Einführung Zentrale Managementaktivitäten: Seite 4 Beobachtung des Systemkontext Management der Aktivitäten Management der Anforderungsartefakte Nachvollziehbarkeit von Anforderungen Priorisierung von Anforderungen Änderungsmanagement

6 Beobachtung des Systemkontext Veränderungen im Kontext erkennen Auswirkungen der Veränderungen abschätzen Beobachtung der 4 Kontextfacetten Seite 6

7 Beobachtung des Systemkontext Techniken zur Kontextbeobachtung: Seite 7 Kontextscannen: Über die Grenzen des Kontext hinaus werden relevante Aspekte der Umgebung systematisch auf Veränderungen untersucht. Kontextmonitoring: Basiert auf der kontinuierlichen Aufzeichnung der Kontextentwicklung. Kontextprognose: Aufbauend auf vorherigen Ergebnissen wird eine Prognose für mögliche Veränderungen in der Zukunft aufgestellt.

8 Beobachtung des Systemkontext Beispiel Koordination der Kontextbeobachtung: Seite 8 Verantwortung für die Beobachtung des Marktes liegt beim Produktmanagement Produktmanagement muss Requirements-Ingenieure über neue Systeme anderer Marktteilnehmer informieren Requirements-Ingenieure analysieren die Situation und stellen die Ergebnisse dem Produktmanagement zur Verfügung.

10 Management der Aktivitäten Meist keine feste Abfolge von Aktivitäten für Requirements-Engineering Prozess definiert Ziel ist eine effektive Steuerung der Aktivitäten Ausgangsbasis ist das erreichte Niveau in den drei Dimensionen Dokumentation, Inhalt und Übereinstimmung Zwei mögliche Steuerungen: Seite 10 phasenorientiert anforderungsartefaktspezifisch

11 Management der Aktivitäten bei bekannten Anforderungen ist sequenzielle Ausführung der Phasen möglich Rücksprünge in andere Phasen sind jederzeit möglich Gewinnung Seite 11 Dokumentation Übereinstimmung Validierung

12 Management der Aktivitäten Bestimmung der nächsten Aktivität aufgrund der Bewertung des Anforderungsartefakts Vorteilhaft bei weitgehend unbekanntem Systemkontext Flexible Aktivitätsausführung Hoher Koordinationsaufwand Vorgehensweise erfolgt in zwei Schritten Seite 12 Bewertung Auswahl der Folgeaktivität

14 Inspektion und Review Inspektion und Review sind Validierungstechniken manuelle Prüfungen von Dokumenten und Software Ziel ist frühe Aufdeckung von Fehlern in Entwicklungsartefakten Formale Inspektion ist aufwändige Technik Es existieren auch weniger aufwändige Reviewtechniken Seite 14

15 Inspektion und Review Eigenschaften und Ziele von Inspektionen: Erhöhung von Effektivität und Effizienz bei Fehlerfindung Definierte Phasen Teilnehmer mit festen Rollen Unabhängigkeit der Prüfer Inspektionen sollten nicht zu selten stattfinden Seite 15

16 Inspektion und Review Phasen einer Inspektion: Planung, organisatorische Vorbereitung Überblicksveranstaltung Vorbereitung der einzelnen Inspektoren Inspektionssitzung Nacharbeit, Fehlerkorrekturen Überprüfung, Anfertigung der Berichte Seite 16

17 Inspektion und Review Seite 17

19 Priorisierung von Anforderungen Grundlagen der Priorisierung Techniken der Priorisierung Seite 19

20 Priorisierung von Anforderungen Priorität einer Anforderung dokumentiert die Bedeutung der Anforderung bzgl. Priorisierungskriterien Priorisierung erforderlich um Rangfolgen festzulegen In jeder der fünf Aktivitäten Gewinnung, Dokumentation, Übereinstimmung, Validierung und Management erforderlich Seite 20

21 Priorisierung von Anforderungen Vorbereitungsaktivitäten für die Priorisierung Seite 21 Bestimmung der Stakeholder Auswahl der zu priorisierenden Anforderungsartefakte Festlegung der Priorisierungskriterien Auswahl geeigneter Priorisierungstechnik

22 Priorisierung von Anforderungen Seite 22

23 Priorisierung von Anforderungen Ein-Kriterien-Klassifikation: Anforderungen werden hinsichtlich Wichtigkeit der Realisierung klassifiziert Prioritätsklassen: Seite 23 Mandatory: muss unbedingt umgesetzt werden Optional: wichtig, Fehlen ist aber unschädlich Nice-to-have: Fehlen ist absolut unschädlich Einteilung oft ungünstig, Kano-Klassifikation empfehlenswert

24 Priorisierung von Anforderungen Begeisterungsmerkmale: nicht erwartet unbewusst nicht artikuliert Zusatzmerkmale: bewusst artikuliert spezifiziert Zufriedenheit Erfüllungsgrad Seite 24 Basismerkmale: tendentiell unbewusst nicht artikuliert selbstverständlich

25 Priorisierung von Anforderungen Seite 25

27 Änderungsmanagement Definition: Das Änderungsmanagement beschreibt Funktionen und Prozesse, die in einer Organisation etabliert werden, um Änderungen an Produkten der Organisation kontrolliert und dokumentiert vorzunehmen. Kernelement ist die Änderungsanforderung. Nach ihrer systematischen Erfassung durchläuft sie einen Genehmigungsprozess. Nach Freigabe erfolgt die Änderungsdurchführung zu einem vorgegebenen Zieltermin. Beginnend vom Review spielt das Änderungswesen bis zum Ende des Produktlebenszyklus eine wichtige Rolle. Seite 27

28 Requirements Management : Gliederung Gliederung Seite 28 Einführung... Änderungsmanagement Ursachen für Änderungen von Anforderungen Konfigurationsmanagement Das Änderungsgremium Der Änderungsantrag Vorgehen für das Änderungsmanagement

29 Änderungsmanagement : Ursachen für Änderungen von Anforderungen Fehler im Betrieb: Trotz korrekter Umsetzung aller betreffenden Anforderungen kommt es zu Fehlverhalten während des Betriebs, bzw. Fehlverhalten beim Testen Änderungen in den Systemkontextfacetten Seite 29

30 Änderungsmanagement : Ursachen für Änderungen von Anforderungen Bezieht sich auf reale, im System abgebildete Aspekte Der Gesetzgeber verändert die Verordnung hinsichtlich der Genauigkeit der Ortung von Fahrzeugen über GPS von vorher <10m auf <5m. Seite 30

31 Änderungsmanagement : Ursachen für Änderungen von Anforderungen Veränderte Nutzungswünsche der Stakeholder z.b. Erweiterung der Softwarefunktionen Der Auftraggeber möchte zusätzlich, dass das zu entwickelnde Navigationssystem auch die Möglichkeit bietet, den Zielort per Spracheingabe zu erfassen. Seite 31

32 Änderungsmanagement : Ursachen für Änderungen von Anforderungen Betrifft Systemhardware und genutze Technologie Änderungen oft durch technologischen Fortschritt ausgelöst Durch die BlueRay-Technologie steht ein neues Medium zur Speicherung von Navigationsdaten zur Verfügung. Seite 32

33 Änderungsmanagement : Ursachen für Änderungen von Anforderungen Tritt im Verlauf des Entwicklungsprozess auf Anforderungen können nicht wie spezifiziert umgesetzt werden Anforderungen führen zu Fehlverhalten Seite 33

34 Änderungsmanagement : Ursachen für Änderungen von Anforderungen R-17: Das System soll weniger als 1,3 Sekunden zur Routenberechnung benötigen. R-34: Die berechnete Route soll pro 10 Kilometer mehr als 2 Wegpunkte aufweisen. Im Feinentwurf stellt sich heraus, dass die in R-17 definierte Performance des geplanten Systems die in R-34 definierte Genauigkeit der Ergebnisse nicht möglich macht und umgekehrt. Seite 34

36 Änderungsmanagement : Konfigurationsmanagement Verwaltung der Anforderungsartefakte findet auf 3 Ebenen statt: Dokumentenebene Artefaktebene Attributebene Betrifft immer die kleinsten, zu verwaltenden Einheiten Seite 36 Konfigurationsmanagement auf Attributebene sehr aufwändig und komplex

37 Änderungsmanagement : Konfigurationsmanagement Anforderungsartefakte werden durch eindeutige Nummern identifiziert durchlaufen verschiedene Versionen in verschiedenen Dimensionen: Seite 37 Kann detaillierter werden Übereinstimmung der Stakeholder kann sich ändern Dokumentationsform kann sich ändern (natürlichsprachlich oder modellbasiert)

38 Änderungsmanagement : Konfigurationsmanagement Konfigurationen fassen definierte Mengen logisch zusammenhängender Versionen von Anforderungserungsartefakte zusammen Eigenschaften: Konsistent (widerspruchsfrei, logisch zusammenhängend) Eindeutige Identifikation (ID) Nicht veränderbar, nachträgliche Änderungen nicht erlaubt Grundlage für evtl. Rücksetzen Basislinien sind Konfigurationen, die sich durch sichtbare Fortschritte auszeichnen. Seite 38

40 Änderungsmanagement : Änderungsgremium Bei größeren Projekten erforderlich Es sollten Stakeholder aus jeder Kontextfacette vertreten sein! Seite 40

41 Änderungsmanagement : Änderungsgremium Aufgaben: Seite 41 Kategorisierung eingehender Änderungen Anforderungsdefinition aufgrund neuer Änderungsanträge Bestimmung des Aufwands Beurteilung Aufwand/Nutzen Entscheidung über Annahme/Ablehnung Priorisierung angenommener Anforderungsänderungen Gruppierung/Zuordnung der angenommenen Anforderungsänderungen

43 Änderungsmanagement : Der Änderungsantrag Inhalt Projektname Antragsnummer Titel Datum Antragssteller Ursprung Status Priorität des Antragstellers Priorität der Umsetzung Prüfer der Änderung Aktualisierungsdatum Release Änderungsaufwand Beschreibung der Änderung Kommentare Seite 43 Beschreibung Titel der Änderung z.b. Marketing, Management, Kunde,... z.b. eingereicht, bewertet, abgelehnt, durchzuführen, überprüft, abgeschlossen Datum der letzten Aktualisierung Release, in dem die Anforderung umgesetzt werden soll (Prognose) -

45 Änderungsmanagement : Vorgehen für das Änderungsmanagement Änderungen werden in einem definierten Prozess kanalisiert Prozess betrachtet den Änderungsantrag vom Eingang bis hin zur Ablehnung / Einplanung der Änderung in Systemrelease Seite 45

46 Änderungsmanagement : Vorgehen für das Änderungsmanagement Arten von Änderungen: Integration einer neuen Anforderung Löschen einer bestehenden Anforderung Ergänzen einer bestehenden Anforderung Reduktion einer bestehenden Anforderung Kategorien: Seite 46 korrekiv: Fehlverhalten aufgrund falscher Anforderungen adaptiv: Kontextänderungen erfordern Anpassungen Ausnahmeänderung (hotfix): unbedingt notwendig und unmittelbar durchzuführende Änderung

47 Änderungsmanagement : Vorgehen für das Änderungsmanagement Auswirkungsanalyse Beurteilung der Änderung Annahme Ablehung Kommunikation der Ablehnung Priorisierung der Änderung Zuordnung der Änderung ins Projekt Seite 47

48 Änderungsmanagement : Vorgehen für das Änderungsmanagement Auswirkungsanalyse Gesamtaufwand ermitteln: Beurteilung der Änderung Ermittlung aller, von der Änderung betroffenen Anforderungen Ermittlung der Teilaufwände mittels Nachvollziebarkeitsinformationen Annahme Priorisierung der Änderung Zuordnung der Änderung ins Projekt Stehen keine Nachvollziehbarkeitsinformationen zur Verfügung, kann der Gesamtaufwand auch von Experten abgeschätzt werden. Seite 48 Ablehung Kommunikation der Ablehnung

49 Änderungsmanagement : Vorgehen für das Änderungsmanagement Auswirkungsanalyse Beurteilung der Änderung Annahme Priorisierung der Änderung Beurteilung der Änderung Zuordnung der Änderung ins Projekt Verhältnis Aufwand/Nutzen Ist sich das Änderungsgremium uneinig, können Übereinstimmungstechniken verwendet werden. Seite 49 Ablehung Kommunikation der Ablehnung

50 Änderungsmanagement : Vorgehen für das Änderungsmanagement Auswirkungsanalyse Beurteilung der Änderung Annahme des Änderungsantrags Priorisierung mittels Priorisierungstechniken Zuordnung zu Systemrelease unter Berücksichtigung etwaiger Abhängigkeiten Annahme Priorisierung der Änderung Zuordnung der Änderung ins Projekt Durchführung und Validierung übernimmt das Projektmanagement. Ablehnung des Änderungsantrags Kommunikation an die betroffenen Personen Seite 50 Ablehung Kommunikation der Ablehnung

52 Requirements Management : Übung Änderung eines Bibliotheksystems I Im Bibliothekssystem dürfen gesperrte Benutzer keine Bibliotheksexemplare zur späteren Ausleihe vormerken, damit eine Ausleihe für zugelassene Benutzer nicht blockiert wird. Änderungsantrag Projektname Antragsnummer Antragssteller Ursprung Status Priorität der Umsetzung Beschreibung der Änderung Seite 52 Anforderungsartefakt Bibliothekssytem 1028 Adrian Ringel (Bibliothekar) Kunde durchzuführen hoch Das System muss sicherstellen, dass kein gesperrter Benutzer ein Exemplar zur Ausleihe vormerken kann. Projektname Anforderungsnummer Titel Ursprung Anforderungsbeschreibung Bibliothekssytem 4711 Änderung der Rechte für gesperrte Nutzer Änderungsantrag 1028 Kein gesperrter Benutzer darf Bücher vormerken.

53 Requirements Management : Übung Änderungsantrag Projektname Antragsnummer Antragssteller Ursprung Status Priorität der Umsetzung Beschreibung der Änderung Bibliothekssytem 1028 Adrian Ringel (Bibliothekar) Kunde durchzuführen hoch Das System muss sicherstellen, dass kein gesperrter Benutzer ein Exemplar zur Ausleihe vormerken kann. Projektname Anforderungsnummer Titel Ursprung Anforderungsbeschreibung Bibliothekssytem 4711 Rechte für gesperrte Nutzer Änderungsantrag 1028 Kein gesperrter Benutzer darf Bücher vormerken. Projektname Antragsnummer Antragssteller Titel Beschreibung der Änderung Bibliothekssytem 1029 Heinz Müller (Software-Architekt) Änderung der Rechte für gesperrte Nutzer Die Forderung, dass berechtigte Benutzer nicht durch Vormerkungen gesperrter Benutzer blockiert werden dürfen, wird durch die Anforderung 4711 nicht vollständig erfüllt. Dazu müssten auch alle vorhandenen Vormerkungen eines gesperrten Benutzers gelöscht werden. Eine solche Anforderung wurde aber bisher nicht formuliert. Eine ergänzende Anforderung definieren, dass bei der Sperrung eines Benutzers dessen Vormerkungen gelöscht werden. Der Empfehlung wird gefolgt. Anforderung wird definiert -> Projektname Anforderungsnummer Titel Ursprung Anforderungsbeschreibung Bibliothekssytem 4712 Rechte für gesperrte Nutzer Änderungsantrag 1029 Wird ein Benutzer gesperrt, müssen alle seine Vormerkungen gelöscht werden. Empfehlung Reaktion Seite 53 Anforderungsartefakt

55 Requirements Management : Zusammenfassung Beobachtung des Systemkontext neue Änderungen Priorisierung durch Kontextveränderungen Änderungsmanagement Auswirkungsanalyse - Ranking - Top-Ten-Technik - Kano-Klassifikation -... Beurteilung der Änderung Annahme Anforderungen Ablehung Kommunikation der Ablehnung Priorisierung der Änderung Zuordnung der Änderung ins Projekt neue Anforderungen neue Änderungen durch z.b. Inkonsistenzen Management der Aktivitäten Gewinnung Seite 55 Dokumentation Übereinstimmung Validierung

56 Seminar Softwaretechnik Requirements Management 23. Juli 2007 Andreas Bäuml, Marcus Mews Quellen Pohl, Klaus: Requirements Engineering. Grundlagen, Prinzipien, Techniken. Heidelberg: dpunkt.verlag, Februar 2007 Liggesmeyer, P.: Software-Qualität. Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, 2002 Wiegers, Karl E.: Software-Requirements. Microsoft Press, [Stand: ]