ABSTRACT Recent studies have shown that many software developers do not have sufficient knowledge and understanding of how to develop a privacy‐friendly system. This may become a challenge in developing systems complying with data protection laws. To address this issue, we investigated the factors that influence developers' decision‐making when developing privacy‐sensitive systems. We conducted an empirical study by means of a survey with 109 practitioners. Our data analysis is based on the principles of social cognitive theory, which includes personal, behavioral, and external environmental factors. We identified six personal, five behavioral, and five external environment factors that affect how developers make decisions regarding privacy, including confusion between privacy and security and reliance on informal practices and organizational support gaps. These findings contribute to understanding how practitioners and companies consider privacy, showing improvements in formal training and structured support over previous studies yet highlighting persistent challenges in consistent privacy integration.

Assurance Case Development is an emerging approach for demonstrating that a system is safe. An assurance case includes top-level claims for a property of a system (e.g., safety) and a structured argumentation that breaks down claims into supporting evidence. Its production is an effortful activity that relies on project information and its associated traceability. It is challenging for developers to build assurance cases as they have to identify and gather the project information relevant to the argumentation and assess its consistency and completeness. However, regular project information (e.g. requirements, design, rationale) and assurance-related information (e.g. hazard, causes, mitigation strategies) are likely managed separately. In this context, we designed the ARCADE framework to support the integration of assurance information together with regular information inside project management tools, and to perform automated consistency/completeness analysis and generation of assurance cases. Thus, our approach promotes early and continuous review of traceability information needed to produce assurance cases, while automating their construction. In this work, we present the design of the framework and its current implementation.

Privacy has become a concern in Agile Software Development (ASD), either to satisfy users' needs or to comply with privacy laws. However, recent studies have shown that ASD approaches still neglect non-functional requirements (NFRs), as is the privacy case. This concern and new data protection laws that came into force recently led companies to face the challenges to understand the laws and to comply with them. In addition, research has shown that many developers do not have sufficient knowledge about how to develop privacy-sensitive software. Motivated by this scenario, this tutorial aims to draw attention to the need to understand privacy from the beginning of the software development lifecycle. Initially, we will present an overview of privacy, as well as several privacy principles. Later, we will show the main data protection laws (In-depth detailing of the General Data Protection Regulation - GDPR). Then, we will discuss how to read and evaluate privacy policies. Finally, we will present an approach for specifying privacy requirements in ASD called Privacy Criteria Method (PCM). At the end of the tutorial, participants will be able to have a critical and technical view of privacy when performing the requirements specification activity.

Requirements Engineering and Architectural Design are activities of the software development process that are strongly related and intertwined. Thus, providing effective methods of integration between requirements and architecture is an important Software Engineering challenge. In this context, the STREAM process presents a model-driven approach to generate early software architecture models from requirements models. Despite being a systematic derivation approach, STREAM does not support the documentation of architectural decisions and their corresponding rationale. Recent studies in the software architecture community have stressed the need to treat architectural design decisions and their rationale as first class citizens in software architecture specification. In this paper we define an extension of this process, named STREAM-ADD (Strategy for Transition between Requirements and Architectural Models with Architectural Decisions Documentation). This extended process aims to systematize the documentation of architectural decisions by the time they are made and to support the refinement of the architecture according to such decisions. In order to illustrate our approach, it was applied for creating the architecture specification of a route-planning system.

i* is a framework for goal-oriented requirements modeling. This framework contains an organizational modeling language defined by actors and dependencies among them. Although i* has been widely used, it is still hard to work with it due to its diversity of variants. In this paper, we propose a unified metamodel that presents elements of two well-known variants of i*. We show how OCL restrictions can be applied this metamodel in order to generate a specific variant. In doing so, we intend to unify the efforts of i* community. This metamodel can be useful when developing generic tools for i*, as well as to reason about i* language. Moreover, it makes it easier to extend the i* language. Thus, our proposal is an attempt towards the unification on i* variants by considering similarities and differences among them.

This poster outlines a set of rules to systematically identify crosscutting concerns present in i* models, and modularizing them using aspects. The result is the reduction of the complexity of those models