Upload
lyxuyen
View
228
Download
0
Embed Size (px)
Citation preview
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.