Gutachten & Methodik
Technische Feststellungen werden erst dann bewertbar, wenn transparent ist, woran sie gemessen werden. Ein Referenzmaßstab kann aus dokumentierten Anforderungen, anerkannten technischen Spezifikationen, Normen, Herstellerangaben, reproduzierbaren Vergleichszuständen oder fachlich begründeten Kriterien bestehen. Entscheidend ist, dass Herkunft, Geltung und Operationalisierung des Maßstabs vor der Schlussfolgerung nachvollziehbar sind.
Kurzantwort
Ein belastbarer Referenzmaßstab wird nicht nachträglich passend zum Befund ausgewählt. Zuerst wird bestimmt, welche technische Eigenschaft beurteilt werden soll, welcher Maßstab dafür einschlägig ist und wie dessen Kriterien beobachtbar oder messbar gemacht werden. Abweichung, Unsicherheit und Reichweite der Bewertung werden anschließend getrennt dokumentiert.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Referenzmaßstab von der Untersuchungsfrage her bestimmen
Ein Referenzmaßstab ist kein dekorativer Quellenhinweis, sondern die fachliche Bezugsgröße der Bewertung. Soll beispielsweise die Wartbarkeit einer Software, die Vollständigkeit einer Anforderung oder die Robustheit einer Schnittstelle beurteilt werden, muss zunächst geklärt werden, welche technische Eigenschaft tatsächlich Gegenstand der Frage ist. Erst danach lässt sich entscheiden, ob projektspezifische Anforderungen, ein veröffentlichter Standard oder eine fachlich begründete Vergleichsbasis trägt.
Projektinterne Dokumente können für einen konkreten Soll-Zustand maßgeblicher sein als ein allgemeiner Qualitätsstandard. Umgekehrt kann ein allgemeiner Standard hilfreich sein, wenn er Begriffe, Qualitätsmerkmale oder Prüfkonzepte strukturiert. Beides darf nicht vermischt werden: Ein Qualitätsmodell definiert nicht automatisch die vertraglich geschuldete Eigenschaft eines konkreten Systems.
2. Geltungsbereich, Version und Hierarchie der Quellen dokumentieren
Normen, Spezifikationen und technische Richtlinien besitzen Fassungen, Anwendungsbereiche und teilweise ausdrücklich informative oder normative Bestandteile. Für ein Gutachten wird deshalb dokumentiert, welche Ausgabe oder Fassung verwendet wird, für welchen Teil des Untersuchungsgegenstands sie herangezogen wird und ob sie unmittelbar oder nur orientierend dient.
Bei mehreren denkbaren Maßstäben ist eine Priorisierung erforderlich. Eine projektspezifische Akzeptanzbedingung, eine Hersteller-Schnittstellenspezifikation und ein generisches Qualitätsmodell können unterschiedliche Ebenen betreffen. Der Bericht sollte sichtbar machen, welche Quelle welche Frage beantwortet und wo kein eindeutiger Vorrang fachlich begründet werden kann.
3. Abstrakte Qualitätsbegriffe operationalisieren
Begriffe wie zuverlässig, wartbar, sicher, performant oder benutzbar sind ohne Operationalisierung nicht unmittelbar prüfbar. Aus ihnen werden daher konkrete Beobachtungen oder Messgrößen abgeleitet. Das können Fehlerraten, Antwortzeiten, Testabdeckungen, Wiederherstellungszeiten, nachvollziehbare Architekturmerkmale oder reproduzierbare Nutzeraufgaben sein.
Die Operationalisierung enthält auch die Messbedingungen. Ein Grenzwert ohne Lastprofil, Hardwarekonfiguration oder Messfenster kann wenig aussagekräftig sein. Ebenso ist ein Codequalitätsindikator ohne Bezug auf Sprache, Projektart und verwendetes Analysewerkzeug nur eingeschränkt interpretierbar.
4. Toleranzen, Unsicherheit und Gegenprüfung einbeziehen
Nicht jede technische Bewertung ist binär. Messungen besitzen Streuung, Werkzeuge können unterschiedliche Ergebnisse liefern und Anforderungen können Spielräume enthalten. Deshalb werden Toleranzen oder Unsicherheitsbereiche soweit sinnvoll vor der endgültigen Bewertung festgelegt und nicht erst nach Sichtung des Ergebnisses angepasst.
Eine Gegenprüfung fragt, ob ein anderes plausibles Kriterium zu einer abweichenden Einordnung führen würde. Werden etwa Performanceprobleme nur unter einer untypischen Testlast sichtbar, muss geprüft werden, ob diese Last vom maßgeblichen Einsatzszenario getragen wird. So wird verhindert, dass ein einzelner Messwert über seinen Kontext hinaus verallgemeinert wird.
5. Befund, Interpretation und Bewertung getrennt halten
Der Befund beschreibt zunächst, was beobachtet oder gemessen wurde. Die Interpretation ordnet ein, welche technische Ursache oder Bedeutung daraus plausibel folgt. Die Bewertung stellt anschließend den Bezug zum gewählten Maßstab her. Diese Trennung ist besonders wichtig, wenn derselbe Befund unter verschiedenen Kriterien unterschiedlich eingeordnet werden könnte.
Im Bericht sollte daher nicht nur stehen, dass ein System „nicht normgerecht“ oder „mangelhaft“ sei. Besser ist die konkrete Kette: untersuchter Zustand, gemessener Wert oder beobachtetes Merkmal, einschlägiges Kriterium, festgestellte Abweichung und Reichweite der technischen Schlussfolgerung.
6. Revisionsanlass bei verändertem Maßstab dokumentieren
Ändert sich die maßgebliche Anforderung, erscheint eine neue Spezifikationsfassung oder wird ein anderer Systemstand Gegenstand der Untersuchung, kann sich auch der Referenzmaßstab ändern. Das ist ein methodischer Revisionsanlass. Frühere Ergebnisse werden dann nicht stillschweigend auf den neuen Kontext übertragen.
Eine nachvollziehbare Revision dokumentiert, welche Kriterien unverändert bleiben, welche ersetzt wurden und welche bereits erhobenen Befunde neu eingeordnet werden müssen. So bleibt erkennbar, ob sich das technische System, der Maßstab oder beides verändert hat.
Besonders bei heterogenen Anforderungen sollte außerdem festgehalten werden, ob ein Kriterium Mindestanforderung, Zielwert oder bloßer Vergleichswert ist. Diese Rollen haben unterschiedliche Aussagekraft. Ein Zielwert kann als Optimierungsrichtung dienen, ohne dass jede Unterschreitung bereits eine technische Nichterfüllung bedeutet. Umgekehrt kann eine explizite Mindestschwelle eine klare Prüfkante bilden, sofern Messverfahren und Randbedingungen eindeutig festgelegt sind.
Bei toolgestützten Metriken gehört die Werkzeugkonfiguration selbst zum Referenzmaßstab. Unterschiedliche Regelsets, Schwellwerte oder Parser können zu abweichenden Ergebnissen führen. Deshalb werden Toolversion, Konfiguration und relevante Ausschlüsse dokumentiert, wenn sie die Bewertung materially beeinflussen.
Ist eine Norm automatisch der maßgebliche Soll-Zustand?
Nein. Eine Norm kann einen anerkannten technischen Referenzrahmen liefern, ist aber nicht allein deshalb der projektspezifische Soll-Zustand.
Für die konkrete Untersuchung muss begründet werden, warum eine Norm, Spezifikation oder Anforderung auf den untersuchten Sachverhalt anwendbar ist.
Bei rechtlich streitiger Verbindlichkeit bleibt die rechtliche Einordnung außerhalb der technischen Schlussfolgerung.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Ist die zu bewertende technische Eigenschaft eindeutig beschrieben?
- Ist die Quelle des Referenzmaßstabs mit Fassung oder Versionsbezug dokumentiert?
- Ist begründet, warum der Maßstab auf den konkreten Untersuchungsgegenstand anwendbar ist?
- Sind abstrakte Kriterien in beobachtbare oder messbare Merkmale übersetzt?
- Sind Messbedingungen, Toleranzen und Unsicherheiten dokumentiert?
- Wurde geprüft, ob ein plausibler Alternativmaßstab die Einordnung wesentlich ändern würde?
- Bleiben technische Bewertung und rechtliche Verbindlichkeit sprachlich getrennt?
Konstruiertes Beispiel
Für eine Webanwendung wird eine maximale Antwortzeit behauptet. Die Untersuchung stellt zunächst fest, ob diese Grenze aus einer projektspezifischen Anforderung, einer Betriebsvereinbarung oder lediglich aus einer allgemeinen Erwartung stammt. Erst danach werden Lastprofil, Messpunkt und Toleranz bestimmt und der gemessene Systemstand gegen diesen Maßstab geprüft.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Internationaler Standard ISO/IEC 25010:2023 stellt ein Produktqualitätsmodell für ICT- und Softwareprodukte bereit. Quelle öffnen.
- Internationaler Standard ISO/IEC/IEEE 29148:2018 beschreibt Prozesse und Informationsinhalte des Requirements Engineering. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Technische Fragestellung und Prüfauftrag abgrenzen
- Befund, Interpretation und Bewertung trennen
- 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.
- Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Daten zu Lösungen in Data Science mit Python – Vom Problem zur verantwortbaren Lösung
- Eigenes Fachbuch Von Modellen zu Entscheidungen in Machine Learning mit Python – Vom Modell zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Code zu Lösungen im Software Engineering mit Java – Vom Problem zur verantwortbaren Lösung
Technische Untersuchung zum Themenbereich Gutachten & Methodik
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Analyse & Bewertung