Typische Fehler in Softwaredokumentationen

Die häufigsten Fehler in Softwaredokumentationen

Diese Probleme treten in nahezu allen Entwicklungsmodellen auf – egal ob agil, hybrid oder klassisch.

1. Dokumentation beginnt zu spät

Ein häufiger Irrtum: „Wir schreiben die Dokumentation am Ende.“ Spätestens in IEC-62304-Projekten führt das zu massiven Lücken.

Folgen: fehlende Nachweise, keine Traceability, Zeitdruck, Auditabweichungen.

Lösung: Dokumentation als festen Bestandteil jedes Sprints/Meilensteins etablieren.

2. Keine durchgängige Traceability

Die IEC 62304 verlangt: Anforderungen → Design → Implementierung → Tests → Risiken müssen rückverfolgbar sein.

Typische Lücken:

• Anforderungen ohne Testnachweise
• Design ohne Bezug zu Risiken
• Tests ohne Bezug zu Anforderungen

Lösung: Traceability Matrix und klare Verlinkung in jedem Dokument. Siehe auch unsere Checkliste Softwaredokumentation.

3. Unvollständige oder fehlende Softwarearchitektur

Viele Teams dokumentieren nur den Code – nicht jedoch das System dahinter. Für Audits ist eine klare Architektur jedoch unverzichtbar.

Lösung: Architekturdiagramme, Modulübersichten, Schnittstellenbeschreibungen.

4. Inkonsistenzen zwischen Code, Anforderungen und Tests

Anforderungen beschreiben etwas anderes als das Design. Tests prüfen andere Dinge als die Anforderungen. Dokumentation stimmt nicht mit UI oder Risikoakte überein.

Lösung: regelmäßige Reviews zwischen Dev ↔ QA ↔ RA ↔ Redaktion.

5. Fehlende oder unklare Risikobewertung

Besonders Softwareteams unterschätzen die Anforderungen der ISO 14971 für Software.

• Gefährdungen werden nicht erkannt
• Risikokontrollen fehlen oder sind nicht dokumentiert
• Risiken sind nicht mit Tests verknüpft

Lösung: frühe Einbindung der Risikoakte und Integration mit Anforderungen & Tests.

6. Benutzer und Warnhinweise werden nicht berücksichtigt

Usability (IEC 62366-1) ist in der Software ebenso wichtig wie in IFUs. Häufig fehlen:

• kritische Benutzeraufgaben
• UI-Textkonzepte
• Warnhinweise in der Software

Lösung: Usability Engineering früh integrieren. Siehe: Usability-Doku für Software.

7. Änderungen sind nicht nachvollziehbar (Change Management)

Ohne Versionierung und Impact-Analyse erfüllen Softwareupdates nicht die MDR-Anforderungen.

• fehlende Release Notes
• keine Bewertung der Änderungen
• keine Dokumente zur Wartung

Lösung: integriertes Konfigurations- und Änderungsmanagement.

8. Externe Bibliotheken sind schlecht dokumentiert

In Audits wird zunehmend geprüft:

• Welche Libraries werden verwendet?
• Sind Updates sicher & dokumentiert?
• Gibt es Abhängigkeiten, die Risiken verursachen?

Lösung: vollständige Third-Party-Liste mit Versionen, Herkunft und Zweck.

9. Kein abgestimmter Schreibstil oder fehlende Terminologie

Unterschiedliche Teams schreiben unterschiedlich – besonders gefährlich bei sicherheitsrelevanten Inhalten.

Lösung: Terminologiemanagement mit Tools wie flashterm, Styleguides, Glossare.

10. Entwickler schreiben für Entwickler – nicht für Audits

Fachlich korrekt, aber für RA/QM oder Benannte Stellen unverständlich.

Lösung: Technische Redaktion als verbindende Instanz zwischen Dev, QA und Regulatory Affairs.