Inhalt Pflichtenheft

[standi]

Hallo,

zur Klarstellung vorerst. Dies ist kein reales Projekt, sondern dient für theoretischem Schulzweck.

In vielen Lektüren heißt es, dass ein Pflichtenheft, eine Antwort auf das Lastenheft ist. Aus dem "WAS", wird im Pflichtenheft auch ein "WAS" und "WIE". Sprich, wie man gedenkt die Anforderung durchzusetzen.


Nun gibt es ein Aufbau nach Helmuz Balzert (Produktfunktionen, Produktdaten und Produktleistungen) oder wie ich es auch oft gesehen habe eine Unterteilung in "Funktionale Anforderungen" und "Nicht funktionale Anforderungen"

Nun meine Fragen:

1. Wie werden im Kapitel "Funktionale Anforderungen" zwischen Funktion und Daten unterschieden?
Gibt es in "Funktionale Anforderungen" die Unterteilung "Produktfunktion" und "Produktdaten"? Wo tauchen Produktleistungen dann wiederum auf? Sind Produktleistungen und Qualitätskriterien dann "Nicht funktionale Anforderungen" ?


2. Nun die eigentliche Frage. Es heißt in manchen Lektüren (sogar im selben Dokument), dass man im Pflichtenheft das "WIE" verfasst, aber dennoch soll man keine Lösung suggerieren. Ist aber das WIE != Lösung? Kann man im Pflichtenheft zu den Anforderungen schreiben, dass Anforderungen 1-10 Beispiel mit Software A abgedeckt werden, und Anforderungen 20-30 mit Software B mit einer kleinen Anpassung im Bereich XYZ?

3. Kann man auch benötigte Hardware eventuell genau spezifizieren und aufführen?


Über Tipps würde ich mich sehr freuen.



Viele Grüße

 

[echoDave]

Also ich kenne es von der Arbeit so Fachkonzept (Lastenheft) wird vom Kunden verfasst dort stehen die Anforderungen, Leistungsausgrenzungen und Prämissen.

Im DV-Konzept (Pflichtenheft) beschreibt der Projektleiter/Entwickler wie er diese umsetzen will.
Ich habe die Erfahrung gemacht, dass je genauer man den Lösungsweg im DV-Konzept beschreibt umso weniger Probleme kommen später in der Realisierungsphase.

Natürlich muss man da abwägen was grob beschrieben werden kann und was sehr detailiert beschrieben werden sollte. Komplexe Programmlogik oder komplexe Fachliche Anforderungen wurde ich sehr genau beschreiben. genau beschreiben bedeutet dass du die verwendete Technik beschreibst, Pseudocode und Diagramme sind seht gut.

Allgemein gilt die Devise: "Schreibe das DV-Konzept so dass ein anderer Programmierer der mit dem Projekt nichts zu tun hat, es umsetzen kann und die fertige Anwendung tut was sie tun soll"


Hoffe konnte weiterhelfen ;-)

LG

 

[standi]

Hi,
vielen Dank. Hilft mir natürlich weiter. Wie sieht es aus, wenn man nicht programmiert, sondern für bestimmte Anforderungen eine Fertigsoftware installiert. (ggf. noch Anpassungen vornimmt)


1. Kann man hier das Fertigprodukt nennen?

2. Was mir noch fehlt. In welchem Standardkapitel man Hardware und Infrastruktur erwähnt, die noch im Rahmen des Pflichtenheftes bezogen werden?

Grüße

 

[Poke646]

Im DV-Konzept (Pflichtenheft) beschreibt der Projektleiter/Entwickler wie er diese umsetzen will.
Ich habe die Erfahrung gemacht, dass je genauer man den Lösungsweg im DV-Konzept beschreibt umso weniger Probleme kommen später in der Realisierungsphase.

Ich glaube nicht, dass das Pflichtenheft das selbe ist wie ein DV-Konzept. Mit der Grundaussage hast du jedoch recht, ein gutes Pflichtenheft ist die eigene Versicherung, nicht primär nur wegen der technischen Seite. In der Regel wird dies nämlich Vertragsbestandteil und ist eins der wenigen Dinge, auf welche du dich hinterher bei rechtlichen Problemen stützen kannst.

Komplexe Programmlogik ... wurde ich sehr genau beschreiben ... Pseudocode .... sind seht gut.

Hm, dieser feine Detailierungsgrad ist eigentlich nicht Bestandteil eines Pflichtenhefts, dafür gibt es genug andere Dokumente. Was im Pflichtenheft steht, sollte vom Kunden schon noch grob verstanden werden, denn der muss es annehmen. In der Regel hat der jedoch keine Ahnung von technischen Details (mal überspitzt formuliert).

 

[kinglouy]

Im Pflichtenheft keine Details nennen, WIE du die im Lastenheft vorgegebenen Ziele erreichen willst (d.h. kein Code oder sonstiges). Noch dämlicher wäre es, das ganze so zu schreiben, dass es jeder dahergelaufene Programmierer allein aus dem Pflichtenheft umsetzen kann.

Bei der Erstellung des Pflichtenhefts ist nämlich noch kein Geld geflossen und ein Auftrag ist auch noch nicht sicher. Gibst du hier im Pflichtenheft allerdings schon erarbeitete Lösungen ab, bedankt sich der Auftraggeber für die unbezahlte Lösung und macht es selber.

 

[estre]

@ Poke646
Genau so sehe ich das auch.

Im Pflichtenheft keine Details nennen, WIE du die im Lastenheft vorgegebenen Ziele erreichen willst (d.h. kein Code oder sonstiges). Noch dämlicher wäre es, das ganze so zu schreiben, dass es jeder dahergelaufene Programmierer allein aus dem Pflichtenheft umsetzen kann..

Bei der Erstellung des Pflichtenhefts ist nämlich noch kein Geld geflossen und ein Auftrag ist auch noch nicht sicher. Gibst du hier im Pflichtenheft allerdings schon erarbeitete Lösungen ab, bedankt sich der Auftraggeber für die unbezahlte Lösung und macht es selber.

Das sehe ich komplett anders. Meiner Erfahrung nach ist es zwingend erforderlich im Pflichtenheft sämtliche Details zu nennen, nämlich genau dafür ist das Pflichtenheft gedacht. Natürlich wird niemand hingehen und Quellcode ins Pflichtenheft schreiben, aber wenn ich beispielsweise eine SAP-Schnittstelle zu meinem CRM-System benötige, dann steht im Pflichtenheft genau wie dies umgesetzt wird.
Es ist die Grundlage auf die sich der Kunde während der Implementierung der Software berufen kann. Dort steht genau drin wie die Anforderungen des Kunden aus dem Lastenheft umgesetzt werden sollen. Alles andere ist viel zu sehr wischi-waschi und führt häufig zu höheren Kosten beim Auftraggeber.


Auch, dass er Kunde nach Erstellung des Pflichtenheftes abspringen könnte wenn es zu detailliert ist halte ich für ziemlich unrealistisch. Jedenfalls habe ich persönlich noch kein Pflichtenheft gesehen (und ich habe schon einige gute gesehen) anhand dessen man das Projekt komplett alleine umsetzen könnte, das ist doch nicht praxisnah.

 

[standi]

Hallo,
vielen Dank euch allen für die Informationen und der Meinungen.

Klar, wenn man selber etwas entwickelt, dass es schwierig ist, den Detaillierungsgrad festzulegen. Für den einen ist es besser, desto detaillierter desto besser, für den einen ist dies zu viel Aufwand, bzw. nicht Platz im Pflichtenheft.

Wie sieht es aber, wie bereits erwähnt aus, wenn man nicht ein Produkt entwickelt, sondern eine Fertiglösung (Softwarebezug) installiert. Dann gibt es hier ja praktisch 0 oder 1. Erwähnen oder nicht erwähnen?

@estre
wie sieht es aus mit benötigter Hardware. Abgesehen vom Detaillierungsgrad. In welches Kapitel tut ihr das rein (tut ihr es überhaupt rein), wenn das Pflichtenheft einen allgemeinüblichen Aufbau hat?

 

[estre]

Hallo,
Wie sieht es aber, wie bereits erwähnt aus, wenn man nicht ein Produkt entwickelt, sondern eine Fertiglösung (Softwarebezug) installiert. Dann gibt es hier ja praktisch 0 oder 1. Erwähnen oder nicht erwähnen?

Bei einer Fertiglösung (Standardsoftware) ist es in vielen Fällen nicht großartig anders als bei einer individuellen Lösung. Der große Unterschied in diesen beiden Dingen besteht ja darin, dass du als Kunde bei einer Fertiglösung deine Geschäftsprozesse an die Software anpassen musst. Bei einer Individualsoftware hingegen wird die Software an deine Prozesse angepasst.
Dies ist ein grundlegender Unterschied, da du dir bei Letzererm wesentlich mehr Gedanken über deine internen Prozesse machen musst, da du von dem Softwareprodukt nicht an die Hand genommen wirst.

Um nun wieder auf deine Frage des Detaillierungsgrades zurückzukommen: Du musst immer aus Sicht des Kunden denken. Es interessiert niemanden wie viele Zeilen Code im Quellcode stehen (weder bei Standardsoftware noch bei Individualsoftware).
Der Kunde möchte wissen WIE der Softwareanbieter (konkret) gedenkt die Anforderungen aus dem Lastenheft umzusetzen. Angenommen du entscheidest dich als Kunde für die Einführung einer Individualsoftware und hast im Lastenheft dokumentiert wie ein Kundendatensatz aufgebaut sein muss (also welche Eigenschaften/Felder dieser beinhalten muss (Name, Vorname, Adresse, etc.)). Im Pflichtenheft würde ich als Kunde dann z.B. einen Sketch/Mock-Up des Kundendatensatzes erwarten, damit ich weiß wie es im späteren Programm aussehen wird.

Nehmen wir nun an du entscheidest dich für eine Fertiglösung und hast ebenfalls im Lastenheft dokumentiert, dass dein CRM-System eine Schnittstelle zu SAP benötigt. Wenn du sauber gearbeitet hast steht da nicht nur, dass du die Schnittstelle benötigst, sondern auch noch ob sie uni-/bidirektional sein muss oder wie oft die Daten synchronisiert werden müssen (einmal pro Tag, alle Stunde whatever).
Im Pflichtenheft würde man dann noch viel detaillierter beschreiben wie man die Schnittstelle umsetzt. Also z.B. welche Felder genau synchronisiert werden müssen, ob die Schnittstelle dateibasiert arbeitet (z.B. durch Austausch von XML Dateien), ob die Schnittstelle „triggergesteuert“ (also immer wenn sich ein Datensatz ändert) die Datensätze aktualisiert (Beispiel: Datensatz XY wird im CRM-System geändert. Die Schnittstelle bekommt dies mit und aktualisiert den Datensatz auch direktin SAP), oder wie der Datentransfer zwischen den Systemen genau ablaufen muss (welches ist das führende System? welches System darf nur Änderungsanfragen an Datensätze stellen ?).
Dies sind ja alles Dinge die du während du dein Lastenheft erstellst und somit noch gar nicht weißt wer der finale Softwareanbieter mit seinem Produkt sein wird, nicht wissen kannst. Insofern stehen sie im Pflichtenheft, welches dann übrigens vom Softwareanbieter erstellt wird.

@estre
wie sieht es aus mit benötigter Hardware. Abgesehen vom Detaillierungsgrad. In welches Kapitel tut ihr das rein (tut ihr es überhaupt rein), wenn das Pflichtenheft einen allgemeinüblichen Aufbau hat?

Hardwareanforderungen müssen natürlich auch in das Pflichtenheft, genauso wie Lizenzkosten. Häufig stehen diese Dinge auch schon im Angebot, das der Softwarehersteller im Rahmen des Auswahlprozesses abgibt. Allerdings sind diese oftmals nicht genau genug und geben nur eine ungefähre Hausnummer an, da der Anbieter deine IT-Infrastruktur natürlich noch nicht kennt.
Wo es per Definition zu stehen hat weiß ich jetzt nicht, Hauptsache es steht aber irgendwo. Man könnte es z.B. zum Aufbau der Systemlandschaft dazuschreiben…


Grüße

 

[standi]

Hi estre,

vielen Dank für Deine ausführliche Antwort.

Bei einer Fertiglösung (Standardsoftware) ist es in vielen Fällen nicht großartig anders als bei einer individuellen Lösung. Der große Unterschied in diesen beiden Dingen besteht ja darin, dass du als Kunde bei einer Fertiglösung deine Geschäftsprozesse an die Software anpassen musst. Bei einer Individualsoftware hingegen wird die Software an deine Prozesse angepasst.
Dies ist ein grundlegender Unterschied, da du dir bei Letzererm wesentlich mehr Gedanken über deine internen Prozesse machen musst, da du von dem Softwareprodukt nicht an die Hand genommen wirst.

Genau. Wobei es ja sein kann (bei sehr kleinen Projekten), dass eine Fertiglösung sich den Prozessen des Unternehmens fügt, ohne dass weder die Prozesse, noch die Fertiglösung großartig angepasst werden muss.

Bei größeren Projekten jedoch stelle ich mir weitere Fragen. Nämlich der Machbarkeitsstudie, wenn ein Lastenheft vorliegt und eine Pflichtenheft generiert werden muss.

In der Machbarkeitsanalyse geht es hauptsächlich um die wirtschaftliche und technische Machbarkeit.

Ach, ich merke gerade, dass meine Frage sinnlos wird. Denn der potentielle Auftragsnehmer muss intern ja eh ein Grobkonzept machen, ob er das Lastenheft erfüllen kann und kann daraus folgern, ob es wirtschaftlich und technisch umsetzbar ist :-)

 

[Bauergiesen]

Schau dir am besten zur genauen Abgrenzen zwischen Pflichtenheft, Lastenheft, Fachkonzept und DV/IT-Konzept folgende Seite genauer an:
http://www.philipphauer.de/study/pm/it-projektmanagement.php

Schließlich gibt es zwischen den einzelnen auch Überschneidungen

 

[standi]

Hi,
ja das ist wirklich sehr schön zusammengestellt.

Ist das Pflichtenheft vom Kunden abgesegnet, beginnt die Phase der Grobkonzipierung. Hier werden die Lösungsansätze des Pflichtenheftes im Hinblick auf die technischen Anforderungen und Realisierungsmöglichkeiten vertieft. Die Lösungsvorschläge werden konkreter und weniger abstrakt.

Wenn aber ein Auftragsnehmer ein Pflichtenheft erstellt, muss bzw. sollte er ja davor eine Grobkonzeption aufstellen, um überhaupt zu wissen, ob die Anforderungen erfüllt werden können oder nicht? Und wäre die Anforderungskomplexität gering, dann könnte man mit einer Grobkonzeption eigentlich schon die Lösung haben. (Voraussetzung es gibt eine Fertiglösung, ansonsten kann man eine Individualsoftware natürlich immer von Grob in Richtung Fein planen)

 

[estre]

Letzlich ist es eine reine Frage der Definition.
Für mich gehören Grobkonzept und Detailentwurf, wie sie in dem verlinken Artikel genannt werden, ins Pflichtenheft.
Alles andere halte ich auch für nicht praxisnah. Niemand geht hin und wird eine derart strikte und granulare Trennung vornehmen, diese paradigmenhaften Definitionen ohne Bezug zur Realität lernt man nur so in der SChule

Mit Grobentwurf ist wahrscheinlich die Erstellung von Ablaufdiagrammen oder Klassendiagrammen gemeint, also schon Dinge die man erst für die Erstellung des Pflichtenheftes benötigt

 

[Bauergiesen]

Die meisten Sachen sind Definitionssache bzw. liegen im Ermessen des Erstellers.
In den meisten größeren Unternehmen gibt es Standards und Vorlagen, welche genau beschreiben, was in entsprechende Dokumente reingehört.
Ich würde z.B. ein Klassendiagramm nicht als Grobentwurf ansehen, sondern als klare Spezifikation in einem DV/IT-Konzept sehen. (z.B. als Definition einer Schnittstelle /WebService)

 

[Poke646]

Also Klassendiagramme und Co. gehören definitiv nicht ins Pflichtenheft, das ist ein Dokument zwischen Dir und deinem Kunden. Kann sein, dass irgendwann mal ein Kunde daher kommt und dir das Pflichtenheft um die Ohren haut wenn er dort solche Details vorfindet. Es geht ja nicht nur darum, dass der Kunde solche Dinge nicht versteht, es geht auch darum, dass sie ihn gar nicht interessieren.

Wenn du ein Auto kaufen gehst, dann steht auf dem Datenblatt und im Vertrag 160 PS, 2 Liter Vierzylinder Benzinmotor, vielleicht noch wie viel Drehmoment bei welcher Drehzahl. Dort steht aber nichts darüber, wo der Totpunkt deiner Zylinder liegt, wie die Einlasssteuerzeiten der Ventile sind und mit wie viel Grad die Zylinderbänke angeordnet sind, warum auch?

Außerdem sollte das Pflichtenheft dann auch mal abgeschlossen sein. Willst du jedesmal das Pflichtenheft ändern, wenn sich was an deinen Implementierungsdetails ändert? Nein, dafür ist es nicht da.

Der Point of no return ist bei der Erstellung des Pflichtenhefts übrigens noch lange nicht erreicht. Wenn du dir die Mühe machst, ein über-detailiertes, technisch fein-granulares Pflichenheft zu machen, kann der Kunde danach immer noch sagen, nö lass mal, ich geh zur Konkurrenz. Der Aufwand hat sich für dich ja super gelohnt.

Das hat gar nichts mit Unterschied Realität <-> Schule zu tun.

 

[standi]

Ja, ihr habt Recht.

Das hat gar nichts mit Unterschied Realität <-> Schule zu tun.

Von manchen Proffs. (Schule) wird es ja so heruntergebrochen, dass man sagt, dass in das Pflichtenheft garnichts von dem "WIE man es gedenkt zu lösen" hereinkommt. Das nennen die dann aber auch SRS und SDD.

In der Praxis würde das aber am Besten gehen, wenn ein Vertrag abgeschlossen wurde und man gemeinsam (AG und AN) den SRS ausarbeiten. Bis zu einem Vertrag könnte man kommen (wie es bereits estre mal geschrieben hatte) über eine Compliancematrix.

Jetzt könnte aber von einem Proff. die Gegenfrage kommen, warum nicht gleich ein Pflichtenheft/SRS erstellen, ohne das ein Designkonzept(DV-Konzept)/SDD genannt wird.

 

[standi]

Mir fällt seit gestern kein Gegenargument (bzw. Problematik aus der Praxis) nicht ein, warum im Pflichtenheft nur Anforderungen (WAS) zu schreiben und das WIE komplett im Software Design Description oder DV-Konzept oder sonst etwas :-)

 

[Bauergiesen]

Poke646: Da muss/kann ich dir leider nicht Recht geben. Wenn z.B. ein Projekt zwischen zwei technischen Dienstleistern realisiert wird, dann machen z.B. Schnittstellen-Diagramm Sinn. Wie soll denn ansonsten technisch ansonsten beschrieben sein, wie die Schnittstelle aussieht?

 

[BullshitBingo]

Also es gibt ja keine allgemein gültige Vorgabe, was alles in ein Pflichtenheft gehört. Aus meiner Erfahrung kommen in das Pflichtenheft neben den Anforderungen auch Geschäftsprozesse, Anwendungsfälle, Beschreibung des groben fachlichen Entwurfs und und und.

 

[Poke646]

Poke646: Da muss/kann ich dir leider nicht Recht geben. Wenn z.B. ein Projekt zwischen zwei technischen Dienstleistern realisiert wird, dann machen z.B. Schnittstellen-Diagramm Sinn. Wie soll denn ansonsten technisch ansonsten beschrieben sein, wie die Schnittstelle aussieht?

Das sind dann aber keine Interna mehr, die einen davon nichts angehen würden. Wüsste nicht, wo ich da etwas anderes gesagt habe.

 

[standi]

Und was für Argumente sprechen dagegen, wenn man ins Pflichtenheft überhaupt kein Design ("WIE") auflistet? Wie nach IEEE in SRS nur die Anforderungen und separat in das SDD das Konzept, wie man gedenkt die Anforderungen zu lösen.