Requirements Management
add contents
Top1 Links und Referenzen
Top2 Einführung
Top2.1 Abkürzungen
- IREB e.V.: International Requirements Engineering Board,
gegründet 2007 von unabhängigen Experten, Ziel: Standardisierung der Aus-/Weiterbildung
im Bereich Requirements Engineering, hierzu Einführung eines Zertifikates: CRPE,
Internetseite des IREB mit aktuellem Glossar
und Prü+fungsmodalitäten
- CRPE: Certified Professional for Requirements Engineering,
Zertifikat des IREB e.V.
- iSQI: International Software Quality Institute,
Zertifizierungsstelle
- QAMP: Quality Assurance Management Professional,
Nachweis für lebenslanges Lernen, Zertifikat muss jährlich durch Nachweis
fachspezifischer Tätigkeit erneuert werden, modulares Weiterbildungskonzept
von iSQI
- IREB Certified Professional for Requirements Engineering:
erster Baustein der QAMP-Zertifizierung
Top2.2 Begriffe
- Requirement/Anforderung:
Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen muss
- Stakeholder / Projektbetroffener:
Person oder Organisation, die Anforderungen beeinflusst
- Requirements Engineering:
kooperativer, iterativer, inkrementeller Prozess mit folgenden Zielen:
- alle relevanten Anforderungen sind mit der benötigten Detaillierungstiefe
bekannt
- alle Stakeholder haben ausreichende Übereinstimmung über die Anforderungen
- Dokumentations-/Spezifikationsvorschriften werden erfüllt
Top2.3 Motivation und Zielsetzungen
- Requirements Engineering ist Schlüsseldisziplin der Systementwicklung,
Requirement Engineer ist zunehmend eine eigenständige Rolle mit
anspruchsvollen Tätigkeiten
- zentrales Ziel: Entwicklung von Systemen, die den Kunden zufriedenstellen,
dabei Einhaltung der Zeit- und Budgetpläne
- möglichst vollständig die Kundenanforderungen in guter Qualität dokumentieren
- Fehler möglchst frühzeitig erkennen
- Zielsetzungen des Requirement Engineering
- Erreichung von Gechäftsvorteilen:
Anforderungen finden mit größtmöglichen und am schnellsten zu
erreichenden Vorteilen
- Anforderungen effizient und effektiv erfassen
- Verbesserung der Kommunikation zwischen IT- und Business-Welt
- fehlerfreie und vollständige
Anforderungen als Basis für erfolgreiche Systementwicklung
(erst später im Entwicklungsprozeß entdeckte Fehler verursachen
einen vielfachen Aufwand zur Behebung)
- Häufige Probleme
- aufgrund ungenügender Beachtung der Anforderungen scheitern
viele Projekte oder leiden unter erheblichen Zeit/Budgetüberschreitungen
- 60% der Fehler in Entwicklungsprojekten entstehen bereits im
Requirements Engineering
- mögliche Ursachen:
- falsche Annahme der Stakeholder, dass vieles selbstverständlich ist
- Kommunikationsprobleme zwischen den Beteiligten
- Anforderungen zu ungenau formuliert, verschiedenartig interpretierbar
- Übersehen eines Stakeholders
Top2.4 Haupttätigkeiten des RE
- Ermitteln der Anforderungen
- Dokumentation der Anforderungen (Prosa, Modell)
- Prüfung und Abstimmung der erfassten Anforderungen
- Verwaltung der Anforderungen (Requirements Management), inkl.
Strukturierung und Aufbereitung
Top2.5 Kommunikation
- Sprache dient als Medium zur Kommunikation von Anforderngen.
Zur Vermeidung von Mißverständnissen sinnvoll: Einführung eines Glossars
oder Einsatz einer formalen Beschreibungssprache (z.B. UML).
Top2.6 Eigenschaften eines Requirements Engineer
Fachwissen
Der RE pflegt direkten Kontakt zu allen Stakeholdern und muss sich
in deren Fachgebiet in ausreichendem Maße einarbeiten.
Der RE besitzt ausserdem genügend IT-Wisssen, so dass er als Dolmetscher
zwischen den Fachgebieten der Stakeholder und
den Belangen der Entwickler eine zentrale Rolle im Projekt einnehmen kann.
Methodenwissen
???
Softskills
- Analytisches Denken: für schnelle Einarbeitung in neue Fachgebiete, Abstrahierung
konkreter Aussagen/Beispiele der Stakeholder
- Empathie: Erkennen des tatsächlichen Bedarfs, Berücksichtigung gruppendynamischer
Effekte unter den Stakeholdern
- Kommunikaionsfähigkeit
- Konfliktlösungsfähikeit: Erkennen und Lösen von Konflikten zwischen
den Stakeholdern.
- Moderationsfähigkeit: Vermittlung zwischen nterschiedlichen Meinungen,
Leiten von Diskussionen
- Selbstbewußtsein: häufig im Mittelpunkt, manchmal der Kritik ausgesetzt
- Überzeugungsfähigkeit: "Anwalt" der Anforderungen, Konsolidierung
unterschiedlicher Meinungen unter den Stakeholdern (Herbeiführen
einer Entscheidung)
Top2.7 Arten von Anforderungen
- Funktionale Anforderungen:
legen die vom betrachteten System bereitzustellende Funktion fest, häufig
unterteilt in Funktions-, Verhaltens-und Strukturanforderungen
- Qualitätsanforderungen:
qualitative Eigenschaften des betrachteten Systems, typischerweise:
Performance, Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit,
Portabilität
- Randbedingungen:
organisatorische Vorgaben (z.B. erforderlicher Fertigstellungstermin)
oder technologische Vorgaben (z.B. Realisierung als Web-Service), die
den Lösungsraum im Entwicklungsprozeß einschränken
Top3 Abgrenzung System und Systemkontext
Top3.1 Systemkontext
- Identifikation des Teils der Umgebung/der Realität, der für das System relevant ist
- Der Ursprung aller Anforderungen an das System liegt im Systemkontext
- unvollständige Erfassung des Systemkontexts führt
zu unvollständigen/fehlerhaften Anforderungen
- Mögliche Aspekte im Systemkontext
- Personen (Stakeholder)
- andere technische Systeme
- (technische) Prozesse, Geschäftsprozesse
- Ereignisse
- Dokumente (z.B. Standards)
Top3.2 Systemabgrenzung/Systemgrenze
Bestimmung der Systemgrenze: Was wird von
dem zu entwickelnden System abgedeckt? Was ist Teil der Umgebung?
- Identifikation der Schnittstellen des Systems mit seiner Umgebung.
- Quellen liefern Eingaben für das System.
- Senken erhalten Ausgaben vom System.
- Grauzone der Systemabgrenzung kann sich während des RE-Prozesses
noch verschieben. Am Ende des RE-Prozesses muss die Grauzone aufgelöst sein,
damit alle Systemschnittstellen bekannt sind.
Top3.3 Kontextabgrenzung/Kontextgrenze
Abgrenzung zur irrelevanten Umgebung, Erfassung aller Aspekte, die für
die Anforderungen an das System relevant sind.
- Grauzone der Kontextabgrenzung kann sich während des RE-Prozesses
noch verschieben. Häufig ist es aber nicht möglich/erforderlich
am Ende des RE-Prozesses die Grauzone der Kontextabgrenzung vollständig aufzulösen.
Top3.4 Dokumentation des Systemkontexts
- Use-Case-Diagramme
- Datenflussdiagramme mt Quellen und Senken
- UML-Klassendiagramme
- i.d.R. Kombination verschiedener Dokumentationsformen
Top4 Ermittlung von Anforderungen
Ausgangspunkt: Systemkontext des zu entwickelnden Systems
Top4.1 Anforderungsquellen
- Stakeholder (Personen, Organisationen)
- Es ist notwendig alle Stakeholder möglichst frühzeitig zu
ermitteln, um alle wesentlichen Anforderungen erfassen
zu können (sonst Zusatzkosten durch später erforderliche Änderungen)
- Verwaltung der Stakeholder in Listen (Name, Funktion, Vefügbarkeit,
Wissensgebiet, Ziele und Interessen),
Ausgangspunkt: Vorschlag aus Management und von Fachexperten
- kontinuierlicher Informationsfluss erforderlich um ausBetroffenen
Beteiligte zu machen
- Aufgaben des Requirements Engineer: spricht Sprache der Stakeholder,
arbeitet sich in Fachgebiet gründlich ein, erstellt und erläutert
Anforderungsdokument, sorgt dafür dass das System den Ansprüchen
der Stakeholder gerecht wird.
- Aufgaben des Stakeholders: führt RE in Fachgebiet ein, liefert
priorisierte Anforderungen, überprüft die dokumentierten Anforderungen
des RE
- Dokumente
- Systeme in Bertieb (Vorgängersystem, Konkurrenzsystem)
Top4.2 Anforderungskategorisierung(Kano-Modell)
- Basisfaktoren: selbstverständlich vorausgesetzte Merkmale,
unbewusstes Wissen, müssen in jedem Fall vollständig erfüllt werden, um größere
Unzufriedenheit mit dem System zu verhindern, Ermittlung über Beobachtungstechniken
und dokumentenzentrierte Techniken
- Leistungsfaktoren: explizit geforderte Merkmale,
bewusstes Wissen, Ermittlung durch Befragungstechniken
- Begeisterungsfaktoren: dem Stakeholder unbekannte Merkmale, die er erst während
der Benutzung als nützlich erkennt, unterbewusstes Wissen, tragen in benderem
Maße zur Zufriedenheit mit dem realisierten System bei,
Ermittlung durch Kreativitätstechniken
WEITER AB S. 32