Konzeption eines Lastenhefts und Pflichtenhefts für eine betriebsinterne Softwarelösung (Projektbericht)

Die fortschreitende digitale Transformation bietet Unternehmen vielfältige Möglichkeiten, um betriebliche Prozesse effizienter zu gestalten und sich langfristig Wettbewerbsvorteile zu sichern. Ein wesentliches Ziel ist es, durch den Einsatz moderner Softwarelösungen Kosten zu optimieren, Prozesszeiten zu verkürzen und menschliche Fehler zu minimieren. Der Schwerpunkt liegt dabei auf Prozessen, die sich aufgrund ihres repetitiven Charakters, ihrer klar definierten Abläufe und Regeln besonders gut für eine Automatisierung eignen. Die erfolgreiche Integration dieser Softwarelösungen in bestehende Strukturen stellt jedoch für zahlreiche Unternehmen eine Herausforderung dar. Softwareentwicklungsprojekte sind zudem häufig mit hohen Kosten verbunden. Ohne adäquate Planungsinstrumente besteht das Risiko, dass Zeitrahmen und Budgets schnell überschritten werden. Um solche Risiken zu minimieren, bieten Lasten- und Pflichtenhefte als bewährte Werkzeuge der Softwareentwicklung einen strukturierten Ansatz.^[1]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

Hauptziel der vorliegenden Arbeit ist die Konzeption eines Lasten- und Pflichtenheftes für eine unternehmensinterne Softwarelösung im Bereich Qualitätsmanagement, das als Planungsgrundlage für die erfolgreiche Umsetzung der Maßnahmen dient. Zwischenziele sind die Definition der Begriffe Lastenheft und Pflichtenheft sowie die Vorstellung verschiedener Ansätze zum Aufbau dieser Dokumente aus der Literatur. Die Einordnung dieser Artefakte in den Softwareentwicklungsprozess stellt ein weiteres Zwischenziel dar.

In den Grundlagen dieser Arbeit werden zunächst in Kapitel 2.1 die Begriffe Lastenheft und Pflichtenheft anhand verschiedener Definitionen aus der Literatur definiert. In Kapitel 2.2 werden unterschiedliche Herangehensweisen zum Aufbau dieser Dokumente analysiert. Anschließend wird in Kapitel 2.3 die Bedeutung von Lasten- und Pflichtenheften im Kontext des Softwareentwicklungsprozesses betrachtet. Dazu werden verschiedene Vorgehensmodelle erläutert und die Artefakte in die Modelle eingeordnet. Im Mittelpunkt steht dabei die Frage, ob Lasten- und Pflichtenhefte im agilen Zeitalter noch Relevanz haben. Da Materialzertifikate in dieser Arbeit eine zentrale Rolle spielen, wird abschließend in Kapitel 2.4 auf die Definition und Bedeutung von Materialzertifikaten für den betrieblichen Qualitätsmanagementprozess eingegangen.

Auf Basis der gewonnenen Erkenntnisse wird im Hauptteil der Arbeit zunächst das Lastenheft erstellt. Zunächst erfolgt eine Darstellung des Unternehmens (Kapitel 3.1.1) und eine Analyse der Ausgangssituation (Kapitel 3.1.2). Daraufhin werden in Kapitel 3.1.3 die Ziele des Projekts definiert und sowohl die funktionalen als auch die nicht-funktionalen Anforderungen an das System herausgearbeitet (Kapitel 3.1.4). Im letzten Teil des Lastenheftes werden die bestehende Systemarchitektur und die Schnittstellen zwischen den Systemkomponenten beschrieben.

Die dargestellten Aspekte des Lastenheftes werden anschließend in der Konzeption des Pflichtenheftes aufgenommen. In Kapitel 3.2.1 wird der angestrebte Soll-Zustand vorgestellt. Die neue Systemarchitektur wird in Kapitel 3.2.2 beschrieben. Die Benutzeroberflächen werden in Kapitel 3.2.3 erläutert. Darauf folgt der grobe Projektplan in Kapitel 3.2.4. Abschließend werden in Kapitel 3.2.5 Aspekte der Weiterentwicklung und mögliche Anpassungen behandelt.

In der Literatur wird bei der Definition des Begriffs Lastenheft häufig auf die Norm DIN 69901-5 zurückgegriffen, nach der ein Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferung und Leistung eines Auftragnehmers innerhalb eines (Projekt-) Auftrags“^[2] beschreibt.

Ein Großteil der Definitionen (siehe Tab. 1) betont die fachliche Sicht des Auftraggebers. Aufgabe des Auftraggebers ist es, die Anforderungen aus Nutzersicht zu dokumentieren und alle Randbedingungen zu erfassen. Verfügt der Auftraggeber nicht über das notwendige Fachwissen, sollte er jemanden mit dieser Aufgabe beauftragen.^[3] Auf dieser Basis beauftragt der Auftraggeber „den Auftragnehmer mit der Realisierung der Anforderungen.“^[4]

Tab. 1: Definitionen Lastenheft (eigene Darstellung)

Grundsätzlich definiert das Lastenheft den Funktionsinhalt eines Projektes, also das "WAS" und "WOFÜR" und beschreibt das Problem aus Anwendersicht. Einerseits dient es als Ausschreibungsdokument, auf dessen Grundlage sich potenzielle Auftragnehmer bewerben können. Andererseits stellt es auch ein wichtiges Vertragsdokument dar, in dem die Erwartungen und Anforderungen klar festgelegt werden.^[8] Des Weiteren dient es als zentrale Planungsgrundlage für die Projektleitung, als Leitfaden für alle involvierten Gruppen sowie als Instrument zur Überwachung des Projektfortschritts.^[9]

Lastenhefte finden sowohl bei der Ausschreibung zur Erstellung von Individualsoftware als auch bei der Auswahl und Beschaffung von bereits existierender Standardsoftware Anwendung. Im Rahmen dessen ist eine Kategorisierung der Anforderungen in "kritisch", "gefordert" und "optional" empfehlenswert. Die als kritisch eingestuften Anforderungen sind für das Projekt unverzichtbar. Sollte die Softwarelösung eines Anbieters diese K.O.-Kriterien nicht erfüllen, muss dies unmittelbar bei der Analyse festgestellt werden. Geforderte Anforderungen sind notwendig, um die Projektziele zu erreichen, während optionale Anforderungen als Bonus betrachtet werden. Diese optionalen Anforderungen ermöglichen es zu prüfen, ob die neue Lösung zusätzliche Funktionen bietet. Bei der Bewertung sollte insbesondere geprüft werden, ob der Nutzen der zusätzlichen Funktionen die damit verbundenen Kosten rechtfertigt und ob diese Funktionen tatsächlich erforderlich sind.^[10]

Auf der Grundlage der im Lastenheft definierten Anforderungen erstellt der Auftragnehmer das Pflichtenheft, in dem detailliert beschrieben wird, wie der gewünschte Soll-Zustand unter Berücksichtigung konkreter Lösungsansätze erreicht werden soll.^[11] Neben dem Begriff "Pflichtenheft" finden sich in der Praxis, häufig auch andere Bezeichnungen wie "Feinkonzept", "Fachspezifikation" oder "Sollkonzept".^[12] Das Pflichtenheft ist in der Regel Bestandteil des Angebots des Auftragnehmers.^[13] Der Auftraggeber ist dafür verantwortlich, die Widerspruchsfreiheit und Umsetzbarkeit der im Lastenheft definierten Anforderungen zu überprüfen. Nach Genehmigung des Pflichtenheftes durch den Auftraggeber wird das Pflichtenheft Vertragsbestandteil.^[14] Anschließend dient es als Referenzdokument, um zu überprüfen, ob die erbrachte Leistung vollständig und gemäß den definierten Anforderungen umgesetzt wurde.^[15]

Tab. 2: Definitionen Pflichtenheft (eigene Darstellung)

Die zuvor dargestellten Definitionen (s.o.) betonen eine klare Abgrenzung zwischen dem Lastenheft, das vom Auftraggeber erstellt wird und ausschließlich der Beschreibung des Problems dient, und dem Pflichtenheft, das vom Auftragnehmer erstellt wird und sich auf die Beschreibung des Lösungsraumes konzentriert. In der Praxis lässt sich jedoch einerseits „die klare Trennung von Problem- und Lösungsraum mithilfe der beiden Dokumente“^[20] nicht vollständig gewährleisten. Andererseits ist es auch möglich, dass der Auftragnehmer den Auftraggeber bei der Erstellung des Lastenheftes unterstützt, insbesondere dann, wenn der Auftraggeber nicht über die erforderliche methodische und fachliche Kompetenz verfügt. Ebenso ist es möglich, dass der Auftraggeber gemeinsam mit dem Dienstleister das Pflichtenheft ausarbeitet, wenn dieser Einfluss auf die Lösung nehmen möchte.^[21]

Die Bedeutung von Lasten- und Pflichtenheften ist nicht zu unterschätzen. Diesbezüglich sei auf die Erkenntnisse verschiedener Autoren verwiesen, darunter Teich et al. (2008), Groß und Pfenning (2019), Broy und Kuhrmann (2021) sowie Madauss (2020), die übereinstimmend betonen, dass sie eine entscheidende Rolle für den langfristigen Erfolg von Softwareprojekten spielen.^[22]

Lasten- und Pflichtenhefte werden im Rahmen von Projekten in vielen Branchen – auch außerhalb der Softwareentwicklung - eingesetzt, wobei sich in einigen Bereichen standardisierte Vorgaben etabliert haben. International wird für die Softwareentwicklung häufig auf die Norm ISO/IEC/IEEE 29148:2018 verwiesen. Diese Norm unterscheidet nicht explizit zwischen dem Lasten- und Pflichtenheft und behandelt Aspekte des Anforderungsmanagements wesentlich detaillierter.^[23] Am ehesten vergleichbar mit den traditionellen Lasten- und Pflichtenheften ist das Kapitel 9.6, das sich mit der "Software Requirements Specification" befasst.^[24] Die Praxis hat aber gezeigt, dass diese Vorgehensweise ab einer bestimmten Projektgröße insbesondere aus rechtlicher Sicht nicht zu empfehlen ist.^[25]

Die häufig verwendete DIN-Norm liefert keine spezifischen Vorgaben zur Gliederung und zu den Inhalten des Lasten- und Pflichtenheftes. Andere Autoren und Normen, insbesondere Balzert (2009), Broy (2021) und der VDI (2014) bieten hingegen Vorschläge zum strukturellen Aufbau und zu den erforderlichen Inhalten.

Tab. 3: Verschiedene Herangehensweisen zum Aufbau eines Lastenhefts (eigene Darstellung)^[26]

In den verschiedenen Ansätzen zum Aufbau eines Lastenheftes lässt sich eine gemeinsame Struktur erkennen. In allen vorgestellten Herangehensweisen findet sich eine Beschreibung der Ausgangssituation, eine Definition der Projektziele sowie die Erfassung spezifischer Anforderungen. Auffallend ist jedoch, dass die Projektplanung bei Balzert (2009) nicht explizit behandelt wird, während Broy (2021) zusätzlich das Risikopotenzial berücksichtigt.

Analog zum Lastenheft existieren auch für das Pflichtenheft diverse Vorschläge hinsichtlich des Aufbaus. Die verschiedenen Ansätze (s.u.) zeichnen sich durch signifikante strukturelle Unterschiede aus. Balzert definiert das Pflichtenheft als „eine Verfeinerung und Präzisierung des Lastenhefts“^[27] und folgt dabei einem Aufbau, der eng an das Lastenheft angelehnt ist. Im Kontrast dazu präsentiert der VDI einen deutlich flexibleren Ansatz, der eine offenere Gestaltung ermöglicht. Auch Broy orientiert sich in seinem Vorschlag an der Struktur des Lastenhefts, wobei die Kapitel des Pflichtenhefts als direkte Antwort auf die im Lastenheft definierten Kapitel zu verstehen sind. Balzert misst der Projektplanung keine Bedeutung bei, während in der VDI-Norm die Anforderungen an die Projektabwicklung im Lastenheft festgelegt werden. Bei Broy und Kuhmann hingegen wird der Projektplan im Pflichtenheft definiert.

Tab. 4: Verschiedene Herangehensweisen für den Aufbau eines Pflichtenhefts (eigene Darstellung)^[28]

Trotz fehlender Standardisierung sollte das Pflichtenheft, als Antwort auf das Lastenheft, dessen Anforderungen und Probleme aufgreifen und konkrete Anwendungsfälle beschreiben. Im IT-Kontext zählen unter anderem Design-Layouts und die Informationsarchitektur dazu.^[29]

Die Vielzahl an unterschiedlichen Vorgehensmodellen zur Umsetzung von IT-Projekten sowie die variierenden Ansätze im Umgang mit Lasten- und Pflichtenheften machen eine genauere Betrachtung erforderlich. Gemäß Broy und Kuhrmann (2013) beschreibt ein Vorgehensmodell „systematische, organisatorische, ingenieurmäßige und quantifizierbare Vorgehensweisen, um Aufgaben einer bestimmten Klasse wiederholbar zu lösen.“^[30]

Ein Vorgehensmodell definiert den organisatorischen Rahmen für ein Projekt, dessen Ziel die Entwicklung eines Softwaresystems ist, und beeinflusst maßgeblich die Art und Weise, wie Anforderungen erfasst, dokumentiert und umgesetzt werden.^[31] Zu ihnen zählen klassische Ansätze, wie das Wasserfallmodel und das V-Modell mit der Erweiterung XT als auch moderne Ansätze wie Scrum.

Das Wasserfallmodell ist „das älteste und bekannteste Vorgehensmodell für IT-Projekte, insbesondere für die Softwareentwicklung“^[32], welches durch Royce (1970) und später Boehm (1981) an Bedeutung erlangte. Die einzelnen Phasen des Projekts – von der Anforderungsanalyse über Entwurf und Implementierung bis hin zu Test und Wartung – sind klar voneinander abgegrenzt und werden nacheinander durchlaufen. Jede Phase endet mit einer Qualitätsprüfung, die sicherstellt, dass die Anforderungen korrekt umgesetzt wurden, bevor der nächste Schritt eingeleitet wird. Während Rückkopplungen zwischen unmittelbar benachbarten Phasen möglich sind, erfordern Rücksprünge zu früheren Phasen aufgrund von Fehlern oder geänderten Anforderungen stets eine neue Qualitätsprüfung.^[33]

Abb. 1: Softwareentwicklungsphasen (links) und ihre Ergebnisse (rechts) am Beispiel des klassischen Wasserfallmodells^[34]

Das Lastenheft ist das Ergebnis der Anforderungsanalyse im Wasserfallmodell, während das Pflichtenheft im nachfolgenden Schritt "Entwurf" erstellt wird.^[35]

Die mangelnde Flexibilität sowie die späte Einbindung des Kunden im Wasserfallmodell führten zur Entwicklung alternativer Vorgehensmodelle.^[36]

Das V-Modell, welches „das erstmals in den 1980er Jahren beschrieben wurde“^[37], wird häufig als Erweiterung des klassischen Wasserfallmodells angesehen. Im Gegensatz zum rein sequenziellen Ansatz des Wasserfallmodells, das lineare Entwicklungsschritte vorschreibt, verfolgt das V-Modell einen systematischeren und stärker strukturierteren Ansatz, der die Gegenüberstellung zwischen Entwicklung und Qualitätssicherung betont.^[38]

Der linke Zweig des V-Modells (Abb. 2) beschreibt die verschiedenen Phasen der System- und Softwareentwicklung, beginnend mit der Anforderungsanalyse bis hin zur Implementierung. Der rechte Zweig des Modells konzentriert sich auf die entsprechenden Qualitätsmaßnahmen, die parallel zu den Entwicklungsphasen ablaufen. Dies bedeutet, dass jeder Entwicklungsphase eine zugehörige Testphase zugeordnet ist, um sicherzustellen, dass die entwickelten Komponenten den Anforderungen entsprechen und korrekt implementiert sind.^[39]

Abb. 2: V-Modell^[40]

Das Lastenheft wird in der Phase Anforderungsdefinition erstellt, während das Pflichtenheft der Phase Grob- bzw. Feinentwurf zugeordnet wird.^[41]

Das ursprüngliche V-Modell wurde im Laufe der Jahre kontinuierlich weiterentwickelt, um den Anforderungen moderner Softwareentwicklungsprojekte gerecht zu werden. Eine entscheidende Neuerung stellt dabei das V-Modell XT dar, welches für "eXtreme Tailoring" steht und die flexible Anpassung von Projekten an individuelle Anforderungen in den Vordergrund stellt.^[42] Durch einen modularen Aufbau in den Bereichen Produktmodell, Rollenmodell und Prozessabläufe ermöglicht es den „Ein- und Ausbau von Vorgehensbausteinen für ein spezifisches Projekt“^[43]. Zudem erlaubt es im Gegensatz zum stark sequenziell geprägten klassischen V-Modell die Integration agiler Methoden.^[44]

Mit der wachsenden Komplexität moderner Softwareprojekte stoßen traditionelle Ansätze wie die Wasserfallmethode oder das ursprüngliche V-Modell zunehmend an ihre Grenzen. Diese klassischen Modelle basieren auf starren, sequenziellen Abläufen und umfangreichen Vorgaben, die in dynamischen und schnelllebigen Projektumgebungen nicht immer flexibel genug sind. In den 1990er Jahren formierte sich in der Softwareentwicklung eine Gegenbewegung, die 2001 mit der Veröffentlichung des sogenannten "Agilen Manifests" durch eine Gruppe führender Softwareentwickler entscheidende Bekanntheit erlangte. Während zuvor Prozesse, Werkzeuge und detaillierte Pläne im Fokus standen, rückt das Agile Manifest Flexibilität, Kundeninteraktion und die Fähigkeit, auf Veränderungen zu reagieren, in den Vordergrund.^[45]

Scrum hat sich als die am weitesten verbreitete Methode der agilen Softwareentwicklung etabliert. Laut einer Studie von VersionOne und Collab.net steht „keine andere Methodik [...] so sehr für das agile Arbeiten und wird so häufig genutzt wie die Methode "SCRUM".“^[46] Agilität selbst wird dabei allgemein als die Fähigkeit verstanden, Veränderungen offen zu begegnen und deren Auswirkungen effektiv zu bewältigen.^[47]

Scrum zeichnet sich dabei durch besonders wenige Vorgaben in Bezug auf Vorgehensweise, Dokumentation und Testen aus und geht damit noch einen Schritt weiter als die allgemeinen Prinzipien der agilen Entwicklung. Im Mittelpunkt stehen klar definierte Rollen (Product Owner, Scrum Master und Team), eine spezielle Besprechungsphilosophie und festgelegte Entwicklungszyklen (Sprints) sowie Artefakte (Produkt-Backlog und Sprint-Backlog).^[48]

Bei der Anwendung agiler Methoden wie Scrum oder Kanban wird zwar auf die Erstellung eines expliziten Lasten- und Pflichtenheftes verzichtet, wie dies bei traditionellen Vorgehensmodellen üblich ist. Dennoch bleibt die Bedeutung einer umfassenden Anforderungsdokumentation bestehen. Auch in agilen Projekten zeigt sich, dass eine klare Definition der Anforderungen am Anfang des Projekts unerlässlich ist, unabhängig vom gewählten Vorgehensmodell. Auch bei Ausschreibungen behält das Lastenheft weiterhin seine Relevanz. Während das Lastenheft in diesem Zusammenhang weiterhin eine bedeutende Rolle spielt, entsteht das Pflichtenheft tendenziell implizit und entwickelt sich parallel zur fortschreitenden Softwareentwicklung. Dabei kommen Instrumente wie Backlogs zur Speicherung von Anforderungen, Visions und Goals zur Definition von Anforderungen an das Gesamtsystem, Epics für noch unklare oder sehr grobe Anforderungen sowie User Stories für konkrete funktionale Anforderungen zum Einsatz.^[49] Trotzdem kann es auch hier Sinn ergeben eine grobe Lösungskonzeption zu entwickeln, welche dazu dient, „den Projektstart in die richtige Richtung zu lenken und auf vertraglicher Ebene zwischen Auftraggeber und Auftragnehmer ein Mindestmaß an Verbindlichkeit zu schaffen.“^[50]

Das Unternehmen produziert seine Produkte gemäß den Normen [...] und [...]. Diese Normen fordern eine lückenlose Nachverfolgbarkeit aller extern zugekauften Komponenten durch Materialzertifikate, die in den Produkten verwendet werden.^[51]

Materialzertifikate oder Prüfbescheinigungen sind Dokumente, die die Übereinstimmung eines Materials mit den vereinbarten Spezifikationen und Qualitätsanforderungen bestätigen. Sie spielen eine entscheidende Rolle in der Qualitätssicherung und Rückverfolgbarkeit von Materialien, insbesondere in der metallverarbeitenden Industrie.^[52]

Die Norm DIN EN 10204:2005-01 beschreibt die verschiedenen Arten von Materialzertifikaten, die für metallische Werkstoffe relevant sind. Sie definiert verschiedene Typen von Abnahmeprüfzeugnissen und legt fest, welche Informationen und Nachweise in einem solchen Dokument enthalten sein müssen. Obwohl es sich um eine europäische Norm handelt, ist sie weltweit anerkannt. Darüber hinaus ist die Anwendung dieser Norm nicht auf metallische Produkte beschränkt, sondern kann auch auf nichtmetallische Produkte angewendet werden.^[53]

Für das beschriebene Unternehmen sind vor allem Prüfbescheinigungen vom Typ 3.1 (Abnahmeprüfzeugnis) von Bedeutung. Diese Zertifikate stellen sicher, dass die Materialeigenschaften anhand spezifischer Prüfungen nachgewiesen wurden und bestätigen, dass die gelieferten Materialien den festgelegten Qualitäts- und Kundenanforderungen entsprechen. Wichtig ist, dass bei der Prüfbescheinigung vom Typ 3.1 die Prüfung durch einen Prüfer des Herstellers erfolgt, der jedoch nicht der Produktionsabteilung angehören darf.^[54]

Im Hauptteil dieser Arbeit wird zunächst das Lastenheft entwickelt, gefolgt von der Erstellung des Pflichtenhefts. Der Aufbau beider Dokumente orientiert sich an der in Kapitel 2.2 vorgestellten Vorgehensweisen, aus der verschiedene Aspekte ausgewählt wurden.

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

Als Erstes wurde das Lastenheft konzipiert. Hier wurde zunächst die Ist-Situation erfasst und die damit verbundenen Probleme, wie [...] und [...], beschrieben. Anschließend wurden Ziele wie [...] und [...], die [...] entstehen, definiert. Im Folgenden wurden die funktionalen Anforderungen an das System festgelegt sowie die nicht-funktionalen Anforderungen zu den Themen Sicherheit, Belastbarkeit und Benutzbarkeit aufgelistet. Im Anschluss wurde das Pflichtenheft entwickelt, welches konkrete technische Lösungen für die im Lastenheft beschriebenen Anforderungen definiert. Im Mittelpunkt standen dabei der angestrebte Soll-Zustand, die Systemarchitektur, die Benutzeroberflächen, der grobe Projektplan sowie mögliche Weiterentwicklungen und Anpassungen des Systems.

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

In Anbetracht der Tatsache, dass [Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.], kann das beschriebene Vorgehen zur Erstellung eines Lasten- und Pflichtenheftes kritisch hinterfragt werden. Auf diese Problematik wurde bereits in Kapitel 2.3.3 ausführlich eingegangen. Da [Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.], die auf [Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.] zurückzuführen waren, erscheint die Erstellung eines Lasten- und Pflichtenheftes vor diesem Hintergrund gerade für dieses Projekt sinnvoll. Ob das beschriebene Vorgehen tatsächlich erfolgreicher ist, lässt sich erst nach der vollständigen Implementierung und dem Abschluss des Projekts bewerten.

Für diese Konzeption wurde ein selbst entwickelter Aufbau gewählt, der Teile der vorgestellten Herangehensweisen (Kapitel 2.2) enthält. Bei größeren Softwareprojekten empfiehlt es sich, die VDI-Norm 3694 stärker als Orientierung zu nutzen, da diese eine umfassendere Struktur mit zusätzlichen Unterkapiteln bietet. Die Norm beinhaltet Aspekte wie die detaillierte Projektplanung sowie die Definition von Anforderungen an die Systementwicklung, -inbetriebnahme und -einsatz, die in dieser Arbeit aufgrund des begrenzten Umfangs nicht behandelt werden konnten. Auch auf formale Aspekte des Lasten- und Pflichtenheftes wie einem Deckblatt, einer Version und einem Inhaltsverzeichnis musste aus diesem Grund verzichtet werden. Für die Definition der Materialzertifikate musste teilweise auf graue Literatur zurückgegriffen werden.

[Der Abschnitt wurde aus der öffentlichen Version dieser Arbeit entfernt, da er vertrauliche Daten enthält.]

Das Thema Vorgehensmodelle in der Softwareentwicklung konnte nur angerissen werden. In der Praxis werden häufig auch hybride Modelle eingesetzt, die sich nicht eindeutig einem einzelnen Modell zuordnen lassen.^[55]

Alpar, P./Alt, R./Bensberg, F. (u.a.) (2023): Anwendungsorientierte Wirtschaftsinformatik - Strategische Planung, Entwicklung und Nutzung von Informationssystemen, 10. Aufl., Wiesbaden: Springer Vieweg

Bär, C./Fiege, J./Weiß, M. (2017): Anwendungsbezogenes Projektmanagement - Praxis und Theorie für Projektleiter, Berlin: Springer Vieweg

Boehm, B. (1981): Software Engineering Economics, New Jersey: Prentice Hall

Brandt-Pook, H./Kollmeier, R. (2020): Softwareentwicklung kompakt und verständlich - Wie Softwaresysteme entstehen, 3., verbesserte Aufl., Wiesbaden: Springer Vieweg

Broy, M./Kuhrmann, M. (2013): Projektorganisation und Management im Software Engineering, Berlin: Springer Vieweg

Broy, M./Kuhrmann, M. (2021): Einführung in die Softwaretechnik. Berlin: Springer Vieweg

DIN EN 10204:2005-01 (2005): Metallische Erzeugnisse - Arten von Prüfbescheinigungen, Berlin: Beuth Verlag

DIN 69901-5 (2009): Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe, Berlin: Beuth Verlag

Duschl, D. (2024): Software-Fehler erkennen und vermeiden, Wiesbaden: Springer Vieweg

Eisele, O./Harlacher, M./Lennings, F. (2023): Bedarfsgerechte Auswahl und Einführung von KI-Anwendungen, in: Stowasser, S. (Hrsg.): Künstliche Intelligenz (KI) und Arbeit - Leitfaden zur soziotechnischen Gestaltung von KI-Systemen, Berlin: Springer Vieweg

Ernst, H./Schmidt, J./Beneken, G. (2023): Grundkurs Informatik - Grundlagen und Konzepte für die erfolgreiche IT-Praxis – Eine umfassende Einführung, 8. Aufl., Wiesbaden: Springer Vieweg

Friederich, I. (2006): Nach einem Jahr mit der neuen Norm für Prüfbescheinigungen- Viele Fragen offen, in: QZ – Qualität und Zuverlässigkeit, 2006 (5), München: Hanser, S. 48-51

Gagliardi, V. (2021): Decoupled Django - Understand and Build Decoupled Django Architectures for JavaScript Front-ends, New York: Apress

Goldman, S./Nagel, R./Preiss, K. (1995): Agile Competitors and Virtual Organizations - Strategies for Enriching the Customer, New York: Van Nostrand Reinhold

Goll, J. (2011): Methoden und Architekturen der Softwareentwicklung. Wiesbaden: Vieweg+Teubner Verlag

Groß, C./Pfenning, R. (2019): Digitalisierung in Industrie, Handel und Logistik Leitfaden von der Prozessanalyse bis zur Einsatzoptimierung, 2. Aufl., Wiesbaden: Springer Gabler

Hahn, M. (2020): Webdesign – Das Handbuch zur Webgestaltung, 3. Aufl., Bonn: Rheinwerk Verlag

Hammerschall, U./Beneken, G. (2013): Software Requirements, München: Pearson Deutschland GmbH

Hinsch, M./Klarner, A./Berlinger, C. (2022): Einführung in die DEMAR - Strategien und Umsetzung des Zulassungswesens für Luftfahrzeuge der Bundeswehr, Berlin: Springer Vieweg

Hoppen, P. (2015): Software-Anforderungsdokumentation, in: Bartsch, M./Grützmacher, M./Härtling, N. (u.a.): Computer und Recht, 2015 (11), Köln: Otto Schmidt, S. 747-760

ISO/IEC/IEEE (Hrsg.) (2018): 29148:2018-11 - Systems and software engineering – Life cycle processes – Requirements engineering, New York City: IEEE

Jakoby, P. (2024): Agilität in der digitalen Transformation: Scrum als Schlüssel zum Erfolg? in: Bruns, P./Bruns, W. (Hrsg.): Praxishandbuch Kompetenzen in der Digitalen Transformation der Arbeit, Wiesbaden: Springer VS, S. 155-190

Jordan, J. (1997): Enablers for Agile Virtual Enterprise Integration, in: Agility & Global Competition, 1 (3), New Jersey: Wiley, S. 26-46

Kaufmann, J./Mülder, W. (2023): Grundkurs Wirtschaftsinformatik - Eine kompakte und praxisorientierte Einführung, 10. Aufl., Wiesbaden: Springer Vieweg

Krypczyk, V./Bochkor, O. (2018): Handbuch für Softwareentwickler, Bonn: Rheinwerk Verlag

Lettau, C. (2000): Das Web-Pflichtenheft, Bonn: MITP-Verlag GmbH

Lohse, W./Laumann, J./Wolf, C. (2016): Stahlbau 1 - Bemessung von Stahlbauten nach Eurocode mit zahlreichen Beispielen, 25. Aufl., Wiesbaden: Springer Vieweg

Madauss, B.-J. (2020): Projektmanagement - Theorie und Praxis aus einer Hand, 8. Aufl., Berlin: Springer Vieweg

Metzner, A. (2020): Software Engineering – Kompakt, München: Carl Hanser Verlag München

Osterhage, W. (2016): Qualität in der Softwareentwicklung, in: Leyh, C./Schäffer, T. (Hrsg.): Digitale Kompetenzen (HMD), 61 (1), Wiesbaden: Springer Vieweg, S. 153-168

Royce, W. (1970): Managing the development of large systems, in: Proceedings of IEEE Wescon (26), Los Angeles: TRW, S. 1-9

Seelmann, V./Hicking. J. (2022): Projektmanagement, in: Schuh, G./Zeller, V./Stich, V. (Hrsg.): Digitalisierungs- und Informationsmanagement - Handbuch Produktion und Management 9, Berlin: Springer Vieweg, S. 213-248

Stender, P. (2011): Webprojekte realisieren nach neuesten OOP-Kriterien – Ein Workshop über die Kooperation von PHP/XSL/JavaScript, Wiesbaden: Vieweg+Teubner Verlag

Teich, I./Kolbenschlag, W./Reiners, W. (2008): Der richtige Weg zur Softwareauswahl – Lastenheft, Pflichtenheft, Compliance, Erfolgskontrolle, Berlin: Springer

VDI (2001): VDI 2519 Blatt 1 - Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften, Berlin: Beuth Verlag

VDI (2014): VDI 3694 - Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen, Berlin: Beuth Verlag

Wieczorrek, H. W./Mertens, P. (2011): Management von IT-Projekten - Von der Planung zur Realisierung, 4. Aufl., Heidelberg: Springer Berlin

Beck, K./Beedle, M./Beenekum A.v. (u.a.) (2001): Manifest für Agile Softwareentwicklung. agilemanifesto, https://agilemanifesto.org/iso/de/manifesto.html (Abgerufen am 20.10.2024)

LB MetallService AG (o.D.): Materialprüfbescheinigungen. LB MetallService AG, https://www.lb-metallservice.ch/de/materialpruefzertifikate/ (Abgerufen am 20.10.2024)

Vorest AG (o.D.): Prüfbescheinigungen & deren Arten nach DIN EN 10204. Vorest AG, https://www.vorest-ag.com/Qualitaetssicherung-Methoden/Wissen/pruefbescheinigungen (Abgerufen am 20.10.2024)