Requirements Engineering - HKI

Requirements Engineering
Virtuelle Forschungsumgebungen
Dozent Prof. Dr. M. Thaller
Referentin Nadya Steinert
1
Requirements Engineering
 Anforderungen und Ziele sind die Hauptbausteine
von Requirements Engineering. Es kann nicht nach
einer Lösung gesucht werden, ohne das es ein gut
definiertes Problem gibt.
 Die meisten abgebrochenen Projekte hatten nur
ungenügend geklärte Anforderungen und konnten
Änderungen der Anforderungen nicht beherrschen.
 Oft erreichen Projekte ihre Ziele nicht, weil diese
nicht sauber formuliert wurden
2
Risiken und Fehler durch Anforderungen
 Erfolgsfaktoren für Produktentwicklung
 Ergebnisorientierte Vorgaben
 Zielorientierte Prozesse
 Kompetentes Produkt- und Projektmanagement
 Standardisierte und optimierte Infrastruktur
 Fokus auf Anforderungen, Änderungen und Risiken im
Projekt
3
Risiken und Fehler durch Anforderungen
 Risiko 1: Fehlende Anforderungen
 Bestimmte Anforderungen werden übersehen
 Typen von Anforderungen: funktionale Anforderungen,
Qualitätsanforderungen, Rahmenbedingungen,
Produkt- ,Markt- und Komponentenanforderungen
 Für vollständige Anforderungsdokumentation müssen
alle diese Typen hinterfragt werden
 Testfälle müssen alle diese Kategorien von
Anforderungen abdecken
4
Risiken und Fehler durch Anforderungen
 Risiko 2: Falsche Anforderungen
 Fehler werden erst bei Test und Abnahme des Produkts
entdeckt: die Korrektur wird aufwendig
 Anforderungen werden oft von Kunden- und
Benutzerinterviews übernommen; sie müssen aber
erweitert und präzisiert werden
 Fehler werden frühzeitig durch Verifikation und
Validierung entdeckt (Checklisten und Szenarien
wichtiger Abläufe)
5
Risiken und Fehler durch Anforderungen
 Falsche Anforderungen entstehen, wenn Bedarf und
Lösung gemischt oder verwechselt werden
 Es sollen immer zwei Spezifikationsdokumente geführt
werden: Liste der Anforderungen (Lastenheft) und
Liste der Lösungsspezifikationen (Pflichtenheft)
 Entwickler verstehen Anforderungen falsch: es kommt
zu Verzögerungen, hohen Kosten, zusätzlichem
Entwicklung-, Korrektur-, und Testaufwand
6
Risiken und Fehler durch Anforderungen
 Risiko 3: Sich ändernde Anforderungen
 Nicht beherrschbare Änderungen an Anforderungen
führen zu Kosten- und Terminüberschreitungen und
reduzieren die Qualität
 Es gibt meistens eine gewisse Basis an Anforderungen,
einige Punkte sind offen und werden im Laufe der Zeit
geklärt
 Unzureichende Einbeziehung der Benutzer führt zu
nicht akzeptierte Produkte und unzufriedene Kunden
7
Risiken und Fehler durch Anforderungen
 Bis bestimmten Meilensteinen soll die Änderungsmenge
reduziert werden
 Rückwärtsplanung von Ausgabe zurück ins Projekt
zeigt, wie früh es keine parallel Arbeit mehr zulässig ist
8
Der Nutzen von Requirements
Engineering
 Produktivitätsverbesserung: 30-50% des
Entwicklungsaufwands sind für Fehlerbehebung; die
Hälfte der Fehler kommt von unzureichenden
Anforderungen und unkontrollierten Änderungen
 Bekannte Anforderungen und klare Verantwortungen
im Projektteam führen zu verbesserte Projektplanung
und Ressourceneinteilung, weniger Verzögerungen
und Termintreue
9
Der Nutzen von Requirements
Engineering
 Fokus auf jene Aktivitäten und Inhalte, die Wert
schaffen. Knapp die Hälfte aller Funktionen eines
Softwaresystems werden nicht genutzt. Weniger
Anforderungen reduzieren die Komplexität und
machen die Qualität besser.
 Bessere Kundenzufriedenheit durch konsistentes
Verständnis über die wirklichen Anforderungen
10
Konzepte des Requirements Engineering
 Was ist eine Anforderung?: Sie beschreibt, was der
Kunde oder Benutzer vom Produkt erwartet:
 Eine Eigenschaft oder Bedingung
- die von einem Benutzer zur Lösung eines Problems
oder zur Erreichung eines Ziels benötigt wird
- die ein System oder eine Systemkomponente erfüllen
muss, um einen Vertrag oder Spezifikation zu erfüllen
 Eine dokumentierte Repräsentation einer Eigenschaft
oder Bedingung, wie oben beschrieben
11
Konzepte des Requirements Engineering
 Anforderungen können mehrdeutig, überspezifisch,
unvollständig, kontextspezifisch, unmöglich oder falsch
sein, aber immer zu viele.
 Bei Anforderungen stellen sich viele Fragen:
 Ist die Anforderung wichtig?
 Sind alle Inhalte gleichermaßen wichtig und wie korrelieren
sie?
 Wie ist der Status der Anforderung?
 Wer ist für die Anforderung verantwortlich?
 Ist die Anforderung machbar? Welche Einflüsse hat sie?
12
Konzepte des Requirements Engineering
 Wurde diese Anforderung geändert und durch wen?
 Wo sind die Analyseergebnisse dokumentiert?
 Wie wird die Anforderung validiert?
 Wie konkretisiert sich die Anforderung?
Requirements Engineering hat die Aufgabe,
verschiedene Interessen und Sichtweisen unter einen
Hut zu bringen. Es begrenzt und steuert die Verluste, die
im Projekt auftreten
13
Sichten auf Anforderungen
 Marktanforderungen
 Anforderungen an ein Produkt aus Sicht des Kunden
 warum ein Projekt durchgeführt werden soll?
 Werden im Lastenheft dokumentiert
 Es muss Priorisierung aus betriebswirtschaftlicher Sicht
geben
 Z. B. Marktanforderungen an einer Digitalkamera gehen
sehr konkret auf Benutzungsaspekte ein: Lebensdauer
der Akkus, Pixelzahl, Bildschirmschärfe usw.
14
Sichten auf Anforderungen
 Produktanforderungen
 Anforderungen an ein Produkt aus Sicht der Realisierung
einer späteren Lösung
 Beschreiben, was verschiedene Benutzer mit dem
Produkt machen können
 Sie werden im Pflichtenheft dokumentiert
 Betrachten Softwareprodukt oder Dienst innerhalb der
Umgebung, in der das System einmal arbeiten muss
15
Sichten auf Anforderungen
 Komponentenanforderungen
 Anforderungen an eine Komponente eines Produkts
 Werden auch im Pflichtenheft spezifiziert
 Das sind z. B. Anforderungen an ein Betriebssystem
oder an ein Rauchmelder
Das vermischen der Produkt- und
Komponentenanforderungen führt zu einem
Strukturbruch, der schwer zu handhaben ist
16
Arten von Anforderungen
 Funktionale Anfoerderungen
 Beschreiben eine vom System bereitzustellende
Funktion, was das System tun soll
 Sie lassen sich leicht verfolgen und verifizieren
 Man kann für eine bestimmte Funktion sogar einen
Testfall schreiben, der später in verschiedenen Phasen
geprüft wird
17
Arten von Anforderungen
 Qualitätsanforderungen
 Beschreiben eine qualitative Eigenschaft, die das System
oder eine Funktion aufweisen müssen
 Sie ergänzen die funktionalen Anforderungen: Beispiele
sind Zuverlässigkeit, Verfügbarkeit, Wartbarkeit
 Sind schwer zu spezifizieren und zu testen
 Schwierige und oft unzureichende Diagnose und
Fehlermanagement
18
Arten von Anforderungen
 Randbedingungen
 Eine organisatorische oder technische Anforderung, die
die Art und Weise einschränkt, wie ein System realisiert
werden kann
 Sie ergänzen funktionale Anforderungen und
Qualitätsanforderungen; Kosten , Geschäftsprozesse,
Gesetze sind typische Beispiele
 Organisatorische Randbedingungen spielen auch eine
Rolle, obwohl sie nicht als Anforderungen zugegeben
werden
19
Was ist Requirements Engineering?
 Requirements Engineering (RE) ist das disziplinierte
und systematische Vorgehen zur Ermittlung,
Spezifikation, Analyse, Vereinbarung, Validierung
und Verwaltung von Anforderungen, um Bedürfnisse
und Ziele in ein Produkt umzusetzen
 RE ist eine Kerndisziplin aller
Ingenieurwissenschaften und damit auch der
Softwaretechnik und Systemtechnik
20
Was ist RE?
 Re wird sowohl bei neuen Produkten, als auch bei
Änderungen bestehender Produkte angewandt. Re
wird vor dem Projektstart und während der
gesamten Laufzeit eines Projekts eingesetzt. Die
Techniken unterscheiden sich dabei, aber die
Aktivitäten von der Ermittlung bis zur Verwaltung
sind immer Pflicht.
21
Was ist RE?
 Das Ziel von RE ist es, qualitativ gute – nicht perfekte
– Anforderungen zu generieren, die es erlauben, das
Projekt mit einem akzeptablen Risiko zu beginnen.
 Der zweck des RE ist es , ein Einverständnis zwischen
dem Kunden und dem Software Projekt(also dem
Lieferanten) über jene Anforderungen zu erreichen,
die durch das Softwareprojekt abgedeckt wurden.
22
Standards und Normen
 Ein grundlegendes Standard der System und
Softwaretechnik ist das CMMI (Capability Maturity Model
Integration); es basiert auf die Erkenntnis, dass die
Zusammensetzung von einzelnen besten Praktiken keine
Lösung verspricht. Man muss den gesamten Lebenszyklus
von der Konzeption bis zur Lieferung durchgängig
betrachtet, wenn man etwas nachhaltig verbessern will.
 Andere Standards sind die ISO/IEC, IEEE, VDI-Richtlinie.
23
Methodik des RE
 Die Methodik des RE basiert auf einem
Kundenorientierten Ansatz, der die Wünsche
verschiedener Interessengruppen erfasst, bewertet
und verbindet. Nur unter diesen Bedingungen kann
ein motiviertes Projektteam, mit gemeinsamer
Mission geformt werden.
24
Lebenszyklus
 Strategie und Konzeption- „Upstream“-Phase in der
Produktentwicklung vor Beginn des Projekts; es wird
festgesetzt welche Anforderungen berücksichtigt werden;
Inhalte, Ziele und Meilensteine werden vereinbart; die
Produktvision entsteht: z. B. welche Märkte in welcher
Form adressiert oder nicht adressiert werden
 RE in der Planungsphase bezieht sich unter anderem auf
die Analyse der Systemumgebung, des Benutzerverhaltens
und der späteren Entwicklungsschritte
25
Lebenszyklus
 Entwicklung – Umsetzung der Anforderungen in ein
funktionsfähiges Produkt unter vereinbarten
Einschränkungen(Kosten, Zeit etc.)
Grundlegende Prozesse in dieser Phase sind Management
der Anforderungen, Entwicklung einer Architektur oder
Entwurf, Verifikations- und Validierungsstrategie,
Implementierung, Paketierung und Qualitätskontrolle
26
Lebenszyklus
 Markteintritt – relevant für die Aufnahme und Akzeptanz
eines Produkts; er beeinflusst den wahrgenommenen
Nutzen: eine neue hervorragende Serverplattform in einer
Anwendung , die sich nicht verkauft ist nicht nützlich
 Evolution(Wartungsphase) – wird durch zwei
Änderungsarten am existierenden Produkt bestimmt :
Fehlerkorrekturen und Erweiterungen , was zu einem
neuen Produkt führt
 RE spielt bei Wartungsprojekten sehr große Rolle: bei jeder
Änderung muss man abwägen, ob sie in die gesamte
Strategie passt
27
Rollen, Verantwortungen, Kompetenzen
 Interessenvertreter(Stakeholder), Perspektiven und
Zielgruppen
Im RE gibt es zwei grundsätzlich verschiedene Rollen:
Ein Auftraggeber(Benutzer, Kunde), der eine Lösung für
seine Bedürfnisse sucht
Ein Lieferant, der diese Anforderungen in eine Lösung
umgesetzt liefert
Beide Seiten können vom Projektmanager nicht optimiert
werden, aber man muss die Argumente der anderen Seite
verstehen
28
Rollen, Verantwortungen, Kompetenzen
 Diese Rollentrennung ist wichtig in Situationen, wo der
Kunde oder Benutzer nicht direkt ansprechbar ist;
beispielweise bei Konsumgütern, eingebetteter Software
oder Anwendungen für die noch kein Markt existiert. Also
muss jemand von der Seite des Lieferanten diese Rolle
effektiv einnehmen
 Neben diese zwei Hauptrollen, gibt es auch andere:
Marketing und Vertrieb, Produktmanager,
Geschäftsleitung, Entwicklung, Qualitätssicherung etc. Es
ergeben sich immer Konflikte zwischen diesen Rollen, die
gemeistert werden müssen
29
Rollen, Verantwortungen, Kompetenzen
 Schlüsselpersonen und Interessengruppen zu kennen
und mit ihnen richtig umgehen zu können, ist
wesentlicher Erfolgsfaktor von RE. Es muss zuerst
festgestellt werden, welche Interessenvertreter für
das Projekt eine Rolle spielen, und welche für das
spätere Produkt
30
Aufgaben, Rollen und Organisationsstruktur
 Auftraggeber, Kunde – erwartet eine Lösung innerhalb
bestimmter Rahmenbedingungen; kommt typischerweise
von außerhalb des Unternehmens, die Verhältnisse werden
vertraglich geregelt; kann aber auch innerhalb des
Unternehmens sitzen; kommuniziert je nach
Projektumfang mit dem Projektmanager, Vertrieb,
Geschäftsleitung
 Benutzer – sie betreiben oder nutzen das System, stehen
häufig auf Kundenseiten, in vielen Fällen aber muss scharf
getrennt werden; für Benutzer ist Funktionalität wichtig,
für Auftraggeber die Kosten
31
Aufgaben, Rollen und Organisationsstruktur
 Projektmanager – ist für das Projekt verantwortlich;
bringt die verschiedenen Anforderungen zusammen,
sorgt dafür das Anforderungen, Zeitdauer und
Aufwand mit den vorhandenen Ressourcen
korrespondieren; wird am Erfolg des
Projektes(Projekt im Rahmen der akzeptierten
Randbedingungen liefern) gemessen
32
Aufgaben, Rollen und Organisationsstruktur
 Produktmanager – ist für das Produkt( verschiedene
Versionen, Varianten, Dienstleistungen) über den
gesamten Produktlebenszyklus verantwortlich; hat
Interesse an langfristigem Produkterfolg; seine
Kernaufgabe ist Wirtschaftlichkeitsrechnung
aufzustellen( entscheidet, was zu welchem Preis
geliefert wird)
33
Aufgaben, Rollen und Organisationsstruktur
 Marketing, Vertrieb – sorgt dafür das ein bestmöglicher Markt
adressiert wird; versteht die Bedürfnisse der Kunden; sind für Re
eine wichtige Quelle für Anforderungen und deren Änderungen
 Requirements- ingenieur – ist Bindeglied zwischen Kunden,
Benutzer, Marketing/Vertrieb, Produktmanagement und
Entwicklung ; für Dokumentation der Kundenbedürfnisse
zuständig ; gemeinsam mit dem Kunden plant und spezifiziert
Softwaresysteme und begleitet die Umsetzung, gleicht
verschiedene Randbedingungen gegeneinander ab, um
Konflikten zwischen Stakeholder zu entschärfen und zu Win-winSituationen zu kommen
34
Aufgaben, Rollen und Organisationsstruktur
 Entwicklung – stellet die Ressourcen bereit, um das
Projekt auszuführen und Lösung zu entwickeln;
Entwickler bringen durch ihre Sichtweise oft eine
ganze Reihe von weiteren Anforderungen; geben
wichtige Hinweise um Anforderungen zu präzisieren;
Tester gehören auch zu Entwickler; Tests sollen noch
am Anfang durchgeführt werden und nicht im
nachhinein; wichtige Rolle im RE da sie die
Anforderungen neutral und vom Hintergrund
betrachten.
35
Aufgaben, Rollen und Organisationsstruktur
 Qualitätssicherung – unabhängiger Kontrollorgan,
sichert die Erfüllung von Qualitätsanforderungen an
Produkt und Prozesse
 Änderungskomitee(engl. Change Control Board) –
eine formal definierte Gruppe verschiedener
Repräsentanten von Interessensphären, die über alle
Änderungen zu Konfigurationsbasis des Projekts
entscheiden
36
Aufgaben, Rollen und Organisationsstruktur
 Projektkernteam/Leitungsgruppe – für die gesamte
Steuerung des Prozesses nach innen und außen
verantwortlich; besteht aus Projekt- ,Produkt-,
Marketingmanager, Vertreter von Entwicklung,
Betrieb, Qualitätssicherung und Service die sich
einmal wöchentlich trifft
 Geschäftsleitung – die Projekte sollen zu den
geschäftszielen des Unternehmens passen
37
Aufgaben, Rollen und Organisationsstruktur
 Produktmanagement – verantwortet Markt- und
Produktanforderungen; balanciert Umsatz und Kosten
 Projektmanagement – prüft ob Anforderungen klar
definiert sind und ob die für alle Rollen im Projekt
verständlich sind; bestimmt über alle Anforderungen und
deren Änderungen; achtet bei wiederverwendeten
Komponente, Wartungsprojekte und Unteraufträge
darauf, das die Codebasis gemeinsam mit Anforderungen,
Testfällen und Prüferergebnisse geliefert wird
38
Aufgaben, Rollen und Organisationsstruktur
 Soft Skills – Win-win-Sutuationen ergeben sich aus
verschiedene Elemente:
 Realistische Projekte
 Zusammensetzung der Anforderungen und Bewertung
hinsichtlich unterschiedlicher Sichtweisen
 Risikomanagement gemeinsam mit dem Kunden;
Abschwächung eines Risikos auf Kundenseite oftmals
einfacher und billiger
39
Anforderungen ermitteln
 Vor Ermittlung der Anforderungen muss ein Ziel oder
eine Vision stehen, die über die Anforderungen selbst
hinausgehen muss.
 Ziel der Ermittlung der Anforderungen ist wichtige
Kunden , Märkte und Wettbewerber zu identifizieren
und zu verstehen.
 Eine Produktvision orientiert sich an folgenden
Fragen:
40
Anforderungen ermitteln
 Was wird das Produkt verändern?
 Warum ist das Produkt für die Kunden nötig?
 Welche Erfahrung soll der Kunde damit machen?
 Wer wird durch das Produkt profitieren? Wie?
 Wie wird durch das Produkt Geld verdient?
 Welche Kosten und Risiken sind wir bereit zu tragen?
Die Wahl der Ziele hat einen erheblichen Einfluss auf
das bestehende Produkt und auf das
Entwicklungsprozess
41
Anforderungen ermitteln
 Produktideen und Produktvisionen orientieren sich an
folgenden Einflüssen:
 Kunden: Kundenziele, Umgebung des Kunden,
Wettbewerbssituation, Kundeninformationen,
Kundenzufriedenheit, verfügbare Ressourcen
 Strategie: Unternehmensstrategie, Marktpositionierung,
Umsatzentwicklung
 Wettbewerb: Wettbewerbsdaten, Marktanteil,
Marktentwicklung
42
Anforderungen ermitteln
 Produkte: Produktalter, Innovationsgrad, Wartungsanteil,
Fehlerkosten, Verfügbarkeit, Nutzungsgrad,
Kostenreduzierung,
 Technologien: ablösende/innovative Technologien, neue
Forschungsergebnisse, neue Komponente, Werkzeuge,
Lieferanten etc.
 Verfügbare Ressourcen als Restriktion : Zeit, Fähigkeiten,
Mitarbeiter, Beherrschung von Technologien
 die Schlüsselfrage an jeder Produktvision lautet: Was wird bei
den Kunden oder Benutzern anders sein, wenn das Produkt
ausgeliefert ist ?
43
Anforderungen ermitteln
 Den Kunden verstehen: häufig wird dem Kunden
gebracht, was er braucht und nicht was er will. Ein
Produkt muss immer den Kunden zufriedenstellen
 Es sollen keine unrealistische Termine und Preise
gesetzt werden, da dies zu ungewünschte Resultate
führen kann.
44
Anforderungen ermitteln
 Techniken zur Ermittlung von Anforderungen:
Anforderungen müssen einen Zusatznutzen bieten, für
den ein Kunde bereit ist zu zahlen.
 Es geht darum zu verstehen was den Kunden oder
Benutzer bewegt und wie das zukünftige Produkt einen
positiven Einfluss darauf nehmen kann.
 Quellen für Anforderungen sind: Marktforschung und
Marktstudien, Internet(Foren, Bewertungen), eigene
Forschung und Entwicklung, Kundeninterviews , Seminare
Workshops etc.
45
Anforderungen ermitteln
 Unbekannte Anforderungen sind schwer zu ermitteln;
es gibt Bereiche wo der Kunde und der Lieferant
etwas nicht wissen.
 Es sollen „negative Anforderungen“ benutzt werden,
um Szenarios zu beschreiben, die nicht eintreten
dürfen.
 Um an Anforderungen zu kommen kann man
unterschiedliche Techniken benutzen: Fragebögen ,
Interviews, Brainstorming, Rollenspiele
46
Anforderungen ermitteln
 Die Anforderungen werden analysiert und priorisiert und
dann wird entschieden intern oder extern welche
Annahmen, Randbedingungen und Einschränkungen
übernommen werden
 Workshops mit verschiedenen Interessengruppen sind
ideal, um Anforderungen zu ermitteln; die
unterschiedlichen Bedürfnisse und daraus resultierende
Konflikte werden offen ausgetragen
 Teilnehmer an ein Workshop: Auftraggeber, Benutzer(die
mit dem System arbeiten), Benutzer (die installieren ,
pflegen ), Marketing, Entwickler, Lieferanten
47
Anforderungen ermitteln
 Qualitätsanforderungen
 Benutzbarkeit: der Grad, zu dem ein Produkt durch
bestimmte Benutzer im bestimmten Nutzungskontext
genutzt werden kann, um bestimmte Ziele effektiv und
effizient zu erreichen
 Funktionale Sicherheit: die Summe der Eigenschaften eines
Produkts, die dazu beitragen, dass es frei von nicht
vertretbaren Risiken oder Gefahren ist
 Informationssicherheit: bedeutet, dass das Produkt mit dem
von ihm verarbeitete oder gespeicherte Informationen, nichts
tut, was von ihm nicht erwartet wird
48
Anforderungen ermitteln
 Randbedingungen reduzieren den möglichen
Lösungsraum, Beispiele sind gesetzliche
Bestimmungen wie der Datenschutz im
Softwaresystem
49
Anforderungen spezifizieren
 Durch die Spezifikation werden Details klar,
Zusammenhänge transparent
 Anforderungen testbar und entscheidbar beschreiben
 Aufgaben und Lösungsbeschreibung müssen klar
getrennt werden
 Schritte zur Spezifikation:
 Die verschiedenen Interessengruppen identifizieren
 Vision und Zielsetzung definieren
 Anforderungen ermitteln
50
Anforderungen spezifizieren
 Anforderungen strukturiert spezifizieren
 Systemumgebung beschreiben
 Lösungsraum bestimmen
 Kundenkontakte beschreiben
 Anforderungen: vorläufige Analyse
 Klassifizieren und Priorisieren der Anforderungen
 Prüfen der Anforderungen
 Das Problemraum modellieren
 Lösungsraum modellieren und beschreiben
51
Anforderungen modellieren und analysieren
 Die Analyse beschäftigt sich mit der Beschreibung der
Lösung und die genauen Schritten dazu. Das Ergebnis der
Analysephase ist die Spezifikation eines Lösungsmodells.
 Die Beschreibung der Lösung führt zu neuen Fragen und
weiteren Anforderungen.
 Die Analysephase wird zweitgeteilt; nach einer ersten
Analyse vom Lieferant zum Zweck des Angebotserstellung,
wird eine zweite Analyse zum Projektstart durchgeführt
52
Anforderungen modellieren und analysieren
 Analyse beschreibt Funktionen, Schnittstellen,
Informationsaustausch, Zustände und die Interaktion
mit der Umgebung; sie liefert mehrere Modelle
dynamisch und statisch)
 Die Modelle beschreiben keine exakte
Implementierung; die unterstützen die
Kommunikation der Aufgaben- und
Lösungsbeschreibung
53
Anforderungen verifizieren und validieren
 Verifikation und Validierung sind die Schlüssel um
Fehler in Anforderungen und Spezifikationen zu
finden.
 Validierung: „doing the right things“; vergleicht
Anforderungen an das Produkt mit verfügbaren
Ergebnissen; externe Sicht
 Verifikation: „doing things right“; vergleicht
Prozessanforderungen mit Prozessergebnissen;
Prozesssicht
54
Anforderungen verifizieren und validieren
 Qualitätskriterien für Anforderungen :
Geschäftsnutzen, Korrektheit, Eindeutigkeit,
Verständlichkeit, Vollständigkeit, Konsistenz,
Nachverfolgbarkeit, Relevanz
55
Anforderungen vereinbaren
 Ausgewählte Anforderungen werden einem Projekt
zugewiesen, erst dann können realistische Vereinbarungen
mit dem Kunden geschlossen werden und man kann mit
den Entwicklungsarbeiten beginnen.
 Da Anforderungen unstabil sind, heißt vereinbaren nicht
einfrieren;
 Ab dem Projektstart müssen alle Anforderungen
verbindlich kontrolliert werden, Änderungen unterliegen
dem Änderungsmanagement
56
Anforderungen vereinbaren
 Produkte sind dann erfolgreich, wenn
 Der Eintrittstermin stimmt
 Die Qualität den Anforderungen des Markts genügt
 Der Preis konkurrenzfähig ist
 Ein Bedarf an dem Produkt besteht oder erzeugt
werden kann
57
Änderungen managen
 Änderungen müssen sorgfältig geprüft werden, in das
Projekt aufgenommen und verfolgt werden.
 Ein gutes Projekt beherrscht die Änderungen und
wird nicht von Ihnen beherrscht.
 Änderungen in der Umgebung verursachen
Änderungen der Anforderungen
 Anforderungen können sich zu jedem Zeitpunkt
ändern, denn man lernt ständig etwas neues zu dieser
Anforderung
58
Änderungen managen
 Anforderungen und deren Änderungen müssen
kontrolliert und verfolgt werden, um ihren Einfluss im
Projekt zu erkennen.
 Für einen Tester ist wichtig zu wissen, welche
Testfälle sich auf welche Anforderungen beziehen.
59
Werkzeugunterstützung
 Spreadsheets – selbstgemachte Templates in einer
Tabellenkalkulation; sie erlauben eine wirksame
Kontrolle von Anforderungen in kleinen Projekten
 Wikis – erlauben den unmittelbaren Zugriff
verschiedener Benutzer zur Organisation von
Anforderungen; man kann ein vorhandenes Template
oder ein komplettes Hosting von einer externen
Quelle übernehmen und entsprechend anpassen
60
Werkzeugunterstützung
 Workflow- Tools – sie beschreiben eine Abfolge von
Schritten, beispielweise von der Ermittlung bis zur
Freigabe, die dann an verschiedenen Personen
weitergeleitet werden kann; Bugzilla, Mylyn(Pflege
von Verknüpfungen)
61
Vielen Dank!!!
62