Requirements Dokumentation Seminar- Requirements Engineering. Manoj Samtani Oliver Frank

Transkript

1 Requirements Dokumentation Seminar- Requirements Engineering Manoj Samtani Oliver Frank TU Berlin SS 2007

2 Inhaltsübersicht Ziel des Dokumentierens Dokumentation vs. Spezifikation Qualitätskriterien für Anforderungen und Anforderungsdokumente Typen von Anforderungsdokumenten Dokumentationsformen TU Berlin SS

3 Inhaltsübersicht Vorteile und Nachteile der natürlichsprachlichen Dokumentation Techniken zur Vermeidung von Mehrdeutigkeit Strukturierung einer Anforderung und eines Anforderungsdokuments Referenzstrukturen TU Berlin SS

4 Anforderungsbegriff Eine Anforderung ist eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft, die ein System bzw. eine Person benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. [Pohl 2007] S TU Berlin SS

5 Vorteile des Dokumentierens Persistenz Gemeinsame Informationsbasis Fördert Kommunikation Einarbeitung neuer Mitarbeiter Unabhängigkeit von Wissensträgern TU Berlin SS

6 Ziel des Dokumentierens Inhalt Ziel vollständig Übereinstimmung vage konsolidierte Sicht individuelle Sicht informell gemäß Vorschriften Dokumentation [Pohl 2007] S TU Berlin SS

7 Dokumentation vs. Spezifikation Anforderungen müssen auf Deutsch dokumentiert werden. Spezifikationsvorschrift Allgemeine Dokumentationsvorschrift Dokumentationsvorschrift Der Realisierungsaufwand einer Anforderung Protokolle muss sind eine der drei Kategorien mit Datum zu hoch, mittel oder versehen. gering eingeordnet sein. Dokumentierte Anforderungen Spezifizierte Anforderungen Dokumentierte Informationen [Pohl 2007] S TU Berlin SS

8 Qualitätskriterien für Anforderungen Vollständigkeit Ist die Anforderung vollständig erfasst? Korrektheit (Achtung: Gold Plating) Widerspruchsfreiheit Eindeutigkeit Verständlichkeit Der Fahrer gibt zur Authentifizierung eine elektronische Karte und eine PIN ein. Ist diese nicht gültig, kann das Fahrzeug nicht gestartet werden. [Pohl 2007] TU Berlin SS

9 Qualitätskriterien für Anforderungsdokumente Vollständigkeit Umfasst das Anforderungsdokument alle notwendige Anforderungen? Konsistenz Änderungsfreundlichkeit Lesbarkeit TU Berlin SS

10 Typen von Anforderungsdokumenten Im deutschsprachigen Raum Lastenheft (vom Auftraggeber) Pflichtenheft (vom Auftragnehmer) Im englischsprachigen Raum System Requirements Specification Software Requirements Specification (SRS) TU Berlin SS

11 Lastenheft Das Lastenheft enthält die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragsnehmers (DIN ) Definition der Systemvision ( Was? ) Beschreibung der Funktionen und Qualitäten ( Wie? ) R-12: Das zu erstellende Sicherheitssystem muss über eine Benutzer- und Zugriffsverwaltung verfügen. [Pohl 2007] TU Berlin SS

12 Lastenheft (2) Grundlage für Pflichtenheft Basis für Ausschreibungen bzw. Vertragsverhandlungen Bewertung der Make-or-Buy Entscheidung Grundlage für Risikoabschätzung TU Berlin SS

13 Pflichtenheft Beschreibt die Umsetzung des Lastenhefts Detaillierung von Anforderungen im Pflichtenheft: R-8: Das Sicherheitssystem soll die Definition eines Administrator ermöglichen. R-14: Der Administrator soll neue Benutzer des Systems anlegen können. R-23: Der Benutzer soll seinen Passwort ändern können. [Pohl 2007] TU Berlin SS

14 Lasten- und Pflichtenheft WAS? Vision WIE? WAS? Lastenheft Sicht des Auftraggebers WIE? Pflichtenheft Sicht des Auftragnehmers [Pohl 2007] S TU Berlin SS

15 Pflichtenheft (2) Grundlage für Projektplanung und Architekturentwurf Grundlage für Tests und Systemabnahme Vertragsmanagement! TU Berlin SS

16 Dokumentationsformen Natürlichsprachlich Modellbasiert (z.b. mit UML) TU Berlin SS

17 Modellbasierte Dokumentation Unterschiedliche Diagramme sinnvoll für unterschiedliche Arten von Anforderungen Ziele z.b. Use-Case Diagramme Szenarien z.b. Sequenz- bzw. Aktivitätsdiagramme Lösungsorientierte Anforderung Unterschiedliche Diagramme, je nach Perspektive TU Berlin SS

18 Modellbasierte Dokumentation von lösungsorientierten Anforderungen Lösungsorientierte Anforderungen können aus Zielen und Szenarien gewonnen werden Beschreiben alle Details die zur technischen Umsetzung der Anforderung nötig sind Betrachtung der Anforderung aus verschiedenen Perspektiven möglich TU Berlin SS

19 Perspektiven einer lösungsorientierten Anforderung [Pohl 2007] S TU Berlin SS

20 Vorteile natürlichsprachiger Dokumentation Domänenübergreifend Flexibel Beliebige Detaillierungs- bzw. Abstraktionsgrade Leicht anwendbar Kein Erlernen zusätzlicher Techniken oder Werkzeuge nötig TU Berlin SS

21 Nachteile natürlichsprachiger Dokumentation Unterspezifikation 1) durch Mehrdeutigkeiten in der Sprache Lexikalische Mehrdeutigkeit Synonym (z.b. Kundennummer Kunden-ID) Homonym (z.b. Bank, Schimmel, Steuer) Syntaktische Mehrdeutigkeit Die letzten fünf Zielorte und die Startpunkte werden im Anzeigefeld des Navigationssystems angezeigt TU Berlin SS

22 Nachteile natürlichsprachiger Dokumentation (2) Semantische Mehrdeutigkeit Wird eine Scheibe am Fahrzeug beschädigt und die Innenraumüberwachung des Fahrzeugs stellt einen Eindringling fest oder ein Tür des Fahrzeugs wird ohne Fahrzeugschlüssel geöffnet, löst das Sicherheitssystem einen Diebstahlalarm aus. Referentielle Mehrdeutigkeit 2) Generalität und Vagheit von Begriffen TU Berlin SS

23 Glossare Im Glossar werden Begriffe eindeutig definiert Definiert weiterhin Synonyme und verwandte Begriffe Vermeidung von Missverständnissen Unbekannte Begriffe können nachgeschlagen werden TU Berlin SS

24 Normsprachen Einschränkung der natürlichen Sprache Definiert zu verwendende Begriffe und Grammatik Domänenspezifisch TU Berlin SS

25 Prozess zur Erstellung einer Normsprache 1. Erhebung einer Liste von umgangssprachlichen Aussagen 2. Klärung und Definition von Fachbegriffen 3. Begriffe bzw. Anforderungen nach vorgegebenen Satzmustern standardisieren 4. Normierte Aussagen klassifizieren TU Berlin SS

26 Struktur einer Anforderung Weiterer Nachteil von natürlichsprachlicher Dokumentation: fehlende Struktur Problem: Wie kann man z.b. erkennen, ob jede Anforderung eine definierte Priorität hat? Lösung: Definition von Attributen für Anforderungen TU Berlin SS

27 Attribute von Anforderungen Attribut ist durch einen Namen, Semantik, Wertebereich und Wertesemantik definiert Menge aller Attribute für eine Klasse von Anforderungen (z.b. funktionale Anforderungen) wird Attributierungsschema genannt TU Berlin SS

28 Beispiel für ein Attributierungsschema [Pohl 2007] S TU Berlin SS

29 Vorteile von Attributierungsschemen Ermöglichen die strukturierte Festlegung der benötigten Attribute Helfen bei der Erkennung von Lücken Gleiche Informationen an gleicher Stelle TU Berlin SS

30 Referenzstrukturen für Anforderungen (Schablonen) Viele Attribute von Anforderungen sind nicht projektspezifisch => Festlegung einer Referenzstruktur (Schablone) für Attributierungsschemen sinnvoll Schablonen erleichtern die Einarbeitung von Mitarbeitern Volere TU Berlin SS

31 Struktur eines Anforderungsdokuments Auch hier Verwendung von Referenzstrukturen sinnvoll weil: Wissen wiederverwendet wird Überprüfung auf Vollständigkeit leichter möglich ist Der Requirements Engineer sich auf die Inhalte konzentrieren kann Gleiche Informationen am gleichen Ort zu finden sind Anforderungsdokumente dann Werkzeug unterstützt erstellt werden können TU Berlin SS

32 Referenzstruktur für ein Anforderungsdokument IEEE Standard TU Berlin SS

33 Zusammenfassung Dokumentation ist wichtiger Bestandteil des Requirements Engineering Verschiedene Qualitätskriterien sind zu beachten Zusammenfassen der Anforderungen in verschiedenen Dokumenttypen möglich Strukturierung zum Wiederauffinden und Überprüfen von Informationen wichtig TU Berlin SS

34 Diskussion Wieviel Dokumentation ist sinnvoll? TU Berlin SS

35 Literatur [Pohl 2007]: K. Pohl: Requirements Engineering - Grundlagen, Prinzipien, Techniken (Gebundene Ausgabe), dpunkt.verlag, Heidelberg, Februar TU Berlin SS