Transcript No Slide Title

Requirements Engineering
IT SERVICES,
IT SERVICES
2/3 der Fehler entstehen bereits beim Requirements Engineering
36%
1%
Fachkonzept
Realisierung
Test
63%
Anteil Fehlerentstehung nach Phasen
Seite 2
IT SERVICES
Anforderungen: Sinn und Zweck
Gründe für ein mangelhaftes RE?
Hauptsächlich:
■
■
■
■
Kommunikationsprobleme,
zu starke Ausrichtung auf schnelle Ergebnisse,
die Annahme, dass manches „selbstverständlich“ sei,
der Versuch, Kosten zu sparen.
Seite 3
IT SERVICES
Anforderungen: Sinn und Zweck
Gründe für ein mangelhaftes RE?
… und zudem:
■
■
■
■
■
■
■
■
Benutzer wolle keine Änderung.
Häufige „willkürliche“ Änderungen (Produkt- versus Entwicklungsprozess).
Schlechte Dokumentation.
Unklare Verantwortlichkeiten.
Stakeholder haben oft unterschiedliche Vorstellungen.
Mangelnde Abstimmung zwischen den Stakeholdern.
Funktionalität des Altsystems meist oft nicht (vollständig) bekannt.
Anwendungsdomäne ist oft unvollständig verstanden .
Seite 4
IT SERVICES
Definitionen
Requirements Engineering, Requirements Management
■
■
Requirements Engineering umfasst die Analyse und das Management der Anforderungen mit
ingenieurmäßigem Vorgehen.
(Quelle: CRE Glossar)
umfasst die Anforderungsanalyse, also das Ermitteln, Beschreiben, Abstimmen und
Prüfen von Anforderungen an ein IT-System
Requirements Engineering
Requirements
Analyse
Requirements Analyse umfasst
das Erheben, Dokumentieren
und Prüfen von Anforderungen.
+
Requirements
Management
Requirements Management umfasst
das Management der Änderungen
von Anforderungen und die Pflege
ihrer Spezifikation.
(Quelle; CRE Glossar)
Seite 5
IT SERVICES
Template Anforderungsspezifikation
■ 1 ALLGEMEINES
1.1
1.2
1.3
1.4
1.5
Zweck des Dokumentes
4.1
IT-System Grenzen
4.2
Anwendungsfälle
4.3
Testfälle
4.4
Geschäftsobjekte/Daten
Informationen zum Dokument
Änderungsübersicht
Verteiler
Abkürzungen
■ 2 REQUIREMENTS ENGINEERING
■
 4 FUNKTIONALE ANFORDERUNGEN
SCOPE
3 GESCHÄFTSPROZESS
3.1
Interessengruppen (Stakeholder)
3.2
Geschäftsprozessabgrenzung
3.3
Katalog zu Fachbegriffen (Glossar)
 5 SCHNITTSTELLEN
5.1
Benutzerschnittstelle
5.2
System- und Datenschnittstelle
 6 NICHTFUNKTIONALE
ANFORDERUNGEN
6.1
Qualitätsanforderungen
6.2
Gesetzliche Anforderungen und Randbedingungen
6.3
Technische Anforderungen und Randbedingungen
6.4
Unternehmens-/ Erstellungsprozessanforderungen
Seite 6
IT SERVICES
Anforderungen an eine Anforderungsspezifikation
■ Heninger
–Sollte nur das äußere Systemverhalten festlegen
–Sollte Beschränkungen bezüglich der Implementierung vermeiden
–Sollte leicht verständlich sein
–Sollte als Referenz für Systemwarter dienen (können)
–Sollte Vorüberlegungen zum Lebenszyklus des Systems enthalten
–Sollte akzeptable Reaktionen auf potenzielle Systemfehler
beschreiben
Seite 7
IT SERVICES
Anforderungen an eine Anforderungsspezifikation
■ Sommerville:
–Die Anforderungsspezifikation ist kein Design-Dokument. Soweit irgend
möglich, sollte es nur festlegen, WAS das System tun soll, NICHT, WIE
es das tun soll
■ Rombach:
–Empirisch belegt ist die Relevanz der vier C's
– Clarity
– Completeness
– Consistency
– Correctness
Seite 8
IT SERVICES
Zielgruppen der Anforderungsspezifikation
Seite 9
IT SERVICES
Beispiel Grob-/Feinspezifikation
Seite 10
IT SERVICES
Erheben von Anwenderanforderungen
Methoden zur Erhebung und
Spezifikation von
Anwenderanforderungen
Informale Methoden
Erhebungstechniken
Metaplantechniken
Interview
Fragebogen
Beobachtung
Selbstaufschreibung
Dokumentenstudium
Einarbeitung
Semiformale
Methoden
Formale Methoden
Strukturierte Methoden
Geschäftsprozessanalyse (ARIS)
Objektorientierte
Analyse
Prototyping
Benutzungsoberfläche
Verarbeitungslogik
Seite 11
IT SERVICES
Identifikation von Anforderungen
■ Kartenfrage an die Stakeholdern (die „Stimme des Stakeholdern“):
“Welche Forderungen stelle ich an das Produkt?”
■ Hilfestellungen
– Orientierung an den zu unterstützenden Geschäftsprozessen und den enthaltenen
Aktivitäten sowie an positiven/negativen Erlebnissen bei der Nutzung früherer
Software bzw. bei zu unterstützenden Geschäftsprozessen
– Orientierung am Stakeholdernnutzen, den Anwendungszielen im Sinne von
Vorteilen für den Benutzer/Auftraggeber durch Nutzung des Produkts,
zu lösenden Probleme, zu erreichenden Wirkungen etc.
– Implementationsunabhängigkeit beachten und „Lösungen“ zurückstellen!
– Unklare Aussagen erläutern lassen und präzisieren z. B. anhand der 6W-Fragen
insb. „Warum“ und „Wozu“ eine Anforderung benötigt wird
Seite 12
IT SERVICES
Vom Stakeholdern erhalten Sie die folgenden Anforderungen …
■ Ein Monatsbericht wird erstellt
■ Das System muss die Berechnung der Statistik innerhalb einer Stunde zu Ende bringen
■ Die Auslastung der Systemressourcen soll überwachbar sein
■ Die Online-Abfrage soll leicht durchführbar sein
■ Sonstige Benutzer sollen nur allgemein verfügbare Statistiken einsehen dürfen
■ Dem System soll bekannt sein, welche Daten im Archiv vorzuhalten sind
■ Das System soll die Daten einer anderen Zweigstelle empfangen und diese verarbeiten können
■ Die Performanz des Systems soll auch bei massiver Erweiterung nicht unter die geforderten
Werte fallen
■ Das System soll die Möglichkeit bieten, Kostenstellenberichte abzurufen
Seite 13
IT SERVICES
Identifikation von Anforderungen mit der 6W-Methode
Frage
Heute
Zukunft
WER
WER nutzt/ benötigt …?
WER könnte …. benötigen?
WOZU / WAS
WOZU wir … benutzt/
benötigt?
WOZU könnte … benutzt/
benötigt werden?
Welchen Zweck erfüllt …?
WARUM
WARUM wird … benötigt?
WARUM könnte … benötigt
werden?
WANN
WANN wird … benötigt?
WANN könnte … benötigt
werden?
WO
WO wird … benötigt?
WO könnte … benötigt werden
WIE(-VIEL)
WIE wird .. Benötigt?
WIE könnte .. Benötigt werden
Seite 14
IT SERVICES
Modellierung von Anwenderanforderungen
■
Verwendung des Industriestandards Unified Modeling Language (UML) zur grafischen
Spezifikation von Anwenderanforderungen
Stakeholder
[Bestellung
eingegangen]
Auftragsbearbeitung
Lager
Bestellung
entgegennehmen
Warenbestand prüfen
[Ware nicht
vorrätig]
[Ware vorrätig]
Rechnung
stellen
Auf Wareneingang
warten
Lieferung veranlassen
Ware
ausliefern
[Zahlung erfolgt]
Seite 15
IT SERVICES