Software & Quellcode
Wird beanstandet, dass eine Software nicht die erwarteten Funktionen oder Qualitätsmerkmale besitzt, beginnt eine technische Untersuchung nicht mit der Aussage, es liege ein „Mangel“ vor. Zunächst muss nachvollziehbar bestimmt werden, welches technische Soll gelten soll, welcher konkrete Softwarestand untersucht wird und anhand welcher Kriterien beide Zustände verglichen werden.
Kurzantwort
Ein technischer Soll-Ist-Vergleich besteht aus vier voneinander zu trennenden Schritten: dokumentiertes Soll bestimmen, relevanten Ist-Zustand eindeutig festlegen, prüfbare Kriterien ableiten und beobachtete Abweichungen reproduzierbar dokumentieren.
Das technische Ergebnis lautet daher beispielsweise, dass eine definierte Funktion in einem bestimmten Softwarestand fehlt oder ein festgelegtes Prüfkriterium unter dokumentierten Bedingungen nicht erfüllt wird. Ob daraus rechtlich ein Mangel oder eine bestimmte Rechtsfolge folgt, ist davon zu trennen.
Von der Anforderung zum begrenzten technischen Befund
1. Untersuchungsgegenstand und Vergleichsfrage bestimmen
Ein Soll-Ist-Vergleich setzt zwei hinreichend bestimmte Zustände voraus. Das Soll beschreibt die technischen Funktionen, Eigenschaften oder Qualitätsmerkmale, die als Prüfmaßstab verwendet werden. Das Ist beschreibt die tatsächlich untersuchte Software einschließlich ihres Versions- und Umgebungsbezugs.
Ohne diese Zuordnung besteht das Risiko, Anforderungen aus einem Zeitpunkt mit einer Softwarefassung aus einem anderen Zeitpunkt zu vergleichen. Eine solche Vermischung kann die Aussagekraft der Untersuchung erheblich einschränken.
2. Technischen Soll-Zustand nachvollziehbar bestimmen
Der technische Soll-Zustand kann sich aus mehreren dokumentierten Quellen ergeben. Abhängig vom Projekt kommen beispielsweise in Betracht:
- Lasten- und Pflichtenhefte,
- technische Leistungsbeschreibungen,
- Software Requirements Specifications,
- User Stories und Akzeptanzkriterien,
- Schnittstellen- und Datenformatspezifikationen,
- Change Requests und freigegebene Änderungen,
- Test- und Abnahmekriterien,
- technische Protokolle, in denen Anforderungen konkretisiert wurden.
Für die technische Untersuchung ist zu dokumentieren, welche dieser Unterlagen als Prüfgrundlage verwendet werden und auf welchen Versions- oder Zeitstand sie sich beziehen.
Anforderungen müssen in prüfbare Kriterien überführt werden
Dokumentierte Anforderungen sind nicht immer unmittelbar als Testkriterium verwendbar. Aussagen wie „die Anwendung soll schnell sein“ oder „die Bedienung soll intuitiv sein“ benötigen für einen reproduzierbaren technischen Vergleich zunächst einen konkretisierten Prüfmaßstab.
Ein Prüfkriterium sollte erkennen lassen, welcher Ausgangszustand vorausgesetzt wird, welche Aktion oder Messung erfolgt und welches Ergebnis als erwarteter Zustand dokumentiert ist.
Welche technische Eigenschaft ist dokumentiert?
Für welchen Softwarestand gilt die Untersuchung?
Welche Umgebung, Eingabedaten und Konfiguration werden verwendet?
Welche Funktion wird ausgeführt oder welche Eigenschaft wird gemessen?
Welches Ergebnis entspricht dem dokumentierten Soll?
Was tritt beim konkreten Ist-Zustand tatsächlich auf?
3. Technischen Ist-Zustand eindeutig bestimmen
Die Aussage „die Software funktioniert nicht“ bezeichnet noch keinen reproduzierbaren Untersuchungsgegenstand. Festzuhalten ist vielmehr, welche konkrete Softwarefassung geprüft wurde.
Bei versionsverwalteter Software können dafür beispielsweise relevant sein:
- Commit- oder Revisionskennung,
- Release und Tag,
- zugehöriges Build-Artefakt,
- verwendete Abhängigkeiten,
- Konfiguration,
- Datenbank- oder Datenstand,
- Laufzeit- und Betriebsumgebung.
Die offizielle Git-Dokumentation beschreibt Revisionsparameter unter anderem als Möglichkeit, konkrete Commit-Objekte eindeutig zu bezeichnen. Ein solcher Bezug kann deshalb ein Bestandteil der technischen Identifikation des Prüfgegenstands sein.
4. Soll-Ist-Vergleich methodisch durchführen
Ein Test benötigt einen Maßstab, an dem das beobachtete Verhalten als erwartet oder abweichend eingeordnet wird (Test Oracle). Ist die Soll-Beschreibung unvollständig oder widersprüchlich, kann ein bestandener Test nur das geprüfte Kriterium bestätigen; er beweist nicht jede denkbare Anforderung an die Software.
Die eigentliche Untersuchung sollte so dokumentiert werden, dass ein fachkundiger Dritter nachvollziehen kann, wie der Befund entstanden ist.
Dazu gehören insbesondere:
- verwendete Anforderungsquelle,
- konkret untersuchter Softwarestand,
- Test- oder Messumgebung,
- Eingabedaten und Vorbedingungen,
- einzelne Prüfschritte,
- erwartetes Ergebnis,
- beobachtetes Ergebnis,
- Logs, Screenshots, Messwerte oder andere technische Nachweise,
- bekannte Einschränkungen der Untersuchung.
| Schritt | Zu dokumentieren | Typische Fehlerquelle |
|---|---|---|
| Soll | Anforderungsquelle, Version und erwartetes Ergebnis | unbestimmte oder widersprüchliche Anforderungen |
| Ist | Softwarestand, Build, Konfiguration und Umgebung | Prüfung eines anderen Zustands als des maßgeblichen |
| Prüfung | Vorbedingungen, Eingaben, Handlung und Messmethode | nicht reproduzierbare oder implizite Testbedingungen |
| Befund | erwartetes und beobachtetes Ergebnis samt Nachweisen | Bewertung oder Rechtsfolge wird mit Beobachtung vermischt |
Funktionale und qualitative Abweichungen unterscheiden
Nicht jede technische Beanstandung betrifft eine vollständig fehlende Funktion. Ein Soll-Ist-Vergleich kann sich auch auf Qualitätsmerkmale einer Software beziehen, beispielsweise Zuverlässigkeit, Performance, Sicherheit oder Wartbarkeit.
ISO/IEC 25010:2023 stellt hierfür ein Produktqualitätsmodell bereit. Die dort beschriebenen Qualitätsmerkmale können als fachlicher Bezugsrahmen dienen, wenn Anforderungen, Testziele, Qualitätskriterien oder Akzeptanzkriterien systematisch strukturiert werden sollen.
Die bloße Nennung eines Qualitätsmerkmals ersetzt jedoch kein konkretes Prüfkriterium für den Einzelfall. Es muss weiterhin festgelegt werden, welche Eigenschaft mit welcher Methode untersucht wird.
Eine technische Abweichung präzise formulieren
Ein belastbarer Befund sollte den Vergleich möglichst konkret beschreiben. Statt einer pauschalen Aussage wie „die Software ist mangelhaft“ kann beispielsweise festgehalten werden, dass ein definiertes Akzeptanzkriterium in einem konkret bezeichneten Release unter dokumentierten Testbedingungen nicht erfüllt wurde.
Dadurch bleibt erkennbar, was unmittelbar beobachtet wurde und welcher Teil bereits fachliche Interpretation ist.
Warum beweist ein bestandener Test nicht automatisch, dass die gesamte Software dem Soll entspricht?
Ein Test kann nur das Kriterium bewerten, für das ein nachvollziehbarer Prüfmaßstab, definierte Bedingungen und ein erwartetes Ergebnis vorliegen.
- Ungeprüfte Anforderungen werden durch einen erfolgreichen Einzeltest nicht mitbestätigt.
- Ein anderer Software-, Daten- oder Umgebungsstand kann zu einem anderen Ergebnis führen.
- Widersprüchliche Soll-Unterlagen begrenzen die technische Bewertbarkeit.
- Der technische Testbefund ersetzt keine rechtliche Einordnung als Mangel.
5. Unvollständige oder widersprüchliche Grundlagen behandeln
In realen Projekten ist der dokumentierte Soll-Zustand nicht immer widerspruchsfrei. Ein Pflichtenheft kann beispielsweise von späteren Change Requests, Tickets oder Abnahmeunterlagen abweichen.
In diesem Fall sollte die technische Untersuchung die unterschiedlichen Fassungen transparent gegenüberstellen, ihren jeweiligen Zeitbezug dokumentieren und deutlich machen, welche Variante für welchen Prüfschritt verwendet wurde.
Kann kein hinreichend bestimmter technischer Soll-Zustand rekonstruiert werden, begrenzt dies die Reichweite des möglichen Gutachtenergebnisses.
Ein fehlender ursprünglicher Softwarestand begrenzt die Aussage
Auch der Ist-Zustand kann unvollständig dokumentiert sein. Fehlt beispielsweise der tatsächlich ausgelieferte oder abgenommene Softwarestand, darf eine spätere Fassung nicht ohne Weiteres als identischer Untersuchungsgegenstand behandelt werden.
In solchen Fällen ist zu dokumentieren, welche Rekonstruktion technisch möglich ist, welche Annahmen erforderlich sind und welche Aussagen wegen fehlender Artefakte gerade nicht getroffen werden können.
6. Befund, Interpretation und rechtliche Würdigung trennen
Der technische Befund hält fest, welche Übereinstimmung oder Abweichung zwischen dem verwendeten Soll-Kriterium und dem untersuchten Ist-Zustand festgestellt wurde.
Die fachliche Interpretation kann anschließend erläutern, welche technische Bedeutung die Abweichung besitzt, welche Systembestandteile betroffen sind und welche Aussagegrenzen bestehen.
Ist der Soll-Ist-Vergleich technisch belastbar?
- Ist der technische Untersuchungsgegenstand bestimmt?
- Ist der herangezogene Soll-Zustand nachvollziehbar belegt?
- Sind Anforderungen in beobachtbare Prüfkriterien überführt?
- Ist der untersuchte Ist-Stand eindeutig versioniert?
- Sind Prüfbedingungen und Erfolgskriterien dokumentiert?
- Werden funktionale und qualitative Abweichungen sachgerecht unterschieden?
- Werden widersprüchliche oder fehlende Soll-Unterlagen als Unsicherheit behandelt?
- Bleibt die rechtliche Mangelbewertung von der technischen Feststellung getrennt?
Konstruiertes Beispiel
Für eine Individualsoftware ist in einem freigegebenen Anforderungsdokument beschrieben, dass ein Export bestimmte Datensätze in einem definierten Format erzeugen soll. Zusätzlich liegt ein gekennzeichnetes Release mit zugehörigem Git-Commit vor.
Für die Untersuchung wird zunächst dokumentiert, welche Anforderungsfassung für den relevanten Zeitpunkt verwendet wird. Anschließend werden Eingabedaten, Systemumgebung und erwartetes Exportformat festgelegt und der Test am bezeichneten Release ausgeführt.
Ergibt der Test ein abweichendes Dateiformat, kann dieser Unterschied als technischer Befund dokumentiert werden. Die rechtliche Bedeutung dieses Befunds ist davon getrennt zu beurteilen.
Das Beispiel ist vollständig konstruiert und stellt kein reales Mandat und keine gerichtliche Beauftragung dar.
Quellen und fachliche Grundlage
- Wissenschaftliche Facharbeit Earl T. Barr et al.: The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering 41(5) (2015), 507–525, insbesondere Einleitung und Begriffsdefinitionen. Erläutert die Grenze zwischen Testeingabe, beobachtetem Verhalten und begründetem Soll; keine Feststellung eines konkreten Softwaremangels. Geprüft am 19.10.2026.
- Normative Primärquelle ISO/IEC/IEEE 29148:2018: Systems and software engineering – Life cycle processes – Requirements engineering. Offizielle ISO-Produktseite . Geprüft am 19.10.2026.
- Normative Primärquelle ISO/IEC 25010:2023: Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Product quality model. Offizielle ISO-Produktseite . Geprüft am 19.10.2026.
- Technische Primärquelle Git-Projekt: gitrevisions – offizielle Dokumentation . Geprüft am 19.10.2026.
- Eigene Fachliteratur Mathias Ellmann: Von Code zu Lösungen im Software Engineering mit Java . Fachlicher Hintergrund zu Anforderungen, Implementierung, Qualität und Fehleranalyse.
- Eigene fachliche Einordnung Die konkrete Untersuchungsstruktur des Soll-Ist-Vergleichs ist eine methodische sachverständige Einordnung. Der tatsächliche Prüfmaßstab wird aus der jeweiligen technischen Fragestellung und der dokumentierten Untersuchungsgrundlage abgeleitet.
Weiterführende Beiträge
Welche Unterlagen für die Bestimmung von Soll- und Ist-Zustand benötigt werden können, erläutert der Beitrag Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware?
Wie der für einen Soll-Ist-Vergleich relevante Softwarestand technisch bestimmt und dokumentiert werden kann, erläutert der Beitrag Welche Softwareversion muss ein Sachverständiger untersuchen? .
Wenn der untersuchte Ist-Zustand aus einem Repository oder Quellcodebestand abgeleitet wird, erläutert der Beitrag Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build die technische Dokumentation von Repository-Zustand und Build-Bezug.
Der allgemeine Quellen- und Dokumentationsstandard des Wissensbereichs ist unter Quellen und Methodik beschrieben.
Kritische Gegenprüfung und methodische Aussagegrenze
Eine beobachtete Soll-Ist-Abweichung ist zunächst ein technischer Befund. Vor der Mangelbewertung müssen Sollquelle, Systemstand und konkurrierende Ursachen der Abweichung geprüft werden.
- Sollquelle prüfen: Vertragliche Beschreibung, Spezifikation, Ticket, Abnahmekriterium und tatsächlicher Produktstand können voneinander abweichen.
- Umgebung als Alternativerklärung: Datenstand, Konfiguration, Berechtigung, Browser, Betriebssystem oder externe Dienste können ein Fehlverhalten auslösen, ohne dass der Quellcode allein ursächlich ist.
- Einzeltest begrenzt Aussage: Ein reproduzierter Fehler belegt den dokumentierten Pfad; ein bestandener Test beweist nicht die Fehlerfreiheit außerhalb des geprüften Bereichs.
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Software- und Quellcode-Gutachten
Wenn dokumentierte Anforderungen mit einem konkreten Softwarestand verglichen werden sollen, können zunächst Untersuchungsgegenstand, Soll-Grundlage und Prüfkriterien eingegrenzt werden.
Software-Gutachten ansehen