ANFORDERUNGSDOKUMENTE. Dr. Peter Hruschka. Requirements Engineering!

Transkript

1 1 ANFORDERUNGSDOKUMENTE Dr. Peter Hruschka Atlantic Systems Guild Aaachen London New York

2 2 Sie lernen Qualitätseigenschaften von Requirements-Dokumenten Standardinhalte für Requirements-Dokumente

3 3 ANFORDERUNGSDOKUMENTE

4 4 Anforderungsdokument oder Anforderungsspezifikation) Andere Bezeichnungen:! Requirements-Spezifikation, Funktionale Spezifikation Manchmal zweistufig: User Requirements Specification (URS) + Software Requirements Specification (SRS) Lastenheft + Pflichtenheft Vielleicht auch dreistufig:" Marketing-Spec + User-Spec + Product-Spec

5 5 WARUM ÜBERHAUPT DOKUMENTE?

6 6 Basis für Systementwicklung Rechtlich relevant Bewältigung der Komplexität, Überblick bewahren Zugänglich für alle Projektbeteiligten

7 7 Inhaltsgestaltung: Natürliche Sprache Für (fast) jeden leicht lesbar Kein Lernaufwand (grafische) Modelle Mehr Formalität als natürliche Sprache eindeutiger, weniger interpretierbar Grafischer Überblick -> Komplexität besser beherrschbar als durch nur Text Mischformen: die heute ideale Form " eines RE-Dokuments

8 Empfehlung: Modelle eher zur Strukturierung/Gliederung von Anforderungen" (Funktionen gliedern in Use Cases, Activities,...; Daten gliedern durch Entity/Relationship- Diagramme oder Klassendiagramme) Natürlichsprachige Anforderungen für die Details

9 9 ANFORDERUNGEN AN DIE REQUIREMENTS-DOKUMENTATION (gemäß IEEE )

10 10 Eindeutigkeit und Konsistenz! Voraussetzung: einzelne Anforderungen eindeutig und in sich konsistent Keine Widersprüche zwischen verschiedenen Anforderungen Klare Struktur! Modifizierbarkeit und Erweiterbarkeit! Mit Versionsverwaltung (siehe Requirements Management)" Vollständigkeit! Alle (für den nächsten Release) relevanten Anforderungen enthalten Formal vollständig (Referenzen, Verweise)" Verfolgbarkeit! zu anderen Dokumenten (siehe Requirements Management)

11 11 Verwenden Sie eine vordefinierte, standardisierte Dokumentenstruktur! für Requirementsdokumente. Sie hilft Requirements systematisch zu erheben ihre Vollständigkeit zu prüfen und Requirements wiederzuverwenden

12 12 BEISPIELE FÜR DIE STRUKTUR VON REQUIREMENTS-DOKUMENTEN

13 Volere James & Suzanne Robertson: Mastering the Requirements Process, 3 rd Edition Addison Wesley, 2012" oder: Project Drivers! 1. The Purpose of the Product 2. The Stakeholders Project Constraints! 3. Mandated Constraints 4. Naming Conventions and Terminology 5. Relevant Facts and Assumptions Functional Requirements! 6. The Scope of the Work 7. Business Data Model & Data Dictionary 8. The Scope of the Product 9. Functional Requirements Non-functional Requirements! Project Issues! 10. Look and Feel Requirements 11. Usability and Humanity Requirements 12. Performance Requirements 13. Operational and Environmental Requirements 14. Maintainability & Support Requirements 15. Security Requirements 16. Cultural Requirements 17. Legal Requirements 18. Open Issues 19. Off-the-shelf Solutions 20. New Problems 21. Tasks 22. Migration to the New Product 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions 13

14 PROJEKTTREIBER 1. Ziele des Projekts 2. Stakeholder RANDBEDINGUNGEN FÜR DAS PROJEKT 3. Geforderte Randbedingungen 4. Namenskonventionen und Terminologie 5. Relevante Fakten und Annahmen DAS PROJEKT Ziele Purpose: Advantage: Measure: Wer? Wozu?.. Stakeholder-" tabelle Ereignisliste Business-Use-Case- Spezifikationen IT-relevanter Ausschnitt n.. EINBETTUNG IN 14 DAS ARBEITSGEBIET BusinessKontext FUNKTIONALE ANFORDERUNGEN 6. Einbettung in das Arbeitsgebiet 7. Datenmodell 8. Umfang des Produkts 9. Funktionale Anforderungen Klassenmodell Klassen-" Spezifikation Beziehungs-" Spezifikation Strukturiertes Glossar Attribut-" Spezifikation einzelne Anforderungen an Daten NICHT-FUNKTIONALE ANFORDERUNGEN 10. Anforderungen an die Benutzungsschnittstelle 11. Ergonomieanforderungen 12. Performanzanforderungen 13. Operative und Umwelt-Anforderungen 14. Anforderungen an Wartbarkeit und Support 15. Sicherheitsanforderungen 16. Kulturelle Anforderungen 17. Rechtliche Anforderungen PROJEKTASPEKTE 18. Offene Punkte 19. Kauf und Wiederverwendung 20. Neue Probleme 21. Projektplanung 22. Anforderungen an Migration und Inbetriebnahme 23. Risiken 24. Kosten 25. Anwenderdokumentation und -schulung 26. Warteraum 27. Lösungsideen Produkt-Kontext einzelne nicht-funktionale Anforderungen Produkt-Use-Case-" Diagramm Produkt-Use-Case- Spezifikationen DAS PRODUKT Aktivitäts-" diagramme Sequenzdiagramme Aktivitäts- diagramme (verfeinert) Aktivitäts- spezifikationen einzelne Anforderungen an Funktionen

15 15 IEEE Standard (Software Requirements Specification! 1.Introduction» Purpose (of the document)» Goal (of the product)» Links to Resources» Definitions of Terms, Abbreviations» Overview (how is the document structured) 2. General Description (of the software product)» Product Perspective (w.r.t other software products)» Product Functions (summary and overview)» Expected Users» Constraints (for the developers)» Assumptions and Dependencies 3.Specific Requirements» Functional Requirements» Nonfunctional Requirements» External Interfaces» Design Constraints» Performance Requirements» Quality Requirements» Other Requirements

16 16 Andere IEEE Standards:! IEEE Standard Guide for Information Technology - System Definition - " Concept of Operations Document " IEEE Standard Guide for Developing System Requirements Specifications"

17 17 V-Modell XT: Vorgeschlagene Lastenheft-Struktur 1. Einleitung 2. Ausgangssituation und Zielsetzung 2.1 Ausgangssituation 2.2 Zielsetzung 3. Funktionale Anforderungen 4. Nicht Funktionale Anforderungen 5. Skizze des Lebenszyklus und der Gesamtsystemarchitektur 5.1 Lebenszyklus 5.2 Gesamtsystemarchitektur 6. Lieferumfang 6.1 Lieferumfang 6.2 Kosten 6.3 Liefertermin 6.4 Ansprechpartner und Lieferort 7. Abnahmekriterien 8. Anforderungsverfolgung 9. Abkürzungsverzeichnis

18 18 MINDESTINHALTE

19 19 1. ZIELE! 2. STAKEHOLDER! 3. KONTEXTABGRENZUNG! 4. FUNKTIONALE ANFORDERUNGEN! Abläufe! Daten! 5. NICHT-FUNKTIONALE ANFORDERUNGEN! Qualitätsanforderungen! Randbedingungen! 6. GLOSSAR und ABKÜRZUNGSVERZEICHNIS

20 ZUSAMMENFASSUNG

21 21 Nutzen Sie einen Standard oder eine Mustergliederung für Ihre Anforderungen um Vollständigkeit sicherzustellen als Hilfe bei der Erhebung aller Arten von Anforderungen als Unterstützung, um die Bedürfnisse unterschiedlicher Stakeholder zu befriedigen Achten Sie darauf, dass Ihre Methode die IEEE- Anforderungen erfüllt, soweit Sie diese Qualitätsaspekte brauchen.