Companies adopt agile methodologies and DevOps to facilitate efficient development and deployment of software-intensive products. This, in turn, introduces challenges in relation to security standard compliance traditionally following a more linear workflow. This is especially a challenge for the engineering of products and services associated with critical infrastructures. To support companies in their transition towards DevOps, this paper presents an adaptation of DevOps according to security regulations and standards. We report on our longitudinal study at Siemens AG, consisting of several individual sub-studies in the inception, validation, and initial adoption of our framework based on RefA as well as the implications for practice. RefA is a prescriptive model of a security compliant DevOps lifecycle based on the IEC 62443-4-1 standard. The overall framework is aimed at professionals, not only security experts, being able to use it on implementing DevOps processes while remaining compliant with security norms. We demonstrate how RefA facilitates the transfer of security compliance knowledge to product development teams. This knowledge transfer supports the agility aim of ensuring that cross-functional teams have all the skills needed to deliver the compliant products.

Context Boundary artefacts are shared artefacts that support collaboration by allowing different groups to interpret the same information in different ways. Software development activities benefit from them, as a single artefact can support stakeholders across different organisational boundaries. When these artefacts contain inconsistencies, such as incorrect information, practitioners' trust in them may decrease, leading to inefficiencies in task execution.

Objective This study developed and evaluated a guideline to support the creation of boundary artefacts in software engineering contexts.

Method We conducted a longitudinal, multi-phase study embedded in an industrial setting. The guideline was developed based on a literature review and prior findings from a previous case study and was then submitted for practitioner evaluation. A post-implementation analysis of the guideline was carried out after a period without researcher intervention.

Results Our guideline consists of 10 principles grouped into three categories: (1) Scope: stakeholders, boundaries, and terminology; (2) Structure: artefact format, transference, granularity, and additions; and (3) Management: evaluation, ownership, governance, and integration. Practitioner evaluations suggested that these principles support the creation of reliable, predictable, and functional boundary artefacts. However, practitioners also noted challenges during use, including the time-consuming nature of the activity and difficulties in understanding the concept of boundary artefact.

Conclusions Overall, the guideline was well received. After the non-intervention period, it was adopted as a standard by the partner company for artefacts such as security testing, standards documentation, and requirements specifications. Adoption challenges persisted, including cultural barriers and comprehension issues. Further applications across different artefacts could clarify how the principles influence their reliability, functionality, and predictability.

Context: Software systems in regulated domains must continually adapt to legal changes, yet practitioners often handle updates manually with limited support, making compliance work costly and error prone. Recent advances in LLMs prompt the question of how automation can reliably assist this process.

Objectives: We aim to (1) characterize the nature of regulatory changes and derive a systematic taxonomy, (2) understand through the lens of practitioners where automation is most useful, and (3) assess the feasibility of using LLMs for detecting and classifying regulatory changes.

Method: We conducted a mixed-methods study grounded in the German social security (DEÜV) in collaboration with practitioners from a FinTech company. First, we developed a taxonomy of regulatory changes through manual document analysis of four Regulatory Implementation Specifications (RIS), followed by a workshop and expert interviews. Second, we validated the taxonomy and elicited challenges through semi-structured practitioner interviews. Third, we built a gold-standard dataset of 93 annotated change instances and evaluated seven state-of-the-art LLMs within an automated detection and classification pipeline.

Results: The taxonomy defines five change scopes and four optional context dimensions. Practitioners found it intuitive and useful for filtering relevant changes, particularly Data and Field updates, but reported challenges such as tight deadlines, legal ambiguity, limited traceability, and overlapping categories. In automation, proprietary LLMs performed best, while performance dropped on narrative or weakly structured documents, highlighting sensitivity to document format.

Conclusion: The proposed taxonomy provides a practical lens for organizing regulatory change information, and LLMs can support the identification and classification of recurring, structurally explicit changes. Their limitations on context-dependent and infrequent categories suggest that automation should complement, rather than replace, expert assessment, motivating future work on human-in-the-loop compliance tooling across broader regulatory ecosystems. 

Background. The Software Bill of Materials (SBOM) is a machine-readable list of all the software dependencies included in a software. SBOM emerged as way to assist securing the software supply chain. However, despite mandates from governments to use SBOM, research on this artifact is still in its early stages.

Aims. We want to understand the current state of SBOM in open-source projects, focusing specifically on policy-driven SBOMs—i.e., SBOM created to achieve security goals, such as enhancing project transparency and ensuring compliance, rather than being used as fixtures for tools or artificially generated for benchmarking or academic research purposes.

Method. We performed a mining software repository study to collect and carefully select 620 SBOM files hosted on GitHub. We analyzed the information reported in policy-driven SBOMs and the vulnerabilities associated with the declared dependencies by means of descriptive statistics.

Results. We show that only 0.56% of popular GitHub repositories contain policy-driven SBOM. The declared dependencies contain 2,202 unique vulnerabilities, while 22% of them do not report licensing information.

Conclusion. Our findings provide insights for SBOM usage to support security assessment and licensing. 

Context: Consistent requirements and system specifications are essential for the compliance of software systems towards the General Data Protection Regulation (GDPR). Both artefacts need to be "grounded" in the original text and conjointly assure the achievement of privacy by design (PbD).

Objectives: There is little understanding of the perspectives of practitioners on specification objectives and goals to address PbD. Existing approaches to GDPR and PbD do not account for the complex intersection between problem and solution space expressed in GDPR. In this study we explore the demand for conjoint requirements and system specification for PbD and suggest an initial version of an approach to address this demand.

Methods: We reviewed existing secondary and related primary studies on GDPR compliance and conducted interviews with practitioners to (1) investigate the state-of-practice in requirements and system specifications for GDPR compliance and (2) understand the underlying specification objectives and goals (e.g., traceability). We developed and evaluated an initial version of an approach for requirements and systems specification for PbD, and evaluated it against the specification objectives.

Results: The relationship between problem and solution space, as expressed in GDPR, is instrumental in supporting PbD. We demonstrate how our approach, based on the modeling GDPR content with original legal concepts, contributes to specification objectives of capturing legal knowledge, supporting specification transparency for roles involved, and traceability.

Conclusion: In addition to assuring traceability, GDPR demands need to be addressed throughout different levels of abstraction in the engineering lifecycle to achieve PbD. Legal knowledge specified in the GDPR text should be captured in specifications to address the demands of different stakeholders and ensure compliance. While our results confirm the suitability of our approach to address practical needs, we also revealed specific needs for the future effective operationalization of our suggested approach.

Developers now routinely interact with large language models (LLMs) to support a range of software engineering (SE) tasks. This prominent role positions prompts as potential SE artifacts that, like other artifacts, may require systematic development, documentation, and maintenance. However, little is known about how prompts are actually used and managed in LLM-integrated workflows, what challenges practitioners face, and whether the benefits of systematic prompt management outweigh the associated effort. To address this gap, we propose a research programme that (a) characterizes current prompt practices, challenges, and influencing factors in SE; (b) analyzes prompts as software artifacts, examining their evolution, traceability, reuse, and the trade-offs of systematic management; and (c) develops and empirically evaluates evidence-based guidelines for managing prompts in LLM-integrated workflows. As a first step, we conducted an exploratory survey with 74 software professionals from six countries to investigate current prompt practices and challenges. The findings reveal that prompt usage in SE is largely ad-hoc: prompts are often refined through trial-and-error, rarely reused, and shaped more by individual heuristics than standardized practices. These insights not only highlight the need for more systematic approaches to prompt management but also provide the empirical foundation for the subsequent stages of our research programme. 

Implementing privacy by design (PbD) according to the General Data Protection Regulation (GDPR) is met with a growing number of requirements engineering (RE) approaches. However, the question of which RE method for PbD fits best the goals of organisations remains a challenge. We report our endeavor to close this gap by synthesizing a goal-centric approach for PbD methods assessment. We used literature review, interviews, and validation with practitioners to achieve the goal of our study. As practitioners do not approach PbD systematically, we suggest that RE methods for PbD should be assessed against organisational goals, rather than process characteristics only. We hope that, when further developed, the goal-centric approach could support the development, selection, and tailoring of RE practices for PbD. 

The COVID-19 pandemic has permanently altered workplace structures, making remote work a widespread practice. While many employees advocate for flexibility, many employers reconsider their attitude toward remote work and opt for structured return-to-office mandates. Media headlines repeatedly emphasize that the corporate world returns to full-time office work. This study examines how companies in software-intensive industry regulate work location, whether corporate policies have evolved in the last five years, and, if so, how, and why. We collected data on remote work regulation from corporate HR and management representatives from 68 companies that vary in size, location, and preferred work modality. Our findings reveal that although many companies prioritize office-oriented work (50%), most companies in our sample permit hybrid work (84%) and only four companies are returning to full-time office work. Remote work regulation does not reveal any particular new “best practice” as policies differ greatly; however, the single most popular arrangement was the three in-office days per week. More than half of the companies (53%) encourage or mandate office attendance centrally, with additional 18% having decentralized mandates. Over a quarter (28%) have changed regulations gradually increasing the mandatory office presence or implementing differentiated conditions. Our key recommendation for office-oriented companies is to consider trust-based recommendations as an alternative to centralized office presence mandates, while for companies oriented toward remote working, we warn about the points of no (or hard) return. Finally, the current state of policies is clearly not final, as companies continue to experiment and adjust their work regulation.

The growing complexity, the ever-ending demands for new features, and the need to become faster to remain competitive force software development organizations to rethink their development and value delivery practices. While continuous delivery has become more popular, it still relies mainly on internal metrics, ad-hoc data, and expert opinions. As a result, software organizations stumble to find the balance between improving internal system quality and delivering external value. In fact, understanding and measuring customer value is on itself essential. In this PhD project, we aim for a better understanding of customer value and develop measurement instruments to be integrated with internal perspectives to drive proactive and continuous internal improvement while delivering relevant customer value. 

It is commonly accepted that the quality of requirements specifications impacts subsequent software engineering activities. However, we still lack empirical evidence to support organizations in deciding whether their requirements are good enough or impede subsequent activities. We aim to contribute empirical evidence to the effect that requirements quality defects have on a software engineering activity that depends on this requirement. We conduct a controlled experiment in which 25 participants from industry and university generate domain models from four natural language requirements containing different quality defects. We evaluate the resulting models using both frequentist and Bayesian data analysis. Contrary to our expectations, our results show that the use of passive voice only has a minor impact on the resulting domain models. The use of ambiguous pronouns, however, shows a strong effect on various properties of the resulting domain models. Most notably, ambiguous pronouns lead to incorrect associations in domain models. Despite being equally advised against by literature and frequentist methods, the Bayesian data analysis shows that the two investigated quality defects have vastly different impacts on software engineering activities and, hence, deserve different levels of attention. Our employed method can be further utilized by researchers to improve reliable, detailed empirical evidence on requirements quality. © The Author(s) 2024.