Warum Anforderungsmanagement. Warum Anforderungsmanagement. 2.1 Grundlagen

Transkript

1 Warum Anforderungsmanagement Begriffe nach IEEE Arten von Anforderungen Nicht-funktionale Anforderungen Eigenschaften von Anforderungen Ziele des RE H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen Warum Anforderungsmanagement Anforderungsfehler Entwurfsfehler Codierfehler Review d. Anforderungen Review d. Entwurfs Code Review Integrationstest Betrieb Warum Anforderungsmanagement Jedes Produkt soll bestimmte Anforderungen erfüllen Diese müssen definiert werden! Systemanalyse Systematische Vorgehensweise, um (iterativ) die Anforderungen an ein Produkt zu ermitteln Requirements Engineering Pflichtenheft Ergebnis der Systemanalyse Oft wird auch der Begriff Anforderungsspezifikation oder Spezifikation verwendet Probleme Quelle: R. Dunn, Software Defect Removal, McGraw-Hill

2 Begriffe nach IEEE requirement 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. 3. A documented representation of a condition or capability as in (1) or (2). requirements analysis 1. The process of studying user needs to arrive at a definition of system, hardware, or software requirements. 2. The process of studying and refining system, hardware, or software requirements. requirements specification A document that specifies the requirements for a system or component. Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards. Arten von Anforderungen Funktionale Anforderung Nicht-funktionale Anforderung funktionale Anforderung Anforderung nicht-funktionale Anforderung Qualitätsanforderungen Nicht-funktionale Anforderungen nicht-funktionale Anforderung Randbedingungen für den Entwurf Anforderungen an den Prozess Beispiel Nicht-funktionale Anforderungen muss weniger als 70gr wiegen Muss nach dem Einschalten in weniger als 5 s funktionsbereit sein Benutzbarkeitsanforderungen Effizienzanforderungen Vorgaben für Einbettung und Verteilung Vorgeschriebene Technologie Anforderungen an das Vorgehensmodell Anforderungen an die Inbetriebnahme muss ohne Training benutzbar sein Die Strahlung muss unter... liegen Zuverlässigkeit- und Verfügbarkeitsanforderungen Portabilitätsanforderungen Sicherheitsanforderungen Gesetzliche Anforderungen Physikalische Anforderungen Umweltanforderungen Anforderungen an den Systemsupport P. Hruschka, REDays 2001 Muss mit den Akkus der 5 Hauptanbieter ausstattbar sein Das Gehäuse darf vom Benutzer nicht zu öffnen sein Das Telefonbuch muss von den Vorgängern seit 1998 übernehmbar sein P. Hruschka, REDays

3 Eigenschaften von Anforderungen - 1 Eigenschaften von Anforderungen - 2 Inhaltlich sollten Anforderungen folgenden Kriterien genügen zutreffend (korrekt) Sie soll die Vorstellungen des Kunden richtig wiedergeben. testbar Das realisierte System soll anhand der Anforderungen überprüfbar sein. Man spricht hier auch von testbaren Anforderungen. Der Kunde muss die formulierte Anforderung verstehen können vollständig Jede Anforderung muss die zu liefernde Funktionalität vollständig beschreiben notwendig Es sollen nur die Anforderungen aufgenommen werden, die der Kunde tatsächlich benötigt. Jede (in einem Kopf oder in einem Dokument) vorhandene Anforderung soll in der Spezifikation enthalten sein. widerspruchsfrei (oder konsistent) Keine Anforderungen soll mit den anderen unvereinbar sein. bewertbar Bei größeren Entwicklungen müssen die Anforderungen priorisiert werden. Fachliche Priorisierung, Dringlichkeit, Wichtigkeit Dazu müssen Anforderungen miteinander verglichen werden umsetzbar neutral Jede Anforderung muss auf Basis der bekannten Fähigkeiten realisierbar sein. Sie soll die Realisierung nicht vorwegnehmen Eigenschaften von Anforderungen - 3 Die Darstellung sollte leicht verständlich sein Alle Interessenten sollen in der Lage sein, die Anforderungen zu verstehen. präzise sein Eine Anforderung darf keine Unklarheiten lassen. Es darf kein Interpretationsspielraum vorhanden sein. In der Form sollten Anforderungen leicht zu erstellen sein Die Anfertigung und Nachführung der Spezifikation darf keinen unangemessen hohen Aufwand erfordern. leicht verwaltbar sein Die Speicherung der Spezifikation und der Zugriff darauf dürfen keinen unangemessen hohen Aufwand erfordern. verfolgbar sein Jede Anforderung muss für sich eindeutig zu identifizieren sein Anforderungen sind zu kennzeichnen Ziele des RE Verstehen und beschreiben, was ein System leisten soll Nicht wie! Verstehen des Kontextes z.b. Ziele des Unternehmens Anforderungen existieren immer nur in einem Kontext Herausarbeiten der essentiellen Bedürfnisse Reduktion der Anforderungen auf ihre fachliche Essenz Durch Abstraktion werden technologie- und lösungsneutrale Anforderungen ermittelt Verwalten der Anforderungen Versionierung Change-Management Tracebility

4 Allgemeine Vorgehensweise Techniken der Anforderungsermittlung Techniken der Anforderungsermittlung Nutzen der Spezifikation Beschreibungsmittel Formale und nicht-formale Notationen Allgemeine Vorgehensweise H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen Techniken der Anforderungsermittlung Befragungen Ziel: genaue, unverfälschte Anforderungen zu erhalten Arten: freies und fragebogengestütztes Interview Probleme: Interviews werden durch den Analytiker bestimmt Anforderungen können vergessen werden Beobachtungen Analytiker beobachtet die vorhandenen Arbeitsabläufe Geeignet für die Ist-Analyse Ergänzt Befragungen Brainstorming Gruppentechnik Alle können alle denkbaren Anforderungen äußern Techniken der Anforderungsermittlung Simulation und Prototyping Anforderungen werden teilweise erst dann sichtbar, wenn das System existiert. Ein Prototyp zeigt bestimmte Aspekte des zukünftigen Systems z.b. die Bedienoberfläche Prototypen können leicht und effektiv evaluiert werden. Prototypen müssen schnell und günstig herstellbar sein. Anwendungsfallmodellierung Ein Anwendungsfall beschreibt den Umgang mit dem zu erstellenden System aus der Außensicht. Sie sind ergebnis-, zielgetrieben Welches Ziel möchte ich erreichen? Beispiel: Geld am Geldautomaten beziehen H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen

5 Beschreibungsmittel Formale und nicht-formale Notationen Ziel der Anforderungsanalyse Um aus den Anforderungen auf eindeutige Art und Weise eine Lösung entwickeln zu können, die auf einem Computer lauffähig ist, muss das Ergebnis der Analyse eine Eigenschaft aufweisen: es muss formal sein. Realität Im Normalfall bilden die Anforderungen an ein Software-System kein formales Modell der fachlichen Logik. Typischerweise hat man eine unvollständige, mehrdeutige und widersprüchliche Aussagensammlung vorliegen. Um die geforderten Eigenschaften von Anforderungen zu erzielen, müssen geeignete Notationen gewählt werden. Natürliche Sprache Vorteile Nachteile Formale Sprachen Vorteile requirements specification language A specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document hardware or software requirements. IEEE Nachteile H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen Aufgabe und Inhalt Aufbau des Pflichtenhefts Hinweise Aufgabe Aufgabe und Inhalt Fasst alle fachlichen Anforderungen an das geplante System aus der Sicht des Auftraggebers zusammen. dokumentiert die Anforderungen an eine Software und ihre Schnittstellen, und zwar präzise, vollständig und überprüfbar. Adressaten Auftraggeber, Projektleiter, Systemanalytiker, Entwerfer... Inhalt Es wird beschrieben, WAS das System leisten soll. Es wird nicht beschrieben, WIE es funktionieren soll (lösungsunabhängig). Es kann als Basis für einen juristischen Vertrag dienen. Form strukturiert (auf Basis einer Vorlage) 1. Einleitung natürlichsprachlich 2. Produkt-Anforderungen Zeitpunkt 3. Nichtfunktionale Anforderungen Nach Abschluss der Planungsphase 4. Referenzen H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen 2.3 Pflichtenheft

6 1. Einleitung Aufbau des Pflichtenhefts Zweck und Ziele des Produkts Warum wird dieses Produkt gebraucht? Was soll damit erreicht werden? 1.2. Benutzer des Produkts Wer wird dieses Produkt nutzen (Nutzergruppen)? Wie sieht das Nutzerprofil aus? 1.3. Annahmen und Abhängigkeiten Welche Annahmen werden getroffen? Welche Randbedingungen müssen beachtet werden? 1.4. Definitionen und Namenskonventionen Glossar aller wichtigen fachlichen Begriffe und Abkürzungen Aufbau des Pflichtenhefts 2 2. Produkt-Anforderungen 2.1. Anwendungsbereich und Produktabgrenzung Wie grenzt sich die Funktionalität des Produkts zu anderen Systemen ab? Gibt es Schnittstellen zu anderen Produkten? Diese produzieren oder konsumieren Daten 2.2. Funktionale Anforderungen Was sind die zentralen Funktionen aus Sicht der Nutzer, die das Produkt zur Verfügung stellen muss? Funktionen können nach Aspekten gruppiert werden 2.3. Anforderungen an die Daten Welche Daten werden für das Produkt benötigt? Welche Daten müssen persistent gespeichert werden? Aussagen zum Daten-Volumen IEEE SRS S. Robertson, J. Robertson (1999): Mastering the Requirements Process, Addison-Wesley H. Lichter, RWTH Aachen 2.3 Pflichtenheft H. Lichter, RWTH Aachen Aufbau des Pflichtenhefts 3 3. Nichtfunktionale Anforderungen 3.1. Anforderungen an die Benutzungsschnittstelle Mit welchen Medien soll die Benutzungsschnittstelle gestaltet werden? 3.2. Anforderungen an die Handhabbarkeit Wie sollen die Nutzer das System bedienen können? Welches Wissen (Training) ist dazu notwendig? 3.3. Anforderungen an das Leistungsverhalten Anforderungen an Laufzeit, Antwortverhalten, Speicher etc Anforderungen an die Wartbarkeit des Produkts Einsatzdauer des Produkts Wo soll das System erweiterbar sein? 3.5. Anforderungen an die Sicherheit Übermittlung von Daten, Zugriff auf Daten 3.6. Anforderungen an die Entwicklungs- und Zielplattform Betriebsystem, Programmiersprache, Datenbank etc? 3.7. Sonstige Nichtfunktionale Anforderungen Inbetriebnahme System-Support Nutzen der Spezifikation Die Spezifikation (Pflichtenheft) ist der Angelpunkt der Software-Entwicklung und erforderlich für: Fehlt sie, dann hat das z.b. folgenden Konsequenzen H. Lichter, RWTH Aachen 2.3 Pflichtenheft H. Lichter, RWTH Aachen 2.3 Pflichtenheft

7 Hinweise Versuchen Sie, sprachlich exakt zu formulieren Vermeiden Sie : möglicherweise, kann, in den meisten Fällen etc. Quantifizieren Sie Ihre Anforderungen Schlecht: "Das System soll auf jedem gängigen PC installierbar sein" Besser: "PC-Konfiguration: min 31MB RAM, 300 MB Festplatte... Kennzeichnen Sie die Anforderungen z.b. durch Nummerierung Im Text soll eine Anforderung von dem dazu gehörenden erklärenden Text unterschieden werden können. Verwenden Sie Grafiken beispielsweise um Anforderungen zu erläutern Legen Sie ein Begriffslexikon an! Benutzen Sie die Begriffe dann auch nur gemäß dem Begriffslexikon. Wenn Informationen noch nicht verfügbar sind, dann kennzeichnen Sie die Stelle als "to be defined" (TBD) Sind Abschnitte im Musterdokument der Spezifikation nicht relevant, dann kennzeichnen Sie diese als "nicht anwendbar". Löschen Sie diese nicht! Ziele der Formulierung von Anforderungen Sprachliche Defekte Tilgungs-Regeln Generalisierungs-Regeln H. Lichter, RWTH Aachen 2.3 Pflichtenheft H. Lichter, RWTH Aachen Ziele der Formulierung von Anforderungen Ziel Anforderungen sollen präzise, vollständig und widerspruchsfrei formuliert werden. Wichtig ist, dass Anforderungen eindeutig verstanden werden. Beispiele Die Untersuchung von FBI-Agenten kann gefährlich sein Es kann gefährlich sein, FBI-Agenten zu untersuchen Die Untersuchungen, die FBI-Agenten durchführen, können gefährlich sein. Michaela zog Peters Hemd aus Michaela zog dem Peter das Hemd aus. Michaela zog das Hemd aus, das dem Peter gehörte. Erkenntnis Tilgung Sprachliche Defekte Bei der Formulierung natürlichsprachlicher Anforderungen werden häufig folgende Transformationen durchgeführt. Diese führen zu sprachlichen Defekten. Wir vergessen Aspekte! Generalisierung Wir formulieren allgemeingültige Aussagen, die aber nicht immer gelten! Fehler- und Sonderfälle fehlen Verzerrung Wir verfälschen Aspekte! Chris Rupp (2001): Requirements Engineering und Management, Hanser Verlag. H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen

8 Tilgungs-Regeln R1: Formulieren Sie jede Anforderung im Aktiv Schlecht: Das Kennwort wird an einem Terminal eingegeben Besser: Der Benutzer gibt das Kennwort am Terminal ein R2: Drücken Sie Prozesse durch Vollverben aus! Schlecht: Zwischen den Leihobjekten muss ein Unterschied gemacht werden Besser: Das System unterscheidet Buch-Leihobjekte und Zeitschriften- Leihobjekte R3: Vermeiden Sie unvollständig spezifizierte Prozesswörter! Schlecht: Leihobjekte, die 3 Jahre nicht mehr entliehen wurden, sollen erkannt und gemeldet werden Besser: Leihobjekte, die 3 Jahre nicht mehr entliehen wurden, werden durch das System an jedem Monatsende erkannt. Das System erstellt eine Liste dieser Leihobjekte und meldet diese dem Administrator. R4: Spezifizieren Sie Vergleiche und Steigerungen vollständig! Schlecht: Die Berechtigungen sollen leicht änderbar sein. Besser: Die Berechtigungen sollen durch den Administrator in einer einzigen Maske geändert werden können. Dieser Vorgang darf nicht mehr als 1 Minute dauern. Generalisierungs-Regeln R5: Hinterfagen Sie alle Universalquantoren! Signalwörter: nie", immer", kein", jeder", alle", irgendeiner", nichts" Gilt die Anforderung wirklich für alle Objekte? Gibt es Ausnahmen? Das System soll eine durch den Benutzer eingeleitete Sicherung von aufgezeichneten Daten auf Band ermöglichen." Fragen: Darf jeder Benutzer die Sicherung einleiten? Alle aufgezeichneten Daten? Immer? R6: Ermitteln Sie unvollständig spezifizierte Bedingungen Signalwörter: wenn", dann", falls", im Falle von" und abhängig von". Es soll die Möglichkeit bestehen, die einzelnen Felder der Stammdaten-Maske zu editieren (im Falle einer Störung der automatischen Datenübertragung)." Frage: Was soll möglich sein, wenn keine Störung vorliegt? H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen Ohne definierte Anforderungen kann nicht zielgerichtet entwickelt werden. Anforderungen müssen präzise und vollständig erfasst werden. Funktionale und nicht-funktionale Anforderungen Anforderungen werden iterativ ermittelt; alle Stakeholder müssen dazu bekannt sein. Das RE kennt eine Vielzahl von Notationen für Anforderungen informal, semiformal, formal Das Pflichtenheft fasst die Anforderungen aus Sicht des Auftraggebers zusammen. Auch natürlichsprachlich formulierte Anforderungen können präzise sein. Literatur Chris Rupp (2001): Requirements Engineering und Management Professionelle, Iterative Anforderungsanalyse für die Praxis, Hanser Verlag. Natürlichsprachliche Methoden H. Partsch (1998): Requirements Engineering systematisch, Springer Verlag Lehrbuch Überblick über Methoden und Notationen S. Robertson, J. Robertson (1999): Mastering the Requirements Process, Addison-Wesley Beschreibt den Volere Ansatz Enthält sinnvolle praxiserprobte Templates IEEE Guide To Software Requirements Specification (1984) Genormt als: IEEE Std H. Lichter, RWTH Aachen H. Lichter, RWTH Aachen