ANFORDERUNGSANALYSE UND‐SPEZIFIKATION

3. KapitelSPEZIFIKATION

TEIL 2

Software Engineering

Prof. Dr. Wolfgang Schramm

Übersicht1

1. Einführung in das Software Engineering

2. Softwareprozesse3 A f d l d3. Anforderungsanalyse und

‐Spezifikation4 UML4. UML5. Softwareentwurf6. Entwurfsmuster7. Programmierung8. Software‐Qualitätssicherung und ‐

Prüfung9. Konfigurationsverwaltung10. Software‐Wartung

Lernziele des Kapitels2

Sie lernen die wichtigsten Begriffe des Requirements Engineering (RE) kennenRequirements Engineering (RE) kennen.

Sie verstehen, warum der Anforderungsprozess wichtig ist.

Sie lernen die verschiedenen Arten von Sie lernen die verschiedenen Arten von Anforderungen kennen.

Sie lernen, welche Tätigkeiten zum Anforderungsprozess gehören und wie g p gder Anforderungsprozess abläuft.

Sie lernen, welche Personen an der Anforderungsphase beteiligt sind.

Sie lernen welche Dokumente erstellt werden müssen und wie sie aufgebaut sind.

Sie lernen wie man mit Anforderungen und mit Kunden umgeht.

Sie lernen verschiedene Techniken für die Erhebung der Anforderungen kennenErhebung der Anforderungen kennen.

Inhalt3

3. Anforderungen3 1 Einführung / Motivation3.1. Einführung / Motivation3.2. Requirements Engineering (RE)3.3. Bestandteile der Dokumentation3 4 E h b A f d3.4. Erhebung von Anforderungen3.5. Zielgruppen der Anforderungen3.6. Anforderungsarten3.7. Notation für Anforderungen3.8. Dokumentation der Anforderungen3.9. Aufbau und Inhalt der Spezifikation/ des Pflichtenheftsp3.10. RE Prozess3.11. Erheben der Anforderungen, Techniken der Erhebung3 12 Anforderungsmanagement3.12. Anforderungsmanagement3.13. Qualitätssicherung von Anforderungen3.14. Änderungsmanagement3 15 Anwendungsfälle für die Anforderungsanalyse3.15. Anwendungsfälle für die Anforderungsanalyse

Aktivitäten4

Kernaktivitäten Erhebung/Herausfinden/Elicitation Dokumentation

Querschnittsaktivitäten Management

der Anforderungsartefakte Planung, Steuerung und Kontrolle der Aktivitäten

Validierung  der Anforderungsartefakte der Aktivitäten

RE‐Prozess: Anforderungsbestimmung5

Durchführbar- Bestimmung und Analyse derkeitsstudie und Analyse der Anforderungen

Spezifikation der Anforderungen

Validierung der Anforderungen

g

Durchführbar- Anforderungenkeitsbericht

Benutzer- und

System-modelle

System-anforderungen

Pflichtenheft

nach [Som01]

Anforderungsbestimmung und –analyse – im Detail6

Anforderungs-spezifikation und

Anforderungs-überprüfung

spezifikation unddokumentation

überprüfung(Validierung)

Verstehen desAnwendungs-

bereichs

Setzen von PrioritätenProzessbeginn

KonfliktlösungAnforderungs-sammlung

Pflichtenheft

Klassifizierung

sammlung

Klassifizierung

Anforderungsbestimmung: was ist zu beachten?7

Es gibt keinen idealen RE‐Prozess zuschneiden auf konkrete ProjektsituationZu berücksichtigende Faktoren:

Zugrunde liegendes Prozessmodell (lineares oder inkrementelles Vorgehen)?

Muss die Spezifikation wasserdicht sein (Vertrag; Realisierung durch Dritte)?

Sind die Kunden/Benutzer bekannt und können sie in die Erstellung derSpezifikation einbezogen werden?

Wird das zu spezifizierende System im Kundenauftrag oder für den Marktp y gentwickelt?

Soll Standardsoftware zum Einsatz kommen?

Erhebung von Anforderungen8

Der schwierigste Schritt der Anforderungsphase. Geht über das Abfragen von Wissen hinaus. Die Quellen sind zu Beginn der Anforderungsphase oft nicht 

bekannt. Beinhaltet häufig auch die Generierung neuer Ideen 

(insbesondere bei innovativen/neuen Produkten).

Anforderungen: Abbilden oder Gestalten?

9Abbilden oder Gestalten?

Weder … dem Kunden genau das liefern, was er wünscht.

Noch …„Wir wissen schon, was gut für den Kunden ist.“

Innovation initiieren! Den Beteiligten innovative Lösungen vorschlagen Kreativität der Beteiligten anregen

Zukunftsszenarien entwerfen und durchspielen Zukunftsszenarien entwerfen und durchspielen Alle Beschränkungen fallen lassen Metaphern suchen und explorieren

Erhebung von Anforderungen10

Information über Beteiligte Stakeholder und ihre Ziele Nutzeraufgaben

G ä ti Sit ti (I t Sit ti ) Gegenwärtige Situation (Ist‐Situation) Erwartungen Wissen über die Domäne Wissen über die Domäne

Anforderungsquellen11

StakeholderEin Stakeholder (im RE) ist eine Person oder

Beobachten Interviews

W k h

( )eine Organisation, die ein potenzielles Interesse an dem zukünftigen System hat und somit i.d.R. auch Anforderungen an das System stellt. Eine Person kann dabei Interessen von mehreren

Workshops

BeobachtungV ä d k

Personen oder Organisationen vertreten, d.h. mehrere Rollen einnehmen.

nach [RR06]

Vorgängerprodukte  Untersuchen Dokumentation Dokumentation

Probleme bei der Erhebung12

Probleme bei der Erhebung

Methoden der Anforderungsbestimmung13

Blickwinkel‐orientierte Bestimmung Anforderungen werden aus den jeweiligen Blickwinkeln der Projektbeteiligten

(Stakeholder) gesucht / beschrieben. Anwendungsfälle, Use Cases.g ,

Szenarien Beispiele helfen, Anforderungen zu finden / zu beschreiben.

Ethnographie Durch Beobachtung tatsächlicher Abläufe werden Anforderungen identifiziert

/ b h b/ beschrieben.

Kommunikation15

Kommunikation

Kommunikation mittels Sprache Kommunikation mittels Sprache Representation of experiences (perceptions) Communication of personal reality (presentation) Communication of personal reality (presentation)

User/ Customer Requirements Engineer

Perception Presentation Interpretation

User/ Customer Requirements Engineer

Objective reality Personal reality Linguistic expression Result

Aufgabe16

Die Leitung eines Universitätsinstituts will den Betrieb der Institutsbibliothek

rationalisieren. Folgende Informationen sind bekannt:

Gewünscht wird ein softwarebasiertes System mit folgenden Fähigkeiten:

Ausleihe Rückgabe Verlängern und Vormerken vollständig in Ausleihe, Rückgabe, Verlängern und Vormerken vollständig inSelbstbedienung durch die Bibliotheksbenutzer,

Benutzerverwaltung und Katalogpflege durch die Bibliothekarin Benutzerverwaltung und Katalogpflege durch die Bibliothekarin,

Teilautomatisierter Mahnprozess (Schreiben der Mahnbriefe undFühren des Mahnstatus automatisiert; Versand und Inkasso manuell),Führen des Mahnstatus automatisiert; Versand und Inkasso manuell),

Katalogrecherche, Verlängern und Vormerken lokal und über WWW.

Ferner ist ein Diebstahlsicherungssystem zu installieren, das verhindert, dass jemand dieg y , , jBibliothek mit nicht ausgeliehenen Büchern verlässt.

Identifizieren Sie Beteiligte, die im Rahmen dieses Projekts Anforderungen stellen können.

Anforderungen gewinnen17

Techniken der Informationsbeschaffung18

Interviews

Beteiligte werden einzeln oder in Gruppen befragt. Gemeinsame Arbeitstagungen

Gemeinsame Erarbeitung von Anforderungen in einer Gruppe Gemeinsame Erarbeitung von Anforderungen in einer Gruppe ausgewählter Beteiligter und Anforderungsingenieure.

Beobachtung

Beteiligte bei der Arbeit beobachten. Umfragen/Fragebogen

Erfassung von Begriffswelt und Bedürfnissen einer größeren Gruppe Erfassung von Begriffswelt und Bedürfnissen einer größeren Gruppe von Beteiligten.

Prototypenyp

Gewinnen von Anforderungen durch Erprobung möglicher Lösungen. ...

Regeln für die Informationsbeschaffung19

Informationen über den Anwendungsbereich gewinnen undg ganalysieren. Begriffswelt.

G tä d d P Gegenstände und Prozesse.

Konkrete Bedürfnisse und Wünsche erfassen und analysieren. Anforderungsspezifikation fortlaufend inkrementell aufbauen Anforderungsspezifikation fortlaufend inkrementell aufbauen.

Keine großen Materialsammlungen. Gewinnung, Analyse und Darstellung miteinander verzahnen Rückkopplung ist wichtig. Von festem Grund ausgehen: vom Bekannten und Gesicherten zum

Unbekannten und Offenen.

Anforderungen betreffen einen SOLL-Zustand. Den IST-Zustand nur analysieren, wenn dies notwendig ist.

Typische Beobachtungen, Schwierigkeiten20

Erwartungs‐ und Begriffsdiskrepanzen bei den Beteiligten

Beteiligte wissen zwar was sie wollen können ihre Vorstellungen aber nicht formulieren Beteiligte wissen zwar, was sie wollen, können ihre Vorstellungen aber nicht formulieren.

Beteiligte wissen nicht, was sie wollen.

Beteiligte haben verdeckte Ziele, die sie absichtlich nicht offen legen.

Beteiligte sind auf bestimmte Lösungen fixiert.

Requirements Engineering ist immer auchRequirements Engineering ist immer auch

Aufgabenklärung.

Risikoanalyse.y

Konsensbildung.

Konflikterkennung und –auflösung.

Anregung von Kreativität bei den Beteiligten.

Praxiserfahrungen21

Analyse wird von einem Kernteam durchgeführt(Fachexperten aus der Anwendung Entwickler)(Fachexperten aus der Anwendung, Entwickler).

Entscheidungsträger (Manager), Fachleute, Anwenderbefragen.befragen.

Das gewonnene Rohmaterial wird in Workshops geordnetund bewertet.Ziele der Workshops: Widersprüche entdecken, Priorisierungder Anforderungen. Wichtig: Analytiker stellt unterschiedlicheInteressen dar und drängt den Kunden zur Entscheidung –Interessen dar und drängt den Kunden zur Entscheidungtrifft also Entscheidungen nicht selbst.

Kunde versteht formale Darstellungen (fast) nie. Ausnahme:Anwendungsfälle.

Neben der Sammlung der Anforderungen wichtig:B iff l ikBegriffslexikon.

Arten von Interviews22

Grad der Formalität Offenes Interview Offenes Interview

Offene Fragen. Analyse der Daten ist schwierig. Erfordert gute Interview Fähigkeiten.g g Persönlichkeit hat Einfluss auf das Ergebnis.

lb k i i Halb‐strukturiertes Interview Wird durch vorformulierte Interviewfragen geleitet. Wird an Hand von Themen gegliedert. Lässt Raum für spontane Abschweifungen /Ergänzungen Lässt Raum für spontane Abschweifungen /Ergänzungen.

Strukturiertes Interview Hohes Maß an Objektivität. Erlaubt den einfachen Vergleich zwischen verschiedenen Interviews. Erlaubt quantitative Auswertung. Keine Freiheiten in der Interviewführung enge Führung Keine Freiheiten in der Interviewführung, enge Führung.

Interview Durchführung23

1. VorbereitungVorliegende Dokumente studierenVorliegende Dokumente studieren.Fragen vorbereiten. 

2. DurchführungWenn möglich mit zwei InterviewendenWenn möglich mit zwei Interviewenden.Evtl. Aufnahme des Interviews auf Band.

3. Eröffnung des InterviewsW fü i t d I t iWofür ist das Interview. Was passiert mit den Antworten.

4. Die FragenAm  Anfang eher allgemein, später spezifischer.Eine Mischung aus offenen und geschlossenen FragenAktives Zuhören.Achtung: Auch nonverbale Kommunikation ist von Bedeutung.

5. AbschlussWie geht es weiter.Die interviewte Person hat das letzte Wort.

Nach dem „WARUM“ fragen!24

Bsp: Neurologische Diagnostik Das System soll ein Mini‐Keyboard haben, mit Start und Stop 

Knopf…. WARUM?

Man soll es mit der linken Hand bedienen können WARUM?

Beide Hände sind in der Nähe des PatientenWARUM? WARUM?

Schmerzhaft für den Patienten, Elektroden, …..

Später: Im Anforderungsdokument25

Kontext: Neurologische Messungen sind schmerzhaft für den Patienten. 

Die Elektroden müssen während der Messung fixiert bleiben. Beide 

Hände müssen während der Messung in der Nähe des Patienten sein.g

WAS ‐ Anforderung: Beginn und Ende der Messung müssen bedient 

werden können, während beide Hände in der Nähe des Patienten sind.

WIE ‐ Anforderung: Start und Stopp werden mit einem Fußpedal oder WIE  Anforderung: Start und Stopp werden mit einem Fußpedal oder 

mittels Sprachsteuerung angesteuert.  

Interview Effekte26

Wechselwirkung zwischen Befragtem und Fragendem.

Soziale Erwünschtheit27

Soziale Erwünschtheit liegt vor, wenn Befragte Antworten b l b f h f

.

geben, von denen sie glauben, sie träfen eher auf Zustimmung als die korrekte Antwort, bei der sie soziale Ablehnung befürchtenAblehnung befürchten.

Wie oft

Ähm... 2 x pro Woche ein

Glas!

trinken sieAlkohol?

Durchschnitt-lich viel!lich viel!

Halo Effekt28

Halo Effekt

Einzelne Eigenschaften einer Person erzeugen einen Gesamteindruck, der die weitere Wahrnehmung der Person "überstrahlt"überstrahlt . 

Attraktiv

= reich

= intelligent

Recency‐ Effekt29

Recency Effekt

Der Recency‐Effekt ist ein psychologisches Gedächtnisphänomen, welches dazu führt, dass später (recency) erfasste Information gegenüber anderer(recency) erfasste Information gegenüber anderer eingehender Information bevorteilt wird.

Fokus Gruppen30

Fokus  Gruppen

hier:Stakeholder

(insbesondere

hier:Stakeholder

(insbesondere Nutzer)Nutzer)

Quelle: Krueger & Mary, 2003, „Focus Groups“, Sage Publ., London

Fokus Gruppe31

Fokus Gruppe

Spezielle Form von Workshop (6‐8 Teilnehmern).P f i ll M d Professioneller Moderator.

Mit Problemen beginnen:l h bf Flipchart, Kartenabfrage,

Gründe sammeln.

Dann auf Lösung fokussieren Dann auf Lösung fokussieren.

Fokus Gruppe32

Gruppierung der gesammelten Punkte. ca. 40 Punkte.

Priorisierung Z.B. 10 Punkte kleben, in Gruppen je nach Stakeholder Rolle.

Ab hl i i Z f d E b i Abschluss mit einer Zusammenfassung der Ergebnisse.

Fokus Gruppe33

Die Fokus Gruppe ist die geeignete Methode, wenn:   … noch zu wenig Informationen über die Nutzer, deren 

Aufgaben, den Kontext und die Domäne vorhanden ist. … sehr viele Ideen vorhanden sind und diese bewertet 

werden müssten. … verschiedene Perspektiven und Standpunkte besser 

verstanden werden sollen.di V il i F G d ll … die Vorteile einer Focus Group genutzt werden sollen 

(Vertrauensbildung,  Kundenorientierung) .

Beobachtung34

Anwender im Kontext beobachten.

Arbeitsumgebung, Kommunikationswege, Geräte.

Arbeitsartefakte.

Beobachtung ‐ Site Visits35

Beobachtung der Stakeholder in ihrer realen Umgebung (evtl. h )auch Kamera, Computer Monitoring).

Ziele Erfassung on implizitem Wissen. Identifikation versteckter Anforderungen. Besseres Verständnis des Kontextes Besseres Verständnis des Kontextes.

Geeignet für die Entwicklung neuer Produkte oder in neuen MarktsegmentenMarktsegmenten.

Beobachtung – Site Visits36

1‐2 Interviews pro Tag und Team. Analyse der Daten innerhalb von 48 Stunden.. Nachbesprechung im Team (debriefing) ist sehr wichtig. Nachteile:

Erhebung großer Mengen irrelevanter Daten. Zeitaufwendig. Seltene Ereignisse werden übersehen.

Priorisierung von Anforderungen38

Zeitliche und finanzielle Restriktionen erlauben es meist nicht alle 

Anforderungen mit der gleichen Intensität zu beachten.

Anforderungen werden in Abhängigkeit von ihrer Bedeutung priorisiert.

Priorisierung von Anforderungen39

Nicht alle Anforderungen sind gleich wichtig: Muss‐Anforderungen – unverzichtbar. Soll‐Anforderungen – wichtig, aber bei zu hohen Kosten verzichtbar. Wunsch‐Anforderungen – schön zu haben aber nicht essenziell Wunsch‐Anforderungen – schön zu haben, aber nicht essenziell.

Priorisierung nötig bei harten Terminen. harten Terminen. harten Preisobergrenzen. Beschaffung.

Priorisierung nützlich bei Festlegung von Inhalt und Umfang der Inkremente bei inkrementeller 

EntwicklungEntwicklung. Releaseplanung bei der Weiterentwicklung bestehender Systeme.

Klassifikation von Prioritäten40

Ad‐hoc Priorisierung : Ranking im Hinblick auf ein bbestimmtes Kriterium.

Klassifikation nach IEEE Std 830‐1998: Mandatory: Anforderungen müssen umgesetzt werden, um den Erfolg 

zu gewährleisten.  Optional: Anforderungen die zwar wichtig sind deren vereinzeltes Optional: Anforderungen, die zwar wichtig sind, deren vereinzeltes 

Fehlen im System den Erfolg nicht gefährdet. Nice‐to‐have: Anforderungen, deren Fehlen im System den Erfolg des 

S i h fäh dSystems nicht gefährdet.

Beobachtung: Meist starke Häufung in der Klasse Mandatory“ Beobachtung: Meist starke Häufung in der Klasse „Mandatory .

Priorisierung nach [RR06]43

Volere Prioritisation SpreadsheetCopyright c The Atlantic Systems Guild 2002 / siehe Web-Seite

Requirement/Product Use Case/Feature

Number

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

Total Weight

Value to Customer

40Value to Business

20Minimise

Implementati 10Ease of

Implementati 30Priority Rating

100

1 2 0 8 7 1 4 3 0 3 8 2 4 4 9Requirement 1 1 2 0,8 7 1,4 3 0,3 8 2,4 4,9

Requirement 2 2 8 3,2 8 1,6 5 0,5 7 2,1 7,4

Requirement 3 3 7 2,8 3 0,6 7 0,7 4 1,2 5,3

R i 4 4 6 2 4 8 1 6 3 0 3 5 1 5 5 8Requirement 4 4 6 2,4 8 1,6 3 0,3 5 1,5 5,8

Requirement 5 5 5 2 5 1 1 0,1 3 0,9 4

Requirement 6 6 9 4 6 1,2 6 0,6 5 1,5 6,9

Requirement 7 7 4 2 3 0,6 6 0,6 7 2,1 4,9Requirement 7 7 4 2 3 0,6 6 0,6 7 2,1 4,9

Requirement

Requirement

Requirement Requirement

Requirement

Requirement

Requirement Requirement

Requirement

Requirement

Techniken zur Priorisierung: Kano Klassifikation (1)44

Techniken zur Priorisierung: Kano‐Klassifikation (2)45

Merkmalsklassen Basismerkmal: Dieses Merkmal muss vorhanden sein, um den 

Markteintritt zu ermöglichen Leistungsmerkmal: Diese Merkmale bestimmen die Zufriedenheit des Leistungsmerkmal: Diese Merkmale bestimmen die Zufriedenheit des 

Kunden Begeisterungsmerkmal: Die Kundenzufriedenheit wächst 

überproportional, wenn dieses Merkmal vorhanden ist.

Die Kundenbedürfnisse verändern sich mit der Zeit Aus Begeisterungsmerkmalen werden Leistungsmerkmale Aus Leistungsmerkmalen werden Basismerkmale

Nachvollziehbarkeit  ‐ Tracebility46

Ziel:  Beherrschung der Evolution der Anforderungen.

Anforderungen stabil halten. Veränderung kontrolliert zulassen.

Erreichen des Ziels:  Konfigurationsmanagement für Anforderungen. Anforderungen einzeln identifizierbar machen. Geordneter Änderungsprozess. Klare Zuständigkeiten und Verantwortlichkeiten. Rückverfolgbarkeit aller Entscheide und Änderungen.g g

Nachvollziehbarkeit von Anforderungen47

Im Entwicklungprozess nachvollziehen  des Ursprungs der Anforderungen, der Verwendung der Anforderung.

In‐Tracebility

Vorgelagerte Artefakte

Vorgelagerte Artefakte AnforderungenAnforderungen Nachgelagerte

ArtefakteNachgelagerte

Artefakte

Pre‐Tracebility Post‐Tracebility

Nachvollziehbarkeitsinformation49

Durch textuelle Referenzen. Durch Hyperlinks. Durch Nachvollziehbarkeitsmatrizen.

U: uses, benutzt, hängt ab von

R: relates, bezieht sich auf

Prüfen von Anforderungen50

Abweichungen von der geforderten Qualität der Spezifikation feststellen.Mö li h i l F hl Lü k Möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten, etc. finden und behebenfinden und beheben.

Konflikte zwischen den Wünschen / Forderungen verschiedener beteiligterForderungen verschiedener beteiligter Personen erkennen und lösen.

Verdeckte Wünsche / Erwartungen / / g /Befürchtungen erkennen und thematisieren.

Organisation der Anforderungsprüfung51

Vertreter aller Beteiligten einbeziehen Endbenutzer Auftraggeber Betreiber Betreiber Entwickler Projektleitung ...

Zeitpunkt(e): Fortlaufend, d.h. begleitend zur Erstellung der Spezifikation,

z. B. Autor‐Kritiker‐Zyklus. Wenn die Spezifikation fertig ist (aber noch genug Zeit bleibt,

die gefundenen Mängel zu beheben).

Verfahren der Anforderungsprüfung 1/252

Review Das Mittel der Wahl zur Prüfung von Spezifikationen. Walkthrough: Autor führt durch das Review. Inspektion: Gutachter prüfen eigenständig tragen in Sitzung Befunde Inspektion: Gutachter prüfen eigenständig, tragen in Sitzung Befunde

zusammen. Autor‐Kritiker‐Zyklus: Kunde liest und kritisiert, bespricht Befunde mit Autor.

Prüf‐ und Analysemittel in Werkzeugen Einsatz bei werkzeuggestützter Erstellung der Spezifikation.

A ffi d Lü k d Wid ü h Auffinden von Lücken und Widersprüchen.

Verfahren der Anforderungsprüfung 2/253

Simulation/Animation Untersuchung der Adäquatheit des Systemverhaltens.

Dynamisches Verhalten des spezifizierten Systems wird durch Simulatorausgeführt und/oder durch Animator visualisiertausgeführt und/oder durch Animator visualisiert.

Prototyp Beurteilung der Adäquatheit / praktischen Brauchbarkeit des spezifizierten Beurteilung der Adäquatheit / praktischen Brauchbarkeit des spezifizierten

Systems anhand der im Prototyp realisierten Systemteile.

Erprobung eines Systems in der geplanten Einsatzumgebung.

Modell für das zu schaffende Produkt.

Mächtigstes (aber auch aufwendigstes) Mittel zur Beurteilung der Adäquatheit.

Anforderungsprüfung ‐Prototyping54

Geeignet bei interaktiven Systemeny

Horizontaler PrototypVorteileVorteile

Fördert die Kommunikation mit dem Benutzerhl d f d d Fehlende Anforderungen werden 

identifiziert Missverständnisse werden entdeckt Reduziert Entwicklungsrisiko

Paper Prototyping // Low‐fidelity55

Eingabemasken auf Papier Keine/Wenig Ähnlichkeit zum fertigen Produkt.

Vorteile Preiswert, schnell, technisch einfaches Verfahren. Kommunikativ.

Änder ngs orschläge können direkt mgeset t erden Änderungsvorschläge können  direkt umgesetzt werden.

Nachteile Ohne Funktionalität Ohne Funktionalität. Nicht weiter nutzbar. Nicht alle Ideen technisch umsetzbar. Nicht alle Ideen technisch umsetzbar.

Computer‐gestütztes Prototyping56

High‐fidelity. Hohe Ähnlichkeit zum fertigen Produkt. Liste mit Prototyping‐Tools unter: sourceforge.net

Vorteile Mehr Funktionalität. User kann mit Prototyp interagieren.

Nachteile Teuer// Aufwendig. Änderungen nur mit größerem Aufwand. mögliche Verwechslung mit Zielsystem.

Der Requirements Prozess57

Requirementselicitation

Requirements analysis & negotiation

Requirements documentation

Requirements validation

User needs,

domain information Requirementsdomain information, existing systems,

regulations, standards, ...

Requirements documents

AgreedRequirements

Anforderungsmanagement 1/258

Anforderungen stabil halten. Veränderung kontrolliert zulassen.

l h h d l d f d Ziel: Beherrschung der Evolution der Anforderungen.

Konfigurationsmanagement für Anforderungen

Anforderungen einzeln identifizierbar. Geordneter Änderungsprozess Geordneter Änderungsprozess. Klare Zuständigkeiten und Verantwortlichkeiten. Rückverfolgbarkeit aller Entscheide und Änderungen Rückverfolgbarkeit aller Entscheide und Änderungen.

Anforderungsmanagement 2/259

Nachvollziehbarkeit (Traceability) von h i t lAnforderungen

Quellen‐Nachvollziehbarkeit:

horizontal

vertikalWoher, von wem kommt die Anforderung?

Anforderungs‐Nachvollziehbarkeit:

vertikal

Welche Anforderungen hängen voneinander ab/bedingen einander?

Entwurfs‐Nachvollziehbarkeit: Entwurfs‐Nachvollziehbarkeit:

Wo/wie ist die Anforderung im Entwurf/in der Implementierung umgesetzt?

horizontalden roten

Pfeilen folgendPfeilen folgend

Änderungsmanagement60

Erkanntes „Problem“

Problemanalyse und ÄnderungsspezifikationÄnderungsspezifikation

InformationenÄnderungsanalyse und

Aufwandsschätzung

Informationen über die

Abhängigkeit von

I l ti d

von Anforderungen

Implementierung der Änderung

ÜberarbeiteteA f d E t fAnforderungen, Entwurf,

Implementierung

Bearbeitung von Änderungsanträgen / Change Request

61Request

Auslöser: CR(change request)

Auslöser: CR(change request)

Change

Projektmanager

Auswirkungsanalyse Aufwands-ermittlungAufwands-ermittlung

K t /N tK t /N t

Changecontrol board

Beurteilung der Änderung

[Annahme der Änderung] [Ablehnung der Änderung]

Kosten/Nutzen-Analyse

Kosten/Nutzen-Analyse

Kommunikation der

Priorisierung derAnforderungsänderung

Kommunikation derAblehnungZuordnung

der Änderung zu Änderungsprojekt

Folgeaktivität:Umsetzung

Folgeaktivität:UmsetzungPohl, Rupp: Basiswissen Requirements-Engineering, 2009

7 Sünden der Anforderungsspezifikation nach Myers62

Irrelevante Information Unvollständigkeit Über‐Spezifika on (≠ Design‐Entscheidungen) Inkonsistenzen Mehrdeutigkeitg Vorwärts‐Referenzen Nicht testbare Anforderungenc t testba e o de u ge

Zusammenfassung63

Der Grad der Formalität und des Detailgrads von f h k l k bAnforderungen hängt von dem zu entwickelnden Produkt ab.

Ein  System zur Steuerung eines intensivmedizinischen Gerätes verlangt eine sehr detaillierte Spezifikationverlangt eine sehr detaillierte Spezifikation.

Die Spezifikation eines Computerspieles kann aus einem Storyboard(dargestellt durch Bilder) und einem Beispiel bestehen. 

Verschiedene Produkte verlangen auch sehr unterschiedliches Vorgehen bei der Erhebung und beim 

i Ä d ß hi d iUmgang mit Änderungen  große Unterschiede im RE‐ProzessDi H f d d RE li i d K ik ti Die Herausforderungen des RE liegen in der Kommunikation, in der Identifikation „versteckter“ Anforderungen, in der Überspezifikation und in der Instabilität von Anforderungen.Überspezifikation und in der Instabilität von Anforderungen.