Diskussion:Lastenheft

nach din 69905 muss das lastenheft aber einer bestimmten form entsprechen

oben

Ein Pflichenheft muss dem Kunden/Auftraggeber nicht unbedingt vorgelegt werden. Oft will der Kunden/Auftraggeber gar nicht im Detail wissen wie etwas realisiert wird. Beispiel: Ich sage dem Malermeiser, dass meine Hausfasade gelb gestrichen werden muss (Lastenhesft). Ob der Malermeister sie mit einem Pinsel oder mit einer Rolle streicht ist mir egal (Pflichenheft). Bei großen Aufträgen Anlagen/Software werde nach der Ausschreibung UmsetzungsKONZEPTE (und Referenzen) eingereicht. Ein Pflichenheft wäre zu viel. -- 87.123.94.96 21:10, 16. Mai 2012 (CEST)

genau

Die Formulierung in natürlicher Sprache ist einfach schlecht (ggü. der Modellierung), auch wenn das evtl. in irgendwelchen Vorschriften steht.

"Die Anforderungen in einem Lastenheft sollten durch ihre Formulierung so allgemein wie möglich und so einschränkend wie nötig formuliert werden." - Ey jetzt mal ehrlich hebt das eine das andere nicht auf?

Eigentlich nicht. Man kann eine Anforderung zu allgemein spezifizieren. Der Implementierer weiss dann nicht worauf es dem Auftraggeber ankommt.
Man kann eine Anforderung aber auch zu konkret spezifizieren. Der Implementierer ist dann zu stark eingeschränkt fuer eine optimale Loesung.
Das statement beschreibt diese Balance zwischen allgemein <-> konkret. (nicht signierter Beitrag von 192.25.10.8 (Diskussion | Beiträge) 13:31, 7. Okt. 2009 (CEST))

Genauso könnte man pauschal sagen die Formulierung mit graphischen Sprachen ("Modellierung") ist einfach schlecht. Was einfach gut ist, ist erst nach Review und Gusto der Rezipienten etwas klarer. Bei einem großen Rezipienten Kreis gelten die in der Fachdomäne anerkannten Repräsentationsformen. --91.65.213.154 15:02, 23. Feb. 2022 (CET)

bähm

Siehe z.B. Trade-off... --wizzar 23:17, 1. Feb. 2009 (CET)

Solte ein Lastenheft nicht so präzise wie möglich verfasst werden? Einen genau Umschreibung dessen was der Auftragsnehmer haben möchte, minimiert meiner Ansicht nach das ünnötig Ressourcen vernichtet werden weil aufgrund einer zu schwammigen Zeilsetzung, nicht Zielgerichtet gearbeitet wurde. (nicht signierter Beitrag von 31.18.66.153 (Diskussion) 13:26, 21. Mär. 2013 (CET))

Ein Lastenheft sollte so präzise sein, wie man die Umsetzung erwartet. Beispiel aus der Softwareentwicklung: Es soll eine Tabelle mit einigen Spalten ausgegeben werden. Wenn einem die Breite der Spalten wichtig ist, sollte man diese auch spezifizieren. Wenn einen die Breiten nicht so wichtig sind, kann man auf den gesunden Menschenverstand des Entwicklers vertratuen; das wird in der Regel gutgehen, aber manchmal auch nicht.--Avron (Diskussion) 17:53, 21. Mär. 2013 (CET)

Deutsche Sprache bei Columbus Projekt

Sollte die Punktliste dort nicht besser deutschsprachig sein?

Die Liste ist aus der Original Columbus-Spezifikation, die in Englisch geschrieben ist. Eine Übersetzung halte ich nicht für notwendig, da normalerweise alle etwas tiefer gehenden fachlichen Artikel zur Raumfahrt in der Literatur in Englisch sind.Hjpospie 16:32, 29. Nov. 2007 (CET)

Balzert

finde die detailierten Ausführungen zu Balzert Punkt 7 und 8 überflüssig und unausgewogen ggü. den anderen teilweise wichtigeren Punkten bei denen nichts steht. Evtl Pkt 7/8 löschen?

Die Quelle Balzert halte ich für relativ seriös. Was ich zu bemängeln habe ist, dass diese veraltet ist. Es gibt das Buch von Balzert inzwischen aus dem Jahr 2009. Dort hat er die Vorlage für ein Lastenheft stark verändert.--AlbrechtEhlert (Diskussion) 12:50, 15. Nov. 2012 (CET)

Angegebenes Beispiel eines Lastenheftes möglicherweise fehlerhaft

Das Beispiel eines Lastenheftes, was unter http://www.stefan-baur.de/downloads/Lastenheft.pdf zu finden ist und indirekt über den Artikel verlinkt wurde, enthält möglicherweise folgende(n) Fehler:

• S.14: Ein Kapitel "Realisierung" gehört nicht ins Lasten- sondern ins Pflichtenheft.

--Sternenfaenger 16:54, 14. Sep 2006 (CEST)

M.Capraro: Grundsätzlich ist die Realisierung tatsächlich sache des Pflichtenheftes. In diesem Fall ist aber eher "Anforderungen an die Realisierung" gemeint. Das heißt bestehende Vorgaben zu ggf. zuverwendenden Technologien. Oder irre ich da? (nicht signierter Beitrag von 84.184.181.232 (Diskussion) 16:29, 11. Dez. 2010 (CET))

HPW: Angabe "Realsierung mittels PHP und MySQL" ist im Lastenheft vollkommen richtig. Es handelt sich hier um eine Einschränkung bzw. eine infrastrukturbedingte Vorgabe. Wenn eine Einschränkung nicht erfolgt, ist eine Umsetzung z. B. via ASP.NET möglich, aber für den Auftraggeber nicht nutzbar. (nicht signierter Beitrag von 194.138.39.56 (Diskussion) 11:54, 17. Dez. 2010 (CET))

Nichtfunktionale Anforderungen

- ...
- Funktionalität
- ...
Hä? Seit wann ist Funktionalität eine nichtfunktionale Anforderung? Ich fürchte, das wurde einfach von der englischen Seite übernommen. Meiner Meinung nach gehört das ersatzlos gestrichen. Wenn damit Verfügbarkeit gemeint ist, sollte das auch so da stehen.

Raumfahrt

Der halbe Artikel dreht sich um die Raumfahrt, das liest sich sehr seltsam und unausgeglichen. --A.Hellwig 12:56, 28. Jun. 2007 (CEST)

Das liegt wohl daran, dass in der Raumfahrt Inhalte, Benutzung usw. am besten definiert sind. Dort wird klar zwischen Lastenheft (= specification) und Pflichtenheft (= statement of work) unterschieden. In der Software-Welt wird leider immer wieder eine unnötige Diskussion um Änderungen des Prinzips initiiert. Hjpospie 16:27, 7. Jul. 2007 (CEST)

Ersteller des Lastenheftes

"In der Softwaretechnik ist das Lastenheft das Ergebnis der Planungsphase und wird in der Regel von den Entwicklern als Vorstufe des Pflichtenhefts erarbeitet."

Das Lastenheft wird vom AuftragGEBER erstellt, nicht von den Entwicklern. Auf welcher Basis sollen die Entwickler es denn auch erstellen?

In der Softwaretechnik gibt es (leider) immer wieder Ungereimtheiten, da etwas Neues definiert wird obwohl bereits erprobte Prozesse und Definitionen vorhanden sind.

Also nochmal:

• Das Lastenheft beinhaltet die Anforderungen an das zu liefernde Produkt. Es wird erst vom Auftraggeber als "requirement spec" erstellt.
• In der folgenden Phase antwortet der Auftragnehmer mit einem detaillierten Lastenheft ("design to spec").
• Das Pflichtenheft wird vom Auftraggeber erstellt und definiert die vom Auftragnehmer durchzuführenden Arbeiten (Statement of Work). Der Auftragnehmer antwortet darauf in seinem Angebot mit einem Entwicklungsplan (Design and Development Plan), der die durchzuführenden Arbeiten detailliert (z.B. Verteilung auf Unterauftragnehmer, eingesetzte Anlagen).

Hjpospie 16:46, 29. Nov. 2007 (CET)

Ich würd' mal sagen, das ist der Unterschied zwischen Theorie und Praxis. Viele "Auftraggeber" sind zu faul, selbst ein Lastenheft auszuarbeiten (v.a. bei kleineren/hausinternen Projekten, die nicht erst groß "ausgeschrieben werden"). Man macht ein Meeting, Fachmensch und Softwareentwickler, der Entwickler selbst schreibt das Lastenheft, der Fachmensch/Auftraggeber überfliegt es, ändert 2-3 Punkte, und nickt es ab.

Dann erstellt der Entwickler das Pflichtenheft, das der Auftraggeber auch nochmal querließt (oder nicht), usw.

Dat nennt sich "Realität". --129.247.247.239 16:33, 22. Mär. 2012 (CET)

Das ist wohl die Realität für ein Mickey-Mouse-Projekt aber nichts Grosses, wo die Software wie jedes andere Teil in ein Spezifikationssystem eingebunden ist.-- Hjpospie (Diskussion) 13:37, 14. Mai 2012 (CEST)

--84.19.197.83 13:12, 31. Aug. 2012 (CEST):::@Hjpospie: Danke, endlich mal mal einer der's echt begriffen hat. @IP: Das ist wohl der Grund warum deine Projekte so laufen, wie sie laufen. Und wie sie laufen, das kann ich mir sehr gut vorstellen..die berühmten never ending stories

Der Auftraggeber erstellt NIEMALS das Pflichtenheft. Siehe auch entsprechenden Artikel hier bei Wikipedia: "Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt..." --85.199.68.80 12:23, 10. Sep. 2021 (CEST)

Das stimmt vielleicht bei Kleinprojekten. Bei grossen Projekten z.B. mit dem NASA oder ESA schreibt der Auftraggeber die vertragliche Spezifikation und der Auftragnehmer antwortet mit der detaillierten Design-to-Spec (manchmal auch einfach Design Spezifikation genannt), die der Auftraggeber unterschreibt. Leider wird in Deutschland vieles neu erfunden und speziell die Softwaregemeinde denkt es gibt nur Software; wirkliche Systeme beinhalten Hardware und Software; und die ist auf niedriger Ebene eingebunden und muss wie jedes andere Teilsystem alle Regeln und Anforderungen erfüllen. --Hjpospie (Diskussion) 12:06, 10. Sep. 2023 (CEST)

Erwartungen und Wünsche

Der Satz im Anfang des Artikels "Es kann nicht die Erwartungen und Wünsche an ein geplantes Produkt enthalten." ist irrelevant und sollte entfernt werden. Man kann nicht alles auflisten, was nicht in einem Lastenheft enthalten sein soll, es sei denn in Abgrenzung zu einem anderen Dokument wie zum Beispiel dem Pflichtenheft.Hjpospie 15:51, 19. Feb. 2008 (CET)

Columbus Projekt APM Spezifikation

Im Artikel steht unter dem Columbus- Beispiel bei Punkt 2: Para 1. Scope: Purpose, Summary Description, Classification, Applicability) ..da fehlt scheinbar eine öffnende Klammer, oder ist die schließende Klammer zu viel? --MichaV 20:38, 27. Apr. 2008 (CEST)

Fehler korrigiert.

Hjpospie 13:10, 18. Mai 2008 (CEST)

Hier wird vielmehr die Implementierungsspezifikation also Pflichtenheft beschrieben. --Avron 08:13, 23. Jul. 2008 (CEST)

Nein, das Pflichtenheft ist NICHT die Implementierungsspezifikation (siehe Kommentar zum nächsten Abschnitt) Hjpospie 10:43, 17. Nov. 2008 (CET)

Hier ist das NASA Dokument. [1] Bitte als Quelle mit Seite referenzieren. -- Avron 21:02, 23. Jul. 2008 (CEST)

Was soll diese Referenz denn verbessern? Hjpospie 10:43, 17. Nov. 2008 (CET)

Aufbau/Gliederung

Da hat jemand die Abschnitte im Dokument verschlimmbessert. Hier war es, meiner Meinung nach, noch richtig :[2]

--Avron 10:56, 23. Jul. 2008 (CEST)

Ich kann dem nur zustimmen, dieser Artikel war schon mal besser (aber nicht in der von Avron genannten Ref.Version). Der Artikel berücksichtigt in der jetzigen Version wieder nur Software / Informatik und nicht die für Entwicklung umfassender Systeme benutzte Vorgehensweise. Die von Balzert definierten Begriffe sind nur für die Entwicklung reiner Software Systeme gültig (und auch nur dafür hat Balzert Erfahrungen). Speziell in der Luft- und Raumfahrt gibt es klare Definitionen, die schon in vielen Projekten erfolgreich benutzt wurden, und von der NASA und dem DoD stammen (siehe auch INCOSE / GfSE). In den Fällen wo die Software ein Teilsystem des Gesamtsystems ist (zum Beispiel ISS ) folgt die Software den dort gültigen Regeln und nicht den von Balzert vorgeschlagenen.

Ich bin auch dafür, nicht immer nur englische Ausdrücke zu benutzen aber "Spezifikation" statt "Lastenheft" bietet sich als Begriff an und würde die Relation zu internationalen Definitionen verbessern.

- Ein Lastenheft ( = specification) legt die technischen Anforderungen an das zu erstellende Produkt fest. Man unterscheidet die "requirements specification", die vom Auftraggeber geschrieben wird (z.B. Columbus soll mit Space Shuttle gestartet werden) werden, und die "implementation specification", die vom Auftragnehmer geschrieben wird; sie beantwortet /detailliert die Auftraggeberanforderungen (z.B. Columbus soll 4 m Durchmesser und eine Länge von 8 m haben).

- Das Plichtenheft( = statement of work) legt die Durchführungsanforderungen fest (z.B. welche Dokumente müssen zu welchem Zeitpunkt geliefert werden) und wird vom Auftraggeber erstellt. Der Auftragnehmer antwortet mit Plänen wie Entwicklungsplan (design and development) - Plan, Fertigungs (manufacturing)- Plan usw.

Es gibt zwei Optionen um den Artikel richtigzustellen: entweder neu schreiben oder klarstellen, dass er sich nur auf Software bezieht.

Hjpospie 12:08, 16. Nov. 2008 (CET)

Na ja, ich sehe das schon ziemlich anders: Lastenheft = requirements specification und Plichtenheft = implementation specification. Das was du als "statement of work" bezeichnest ist würde ich Projektplan nennen. Ich möchte da auch kein neues Fass aufmachen. Was Lastenheft und Pflichtenheft ist, beschreibt di DIN.--Avron 16:06, 17. Nov. 2008 (CET)

Der Projektplan ist die Antwort des Auftragnehmers auf das Statement of Work ( = Pflichtenheft in der Raumfahrt). Kannst Du mir die Referenz zur DIN geben. Die internationale Raumfahrt kümmert sich nicht um DIN - vielleicht bezieht sich das nur auf Software?

Was meinst Du zu dem Vorschlag, wenigstens in dem Artikel darauf hinzuweisen, dass er sich nur auf Software Systemen bezieht?Hjpospie 12:56, 21. Nov. 2008 (CET)

Pflichten-/Lastenheft sind nach DIN 69905 definiert. Das hat mit Software nichts zu tun sondern mit Projektmanagement. Ansonsten führchte ich, dass du die Begriffe ziemlich vermischst: Der Projektplan ist die Antwort des Auftragnehmers auf das Statement of Work ( = Pflichtenheft in der Raumfahrt) Da fährt mir ein kalter Schauer den Rücken runter.--Avron 16:42, 21. Nov. 2008 (CET)

Es tut mir sehr leid, dass ich kalte Schauer bei dir bewirke aber ich zitiere nicht irgendwelche Dokumente sondern spreche aus Erfahrung mit internationalen Raumfahrtprojekten, die nach den anerkannten Verfahren der NASA und ESA sehr streng kontrolliert werden. Als guter Deutscher bist du vielleicht enttäuscht, dass DIN da so wenig beachtet wird aber das ist nun mal Fakt. Wenn du noch nie ein Pflichtenheft (Statement of Work), Projektplan oder Lastenheft für ein richtiges Programm gesehen hast, kann ich Dir gerne Kopien zukommen lassen.Hjpospie 16:46, 30. Nov. 2008 (CET)

Ich bin nicht enttäuscht, du siehst das in einem falschen Licht. Was mit Pflichten- und Lastenheft bzw. Projektplan gemeint ist regelt nun mal die DIN; daran gibt es nichts zu rütteln. Bei der NASA/ESA heißt das Ding nun mal nicht Pflichtenheft, weil die Dokumente nicht auf deutsch, sondern auf englisch sind. Daher wählt man bei Übersetzungen einen Begriff der wohl am ehesten passt. Wenn es aber einen Projektmanagementstandard bei der Raumfahrt gibt, wäre es toll einen Artikel darüber zu haben. Es gibt ja auch den Artikel Software Requirements Specification. Problematisch wird es aber erst, wenn man Begriffe zu verbiegen versucht. Ich kann dich aber beruhigen, ich habe schon einige Projektmanagement-Dokumente gesehen.-- Avron 19:50, 30. Nov. 2008 (CET)

Es freut mich, dass wir langsam zum Kern der Sache kommen (Bei früheren deutschen Raumfahrtprogrammen wie z.B. HELIOS, AZUR wurden Lastenheft und Pflichtenheft mit den von mir erklärten Definitionen benutzt - aber das ist schon lange her)....Wie heisst denn nach deinem Verständnis das "Statement of Work"? Hjpospie 12:48, 1. Dez. 2008 (CET)

Statement of Work ist schon eine Entsprechung zum Pflichtenheft und Request for Proposal scheint die Entsprechung für Lastenheft zu sein. So weit so gut; ich habe vorher etwas Falsches erzählt. Nur wie deckungsgleich die Begriffe im Detail sind, ist immer fraglich. -- Avron 23:52, 1. Dez. 2008 (CET)

Na nun geht es aber total durcheinander. Das Request for Proposal beinhaltet nur die Anforderungen für das Angebot(Abgabefrist, Detailierung usw) und beinhaltet 3 Dokumente: Vertagsbedingungen, Statement of Work (in der Raumfahrt auch Pflichtenheft genannt), Spezifikation (Lastenheft). Nach Vertragsabschluss ist das Request for Proposal nicht mehr relevant; die Dokumente Vertrag, Statement of Work und Spezifikation sind die Referenzen wogegen die Erfüllung des Vertrages gemessen wird. Du siehst, es ist alles genau geregelt und nur die Begriffe der Dokumente gehen etwas durcheinander; du kannst einem alten Hasen ruhig mal glauben... Hjpospie 11:22, 14. Dez. 2008 (CET)

Dann muss ich dir sagen, was ich schon vorher gesagt habe. Das was man bei dir als Lastenheft bzw. Pflichtenheft gennant hat passt nicht in die DIN-Terminologie. Dann mach einen eigenen Artikel über Projektmanagement in der Raumfahrt.-- Avron 20:31, 15. Dez. 2008 (CET)

Habe mal gegoogled, um mehr zu der so oft von dir zitierten DIN und den Definitionen zu Lastenheft und Pflichtenheft zu finden; leider finde ich die 96605 nicht im Wortlaut. Die Diskussionen über diese Dokumente werden meistens in Software-Kreisen geführt, zum Beispiel im Lexitron: "Der Auftragnehmer setzt dann die im Lastenheft spezifizierten Leistungen (Lasten) in die erforderlichen Tätigkeiten (Pflichten) um und erstellt so ein Pflichtenheft". Das ist für mich ein Plan und keine Spezifikation! Deine Anregung über einen einen Artikel "Projektmanagement in der Raumfahrt" ist eine interessante Variante - ich denke darüber nach... Hab's bis jetzt immer nur durch Zusätze zu bestehenden Artikeln probiert (siehe Unterartikel im "Lastenheft"). Hjpospie 14:17, 17. Dez. 2008 (CET)

Nur noch als Anmerkung: "Plan" hat viele Bedeutungen und ist als Bezeichnung alleine ungeeignet. z. B. Projektplan, Testplan, Durchführungsplan. Wie auch immer, die zitierte Stelle aus Lexitron(?) ist, sagen wir mal, seltsam.--Avron 13:50, 2. Feb. 2009 (CET)

Wie passt die Leistungsbeschreibung zu Lastenheft und Pflichtenheft?

Im Zusammenhang mit Lastenheft und Pflichtenheft habe ich auch den Begriff der Leistungsbeschreibung gelesen. Wie passt der zu den beiden anderen Begriffen bzw. kann von ihnen abgegrenzt werden? Bernburgerin 13:20, 15. Apr. 2009 (CEST)

Je nach dem ob es aus Sicht des Auftraggebers oder -nehmers geschrieben ist, kann es sowohl äquivalent zu Lastenheft oder Pflichtenheft sein. Zusätlich dazu regeln Lasten/Pflichtenheft manchmal Dinge über den eigentlichen Gegenstand hinaus z. B. Zahlungsmodaliltäten. In einer reinen Leistungsbeschreibung könnte so etwas fehlen.-- Avron 17:34, 15. Apr. 2009 (CEST)

Lastenheft ändert sich während des Projekts

Was mir an Festpreis-Projekten immer nicht gefällt: Der Auftraggeber gibt zum Zeitpunkt A einen Auftrag, mit Lastenheft Version A. Der Kunde schreibt zum Zeitpunkt A das Angebot A (Pflichtenheft A) und erhält den Auftrag für den Geldwert A.

Wenn das fertige Projekt aber dann zum Zeitpunkt B abgenommen wird, dann wird durch den Auftraggeber plötzlich Lastenheft Version B verwendet, um die Abnahme zu machen. Das läuft wohl nur unbewusst ab, hat aber Folgen! Gerade WEIL viele Auftraggeber die Requirements so schwammig halten (wie auch hier wieder empfohlen wird) ist die Abnahme am Schluss nicht fair. Es gibt dann den berühmten Satz "Na, aber so haben wir Feature X nicht haben wollen. Dafür ziehen wir einen Teil von der Rechnung ab!"

=> Ist das laut DIN 69901-5 wirklich so unfair gedacht?? Falls nein, muss der Text klarer formuliert werden. --Patchworker 00:35, 8. Aug. 2009 (CEST)

Nein, es ist nicht "unfair" gedacht, sondern eigentlich absolut fair.

Wenn in einem Lastenheft eine zu schwammige Anforderung spezifiziert ist, so muss auch nach dieser schwammigen anfordeung abgenommen werden. Beispiel "Die Software muss dem Anwender die Möglichkeit bieten zu drucken.", diese Anforderung ist so schwammig, das es dem AuftragNEHMER überlassen ist, wie er diesen Druck realisiert. Wenn der Auftraggeber hier eine speziellere Ausprägung haben will (z.B. Druck auf einer zentralen Druckstraße, und nciht nur Druck auf einem an den PC angeschlossenen Drucker) so muss er zusätzliches Geld in die Hand nehmene, oder auf die Kulanz des Auftragnehmers bauen.

für die Abnahme sind ausschließlich die zuvor durch laten- und pflichtenheft definierten Abnahmekriterien relevant.

-- -gpf- 20:03, 18. Aug. 2010 (CEST)

Die Diskussion beruht auf Unkenntnis des vertraglichen Vorgehens; wenn der Auftraggeber eine neue Version des Lastenheftes einführen will, geht das nur über eine Vertragsänderung (in der internationalen Raumfahrt heisst das Contract Change Notice). Insgesamt solltet ihr euch den obigen Kommentar zur Erstellung des Lastenheftes / Spezifikation ansehen, dann versteht man, wie die "Schwammigkeiten" aufgelöst werden.-- Hjpospie 13:15, 14. Okt. 2010 (CEST)

Branchen?

Ich finde in den ersten Satz gehört die Infomation, in welchen Branchen das üblich ist. Alles scheint sich hier auf Softwareentwicklung zu beziehen (v.a. bei Pflichtenheft), ist das ein Begriff der sich nur auf Softwareentwicklung bezieht? Z.b. im Baugewerbe wäre die Entsprechung Leistungsverzeichnis. Wo wird ein Lastenheft angewandt? 85.179.140.192 22:52, 9. Jul. 2011 (CEST)

Ich war in der Softwareentwicklung und Hardwareentwicklung (für Industriekunden bzw. Privatkunden) tätig und in beiden Entwicklungen haben wir Lastenhefte geschrieben, sowohl für interne Entwicklungsprojekte (Auftraggeber = eigener Vertrieb, Product Line Manager) bzw. für outgesourcete Entwicklungsprojekte (Auftraggeber = Entwicklungsabteilung). In der F&E sind Lastenhefte meiner Erfahrung (mehrere verschiedene Firmen, mehrere verschiedene Branchen) nach, sind Lastenheften auch in Nicht-Software-Projekten üblich. -- Optimike 08:53, 19. Aug. 2011 (CEST)

Andere Sprachen

Aktuell verweist das Lastenheft auf en:Product requirements document. Die Beschreibung dort klingt für mich eher nach einer Produktspezifikation. Ist das englische Pendant nicht eher en:marketing requirements document? Jedenfalls wird es bei uns so in der Firma verwendet, auch mit englischsprachigen Kunden. (nicht signierter Beitrag von Sikarjan (Diskussion | Beiträge) 12:14, 3. Dez. 2012 (CET))

Das MRD ist mehr eine grobe Produktdefinition, beschreibt welche Vision man mit dem Produkt hat, wie sich das Produkt im Markt und gegenüber Wettbewerbersproduktn positioniert usw. Das PRD beschreibt hingegen die genauen Produkanforderungen, was dem Lastenheft entspricht.--Avron (Diskussion) 12:59, 3. Dez. 2012 (CET)

Fragwürdiger Text

Benutzer:RehbeinC hat folgenen Text eingefügt: Ist sich Auftraggeber und Auftragnehmer uneinig über die Lasten, so sollten die Details nachverhandelt und ein Konsens erreicht werden. Dieser Konsens stellt in der industriellen Produktentwicklung die Produktspezifikation dar, auf die hin entwickelt wird.

Ich halte ihn für fragwürdig. In der Theorie wird das Lastenheft vom Auftraggeber geschrieben; der potentielle Auftragnehmer antwortet mit einem Pflichtenheft. Hier von einem Konsens zu reden, finde ich falsch. Auch ein neuer Begriff "Produktspezifikation" ist der Sache nicht dienlich. Es kommt aber natürlich zu Diskussionen und eine Möglichkeit kann eine Änderung der Dokumente sein.--Avron (Diskussion) 17:20, 4. Jul. 2017 (CEST)