Ein Benutzerhandbuch als Systemspezifikation halber Aufwand bei doppeltem Nutzen?

Transkript

1 Ein Benutzerhandbuch als Systemspezifikation halber Aufwand bei doppeltem Nutzen? Autor: Chris Rupp Keywords: Requirements Engineering Gesamtseitenzahl: 7 Gesamtwortzahl: 1631 Erschienen in: pmi austria SOPHIST GmbH General Manager: Christine Rupp, Dipl. Information Technology (FH) Roland Ehrlinger Vordere Cramergasse Nürnberg Deutschland fon: +49 (0) fax: +49 (0) heureka@sophist.de Internet: Copyright 2009 by SOPHIST GmbH Publikation urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckens und der Vervielfältigung oder Teilen daraus, vorbehalten. Kein Teil der Publikation darf in irgendeiner Form, egal welches Verfahren, reproduziert oder unter Verwendung elektronischer Systeme verarbeitet werden, vervielfältigt oder verbreitet werden. Dies gilt auch für Zwecke der Unterrichtsgestaltung. Eine schriftliche Genehmigung ist einzuholen. Die Rechte Dritter bleiben unberührt.

2 Abstract In Zeiten von immer kürzeren Innovationszyklen und immer knapperen Projektbudgets wird der Zeitund Kostenrahmen für eine vollständige Systemspezifikation häufig gekürzt, da es sehr aufwendig und kostenintensiv ist, sie zu erstellen. Verantwortliche und Durchführende sind immer weniger vom Overhead einer zusätzlichen, aufwendig zu wartenden Spezifikation zu überzeugen, auch wenn die QS weiterhin auf professionell organisierten Anforderungen besteht. Um dennoch das Risiko von unzufriedenen weil unverstandenen Kunden zu vermeiden, müssen effektive Methoden zur Systemanalyse gefunden werden, die eine erfolgreiche Systementwicklung bei knappem Budget ermöglichen. Als Lösung schlagen wir vor, das Benutzerhandbuch in der Systemanalyse anstatt einer reinen Systemspezifikation zu verwenden. Bei diesem Vorgehen kann enormer Aufwand gespart und gleichzeitig die Qualität der Analyseergebnisse verbessert werden. Doppelter Aufwand Ein Benutzerhandbuch ähnelt an vielen Stellen sehr stark einer klassischen Systemspezifikation. Beide beschreiben aus der Anwender-Sicht, wie sich das System verhält, ohne Realisierungsdetails zu nennen. Gibt es eine Möglichkeit, diese redundanten Anteile zusammenzufassen? Jedes der beiden Artefakte kann bei schlechter Qualität ein Projekt zum Scheitern bringen. Eine ausreichend gute Systemspezifikation ist eine Voraussetzung für ein erfolgreiches Projekt, wie im CHAOS- Report der Standish-Group in [CHAOS] dokumentiert wurde. Erst ein qualitativ hochwertiges Benutzerhandbuch macht ein Produkt im realen Einsatz erfolgreich, da es dem Benutzer ermöglicht, das System zu benutzen. Beide Artefakte müssen also erstellt und der entsprechende Aufwand eingeplant werden. Unsere Idee ist es, beide Artefakte zu einer Handbuch-Spezifikation zu vereinen und die Chance auf eine gute Systemspezifikation und ein gutes Handbuch zu steigern, bei gleichzeitig gesenkten Kosten. Wir werden zunächst einige Voraussetzungen untersuchen, um die beiden Artefakte zusammenzufassen. Anschließend geben wir einige Hinweise auf ein effektives Vorgehen und eine sonnvolle Organisation der Handbuch-Spezifikation. Im Folgenden benutzen wir den Begriff (Benutzer-) Handbuch stellvertretend für weitere ähnliche Artefakte, wie das Online-Handbuch, ein Hilfesystem oder Internet-Tutorials. Sie lassen sich austauschen oder mit ein wenig Mehr-Aufwand aus den beschriebenen Handbuch-Forderungen generieren. Vergleich der Artefakte Um die beiden Artefakte zusammenfassen zu können, müssen wir untersuchen, wo sie sich überlappen. Die Qualitätskriterien der Artefakte dürfen sich nicht widersprechen und die Zielgruppen müssen eine Handbuch-Spezifikation akzeptieren. Seite 2 von 8

3 Inhalte einer Handbuch-Spezifikation Wir unterscheiden im Folgenden die drei Begriffe Handbuch-Forderung, reine Handbuch-Beschreibung und reine Anforderung, wie in Abb. 1 dargestellt. Systemspezifikation Benutzerhandbuch Reine Anforderungen Handbuch-Forderungen Reine Handbuch- Beschreibungen Abb. 1: Arten von Informationen Handbuch-Spezifikation Handbuch-Forderungen sind Informationen, die für das Handbuch und die Spezifikation relevant sind. Sie umfassen im Wesentlichen alle funktionalen Anforderungen und bilden damit das Herzstück der Handbuch-Spezifikation. Um eine Packliste Werbemittel zu erstellen, haben Sie die Möglichkeit folgende Informationen einzugeben: - Verantwortlicher - Werbeplan* - Notizen* *In diesen Feldern können auch Grafiken, Worddokumente oder andere Dateiformate (wie z. B. filename.zip) abgelegt werden. Beispiel 1: Handbuch-Forderung Reine Handbuch-Beschreibungen sind Texte, die nur für das Handbuch relevant sind, wie z. B. Installationsanweisungen oder ein Kapitel Erste Schritte. Schließen Sie vor der Installation alle offenen Anwendungen, um eventuelle Konflikte zu vermeiden. Beispiel 2: Reine Handbuch-Beschreibung Reine Anforderungen werden nur in der Spezifikation benötigt. Beispiele sind technische Anforderungen und das Verhalten in (seltenen) Fehlerfällen. Das System soll fähig sein, die bestehenden Ressourcenobjekte aus dem Ressourcenverwaltungssystem über die Schnittstelle xy zu empfangen. Beispiel 3: Reine Anforderung Seite 3 von 8

4 Qualitätskriterien Eine hochwertige Systemspezifikation erfüllt alle Qualitätskriterien, die ein exzellentes Benutzerhandbuch erfüllen muss. Damit ist eine weitere Voraussetzung für die Kombination erfüllt. Im einzelnen muss eine Handbuch-Spezifikation die folgenden Qualitätskriterien erfüllen: > Vollständigkeit (alle nach außen wahrnehmbaren Aktionen des Systems sind beschrieben) > Verstehbarkeit, Übersichtlichkeit > Korrektheit > Eindeutigkeit und Konsistenz > Modifizier- und Erweiterbarkeit > Traceability > Testbarkeit > Realisierbarkeit Die Kriterien Testbarkeit und Realisierbarkeit sind dabei nur für eine Systemspezifikation relevant. Für das kombinierte Artefakt müssen jedoch die strengeren Kriterien gelten. Weiterhin muss beachtet werden, dass die Kriterien Verstehbarkeit und Übersichtlichkeit unterschiedlich definiert sind. Sie richten sich bei den Artefakten nach unterschiedlichen Zielgruppen. Zielgruppen der Artefakte Eine Systemspezifikation wird von an der Entwicklung beteiligten Personen gelesen, die ein grundlegendes technisches Verständnis besitzen und für Ihre Arbeit eine präzise Beschreibung benötigen. Ein Benutzerhandbuch wird dagegen von Menschen gelesen, die das System als reines Werkzeug betrachten und sich nicht tiefer für die technischen Hintergründe interessieren. Für sie ist vor allem Verstehbarkeit und Übersichtlichkeit wichtig. Um beiden Zielgruppen gerecht zu werden, muss eine Handbuch-Spezifikation die Präzision der Systemspezifikation mit der Übersichtlichkeit und Einfachheit des Benutzerhandbuchs kombinieren. Wie dies möglich ist werden wir im Abschnitt Umsetzung vorstellen. Vorgehen bei der Systemanalyse Bei der Systemanalyse müssen die Besonderheiten beim Einsatz einer Handbuch-Spezifikation berücksichtigt werden. Ermitteln Beim Ermitteln der Anforderungen werden alle Wünsche und Vorstellungen der Stakeholder vollständig gesammelt. Die dabei eingesetzten Methoden sind unabhängig von der Form der Dokumentation der Ergebnisse. In [Rupp02] werden eine Reihe von für unterschiedliche Projekt-Randbedingungen geeignete Techniken vorgestellt, die es ermöglichen, effektiv Wissen zu gewinnen. Nach unserer Erfahrung in Forschungs- und Industrieprojekten fällt es sehr leicht, die für Anforderungen richtige Sicht einzunehmen, wenn eine Handbuch-Spezifikation verwendet wird. Jeder Stakeholder hat eine intuitive Vorstellung, welche Informationen ein Handbuch enthält. Das System muss aus Benutzersicht beschrieben werden und darf keine Lösungsdetails enthalten. Seite 4 von 8

5 Dokumentieren Beim Dokumentieren werde die ermittelten Anforderungen an das System für alle Projektbeteiligten verständlich beschrieben. Eine Handbuch-Spezifikation wird in verständlicher Sprache übersichtlich dokumentiert, ohne (semi-)formale Sprachen wie die UML zu verwenden. Das Ziel des Benutzerhandbuchs, verständlich und übersichtlich das Systemverhalten zu erklären, bringt nach unserer Erfahrung Vorteile für die Funktion als Systemspezifikation. Die Leser der Anforderungen akzeptieren das Dokument wesentlich besser als herkömmliche Anforderungen. Verwalten Handbuch-Forderungen sollten durch Tool verwaltet werden. Es kann per Knopfdruck aus einer Handbuch-Spezifikation die beiden wichtigen Artefakte ausgeben, Handbuch oder Systemspezifikation. Das Tool sollte dann die parallele Arbeit unterschiedlicher Personen in den Rollen Analytiker und Handbuch-Schreiber unterstützen. Es muss Change Requests verwalten, Workflows unterstützen, sowie ein Rechte- und Rollensystem umsetzen. Einzelne Handbuch-Forderungen müssen mit Attributen ergänzt werden können. Prüfen Die Anforderungen werden nach dem Dokumentieren mithilfe geeigneter Techniken darauf geprüft, ob sie die Qualitätskriterien erfüllen. Solche Techniken sind z. B. das SOPHIST-REgelwerk (siehe [Rupp02]) oder Reviews (siehe [Wall90]). Da die Stakeholder die Handbuch-Forderungen leicht verstehen, finden sie falsche Aussagen leichter und finden vergleichsweise viele Fehler. Durch die gute Akzeptanz sind die Stakeholder eher als bei klassischen Anforderungen bereit, sich mit den Handbuch-Forderungen auseinanderzusetzen und sie zu prüfen. Umsetzung Werden Anforderungen in einer Handbuch-Spezifikation dokumentiert, müssen bei der Systemanalyse einige Feinheiten berücksichtigt werden. Rollen Durch die Kombination der Artefakte Systemspezifikation und Benutzerhandbuch müssen die beiden Rollen Systemanalytiker und Handbuch-Schreiber sehr eng zusammenarbeiten. Es ist weiterhin sinnvoll, beide Rollen durch zwei verschiedene Personen zu besetzen, sodass beide ihre Stärken beitragen können. Der Handbuch-Schreiber achtet auf Verständlichkeit und Lesbarkeit der Handbuch-Forderungen, während sie der Systemanalytiker präzise und eindeutig macht. Nach unserer Erfahrung ist diese Zusammenarbeit sehr fruchtbar. Wir konnten eine gesteigerte Effektivität sowohl bei der Anforderungsanalyse, als auch beim Schreiben des Handbuchs feststellen, bei gleichzeitig verbesserter Qualität. Zustandsmodell Seite 5 von 8

6 Abb. 2: Vereinfachtes Zustandsmodell Der Fortschritt der Systemanalyse wird mithilfe des Zustands jeder einzelnen Handbuch-Forderung, Handbuch-Beschreibung und reinen Anforderung protokolliert. Dabei muss berücksichtigt werden, dass diese von verschiedenen Personen in unterschiedlichen Entwicklungsphasen bearbeitet werden. In Abb. 2 ist ein vereinfachtes Zustandsmodell dargestellt. Um eine Packliste Werbemittel zu erstellen, haben Sie die Möglichkeit folgende Informationen einzugeben: - Verantwortlicher - Werbeplan* - Notizen* Drücken Sie dazu im Reiter Packlisten den Button PL Werbemittel erstellen. Es wird ein neues Dokument geöffnet, in dem Ihnen im Dokumentkopf die Felder zur Verfügung stehen. *In diesen Feldern können auch Grafiken, Worddokumente oder andere Dateiformate (wie z. B. filename.zip) abgelegt werden. Beispiel 1: Handbuch-Forderung, Status Manual Signed Im ersten Schritt dokumentiert der Analytiker essenzielle, lösungsneutrale Anforderungen, die der Handbuch-Schreiber anschließend umformuliert und um Beschreibungen der Benutzeroberfläche ergänzt, mit dem Ziel eines vergnüglich zu lesenden Handbuchs. Schreiben von Handbuch-Forderungen Beim Schreiben der Handbuch-Forderung sollte der Analytiker berücksichtigen, dass sie später in ein Handbuch überführt werden. Formuliert er sie geschickt, kann den Aufwand reduziert werden, das Handbuch zu erstellen, ohne die Präzision zu verlieren. In [Cock03] sind einige Formulierungs-Regeln im Kontext der Use-Case-Analyse beschrieben, die sich hier ebenfalls anwenden lassen. Struktur der Handbuch-Spezifikation Handbuch-Forderungen müssen so strukturiert werden, dass sie sowohl im Handbuch, als auch in der Spezifikation verwendet werden können. In unseren Projekten hat sich eine Use-Case-Struktur bewährt, welche die Anforderungen anhand typischer Benutzerinteraktionen strukturiert (siehe [Cock03]). Anhand seines aktuellen Ziels findet der Anwender schnell die Stelle im Handbuch, an der die Funktionalität beschrieben ist, zu der er eine Erläuterung sucht. Die reinen Anforderungen sollten zusätzlich anhand eines Standards gegliedert werden, z. B. IEEE in [IEEE830] oder Volere in [Robe99]. Seite 6 von 8

7 Diskussion In Forschungs- und Industrieprojekten haben wir folgende wesentliche Vorteile eines Benutzerhandbuchs als Systemspezifikation festgestellt. Dan Berry belegt in [Berr03] einige der Vorteile an weiteren Fallstudien. > Qualität der Artefakte steigt wesentlich durch enge Zusammenarbeit zwischen Analytiker und Handbuch-Schreiber > Große Aufwands- und Kostenersparnis durch wenig doppelte Arbeit und gesteigerte Effektivität > Hohe Akzeptanz bei Anwendern und Entwicklern durch gute Verstehbarkeit und Übersichtlichkeit Wichtige Nachteile: > Nicht jedes System ist geeignet (z. B. komplexe Algorithmen, keine Benutzeroberfläche) > Nicht für jede Detaillierungsebene geeignet (Projektziele oder Komponenten-Anforderungen haben kein Pendant im Benutzerhandbuch) Einen großen Vorteil des beschriebenen Vorgehens sehen wir außerdem bei einer Systementwicklung, die ein bestehendes Altsystem weiterentwickelt oder ablöst, da hier das aktuellste Dokument in vielen Fällen das Benutzerhandbuch ist. Literatur [Berr03] [CHAOS] Berry, D.M. et al.: User s Manual as a Requirements Specification: Case Studies. University of Waterloo, Canada, 2003 The Standish Group: The CHAOS Report, [Cock03] Cockburn, A.: Use Cases effektiv erstellen, Addison-Wesley, 2003 [IEEE830] [Robe99] [Rupp02] IEEE-Standard : IEEE Recommended Practice for Software Requirements Specifications. Approved June 25, IEEE-SA Standards Board print Robertson, S., Robertson, J.: Mastering the Requirements Process. Reading/MA, Addison Wesley 1999 Rupp, C.; SOPHIST GROUP: Requirements-Engineering und -Management, Hanser Verlag [Wall90] Ernest Wallmüller, Software-Qualitätssicherung, Hanser Verlag, Autor: Seite 7 von 8

8 Chris Rupp liefert durch Ihre Publikatio- nen und Vorträgen immer wieder wichtige Impulse für die Bereiche Requirements Engineering und Objektorientierung. Erfindungen von Ihr und den SOPHISTen legten die Basis des modernen Requirements Engineering. Chris ist Geschäftsführerin der SOPHIST GmbH. Seite 8 von 8