Reusing knowledge on delivering privacy and transparency together

Zinovatna, Olena; Cysneiros, Luiz Marcio

doi:10.1109/repa.2015.7407733

Cited by 15 publications

(12 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Zinovatna and Cysneiros [101] investigated the interdependencies between transparency and privacy. They established them as two intertwined concepts that need to be correctly elicited in order to determine the necessary architectural decisions.…”

Section: Transparencymentioning

confidence: 99%

Explainability as a non-functional requirement: challenges and recommendations

2020

View full text Add to dashboard Cite

Software systems are becoming increasingly complex. Their ubiquitous presence makes users more dependent on their correctness in many aspects of daily life. As a result, there is a growing need to make software systems and their decisions more comprehensible, with more transparency in software-based decision making. Transparency is therefore becoming increasingly important as a non-functional requirement. However, the abstract quality aspect of transparency needs to be better understood and related to mechanisms that can foster it. The integration of explanations into software has often been discussed as a solution to mitigate system opacity. Yet, an important first step is to understand user requirements in terms of explainable software behavior: Are users really interested in software transparency and are explanations considered an appropriate way to achieve it? We conducted a survey with 107 end users to assess their opinion on the current level of transparency in software systems and what they consider to be the main advantages and disadvantages of embedded explanations. We assess the relationship between explanations and transparency and analyze its potential impact on software quality. As explainability has become an important issue, researchers and professionals have been discussing how to deal with it in practice. While there are differences of opinion on the need for built-in explanations, understanding this concept and its impact on software is a key step for requirements engineering. Based on our research results and on the study of existing literature, we offer recommendations for the elicitation and analysis of explainability and discuss strategies for the practice.

show abstract

Section: Transparencymentioning

confidence: 99%

Explainability as a non-functional requirement: challenges and recommendations

2020

View full text Add to dashboard Cite

show abstract

“…These solutions are also referred to as operationalizations. Rather than use the term "satisfy", since an NFR can rarely be fully satisfied, we use the term "satisfice" to indicate that the NFR is satisfied to a reasonable degree [1]. This relationship could include causal conditions, phenomena, strategies, and context.…”

Section: Research Approachmentioning

confidence: 99%

“…Software today is omnipresent in daily life. Transparency is becoming more and more important to consumers, which extends to the final product and the developmental process itself [1]. Consumers need to trust software and software developers [2], but this Trust is frequently violated, leading to loss of Trust.…”

Section: Introductionmentioning

confidence: 99%

“…This led Facebook to respond with apologies through major UK and US media [3]. Being transparent in their late apology 1 , Facebook aimed to retain consumers. On another front, AI advances, including the current high-profile issue of autonomous vehicles, lead to complex ethical dilemmas that impair user trust.…”

Section: Introductionmentioning

confidence: 99%

“…In the event of collisions leading to loss of property, or worse, loss of life, the party responsible for reparations is unclear [4]. The Mercedes-Benz automotive corporation has announced that its self-driving vehicles will be 1 The breach occurred in 2014 and the apology was published in March 2018.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Artifacts for Towards Achieving Trust Through Transparency and Ethics [RE 21]

Kwan,

Cysneiros,

Leite

2021

Self Cite

View full text Add to dashboard Cite

The ubiquitous presence of software in the products we use, together with Artificial Intelligence in these products, has led to an increasing need for consumer trust. Consumers often lose faith in products, and the lack of Trust propagates to the companies behind them. This is even more so in mission-critical systems such as autonomous vehicles and clinical support systems. This paper follows grounded theory principles to elicit knowledge related to Trust, Ethics, and Transparency. We approach these qualities as Non-Functional Requirements (NFRs), aiming to build catalogs to subsidize the construction of Socially Responsible Software. The corpus we have used was built on a selected collection of literature on Corporate Social Responsibility, with an emphasis on Business Ethics. Our challenge is how to encode the social perspective knowledge, mainly through the view of Corporate Social Responsibility, on how organizations or institutions achieve trustworthiness. Since our ground perspective is that of NFRs, results are presented by a catalogue of Trust as a Non-Functional Requirement, represented as a Softgoal Interdependency Graph (SIG). The SIG language helps software engineers in understanding alternatives they have to improve Trust in software products.

show abstract

SCARS: Suturing wounds due to conflicts between non‐functional requirements in autonomous and robotic systems

Roy,

Bag,

Deb

et al. 2023

Softw Pract Exp

View full text Add to dashboard Cite

In autonomous and robotic systems, the functional requirements (FRs) and non‐functional requirements (NFRs) are gathered from multiple stakeholders. The different stakeholder requirements are associated with different components of the robotic system and with the contexts in which the system may operate. This aggregation of requirements from different sources (multiple stakeholders) often results in inconsistent or conflicting sets of requirements. Conflicts among NFRs for robotic systems heavily depend on features of actual execution contexts. It is essential to analyze the inconsistencies and conflicts among the requirements in the early planning phase to design the robotic systems in a systematic manner. In this work, we design and experimentally evaluate a framework, called SCARS, providing: (a) a domain‐specific language extending the ROS2 Domain Specific Language (DSL) concepts by considering the different environmental contexts in which the system has to operate, (b) support to analyze their impact on NFRs, and (c) the computation of the optimal degree of NFR satisfaction that can be achieved within different system configurations. The effectiveness of SCARS has been validated on the iRobot Create3 robot using Gazebo simulation.

show abstract

Reusing knowledge on delivering privacy and transparency together

Cited by 15 publications

References 25 publications

Explainability as a non-functional requirement: challenges and recommendations

Explainability as a non-functional requirement: challenges and recommendations

Artifacts for Towards Achieving Trust Through Transparency and Ethics [RE 21]

SCARS: Suturing wounds due to conflicts between non‐functional requirements in autonomous and robotic systems

Contact Info

Product

Resources

About