Diskussion:Pflichtenheft/Archiv/1

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Lemma-Abgrenzung

Müßte hier nicht vielleicht auch etwas über Pflichtenhefte in anderen Bereichen als der IT gesagt werden? --HoHun 18:21, 5. Okt 2004 (CEST)

Vielleicht sollte diese Seite dann eher nur allgemein etwas über Plichtenhefte enthalten und Unterseiten zu den einzelnen Fachgebieten haben. Fritz 04.08.2005

Es gibt auch den Artikel Software_Requirements_Specification - evtl zusammenlegen?

  • Fände ich nicht gut die beiden Ansätze mit Gewalt zu mergen. Besser ist verlinken. Besser ist, wenn gleich oben in der Zusammenfassung zu lesen ist, dass das Pflichtenheft zu Balzerts Modellen gehört. Also zu Wasserfallmodell, Spiralmodell, Rapid Prototyping. In anderen Modellen gibt es das Wort "Pflichtenheft" eh nicht. :-) --Patchworker 14:20, 6. Sep 2005 (CEST)

Nicht jeder, der ein Pflichtenheft schreibt/benutzt, arbeitet nach einem benannten Vorgehensmodell. Ich finde es tut eher not, die Rolle und den Zweck eines Pflichtenheftes in einem Entwicklungsprozess zu beschreiben. Den Ansatz, einfach das Inhaltsverzeichnis eines Prozessberaters zu verkaufen, finde ich nicht gut. Das kommt dann schon zu sehr in Richtung Reklame.

Lastenheft und Pflichtenheft in der Hand der Entwickler

Im Artikel wird davon gesprochen, dass das Lastenheft vom Auftraggeber ausgearbeitet wird, während das Pflichtenheft von Auftragnehmer erstellt wird. Ich bin mir sicher, dass beide Dokumente von den Software-Entwicklern (Auftragnehmern) geschrieben werden. Das Lastenheft ist eine Vorstufe für das Pflichtenheft, welches zum Review dem Auftraggeber vorgelegt wird, und in oft mehreren Iterationsstufen dann irgendwann daraus das Pflichtenheft formuliert werden kann. -- WhiteCrow 17:22, 21. Dez. 2006 (CET)

Also in der Firma, wo ich gearbeitet habe, kam das Lastenheft definitiv von der auftraggebenden Firma. Bei uns, den Auftragnehmern und Entwicklern, wurde daraus das Pflichtenheft erarbeitet, das vom Auftraggeber nochmal abgesegnet werden musste und dann als Grundlage der Entwicklung bei uns diente. --PeterFrankfurt 02:07, 26. Dez. 2006 (CET)
Da wir uns hier offensichtlich nicht einig sind, habe ich den Text des Artikels neutraler formuliert und möchte die Rolle des Lastenhefts erstmal zur Diskussion stellen, denn in meiner Arbeit als Dozent am Lehrstuhl Softwaretechnik haben meine Kollegen und ich es über Jahre so gelehrt, wie ich es oben beschrieben habe. Wenn es geklärt und durch ausreichend Quellen belegt ist, sollte dann auch der Artikel Lastenheft entsprechend aktualisiert werden. --WhiteCrow 15:46, 27. Dez. 2006 (CET)
Erstaunlich. Im Artikel Lastenheft steht es m. E. korrekt, und das habe nicht ich geschrieben. Irgendwas muss doch schließlich vom Auftraggeber kommen. Wie soll das dann sonst heißen? Die von mir zitierte Praxis aus dem Automobilzuliefererbereich ist doch logisch: a) Der Auftraggeber braucht etwas Bestimmtes. Er formuliert, was er haben will, wer schließlich sonst. Und das nennt sich dann halt Lastenheft. b) Der potenzielle Auftragnehmer schaut sich diese Anforderung an (auf Neudeutsch kommt dann schnell der Terminus Requirements (Management) ins Spiel). Er entscheidet, ob das überhaupt machbar ist, wenn ja, wie es ggf. durch Modifikation schon bestehender Produkte realisiert werden kann. c) Mit diesen erarbeiteten Erkenntnissen formuliert er das Pflichtenheft, d) lässt es sich vom Auftraggeber absegnen und e) setzt dann seine Leute an die praktische Arbeit. - Das ist für mich ein konsistenter und logischer Ablauf.
Das war jetzt die hehre Theorie. In der hässlichen Praxis arbeitet man natürlich oft laxer. Bei uns wurden die Pflichtenhefte aus Zeitnot häufig als Allerletztes fertig, aber der Auftraggeber hat sie netterweise trotzdem abgesegnet, und wir waren uns immer bewusst, dass es eigentlich anders hätte laufen sollen... --PeterFrankfurt 21:28, 27. Dez. 2006 (CET)

IT-Handbuch für Systemelektroniker und Fachinformatiker, ISBN 3-14-225042-5, S. 336: "Pflichtenheft... Vom Auftragnehmer erarbeitete Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes.". Hier wird auf die DIN VDI/VDE 3694: 91-04 verwiesen.

Aus der Praxis kann ich bestätigen, dass manche Kunden fachlich nicht mehr in der Lage sind, ein Lastenheft zu erstellen. Also erstellt man es selber und lässt es sich bestätigen. Allerdings bestehe ich immer auf ein abgesegnetes Pflichtenheft. Ich habe schon zu viele Never-Ending-Stories erlebt. --Mfg.fw 12:20, 4. Jan. 2007 (CET)

Der Artikel ist mit dem Vorgehen in der Raumfahrt nicht kompatibel. Die Abgrenzung zwischen Lastenheft (specification) und Pflichtenheft (statement of work) ist an einigen Stellen falsch. Formell erstellt beides der Auftraggeber; manchmal lässt er sich diese vom Auftraggeber erstellen weil er nicht die entsprechenden Leute hat. Im kontraktuellen Kontext sind beide Dokumente jedoch Auftraggeber-Dokumente. Irgendjemand sollte den Artikel klarziehen....--Hjpospie 14:40, 7. Jan. 2007 (CET)

Huch, jetzt geht es ja 180° in das andere Extrem. Dass der Auftraggeber das Lastenheft erstellt, kenne ich ja auch, und dass er das manchmal den Auftragnehmer machen lässte, sozusagen auf Zuruf, kann ich mir auch vorstellen. Aber dass das Pflichtenheft vom Auftragnehmer kommt, finde ich logischer, weil hier ja die Machbarkeit und die praktische Realisierbarkeit z. B. in Angesicht irgendwelcher Vorgeschichte und deren potentieller Modifikation einfließen muss. Aber auch hier kann ich mir in der Realität vorstellen, dass die Rollen aus irgendwelchen praktischen/historischen Gründen schon mal anders verteilt sind. Aber dass für die Erstellung des Pflichtenheftes offiziell der Auftraggeber zuständig sein soll, kann ich mir aus obigen Gründen schlecht vorstellen. Er muss es natürlich genehmigen, gutheißen, akzeptieren, autorisieren oder was auch immer, aber machen? --PeterFrankfurt 22:27, 7. Jan. 2007 (CET)
Ich glaube nicht, dass es in's andere Extreme geht, es herrscht nur ein ziemliches Durcheinander zwischen Lastenheft und Pflichtenheft. Ich habe unter Lastenheft versucht, die beiden Arten des Lastenheftes (= technische Anforderungen) und wer was schreibt für die Raumfahrt zu beschreiben. Das Pflichtenheft (= Durchführungsanforderungen) hat damit nichts zu tun (ausser das es z.B. fordert, wann das Lastenheft zur Unterschrift vorliegen soll). Ich habe den Eindruck, dass die anderen Gebiete in dieser Systematik von der Raumfahrt lernen können:-) --Hjpospie 11:43, 8. Jan. 2007 (CET)

Lasten- versus Pflichtenheft. Im V-Modell-XT (das Vorgehensmodell des Bundes zum Planen und Durchführen von Projekten, für Bundesbehörden vorgeschrieben!) wird das Pflichtenheft "Gesamtsystemspezifikation" genannt und als Teil der Entwicklung (also auf Auftragnehmerseite) verstanden. Die (funktionalen und nichtfunktionalen) Systemanforderungen dagegen werden laut V-Modell-XT vom Auftraggeber (evtl. mit externer Hilfe) in das Lastenheft verfaßt. Das Lastenheft ist im V-Modell-XT somit das relevante, vetragsverbindliche Dokument bei der Abnahme einer Leistung. -- Gruss aus Bonn, Julian Daniel Jimenez-Krause jk<at>zadi.de, 28.08.2007

Jetzt verstehe, ich warum in unserem Hause an Ausschreibungen gar nicht mehr teilgenommen wird, bei denen das V-Modell vorgeschrieben ist! ;) - im Ernst: im Pflichtenheft definiere ich als Auftragnehmer, wie ich die Anforderungen aus dem Lastenheft umsetzen will. In der Regel habe ich dabei immer Abweichungen von den Vorgaben des Lastenhefts, die ich begründe und damit neue Abnahmebedingungen im Pflichtenheft festschreibe. Bei der Abnahme gegen das Lastenheft zu prüfen hieße, den Verfahrensweg des Auftragnehmers zu ignorieren. Das kann ja nicht gut gehen. Die Pflichtenhefte aus unserem Haus werden immer Vertragsbestandteil - der Testplan für die Abnahme wird aus den Funktionsbausteinen des Pflichtenhefts generiert. -- Benutzer:Dudlhofer 01.01.2008

Lastenheft, Pflichtenheft vs. Verantwortung Auftraggeber/ Auftragnehmer

Ich beschäftige mich nun schon einige Jahre mit der Thematik Anforderungsmanagement und kenne die hier geführte Diskussion nur zu gut, da mir sämtliche Interpretationsweisen schon untergekommen sind. Rein formell betrachtet erstellt der Auftraggeber das Lastenheft und der Auftragnehmer das Pflichtenheft. In der Praxis ist es jedoch so, dass nur in den seltensten Fällen das Lastenheft die "Qualität" aufweist, die für die Erstellung eines Pflichtenhefts notwendig ist. Oftmals sind die Anforderungen unvollständig, widersprechen sich oder sind nicht eindeutig (prüfbar) formuliert. Die Erfahrung zeigt, das die Mithilfe durch den Auftragnehmer erforderlich ist, das Lastenheft in die "notwendige" Form zu bringen (ganz typisch ist das Fehlen der nicht-funktionalen Anforderungen, die zwar immer bestehen, doch kaum berücksichtigt werden). Entscheidend ist letztendlich, dass das Lastenheft vom Auftraggeber freigegeben werden muss. Die "Kunst" bei der Anforderungserfassung ist, dass diese dem Qualitätsmerkmal "Modifizier- und Erweiterbarkeit" entspricht, denn letztendlich können Änderungen des Lastenhefts (sprich der Anforderungen) nicht nur nach der initialen Registrierung, sondern auch noch bei der Pflichtenhefterstellung oder bei der Realisierung und Test entstehen, denen Rechnung getragen werden muss. Das Pflichtenheft, bzw. dessen Erstellung, ist ausschließlich Sache des Auftragnehmers, er legt fest wie die Anforderungen realisiert werden. Doch sollte dies nicht ohne Abstimmung mit dem Auftraggeber erfolgen, deshalb ist es üblich dass das Pflichtenheft auch vom Auftraggeber gegengezeichnet und somit Vertragsbestandteil wird (der Auftraggeber bezahlt ja auch für die Erstellung des Pflichtenhefts). Zusammenfassend kann also gesagt werden, dass neben den formellen Verantwortlichkeiten für die Dokumente, ohne enge Abstimmung und beiderseitigem Mitwirken von Auftraggeber und Auftragnehmer nur selten ein für beide Seiten zufriedenstellendes Lasten- und Pflichtenheft erstellt wird, was letztendlich die Basis für die Qualität der Umsetzung ist.

Klar kann es da eine gegenseitige Abstimmung bei der Erstellung dieser Dokumente geben. Auch der Zeitablauf (Dokumente vor den Produkten und nicht andersrum) entspricht nicht immer der reinen Theorie. Aber am wichtigsten ist zunächst die prinzipielle Zuordnung Lastenheft vom Auftraggeber und Pflichtenheft vom Auftragnehmer. Das muss der Artikel zuvorderst herausstellen, um beim ggf. uninformierten Leser Klarheit zu schaffen. Sonst wäre er wohl nur verwirrt. Erst im zweiten Schritt, wenn man in Details geht, kann man auf die praktischen Aspekte eingehen, dass die Grenzen im wirklichen Leben bis zu einem gewissen Grade verwischen könenn. --PeterFrankfurt 16:22, 21. Mai 2008 (CEST)


In der Raumfahrt stimmt deine Logik nicht; dort gibt es die "reqmts. specification" vom Auftraggeber und die "design-to specification" (manchmal auch "implementation specification" genannt) als Antwort vom Auftragnehmer. Parallel definiert das vom Auftraggeber erstellte "statement of work" WIE die Entwicklung durchgeführt werden soll (welche Dokumente zu erstellen sind usw).
Bei deutschen Raumfahrtprogrammen gab es manchmal nur eine "reqmts. specification" genannt Lastenheft vom Auftraggeber und das "statement of work" genannt Pflichtenheft.
Wie heisst denn das "statement of work" in deinem Konzept?Hjpospie 16:31, 23. Mai 2008 (CEST)
Das glaube ich gerne, dass es da in verschiedenen Bereichen der Industrie mehr oder weniger abweichende Verfahren gibt. Ich kenne das aus der Automobilzuliefererindustrie. Dort scheint es einen Übergang zu geben von dem althergebrachten Schema Lastenheft-Pflichtenheft hin zu Lastenheft-Requirementsmanagement. Parallel dazu wird dann immer noch ein Pflichtenheft erstellt und das heißt auch gut deutsch so (obwohl da in manchen Bereichen auch schon Amtssprache Englisch verwendet wird), aber das ist wohl nur noch übergangsweise Doppelmoppelei. Es scheint Richtung pure Requirements zu gehen, diese Einschätzung aber ohne Gewähr und ohne konkrete Zeitvorstellungen. --PeterFrankfurt 22:49, 23. Mai 2008 (CEST)
Okey aber ich verstehe immer noch nicht, in welchem Dokument die "statement of work" Anforderungen (wie oft muss welcher Bericht geliefert werden usw) bei der Autoindustrie stehen. - Hjpospie 12:52, 24. Mai 2008 (CEST)
Keine Ahnung, bei uns hat es ein "statement of work" noch nie gegeben. Die Vorgehensweise ist offensichtlich langfristig miteinander vereinbart und wird nicht immer neu in Dokumenten festgelegt. --PeterFrankfurt 23:12, 24. Mai 2008 (CEST)

überarbeiten

  • Das Pflichtenheft, auch Technische Richtlinien, Fachspezifikation, fachliche Spezifikation, Fachfeinkonzept, Sollkonzept, Funktionelle Spezifikation, oder Feature Specification beschreibt die unmittelbaren Anforderungen durch den Besteller in der Interpretation des Herstellers für sein Produkt.
    • 1) ganz schön viele Synonyme werden da angeboten. Die meisten halte ich für fraglich und würde besser zu Fachkonzept passen. Einen hätte ich noch anzubieten: Implementierungsspezifikation.
    • 2) statt durch den Besteller wäre wohl des Bestellers eindeutiger.
  • Es enthält jedoch lediglich im Rahmen eines Werkvertrages oder Werkliefervertrages und der dazu gehörenden formellen Abnahme die prüfbaren Leistungen und Lieferungen Was bedeutet lediglich? Ein Pflichtenheft ist die Spezifikation der Anforderungen. Diese müssen eindeutig sein.
  • Es kann, genauso wie das Lastenheft, nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten. Solche abstrakten Merkmale wären, wenn nicht durch eine Prüfung oder Messung zu belegen, durch denjenigen, der das Produkt herstellt, auch eher nicht so einzuschätzen, dass sie zielführend während der Bearbeitung des Werkes und final bei der Abnahme berücksichtigt werden könnten. Was soll das Gesülze?
  • Die Inhalte des zuvor ausgearbeiteten Lastenhefts (auch grobes Pflichtenheft genannt) sind nun präzisiert, vollständig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft. Halte ich für groben Unfug. Lastenheft ist ein Lastenheft und kein grobes Pflichtenheft. Es muss alle Anforderungen von der Seite des Abnehmers enthalten. Pflichtenheft ist keine Präzisierung oder Vervollständigung der Anforderungen sondern die Umsetzung der Anforderungen. Das macht das Dokument dicker.
  • Im Gegensatz zum technischen Design (auch technische Spezifikation – Wie wird es umgesetzt?) beschreibt das Pflichtenheft die geplante technische Lösung – in unserem Beispiel die Software – als Black Box (Was wird umgesetzt?). Zum Teil falsch, zumindest unverständlich. Das Lastenheft beschreibt als Black Box, was umgesetzt wird. Das Pflichtenheft wie es umgesetzt wird. Vielleicht kommt aufgrund von Komplexität, dass das Pflichtenheft in einer hohen Abstraktionsebene bleibt und weitere Dokumente, hier die technische Spezifikation, die Details regeln. Zu dem seltsame Sprache in unserem Beispiel die Software
  • Es ist bewährte Praxis, bei der Erstellung eines Pflichtenheftes das Ein- und Ausschlussprinzip zu verwenden, d. h., konkrete Fälle explizit ein- oder auszuschließen. unverständlich
  • Bei Lieferung der Software wird formell eine Abnahme vollzogen, die die Ausführung des Werkvertrages oder auch des Kaufvertrages beschließt. Diese Abnahme wird häufig über einen Akzeptanztest ausgeführt, der feststellt, ob die Software die Forderungen des Pflichtenheftes in dem Verständnis des Bestellers erfüllt. Irgedwei wirkt der Abschnitt hier fehl am Platz.

--Avron 08:40, 23. Jul. 2008 (CEST)

Pflichtenheft und Lastenheft sind typisch deutsche Bezeichnungen und resultieren aus dem V-Modell, und werden heutzutage teilweise gar nicht mehr verwendet. Die entsprechende englische Bezeichnung ist Software_Requirements_Specification. Es ist ziemlich müßig hier sämtliche Bezeichnungen aufzulisten, hier gibt es kein richitg oder falsch, da jedes Unternehmen seine eigenen Richtlininen und Namenskonvention hat, die i.d.R. nur intern bekannt sind. Alles was hier in diesem Artikel von der V-Modell [1] Spezifikation abweicht (der Name heißt in V-Modell XT auch Gesamtsystemspezifikation (Pflichtenheft)) ist rein unternehmensspezifisch --thomasxb 21:11, 15. Aug. 2008 (CEST)
Ähm, Pflichtenheft und Lastenheft sind älter als das V-Modell und beziehen sich nicht nur auf die Softwareentwicklung. Deswegen halte ich einen Teil deiner Änderungen für falsch.-- Avron 00:13, 16. Aug. 2008 (CEST)
Das V-Modell beinhaltet sowohl Software-, als auch Hardwareanteile. Die einzig mir bekannte eindeutige Definition dieser Begriffe ist im V-Modell 97 verankert. Welchen Standard würdest Du hier als verbindlich ansehen? Wie zuvor auch schon gesagt, hat sich jedes Unetrnehmen seine eigene Definition zusammengebastelt, und je nach dem neue Teile dazugefügt oder gestrichen; so daß man hier sehr aufpassen muß, die Sache allgemeingültig zu beschreiben. Ich hätte den Artikel jetzt noch soweit angepaßt, daß er das Pflichtenheft lt. V-Modell widerspiegelt - lasse mich aber gerne eines anderen belehren. Im übrigen hat bei uns in der Firma schon lange keiner mehr diesen Begriff verwendet, da heißt es dann immer neudeutsch "User Requirements" --thomasxb 10:37, 16. Aug. 2008 (CEST)
Pflichtenheft und Lastenheft sind Dokumnte bei allgemeinen Ausschreibungsverfahren also auch Bauwesen, Maschinenbau usw. Die Bezeichnungen werden mitnichten ausschliesslich für Softwareentwicklung verwendet. Wie ich schon geschrieben habe, sind diese Begriffe älter als das V-Modell. Die Begriffe werden auch in DIN 69905 definiert, wo es um allgeimne Projekte geht.-- Avron 13:40, 16. Aug. 2008 (CEST)

Das sieht für mich jetzt so aus, als sollte das Pflichtenheft als Teil/Unteraspekt des V-Modells angesehen werden. Das trifft es aber wohl nicht. Der Lastenheft-/Pflichtenheft-Mechanismus ist das "Protokoll" der Abwicklung eines Entwicklungsauftrags zwischen Auftraggeber und Auftragnehmer, völlig unabhängig vom Schema, nach dem die Entwicklung am Ende durchgeführt wird. Ob das nach V-Modell oder sonstwie (beim Programmieren gibt's ja noch Extreme Programming u.v.a.m.) geschieht, ist für die Erläuterung des Pflichtenhets unerheblich. Demnach sollte das V-Modell nicht im Vordergrund stehen, sondern höchstens als eine von mehreren Möglichkeiten erwähnt werden, die eigentliche Entwicklungsarbeit im Rahmen des übergeordneten Lastenheft-/Pflichtenheft-Mechanismus zu organisieren. --PeterFrankfurt 21:59, 16. Aug. 2008 (CEST)

Nun habe ich den Artikel umgeschrieben und einiges gestrichen.-- Avron 16:02, 17. Aug. 2008 (CEST)

Ich habe die "alternativen" Bezeichnungen entfernt weil:

  • Technische Richtlinien: eine Richtlinie kann kein Pflichtenheft sein
  • Fachspezifikation, fachliche Spezifikation, Fachfeinkonzept, Funktionelle Spezifikation oder Feature Specification: damit ist eher ein Fachkonzept gemeint
  • Sollkonzept: damit ist eher ein Fachkonzept bzw. Lastenheft gemeint

Natürlich werden die Begriffe verwendet. Der Artikel legte nahe, dass diese Begriffe Synonyme sind, was sie aber nicht sind. Eine Lösung habe ich bereits genannt: für jeden dieser Begriffe eine BKL anlegen.--Avron 08:39, 18. Aug. 2008 (CEST)

Um Gottes Willen, das nicht auch noch. Es ist doch absolut unnötig, für jeden einen eigenen Artikel oder BKL aufzumachen. Ich habe nur in den langen Diskussionen mitbekommen, die sich schon Jahre hinziehen, dass immer wieder Leute mit anderem Hintergrund - von einer anderen Uni, aus einer anderen Firma - kommen, wo wieder ein anderer Sprachgebrauch gepflegt wird. Auch in Fachbüchern wird dieser Wildwuchs anscheinend weitergeführt. Ich finde nicht, dass wir da autoritär entscheiden dürfen, was Unsinn und was erwähnenswert ist (nur Lastenheft an dieser Stelle wäre daneben). Die einfache Erwähnung der anderen Begriffe relativ weit vorne halte ich für die beste Lösung. Dann ist das abgehakt und muss nicht noch mehr Aufwand verursachen. Denn Bedeutungsvarianten unter diesen Begriffen zu diskutieren, fände ich wiederum übertrieben, weil eben auch das wieder variieren dürfte, wo man dann endgültig vom Hölzchen aufs Stöckchen kommen würde, und das würde niemandem dienen. --PeterFrankfurt 00:40, 19. Aug. 2008 (CEST)
Warum ich die Begriffsliste eher vorn als z. B. bei Siehe auch sehen möchte: Jene Leute mit anderem Hintergrund werden nach dem ihnen geläufigen Begriff suchen, und wenn der ihnen nicht auf den ersten Blick (also irgendwo oben) in Fettschrift ins Auge fällt, werden sie irrtümlicherweise annehmen, im falschen Artikel gelandet zu sein, und sie werden wieder wegklicken. Solche ganz praktischen Erwägungen zum User-Interface sind immer sehr wichtig. --PeterFrankfurt 00:47, 19. Aug. 2008 (CEST)
Gut ich habe den Begriffswirrwarr wieder reingenommen. Allerdings nicht Technische Richtlinie das erscheit mir dann doch zu abwegig. Und auch nicht in Fettschrift, weil das in der Regel einen wirklich synonymen Begriff signalisiert. Mit der dazugestellten Erklärung sollte das jetzt halbwegs passen.--Avron 08:20, 19. Aug. 2008 (CEST)

Da sich einiges zum positiven getan hat -> überarbeiten raus.--Avron 08:40, 19. Nov. 2008 (CET)

Link: Braunbuchbeschreibungen vom Institut für Rundfunktechnik IRT

Was hat der Link mit Pflichtenheften zu tun? Das sind doch nur Beschreibungen von vorhandenen Gerät. --Mühsam 12:13, 20. Jun. 2011 (CEST)

Nichts, deswegen ist nun weg.--Avron 10:39, 21. Jun. 2011 (CEST)

Verbesserte Einleitung bitte

Ich kenn mich im Prozedere nicht aus, aber könntet Ihr eventuell eine bessere Einleitung Schreiben. Einen Fachbegriff mit einem anderen zu erklären halte ich für wenig hilfreich. Es wäre nett, schon kurz am Anfang zu erfahren, wozu ein Pflichtenheft dient. Ich danke Euch! -- 89.204.152.53 00:36, 28. Okt. 2011 (CEST)

Ursprüngliche Einleitung:

  • Das Pflichtenheft beschreibt in konkreterer Form, wie der Auftragnehmer die Anforderungen im Lastenheft zu lösen gedenkt – das sogenannte wie und womit.

Einleitung von Benutzer:PeterFrankfurt Das Pflichtenheft ist der zweite Schritt, wenn ein Auftragnehmer ein Produkt für einen Auftraggeber entwickeln und/oder produzieren soll. Im ersten Schritt beschreibt der Auftraggeber im Lastenheft möglichst präzise, was er entwickelt/produziert haben möchte. Da der Auftragnehmer in manchen Details evtl. leicht abweichende Lösungen bevorzugt, beschreibt er seinerseits konkret in Form des Pflichtenhefts, wie er die Anforderungen zu lösen gedenkt – das sogenannte wie und womit. Erst wenn der Auftraggeber diese ggf. abweichende Variante abgesegnet hat, sollte die eigentliche Arbeit beim Auftragnehmer starten.

Ich weiss nicht genau was der IP nicht versändlich ist, das sollte man nachfragen. Allerdings ist die Einleitung von Peter nicht haltbar. Der Erste Satz ist seltsam bis unverständlich; "der zweite Schritt" von was? Auf Seite des Auftraggebers können schon mehrere Schritte gelaufen sein z. B. Projektdefinition, Projektstudie, Lieferantenvorauswahl, usw... Besonders die "abweichende Lösung" ist einfach falsch. Vom Prinzip her sind die Anforderungen im Lastenheft Lösungsfrei, d.h. nur die fachlichen Anforderungen. Da Lastenheft/Pflichtenheft ein Wasserfallmodell sind, bezieht sich das Pflichtenheft immer auf das Lastenheft. Wie gesagt, wir können natürlich gerne über Allgemeinverständlichkeit reden.--Avron 08:15, 28. Okt. 2011 (CEST)

Meine Formulierung war aus dem Handgelenk und ist nicht in Stein gemeißelt. Das kann man gerne weiter überarbeiten. Aber das Anliegen der IP fand ich schon berechtigt: Die lakonische Kürze der vorherigen Formulierung hilft nicht so arg, weil man u. a. notwendigerweise zwischendurch bei Lastenheft nachlesen muss, was das nun wieder sein soll. - Das mit dem "zweiten Schritt" bezieht sich auf 1. Lastenheft des Auftraggebers (ohne dessen Zustandekommen jetzt an dieser Stelle unnötigerweise weiter aufzudröseln, dazu ist woanders Platz genug), dann 2. Pflichtenheft des Auftragnehmers; das ist in der Tat etwas schludrig. - Und ja, die Ausgestaltung im Pflichtenheft kann auch Abweichungen von den Vorgaben des Lastenhefts enthalten: Wenn der Auftraggeber damit einverstanden ist, ist es ja ok, es finden ja auf jeden Fall noch Verhandlungen (oder simpler Gespräche) statt. --PeterFrankfurt 01:03, 29. Okt. 2011 (CEST)

Veraltete Balzert-Quelle

Die gute Nachricht ist: Es wurde auf die relativ seriöse Quelle H. Balzert bezug genommen. Die schlechte Nachricht: In der aktuellen Auflage (2009) hat Balzert einen wesentlich anderen Vorschlag / andere Vorlage für ein Pflichtenheft. Ich würde die aktuellere Quelle bevorzugen.--AlbrechtEhlert (Diskussion) 11:55, 15. Nov. 2012 (CET)

Es ist eigentlich ganz einfach

Alle diese Diskussionspunkte hier sind wohl von Leuten geschrieben worden, die noch nie ein Grossprojekt geleitet haben, zumindest nicht in der internationalen Raumfahrt.

Zusammenfassung:

a) Auftraggeber schreibt Requirements Specification "Was soll das zu liefernde Produkt technisch leisten" (Deutsch: Lastenheft). Beispiel: Satellit soll mit Ariane in 400 km Orbit gebracht werden, Betriebszeit 10 Jahre usw.

b) Auftraggeber schreibt Statement of Work "WIE soll das zu liefernde Produkt entwickelt werden" (Deutsch: Pflichtenheft). Beispiel: Alle Dokumente sollen in Englisch geliefert werden, Auftraggeber muss alle Testprozeduren freigeben usw.

c)Auftragnehmer antwortet auf a) mit Implementierungsspezifikation "Der Satellit soll ein Zylinder mit 1,5 m Durchmesser sein, hat Richtantenne mit 13 db Gewinn usw. (Deutsch: kein equvalenter Begriff)

d)Auftragnehmer antwortet auf b) mit Plänen: Design und Development Plan, Fertigungsplan usw.


Leider versuchen verschiedene Parteien (z.B. ESA gegen CNES) und Leute (wer lehrt heute nicht überall Systems engineering ...) immer wieder eigene Definitionen und Interpretationen auf diesem Gebiet einzubringen und machen es daher speziell Newcomern schwer, diese Prinzipien zu verstehen.--Hjpospie (Diskussion) 12:54, 12. Dez. 2012 (CET)

Wie ich dir schon bei Diskussion:Lastenheft#Aufbau.2FGliederung geantwortet habe; das mag für die Raumfahrt gelten (anscheinend ist man sich nicht mal da einig, so wie ich dich versanden habe); DIN definiert das anders: Auftraggeber schreibt Lastenheft, Auftragnehmer antwortet mit Pflichtenheft.--Avron (Diskussion) 20:42, 12. Dez. 2012 (CET)
Du hast anscheinend recht für Deutschland, wenn man die DIN zugrunde legt. Sie basiert wohl auf IT /Software Projekten wie man aus den vielen Erläuterungen und Beispielen ableiten kann; sie wurde dann verallgemeinert, ohne sie sauber an andere Systeme (z.B. DoD) anzugleichen. Das amerikanische System ist eindeutig klarer und strikter und wird international meistens eingesetzt. Können wir uns also hier darauf einigen, dass meine "Übersetzungen" der Begriffe Pflichtenheft->statement of work und Lastenheft->specification nicht zutreffend ist (obwohl die Begriffe beim ersten deutschen Satelliten Azur so benutzt wurden)?
Im Rahmen der Globalisierung sollte ein deutscher Systems Engineer aber auch mit den internationalen Definitionen umgehen können aber leider wird an den meisten Unis praktisch nichts über dieses Thema gelehrt. Vielleicht gibt unsere Diskussion hier ja jemandem einen Denkanstoss.--Hjpospie (Diskussion) 13:34, 14. Dez. 2012 (CET)

Bullshit

Das ist ein typisches Beispiel, wie sich Inhalte ohne Beleg lange in der WP halten ohne kritisch hinterfragt zu werden:


== Ganzheitliches Pflichtenheft ==

Ein ganzheitliches Pflichtenheft besteht nicht nur aus technischen, sondern auch aus 
marktwirtschaftlichen und ökologischen Anforderungen. Dabei sind Herstellung, Gebrauch 
und Beseitigung des Produktes einzubeziehen, mit den Auswirkungen auf Boden, Wasser 
und Luft. Diese Checkpoints sind übersichtlich im [[Bilanzierungswürfel]] dargestellt, 
der bei der Kontrolle auf Vollständigkeit des ganzheitlichen Pflichtenheftes hilft.

  1. Quelle fehlt.
  2. "Anforderungen" haben im Pflichtenheft nichts zu suchen. Wie der Artikel ja versucht zu erklären. Hier geht es um Lösungen.
  3. "Herstellung, Gebrauch und Beseitigung des Produktes" hilft nur bei physischen Produkten weiter.
  4. Der verlinkte Artikel "Bilanzierungswürfel" wurde x-fach gelöscht (kein Artikel / Unsinn)
  5. Was denn eigentlich für "Checkpoints"? Auch Bullshit.
  6. "Kontrolle auf Vollständigkeit" nochmals Bullshit. Aus wirtschaftlichen Gründen wird ein Pflichtenheft niemals abschließend vollständig sein, sondern nur so weit aufgebaut bis ein Konsens über das Konzept erreicht ist. Vollständigkeit ist gar nicht das Ziel, zumal sonst definiert werden müsste, wer denn die Kriterien einer Vollständigkeit festlegt.

Wie hält sich denn sowas über Jahre hinweg in der WP? Peinlich. --Hamburger (Disk) 18:00, 10. Apr. 2013 (CEST)

überarbeitungswürdig

Entsetzlich, wenn man das liest...und die Diskussion dazu erst! Der ganze Artikel ist sowas von völlig überarbeitungswürdig, da weiß man garnicht, wo anfangen! Auf jeden Fall ist jedem beim Lesen dieser Diskussionsseite klar, warum IT-Projekt so oft so kläglich scheitern! Also wenn Hr. "WhiteCrow" lehrt, das ein Lastenheft vom Auftragnehmer geschrieben wird, dann äußere ich ernsthafte Zweifel am deutschen Bildungssystem! Die armen, armen Studenten, die können einem nur noch leid tun! Ich schreibe mir meine Anforderungen selber und gleich noch hinterher, wie ich das umzusetzten gedenke, und dann unterschreibe ich wahrscheinlich auch noch den Auftrag selber und ach, weil's grad passt, die Abnahme gleich mit...na..merkt Ihr was?

Aber warum wird hier überhaupt endlos über die Selbstverständlichkeiten und die totalen Grundlagen diskutiert? Wohl weil am Lehrstuhl wahrscheinlich gerade nichts los ist und bis Feierabend ist ja noch ein Weilchen ;-) @WhiteCrow: Behalte mal dein offensichtlich völlig unqualifiziertes und zudem gefährliches Halbwissen für Dich. Es reicht, wenn deine Studenten DAS lernen müssen. Furchtbar, wenn ich mir das vorstelle, und die sollen dann in's Berufsleben entlassen werden...man o man Aber jede Wette: Gleich wird auf meinem Kommentar rumgehackt...und wie der so schreibt..und der soll sich erstmal anmelden, immer diese IP-Comments...und überhaupt, soll der sich wenn dann richtig beteiligen.. kann doch den Artikel überarbeiten...bla bla bla (tu ich aber nicht, da mir mir schlicht die Zeit fehlt, hier Basics über die Natur der Säge zu schreiben, anstatt über die Sägetechnik. Es würde im im übrigen schon reichen, wenn einfach mal nur die Nutzer einen Artikel bearbeiten, die auch wissen wovon sie reden). Ach, das Nerding ist so berechenbar... (nicht signierter Beitrag von 84.19.197.83 (Diskussion) 12:35, 31. Aug. 2012 (CEST))

Hallo Gast, es ist immer eine einfache Option, an einem bestehenden Artikel harsche Kritik zu üben. In diesem Fall stimme ich zu, dass der Artikel deutlich verbesserungswürdig ist. Deshalb WP:Sei mutig und reiche Vorschläge ein. Seit deinem Beitrag ist ja einige Zeit vergangen, vielleicht sind dir ja mittlerweile Ansätze eingefallen. Btw, ich hab die Heading mal gekürzt zwecks besserer Übersicht im TOC. Schöne Grüße, --Hamburger (Disk) 20:43, 10. Jun. 2013 (CEST)

Übersetzungen

Obwohl die Einleitung den Unterschied zwischen Lastenheft und Pflichtenheft klar definiert, finde ich es schwer, die Begriffe zu übersetzen. Tipps? ScotXW (Diskussion) 17:45, 21. Okt. 2013 (CEST)

In was für eine Sprache? Es kann sein dass eine genaue Entsprechung nicht gibt.--Avron (Diskussion) 11:29, 23. Okt. 2013 (CEST)

Andere Sprachregelung im Bauwesen?

Mein Bruder ist seit vielen Jahren in Baubegleitung bei größeren Wohnprojekten aktiv. Er sagt mir, dass dort das, was wir hier Lastenheft nennen, Pflichtenheft heißt. Er hat mir auch ein Beispiel gezeigt, wo ich dummerweise keine Gelegenheit hatte, es zu dokumentieren. Kennt sich da jemand über solche babylonischen Verhältnisse aus? S. a. oben mit der Raumfahrtindustrie. Schauder. --PeterFrankfurt (Diskussion) 03:39, 24. Okt. 2013 (CEST)

Zusammenhang? =

Was hat denn ein allgemeines Pflichtenheft mit einer softwareprojekt-spezifischen Software Requirements Specification am Hut?! (nicht signierter Beitrag von 62.95.79.73 (Diskussion) 13:16, 2. Feb. 2015 (CET))

Pflichtenheft ist vom Auftraggeber zu liefern und Schluss

Oje, oje - hier hat es einer immer noch nicht verstanden. Das Pflichtenheft wird vom AuftragGEBER geliefert!!! (nicht signierter Beitrag von Hjpospie (Diskussion | Beiträge) 18:09, 24. Nov. 2014 (CET))

Dass du deine Meinung hier mit viel Pathos vorträgst, ist fein, aber lies doch deine eigenen Worte bitte noch mal genau nach. Du widersprichst dir selber. --Hamburger (Disk) 23:27, 24. Nov. 2014 (CET)
Nach VDI-Richtlinie 3694 erstellt der Auftragnehmer das Pflichtenheft unter Beachtung der im Lastenheft genannten Anforderungen an das Automatisierungssystem. Dirk Kossmann (Diskussion) 17:09, 29. Dez. 2015 (CET)