1. Introduction
Recent years have seen a growing interest within Requirements Engineering (RE) in software qualities that are more cross-cutting, orthogonal, or emergent in nature [3]. As their name suggests, these quality aspects can cut across several aspects of a system simultaneously, including other qualities. As a result, in RE they deserve special attention to ensure early detection of dependencies and conflicts and proper assessment of the impact of changes made to a specific quality aspect with regard to its cross-cutting counterpart. Despite potentially cutting across the more traditional software product qualities, among other things, domain standards such as ISO 25010 do not address them sufficiently, if at all [3]. In turn, this also means the understanding of this perspective on digital systems is limited, which calls for more explicit conceptual guidance beyond regular requirements types in RE. Examples of cross-cutting qualities include well-being and health, sustainability, and accessibility.
We will zoom in on two cross-cutting qualities that have received significant attention in research and practice: explainability – helping stakeholders understand system aspects in a given context, and privacy – ensuring that personal data is properly handled and secured. These quality aspects have in common that they seem to be more independent of a single software product, but instead, they describe more general and consistent needs [4], which we refer to as stakeholder needs. The requirements pertaining to these aspects are therefore not only cross-cutting, but they also appear to be cross-system. This makes the interplay between them particularly interesting.
In this article, we elaborate on the interconnection between the quality aspects explainability and privacy by drawing on the experiences of two independent research groups. Research into explainability by the Software Engineering group at Leibniz University Hannover has resulted, among other things, in a taxonomy of explainability needs [2]. Simultaneously, a consortium of two projects on usable security and privacy (USP) proposed a taxonomy of privacy needs [1]. Because security relates to the protection of personal data, this work considers it part of the cross-cutting quality of privacy, while we retain the name USP needs for the taxonomy. The two independently created taxonomies show clear overlaps: while a category of explainability needs relates to security and privacy, the privacy needs categorized as transparency needs are typically satisfied through explainability concepts.
Given the interfaces between these taxonomies, we investigated the interplay between explainability and privacy. To this end, we link the two taxonomies and derive practical implications. By combining the two taxonomies on stakeholder needs, we have laid the foundation for future work concerning other cross-cutting qualities.
This article is structured as follows: We first introduce the terms explainability and USP/privacy in Sections 2 and 3. We address the special nature of cross-cutting quality aspects in Section 4, where we explain more precisely the common ground as system-independent stakeholder needs. We then identify the overlaps between the two aspects in Section 5 and we present our combined taxonomy of stakeholder needs in Section 6. Finally, we discuss the implications for research and practice in Section 7.
2. What is explainability?
When software is complex, not everything can be understood at first glance. For example, an interaction might not be self-explanatory, or internal processes need elaboration. For such purposes, explanations can be a viable means of enhancing transparency and understandability. As such, explainability has become an important quality aspect of modern software systems. Recent research into software explanations has emphasized the interpretability of artificial intelligence (AI), thereby defining the research field of explainable AI (XAI). By ensuring that its decision making and outputs are transparent and understandable, these explanations help foster trust among stakeholders in the system [5].
However, software explanations have a rich history outside of XAI, especially in human–computer interaction, where explanations usually address aspects that are not externally visible. In particular, the user’s mental models play an important role in their relationship to a system’s explainability. Prior research has shown that users with more accurate mental models can use systems more quickly and proficiently, and more easily infer system-internal processes. Conversely, users with flawed mental models are more often hindered in achieving their goals, as their expectations conflict with the system’s behavior they observe [6]. Whenever these conflicts occur, providing the user with suitable explanations might help them form more accurate mental models, which enhances learnability and user experience [6][7].
Recent research into RE for explainable systems has proposed a taxonomy for explainability needs, which was validated in several follow-up publications [2]. The underlying data indicates that end-users’ explanation needs extend far beyond justifying system behavior, addressing a variety of system aspects. The taxonomy distinguishes between five main categories of explainability needs: interaction, system behavior, domain knowledge, privacy & security, and user interface. The prioritization of these categories of needs depends on many factors, such as the context of use and the individual use preferences [4].
The need for explanations is largely subjective and consists of a unique combination of user-specific factors, such as the context of use, previous experiences, and personal preferences, which may in turn be influenced by demographics and culture [8]. To address these diverse stakeholder needs, RE offers a variety of methods and frameworks. These include explainability personas, which can help assess general explanation needs within a user base during early development stages, and explanation taxonomies, which facilitate requirements elicitation and user feedback analysis [9].
3. What is usable security and privacy (USP)?
USP combines usable security with usable privacy. Usable security is the inter- and transdisciplinary approach to designing security measures for digital products and services so that users are effectively supported in achieving security-related goals. Usable privacy shares similar goals and considers technologies that promote privacy in digital systems and platforms [10]. Our focus in this article is on the protection of personal data and the privacy of end users.
The legal framework for this is provided by data protection law, for example, the General Data Protection Regulation (GDPR) of the EU. To transform abstract legal requirements into appropriate measures and to evaluate their usability, various models and methods have been developed. However, many well-known notations such as soft goal models do not differentiate between data protection and privacy aspects.
The Standard Data Protection Model (SDM) [11] translates the abstract legal requirements of the GDPR into concrete technical and organizational measures, e.g., “Restriction of write and modification permissions” or “Erasure or rectification of incorrect data”. Thus, it provides a means of translation between law and technology, but it does not specify any requirements that go beyond data protection law.
A complementary approach to defining privacy requirements is to consider privacy as a quality characteristic of a software product, similar to security, and to take the seven protection goals from the SDM – data minimization, availability, integrity, confidentiality, unlinkability, transparency, and intervenability – as subcharacteristics. This helps define and organize privacy requirements concerning the quality of personal data, processing procedures, and infrastructure, e.g., “Accuracy of data”, “Efficiency of processes”, or “Documentation of proof of compliance” [12].
In the field of USP, studies have also examined users’ mental models to explore their perceptions of data protection and its impact on their privacy, for example, in relation to informational self-determination in the workplace [13]. The Usable Privacy Cube [14] was developed to support usability evaluations of privacy. This model enables measurement of effectiveness, efficiency, and satisfaction based on modular criteria, considering both objective usability, e.g., “How much time do the data subjects need to invest in order to have control over the processed data?” and perceived usability, e.g., “To what degree do the data subjects perceive the choice of consenting as free and genuine?”
While existing approaches measure a system’s performance or stakeholders’ perceptions of privacy, they do not address the underlying drivers of stakeholder motivation, which represent more fundamental needs. In this context, it is paramount to distinguish between two main user group profiles [15] regarding data privacy – data subjects and data processors – because they have divergent needs, which might be conflicting. For example, employers, police, or tax advisors may be entitled or even legally required to access personal data that some data subjects would rather not disclose.
This led us to propose a set of five privacy needs organized into two logical groups: privacy needs of data subjects and data usage needs of data processors [16]. Each of these needs represents a desire expressed by a stakeholder concerning how personal data is handled, which we elicited through interviews, and documented using the user story template. For example, “As a data subject, I would like there to be a feedback channel for inquiries, so that I can quickly clarify things that are unclear to me” or “As a data processor, I would like to know, which deletion periods I must adhere to for emails.”
We have developed a practice-driven approach for embedding stakeholder needs into the established RE activities, which provides guidance for eliciting stakeholder needs through workshops and semi-structured interviews both with data subjects and data processors [1][17][18]. The needs analysis is performed in various stages – open needs analysis, scenario-based needs analysis, and detailed needs analysis – depending on the status of other requirements artifacts. We suggest holding at least two different workshops: one with stakeholders who are primarily data subjects to elicit their privacy needs, and one with stakeholders who are predominantly data processors to elicit their data usage needs. During the negotiation and validation of the user requirements and stakeholder needs in our specification, a legal expert was a permanent member of the RE team. This expert also helped with clarifying compliance constraints, providing explanations of GDPR terminology (e.g., processing operations), and creating a project glossary.
Despite the involvement of a legal expert, USP needs should not be considered synonymous with legal or privacy requirements. Legal requirements consider only what is required by law, and privacy requirements pertain to particular privacy-preserving functions, whereas USP needs relate more strongly to the way that legal aspects of personal data impact data subjects and data processors. In this way, when the needs of both user groups are optimally fulfilled, a system can be better attuned to the user experience while ensuring legal compliance, and it can also help explain to the stakeholders why certain needs cannot be met, since data protection law does not permit them.
4. Why are the “requirements” for these cross-cutting themes different?
While privacy requirements focus on the system and are often constraints – i.e., “must-requirements” [19] grounded in regulatory compliance – the end users’ concern is not primarily with a system’s compliance, but with what is (potentially) being done with personal data – i.e., what a data subject or data processor expresses regarding its processing. These needs are therefore often more abstract than functional or quality requirements and cannot be translated directly into organizational measures or software properties [1].
The need for explanations depends heavily on the user and the objective the explanation is intended to achieve. This means that, depending on their prior knowledge and personality, users have different expectations for system explanations. Speaking in clichés: a tech-savvy person might simply need explanations that show them shortcuts in the system, while a technologically inexperienced person will instead need basic and simple explanations of how to use the system effectively. Similarly, a very skeptical user needs very detailed explanations of how a system has arrived at a given response in order to trust the system, while a carefree person needs explanations that reveal the system's limitations to avoid blindly trusting its responses [20][21]. This shows that aspects such as a stakeholder’s personality and background knowledge influence expectations, which are independent of any specific system.
The quality aspects of explainability and privacy therefore share a characteristic that is cross-system by nature, depending more on the stakeholders than on the system under consideration.
5. Why is there an overlap between these qualities?
At face value, the cross-cutting qualities of explainability and privacy might seem to be two entirely separate constructs. The former is concerned with what a system conveys to the user, while the latter relates to protecting the user’s privacy. But as we learn more about the underlying needs of users and look more closely at what these qualities consist of, it is actually quite logical that users would also want to know what the system is doing with regard to their personal data – i.e., an explainability perspective on privacy – and conversely, how their personal data is being used by the system – i.e., a privacy perspective on explainability.
Where explainability emphasizes the system perspective and helps improve the user’s understanding (e.g., a domain knowledge need), privacy adopts a protection perspective and helps raise the user’s assurance (e.g., a transparency need). In both cases, this transparency and openness will help boost end-user acceptance and trust, as their concerns are duly addressed. This does mean that the boundary can be wafer-thin. Let’s say that a development team would like to assure end users that their (personal) data is properly secured and used responsibly. If the team decides to inform users of their own volition and this information goes beyond what regulations on privacy, AI, or other aspects demand and can be part of a broader spectrum of information, it could be considered more of a fulfillment of explainability needs. However, if the team is conscious of personal data being processed, provides information as part of their duty to inform, or has identified a need to clarify for data subjects how their data is processed, this would instead relate to privacy needs.
This perfectly illustrates what defines cross-cutting qualities: that characteristic of cutting across various aspects, which can also mean that they can cut into each other. In RE, this is still a relatively novel way of thinking, because requirements engineers often try to separate one quality from another, whereas in this case we distinguish between subtle shades of gray.
6. A combined taxonomy of explainability and USP needs
In Sections 2 and 3, we introduced our previous work, in which taxonomies for explainability needs and USP needs were developed separately from one another. For more details on how these taxonomies were constructed and for definitions of the needs, we refer the reader to the original publications [1][2]. Having established that explainability and privacy are related, we investigated how these two taxonomies could be integrated. At first glance, the relationship between the two cross-cutting qualities seems simple. Since explainability relates to privacy with respect to the algorithm, data privacy, and usage [22], it could essentially be covered entirely by transparency needs. However, after iterative discussions and careful analysis of the definitions of each need, we identified nine relationships, summarized in Figure 1. Below, we discuss these relationships in more detail.
We found that the needs on privacy in the explainability needs taxonomy relate to all five USP needs, but that each of these relationships is a unique perspective on how explanations inform and assure stakeholders with respect to privacy. These relationships are shown in Figure 1 with a lime color. From the viewpoint of data subjects, the transparency needs aim to help them understand or be informed about the processing of their data. The self-determination needs describe the extent to which they have control over the processing of their data. The security needs are aimed at informing them about the organizational measures that are being taken to make sure that their data is well protected during storage and processing. Explainability is also related to helping stakeholders in the role of data processors understand their rights and limitations. The processing information needs aim to help them understand or be informed about regulations regarding the processing of personal data. The data processing needs provide explanations of whether they are authorized or able to process personal data for their intended purposes.
The privacy & security category in the explainability needs taxonomy also includes needs on security. This type is associated with one of the USP needs, namely security needs, and the relationship focuses on informing data subjects about the technical measures taken to ensure that their data is protected, particularly against privacy violations. It should be noted that while the security needs from the privacy perspective focus on (explanations about) the technical measures related to personal data only, the security needs in the explainability taxonomy can concern any data protected by IT security measures.
As privacy is a specific domain with a unique, legislation-driven domain language, we also identified relationships between USP needs and the terminology needs type belonging to the explainability needs category of domain knowledge. Here, terminology concerns explainability needs regarding technical, non-intuitive or otherwise unfamiliar terms, including descriptions of workflows. We found that it has three relationships to USP needs. For transparency needs, this concerns providing understandable information about privacy aspects relevant to the system. If the software provider acts as a data processor, this also includes providing information to fulfill their duty to inform data subjects, which in this case consists of generic, non-personalized descriptions. Beyond simply understanding privacy, data subjects also need to be able to exercise control [23], and the relationship between terminology and self-determination needs specifically addresses what privacy-related rights they have and how they can exercise them, thereby facilitating self-determination. It should be noted that this is different from the aforementioned relationship with the privacy type of explainability need, which informs data subjects about the extent to which they have control. Finally, the link between terminology and processing information needs aims to help data processors navigate the complex landscape of privacy regulations.
Based on the relationships between the cross-cutting qualities we identified, we found clear overlaps between the lowest nodes of the two taxonomies for all five privacy needs and three explainability needs. However, the perspective depends on where the emphasis lies: on an explainability need that takes privacy into account, or on a USP need that makes use of explainability.
7. Implications and outlook
In this article, we have demonstrated a successful integration of research on stakeholder needs, which had previously been conducted separately by two research groups. This shows that these views on stakeholder needs are not only compatible, but also that considering them in combination is both sensible and fruitful.
As implications for both research and practice, considering stakeholder needs on cross-cutting qualities in RE enriches the understanding of the impact of the designed digital solution, as several examples have shown. For the research community, our integration of both taxonomies validated their robustness in a new context, showing that the needs related to a different cross-cutting quality retain their value from the perspective of their own quality.
Practitioners may benefit from our insight that cross-cutting qualities have fluid boundaries and may therefore mutually influence one another. For example, when an end user is confronted with a USP-related question that causes uncertainty, this can be resolved through providing explanations. Due to their system-independent nature, taxonomies of needs for different qualities are highly reusable for the development of technical solutions. To this end, in RE, cross-cutting qualities can be effectively addressed through stakeholder needs, where the relationships between explainability and privacy needs can also be expressed as dependencies. This implies that if adaptations are made regarding one cross-cutting quality, it might be detrimental if the impact on the needs of the interacting quality is not considered through, for example, additional elicitation activities.
We recommend that the interaction between the two qualities be explored further in practice, as each quality extends into the domain of the other. For example, a development team working to improve a system’s explainability might encounter the limitation that they focus too narrowly on what users expect to be informed about, without considering regulatory requirements such as the GDPR’s duty to inform. On the other hand, teams aiming to fulfill privacy needs might focus only on meeting regulatory requirements and thereby fail to address other relevant stakeholder expectations. Moreover, the relationships we identified showed that the goal should not be limited to raising the stakeholders’ privacy-related knowledge, but also helping them make it actionable, such as by informing data subjects about how they can exercise self-determination. Thus, in both directions, this consideration helps ensure that explanations covering and extending beyond privacy-related aspects are provided, and that these remain appropriate from the stakeholders’ perspective.
We have explored the compatibility of the stakeholder needs identified for two cross-cutting qualities: explainability and privacy. We identified several relationships, including subtle ones that required more detailed alignment. We expect that stakeholder needs could also play an important role for other cross-cutting qualities, including possible overlaps between explainability and accessibility, or between privacy and well-being & health. We will also explore dependencies between cross-cutting qualities and existing qualities. Privacy relates, among other things, to the ISO 25010 software quality characteristic of security and potentially the ISO 25019 quality-in-use characteristic of freedom from risk, while explainability can be associated with the ISO 25010 software quality subcharacteristics of interaction capability – and inclusivity, user assistance, and self descriptiveness in particular – as well as the ISO 25019 quality-in-use characteristics of satisfaction and context coverage. Moreover, we have focused on the explainability of information systems, while there may also be other needs for XAI applications. In such settings, privacy concerns regarding automated decision making and profiling affect both the data subject and the data processor, both of whom will express needs for good explanations about what happens in the system.
References
- [1] Groen, E. C., Feth, D., Polst, S., Tolsdorf, J., Wiefling, S., Lo Iacono, L., & Schmitt, H. (2023). Achieving usable security and privacy through Human-Centered Design. In: N. Gerber, A. Stöver & K. Marky (Eds.), “Human factors in privacy research” (pp. 83–113). Springer Nature. doi.org/10.1007/978-3-031-28643-8_5
- [2] Droste, J., Deters, H., Obaidi. M., Klünder, J., & Schneider, K. (2025). Framing what can be explained: An operational taxonomy for explainability needs. In: Requirements Engineering, 1–23, doi.org/10.1007/s00766-025-00440-x
- [3] Glinz, M., Seyff, N., Bühne, S., Franch, X., & Lauenroth, K. (2023). Towards a modern quality framework. In: Proceedings of the IEEE 31st International Requirements Engineering Conference Workshops (REW), 357–361. doi.org/10.1109/REW57809.2023.00067
- [4] Chazette, L, Brunotte, W., & Speith, T. (2022). Explainable software systems: From requirements analysis to system evaluation, Requirements Engineering, 27, 457–487. doi.org/10.1007/s00766-022-00393-5
- [5] Adadi, A., & Berrada, M. (2018). Peeking inside the black-box: A survey on explainable artificial intelligence (XAI), IEEE Access, 6, 52138–52160. doi.org/10.1109/ACCESS.2018.2870052
- [6] Kieras, D., & Bovair, S. (1984). The role of a mental model in learning to operate a device, Cognitive Science, 8(3), 255–273. doi.org/10.1207/s15516709cog0803_3
- [7] Deters, H., Droste, J., Hess, A., Klös, V., Schneider, K., Speith, T., & Vogelsang, A. (2024). The X factor: On the relationship between user experience and explainability, In: Proceedings of the 13th Nordic Conference on Human-Computer Interaction (NordiCHI), Article 19. doi.org/10.1145/3679318.3685352
- [8] Chazette, L, Brunotte, W., & Speith, T. (2022). Explainable software systems: From requirements analysis to system evaluation, Requirements Engineering, 27, 457–487. doi.org/10.1007/s00766-022-00393-5
- [9] Obaidi, M., Deters, H., Droste, J., Herrmann, M., Schneider, K., Voß, N., & Fischbach, J. (2025). Automating explanation need management in app reviews: A case study from the navigation app industry. In: Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 653–663. doi.org/10.1109/ICSE-SEIP66354.2025.00063
- [10] Lo Iacono, L., Schmitt, H., Feth, D., & Heinemann, A. (2025). 11. Usable Security und Privacy Workshop. In: Mensch und Computer 2025 – Workshopband. Gesellschaft für Informatik e.V., Bonn. doi.org/10.18420/muc2025-mci-ws-107
- [11] AK Technik of the Independent Data Protection Supervisory Authorities of the Federation and the Länder. 2022. The Standard Data Protection Model (Version 3.0a). Technical Report. UAG Standard Data Protection Model of the AK Technik of the Independent Data Protection Supervisory Authorities of the Federation and the Länder. datenschutz-mv.de/static/DS/Dateien/Datenschutzmodell/SDM_V3_en.pdf
- [12] Schmitt, H. & Groen, E. C. (2021). Qualitätsmodell zur Förderung des Beschäftigtendatenschutzes. Datenschutz und Datensicherheit – DuD 45(1), 28–32. doi.org/10.1007/s11623-020-1385-y
- [13] Tolsdorf, J., Dehling, F., Reinhardt, D., & Lo Iacono, L. (2021). Exploring mental models of the right to informational self-determination of office workers in Germany. Proceedings on Privacy Enhancing Technologies, 2021(3), 5–27. doi.org/10.2478/popets-2021-0035
- [14] Johansen, J. & Fischer-Hübner, S. (2020). Making GDPR usable: A model to support usability evaluations of privacy. In M. Friedewald et al. (eds.): “Privacy and Identity Management. Data for Better Living: AI and Privacy: Revised Selected Papers” (pp. 275–291), Cham, Switzerland: Springer. doi.org/10.1007/978-3-030-42504-3_18
- [15]ISO (2019). Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems. Standard ISO 9241-210:2019(E). Geneva, Switzerland: International Organization for Standardization. iso.org/standard/77520.html
- [16] Schmitt, H. & Polst, S. (2020). Anforderungen und Rahmenwerk für den betrieblichen Datenschutz. Softwaretechnik-Trends, 40(1), 9–10. doi.org/10.18420/swt40-1_05
- [17] Schmitt, H. & Storck, S. (2023). Usable Privacy: Geeginete RE-Methoden für benutzerfreundlichen Datenschutz. Presented at REConf, 23 April 2023. Available: daccord-projekt.de/WP/daccord-bei-der-reconf-2023-in-muenchen-ein-rueckblick
- [18] Schmitt, H. & Storck, S. (2023). Usable Privacy: Wie RE-Methoden angepasst werden können, um benutzerfreundlichen Datenschutz zu erreichen. Presented at Modern RE. Available: daccord-projekt.de/WP/daccord-bei-der-modern-re-2023-in-leipzig-ein-rueckblick
- [19] Rupp, C. (2014). Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil (6th ed.). Munich, Germany: Hanser. ISBN 978-3-446-43893-4.
- [20] Almaliki, M., Ncube, C., & Ali, R. (2015): Adaptive software-based feedback acquisition: A persona-based design. In: Proceedings of the 9th International Conference on Research Challenges in Information Science (RCIS), 100–111. doi.org/10.1109/RCIS.2015.7128868
- [21] Gulden, J. & Rachmann, A. (2023): The Square of Values for modeling human values in Requirements Engineering. In: Proceedings of the IEEE 31st International Requirements Engineering Conference Workshops (REW), 162–167. doi.org/10.1109/REW57809.2023.00033
- [22] Deters, H., Droste, J., Fechner, M., & Klünder, J. (2023). Explanations on demand: A technique for eliciting the actual need for explanations. In: Proceedings of the IEEE 31st International Requirements Engineering Conference Workshops (REW), 345–351. doi.org/10.1109/REW57809.2023.00065
- [23] Dinev, T. & Hart, P. (2006). An extended privacy calculus model for E-commerce transactions. Information Systems Research, 17(1), 61–80. doi.org/10.1287/isre.1060.0080
Eduard C. (Eddy) Groen is strategic advisor to the executive board on AI and senior requirements engineer at Fraunhofer IESE in Kaiserslautern, Germany. His work focuses on the digital sustainability of complex systems. He holds a PhD in Computer Science on Crowd-based Requirements Engineering and an MSc in Psychology. At IREB, he heads the Special Interest Group on Sustainability (SIGsus).
Hannah Deters is a research associate and PhD candidate at the Software Engineering Group at Leibniz Universität Hannover, Germany, from where she also received her master’s degree in Computer Science. Her research focuses on explainability in the context of Requirements Engineering and the automatic detection of explainability needs.
Jakob Droste is a research associate and PhD candidate at the Software Engineering Group at Leibniz Universität Hannover, Germany, from where he also received his master’s degree in Computer Science. His current research focus is on explainability as a non-functional requirement and on user experience design.
