Startseite
Informatik
Algorithmen
Datenstrukturen
Software-Engineering
Entwicklungsmodelle
Entwicklungsphasen
Anforderungsdefinition
Anforderungserhebung
Lastenheft
DRUCK
2004
2005
2006
2007
2008
2009
Pflichtenheft
Pflichtenheft-Kriterien
Pflichtenheft-Gliederung
Pflichtenheft-Beispiel
Aufwandsschätzung
Entwurf
Spezifikation
Implementation
Verifikation
Installation
Wartung
Web-Engineering
Programmiersprachen
Künstliche Intelligenz
Schach
Privates
Inhalt
Pflichtenheft
Das Pflichtenheft ist Teil und Voraussetzung des Vertrages.
Das Pflichtenheft ist Teil und Voraussetzung des Vertrages.
Einführung
Definition: Pflichtenheft
Was ist ein Pflichtenheft?
Das
Pflichtenheft
legt
(verbal)
die Anforderungen an die fertige Software fest.
Ziel ist es, aus den Anforderungen des Kunden (Lastenheft) eine möglichst vollständige konsistente und eindeutige Produktdefinition zu erstellen, die Grundlage für das zu erstellende Produkt ist.
Das Pflichtenheft bildet ein verbindliches Dokument zwischen Auftraggeber und Softwareproduzent und ist Grundlage für den abzuschließenden Vertrag, nach dessen Unterzeichnung es nur im gegenseitigen Einverständnis geändert werden darf. [INFODUDEN S. 659]
Das Pflichtenheft ist ein Dokument, welches als Vorgabe das Lastenheft erfordert. Die Erarbeitung des Pflichtenhefts beginnt in der Regel mit der Analyse (Problemanalyse) der im Lastenheft angeführten Anforderungen und Wünsche.
Während dieser Phase sieht sich der Softwareproduzent als fachlich versierter Kundenbetreuer im Rahmen der Kundenakquise und der Vertragsbildung. In enger Zusammenarbeit mit dem Kunden werden das WAS und das WOMIT definiert:
Ziel ist es, aus den Anforderungen des Kunden (Lastenheft) eine möglichst vollständige konsistente und eindeutige Produktdefinition zu erstellen, die Grundlage für das zu erstellende Produkt ist.
Das Pflichtenheft bildet ein verbindliches Dokument zwischen Auftraggeber und Softwareproduzent und ist Grundlage für den abzuschließenden Vertrag, nach dessen Unterzeichnung es nur im gegenseitigen Einverständnis geändert werden darf. [INFODUDEN S. 659]
Das Pflichtenheft ist ein Dokument, welches als Vorgabe das Lastenheft erfordert. Die Erarbeitung des Pflichtenhefts beginnt in der Regel mit der Analyse (Problemanalyse) der im Lastenheft angeführten Anforderungen und Wünsche.
Während dieser Phase sieht sich der Softwareproduzent als fachlich versierter Kundenbetreuer im Rahmen der Kundenakquise und der Vertragsbildung. In enger Zusammenarbeit mit dem Kunden werden das WAS und das WOMIT definiert:
- WAS MUSS WOFÜR PRODUZIERT WERDEN?
- Für WAS wird das Endprodukt eingesetzt?
- WAS muss das Endprodukt demnach beinhalten?
- WAS müssen die Funktionen des Endprodukts bewerkstelligen?
- WAS muss über kurz oder lang gespeichert werden?
- Und gegebenenfalls — WAS kann im Laufe des Wandels noch hinzukommen?
- WOMIT wird entwickelt?
Abgrenzung!
Das Gegenstück zum
WAS
(hier Anforderungsspezifikation)
ist das
WIE
— praktisch die Realisierung —
und hat im Pflichtenheft nichts zu suchen!
Erst nach Vertragsabschluss wird mit der eigentlichen Produktion begonnen,
erst dann kümmert sich der Softwareproduzent als Informatiker darum,
WIE
das
WAS
realisiert werden soll.
Das Handbuch
Ein Softwareprodukt benötigt wie jedes andere Produkt ein Handbuch, welches das Produkt in allen Einzelheiten beschreibt.
Praktisch gesehen, ist das Pflichtenheft bereits das Handbuch.
Nur in die richtige Form übertragen, für den Endbenutzer verständlich gemacht,
dürfte der Aufwand für das Handbuch nicht weiter ins Gewicht fallen.
Dem modernen Softwareproduzenten sei deshalb empfohlen, das Pflichtenheft gleich parallel zum Handbuch aspektorientiert zu erstellen. Bei nachträglicher Korrektur im Pflichtenheft würde das dazugehörige Handbuch nämlich (ggf. voll-) automatisch mitkorrigiert werden. Dieser Ansatz würde sogar die parallele Erstellung von Handbüchern für unterschiedliche Zielgruppen erlauben.
Zudem verspricht [SWTECHNIK]bei einer vorgezogenen Handbucherstellung eine bessere Handhabung
(Usability)
des Endprodukts,
da der Entwickler schon vor dem Entwurf gezwungen sei, sich in die Lage des Endbenutzers hineinzuversetzen.
Bis zur Auslieferung des Endprodukts blieben etwa 50 bis 70 Prozent vom vorgezogenen Handbuch erhalten.
Meines Erachtens handelt es sich dabei um eine kluge Erkenntnis, wenn man bedenkt,
dass allein die Usability über den Erfolg eines Produkts entscheiden kann.
Dem modernen Softwareproduzenten sei deshalb empfohlen, das Pflichtenheft gleich parallel zum Handbuch aspektorientiert zu erstellen. Bei nachträglicher Korrektur im Pflichtenheft würde das dazugehörige Handbuch nämlich (ggf. voll-) automatisch mitkorrigiert werden. Dieser Ansatz würde sogar die parallele Erstellung von Handbüchern für unterschiedliche Zielgruppen erlauben.
Zudem verspricht [SWTECHNIK]
bei einer vorgezogenen Handbucherstellung eine bessere Handhabung
(Usability)
des Endprodukts,
da der Entwickler schon vor dem Entwurf gezwungen sei, sich in die Lage des Endbenutzers hineinzuversetzen.
Bis zur Auslieferung des Endprodukts blieben etwa 50 bis 70 Prozent vom vorgezogenen Handbuch erhalten.
Meines Erachtens handelt es sich dabei um eine kluge Erkenntnis, wenn man bedenkt,
dass allein die Usability über den Erfolg eines Produkts entscheiden kann.
Pflichtenheft - nicht nur für Software!
Ein Pflichtenheft definiert die Anforderungen im Allgemeinen für ein beliebiges Produkt
— es gibt keine Beschränkung auf Softwareprodukte.
Mit einem Pflichtenheft können Sie ebensogut Anforderungen für ein Auto oder für irgendetwas anderes definieren.
Synonyme
In
DIN 69905
wird die Anforderungsspezifikation des Auftragnehmers als
Pflichtenheft
bezeichnet.
Es gibt aber auch andere Bezeichnungen dafür, die sich offenbar eingebürgert haben wie zum Beispiel:
- Fachfeinkonzept
- Sollkonzept
- Anforderungsspezifikation
- Fachspezifikation
- Funktionsspezifikation
Übersetzungen
Für
„Pflichtenheft”
habe ich mehrere mögliche Übersetzungen gefunden, die da lauten:
- „design requirement specification” (m. E. die beste Übersetzung)
- „design specification” (Begriff in der deutschen Raumfahrt)
- „feature specification”
- „product requirements document” (PRD)
- „specification book”
- „work statement”
Anmerkung
Wenn Sie erfahren möchten, was ich von dem Begriffsdschungel halte
und warum ich vorzugsweise den Begriff
„Pflichtenheft”
benutze,
dann sollten Sie sich meine Ausführungen unter
Anforderungsdefinition
durchlesen.
Motivation
Motivation zur Erstellung eines Pflichtenheftes
Weitblick!
Die Erstellung des Pflichtenheftes erfordert ungeheuren Weitblick des Softwareproduzenten.
Hier werden indirekt die Weichen gestellt, wie das gesamte Softwareprodukt am Ende funktionieren soll
und welche Bestandteile es enthalten muss.
Zudem ist es notwendig,
die Realisierbarkeit der Anforderungen erst zu prüfen und gegebenenfalls realisierbare Alternativen herauszuarbeiten.
Dabei sollte der Kontakt zum Kunden sehr nah und projektbezogen sein,
um Missverständnisse aus der Welt zu schaffen,
da kleine Fehler im Pflichtenheft möglicherweise einen immens hohen und unnötigen Aufwand zur Folge haben.
Aufgrund der hohen Verantwortung, die der Verfasser des Pflichtenheftes trägt, müssen die Zusammenhänge in diesem stets erneut plausibel gemacht werden, um Widersprüche aufdecken zu können. Selbst erfahrene Softwareproduzenten haben Schwierigkeiten, ein Pflichtenheft widerspruchsfrei zu halten.
Aufgrund der hohen Verantwortung, die der Verfasser des Pflichtenheftes trägt, müssen die Zusammenhänge in diesem stets erneut plausibel gemacht werden, um Widersprüche aufdecken zu können. Selbst erfahrene Softwareproduzenten haben Schwierigkeiten, ein Pflichtenheft widerspruchsfrei zu halten.
Kommunikation!
Experten unterschiedlicher Fachrichtungen können fabelhaft aneinander vorbeireden.
Es ist ja nicht einmal sichergestellt, dass Experten vom selben Fach sich richtig verständigen können.
Deshalb muss in den meisten Fällen erst ein gemeinsamer Nenner geschaffen werden.
Der dabei entstehende Aufwand lohnt sich allemal, wenn man bedenkt, dass das Pflichtenheft die Anforderungen des neuen Softwareprodukts bis zur Fertigstellung starr definiert.
- Oftmals sagen Skizzen mehr als tausend Worte.
- Aber auch Crashkurse im jeweiligen Fachgebiet tragen sehr zur effektiven Kommunikation bei.
Der dabei entstehende Aufwand lohnt sich allemal, wenn man bedenkt, dass das Pflichtenheft die Anforderungen des neuen Softwareprodukts bis zur Fertigstellung starr definiert.
Formulierung!
Die Anforderungen an eine neue Software sind
vage, verschwommen, unzusammenhängend, unvollständig
und
widersprüchlich.
Dabei spielt die sprachliche Formulierung eine entscheidende Rolle.
Das Lastenheft kann trotz aller Bemühungen des Auftraggebers aus Sicht des Softwareproduzenten ungenau formuliert sein. Der Auftraggeber kann sich manchmal nicht vorstellen, welchen Einfluss so manches Adjektiv auf das Softwareprodukt haben kann.
Mit großer Wahrscheinlichkeit wird aber auch das Pflichtenheft stellenweise inkonsistent formuliert sein.
Oftmals entscheiden Adjektive wie multilingual, modular oder erweiterbar über die Gesamtstruktur des Softwareprodukts.
Auch das Weglassen von Adjektiven kann viel ausmachen. Beispielsweise ist der Unterschied zwischen „alle Browser” und „alle gängigen Browser” immens! Besonders bei „Browser” sollte der Entwickler konkret werden und Standards festlegen wie z. B. „HTML 4.01” oder „korrekt verifizierbar nach W3C”. Alternativ gibt es auch die Möglichkeit Browser bzw. Browserversionen aufzulisten wie zum Beispiel „[...] für folgende Browser: Internet-Explorer (ab 5.0), Firefox (ab 1.5), Safari, [...]”
Das Lastenheft kann trotz aller Bemühungen des Auftraggebers aus Sicht des Softwareproduzenten ungenau formuliert sein. Der Auftraggeber kann sich manchmal nicht vorstellen, welchen Einfluss so manches Adjektiv auf das Softwareprodukt haben kann.
Mit großer Wahrscheinlichkeit wird aber auch das Pflichtenheft stellenweise inkonsistent formuliert sein.
Oftmals entscheiden Adjektive wie multilingual, modular oder erweiterbar über die Gesamtstruktur des Softwareprodukts.
Auch das Weglassen von Adjektiven kann viel ausmachen. Beispielsweise ist der Unterschied zwischen „alle Browser” und „alle gängigen Browser” immens! Besonders bei „Browser” sollte der Entwickler konkret werden und Standards festlegen wie z. B. „HTML 4.01” oder „korrekt verifizierbar nach W3C”. Alternativ gibt es auch die Möglichkeit Browser bzw. Browserversionen aufzulisten wie zum Beispiel „[...] für folgende Browser: Internet-Explorer (ab 5.0), Firefox (ab 1.5), Safari, [...]”
Ungenaue Formulierungen im Lastenheft müssen präzisiert werden
— am besten mit Hilfe des Auftraggebers.
Lesen Sie sich dazu am Besten die
Pflichtenheft-Kriterien
durch.
Aufwandsminimierung!
Das Erstellen eines Pflichtenheftes ist sehr aufwendig und zeitintensiv.
Deshalb sei den Pflichtenheftverfassern geraten, sich ein Framework für ein
(beliebiges)
Pflichtenheft anzuschaffen bzw. ein solches selbst zu erstellen.
Möglicherweise entwickelt sich daraus ein neues Produkt, sozusagen eine
„Pflichtenheft-Software”.
Es ist aber unklar, inwieweit eine
Pflichtenheft-Software
den Aufwand einer Pflichtenhefterstellung minimieren kann.
Seien Sie deshalb sorgfältig bei der Softwareauswahl zur Pflichtenhefterstellung.
Beratungspflicht!
Eine ideale Pflichtenhefterstellung stelle ich mir als gemeinsame
Suche nach einem größtmöglichen, sinnvollen Leistungsumfang
für die zu entwickelnde Software vor.
Wobei ich mit
„gemeinsam”
den Auftraggeber und den Auftragnehmer meine.
Dies ist
m. E.
nur möglich, wenn der Auftragnehmer zusätzlich die Position eines Beraters einnimmt.
Es erscheint nicht sehr sinnvoll, eine Tabellenkalkulationskomponente neu zu entwickeln, wenn der Auftraggeber bereits über Hunderte von Excellizenzen verfügt. In diesem Falle sollte dem Auftraggeber verständlich gemacht werden, dass es softwaretechnisch auch möglich ist, diverse Tabellenkalkulationsaufgaben einem externen, bereits vorhandenen Tabellenkalkulationsprogramm zu übergeben. Die Entwicklungszeit, die man dabei einsparen kann, könnte weiteren sinnvollen Features zukommen. Der Vorteil liegt auf der Hand: Der Auftraggeber kann sich in voller Zufriedenheit einen Teil des Budgets einsparen — oder er erhält für das gleiche Budget einen noch größeren Leistungsumfang.
Die Maxime lautet also:
Es erscheint nicht sehr sinnvoll, eine Tabellenkalkulationskomponente neu zu entwickeln, wenn der Auftraggeber bereits über Hunderte von Excellizenzen verfügt. In diesem Falle sollte dem Auftraggeber verständlich gemacht werden, dass es softwaretechnisch auch möglich ist, diverse Tabellenkalkulationsaufgaben einem externen, bereits vorhandenen Tabellenkalkulationsprogramm zu übergeben. Die Entwicklungszeit, die man dabei einsparen kann, könnte weiteren sinnvollen Features zukommen. Der Vorteil liegt auf der Hand: Der Auftraggeber kann sich in voller Zufriedenheit einen Teil des Budgets einsparen — oder er erhält für das gleiche Budget einen noch größeren Leistungsumfang.
Die Maxime lautet also:
- Der Auftragnehmer sollte sich stets verpflichtet fühlen, nach sinnvollen Verbesserungen an der zu entwickelnden Software zu suchen, um seinen Auftraggeber noch zufriedener und gegebenenfalls noch konkurrenzfähiger zu machen.
Richtlinien
Richtlinien zur Erstellung eines Pflichtenhefts
Richtlinien und Tipps zur Verbesserung der Qualität Ihrer Pflichtenhefte.
Nerven Sie Ihren Kunden!
Dieser Vorschlag ist selbstverständlich nicht wortwörtlich zu verstehen.
Sie sollen hiermit lediglich daran erinnert werden, dass nur der Auftraggeber genau weiß, wie er sich sein Wunschprodukt vorstellt.
Je mehr Sie sich um eine adäquate Anforderungsspezifikation während der Definitionsphase bemühen, desto weniger müssen Sie Ihren Auftraggeber in späteren Phasen konsultieren. Nur Ihr Auftraggeber kann Ihnen zu einer adäquaten Anforderungsspezifikation verhelfen. Mit gezieltem Hinterfragen können Sie die Adäquatheit Ihres Pflichtenheftes sicherstellen. Also entlocken Sie ihm so viele Informationen wie möglich, denn in späteren Phasen ist es meist zu spät.
Wenn Sie sich mit dem Thema „requirements engineering” beschäftigen, erfahren Sie im Detail,
Je mehr Sie sich um eine adäquate Anforderungsspezifikation während der Definitionsphase bemühen, desto weniger müssen Sie Ihren Auftraggeber in späteren Phasen konsultieren. Nur Ihr Auftraggeber kann Ihnen zu einer adäquaten Anforderungsspezifikation verhelfen. Mit gezieltem Hinterfragen können Sie die Adäquatheit Ihres Pflichtenheftes sicherstellen. Also entlocken Sie ihm so viele Informationen wie möglich, denn in späteren Phasen ist es meist zu spät.
Wenn Sie sich mit dem Thema „requirements engineering” beschäftigen, erfahren Sie im Detail,
- was Sie bei der Erhebung der Anforderungen Ihres Auftraggebers zu beachten haben und
- wie diese zu sammeln, zu strukturieren, zu bewerten und zu verwalten sind.
Vage Vorstellungen auflösen!
Immer wieder gibt es unklare Punkte aus dem Lastenheft zu klären, wie z. B. vage Produktvorstellungen.
Einer vagen Produktvorstellung Ihres Auftraggebers sollten Sie, auch wenn es zunächst unnötig erscheinen sollte, durch Hinterfragen nachgehen und aus den daraus resultierenden Erkenntnissen eine klare, präzise Produktdefinition formulieren. Oder wollen Sie sich in späteren Phasen durch Diskussionen um die Produktdefinition aufhalten lassen oder gar die Konsistenz des Produkts aufs Spiel setzen?
Wenn Sie vage Vorstellungen in der Definitionsphase auflösen, verhindern Sie potentielle Meinungsverschiedenheiten. Zudem dämmen Sie mit einer sauberen Anforderungsspezifikation die Risiken der technischen Realisierung ein.
Denken Sie also immer daran, dass das, was im Pflichtenheft steht, später auch realisiert werden muss. Und seien Sie hiermit mit den folgenden Worten gewarnt:
Einer vagen Produktvorstellung Ihres Auftraggebers sollten Sie, auch wenn es zunächst unnötig erscheinen sollte, durch Hinterfragen nachgehen und aus den daraus resultierenden Erkenntnissen eine klare, präzise Produktdefinition formulieren. Oder wollen Sie sich in späteren Phasen durch Diskussionen um die Produktdefinition aufhalten lassen oder gar die Konsistenz des Produkts aufs Spiel setzen?
Wenn Sie vage Vorstellungen in der Definitionsphase auflösen, verhindern Sie potentielle Meinungsverschiedenheiten. Zudem dämmen Sie mit einer sauberen Anforderungsspezifikation die Risiken der technischen Realisierung ein.
Denken Sie also immer daran, dass das, was im Pflichtenheft steht, später auch realisiert werden muss. Und seien Sie hiermit mit den folgenden Worten gewarnt:
- Nicht „ungefähr”, sondern gleich „präzise” — mit „ungefähr” läuft keine Softwähr! :-)
Quellenangabe
-
[INFODUDEN]
-
[SWTECHNIK]