Requirements Engineering

Präsentation zum Thema: "Requirements Engineering"—  Präsentation transkript:

1 Requirements Engineering
IT SERVICES,

2 2/3 der Fehler entstehen bereits beim Requirements Engineering
Anteil Fehlerentstehung nach Phasen

3 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.

4 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 .

5 + 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 Management Requirements Analyse umfasst das Erheben, Dokumentieren und Prüfen von Anforderungen. Requirements Management umfasst das Management der Änderungen von Anforderungen und die Pflege ihrer Spezifikation. (Quelle; CRE Glossar)

6 Template Anforderungsspezifikation
1 ALLGEMEINES 1.1 Zweck des Dokumentes 1.2 Informationen zum Dokument 1.3 Änderungsübersicht 1.4 Verteiler 1.5 Abkürzungen 2 REQUIREMENTS ENGINEERING SCOPE 3 GESCHÄFTSPROZESS 3.1 Interessengruppen (Stakeholder) 3.2 Geschäftsprozessabgrenzung 3.3 Katalog zu Fachbegriffen (Glossar) 4 FUNKTIONALE ANFORDERUNGEN 4.1 IT-System Grenzen 4.2 Anwendungsfälle 4.3 Testfälle 4.4 Geschäftsobjekte/Daten 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

7 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

8 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

9 Zielgruppen der Anforderungsspezifikation

10 Beispiel Grob-/Feinspezifikation

11 Erheben von Anwenderanforderungen

12 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

13 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

14 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? Welchen Zweck erfüllt …? WOZU könnte … benutzt/ benötigt werden? 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

15 Modellierung von Anwenderanforderungen
Verwendung des Industriestandards Unified Modeling Language (UML) zur grafischen Spezifikation von Anwenderanforderungen Lieferung veranlassen [Ware vorrätig] Rechnung stellen [Zahlung erfolgt] Bestellung entgegennehmen [Bestellung eingegangen] [Ware nicht vorrätig] Auf Wareneingang warten Stakeholder Auftragsbearbeitung Lager Warenbestand prüfen Ware ausliefern