Softwaremängel technisch untersuchen: Soll-Ist-Vergleich

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.

1. Was wird technisch überhaupt verglichen?

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. Wie wird der technische Soll-Zustand bestimmt?

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.

3. 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.

4. Der Ist-Zustand muss eindeutig bestimmt werden

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.

5. Durchführung des Soll-Ist-Vergleichs

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.

6. Funktionale und qualitative Abweichungen

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.

7. Wie wird eine technische Abweichung formuliert?

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.

8. Widersprüchliche oder unvollständige Soll-Unterlagen

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.

9. Was bedeutet ein fehlender ursprünglicher Softwarestand?

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.

10. Befund, Interpretation und rechtliche Würdigung

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.

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.

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