Requirements Engineering

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. Requirements Engineering + Requirements Analyse Requirements Management 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 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

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