ZA007 - Lastenheft vs Pflichtenheft
27.03.2012 
40 Minuten
- Download:
- MP3 Audio28 MB
On Air in dieser Episode
Zusammenfassung
In der heutigen Folge beschäftige ich mich mit der Frage, warum Lastenhefte und Pflichtenhefte sinnvoll sind. Ich beleuchte, wie Lastenhefte analysiert, Normen bewertet und System-Pflichtenhefte erstellt werden können. Außerdem beantworte ich die Frage, wie pragmatisch mit diesen Spezifikationen umgegangen werden kann. Zum Schluss gebe ich noch ein paar Tipps und Tricks aus der Praxis mit.
Der Inhalt dieser Episode:
- Warum brauchen wir Spezifikationen?
- Was sind Lastenhefte?
- Was sind Pflichtenhefte?
- Tipps & Tricks zum Umgang mit Lasten- und Pflichtenheften
Themen: Lastenhefte, Pflichtenhefte, System Footprint, Customer Requirements, Stakeholder, Systems Requirements Specification, Systems Architecture Specifications, Systemarchitektur, Anforderungserhebung, Hidden links, Komplexität, Fehlertoleranz, Funktionale und nichtfunktionale Anforderungen, Releaseplanung, Allocation, Systemabgrenzung, System-Schnittstellen, Traceability, natursprachliche Anforderungen, Änderungsmanagement, Reviews, Automotive-Spice, SysML, Contract Based Design, Polarion, Doors, MKS Integrity, Enterprise Architect
Hinweise auf andere Episoden rund um Spezifikationen:
- Episode #16: SysML in der Systementwicklung
- Episode #29: Wie strukturiere ich ein Pflichtenheft? – Teil 1: Systems Requirements Specification
- Episode #30: Wie strukturiere ich ein Pflichtenheft? – Teil 2: Systems Architekture Specification
- Episode #42: Sieben Fallen im Requirements Management
- Episode #52: Wie kann ich mein Anforderungsmanagement neu ausrichten?
- Episode #54: Dann kann ich auch Zeitungsartikel in DOORS stopfen
Viel Spaß beim reinhören!
Aus der Praxis eines Troubleshooters:
Subscription link
Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:
Euer Feedback
Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de
Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.
Hallo Maik,
vielen Dank für diese interessante Folge. Ich habe auch "5 Schritte zur Erstellung eines guten Lastenheftes" (siehe mein Kommentar dort) und "10 Schritte zur pragmatischen Analyse von Lastenheften" gelesen. Vergleiche ich deine Herangehensweise mit der anderer im Netz (z.B. auch Wikipedia) so stelle ich fest, dass das was du als Systems Requirement Specification" bezeichnest und unter dem Teil "Pflichtenheft" einordnest, dort eignetlich als das Lastenheft bezeichnet wird. Wenn ich das richtig verstanden habe, kommt das Lastenheft eigentlich vom Kunden, das Plfichtenheft vom Softwareentwickler. Sollte die Systems Requirement Specification nicht vom Kunden kommen?
Grüße,
Markus
Hallo Markus,
danke für dein Feedback!
Ja, es gibt unterschiedliche Sichten und Namensbegriffe. Kommt auf die Branche und die Komplexität der Produkte an.
Ich habe es mit mechatronischen Systemen zu tun, die oft sehr viel Embedded Software beinhalten. Deshalb habe ich in meinem Umfeld mehrere Flugebenen, die mit der Customer Specification (Lastenheft) vom Kunden als oberste Ebene beginnen (ENG.1 nach SPICE).
Darauf hin erstellen wir für die Systemebene die System Requirements Specification (Pflichtenheft – Teil 1) als Antwort für den Kunden (ENG.2 nach SPICE).
Das ist aber gleichzeitig wieder das "Lastenheft" für die interne oder externe Softwareentwicklung. Diese erstellt die Software Requirements Specification (SW-Pflichtenheft) als Antwort (ENG.4 nach SPICE).
Parallel dazu gibt es auf dieser Ebene auch eine Electronic Requirements Specification und eine Mechanic Requirements Specification als Antwort auf die Systems Requirements Specification von den anderen Technologie-Domänen.
Grundsätzlich sind alle Spezifikationen in der Problemsicht geschrieben. Wie viele Ebenen du hast ist abhängig von der Komplexität deines Systems. In weniger komplexen Systemen macht es durchaus Sinn hier pragmatisch zu sein.
Wichtig ist nur, dass du immer eine Kundenebene hast mit den Lasten (das Wünsch-dir-was) und die Antwort der Entwicklung mit den „Pflichten“. Wie das Ganze genannt wird, ist ein Frage der Vereinbarung. Auch hier gibt es in Unternehmen unterschiedliche Namenskonventionen. Ich nutze hier im Podcast die geläufigen (und in SPICE definierten) Begriffe und passe mich aber den Namenskonventionen bei den Kunden in den Projekten oft an. Das Entscheidende ist der Inhalt.
Schönen Gruß aus Köln,
Maik