Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 6/2004.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Das optimale Pflichtenheft

Christoph Spielmann, Düsseldorf

Für den Erfolg eines Software-Projekts spielt das Pflichtenheft eine zentrale Rolle. Dieser Beitrag zeigt Ihnen, wie Sie ein Pflichtenheft erstellen und was alles darin enthalten sein sollte - natürlich nicht, ohne das vorherige Lastenheft und die anschließenden Schritte zu erwähnen.

Von der ersten Idee ...

Wer schon einmal eine Software im Auftrag eines Kunden erstellt hat, wird von den daraus resultierenden Problemen - sei es nun finanzieller oder zeitlicher Natur -, sicherlich ein Lied singen können. Dies endet dann häufig in dem Wunsch, beim nächsten Projekt eine "vernünftige" Planung durchzuführen.

Zu Beginn dieser Planung steht in der Regel die Idee, eine bestimmte Aufgabe in Zukunft von einem Computer qualitativ hochwertiger, schneller oder kostengünstiger lösen zu lassen. Häufig stammen diese Ideen von Personen, die kein oder nur sehr wenig Fachwissen im Bereich der EDV besitzen. Die Aufgabe des Projektleiters ist es nun, diese Ideen möglichst optimal in ein Computer-Programm umzusetzen, sodass der ursprüngliche Zweck auch wirklich erfüllt wird.

Der erste Schritt bei der Planung einer Software ist die Erstellung eines so genannten "Lastenheftes". Das Lastenheft ist ein Dokument, in dem die Anforderungen an die Software grob beschrieben werden. Das Augenmerk liegt hier speziell auf den Anforderungen, also noch nicht darauf, was sich mit dem Computer in welcher Zeit und mit welchen Kosten umsetzten lässt. Es ist also eine Spielwiese für Ideen-Geber. Technische Aspekte bleiben hier zunächst unberücksichtigt.

Auf der Basis des Lastenheftes können sich Entscheider sowie Entwickler der Software zunächst einen groben Überblick verschaffen. So können beispielsweise die Software-Entwickler eine grobe Schätzung des zu erwartenden Programmieraufwands abgeben. Auf dieser Basis können dann die Entscheider den Nutzen abwägen und das Projekt entweder verwerfen oder in die zweite Phase - die Pflichtenheftphase - eintreten.

... zum Pflichtenheft

Ziel des Pflichtenheftes ist es, die Wünsche und Anforderungen der Kunden mit den technischen Aspekten unter einen Hut zu bringen. Hierbei ist es erforderlich, dass sich die am Pflichtenheft beteiligten Kunden in die technischen Aspekte und umgekehrt die Programmierer in die fachlichen Belange einarbeiten. Nur so kann erreicht werden, dass beide Seiten die "gleiche Sprache sprechen" und Missverständnisse möglichst vermieden werden.

Weiterhin ist es sehr wichtig, dass alle Aspekte ausführlich und schriftlich festgehalten werden. Alle Beteiligten sollten nach der Fertigstellung des Pflichtenheftes durch ihre Unterschrift bestätigen, dass die aufgeführten Punkte korrekt und vollständig sind.

Zu guter Letzt sollte das Pflichtenheft einer Auswahl der späteren Benutzer vorgelegt werden, sodass diese eine Endabnahme durchführen können.

Der Aufbau eines
Pflichtenheftes

Ein Pflichtenheft besteht aus mehreren Abschnitten, die im Folgenden beschrieben sind.

Deckblatt und Inhaltsverzeichnis

Das Pflichtenheft beginnt in der Regel mit einem Deckblatt, auf dem der Arbeitstitel des Projekts festgehalten ist. Besonders wichtig ist hierbei die Versionsangabe. Bei jeder Änderung im Pflichtenheft sollte diese erhöht werden. Weiterhin bietet es sich an, die einzelnen Änderungen in Tabellenform grob festzuhalten. Diese Maßnahmen sind wichtig, da an einem Pflichtenheft in der Regel mehrere Personen beteiligt sind. Daran sollte sich ein Inhaltsverzeichnis anschließen.

Die Projektübersicht

Die Projektübersicht beginnt mit einer kurzen Beschreibung des Projekts in verbaler Form. Wichtige Elemente sind hierbei die Gründe dafür, warum das Projekt angestoßen wurde, sowie die Zielsetzung des Projekts.

Im Anschluss daran folgen eine Beschreibung des Pflichtenheft-Aufbaus sowie eine Auflistung der an der Erstellung des Pflichtenheftes beteiligten Personen. Zu jeder einzelnen Person sollte hier ein Unterschriftenbereich vorgesehen werden. Nach der Fertigstellung des Pflichtenheftes sollte hier jede Person unterschreiben, was in der Regel alle Beteiligten dazu zwingt, das komplette Pflichtenheft noch einmal gründlich durchzulesen und zu prüfen.

In einigen Fällen ist ein Glossar sinnvoll, das die verwendeten Fachbegriffe erläutert. Dies soll Dritten die Einarbeitung in das Pflichtenheft erleichtern. Das Glossar enthält alle Fachbegriffe in tabellarischer Form mit jeweils einer kurzen und prägnanten Beschreibung.

Rahmenbedingungen der
Vernetzung

Die Rahmenbedingungen beschreiben das Umfeld, in dem die Software eingesetzt werden soll. Eine wichtige Rolle spielt hier die Vernetzung der einzelnen Benutzer der Software. Ein Szenario ist beispielsweise, dass alle Benutzer innerhalb eines Gebäudes in einem lokalen Netzwerk arbeiten, also untereinander und mit einem eventuell vorhandenen Server über eine schnelle Datenverbindung kommunizieren können. Festzuhalten ist hierbei in jedem Fall die Geschwindigkeit des Netzwerks sowie die sonstige Nutzung des Netzwerks durch andere Anwendungen. Das Ergebnis ist letztlich eine Einschätzung darüber, welche Bandbreite der zu entwickelnden Anwendung zur Verfügung steht.

Besondere Aufmerksamkeit ist immer dann erforderlich, wenn die Benutzer an unterschiedlichen Standorten über eine langsame Leitung kommunizieren. Dies beeinflusst in der Regel das komplette Design der Anwendung, da diese nun eventuell nicht mehr auf viel Komfort, sondern auf eine möglichst effiziente Ausnutzung der Datenleitung ausgelegt werden muss. Gegebenenfalls muss auch der Wille des Nutzers schriftlich fixiert werden, die vorhandenen Leitungskapazitäten den Anforderungen der Software anzupassen, was in der Regel aber mit zusätzlichen Kosten verbunden ist.

Wenn der Benutzer "offline" arbeiten möchte, also die Software trotz fehlender Netzwerk-Verbindung nutzen möchte, muss hier ggf. ein geeignetes Konzept zum Datenaustausch gefunden werden. Wenn sich der Benutzer z.B. regelmäßig per Modem in die Firmenzentrale einwählt, um aktuelle Daten auszutauschen, entstehen hierbei zusätzliche Kosten.

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

Softwareprojekte verwalten

© 2003-2015 André Minhorst Alle Rechte vorbehalten.