Übersicht
Ein Lastenheft ist eines der wichtigsten Dokumente im Entwicklungsprozess. Ein saubere und immer gleiche Struktur gibt dem Entwicklungsprozess einen Rahmen, in dem sich alle Beteiligte gleichermassen sicher bewegen können.
Diese Struktur hilft dabei, leicht ins das Projekt und die zu entwickelnden Geräte einzutauchen und dabei nach und nach die Randbedingungen und die geplante Nutzung zu verstehen. In den Anforderungskapiteln des Dokuments sind alle Details enthalten, die für die Zuweisung und den Start in die Entwicklung genügen.
Zuweisungen zu den Teams der Fachdomänen ist ebenso möglich, wie die Aufteilung der Anforderungen auf unterschiedliche Releasestände des Endproduktes.


Inhalte des Lastenheftes
Kapitel 1 Management Summary
Eine Zusammenfassung des gewünschten Systems auf maximal einer DIN A4 Seite, um den Einsteig von einer hohen Flughöhe zu ermöglichen.
Kapitel 2 Einführung und Ziele
In diesem Kapitel wird der Sinn und Zweck des System of Interest beschrieben.
Kapitel 3 Projektkontext
Gelten bei der Entwicklung oder im späteren Einsatz des Systems besondere Bedingungen, dann werden diese hier Kapitel aufgelistet und beschrieben.
Evtl. existieren noch weitere Projekte, die weitere Teile eines System of Systems liefern, so müssen Abstimmungen mit diesen durchgeführt werden. Die Projektreferenzen gehören zum Projektkontext dazu.
Kapitel 4 Referenzen und Literatur
Alle Referenzen, die Informationen für die Entwicklung des Systems enthalten, sowie Hinweise auf Normen und zertifizierenden Stellen sind im Kapitel 3 aufzunehmen. Dazu gehören auch und vor allem die Anforderungsdokumente des Kunden.
Kapitel 5 Glossar
Abkürzungen und Begriffe, die zu kennen sind, müssen im Kapitel 4 aufgeführt werden.
Kapitel 6 Systemübersicht
Es wird die Umgebung des Systems dargestellt, um herauszuarbeiten, was das System ausmacht und wie es beim Kunden eingesetzt wird.
Kapitel 7 Stakeholder
Eine Liste der Stakeholder des Systems. Als Stakeholder gelten alle Menschen und Institutionen, die in irgendeiner Art und Weise mit dem System zu tun haben.
Kapitel 8 Nutzenversprechen
Das System wird aus einem bestimmten Grund entwickelt. Dieser kann sich auf mehrere, aber wenige Nutzenversprechen aufteilen. Das sind die Kernaussagen, zu den Funktionen, Kaufargumenten und Gründen zur Existenz des Systems oder Produktes.
Kapitel 9 Hauptanwendungsfälle
Die Art und Weise der Nutzung – auch schon die Nutzung während der Entwicklungsphase – wird in diesem Kapitel beschrieben.
Kapitel 10 Hauptfunktionen
Die Anwendungsfälle teilen sich in Funktionen auf, die zusammengesetzt die Anwendungsfälle ergeben. Funktionen können aber sehr leicht als Einstieg in die Architektur des Systems genutzt werden.
Kapitel 11 Hauptkomponenten
Um ein System physikalisch herstellen zu können, sind viele Komponenten notwendig. Darunter befinden sich einige Komponenten, die wichtige Funktionen übernehmen oder bereitstellen. Diesen wird üblicherweise – mit Absicht oder intuitiv – immer viel Beachtung geschenkt. Sie sind hier aufzuführen und zu beschreiben.
Kapitel 12 Hauptliefergegenstände
Wie das System ausgeliefert wird und was zu einer Auslieferung dazugehört, ist in Kapitel 12 nachzulesen.
Kapitel 13 Systemschnittstellen
Das System wird nie alleine existieren. Es werden immer irgendwelche Umsysteme vorhanden sein. Diese gilt es anzubinden. Über welche Schnittstellen dies geschehen soll, ist hier aufzulisten.
Kapitel 14 Technische Einschränkungen
Die technischen Einschränkungen dienen der genaueren Beschreibung des Systems. Sie stellen in den meisten Fällen wichtige Informationen für den architekturellen Entwurf dar.
Kapitel 15 Stakeholder Einschränkungen
Durch Anwender, Beteiligte an der Herstellung, Nutzung oder Zulassung werden weitere Anforderungen an das System gestellt.
Kapitel 16 Risiken und Chancen
Welche Chancen mit dem System erreicht werden können, aber auch welche Risiken auftreten können, das enthält Kapitel 16. Dies ist daher sinnvoll, weil dadurch aufgezeigt werden kann, warum ein Projekt so durchgeführt werden muss, wie es in den vorherigen Kapiteln beschrieben wurde.
Kapitel 17 Offene Punkte
Sofern offene Punkte verbleiben, die schon angesprochen wurden, aber nicht abschließend geklärt werden konnten, sind diese in Kapitel 17 abzulegen.
Features
- Management Summary für das Reporting
- Beschreibung des Projektkontextes und des Systemkontextes
- Auflistung aller Beteiligten
- Beschreibung des Nutzens und der Anwendungsfälle
- Schnittstellen zu Umsystemen werden aufgenommen
- grobe Darstellung der Komponenten und geplanten Liefergegenstände
- Abdeckung der Praktiken des Automotive-SPICE Prozesses SYS.1
- Dokumentenhistorie ist enthalten
- Urheberrecht wird beachtet
- Liste offener Punkte
- Hinweis auf rechtliche Verbindlichkeit ist enthalten
Vorlage für Word (zum sofortigen Start) und als Text-Datei (zum Einfügen in ein beliebiges Anforderungswerkzeug)

Alle zum Werke dieser Seite sind lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.
Vision Statement
„Wir rocken Engineering!“
Mission Statement
„Exzellentes und nachhaltiges Systems Engineering für den Mittelstand!“
Wichtige Seiten
Rechtliches
Kontakt
Björn Schorre
Ingenieurbüro für SE
Knickstr. 10
32584 Löhne



