IT-Projekte & technische Due Diligence
In IT-Projekten entsteht der maßgebliche Soll-Zustand selten aus einem einzigen Dokument. Anforderungen verändern sich, werden präzisiert, in Tickets verteilt und durch Tests oder Abnahmeprotokolle konkretisiert. Eine technische Rekonstruktion muss diese Entwicklung zeitlich und versionsbezogen ordnen.
Kurzantwort
Der Soll-Ist-Abgleich beginnt mit der Frage, welche konkrete Anforderung für welchen Projektstand technisch maßgeblich dokumentiert war. Anschließend werden Umsetzung, Testnachweise und Abnahmeinformationen demselben Stand zugeordnet. Widersprüchliche oder nachträglich geänderte Anforderungen werden als eigene Befunde dokumentiert.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Soll-Zustand aus mehreren Quellen rekonstruieren
Lasten- und Pflichtenhefte, User Stories, Tickets, Spezifikationen, Akzeptanzkriterien und Änderungsprotokolle können gleichzeitig existieren. Sie müssen zeitlich und inhaltlich zueinander in Beziehung gesetzt werden.
Eine spätere Dokumentfassung darf nicht stillschweigend auf einen früheren Entwicklungsstand zurückprojiziert werden. Deshalb werden Versionsstände und Änderungszeitpunkte der Anforderungen soweit möglich dokumentiert.
Technisch relevant ist außerdem, ob eine Anforderung hinreichend konkret war, um sie reproduzierbar zu testen. Unbestimmte Qualitätsbegriffe benötigen gegebenenfalls operationalisierte Kriterien.
2. Ist-Zustand eindeutig bestimmen
Dem Soll wird ein konkreter Implementierungsstand gegenübergestellt. Repository-Revision, Build, Deployment, Konfiguration und Datenstand sollten zusammenpassen. Andernfalls besteht das Risiko, Anforderungen und Implementierung unterschiedlicher Zeitpunkte zu vergleichen.
Bei mehreren Umgebungen wird geklärt, ob Test-, Staging- und Produktivstand technisch identisch oder unterschiedlich waren. Ein bestandener Test in einer Umgebung belegt nicht automatisch das Verhalten einer anderen.
Auch fehlgeschlagene oder nicht ausgeführte Tests sind Teil der Projektlage, dürfen aber nicht mit einem technisch nachgewiesenen Mangel gleichgesetzt werden.
3. Tests und Abnahmeunterlagen einordnen
Testfälle dokumentieren, welche Eigenschaften unter welchen Bedingungen geprüft wurden. Ihre Aussagekraft hängt von Testdaten, Umgebung, Version und erwarteten Ergebnissen ab.
Abnahmeprotokolle oder Freigabevermerke können wichtige Kontextquellen sein. Technisch ist zu prüfen, auf welchen Stand sie sich beziehen und welche Prüfschritte tatsächlich dokumentiert sind. Eine formale Freigabe ersetzt keine technische Untersuchung eines später behaupteten Sachverhalts.
Umgekehrt belegt ein heute reproduzierbarer Fehler nicht automatisch, dass derselbe Fehler zum früheren Abnahmezeitpunkt bereits in derselben Form vorhanden war.
4. Abweichungen klassifizieren
Ein Soll-Ist-Abgleich kann verschiedene Befundarten ergeben: Anforderung erfüllt, reproduzierbar nicht erfüllt, nicht prüfbar, widersprüchlich dokumentiert oder nur unter abweichenden Bedingungen beobachtet.
Diese Kategorien helfen, technische Feststellungen von Projektkommunikation und rechtlicher Bewertung zu trennen. Besonders „nicht prüfbar“ ist kein Synonym für „nicht erfüllt“.
Bei funktionalen und nichtfunktionalen Anforderungen können unterschiedliche Messmethoden erforderlich sein. Performance, Sicherheit oder Usability benötigen andere Evidenz als ein deterministischer Funktionscheck.
5. Projektverlauf und Revisionsanlässe
Ändern sich Anforderungen, kann ein früherer Befund für einen späteren Stand unzutreffend sein. Deshalb werden Change Requests, Ticketänderungen und Freigaben in die zeitliche Rekonstruktion einbezogen.
Ein belastbarer Bericht macht sichtbar, welche Anforderungsversion, welcher Implementierungsstand und welcher Test miteinander verglichen wurden. Nur dann ist der Soll-Ist-Befund für Dritte nachvollziehbar.
Die technische Rekonstruktion beantwortet nicht automatisch, welche Partei eine Änderung schuldete oder ob eine Abnahme rechtlich wirksam war.
6. Traceability-Matrix zwischen Anforderung, Umsetzung und Nachweis
Eine Traceability-Matrix kann je Anforderung die maßgebliche Fassung, zugehörige Tickets, Implementierungsartefakte, Testfälle, Testergebnisse und gegebenenfalls Abnahmevermerke zusammenführen. Sie ersetzt keine fachliche Bewertung, macht aber sichtbar, an welcher Stelle eine Kette vollständig oder unterbrochen ist.
Dabei ist zwischen Existenz und Aussagekraft eines Nachweises zu unterscheiden. Ein bestandener Testfall belegt nur das getestete Verhalten unter den dokumentierten Bedingungen. Ein Abnahmeprotokoll kann organisatorisch relevant sein, beweist aber nicht automatisch, dass jede technische Eigenschaft geprüft wurde.
Besonders kritisch sind Anforderungen, die nachträglich präzisiert oder ersetzt wurden. Ohne Zeitbezug kann eine spätere Fassung fälschlich als Sollmaßstab für einen früheren Build verwendet werden. Deshalb gehört die zeitliche Gültigkeit jeder Baseline in die technische Rekonstruktion.
Bei der Bewertung des Soll-Zustands sollten außerdem Priorität, Akzeptanzkriterien und Abhängigkeiten der Anforderung berücksichtigt werden. Ein Feature kann technisch implementiert sein und dennoch eine definierte Randbedingung, Performance-Grenze oder Schnittstellenanforderung verfehlen. Umgekehrt kann ein beobachtetes Verhalten zulässig sein, wenn die maßgebliche Anforderungsfassung mehrere Varianten erlaubt. Deshalb wird nicht nur auf Schlagwörter oder Ticketstatus geprüft, sondern auf den konkreten Inhalt der gültigen Anforderung und die dazugehörigen Nachweise.
Was bedeutet „abgenommen“ aus technischer Sicht?
Technisch kann untersucht werden, welcher Build oder Release Gegenstand einer dokumentierten Abnahmehandlung war, welche Tests durchgeführt wurden und welche bekannten Abweichungen festgehalten waren.
Der Begriff „Abnahme“ besitzt jedoch eine rechtliche Bedeutung, die über die technische Dokumentation hinausgeht. Die technische Begutachtung sollte deshalb Befund und Rechtsfolge trennen.
Fehlt eine eindeutige Zuordnung zwischen Abnahmeunterlage und Build, ist genau diese Zuordnungslücke auszuweisen.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Ist die maßgebliche Anforderungsfassung mit Datum oder Versionsbezug bestimmt?
- Sind Änderungen und ersetzte Anforderungen nachvollziehbar getrennt?
- Ist der tatsächlich geprüfte Build oder Release eindeutig identifiziert?
- Sind Testfälle mit den jeweiligen Anforderungen verknüpft?
- Wird zwischen bestandenem Test, dokumentierter Abnahmehandlung und technischer Vollständigkeit unterschieden?
- Sind offene oder nicht getestete Anforderungen sichtbar?
- Ist die rechtliche Bewertung der Abnahme klar von der technischen Rekonstruktion getrennt?
Konstruiertes Beispiel
Eine Funktion wird im ursprünglichen Pflichtenheft anders beschrieben als in einem späteren Ticket. Der produktive Build entspricht dem Ticket, aber nicht dem früheren Dokument. Der technische Befund besteht deshalb zunächst in der dokumentierten Anforderungsänderung und der Zuordnung zum Build; welche Fassung vertraglich maßgeblich war, ist getrennt zu beurteilen.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Technische Primärquelle Git-Revisionsmodell zur eindeutigen Zuordnung von Entwicklungsständen. Quelle öffnen.
- Spezifikation SLSA-Provenienz als Referenz für die Zuordnung von Build-Artefakten zu Eingaben. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- Technische Primärquelle Git-Dokumentation zu git-log für die nachvollziehbare Untersuchung von Commit-Historien und Änderungen. Quelle öffnen.
Weiterführende Beiträge
- IT-Projektverlauf rekonstruieren
- Softwaremängel im Soll-Ist-Vergleich
- Alle Beiträge in diesem Themenbereich
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.
Technische Untersuchung zum Themenbereich IT-Projekte & technische Due Diligence
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Projektgutachten