softXplain

Ansprechpartner:

• Prof. Kurt Schneider
• Hannah Deters

Softwaresysteme werden zur heutigen Zeit zunehmend komplexer und gleichzeitig sind wir in immer mehr Bereichen auf diese Systeme angewiesen. Es wird daher zunehmend schwieriger, diese Systeme zu verstehen, aber zeitgleich auch immer wichtiger. Da bei der Nutzung von Softwaresystemen in der Regel keine Ansprechperson für Fragen und Probleme zur Verfügung steht, müssen die Softwaresysteme in der Lage sein, mögliche Fragen selbst zu beantworten. Diese Fähigkeit, als Softwaresystem das eigene Verhalten zu erklären, wird Erklärbarkeit (engl: Explainability) genannt. Es handelt sich hierbei wie bei Benutzbarkeit, Sicherheit oder Wartbarkeit um eine nicht-funktionale Anforderung, dessen genaue Bedeutung und Grad ihrer Umsetzung in einem Softwareprojekt spezifiziert werden müssen. Werden diese Eigenschaften gut umgesetzt, kann die Verwirrung bei der Benutzung verringert und letztlich die Akzeptanz für das System gesteigert werden.

Da sich verschiedene Qualitätseigenschaften widersprechen können, ist es wichtig zu ermitteln, welche Anforderungen hinsichtlich Erklärbarkeit erreicht werden sollen. Dabei steht im Fokus, welche Funktionen nützlich sind, was realistisch umsetzbar ist und wie zwischen konkurrierenden Qualitätsanforderungen abgewogen wird. Um dies zu ermöglichen, sollen folgende Schlüsselfragen geklärt werden:

• Wie kann die Software erfahren, welches Verhalten von ihr erwartet wird?
• Wie lässt sich erkennen, ob Menschen Erklärungen benötigen?
• Was ist die richtige Form und der geeignete Zeitpunkt für solche Erklärungen?

Unterstützend sollen Demonstratoren entwickelt werden, welche unter anderem empirische Untersuchungen ermöglichen.

In diesem Projekt geht es nicht darum, Black Boxen wie neuronale Netze erklärbar zu machen. Deshalb fokussiert dieses Projekt nicht auf Bereiche wie Künstliche Intelligenz bzw. Maschinelles Lernen. Vielmehr sollen generell komplizierte, selbst-erklärende Softwaresysteme untersucht werden und dabei offengelegt werden, wann Erklärungen in welchem Maße benötigt werden.

Eine mögliche Ursache für Verwirrung stellt eine Abweichung zwischen dem mentalen Modell der Nutzenden und dem tatsächlichen Verhalten des Systems dar. Dabei versteht man unter dem mentalen Modell die Vorstellung, welche die Nutzenden vom System aufgebaut haben. Abhängig davon treffen die Nutzenden Vorhersagen zu dem Systemverhalten und passen ihre eigenen Aktionen daran an. Wenn nun die Vorhersage des Nutzenden nicht mit dem tatsächlichen Verhalten übereinstimmt, entsteht Verwirrung. Dieser Verwirrung kann mithilfe von Erklärungen entgegengewirkt werden. Dafür können explizite mentale Modelle erstellt werden, die die Abweichung des erwarteten Verhaltens von dem tatsächlichen Verhalten vorhersagen. Die untenstehende Abbildung zeigt diesen Prozess. Wenn eine Abweichung besteht, werden Erklärungen geliefert und so der Verwirrung vorgebeugt.

• Deters, H., Droste, J., & Schneider, K. (2023, June). A means to what end? evaluating the explainability of software systems using goal-oriented heuristics. In Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering (pp. 329-338). https://doi.org/10.1145/3593434.3593444
• Droste, J., Deters, H., Obaidi, M., & Schneider, K. (2024). Explanations in Everyday Software Systems: Towards a Taxonomy for Explainability Needs. arXiv preprint arXiv:2404.16644. https://doi.org/10.48550/arXiv.2404.16644
• Deters, H., Droste, J., Obaidi, M., & Schneider, K. (2024, March). How Explainable Is Your System? Towards a Quality Model for Explainability. In International Working Conference on Requirements Engineering: Foundation for Software Quality (pp. 3-19). https://doi.org/10.1007/978-3-031-57327-9_1
• Droste, J., Fuchs, R., Deters, H., Klünder, J., Schneider, K. (2024). Explainability Requirements for Time Series Forecasts: A Study in the Energy Domain.
• Chazette, L., & Schneider, K. (2020). Explainability as a non-functional requirement: challenges and recommendations. Requirements Engineering, 25(4), 493-514. https://doi.org/10.1007/s00766-020-00333-1