REQUIREMENTS-MANAGEMENT. Dr. Peter Hruschka

Transkript

1 1 Requirements Engineering! REQUIREMENTS-MANAGEMENT Dr. Peter Hruschka TEIL 12 Requirements-Management Atlantic Systems Guild Aaachen London New York

2 2 Was ist Requirements Management? Festlegung von Rollen, Vorgehensweisen, Dokumenten und Tools Attribute, die pro Requirement verwaltet werden sollten Prioritäten setzen Change/ Problem Management Traceability

3 3 DEFINITION " REQUIREMENTS MANAGEMENT

4 4 Requirements Management umfasst zwei Gruppen von Tätigkeiten: 1. Vorbereitende Tätigkeiten (eher einmalig, oder pro Abteilung, pro Projekt) RE-Prozess festlegen Dokumentenstruktur festlegen Tools auswählen und einführen Prüfverfahren und Checklisten etablieren Laufende Tätigkeiten Requirements-Attribute setzen und pflegen (incl. Traces, Status,...) priorisieren, gewichten (Releases bilden) Change Requests bearbeiten...

5 5 ermitteln" dokumentieren" Anforderungen" verwalten" prüfen & abstimmen"

6 6 Requirements Management umfasst alle Maßnahmen, welche die Anforderungsanalyse und die weitere Verwendung der Anforderungen unterstützt. " Dies schließt das Verwalten von weiteren Informationen rund um die einzelnen Anforderungen... und deren weitere Verwendung... mit ein. [Rupp]... Planung und Lenkung des RE-Prozesses" Konfigurationsmanagement für Anforderungen - Identifikation" - Änderungs- und Freigabewesen" Rückverfolgbarkeit [Martin Glinz, Uni Zürich]

7 7 Requirements Management ist um so wichtiger je höher die Anzahl der Anforderungen ist... je länger die geschätzte Lebensdauer der Software ist... je häufiger Anforderungen geändert werden... je höher die Anzahl der Beteiligten ist... je schlechter die Verfügbarkeit der Stakeholder ist... je höher die Qualitätsansprüche an die Software sind... je mehr Wiederverwendung betrieben werden soll... je komplexer der (RE-)Prozess ist... je inhomogener die Stakeholdermeinungen sind... je mehr Releases/Sprints entwickelt werden sollen... falls Sie Produktfamilien beschreiben

8 8 VORBEREITENDE TÄTIGKEITEN

9 9 Vorgehensmodell für RE festlegen Aktivitäten und (Zwischen-)Ergebnisse Rollen Dokumentationsmethoden und Werkzeuge Strategie der Anforderungsgewinnung (Erhebungstechniken, Prototypen, Ist-Analyse,...) Planung der Validierung der Anforderungen " (wer, wann und wie oft, wie)

10 10 DER REQUIREMENTS-PROZESS

11 Die Extreme: Spezifiziere Anforderungen Rational Unified Process (ca 2000 HTML-Seiten" Beschreibung)

12 12 Marketing Requirements vorgeben FEATURE LIST" User- Requirements ausarbeiten USER REQUIREMENTS SPECIFICATION Requirements- Modellierung &" dokumentation SOFTWARE REQUIREMENTS SPECIFICATION

13 The! VOLERE! Requirements! Process!

14 14 SEIEN SIE PRAGMATISCH: Genügend Festschreibungen, um Requirements- Kultur in einem Unternehmen zu etablieren Genügend Freiheitsgrade Wegen der Unterschiede der Kunden und anderer Stakeholder Jeder liebt andere Notationen, Tools, Vorgehensweisen Wegen der unterschiedlichen Projekttypen Klassisch: eher Wasserfall Innovativ: eher mit Prototypen... Wegen der unterschiedlichen Branchen und Domänen Kommerzielle Systeme: eher Datenmodell, Ablaufmodelle Embedded Systems: verstärkt Zustandsautomaten... Keine zu detaillierten Fesseln für größere Gruppen! Prozess nicht überspezifizieren!

15 15 ROLLEN

16 Die Extreme: Keine spezifische Rolle Viele spezifische Rollen

17 17 Requirements Engineer/Systemanalytiker " (Ermittlung, Dokumentation, Modellierung, Analyse und Qualitätssicherung von Anforderungen) Fachexperte (Know-How-Träger) Verantwortlicher Fachexperte (Entscheider) Tester (Überprüfung auf korrekte Erfüllung von Anforderungen) Projektleiter (juristische Verantwortung)

18 18 LAUFENDE TÄTIGKEITEN

19 19 Attributierung von Requirements Sichtenbildung Priorisierung Baselining Versionsverwaltung Change Management Traceability

20 20 ATTRIBUTIERUNG VON REQUIREMENTS

21 21 z.b: Requirements Status eingegangen dokumentiert/formalisiert geprüft abgelehnt endgültig akzeptiert

22 Schublade aus VOLERE Requirements #: Nummer Req-Kategorie: Event/Use Case: Beschreibung: Ein Satz über die Intention der Anforderung 22 Zuordnung zu Geschäfts- Prozess/Use Case Begründung: Eine Begründung für die Anforderung Quelle: Wer hat die Anforderung gestellt? Abnahmekriterium: Ein Prüfkriterium für die Anforderung, so dass man testen kann ob die Lösung die ursprüngliche Anforderung erfüllt Andere Anforderungen Kundenzufriedenheit: Kundenunzufriedenheit: Konflikte: die nicht erfüllt werden können, Priorität: Eine gewichtete Einschätzung des Wertes dieser Anforderung wenn diese erfüllt wird. Abhängigkeiten: Eine Liste anderer Anforderungen, die Abhängigkeiten von dieser haben. Hintergrund: Historie: Anlage, Änderungen, Löschungen Grad der Stakeholder-Zufriedenheit wenn diese Anforderung erfolgreich implementiert wird Skala von 1 = nicht interessant bis 5 = extrem erfreut Verweis auf Dokumente die diese Anforderung näher erläutern VOLERE Atlantic Systems Guild Grad der Stakeholder-Unzufriedenheit wenn diese Anforderung nicht im endgültigen Produkt erfüllt ist. Skale von 1 = kaum wichtig to 5 = extrem enttäuscht

23 23 Welche Attribute verwaltet man pro Requirement *)? Eine eindeutige Identifizierung Autor (der das Requirement verfasst hat) Verantwortlicher (der den Inhalt der Anforderungen verantwortet) Nächster Bearbeiter Status Version Ableitungen/Zerlegungen, Abhängigkeiten, Konflikte Bearbeitungs-/Änderungshistorie *) Nach [Rupp]

24 24 Wie viele Attribute sollen oder wollen Sie verwalten?!

25 25 SICHTENBILDUNG

26 26 Attribute als Basis zur Sichtenbildung, z.b. jedem Stakeholder seine relevanten Requirements zur Prüfung vorlegen Für Manager nur die höheren Ebenen herausfiltern Für Juristen nur rechtliche Anforderungen selektieren...

27 Sichten erlauben Selektion nach Stakeholderinteresse besseren Überblick Leichteres Erkennen von Abhängigkeiten und Beziehungen (z.b. alles Glossareinträge zu diesem Use-Case)

28 28 PRIORISIERUNG

29 29 Wert für den Kunden Kunden Unzufriedenheit Kundenzufriedenheit L L L L L 2 L L L M M 3 M M M M M 4 M M H H H 5 H H H H H

30 30 Neben der Wichtigkeit für den Kunden spielen evtl. auch folgende Aspekte eine Rolle: Wie passen die Anforderungen zu den übergeordneten Geschäftszielen? Wie häufig wurde diese Anforderung genannt? Was kostet die Umsetzung? Ist es in der Zeit und im Budget realisierbar? Wie risikoreich ist die Implementierung? Wie dringend ist es? Wann muss es gemacht werden? (in welchem Release?, Time to Market) Welche (finanziellen) Auswirkungen hat das Requirement auf unseren Geschäftserfolg? Welche Auswirkungen hat das Requirement auf das laufende System?...

31 31 Jeder Faktor bekommt ein Gewicht (in %) Die endgültige Priorität errechnet sich aus der Summe der gewichteten Faktoren Requirement/ Use Case/ Feature Factor + % weight Factor + % weight Factor + % weight Factor + % weight Requirement Priority Req # score score score score total Pro Faktor werden Werte zwischen 1 und 10 vergeben, die die Priorität entsprechend diesem Faktor entsprechen und dann mit dem Gewichtungsfaktor multipliziert.

32 32 Volere Priorisierungsmatrix Requirement/" Product Use Case/" Feature No Factor - score out of 10 %Weight applied Factor - score out of 10 %Weight applied Factor - score out of 10 %Weight applied Factor - score out of 10 %Weight applied %Weight applied Total Weight Value to Customer 40 Value to Business 20 Minimise Implementat ion Cost 10 Ease of Implementati on 30 Priority Rating 100 Requirement ,8 7 1,4 3 0,3 8 2,4 4,9 Requirement ,2 8 1,6 5 0,5 7 2,1 7,4 Requirement ,8 3 0,6 7 0,7 4 1,2 5,3 Requirement ,4 8 1,6 3 0,3 5 1,5 5,8 Requirement ,1 3 0,9 4 Requirement ,2 6 0,6 5 1,5 6,9 Requirement ,6 6 0,6 7 2,1 4,9 Requirement Requirement Requirement Requirement Requirement Requirement

33 33 Wozu Prioritäten? Was ist uns wichtig (wenn wir nicht für alles Zeit und Geld haben) Was kommt in einem früheren Release? Worauf müssen wir beim Testen besonders viel Wert legen?

34 34 BASELINES & RELEASES

35 35 Baseline = eine Menge von Anforderungen, die zu einem" bestimmten Zeitpunkt gebündelt und" eingefroren werden als Basis für den" nächsten Systemrelease. = eine freigegeben Konfiguration von Anforderungen" Req1! Req8! Baseline1! Req17! Req23! Req48! Req97!

36 36 R R R R R R R D D D D D D D I I I I I I I T T T T T T T Req. Baseline 1 SW Release 1 Req. Baseline 3 SW Release 3 Req. Baseline n SW Release n Um inkrementelles, iteratives Arbeiten zu ermöglichen muss der Status der Requirements (bzw. die Zugehörigkeit zu Releases) klar gekennzeichnet sein.

37 37 CHANGE MANAGEMENT

38 38 Nach Übergabe oder Einfrieren von Anforderungen (nach Bildung einer Baseline): --> Grundsätzlich sauberes Change Management Stakeholder: Change Request gemäß den vereinbarten Spielregeln stellen" (auf deutsch: einen Änderungsantrag stellen) CCB (Change Control Board): Change Request behandeln, d.h. Prüfen, bewerten und Konsequenzen feststellen Evtl. verhandeln (tauschen, Zusatzaufwand, nur eine Klarstellung,...) Entscheiden Entscheidung dem Stakeholder mitteilen

39 39 Versionsmanagement " (einzelner Anforderungen) ist Voraussetzung für > Konfigurationsmanagement (Baselining) akzeptierte Änderungen" werden in eine bestimmten" Baseline aufgenommen ist Auslöser für > Change- Management (Änderungsmanagement)

40 40 Change Management in VOLERE -> Kap. 26: Der Warteraum Anforderungen und Änderungswünsche, die nach Festlegung des Umfangs eines Releases entstehen, kommen in den Warteraum Bei Release-Planungsmeetings werden die Anforderungen im Warteraum (und alle anderen) evtl. neu priorisiert und entsprechend verschoben Aus dem Warteraum in die anderen Kapitel Aus anderen Kapiteln zurück in den Warteraum

41 41 Releaseplanung Neue Anforderungen, Change Requests Project drivers! "1. The Purpose of the Product! "2. The Stakeholders! Project constraints! "3. Mandated Constraints! "4. Naming Conventions and Terminology! "5. Relevant Facts and Assumptions! Functional requirements! "6. The Scope of the Work! "7. Business Data Model & Data Dictionary! "8. The Scope of the Product! "9. Functional and Data Requirements! Non-functional requirements! "10. Look and Feel Requirements! "11. Usability Requirements! "12. Performance & Safety Requirements! "13. Operability Requirements! "14. Maintainability & Portability Requirements! "15. Security Requirements! "16. Cultural and Political Requirements! "17. Legal Requirements! Project Issues! "18. Open Issues! "19. Off-the-shelf Solutions! "20. New Problems! "21. Tasks! "22. Cutover! "23. Risks! "24. Costs! "25. User Documentation and Training! "26. Waiting Room! "27. Ideas for Solutions! Releaseplanung

42 42 TRACEABILITY

43 Nachvollziehbarkeit: Pre- und Post-Traceability, " Traceability innerhalb der Anforderungen 43 Wünsche Requirements Pre-Traceability Requirements Post-Traceability Dokumentation Altsystem Visionen A1 A6 A4 Verträge Standards, Normen A3 A2 A5 Design, Implementation Quellen für " Requirements Requirements Tests

44 44 Voraussetzung für Nachvollziehbarkeit: Ein eindeutiger ID für jede Anforderung Klare Ziele, warum Nachvollziehbarkeit wichtig ist Eine Definition was nachvollziehbar sein soll Eine Festlegung der Detaillierungs-/Abstraktionsebene für die Nachvollziehbarkeit Eine Festlegung der Struktur und des Inhalts der Trace-Daten

45 45 Nutzen von Traceability: Vollständigkeit: Sind alle URS-Anforderungen in der SRS abgedeckt? Sind alle SRS-Anforderungen in dem TDD abgedeckt? Auswirkungen von Änderungen: Welche URS-Anforderungen sind bei einer Änderung an einem bestimmten Modul im Design unter Umständen betroffen? Welche URS-Anforderungen sind bei einer Änderung an der SRS betroffen? Aufwandsaussagen: Wie viele Module müssen angepackt werden, wenn diese Anforderungen geändert werden?

46 46 Traceability verlangt irgendwie geartete IDs von tracebaren Objekten, damit diese verlinkt werden können Setzt Version-Management voraus, damit Links nicht durch Änderungen an Requirements unabsichtlich ungültig werden. Req A V1 Req. B V1 Req. A V2?

47 47 Die Menge theoretisch möglicher Links ist selbst für kleine Systeme sehr groß. Wo liegt die Amortisation? Daher... Tracen Sie nur das absolut Notwendige (entsprechend Ihren Trace-Zielen) Verkaufen Sie Vorteil und Ziele an diejenigen, die die Links aufbauen und pflegen müssen. Vergleichen Sie ernsthaft Nutzen mit Aufwand und Kosten Wählen Sie die Abstraktionsebene, auf der die Links definiert werden sollen, sehr sorgfältig. (Dokument, Use- Case, Atomare Anforderung, Attribute in Datenmodellen,...)

48 Treffen Sie für jedes Thema (Attribute, Priorisierung, Baselines, Change Management, Traceability,...) gezielte Entscheidungen, wie Sie damit umgehen wollen (oder müssen). Jede Entscheidung kann Requirements- Management entweder wesentlich einfacher oder wesentlich komplexer machen.

49 ZUSAMMENFASSUNG

50 50 Für gutes Requirements-Management müssen Sie (möglichst einmalig) folgendes regeln: Wer darf/muss mitspielen? (die Rollen) Wie läuft der RE-Prozess ab? (Ihre Vorgehensweise, Ihre Ergebnisdokumente) Was halten wir pro Requirement fest? (Ihre Attribute) Und im laufenden Projekt Wie wichtig ist die Anforderung? (Prioritäts- und Statusentscheidung; Releasebildung) Wie gehen Sie mit Änderungen um? (Change- und Configuration-Management) Wie viel Traceability brauchen Sie?