10. VL Juristisches IT-Projektmanagement 17.12.2022

Neu auf MyUniNotes – Podcasts

Diese Podcasts sind neu verfügbar und bieten eine großartige Zusammenfassung der Vorlesung. Nach Anwesenheit in der Vorlesung und dem anhören der Audios, kann ich mit gutem Gewissen sagen, dass diese die Vorlesung sehr gut zusammenfassen.

Ich freue mich über euer Feedback! Schreibt mir gerne eure Meinungen, Verbesserungsvorschläge oder Anmerkungen unten in die Kommentare.

Umfassende Analyse von Lastenheft, Pflichtenheft und Spezifikation in der Softwareentwicklung

Einleitung

Diese Zusammenfassung befasst sich mit den zentralen Dokumenten der Softwareentwicklung: Lastenheft, Pflichtenheft und Spezifikation.

1. Fachliche Anforderungsspezifikation: Lastenheft und Pflichtenheft

1.1. Lastenheft

Das Lastenheft ist ein Dokument, das vom Auftraggeber erstellt wird. Es bildet die Grundlage der Anforderungsdefinition und beschreibt aus Sicht des Auftraggebers, welche fachlichen Anforderungen die zu entwickelnde Software erfüllen soll.

• Perspektive: Der Fokus liegt klar auf der Auftraggeberperspektive.
• Inhalt:
  • Enthält ausschließlich fachliche Anforderungen, also was die Software leisten soll.
  • Technische Details der Implementierung werden nicht berücksichtigt.
  • Der Auftraggeber formuliert die Anforderungen in seiner eigenen Begriffswelt, ohne Rücksicht auf technische Machbarkeit oder sprachliche Präzision in der IT-Welt.
• Zweck:
  • Dokumentiert die Wünsche und Erwartungen des Auftraggebers.
  • Dient als Grundlage für die weiteren Schritte im Entwicklungsprozess, insbesondere für die Erstellung des Pflichtenhefts.

1.2. Pflichtenheft

Das Pflichtenheft wird vom Auftragnehmer erstellt. Es baut auf dem Lastenheft auf und beschreibt, wie der Auftragnehmer die Anforderungen des Auftraggebers verstanden hat und wie er sie umsetzen will. Es ist eine fachlich-technische Antwort auf das Lastenheft.

• Perspektive: Die Perspektive wechselt nun zum Auftragnehmer.
• Inhalt:
  • Technische Umsetzung der Anforderungen aus dem Lastenheft.
  • Berücksichtigt die technische Realisierbarkeit.
  • Präzisere Beschreibung der Anforderungen als im Lastenheft.
  • Enthält eine konkrete Planung, wie die Anforderungen erfüllt werden sollen.
• Zweck:
  • Dient als Grundlage für die Kalkulation, das technische Konzept (IT-Konzept) und die Realisierung.
  • Stellt ein gemeinsames Verständnis der Anforderungen zwischen Auftraggeber und Auftragnehmer sicher und dient als verbindliche Vorgabe für die Entwicklung.

1.3. Unterschied zwischen Lastenheft und Pflichtenheft

Merkmal	Lastenheft	Pflichtenheft
Ersteller	Auftraggeber	Auftragnehmer
Perspektive	Auftraggeber	Auftragnehmer
Fokus	Was soll die Software leisten? (fachliche Sicht)	Wie sollen die Anforderungen umgesetzt werden? (fachlich-technische Sicht)
Detailgrad	Grob, fachlich	Detaillierter, fachlich und technisch (noch keine Implementierungsdetails, aber technische Machbarkeit)
Realisierung	Muss nicht vollständig realisierbar sein	Beschreibt die geplante, technisch realisierbare Umsetzung
Kostenschätzung	Auf Basis des Lastenhefts nicht zuverlässig möglich	Dient als Grundlage für die detaillierte Kostenschätzung und die Erstellung technischer Konzepte
Technische Details	Nicht enthalten	Noch keine Implementierungsdetails, aber mit Blick auf die prinzipielle technische Machbarkeit formuliert

Beispiel zur Veranschaulichung:

• Lastenheft (Auftraggeber): “Die Software soll eine Adressverwaltung für Kunden ermöglichen.” (Sehr grob und unspezifisch)
• Pflichtenheft (Auftragnehmer): “Die Software wird eine Adressverwaltung für mindestens 200 Kunden bereitstellen. Folgende Datenfelder werden erfasst: Name, Vorname, Straße, Hausnummer, Postleitzahl und Ort. Es wird eine Funktion zur Erstellung von Serienbriefen implementiert. Die Anwendung wird als Client-Server-System mit einer relationalen Datenbank im Backend realisiert. Die Benutzeroberfläche wird webbasiert sein.” (Detaillierter, fachlich und mit ersten technischen Festlegungen)

Wichtiger Hinweis: In der Praxis existiert oft ein begriffliches Durcheinander. Hier im Kontext ist jedoch klar, dass das Lastenheft vom Auftraggeber und das Pflichtenheft vom Auftragnehmer erstellt wird.

2. Anforderungskatalog am Beispiel eines Großkrankenhauses

2.1. Gliederung und Struktur

Ein Anforderungskatalog ist ein umfangreiches Dokument, das in der Regel hierarchisch strukturiert ist. Es untergliedert sich in verschiedene Ebenen, die den Detaillierungsgrad der jeweiligen Anforderung widerspiegeln.

Beispiel Uniklinikum Augsburg:

• Das Uniklinikum Augsburg (1850 Betten) erstellte im Rahmen einer Softwareeinführung einen Anforderungskatalog mit über 5000 Einzelanforderungen.
• Diese Anforderungen waren in sieben Detailtiefen (Ebenen 1-7) unterteilt.
• Ebene 1: Grober Überblick, z. B. “Anforderungskatalog”.
• Ebene 7: Sehr detaillierte Einzelanforderungen.

2.2. Beispielanforderung aus dem Katalog

”Datenübernahme von Flussraten von Motorspritzpumpen via HL7-Standard in die Dokumentation.”

• Kontext: Diese Anforderung stammt aus dem Bereich der Intensivmedizin.
• Erläuterung: Auf Intensivstationen werden Medikamente häufig über Spritzenpumpen verabreicht, die kontinuierlich eine bestimmte Dosis eines Medikaments in den Blutkreislauf des Patienten pumpen. Diese Anforderung beschreibt, dass die Flussrate (also die Dosierung) dieser Pumpen automatisch in das Dokumentationssystem des Krankenhauses übernommen werden soll.
• HL7-Standard: HL7 (Health Level Seven) ist ein internationaler Standard für den Datenaustausch im Gesundheitswesen. Er definiert, wie medizinische Daten zwischen verschiedenen IT-Systemen ausgetauscht werden können.

2.3. Zusätzliche Spalten im Anforderungskatalog und deren Bedeutung

Der Anforderungskatalog des Uniklinikums enthielt neben der Beschreibung der Anforderungen zusätzliche Spalten mit folgenden Kürzeln:

• V (Vorhanden): Die Anforderung kann mit der bestehenden Software des Anbieters erfüllt werden. Die Funktion ist bereits vorhanden.
• N (Nicht vorhanden): Die Anforderung kann mit der bestehenden Software des Anbieters nicht erfüllt werden. Die Funktion ist nicht vorhanden.
• G (Geplant): Die Anforderung soll in einem zukünftigen Release der Software des Anbieters erfüllt werden.
• I (Individuell): Die Anforderung kann durch individuelle Programmierung (Auftragsentwicklung) erfüllt werden. Dies ist oft mit zusätzlichen Kosten verbunden.
• Relativgewicht: Gibt den prozentualen Anteil der jeweiligen Anforderung an der Gesamtfunktionalität eines bestimmten Bereichs an. Z. B. könnte die Anforderung “Schnittstellen zu intensivmedizinischen Geräten” ein Relativgewicht von 30% im Bereich Intensivmedizin haben.

2.4. Zweck und Verwendung des Anforderungskatalogs im Ausschreibungsprozess

Der detaillierte Anforderungskatalog des Uniklinikums diente als Grundlage für eine öffentliche Ausschreibung.

• Bieterwettbewerb: Verschiedene Software-Anbieter konnten Angebote abgeben und mussten in den Spalten (V, N, G, I) angeben, inwieweit ihre Software die Anforderungen erfüllt.
• Punktesystem: Anhand der Angaben der Anbieter und der Relativgewichte der Anforderungen wurde ein Punktesystem angewendet.
• Preis-Leistungs-Verhältnis: Die erreichte Punktzahl (als Maß für die Erfüllung der Anforderungen) wurde in Relation zum Angebotspreis gesetzt, um das wirtschaftlichste Angebot zu ermitteln.
• Ausschluss ungeeigneter Bieter: Im Vorfeld wurden ungeeignete Bieter, z. B. aufgrund mangelnder Größe oder Zuverlässigkeit, ausgeschlossen.

Vorteil dieses Vorgehens:

• Transparenz: Der Ausschreibungsprozess ist transparent und nachvollziehbar.
• Objektivität: Die Vergabe erfolgt auf Basis objektiver Kriterien (erfüllte Anforderungen, Preis).
• Wirtschaftlichkeit: Das wirtschaftlichste Angebot erhält den Zuschlag.

3. Leistungsbeschreibung, Fachkonzept und Pflichtenheft nach DIN 69901-5

3.1. Leistungsbeschreibung

Die Leistungsbeschreibung ist ein Dokument, das die gewünschten Leistungen detailliert spezifiziert. Sie findet häufig im Bauwesen Anwendung, ist aber auch in anderen Branchen üblich.

• Beispiel aus dem Hausbau: “Die Dachhaut wird in Kupfer ausgeführt.” (Spezifiziert die Ausführung der Dachhaut) oder “Die Dachhaut wird in Biberschwanzziegel ausgeführt”

3.2. Fachkonzept

Das Fachkonzept ist eine sehr detaillierte Ausarbeitung der fachlichen Anforderungen. Es geht über eine einfache Auflistung von Anforderungen (wie im Lastenheft) hinaus und beschreibt die gewünschte Funktionalität umfassend in Textform.

• Abgrenzung zum Lastenheft: Das Fachkonzept ist detaillierter und umfangreicher.
• Ersteller: Kann vom Auftraggeber (Lastenheft erweitert) oder Auftragnehmer (Pflichtenheft erweitert) erstellt werden.
• Keine technischen Details: Auch das Fachkonzept enthält noch keine technischen Details zur Implementierung.

3.3. Pflichtenheft nach DIN 69901-5

Die DIN-Norm 69901-5 definiert das Pflichtenheft interessanterweise anders als es im allgemeinen Sprachgebrauch oder oft in der Praxis verwendet wird.

• Definition: “Vom Auftragnehmer erarbeitete Realisierungsvorgabe aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts.”
• Widerspruch zur Praxis: In der Praxis wird der Begriff Pflichtenheft oft fälschlicherweise für das Lastenheft (Dokument des Auftraggebers) verwendet.

3.4. Das fehlende Bindeglied: Das IT-Konzept

Ein wichtiger Punkt, der im Transkript hervorgehoben wird, ist, dass zwischen dem Pflichtenheft (als fachlicher und technischer Vorgabe) und der eigentlichen Programmierung ein entscheidendes Dokument fehlt: das IT-Konzept.

• Pflichtenheft: Definiert, was fachlich umgesetzt werden soll und wie die Anforderungen technisch im Groben erfüllt werden sollen.
• IT-Konzept: Definiert im Detail, wie die Anforderungen technisch realisiert werden sollen (technische Architektur, Technologien, Datenbankdesign, Schnittstellen etc.).
• Programmierung: Die eigentliche Umsetzung auf Basis des IT-Konzepts.

Problem: Der direkte Sprung vom Pflichtenheft zur Programmierung (“Vom Hirn ins Terminal”) ist in professionellen Projekten nicht zielführend und birgt große Risiken (z.B. falsche Technologieentscheidungen, unzureichende Architektur, mangelnde Wartbarkeit).

4. Grob- und Feinspezifikation: Vorgehen und Vorteile

4.1. Grobspezifikation

• Ziel: Eine grobe Planung des Projekts und der Software zu erstellen.
• Vorteil:
  • Ermöglicht eine erste Übersicht über die wesentlichen Funktionalitäten.
  • Anpassungen sind in dieser Phase noch mit geringem Aufwand möglich.
• Umfang: Typischerweise etwa 20-30 Seiten.
• Inhalt: Enthält die grundlegenden Funktionalitäten und eine grobe Beschreibung der Anforderungen.

4.2. Feinspezifikation

• Voraussetzung: Die Grobspezifikation steht fest und wurde vom Auftraggeber freigegeben.
• Ziel: Eine detaillierte Ausarbeitung aller Anforderungen.
• Inhalt: Umfasst eine präzise und umfassende Beschreibung aller Funktionen, Datenstrukturen, Schnittstellen, Benutzeroberflächen etc.

4.3. Vorteile des stufenweisen Vorgehens (Grob- und Feinspezifikation)

• Arbeitsersparnis: Es wird vermieden, viel Arbeit in die Detaillierung von Anforderungen zu stecken, die sich später als unnötig oder nicht umsetzbar erweisen.
• Flexibilität: In der Grobspezifikationsphase können noch leichter Anpassungen vorgenommen werden, ohne dass bereits viel Detailarbeit geleistet wurde.
• Risikominimierung: Durch die stufenweise Verfeinerung wird das Risiko von Fehlplanungen und Missverständnissen reduziert.
• Effizienz: Die Detailarbeit wird erst dann geleistet, wenn die grundlegenden Anforderungen und der grobe Umfang des Projekts feststehen.

4.4. Zusammenhang mit der Projektplanung

• Fachlicher Teil (Verantwortung des Kunden): Die Grobspezifikation dient als Grundlage für die inhaltliche Planung des Projekts aus Sicht des Kunden. Sie legt fest, was der Kunde haben will.
• Technischer Teil (Verantwortung des Auftragnehmers):
  • Technisches Grobkonzept: Grobe Festlegung der Systemarchitektur, der Komponenten, der Datenflüsse etc. (Teil des Pflichtenhefts).
  • Feinspezifikation: Detaillierte technische Planung (Programmiersprachen, Frameworks, Bibliotheken, Schnittstellen etc.). (IT-Konzept)
  • Entwicklung: Eigentliche Programmierung.

5. Inhalte eines Pflichtenhefts: Detaillierte Betrachtung der Kernelemente

Das Pflichtenheft, erstellt vom Auftragnehmer, sollte bestimmte Kernelemente enthalten, um eine klare und vollständige Grundlage für die Softwareentwicklung zu bieten.

5.1. Ziele und Nutzen des Projekts, Ist-Zustand

• Einleitung: Kurze Beschreibung des Projekts und seiner Ziele.
• Projekthintergrund: Erläuterung des Kontexts und der Motivation für das Projekt.
• Abgrenzung (Wichtig!): Explizite Festlegung, was nicht Bestandteil des Projekts ist. Dies hilft, Missverständnisse und unberechtigte Forderungen des Kunden zu vermeiden.
• Ist-Zustand: Beschreibung der aktuellen Situation beim Auftraggeber, z. B. der bestehenden Systeme und Prozesse. Dies ist besonders wichtig, wenn ein Altsystem abgelöst werden soll.

5.2. Systemarchitektur heute

• Beschreibung der bestehenden IT-Landschaft beim Auftraggeber: Welche Systeme sind im Einsatz? Wie sind sie miteinander verbunden?
• Schnittstellen: Welche Schnittstellen existieren zu anderen Systemen? (Besonders wichtig bei der Integration der neuen Software in die bestehende IT-Landschaft)
• Beispiel: Bei der Einführung eines neuen ERP-Systems muss die Schnittstelle zu einem bestehenden Hochregallager berücksichtigt werden, um einen reibungslosen Materialfluss in der Produktion zu gewährleisten.

5.3. Soll-Zustand der Software

Dieser Abschnitt beschreibt detailliert, welche Anforderungen die zu entwickelnde Software aus Sicht des Auftragnehmers erfüllen soll.

• Geschäftsprozesse:
  • Beschreibung der betrieblichen Abläufe beim Auftraggeber, die durch die Software unterstützt werden sollen.
  • Umfasst alle Schritte eines Prozesses, auch solche, die nicht direkt durch die Software abgebildet werden (z. B. manuelle Tätigkeiten).
  • Beispiel: Der Prozess der Patientenaufnahme in einem Krankenhaus von der Ankunft in der Notaufnahme bis zur Erfassung der Patientendaten im System.
• Anwendungsfälle (Use Cases):
  • Beschreiben die Interaktion des Benutzers mit dem IT-System zur Erreichung eines bestimmten Ziels.
  • Fokussieren sich auf die softwaregestützten Anteile eines Geschäftsprozesses.
  • Beispiel: “Patientendaten im System erfassen”, “Rezept ausstellen”, “Laborbefund abrufen”.
• Testfälle (Rot markiert im Transkript - besonders wichtig!):
  • So früh wie möglich im Projektverlauf spezifizieren!
  • Beschreiben, wie die Software getestet werden soll, um sicherzustellen, dass sie die Anforderungen erfüllt.
  • Dienen als Grundlage für die Abnahmekriterien.
  • Vorteil: Der Entwickler kann die Software von Anfang an gegen die Testfälle entwickeln und prüfen, ob sie die Lieferkriterien erfüllt.
• Fachliches Datenmodell:
  • Beschreibung der Datenstrukturen und Datenbeziehungen, die in der Software verwendet werden sollen (z. B. welche Daten zu einem Patienten gespeichert werden: Name, Vorname, Geburtsdatum, Versichertennummer etc.).
• Berechtigungsmodell:
  • Festlegung, welche Benutzer welche Zugriffsrechte auf die Daten und Funktionen der Software haben (z. B. darf ein Arzt in der Finanzbuchhaltung die Gehälter der Chefärzte einsehen?).
• Wiederverwendbare Systemfunktionen:
  • Identifikation von Funktionen, die in verschiedenen Teilen der Software oder in anderen Projekten wiederverwendet werden können (z. B. eine Funktion zur Adressprüfung).
• Nicht-funktionale Anforderungen:
  • Beschreiben Qualitätsmerkmale der Software, die über die reine Funktionalität hinausgehen.
  • Beispiele: Zuverlässigkeit, Benutzbarkeit, Leistung/Effizienz, Portierbarkeit (siehe auch Abschnitt 6).
• Schnittstellen:
  • Technische Spezifikation der Schnittstellen zu anderen Systemen (z. B. Dateiformate, Protokolle, APIs).
  • Schnittstellenkontrakte: Regeln für die Nutzung der Schnittstellen, z. B. maximale Anzahl von Abfragen pro Minute, Zugriffszeiten, Kosten (siehe auch Abschnitt 9.5).
• Systemtechnik und Infrastruktur:
  • Anforderungen an die Hardware- und Softwareumgebung, in der die Software betrieben werden soll (z. B. Server, Betriebssysteme, Datenbanken).
  • Beispiel: Eine hochperformante Software zur Simulation von Marktentwicklungen erfordert möglicherweise Server mit besonders viel Hauptspeicher.
• Fachliche und organisatorische Auswirkungen:
  • Analyse der Auswirkungen der neuen Software auf bestehende Prozesse, Systeme und die Organisation beim Auftraggeber.
  • Beispiel: Die Einführung einer neuen Software zur Berechnung der optimalen Beladung von LKWs mit Paletten kann dazu führen, dass zusätzliches Personal eingestellt werden muss, wenn die Software diese Funktion nicht oder nur unzureichend erfüllt.
• Ausblick auf nächste Stufen (Release-Plan):
  • Planung der weiteren Entwicklung der Software nach der ersten Implementierung (z. B. welche Funktionen sollen in zukünftigen Releases hinzugefügt werden).
• Wirtschaftlichkeitsbetrachtung:
  • Sehr wichtig!
  • Bewertung, ob sich die Investition in die Software aus wirtschaftlicher Sicht lohnt.
  • Beispiel: Eine Software, die 10 Millionen Euro kostet, sollte idealerweise Einsparungen von mehr als 10 Millionen Euro ermöglichen.
  • Fortlaufende Prüfung: Die Wirtschaftlichkeit sollte in jeder Projektphase neu bewertet werden.

5.4. Unterschied zwischen Anwendungsfällen (Use Cases) und Geschäftsprozessen im Detail

• Geschäftsprozesse:
  • Umfassender als Anwendungsfälle.
  • Beschreiben den gesamten Ablauf eines betrieblichen Vorgangs beim Auftraggeber, unabhängig von der IT-Unterstützung.
  • Beinhalten auch manuelle Tätigkeiten oder Schritte, die außerhalb des IT-Systems stattfinden.
  • Beispiel: Der gesamte Prozess der Patientenaufnahme im Krankenhaus, einschließlich des Wartens in der Notaufnahme, des Ausfüllens von Formularen in Papierform und des Gangs zum Arztzimmer, ist ein Geschäftsprozess.
• Anwendungsfälle (Use Cases):
  • Fokussierter als Geschäftsprozesse.
  • Beschreiben die Interaktion eines Benutzers mit dem IT-System, um ein bestimmtes Ziel zu erreichen oder eine bestimmte Aufgabe zu erledigen.
  • Konzentrieren sich auf die softwaregestützten Anteile eines Geschäftsprozesses.
  • Beispiel: “Patientendaten im System erfassen”, “Rezept im System ausstellen”, “Laborbefund im System abrufen” sind Anwendungsfälle, die sich auf die Nutzung der Krankenhaussoftware beziehen.

Zusammenfassend: Geschäftsprozesse bilden den übergeordneten Rahmen, während Anwendungsfälle die konkrete Interaktion mit dem IT-System innerhalb dieses Rahmens beschreiben.

6. Nicht-funktionale Anforderungen: Detaillierte Erläuterung und Beispiele

Nicht-funktionale Anforderungen sind Qualitätsmerkmale einer Software, die nicht direkt mit der eigentlichen Funktionalität zusammenhängen. Sie sind jedoch ebenso wichtig wie funktionale Anforderungen, da sie maßgeblich die Gebrauchstauglichkeit, Zuverlässigkeit und Akzeptanz der Software beeinflussen.

6.1. Wichtige Kategorien nicht-funktionaler Anforderungen

• Zuverlässigkeit:
  • Die Software soll korrekte Ergebnisse liefern.
  • Sie soll stabil laufen und nicht abstürzen.
  • Sie soll immer verfügbar sein, wenn sie benötigt wird.
  • Beispiel: Eine Finanzbuchhaltungssoftware muss korrekte Bilanzen erstellen und darf nicht während der Bearbeitung wichtiger Vorgänge abstürzen.
• Aussehen und Handhabung (Usability):
  • Die Software soll intuitiv bedienbar sein.
  • Die Benutzeroberfläche soll ansprechend gestaltet sein.
  • Die Software soll leicht erlernbar sein.
  • Beispiel: Eine Adressverwaltungssoftware sollte auch für Benutzer ohne umfangreiche IT-Kenntnisse einfach zu bedienen sein.
• Leistung und Effizienz (Performance):
  • Die Software soll schnell reagieren (kurze Antwortzeiten).
  • Sie soll große Datenmengen effizient verarbeiten können.
  • Sie soll sparsam mit Ressourcen (z. B. Hauptspeicher, CPU-Leistung) umgehen.
  • Beispiel: Eine Software zur Simulation von Marktentwicklungen muss in der Lage sein, Millionen von Szenarien in akzeptabler Zeit durchzurechnen.
• Portierbarkeit:
  • Die Software soll leicht anpassbar an veränderte Anforderungen sein.
  • Sie soll leicht erweiterbar um neue Funktionen sein.
  • Sie soll auf verschiedenen Plattformen (z. B. Betriebssystemen, Hardware) lauffähig sein.
  • Beispiel: Eine Software, die in Modulen aufgebaut ist, lässt sich in der Regel leichter anpassen und erweitern als eine monolithische Anwendung.
• Sicherheit:
  • Die Software muss Daten vor unbefugtem Zugriff schützen.
  • Sie muss sicher gegen Angriffe von außen sein.
  • Sie sollte Mechanismen zur Authentifizierung und Autorisierung von Benutzern bereitstellen.
  • Beispiel: Eine Banking-Software muss besonders hohe Sicherheitsanforderungen erfüllen, um die Finanzdaten der Kunden zu schützen.
• Wartbarkeit:
  • Der Code der Software sollte gut strukturiert, verständlich und dokumentiert sein, um die Wartung zu erleichtern.
  • Die Architektur sollte so gestaltet sein, dass Änderungen und Fehlerbehebungen einfach durchgeführt werden können.

6.2. Beispiele aus der Praxis

• Ressourcenbedarf bei BMW: Die Simulation von Marktentwicklungen bei BMW erforderte eine massive Erhöhung des Hauptspeichers der verwendeten Server von ursprünglich geplanten 8 GB auf 160 GB. Dies verdeutlicht, wie wichtig die Anforderung nach Ressourceneffizienz ist.
• Klapperndes Auto: Ein Auto, das klappert, erfüllt zwar seine funktionale Anforderung (es fährt), entspricht aber nicht der nicht-funktionalen Anforderung nach einer ruhigen Fahrt.
• Speicherverwaltung in einem Speichersystem: Ein teures Speichersystem stürzte regelmäßig nach vier Wochen ab, weil ein Fehler in der Speicherverwaltung dazu führte, dass der Speicher volllief (Speicherleck). Dies ist ein Beispiel für eine mangelnde Zuverlässigkeit aufgrund eines Implementierungsfehlers.

6.3. Warum nicht-funktionale Anforderungen oft vernachlässigt werden

• Fokus auf Funktionalität: Bei der Softwareentwicklung liegt der Fokus oft auf der Erfüllung der funktionalen Anforderungen. Nicht-funktionale Aspekte werden als weniger wichtig erachtet oder erst spät im Projektverlauf berücksichtigt.
• Schwierige Messbarkeit: Viele nicht-funktionale Anforderungen sind schwerer zu messen und zu quantifizieren als funktionale Anforderungen.
• Mangelndes Bewusstsein: Oft fehlt das Bewusstsein für die Bedeutung nicht-funktionaler Anforderungen für die Qualität und den Erfolg einer Software.

Fazit: Nicht-funktionale Anforderungen sind essentiell für die Qualität und den langfristigen Erfolg einer Software. Sie sollten daher von Anfang an in der Anforderungsdefinition und der Softwareentwicklung berücksichtigt werden.

7. Verantwortlichkeiten bei der Erstellung des Fachkonzepts und Pflichtenhefts

Die Erstellung des Fachkonzepts und des Pflichtenhefts ist ein iterativer Prozess, der eine enge Zusammenarbeit zwischen Auftraggeber und Auftragnehmer erfordert.

7.1. Verantwortlichkeiten des Auftraggebers

• Lastenheft Erstellung: Der Auftraggeber ist verantwortlich für die Erstellung des Lastenhefts.
• Zieldefinition: Der Auftraggeber muss klar definieren, welche Ziele mit der Software erreicht werden sollen und welchen Nutzen er sich davon verspricht.
• Bereitstellung von Informationen und Unterlagen: Der Auftraggeber ist dafür verantwortlich, dem Auftragnehmer alle notwendigen Informationen und Unterlagen zur Verfügung zu stellen, die dieser für die Erstellung des Fachkonzepts und Pflichtenhefts benötigt. Dies ist besonders wichtig für die Ist-Analyse.
• Definition der Anforderungen: Der Auftraggeber muss die fachlichen Anforderungen an die Software im Lastenheft definieren. Hierbei ist er insbesondere für die gesetzlichen Vorgaben (Compliance) verantwortlich, z. B.:
  • Datenschutz-Grundverordnung (DSGVO): Regelt den Schutz personenbezogener Daten.
  • Grundsätze ordnungsmäßiger Buchführung (GoBD): Anforderungen an Buchhaltungssysteme.
  • Basel II/III: Eigenkapital- und Liquiditätsvorschriften für Banken.
  • Branchenspezifische Regularien: Z. B. im Versicherungswesen oder in der Pharmaindustrie.
• Freigabe von verfeinerten Anforderungen: Der Auftraggeber muss die vom Auftragnehmer ausgearbeiteten und verfeinerten Anforderungen im Fachkonzept und Pflichtenheft prüfen und freigeben.
• Aussagen zur Einführbarkeit von Stufen: Der Auftraggeber sollte festlegen, in welchen Stufen (Releases) die Software eingeführt werden soll.

7.2. Verantwortlichkeiten des Auftragnehmers

• Pflichtenheft Erstellung: Der Auftragnehmer verantwortlich für die Erstellung des Pflichtenhefts auf Basis des Lastenhefts.
• Methodisches Vorgehen: Der Auftragnehmer schlägt eine methodische Vorgehensweise bei der Erstellung des Fachkonzepts und Pflichtenhefts vor. In der Regel folgt er aber den Vorgaben des Kunden.
• Verfeinerte Anforderungen: Der Auftragnehmer arbeitet die Anforderungen des Auftraggebers detaillierter aus und formuliert sie in einer präziseren Form im Fachkonzept und Pflichtenheft.
• Vorschläge für die Stufenplanung: Der Auftragnehmer kann Vorschläge für die stufenweise Einführung der Software machen.
• Schätzung der Realisierungskosten: Der Auftragnehmer muss die Kosten für die Realisierung der Software auf Basis des Pflichtenhefts schätzen.
• Klärung von organisatorischen Auswirkungen: Der Auftragnehmer sollte die organisatorischen Auswirkungen der Softwareeinführung analysieren und den Auftraggeber darauf hinweisen (z. B. zusätzlicher Personalbedarf, Schulungsbedarf).
• Abweisung unberechtigter Anforderungen: Der Auftragnehmer muss unberechtigte oder nicht realisierbare Anforderungen des Auftraggebers abweisen.

Wichtig: Eine gute Kommunikation und Zusammenarbeit zwischen Auftraggeber und Auftragnehmer ist entscheidend für die Erstellung eines qualitativ hochwertigen Fachkonzepts und Pflichtenhefts.

8. Mögliche Pannen bei der Spezifikation/Pflichtenheft und juristische Konsequenzen

In der Praxis kommt es immer wieder zu Problemen mit der Spezifikation bzw. dem Pflichtenheft. Diese können erhebliche juristische und finanzielle Konsequenzen nach sich ziehen.

8.1. Fehlendes Pflichtenheft

• Fallbeschreibung: Der Auftraggeber äußert seine Anforderungen im Lastenheft, der Auftragnehmer entwickelt die Software ohne ein vollständiges Pflichtenheft. Bei der Abnahme ist der Auftraggeber unzufrieden.
• BGH-Urteil: In einem solchen Fall ist ein Ergebnis geschuldet, das dem Stand der Technik bei einem mittleren Ausführungsstandard entspricht.
  • ”Mittlerer Ausführungsstandard”: Weder Luxusausführung noch Billiglösung, sondern eine solide, dem Stand der Technik entsprechende Lösung.
• Weiteres BGH-Urteil (Vergessenes Pflichtenheft): Wenn die Parteien die Erstellung eines Pflichtenhefts vereinbart hatten, die Entwicklung aber ohne Pflichtenheft durchgeführt wurde, wird das Pflichtenheft durch die tatsächliche Auftragsdurchführung obsolet.
  • Wichtige Konsequenz: Der tatsächliche Projektverlauf hat Vorrang vor der ursprünglichen Vereinbarung, wenn kein Widerspruch erfolgt. Der Auftraggeber kann sich dann nicht mehr auf die ursprüngliche Vereinbarung berufen, wenn er die Abweichung vom Vertrag widerspruchslos hinnimmt.

8.2. Unvollständiges oder nicht ausreichend detailliertes Pflichtenheft

• Fallbeschreibung: Der Auftragnehmer erstellt ein Pflichtenheft, das nicht in allen Punkten detailliert ist. Der Auftragnehmer realisiert die Software auf Basis dieses Pflichtenhefts. Es kommt zum Streit über einzelne Detailfunktionen.
• Rechtliche Konsequenz: Auch in diesem Fall gilt der mittlere Ausführungsstandard.
• Feststellung der Anforderungen: Der Tatrichter muss (ggf. mit Hilfe eines Sachverständigen) feststellen, welche Anforderungen sich im Einzelnen aus dem mittleren Ausführungsstandard ergeben.

8.3. Lückenhaftes Pflichtenheft

• Beispiel: In einer Adressenverwaltungssoftware fehlt die Spezifikation einer postalischen Adressprüfung.
• Frage: Ist die Funktion geschuldet oder nicht?
• Antwort: Es kommt darauf an!
  • Kleiner Friseurladen (200 Kunden): Die Funktion ist wahrscheinlich nicht geschuldet, wenn sie nicht explizit vereinbart wurde.
  • Großkonzern (z. B. BMW mit Millionen von Kunden): Die Funktion ist wahrscheinlich geschuldet, auch wenn sie nicht explizit vereinbart wurde, da sie bei einer so großen Anzahl von Adressen üblich und notwendig ist.

8.4. Widersprüchliches Pflichtenheft

• Beispiel: Im Pflichtenheft steht an einer Stelle, dass die Software drucken können muss, und an anderer Stelle, dass sie nicht drucken können soll.
• Pflicht des Auftragnehmers: Wenn der Auftragnehmer einen Widerspruch im Pflichtenheft bemerkt, muss er den Auftraggeber darauf hinweisen.
• Rechtliche Konsequenz bei Unterlassung: Wenn der Auftragnehmer den Auftraggeber nicht auf den Widerspruch hinweist, haftet er für die widersprüchliche Ausführung.

8.5. Prüfungspflichten des Auftragnehmers

• Frage: Muss der Auftragnehmer das Lastenheft oder die Vorgaben des Auftraggebers vor Vertragsschluss auf Fehler, Lücken oder Widersprüche prüfen?
• Antwort: Ja, wenn der Auftragnehmer etwas bemerkt, was nicht richtig sein kann, dann hat er die Pflicht, den Auftraggeber darauf hinzuweisen. Ansonsten haftet er für die Ausführung, obwohl er wusste, dass es nicht richtig sein kann. Er muss vor der Annahme des Auftrags prüfen, ob das Lastenheft in sich schlüssig und widerspruchsfrei ist.

9. Hierarchie der Beschaffenheitsebenen: Ein juristisches Sicherheitsnetz

Die Hierarchie der Beschaffenheitsebenen ist ein wichtiges juristisches Konstrukt, das hilft, Streitigkeiten über die geschuldete Beschaffenheit einer Software zu lösen, wenn die Spezifikation (Pflichtenheft, Vertrag) lückenhaft oder unklar ist.

9.1. Ebene 1: Vereinbarte Beschaffenheit (Fortsetzung)

• Inhalt: Was explizit im Vertrag oder in Vertragsanlagen (z. B. Spezifikation, Pflichtenheft, Lastenheft) vereinbart wurde, gilt immer.
• Vorrang: Diese Ebene hat absoluten Vorrang vor allen anderen Ebenen.
• Beispiel: Wenn im Vertrag steht, dass keine Online-Dokumentation und kein Anwenderhandbuch geliefert werden müssen, dann ist dies bindend.

9.2. Ebene 2: Nach dem Vertrag vorausgesetzte Verwendung

• Inhalt: Wenn Ebene 1 keine oder keine eindeutige Regelung enthält, dann gelten die Beschaffenheiten, die sich aus der nach dem Vertrag vorausgesetzten Verwendung der Software ergeben.
• Ableitung: Man muss sich fragen, welchen Zweck die Software beim Auftraggeber erfüllen soll und welche Eigenschaften sie dafür benötigt. Der Kontext der Nutzung ist entscheidend.
• Beispiel:
  • Eine Adressverwaltung für einen Konzern mit 20 Millionen Kunden muss performant sein und schnelle Antwortzeiten liefern, auch wenn dies nicht explizit im Vertrag steht. Der Umfang der Nutzung (20 Millionen Datensätze) impliziert die Anforderung an die Performance.
  • Eine Software, die bei einem Friseurladen mit 200 Adressen langsam ist, mag dort akzeptabel sein (geringe Anforderungen an die Performance). Bei einem Großkonzern wäre sie es nicht.

9.3. Ebene 3: Gewöhnliche Verwendung und Üblichkeit

• Inhalt: Wenn auch Ebene 2 keine eindeutige Regelung ergibt, dann gelten die Beschaffenheiten, die sich aus der Eignung für die gewöhnliche Verwendung ergeben und die bei Sachen/Werken gleicher Art üblich sind und die der Besteller (Auftraggeber) nach Art des Werkes erwarten kann.
• Fokus: Hier geht es um den allgemeinen Standard in der Branche und die berechtigten Erwartungen des Auftraggebers, basierend auf vergleichbaren Produkten.
• Beispiel:
  • Vorschaufunktion in einer Finanzbuchhaltungssoftware: Wenn eine solche Funktion bei vergleichbaren Produkten (z. B. von SAP, Microsoft) üblich ist, dann kann der Auftraggeber sie auch von einer anderen Finanzbuchhaltungssoftware erwarten, selbst wenn sie nicht explizit vereinbart wurde.
  • Adressprüfung: Eine Adressprüfungsfunktion mag bei einer Software für einen kleinen Friseurladen unüblich sein, ist aber bei einer Software für einen Großkonzern mit Millionen von Adressen üblich und zu erwarten.

9.4. Bedeutung der Hierarchie

• Juristisches Sicherheitsnetz: Die Hierarchie der Beschaffenheitsebenen stellt sicher, dass es immer eine Lösung für Streitigkeiten über die geschuldete Beschaffenheit einer Software gibt, selbst wenn der Vertrag und die Spezifikationen lückenhaft sind.
• Auffangfunktion von Ebene 3: Die Ebene 3 (“gewöhnliche Verwendung”) dient als Auffangtatbestand, der greift, wenn die Ebenen 1 und 2 keine Regelung bieten.
• Sachverständigenhilfe: Die Feststellung, was “gewöhnliche Verwendung” und “üblich” ist, erfolgt häufig mit Hilfe von Sachverständigen, die vom Gericht bestellt werden.

Zusammenfassung der Hierarchie:

1. Vereinbarte Beschaffenheit: Was steht explizit im Vertrag? (Gilt immer!)
2. Vorausgesetzte Verwendung: Was ergibt sich aus dem Vertragszweck und dem Nutzungskontext?
3. Gewöhnliche Verwendung: Was ist bei vergleichbarer Software üblich und was kann der Auftraggeber erwarten?

9.5. Schnittstellenkontrakte: Mehr als nur Technik

Schnittstellenkontrakte sind ein wichtiger Bestandteil von Pflichtenheften und IT-Konzepten. Sie regeln nicht nur die technischen Aspekte einer Schnittstelle, sondern auch organisatorische und vertragliche Aspekte.

• Technische Spezifikation:
  • Datenformate (z. B. XML, JSON)
  • Protokolle (z. B. HTTP, SOAP)
  • APIs (Application Programming Interfaces)
• Inhaltliche Regelungen im Schnittstellenkontrakt:
  • Zugriffsrechte: Wer darf auf die Schnittstelle zugreifen?
  • Zugriffszeiten: Zu welchen Zeiten ist die Schnittstelle verfügbar? (z. B. Montag bis Freitag, 8-17 Uhr)
  • Performance: Wie viele Anfragen pro Sekunde/Minute sind erlaubt? Welche Antwortzeiten werden garantiert?
  • Kosten: Werden für die Nutzung der Schnittstelle Gebühren erhoben? (z. B. 5 Cent pro Zugriff)
  • Verfügbarkeit: Welche Verfügbarkeit wird garantiert? (z. B. 99,9% im Jahresmittel)
  • Datenschutz: Regelungen zur Einhaltung des Datenschutzes.
  • Haftung: Regelungen zur Haftung bei Fehlern oder Ausfällen.

Beispiel:

Ein Unternehmen möchte auf die Kundendatenbank einer anderen Abteilung zugreifen. Der Schnittstellenkontrakt könnte regeln, dass pro Minute maximal 1000 Adressen abgefragt werden dürfen, die Schnittstelle nur werktags von 8-17 Uhr verfügbar ist und jeder Zugriff 5 Cent kostet.

Wichtig: Schnittstellenkontrakte gehen über die rein technische Spezifikation hinaus und regeln auch wirtschaftliche und organisatorische Aspekte der Schnittstellennutzung. Sie sind daher ein wichtiges Instrument zur Steuerung und Kontrolle von Schnittstellen in komplexen IT-Systemen.

10. Schlussbetrachtung und Ausblick

Die Erstellung von Lastenheften, Pflichtenheften und IT-Konzepten ist ein komplexer und anspruchsvoller Prozess, der sorgfältige Planung, klare Kommunikation und eine enge Zusammenarbeit zwischen Auftraggeber und Auftragnehmer erfordert.

Wichtige Erkenntnisse:

• Klare Unterscheidung: Auftraggeber erstellt Lastenheft (Was?), Auftragnehmer erstellt Pflichtenheft (Wie?).
• Detaillierungsgrad: Stufenweises Vorgehen von Grob- zu Feinspezifikation.
• Nicht-funktionale Anforderungen: Ebenso wichtig wie funktionale Anforderungen.
• Juristische Absicherung: Hierarchie der Beschaffenheitsebenen als Sicherheitsnetz.
• Schnittstellenkontrakte: Umfassende Regelung der Schnittstellennutzung.
• Kommunikation und Zusammenarbeit: Entscheidend für den Projekterfolg.

Ausblick:

Die im Transkript erwähnten Online-Veranstaltungen zu Themen wie KI, öffentlichen Ausschreibungen und dem Data Act werden die hier behandelten Grundlagen weiter vertiefen und einen Einblick in aktuelle Entwicklungen in der IT-Branche geben.

Schlussworte des Dozenten:

Der Dozent bedankt sich bei den Studierenden, wünscht frohe Weihnachten und kündigt an, dass die Vorlesung im Januar online per Zoom fortgesetzt wird. Er weist darauf hin, dass die studentischen Vorträge im Januar wichtige und aktuelle Themen behandeln werden. Die Klausur wird die Folien 1-138 umfassen, sowie ausgewählte Themen aus den studentischen Vorträgen.

---