Pflichtenheft 1 Allgemeines 1.1 Nutzen

Transkript

1 Pflichtenheft 1 Allgemeines Oft wird im Bereich der Softwareentwicklung auf die Erstellung eines Pflichtenheftes verzichtet. Die Gründe sind dafür die Befürchtungen, dass sich dadurch die Entwicklung verzögert und sich das Projekt verteuert. In den meisten Fällen wird also nur kurz skizziert, was die neue Software leisten soll. Man nimmt sich vor, dass man am Ende der Entwicklung alles sauber dokumentieren wird. Die meisten Kunden wollen schnelle Ergebnisse sehen und interessieren sich zunächst einmal nicht für ein Pflichtenheft. Das kann ein fataler Fehler sein. 1.1 Nutzen Fehlt ein Pflichtenheft, dann lassen die geplanten Funktionen des Programms Raum für Interpretationen, da nichts richtig dokumentiert wurde. Sie können sicher sein, dass der Anwender während der Entwicklungsphase immer wieder Zusatz- und Änderungswünsche anbringen will. Des weiteren werden Dinge vorausgesetzt, die nie besprochen wurden, sondern nur als Gedankengebilde beim Anwender und/oder beim Entwickler vorhanden sind. Überdies ergeben sich Unterschiede in der Interpretation von mündlichen oder schriftlich niedergelegten, aber ungenauen, Anforderungen beim Kunden und beim Entwickler. Die vorhandene Software- und Hardwarearchitektur kann sich im Verlaufe der Entwicklung dann auch schon als falsch herausstellen. Dies verursacht weitere Kosten. Es werden Termine genannt, ohne dass der genaue Umfang des Entwicklungsprojektes genau bekannt ist. Die unweigerliche Folge davon sind Terminüberschreitungen. Schon einer der zuvor angeführten Punkte kann ein Softwareprojekt zum Scheitern bringen. Weitere Folgen sind: Anforderungen bleiben ungeklärt. Entwerfer und Programmierer haben keine Vorgaben. Die Basis für das Benutzerhandbuch fehlt. Tests können nicht vorbereitet werden. Die Grundlage für die Abnahme fehlt. Die Wiederverwendung bzw. Re-Implementierung wird erschwert. Das Pflichtenheft ist erforderlich für: Abstimmung mit den Stakeholders. Entwurf und Implementierug Benutzerhandbuch Testvorbereitungen Abnahme Wiederverwendung und Re-Implementierung

2 2 Aufgabe Das Pflichtenheft fasst alle fachlichen Anforderungen an das geplante System aus der Sicht des Auftragsgebers zusammen. Es dokumentiert die präzisen, vollständigen und überprüfbaren Anforderung an eine Software und ihre Schnittstellen. Deshalb erfordert die Erstellung eines Pflichtenheftes größtmögliche Genauigkeit und Detailtreue. Allerdings sollte das Pflichtenheft nicht beschreiben WIE die Software (das System) funktionieren soll, sondern WAS es leisten soll. Das WIE klärt die Organisationsbeschreibung bzw. Programmieranweisung. Das Pflichtenheft auch als Grundlage für juristische Verträge dienen. Die Form eines Pflichtenheftes sollte strukturiert sein. Bpw.: Einleitung Produkt-Anforderungen Nichtfunktionale Anforderungen Referenzen Ein Pflichtenheft sollte natürlichsprachlich abgefasst sein. Was das im Einzelnen bedeutet, wird später noch erläutert. 3 Aufbau 3.1 Einleitung Der Zweck und Ziel der Software sollte auf jeden Fall beschrieben werden. Es stellen sich die Fragen: Warum wird dieses Produkt gebraucht? Was soll damit erreicht werden? Des weiteren sollten die Benutzergruppen erwähnt werden. Wer nutzt diese Software und wie sieht das Nutzerprofil aus? Wenn die Software in eine bereits vorhandene Systemumgebung eingebunden werden soll, ist dieser Punkt sehr wichtig, damit es keine Probleme mit anderen Anwendungen des Systems oder Überschneidungen gibt. Wichtig sind Annahmen und vorhandenen Bedingungen für die zu entwickelnde Software. Treffen die aufgestellten Annahmen nicht zu oder fehlen die Bedingungen, dann kann die Software die für sie bestimmten Aufgaben nicht erfüllen. Damit zwischen dem Architekten des Pflichtenheftes und dem Kunden (Anwender) der Software keine Mißverständnisse in Bezug auf verwendete Formulierungen und Worte entstehen, sollte ein Glossar zur Erläuterung aller wichtigen Begriffe und Abkürzungen

3 verwendet werden. Es sollten für das Pflichtenheft nur Begriffe aus diesem Glossar verwendet werden. 3.2 Produkt-Anforderungen Für welchen Anwendungsbereich soll die Software geschrieben werden? Wie grenzt sich die Funktionalität der Software zu anderer Software ab? Gibt es Schnittstellen zu anderen Produkten? Zu welchen Produkten? Werden Daten entgegen genommen oder abgegeben? Welche Daten sind das? Welches sind die zentralen Funktionen aus Sicht der Nutzer, die das Produkt zur Verfügung stellen muss? Funktionen können nach Aspekten gruppiert werden. Welche Daten werden für die Software benötigt? Welche Daten müssen persistent (ständig) gespeichert werden? Welche Ausagen können zum Daten-Volumen getroffen werden? 3.3 Nichtfunktionale Anforderungen Anforderungen an die Benutzungsschnittstelle Wichtig ist die Frage nach der Bentzerschnittstelle. Unter anderem muss die Frage beantwortet werden, mit welchen Medien die Benutzerschnittstelle gestaltet werden soll. Meistens ergibt sich die Beantwortung zu dieser Frage aus der Verwendung des Entwicklungssystems, das ja meist ein solches Werkzeug enthält Anforderungen an die Handhabbarkeit Eine Anwendung ist nur so gut, wie ihre Bedienbarkeit. Dabei wird nicht danach gefragt, welche Technik verwendet werden soll. Sondern es stellen sich die Fragen: Wie sollen die Nutzer das System bedienen können? Welches Wissen (Training) ist dazu notwendig? Anforderungen an das Leistungsverhalten Welche Anforderungen werden an die Laufzeit und an das Antwortverhalten gestellt? Wie groß muss der Speicher bemessen sein? Anforderungen an die Wartbarkeit des Produkts Zu klären ist auch die voraussichtliche Einsatzdauer des Produkts. Möglicherweise muss auch danach gefragt werden, ob und wie das Produkt durch eine neue Version abgelöst wird. Desweiteren gehört zu den Anforderungen, wo das System erweiterbar sein muss.

4 3.3.5 Anforderungen an die Sicherheit Immer wichtiger sind die Fragen zum Thema Sicherheit. Wie, wann und an wen werden Daten übermittelt? Wer darf wann und wie auf Daten zugreifen? Anforderungen an die Entwicklungs-und Zielplattform Das zukünftige Umfeld der Anwendung und die Voraussetzungen für die Erstellung müssen geklärt werden: Unter welchem Betriebssystem kommt die Anwendung zum Einsatz? Welche Programmiersprache soll verwendet werden? Welche Datenbank soll verwendet werden? Ist die Anwendung Bestandteil eines Pakets (ERP,CRM)? Gibt es andere Anwendungen, in die sich das neue Produkt integrieren muss? Wie muss es sich integrieren? Sonstige Nichtfunktionale Anforderungen Wie soll die Inbetriebnahme erfolgen? Welchen System-Support soll es geben? Wie wird dieser Support geleistet? 4 Natürlichsprachliche Formulierung Die größten Fehler bei Erstellung eines Pflichtenheftes werden bei der Formulierung gemacht. Die Anforderungen in einem Pflichtenheft sollten Sie exakt formulieren. Worte, wie bspw. "möglicherweise", "kann", "in den meisten Fällen", usw. sollten Sie vermeiden. Die Spezifikation muss am besten natürlichsprachlich formuliert werden. Sie muss präzise, unmißverständlich und vollständig definiert werden. Es ist wichtig, dass die Anforderungen eindeutig verstanden werden und keinen Raum für Interpretationen lassen. Beispiele: Ursprüngliche Formulierung: "Die Untersuchung von FBI-Agenten kann gefährlich sein." Interpretation 1: "Es kann gefährlich sein, FBI-Agenten zu untersuchen." Interpretation 2: "Die Untersuchungen, die FBI-Agenten durchführen, können gefährlich sein." Ursprüngliche Formulierung: "Rudi nahm Ottos Buch weg."

5 Interpretation 1: "Rudi nahm Otto das Buch weg." Interpretation 2: "Rudi nahm das Buch weg, das Otto gehörte." Bei der Formulierung natürlichsprachlicher Anforderungen werden häufig folgende Transformationen durchgeführt, die dann zu sogenannten sprachlichen Defekten führen. Tilgung Es werden Aspekte vergessen. Wichtige Einzelheiten werden nicht erwähnt. Generalisierung Es werden allgemeingültige Aussagen formuliert, die aber nicht immer gelten. Fehler und Sonderfälle werden ncht erwähnt. Verzerrung Aspekte und Anforderungen werden verfälscht. Formulieren Sie qualifizierte und quantifizierte Anforderungen: Schlecht: "Das System soll auf einem handelsüblichen PC laufen." Besser: "Hardwarevoraussetzungen: mindestens 1 GB RAM, 200 MB HD " Formulieren Sie die Anforderungen im Aktiv. Schlecht: "Das Kennwort wird an einem Terminal eingegeben." Besser: "Der Benutzer gibt das Kennwort am Terminal ein." 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." Vermeiden Sie unvollständige 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." Spezifizieren Sie Vergleiche und Steigerungen immer vollständig. Schlecht: Die Berechtigungen sollen leicht erkennbar sein. Besser: Die Berechtigungen sollen durch den Administrator in einer eigenen Maske geändert werden können. Dieser Vorgang darf nicht mehr als eine Minute dauern." Prüfen Sie absolute Formulierungen wie "nie", "immer", "jeder", "alle", "irgendeiner", "nichts".

6 Gilt die Anforderung wirklich so für alle Objekte? Gibt es Ausnahmen? Schlechte Formulierung: Das System soll eine durch den Benutzer eingeleitete Sicherung von aufgezeichneten Daten auf Band ermöglichen. Dadurch werden u.a. folgende Fragen aufgeworfen: Darf jeder Benutzer die Sicherung einleiten? Alle aufgezeichneten Daten? Immer? 5 Quelle Prof. Horst Lichter, RWTH Aachen: Foliensatz "Dokumentationen von Anforderungen" Kai-Ulrik Bräutigam, Emsstr. 13a, Greven, info@kb-itberatung.de, IT-Beratung Bräutigam