<\/p>\n
Christoph Spielmann, Düsseldorf<\/b><\/p>\n
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. <\/b><\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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. <\/p>\n
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.<\/p>\n
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.<\/p>\n
Zu guter Letzt sollte das Pflichtenheft einer Auswahl der späteren Benutzer vorgelegt werden, sodass diese eine Endabnahme durchführen können.<\/p>\n
Ein Pflichtenheft besteht aus mehreren Abschnitten, die im Folgenden beschrieben sind.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Darüber hinaus ist der Einsatz von Access über eine langsame Leitung wie zum Beispiel ISDN nur mit sehr schlechter Performance möglich, sodass eventuell andere Entwicklungswerkzeuge eingesetzt werden müssen, mit denen die Entwicklung aufwändiger ist.<\/p>\n
<\/p>\n
Eine nicht weniger wichtige Rolle spielt die verfügbare Hardware-Plattform. In der Regel hat der Kunde den Anspruch, dass die neue Software mit der bereits vorhandenen Hardware funktioniert – also keine Neuanschaffungen erforderlich sind.<\/p>\n
Wichtig ist hierbei, die minimalen Hardware-Anforderungen an das System zu definieren und zu prüfen, ob diese Anforderungen von allen PCs erfüllt werden. In der Praxis stellt es hierbei kein Problem dar, wenn letztlich doch ein geringer Anteil an PCs ausgetauscht werden muss.<\/p>\n
Soll der Kunde generell langsame PCs einsetzen, muss im Rahmen der Software-Architektur eine Verlagerung von Bearbeitungsvorgängen auf den Server angestrebt werden.<\/p>\n
Dies entlastet die PCs der Benutzer. Den Extremfall stellt hierbei eine Web-Anwendung dar, bei der fast alle Vorgänge im Server ausgeführt werden können. Als Client wird hierbei nur ein Web-Browser vorausgesetzt.<\/p>\n
Die Anforderungen an die Hardware sollten in den zwei Blöcken „Minimum“ und „Empfohlen“, jeweils getrennt für die Client-PCs sowie den gegebenenfalls erforderlichen Server aufgeführt werden. Eine wichtige Rolle spielt hierbei die verfügbare Festplatten-Kapazität, die Hauptspeichergröße sowie der Prozessortyp und -takt.<\/p>\n
Auch die Bildschirmauflösung muss festgehalten werden, damit die Formulare der späteren Anwendung komplett sichtbar sind und nicht abgeschnitten werden.<\/p>\n
Das Betriebssystem bestimmt maßgeblich, welche Werkzeuge zur Entwicklung der Software in Frage kommen. So ist es beispielsweise nicht möglich, eine mit .NET entwickelte Software unter Windows 3.1 oder einem Apple-Betriebssystem laufen zu lassen.<\/p>\n
Auch Windows 95 ist inzwischen schon zehn Jahre alt und hat einige gravierende Einschränkungen. So ist beispielsweise der Einsatz des Thread-Pools von .NET unter Windows 95 nicht möglich.<\/p>\n
Als ideale Entwicklungs-Plattform für Arbeitsplatz-PCs ist momentan Windows 2000 oder Windows XP anzustreben. Beim Server sollte Windows 2000 Server oder Windows 2003 Server zum Einsatz kommen. Windows NT 4.0 erfordert ähnlich wie Windows 95 zu viele Einschränkungen und sollte daher vermieden werden.<\/p>\n
Falls der Kunde unterschiedliche Betriebssysteme unterschiedlicher Hersteller einsetzt (zum Beispiel Windows, Linux, Apple, Sun, ….), bleibt als kleinster gemeinsamer Nenner häufig nur ein Web-Browser übrig. In diesem Fall muss darauf geachtet werden, dass alle eingesetzten Versionen dokumentiert werden, damit die spätere Anwendung daran angepasst werden kann.<\/p>\n
Das Mengengerüst beschreibt, wie viele Daten von wie vielen Benutzern in welcher Zeit verarbeitet werden müssen.<\/p>\n
Wenn beispielsweise 20 Benutzer je einmal pro Stunde eine Suche über 100.000 Adressen durchführen, dürfte ein leistungsschwacher Server ausreichend sein. Wenn dagegen jeder Benutzer einmal alle 10 Sekunden eine Suche durchführt, sollte ein leistungsfähiger Server zum Einsatz kommen.<\/p>\n
Weiterhin ist es wichtig, die Entwicklung der Datenmenge über die nächsten fünf Jahre zu betrachten.<\/p>\n
Wenn jährlich 300.000 Adressen hinzukommen und der Server auch in fünf Jahren noch eine akzeptable Performance aufweisen soll, müssen entsprechende Reserven eingeplant werden. Auch die Anzahl der Benutzer sollte mindestens über die kommenden fünf Jahre hinweg abgeschätzt werden.<\/p>\n
Bei größeren Software-Projekten besteht häufig die Anforderung, dass die Benutzeroberfläche in unterschiedlichen Sprachen erscheinen soll.<\/p>\n
Im Pflichtenheft sollten alle zu unterstützenden Sprachen festgehalten werden.<\/p>\n
Weiterhin sollte festgehalten werden, wie und von wem die übersetzung erfolgt. In der Regel ist es unbedingt erforderlich, dass der übersetzer einerseits über die entsprechenden sprachlichen Fähigkeiten verfügt und andererseits die fachlichen Hintergründe versteht.<\/p>\n
Auch das Format für die Ein- und Ausgabe von Dezimalbruchzahlen und Datumswerten muss festgelegt werden. So verwenden beispielsweise die USA den Punkt als Dezimaltrennzeichen. Es sollte insbesondere auch das Verhalten der Software geklärt werden, wenn zum Beispiel eine deutsche Spracheinstellung auf einem amerikanischen Betriebssystem gewählt wird.<\/p>\n
Sollte die Software mit Währungsbeträgen arbeiten, muss hier gegebenenfalls für eine Umrechnung anhand tagesaktueller Wechselkurse gesorgt werden.<\/p>\n
Insbesondere durch die Office-Anwendungen prägt Microsoft das moderne Erscheinungsbild von Windows-Anwendungen. Daher haben Benutzer häufig den Wunsch, dass die neu zu entwickelnde Anwendung ebenfalls ein Office Look&Feel hat. Dies ist insbesondere im Hinblick auf eine einfache Einarbeitung sinnvoll.<\/p>\n
Zu den Standard-Merkmalen gehört eine Menüzeile mit Symbolleiste. Ein weiteres Merkmal ist, dass mehrere Fenster gleichzeitig geöffnet werden können und so ein paralleles Arbeiten an mehreren Dokumenten möglich ist. Auch ein Rückgängigmachen der letzten Operation ist ein typisches Office-Merkmal.<\/p>\n
Im Einzelfall muss entschieden werden, welche dieser Funktionen sinnvoll und mit vertretbarem Aufwand umzusetzen ist. Besonders das Rückgängigmachen der letzten Operation ist bei Datenbankanwendungen im Mehrbenutzerbetrieb eine fast unlösbare Aufgabe. <\/p>\n
Das Pflichtenheft sollte daher nicht die pauschale Aussage „Nach dem Microsoft-Office-Vorbild“ enthalten, sondern alle gewünschten Funktionen einzeln aufführen.<\/p>\n
Die funktionale Beschreibung sollte die einzelnen Module der Software in Form von verbalen Texten beschreiben. Die Beschreibungen sollten, sofern sinnvoll, durch Entwürfe von Bildschirmmasken ergänzt werden. Wenn das Pflichtenheft nach Fertigstellung den Benutzern vorgelegt wird, können diese sich anhand der Abbildungen einen besseren Eindruck von der späteren Software machen. In einigen Fällen ist es hier auch sinnvoll, zunächst einen Prototyp zu erstellen, diesen dann von den späteren Benutzern prüfen zu lassen und das Ergebnis im Pflichtenheft zu dokumentieren.<\/p>\n
Bei der Beschreibung der einzelnen Bildschirmmasken sollte für jedes Feld die Art des Werts (Text, Zahl, Datum…) sowie die zu prüfenden Gültigkeitsregeln abgelegt werden. So darf beispielsweise eine neue Rechnung nicht mit einem Datum angelegt werden, das in der Vergangenheit liegt. Ein gutes Pflichtenheft hat den Anspruch, alle diese Regeln vollständig aufzuführen.<\/p>\n
Komplexe Abläufe sollen mit Hilfe von Grafiken visualisiert werden. Hierbei ist darauf zu achten, dass das Pflichtenheft nicht zu weit in die Technik abgleitet. Die technische Realisierung wird erst in einem späteren technischen Konzept geplant, an dem primär Programmierer und System-Architekten beteiligt sind.<\/p>\n
Auswertungen eignen sich gut dazu, das komplette Konzept der Software bezüglich der vorgehaltenen Daten zu prüfen. Hierbei gilt: Daten, die nicht erfasst sind, können auch nicht ausgewertet werden.<\/p>\n
Die gewünschten Auswertungen sollten daher mit ebenso großer Sorgfältigkeit geplant werden, wie die übrigen Module der Software. In der Praxis bietet es sich an, Prototypen der Berichte mit Hilfe von Word oder Excel zu erstellen und diese dann im Pflichtenheft zu dokumentieren.<\/p>\n
Nach der Beschreibung aller Funktionen muss noch festgelegt werden, welche Benutzer welche Funktionen überhaupt ausführen dürfen. In der Praxis kommen hier oft mindestens zwei Benutzergruppen vor: Normale Anwender und Administratoren. Zu jeder Benutzergruppe sollte im Pflichtenheft genau beschrieben werden, welche Funktionen in welcher Weise genutzt werden können. Beispielsweise darf der Administrator eine Liste mit Stammdaten bearbeiten, der normale Anwender hat aber nur lesenden Zugriff. Die Benutzerliste darf dagegen eventuell von normalen Benutzern nicht einmal im „Nur-Lesezugriff“ geöffnet werden, da sie gegebenenfalls vertraulich ist.<\/p>\n
Bei Anwendungen mit Datenbank-Fokus bietet es sich an, direkt ein ER-Diagramm mit in das Pflichtenheft aufzunehmen. Obwohl es sich hierbei um eine technische Betrachtung der Datenstruktur handelt, trägt es in der Praxis oft zur Vermeidung von Missverständnissen bei.<\/p>\n
Das ER-Diagramm zwingt die Pflichtenheft-Ersteller dazu, alle Felder genau aufzuführen und die Beziehungen zwischen den Daten zu definieren. So kann schnell festgestellt werden, welche Daten noch fehlen oder sogar überflüssig sind.<\/p>\n
Sobald das Pflichtenheft fertig gestellt ist, sollten – wie bereits angesprochen – alle Beteiligten sowie einige Benutzer durch ihre Unterschrift bestätigen, dass alle Angaben korrekt und vollständig sind.<\/p>\n
Anschließend kann in der Regel ein grober Kostenrahmen zur Entwicklung der Software geschätzt werden. Sollte dieser das vorhandene Budget sprengen, werden die einzelnen Punkte des Pflichtenhefts im Regelfall noch einmal nach Wichtigkeit geordnet (zum Beispiel „must have“ und „nice to have“).<\/p>\n
So können eventuell nicht so wichtige Funktionen, die jedoch einen hohen Entwicklungsaufwand haben, auf eine spätere Version verschoben oder völlig gestrichen werden. Das Pflichtenheft liegt anschließend in der endgültigen Version vor, sodass die Entwicklung beginnen kann.<\/p>\n
Diese startet in der Regel mit der Erstellung eines Feinkonzepts, das die Architektur der Software sowie das genaue Format der Daten festhält. Die Architektur bestimmt beispielsweise, wie das Projekt modularisiert werden kann, sodass änderungen an einem Modul nur wenig negative Auswirkungen auf andere Module haben.<\/p>\n
Außerdem spielt die Skalierbarkeit eine wichtige Rolle. Die Anwendung sollte durch den Einsatz zusätzlicher Hardware in der Leistung gesteigert werden können, ohne dass hierfür eine Umprogrammierung der Software erfolgen muss.<\/p>\n
Häufig ist dieses Feinkonzept auch Basis für die Aufteilung des Projekts auf mehrere Entwickler, da sich erst hier eine sinnvolle Aufteilung erkennen lässt.<\/p>\n
Während der Erstellung des Feinkonzepts tauchen in der Praxis immer wieder Punkte auf, die zur Anpassung des Pflichtenheftes führen. <\/p>\n
Der Grund dafür kann zum Beispiel ein sein, dass entweder überhaupt nicht zu lösen ist oder zu höheren Kosten beziehungsweise größerem Zeitaufwand führt.<\/p>\n
Solche Anpassungen sollten mit allen Pflichtenheft-Beteiligten abgesprochen werden, um einen geeigneten Lösungsweg zu finden. Nur so ist sichergestellt, dass das Ziel der Software im Sinne der Auftraggeber erreicht wird.<\/p>\n
Ein gutes Pflichtenheft ist in der Regel eine Garantie dafür, dass die Software später ein Erfolg wird. In der Praxis ist es häufig so, dass für jede Stunde, die vorher in das Pflichtenheft investiert wird, später zehn Stunden Zeit eingespart werden.<\/p>\n
Dennoch ist es in der Praxis häufig so, dass einige Aspekte bei der Planung nicht berücksichtigt wurden. Daher sollte immer ein entsprechender Zeit- und Geld-Puffer in die Planung mit aufgenommen werden. <\/p>\n
Sollte dann doch einmal eine ungeplante änderung auftreten, muss der Projektplan nicht völlig überarbeitet werden.<\/p>\n","protected":false},"excerpt":{"rendered":"
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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662004,66062004,44000040],"tags":[],"class_list":["post-55000242","post","type-post","status-publish","format-standard","hentry","category-662004","category-66062004","category-Allgemein"],"yoast_head":"\n