Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware?

Software & Quellcode

Bei Streit über eine individuell entwickelte Software reicht die installierte Anwendung allein häufig nicht aus, um technische Ursachen, Entwicklungsstand und Abweichungen nachvollziehbar zu untersuchen. Entscheidend ist, welche Anforderungen vereinbart oder dokumentiert wurden, welcher konkrete Softwarestand untersucht werden soll und welche technischen Nachweise zu diesem Stand vorliegen.

1. Zuerst muss die technische Fragestellung feststehen

Die Unterlagen werden nicht abstrakt gesammelt. Sie müssen zur technischen Frage passen. Soll beispielsweise untersucht werden, ob eine bestimmte Funktion im abgenommenen Softwarestand vorhanden war, sind andere Nachweise erforderlich als bei der Frage nach Codequalität, Performance oder einer später eingetretenen Regression.

Eine erste Sichtung sollte deshalb klären, welcher technische Zustand untersucht werden soll, für welchen Zeitpunkt die Aussage gelten soll und welche konkrete Eigenschaft Gegenstand der Prüfung ist.

2. Anforderungen und dokumentierter Soll-Zustand

Für einen technischen Soll-Ist-Vergleich muss nachvollziehbar sein, welche technischen Funktionen oder Eigenschaften als Untersuchungsmaßstab herangezogen werden sollen. Dafür können insbesondere folgende Unterlagen relevant sein:

• Lastenheft und Pflichtenheft,
• technische Leistungsbeschreibungen,
• User Stories und Akzeptanzkriterien,
• Änderungsanforderungen und Change Requests,
• Abnahme- und Testkriterien,
• technische Anlagen zu Angeboten oder Verträgen,
• Protokolle, in denen technische Anforderungen konkretisiert oder geändert wurden.

3. Eindeutiger Software- und Quellcodestand

Eine technische Prüfung benötigt einen reproduzierbar bestimmbaren Untersuchungsgegenstand. Bei versionsverwalteter Software sollte daher möglichst nicht nur ein Ordner mit Quellcodedateien übergeben werden.

Hilfreich sind insbesondere:

• Repository oder dokumentierter Repository-Export,
• konkrete Commit- oder Revisionskennung,
• relevante Branch- und Tag-Bezeichnungen,
• Release-Bezeichnung und Build-Artefakt,
• Build-Anleitung und verwendete Tool-Versionen,
• Abhängigkeitsdateien und Lock-Dateien,
• Konfigurationsdateien, soweit sie den untersuchten Zustand beeinflussen.

Der Versionsbezug ist entscheidend, weil unterschiedliche Commits oder Releases unterschiedliche technische Eigenschaften besitzen können. Die offizielle Git-Dokumentation beschreibt Revisionen als Bezeichner für konkrete Commit-Objekte beziehungsweise für Mengen erreichbarer Commits.

4. Fehlerberichte, Tests und Reproduktionsschritte

Wird ein konkreter Fehler behauptet, muss nachvollzogen werden können, unter welchen Bedingungen er aufgetreten ist. Besonders nützlich sind:

• Ticket oder Fehlerbericht mit Zeitpunkt,
• genaue Reproduktionsschritte,
• erwartetes und beobachtetes Verhalten,
• automatisierte oder manuelle Testfälle,
• Testberichte und CI-Ergebnisse,
• Screenshots oder Bildschirmaufzeichnungen mit nachvollziehbarem Kontext,
• Logdateien und Fehlermeldungen,
• Information darüber, in welcher Softwareversion der Fehler beobachtet wurde.

Ein Fehlerbericht ohne Versions- und Umgebungsbezug kann die technische Einordnung erheblich einschränken.

5. Projekt- und Änderungshistorie

Bei der Rekonstruktion eines Entwicklungsverlaufs können technische Änderungen und ihre zeitliche Reihenfolge von Bedeutung sein.

Je nach Fragestellung können deshalb zusätzlich folgende Artefakte relevant sein:

• Commit-Historie,
• Pull- oder Merge-Requests,
• Issue- und Ticketsystem,
• Review-Kommentare,
• Release Notes,
• CI/CD-Protokolle,
• technische Besprechungs- und Entscheidungsprotokolle.

Diese Unterlagen können helfen, eine technische Änderung mit einem bestimmten Entwicklungsstand und einem dokumentierten Ereignis in Beziehung zu setzen.

6. System- und Betriebsumgebung

Das Verhalten einer Anwendung kann von ihrer Umgebung abhängen. Eine reproduzierbare Prüfung benötigt deshalb gegebenenfalls auch Angaben zur tatsächlichen Betriebs- oder Testumgebung.

• Betriebssystem und Laufzeitumgebung,
• Datenbank- und Middleware-Versionen,
• relevante Infrastrukturkomponenten,
• Container- oder Deployment-Konfiguration,
• Schnittstellen und angebundene Fremdsysteme,
• Datenbank- oder Schemazustand,
• Konfigurationsparameter, soweit sie das untersuchte Verhalten beeinflussen.

7. Dokumentation der Übergabe

Für die technische Nachvollziehbarkeit sollte dokumentiert werden, welche Dateien und Daten tatsächlich untersucht wurden. Bei digitalen Artefakten können Dateilisten, Zeitpunkte und kryptografische Hashwerte eingesetzt werden, um den übernommenen Datenstand eindeutig zu dokumentieren.

Dadurch wird später nachvollziehbar, ob sich die untersuchte Datei oder der untersuchte Datenbestand von einer anderen Fassung unterscheidet.

Welche Unterlagen reichen für eine erste Prüfung?

Für eine erste fachliche Einschätzung muss nicht zwingend bereits der vollständige Projektbestand übermittelt werden. Ein sinnvolles Startpaket kann beispielsweise enthalten:

• konkrete technische Fragestellung,
• kurze Projekt- und Systembeschreibung,
• relevante Anforderungsunterlagen,
• Beschreibung des beanstandeten technischen Problems,
• Angabe des betroffenen Software- oder Release-Stands,
• Übersicht der vorhandenen Quellcode-, Ticket-, Test- und Protokolldaten.

Auf dieser Grundlage lässt sich regelmäßig zunächst bestimmen, welche weiteren technischen Unterlagen für eine belastbare Untersuchung erforderlich wären.

Was bedeutet eine unvollständige Unterlagenlage?

Fehlende Unterlagen führen nicht automatisch dazu, dass keine technische Aussage möglich ist. Sie können aber die Reichweite der Aussage begrenzen.

Fehlt beispielsweise der ursprünglich ausgelieferte Softwarestand, kann eine spätere Codefassung nicht ohne Weiteres als identischer Untersuchungsgegenstand behandelt werden. Fehlen reproduzierbare Fehlerdaten, kann gegebenenfalls nur die vorhandene Dokumentationslage, nicht aber das behauptete Laufzeitverhalten geprüft werden.

Solche Einschränkungen gehören ausdrücklich in die Dokumentation der Untersuchung.

Befund, Interpretation und rechtliche Würdigung

Ein technischer Befund könnte beispielsweise lauten, dass eine bestimmte Funktion in einem untersuchten Commit nicht vorhanden ist oder dass ein dokumentierter Test unter festgelegten Bedingungen fehlschlägt.

Die fachliche Interpretation kann anschließend einordnen, welche technische Bedeutung dieser Befund für die konkrete Untersuchungsfrage besitzt.

Weiterführend: Quellen und Methodik des Wissensbereichs .

Software- oder Quellcode-Gutachten

Wenn ein konkreter Softwarestand, Quellcode, Anforderungen oder technische Abweichungen untersucht werden sollen, kann zunächst die vorhandene Unterlagenlage fachlich eingeordnet werden.

Software-Gutachten ansehen