Context: Traceability is a key quality attribute of artifacts that are used in knowledge-intensive tasks and supports software engineers in producing higher-quality software. Despite its clear benefits, traceability is often neglected in practice due to challenges such as granularity of traces, lack of a common artifact structure, and unclear responsibility. The Taxonomic Trace Links (TTL) approach connects source and target artifacts through a domain-specific taxonomy, aiming to address these common traceability challenges.

Objective: In this study, we empirically evaluate TTL in an industrial setting to identify its strengths and weaknesses for real-world adoption.

Method: We conducted a mixed-methods study at Ericsson involving one of its software products. Quantitative and qualitative data were collected across two traceability use cases. We established trace links between 463 business use cases, 64 test cases, and 277 ISO-standard requirements. Additionally, we held three focus group sessions with practitioners.

Results: We identified two practically relevant scenarios where traceability is required and evaluated TTL in each. Overall, practitioners found TTL to be a useful solution for identifying trace links with reasonable effort. However, developing a domain-specific taxonomy and managing heterogeneous artifact structures were noted as significant challenges.

Conclusion: TTL is a promising approach that can be adopted in practice and enables traceability use cases. However, TTL are not a replacement for traditional trace links, but complementary to enable more traceability use cases, and encourage early trace links creation.

Background: Poor communication of requirements between clients and suppliers contributes to project overruns, in both software and infrastructure projects. Existing literature offers limited insights into the communication challenges at this interface.

Aim: Our research aim to explore the processes and associated challenges with requirements activities that include client-supplier interaction and communication.

Method: we study requirements validation, communication, and digital asset verification processes through two case studies in the road and railway sectors, involving interviews with ten experts across three companies.

Results: We identify 13 challenges, along with their causes and consequences, and suggest solution areas from existing literature.

Conclusion: Interestingly, the challenges in infrastructure projects mirror those found in software engineering, highlighting a need for further research to validate potential solutions.

This vision paper explores the factors that impact the aging and depreciation of software. Based on the exploration of related work in software aging, software anti-aging, the financial aspect of technical debt and accounting of intangible assets, we postulate that a more holistic approach towards obsolescence should be taken as most research focuses solely on the technical aspects of software aging, leaving the business and accounting aspects greatly unexplored. 

Context: In software development organizations employing weak or collective ownership, different teams are allowed and expected to autonomously perform changes in various components. This creates diversity both in the knowledge of, and in the responsibility for, individual components.

Objective: Our objective is to understand how and why different teams introduce technical debt in the form of code clones as they change different components.

Method: We collected data about change size and clone introductions made by ten teams in eight components which was part of a large industrial software system. We then designed a Multi-Level Generalized Linear Model (MLGLM), to illustrate the teams’ differing behavior. Finally, we discussed the results with three development teams, plus line manager and the architect team, evaluating whether the model inferences aligned with what they expected. Responses were recorded and thematically coded.

Results: The results show that teams do behave differently in different components, and the feedback from the teams indicates that this method of illustrating team behavior can be useful as a complement to traditional summary statistics of ownership.

Conclusions: We find that our model-based approach produces useful visualizations of team introductions of code clones as they change different components. Practitioners stated that the visualizations gave them insights that were useful, and by comparing with an average team, inter-team comparisons can be avoided. Thus, this has the potential to be a useful feedback tool for teams in software development organizations that employ weak or collective ownership. © The Author(s) 2024.

Background:

Multi-label requirements classification is an inherently challenging task, especially when dealing with numerous classes at varying levels of abstraction. The task becomes even more difficult when a limited number of requirements is available to train a supervised classifier.  Zero-shot learning does not require training data and can potentially address this problem.

Objective:

This paper investigates the performance of zero-shot classifiers on a multi-label industrial dataset. The study focuses on classifying requirements according to a hierarchical taxonomy designed to support requirements tracing.

Method:

We compare multiple variants of zero-shot classifiers using different embeddings, including 9 language models (LMs) with a reduced number of parameters (up to 3B), e.g., BERT, and 5 large LMs (LLMs) with a large number of parameters (up to 70B), e.g., Llama. Our ground truth includes 377 requirements and 1968 labels from 6 output spaces. For the evaluation, we adopt traditional metrics, i.e., precision, recall, $F_1$, and $F_\beta$, as well as a novel label distance metric $D_n$. This aims to better capture the classification's hierarchical nature and to provide a more nuanced evaluation of how far the results are from the ground truth.

Results:

1) The top-performing model on 5 out of 6 output spaces is T5-xl, with maximum  $F_\beta = 0.78$ and $D_n = 0.04$, while BERT base outperformed the other models in one case, with maximum $F_\beta = 0.83$ and $D_n = 0.04$. 2) LMs with smaller parameter size produce the best classification results compared to LLMs. Thus, addressing the problem in practice is feasible as limited computing power is needed. 3) The model architecture (autoencoding, autoregression, and sentence-to-sentence) significantly affects the classifier's performance.

Contribution:

We conclude that using zero-shot learning for multi-label requirements classification offers promising results. We also present a novel metric that can be used to select the top-performing model for this problem.

This extended abstract presents our vision of requirements engineering for responsible use of AI for creating software solutions for neurodiverse and elderly communities. Our approach highlights that responsible AI is not a technical fix but a socio-technical commitment - one that requires grounding in participatory design, digital inclusion, and context-sensitive policy. 

Trafikverket is responsible for planning, ordering and accepting deliverables from suppliers and maintaining Sweden’s infrastructure. As a client organization, in the planning phase they have the responsibility to communicate requirements to supplier and set the acceptance criteria for the delivered assets, such as design documents.

The verification of deliverables is the responsibility of suppliers. However, due to the large number of regulatory requirements and the extent of the deliverables, a complete verification is often not possible. The supplier has no objective mean to show that all requirements are fulfilled, which increases Trafikverket’s workload when accepting deliverables.

In this project, we investigated the means to automate compliance checks (ACC) of digital assets. This overall aim was divided into three objectives.

First, we developed a maturity model to assess Trafikverket’s capabilities to implement ACC. We designed the ACC maturity model to be compatible with Trafikverket’s effort to establish a digitalization maturity model. The model consists of four levels, each containing activities that are either lead by the client, supplier or require shared leadership. The capability of performing ACC depends on the degree to which these activities are performed.

Second, we analyzed Trafikverket’s regulatory requirements regarding their verifiability, i.e. to what degree it is objectively decidable if a requirement is fulfilled or not. We trained a deep learning model to classify requirements according to four dimensions: target, nature, interpretability and reference. These dimensions allow one to characterize to what degree a requirement is automatically verifiable. We applied this classifier on 18.000 TRVInfra requirements.

Third, we developed an automated verification process, based on the analysis of verifiable requirements. The first step in in this process is to make the requirements machine readable so that their information can be queried for further processing. This information can then be used to automatically generate Information Delivery Specifications (IDS), which in turn are the basis for the verification. The verification can then be performed with tools that can check IDS compliance of IFC files.

The project was executed in collaboration with HOCHTIEF ViCon who have expertise in the construction domain and complement BTH’s expertise in requirements engineering, verification and natural language processing. The detailed results, together with the project deliverables, are reported in Section 4 to Section 0.

The results of the project have the potential to contribute to a more efficient verification process at suppliers. Even though only a fraction of requirements can be automatically verified, this reduction in workload allows engineers to focus on technically difficult requirements. Acceptance testing can then also focus on aspects that are not automatically verifiable, reducing thereby also the workload at Trafikverket and increasing the confidence in the deliverable. As a result of widely adopted ACC, Trafikverket’s projects could see a reduction in cost and lead time, benefiting citizens paying for and using infrastructure.

Background

Code review, the discussion around a code change among humans, forms a communication network that enables its participants to exchange and spread information. Although reported by qualitative studies, our understanding of the capability of code review as a communication network is still limited.

Objective

In this article, we report on a first step towards understanding and evaluating the capability of code review as a communication network by quantifying how fast and how far information can spread through code review: the upper bound of information diffusion in code review.

Method

In an in-silico experiment, we simulate an artificial information diffusion within large (Microsoft), mid-sized (Spotify), and small code review systems (Trivago) modelled as communication networks. We then measure the minimal topological and temporal distances between the participants to quantify how far and how fast information can spread in code review.

Results

An average code review participants in the small and mid-sized code review systems can spread information to between 72 % and 85 % of all code review participants within four weeks independently of network size and tooling; for the large code review systems, we found an absolute boundary of about 11 000 reachable participants. On average (median), information can spread between two participants in code review in less than five hops and less than five days.

Conclusion

We found evidence that the communication network emerging from code review scales well and spreads information fast and broadly, corroborating the findings of prior qualitative work. The study lays the foundation for understanding and improving code review as a communication network.

Requirements attributes play an important role in storing and managing meta-information about requirements. This paper presents the results of a literature review and two industrial case studies performed at two large organizations developing software-intensive products for a global market. We performed seven snowballing iterations and identified 18 studies where we extracted requirements attributes. Next, we compare these identified attributes with those of two large companies developing software-intensive products for a global market. We found common attributes that describe stakeholders and roles, support change management, tracing and communication, tracking the status, and estimating the business value of requirements. 

During software evolution, decisions related to components' origin or source significantly impact the quality properties of the product and development metrics such as cost, time to market, ease of maintenance, and further evolution. Thus, such decisions should ideally be supported by evidence, i.e., using previous experiences and information from different sources, even own previous experiences. A hindering factor to such reuse of previous experiences is that these decisions are highly context-dependent and it is difficult to identify when previous experiences come from sufficiently similar contexts to be useful in a current setting. Conversely, when documenting a decision (as a decision experience), it is difficult to know which context factors will be most beneficial when reusing the experience in the future. An interview study is performed to identify a list of context factors that are perceived to be most important by practitioners when using experiences to support decision-making for component sourcing, using a specific scenario with alternative sources of experiences. We observed that the further away (from a company or an interviewee) the experience evidence is, as is the case for online experiences, the more context factors are perceived as important by practitioners to make use of the experience. Furthermore, we discuss and identify further research to make this type of decision-making more evidence-based. With this interview study, which focuses on which context factors are perceived as important by practitioners when reusing previous knowledge on software component reuse, we contribute with a listing of factors perceived to be important when reusing experiences from other prior decision-making cases of selecting among software components options. image