Inhalte Pflichtenheft

[.::NotesUser::.]

Hallo zusammen...

ich habe leider noch nie ein Pflichtenheft erstellt. Nun muss ich es für die Doku leider tun.

Kann mir jemand sagen, welche Punkte zwingend notwendig sind für ein solches Heft. Und kurz den inhalt erläutern, was unter welchen Punkten zu finden sein soll?

Im IT-Handbuch habe ich leider nichts gefunden....

Danke...

[MBaeuml]

Der Sinn eines Pflichtenheftes sagt einem schon den Inhalt.

Es soll dir und dem Kunden helfen deine Arbeit zu umschreiben und abzugrenzen. Also wen du z.B. schreibst: "Erstellung Formular" kann der Kunde das so weit auslegen wie er will, mit unzähligen Änderungen, mal die Farbe, dann noch eine Funktion mehr usw. bis du Geld für die Arbeiten mitbringst.

Um sowas zu vermeiden schreibt man möglichst konkret ins Pflichtenheft die Programmfunktionen rein, sowie das Layout usw. Wer ganz sicher gehen will (habe das hier mal bei nem wirklich gutem Entwickler gesehen und mit dem gearbeitet) der erstellt erst die Studie mit allen Funktionen, schon erstellten Bildschirmmasken usw. legt die dann dem Kunden vor, der unterzeichnet und man ist so abgesichert.

Wen der Kunde dann noch eine Funktion mehr will, oder doch lieber eine andere Farbe oder anderes Layout, kann man bequem die Hand aufhalten und das dann berechnen, man hat ja das Pflichtenheft.

Mehr dazu findest du sicherlich in der Forensuche und bei google

[.::NotesUser::.]

Gut, soviel war mir schon klar.

Was ich suche ist eine art Vordruck mit den "vorgeschriebenen" "offiziellen" Punkten die immer drin sein sollten.

[Fuldaer_Bub]

Hallo...

Guck doch einfach mal hier

Da steht einiges drin. Viel Spaß ! ;)

[.::NotesUser::.]

Ist das nicht ein wenig viel?

Man soll doch die Doku innerhalb von 10 Std als FIAE fertig stellen...

[Fuldaer_Bub]

Du wolltest ja was "offizielles" haben.

Also in der Regel ist die Doku so 6-10h, da kannst Du Recht haben. Ich habe bei meiner Doku für mein Projekt gar kein Pflichtenheft gemacht, sondern das schon mit Soll-Konzept und Ist-Analyse abgedeckt.

Ja, jetzt werden gleich einige Leute schreien.... Aber über die Notwendigkeit eines Lasten/Pflichtenheft entscheidet das Projekt selbst.

[Shinak]

Original geschrieben von Fuldaer_Bub

Aber über die Notwendigkeit eines Lasten/Pflichtenheft entscheidet das Projekt selbst.

Blödsin

Ich hab auch kein Pflichenheft weill es das in meinerm Projekt nicht gab.

Es gibt ein Protokoll der Besprechung was gefordert wird und was gemacht werden soll. Das wird dann in der Ist-Analyse und im Soll-Konzept auseinander genommen.

[MBaeuml]

Wer sagt den das man als FiAE immer ein Pflichtenheft erstellen muss?

[just_me]

*lol, also rein logisch KANN weder Lastenheft, noch Glossar oder Pflichtenheft Bestandteil des bewertbaren Teils des Projektes sein.

Grund:

Nach allem, was ich bisher erfahren habe, musst du ja bekanntlich einen Antrag abgeben, in dem - zeitlich möglichst präzise - dargelegt wird, wie die zur Verfügung stehende Zeit genutzt werden soll.

Diese Zeit-/Materialplanung geschieht auf der Basis vorhandener Informationen, deren Anhäufung primärer Bestandteil der Definitionsphase ist.

Daher MUESSEN Lastenheft, Glossar und Pflichtenheft (oder adäquate eventuell rudimentäre Dokumente) bereits existieren. NIRGENDWO SONST bekommst du die Informationen her, um eine derartig genaue Planung nachvollziehen zu können. (Von Planungen á là "Das haben wir immer so gemacht. Deshalb weiß ich, dass es 3 Stunden dauern wird." einmal abgesehen.)

Ergo:

Entweder das Pflichtenheft wird außerhalb der Rahmenbedingungen "Projekt" - und damit der Dokumentation - erstellt, und dürfte somit auch nur als sekundäre Quelle in die Dokumentation einfließen, oder die einzureichende Zeitplanung ist eine Farce.

Ja, mir ist durchaus klar, dass die IHK da möglicherweise andere Richlinien ansetzen mag. Daher ist dies auch nur ein "rein logischer" Gedanke bar jeder Garantie und/oder Verantwortung ...

[IJK]

@just_me

Es ist sogar eine Prüfungsvariante (für FIAE) ein Pflichtenheft zu erstellen (Gesetzes-/Verordnungstext nicht zu Hand, gab es aber schon hier im Forum).

Außerdem erwarte ich auch bei einem kleinen Projekt ein Pflichtenheft. Klar kann das (damit das kein Widerspruch ist) bereits im Vorfeld erstellt worden sein und nur die Basis für das Projekt begründen. Mir (als Prüfer bzw. Projektvorgeber) ist aber "all inclusive" lieber...

LiGrü

Michael (Prüfer und Praktikantenbetreuer)

[just_me]

Außerdem erwarte ich auch bei einem kleinen Projekt ein Pflichtenheft.

Das ist auch völlig nachvollziehbar. Insbesondere, wenn man erleben muss, dass "Prüfung-Geschafft-Nu'-Aber-Los-Programmierer" in spe derartige Irritationen erleben und fast ein Exzem bekommen, wenn sie das Wort "Pflichtenheft" hören.

Jedoch ist die Chronologie der Anforderungen absolut nicht nachvollziehbar.

Sie baut letztlich auf einer provozierten - und zwangsläufig rekursiv geduldeten - Lüge auf. Das ist absurd, sorry.

Natürlich ist dieses projektorientierte Prüfungsmodell interessant. Und ebenso natürlich hat es (theoretisch) praktischen Nutzwert. Aber wenn derart viele Fragen entstehen - und dies imo vollkommen zu Recht -, die zudem auch noch "regionsabhängig" geklärt werden müssen, dann gerät die gesamte Situtation in den Anschein einer Posse.

In diesem Sinne: Ich halte ich es - auch angesichts der Kommentare weiter oben - sehr wohl für wichtig und richtig, diese Aspekte mitzuprüfen.

Aber warum geschieht das nicht beispielsweise anhand einer "definierten und wohlgeformten Liste", die a) nachvollziehbar, omnipräsent, c) allgemeingültig und d) logisch ist, und in der Lastenheft, Glossar, Pflichtenheft, technische Dokumentation, Benutzerdokumentation und Projektdokumentation einzelne kontrollierbare Schritte des Projektes bilden, die IMMER Bestandteil der Prüfungen sind!?

[hades]

Original geschrieben von just_me

Aber wenn derart viele Fragen entstehen - und dies imo vollkommen zu Recht -, die zudem auch noch "regionsabhängig" geklärt werden müssen, dann gerät die gesamte Situtation in den Anschein einer Posse.

Das ist das Problem.

Es gibt in den IT-Berufen "bundeseinheitliche" Pruefungen (Ausnahme: Baden-Wuerttemberg braet sich hier eine Extrawurst), wo jede der ueber 80 IHKn selbst festlegen kann wie die Pruefung durchgefuehrt wird.

Nun aber zurueck zur Ausgangsfrage: Was gehoert in ein Plichten- und Lastenheft rein...

[just_me]

Die nachfolgende Auflistung stellt einen allgemeinen Ansatz nach Balzert dar. Sie ist weder endgültig noch vollständig. Vielmehr ist es Aufgabe des Verantwortlichen, die speziellen Unternehmens-/Produkt-/Kundenanforderungen zu berücksichtigen.

Das Pflichtenheft ist Grundlage (oft auch rechtlicher Bestandteil) des Vertrages.

Daher ist JEDES Detail relevant. Allerdings steht das Ziel und nicht die Vorgabe im Mittelpunkt. Es ist also ohne weiteres möglich, Punkte zu erweitern oder zu streichen.

(Mein Tipp angesichts der Kürze des Projektes (Gilt nicht, wenn es sich um ein Teilprojekt handelt!): 1 + 2 vollständig, 3-9 in einem Punkt zusammenfassen, 12 streichen. Summa summarum dürften sich dann ca. 7-10 Seiten (je nach Umfang der Funktionsbeschreibungen) Dokumentation ergeben. geschätzter Zeitaufwand: 1-2 MT)

1 Zielbestimmung

1.1 Muss

1.2 Wunsch

1.3 Abgrenzung

2 Produkteinsatz

2.1 Anwendungsbereiche

2.2 Zielgruppen

2.3 Umgebungsbedingungen

3 Produktübersicht

4 Produktfunktionen

5 Produktdaten

6 Produktleistungen

7 Qualitätsanforderungen

8 Benutzeroberfläche

9 Nichtfunktionale Anforderungen

10 Technische Produktumgebung

10.1 Software

10.2 Hardware

10.3 Orgware

10.4 Schnittstellen

11 Anforderungen an die Entwicklungsumgebung

11.1 Software

11.2 Hardware

11.3 Orgware

11.4 Schnittstellen

12 Gliederung in Teilprojekte

13 Ergänzungen/Änderungen

[.::NotesUser::.]

Hey, danke für die vielen Beiträge.

Also von meiner IHK wird ein Pflichtenheft vorgeschrieben.

Die Gliederung is auch net schlecht.

Wenn mir jemand noch sagen könnte was in die ganzen Punkte rein gehört?

Z.B. bei "Orgware" fällt mir nicht mal ein, was das heißt.

Sorry, wenn das jetzt eine DAU-Frage war... aber wie gesagt. Ich hab sowas noch nie gemacht....

[just_me]

Orgware sind Komponenten, die funktional - oder besser: organisatorisch - abhängig sind.

Beispielsweise nutzt dir der beste Exchange-Server nix, wenn er keinen Netzwerkanschluss hat, oder? Deshalb wird der Exchange-Server als "Software" und zugleich der LAN/MAN/WAN/Inet-Anschluss als "Orgware" aufgeführt.

Bevor du jetzt irritiert aufschreist: Kern dieser Betrachtung war eine Software, die Mail-Funktionen unterstützen muss, und sich des Exchange-Servers bedient. Kern deiner Betrachtung ist dein Projekt.

Es nicht notwendig oder sinnvoll, jede Schraube aufzuzählen, sondern lediglich die Hard-, Soft- und Orgware, die benötigt wird, um deinen Projektaufbau nachvollziehen zu können.

Das gesamte Pflichtenheft erfüllt organisatorische Unterstützungsaufgaben.

Mit seiner Hilfe kann der Projektleiter später die Teams koordinieren und Aufgaben verteilen:

Er wird also Kapitel 10 hernehmen, es einem Techniker in die Hand drücken und ihn beauftragen, das Zielsystem bereitzustellen, damit das Ergebnis dieses Projektes (dein Produkt quasi) installiert und funktionsfähig übergeben werden kann.

Gleiches gilt für Kapitel 11, welches für die "Codier-Säue" geschrieben wird...

[Myxxel]

Hi

Etwas OT vom eigentlichen Thread aber da einige geschrieben haben das sie das Pflichtenheft durch IST/SOLL abgedeckt haben, dazu noch ne Frage:

Ich habe ein Meeting mit dem "Kunden" gehabt, in dem genau diese Punkte besprochen wurden, also was ist der momentane Zustand, was soll auf jeden Fall sein, was wäre wünschenswert. Das habe ich alles in einem Protokoll schriftlich fixiert. Für mein SOLL brauch ich eigentlich nur noch die Abschnitte hier rauskopieren...

Jetzt die Frage, muss (oder wäre es sinnvoll wenn) ich dennoch ein Pflichtenheft machen, wenn in dem Protokoll eh schon die Punkte abgearbeitet sind und dieses Protokoll auch im Anhang der Doku beigefügt ist?

[just_me]

Was du beschreibst, ist das "klassische Lastenheft".

Das Pflichtenheft hingegen spezifiziert die - üblicherweise allgemeinverständlichen - Beschreibungen des Lastenhefts in Form fachlicher Termini.

Beispiel:

Im Lastenheft hast du aufgenommen:

> Produkt muss Dateien im Textformat speichern können.

Das Pflichtenheft hingegen setzt sich mit diesem Vorgang detailliert auseinander:

> Wann? Wo? Wie? Wer löst es aus? Wer ist beteiligt? Wie sieht das Dateiformat aus? Welche Bedingungen führen zum Abbruch? Welche Bedingungen lösen andere use cases aus oder beeinflussen diese? Müssen Sicherheiten geprüft werden? ... und und und ...

Wie sonst, wenn nicht im Pflichtenheft, dokumentierst du diese Vorgänge?

[.::NotesUser::.]

Kann es sein, dass im Pflichtenheft sich viele Teile wiederholen vom Sinn her?

Kann es auch sein, dass in einem Pflichtenheft nicht sehr auf die Wortwahl geachtet wird? Also dass sich ganze Textpasagen immer wieder wiederholen? Also nicht auf eine "abwechlungsreiche" Wortwahl geachtet wird?

[just_me]

Im Pflichtenheft gibt es keine Bewertungen für den Stil, falls du das meinst. Wiederholungen sind daher irrelevant, wenn sie die Information bergen, die benötigt wird.

Statt dessen wird auf eine ABSOLUT PRÄZISE Ausdrucksweise Wert gelegt.

Ein Beispiel.

falsch: Dieser Button löst mehrere Male das Event *bing* aus.

richtig: Ein Klick mit der linken Maustaste auf diesen Button löst 13 Mal das Event *bing* aus.

Mit anderen Worten: Es darf nicht der Hauch eines Zweifels bleiben, was gemeint sein könnte. Selbst professionelle Haarspalter und Erbsenzähler müssen sich an den Formulierungen die Zähne ausbeißen. Erst dann ist es korrekt formuliert. Wenn es dabei - mehr oder weniger zwangsläufig - zu Wiederholungen kommt, dann ist das egal. Schließlich handelt es sich um ein technisches Dokument und keinen Liebesroman.

[.::NotesUser::.]

Ist dann in einem Pflichtenheft auch schon bekannt wie etwas gemcht wird.

Also zum Bsp. habe ich den Workflow des Buchens einer Schulung.

Reicht es wenn man schreibt, dass dies durch den Versand von E-Mails realisiert wird. Die Genehmigt oder Abgelehnt werden können.

Oder muss man genau beschreiben wie es funktioniert, jede Funktion?

[just_me]

Ist dann in einem Pflichtenheft auch schon bekannt wie etwas gemcht wird.

Ich nehme diesen Satz als Frage, und antworte völlig eindeutig: ja und nein.

Denn im Pflichtenheft machst du es bekannt. Das ist einer der Lebenszwecke des Pflichtenheftes.

In den Kapiteln 3-8 dokumentierst du haarklein jede einzelne Funktion deines Projektes. Und zwar hat das so zu geschehen, dass du dieses Kapitel einem Programmierschwein in die Hand drücken und diesen dann in eine Kammer sperren kannst. Wenn du ihn nach 3 oder 4 Wochen wieder rauslässt, hat er die fertige Software/Hardwarebastelei in der Hand --- ohne in der Zwischenzeit noch ein einziges Wort mit dir oder anderen wechseln zu müssen.

Daraus lässt sich ableiten, dass jeder - wirklich JEDER - Vorgang eineindeutig zu beschreiben ist.

Das kann - und meistens tut es das auch - mit groben und allgemeinen Übersichten, wie workflow-patterns, Aktivitätsdiagrammen, etc - beginnen, verliert sich aber im Laufe der Dokumentation so weit ins Detail, dass der Programmierer am Ende lediglich das tun muss, was er am besten kann: Zeile für Zeile "übersetzen" (also in maschinenverständliche Sprache übertragen).

Dafür stellt dir die UML umfangreiche Hilfsmittel zur Verfügung, die du im Verlauf deiner Dokumentation rege nutzen solltest. (Einfache Faustregel: Besser vier Diagramme und Beschreibungen zuviel, als eine einzige Beschreibung zuwenig.)

Damit hätten wir wohl auch die folgende Frage erschlagen, oder?

Reicht es wenn man schreibt, dass dies durch den Versand von E-Mails realisiert wird. Die Genehmigt oder Abgelehnt werden können.

Die Antwort lautet zwangsläufig: nein, absolut nicht.

Was passiert vor einer "Ablehnung" der mail?

Was passiert vor einer "Genehmigung" der mail?

Was passiert bei einer "Ablehnung" der mail?

Was passiert bei einer "Genehmigung" der mail?

Was passiert nach einer Ablehnung der mail?

Was passiert nach einer "Genehmigung" der mail?

Kann sich der Zustand "Ablehnung"/"Genehmigung" vor, während oder nach der Bearbeitung ändern? Wenn ja, was soll dann passieren?

Wer schickt die mail?

Wo geht sie ein?

Wer informiert das System darüber, dass eine mail da ist?

Wer ist "das System"?

Welches Modul des Systems ist involviert?

Wer ist "das Modul"?

Wie soll die mail behandelt werden?

Welches Format hat die mail?

Was passiert, wenn die mail unvollständige Informationen beinhaltet?

Was passiert, wenn die mail fehlerhafte Informationen beinhaltet?

Was passiert, während die mail bearbeitet wird?

Wer ist an diesem Vorgang beteiligt?

Was passiert, wenn einer oder mehrere der Beteiligten anderweitig beschäftigt sind und keine Zeit haben? Soll dann gewartet werden? Oder wird die mail verworfen?

Was passiert, wenn die mail verworfen wird?

Was passiert, wenn das System die mail nicht abschließend bearbeiten kann?

Das sind nur ein paar der Fragen, die mir spontan eingefallen sind, die aber ALLE ohne Ausnahme eineindeutig beantwortet werden müssen. Nur dann hat das Projekt eine Chance, die ersten Betatests zu überleben. (Ausnahme: Es ist ein geschlossenes System, das niemals erweitert, geändert oder gewartet werden soll, kann oder muss.)

[Borges]

.::NotesUser::. schrieb:

>Ist das nicht ein wenig viel?

>Man soll doch die Doku innerhalb von 10 Std als FIAE fertig stellen...

Achtung, Missverständnis! Die Dokumentation ist "eine handlungsorientierte Darstellung des Projektablaufes mit praxisbezogenen, d.h. betriebsüblichen Unterlagen" (siehe Umsetzungshilfen des BMF). Das Pflichtenheft ist ein Arbeitsergebniss, entweder als Teil eines umfangreicheren Projektes oder als eigenständiges Projekt. Daher sollte in der Dokumentation "nur" die Vorgehensweise beschrieben werden und das Pflichtenheft selbst dann in den Anhang (sofern erforderlich). Die Zeit, die dafür erforderlich ist, geht nicht zu Lasten der Dokumentation, sondern gehört in die entsprechende Projektphase. Das sollte schon im Projektantrag berücksichtigt worden sein. Der Quellcode einer Anwendung steht ja auch nicht vollständig im eigentlichen Bericht.

Einer meiner FIs hat als Anwendungsentwickler die Erstellung eines Pflichtenheftes als Projektthema gewählt. Dort wurde dann im Projektbericht der Prozeß der Erstellung beschrieben, das eigentliche Pflichtenheft hätte dann einen halben Ordner füllen können. Die Wahl zeigte Mut zum Risiko, da ein solches Projekt im Bereich unserer IHK (Duisburg) wohl noch nicht so oft vorgekommen ist. Das weckt natürlich Aufmerksamkeit bei den Prüfern, im positiven wie negativen Sinne. Aber es hat sich für den (Ex-)Auszubildenden gelohnt ;-)

Gruß,

Borges

[just_me]

Aha, das bringt endlich Licht ins Dunkel, und bestätigt offensichtlich, was ich bereits vermutete.

Danke für diese Information.

Gibt es Quellen, an denen ich mich diesbezüglich (Inhalt, Voraussetzungen, Umsetzung, Bewertung, etc.) ausführlich - und vor allem: präzise - informieren kann? Das Suchen auf den Seiten der IHKn ist mehr als mühselig und die entsprechenden Informationen, über die ich derzeit verfüge, sind überdies unglaublich dezentral und divergent - ja, ich bin geneigt, es "vorsätzlich kontrovers" zu nennen.

[Borges]

Original geschrieben von just_me

Gibt es Quellen, an denen ich mich diesbezüglich (Inhalt, Voraussetzungen, Umsetzung, Bewertung, etc.) ausführlich - und vor allem: präzise - informieren kann?

Das Wochenende scheint für mich schon zu nah zu sein...was meinst Du genau?

-Zitiert habe ich aus: http://www.bmbf.de/pub/it-abschlussbericht.pdf

-Aúch immer wieder nett sind die Handreichungen der IHK z.B. unter http://www.ihk-duisburg.de/downloads/Handreichungen_IT-Berufe.pdf

Sollte konkret das Pflichtenheft gemeint sein, kann ich nur auf die DIN VDI/VDE3694 verweisen. Die wollte der Prüfungsausschuss im o.g. Fall ausdrücklich berücksichtigt haben.

Schönes Wochenende!

Gruß,

Borges

[timmi-bonn]

Original geschrieben von just_me

Aber warum geschieht das nicht beispielsweise anhand einer "definierten und wohlgeformten Liste", die a) nachvollziehbar, omnipräsent, c) allgemeingültig und d) logisch ist, und in der Lastenheft, Glossar, Pflichtenheft, technische Dokumentation, Benutzerdokumentation und Projektdokumentation einzelne kontrollierbare Schritte des Projektes bilden, die IMMER Bestandteil der Prüfungen sind!?

Weil ein Projekt nach verschiedenen PMS-Modellen ablaufen kann. In manchen gibt es z.B. ein Pflichtenheft, nicht jedoch ein Lastenheft. Ein Fachkonzept ist nicht in jedem PMS obligatorisch. Meilensteine und Berichtswesen werden in vielen PMS weggelassen - usw. usw.

Daher kann es keine einheitliche Schablone zum Prüfen eines Projektes geben.

gruß, timmi