Requirements Engineering最新文献

The success of software projects depends on developing a system that satisfies the stakeholders’ wishes and needs according to their mental models of the intended system. However, stakeholders may have misaligned mental models of the same system, resulting in conflicting requirements. For this reason, a shared understanding of the project vision is essential for the success of software projects. While it is already challenging to achieve shared understanding in synchronous contexts, such as meetings, it is even more challenging when only asynchronous contexts, like messaging services, are possible. When multiple stakeholders are involved from different locations and time zones, primarily asynchronous communication occurs. The use of asynchronous communication tools for the development of a shared understanding has hardly been analyzed. In this paper, we look to turn the potential detriment of having to discuss a project vision asynchronously into an opportunity for stakeholders to achieve a shared understanding. For this purpose, we give an overview of common challenges of asynchronous communication. We also propose five concepts designed to minimize the impact of these challenges. We examine categories of asynchronous communication tools and assess their adaptability to our concepts. In a workshop, we chose three most suited representatives to include in our main experiment. In this experiment, we evaluate the adapted representatives and a prototype of our own with 30 participants. Our results show the suitability of our concepts. Participants using our concepts were able to achieve a higher level of shared understanding.

Formal pattern languages are used in industry to communicate and analyse requirements, as they are said to be both machine-readable and intuitively understandable for humans. The questions arise to what extent this intuitive understanding of a pattern language is in agreement with its formal semantics and whether this understanding can be increased systematically. We present two consecutive empirical experiments to address these questions. The formal semantics serves as an objective judge on the intuitive understanding. Our experiments confirm the practical usefulness of HanforPL insofar the intuition matches the formal semantics in most practically relevant cases. They also reveal a number of edge cases where even a prior exposure to formal logic is not a guarantee for correct understanding. We present and validate systematic adjustments to the patterns, leading to several large increases in understandability but come at the cost of new, but less impactful ambiguities. We demonstrate how an inquiry on the alignment of the intuitive and formal semantics of a pattern language can help to understand and improve the language. While results regarding the understandability of HanforPL are favourable in commonly used cases, there is potential for improvement. The systematic adaption of patterns shows that small modifications may have large effects on the alignment of formal and intuitive semantics, and that modification must be considered with caution in the context of the respective pattern to avoid unintentionally adding new ambiguities. This article is an extension of our published REFSQ paper.

Natural language (NL) is arguably the most prevalent medium for expressing systems and software requirements. Detecting incompleteness in NL requirements is a major challenge. One approach to identify incompleteness is to compare requirements with external sources. Given the rise of large language models (LLMs), an interesting question arises: Are LLMs useful external sources of knowledge for detecting potential incompleteness in NL requirements? This article explores this question by utilizing BERT. Specifically, we employ BERT’s masked language model to generate contextualized predictions for filling masked slots in requirements. To simulate incompleteness, we withhold content from the requirements and assess BERT’s ability to predict terminology that is present in the withheld content but absent in the disclosed content. BERT can produce multiple predictions per mask. Our first contribution is determining the optimal number of predictions per mask, striking a balance between effectively identifying omissions in requirements and mitigating noise present in the predictions. Our second contribution involves designing a machine learning-based filter to post-process BERT’s predictions and further reduce noise. We conduct an empirical evaluation using 40 requirements specifications from the PURE dataset. Our findings indicate that: (1) BERT’s predictions effectively highlight terminology that is missing from requirements, (2) BERT outperforms simpler baselines in identifying relevant yet missing terminology, and (3) our filter reduces noise in the predictions, enhancing BERT’s effectiveness for completeness checking of requirements.

Abstract

The development and operation of critical software that contains machine learning (ML) models requires diligence and established processes. Especially the training data used during the development of ML models have major influences on the later behaviour of the system. Runtime monitors are used to provide guarantees for that behaviour. Runtime monitors for example check that the data at runtime is compatible with the data used to train the model. In a first step towards identifying challenges when specifying requirements for training data and runtime monitors, we conducted and thematically analysed ten interviews with practitioners who develop ML models for critical applications in the automotive industry. We identified 17 themes describing the challenges and classified them in six challenge groups. In a second step, we found interconnection between the challenge themes through an additional semantic analysis of the interviews. We explored how the identified challenge themes and their interconnections can be mapped to different architecture views. This step involved identifying relevant architecture views such as data, context, hardware, AI model, and functional safety views that can address the identified challenges. The article presents a list of the identified underlying challenges, identified relations between the challenges and a mapping to architecture views. The intention of this work is to highlight once more that requirement specifications and system architecture are interlinked, even for AI-specific specification challenges such as specifying requirements for training data and runtime monitoring.

Goal-oriented requirements engineering aims to describe both stakeholders and system goals and their relationships using goal models. Large goal models for complex systems are often constructed from sub-models describing various stakeholders’ views and context-related aspects. These goal-oriented sub-models, also called views, may exhibit overlaps and present discrepancies. Hence, integrating such views is considered a significant barrier to the construction of a unified goal model. Current approaches to merging goal models require intensive human intervention. This paper proposes an approach and a prototype tool, called GRLMerger, to integrate two GRL (Goal-oriented Requirement Language) models into one consolidated model that is correct, complete, and free from any conflict that may arise during the merging process. GRLMerger considers both syntactic and semantic aspects of the GRL models and allows analysts to merge them either interactively or in a fully automated mode. GRLMerger employs natural language processing (NLP) techniques to match intentional elements based on their semantic similarity. The proposed GRLMerger approach and tool have been validated using 12 experimental tasks derived from two case studies, exhibiting very promising performance.

Requirements Engineering (RE) has undergone several transitions over the years, from traditional methods to agile approaches emphasising increased automation. In many software development projects, requirements are expressed in natural language and embedded within large volumes of text documents. At the same time, RE activities aim to define software systems' functionalities and constraints. However, manually executing these tasks is time-consuming and prone to errors. Numerous research efforts have proposed tools and technologies for automating RE activities to address this challenge, which are documented in published works. This review aims to examine empirical evidence on automated RE and analyse its impact on the RE sub-domain and software development. To achieve our goal, we conducted a Systematic Literature Review (SLR) following established guidelines for conducting SLRs. We aimed to identify, aggregate, and analyse papers on automated RE published between 1996 and 2022. We outlined the output of the support tool, the RE phase covered, levels of automation, development approach, and evaluation approaches. We identified 85 papers that discussed automated RE from various perspectives and methodologies. The results of this review demonstrate the significance of automated RE for the software development community, which has the potential to shorten development cycles and reduce associated costs. The support tools primarily assist in generating UML models (44.7%) and other activities such as omission of steps, consistency checking, and requirement validation. The analysis phase of RE is the most widely automated phase, with 49.53% of automated tools developed for this purpose. Natural language processing technologies, particularly POS tagging and Parser, are widely employed in developing these support tools. Controlled experimental methods are the most frequently used (48.2%) for evaluating automated RE tools, while user studies are the least employed evaluation method (8.2%). This paper contributes to the existing body of knowledge by providing an updated overview of the research literature, enabling a better understanding of trends and state-of-the-art practices in automated RE for researchers and practitioners. It also paves the way for future research directions in automated requirements engineering.

People with disabilities (PwD) are frequently excluded from certain activities due to the lack of accessible information. In this area, information systems can help PwD by allowing access to a range of information about the accessibility of spaces, facilities, and products. There has been an increase in technologies that promote accessibility, but there are few literature studies which analyse how these technologies were developed to ensure access for all. To address this gap, this study aims to explore the integration of accessibility requirements in the processes of developing information systems. To achieve this aim, a systematic literature review was conducted using the PRISMA reporting guidelines. To conduct the review, a search was carried out for primary studies in four well-established databases—SCOPUS, Web of Science, IEEE, and ACM. A snowball search to find additional studies was also performed. Based on this, 34 papers were obtained to conduct the study. In general, the studies published on this topic are relatively recent, with healthcare and education being the two major areas where accessibility in information systems is most addressed. The integration of accessibility seems to be primarily applied during the requirement assessment and testing phases, involving potential users in the process. The results obtained within this systematic literature review raise awareness about the integration of accessibility for the success of solutions, which are oriented towards the accessible market. Additionally, the different practical and theoretical contributions can help future practitioners and technology developers establish guidelines that promote the integration of accessibility, thus achieving a more accessible and inclusive society.

Requirements traceability (RT) is the ability to link requirements to other software development artifacts. In pre-requirements (pre-RS) traceability, requirements are linked to their origin, such as interviews with stakeholders, meeting protocols, or legacy systems. Compared with post-RS traceability, which links requirements to source code and other later artifacts, pre-RS traceability has seen much less research. This article presents a systematic literature review of pre-RS traceability based on 77 articles published between 1992 and 2022, aiming to provide a comprehensive overview of its use cases, benefits, problems, and solutions. Through the analysis of existing literature, this review identifies gaps for future research and establishes a foundation for future investigations in the field of pre-RS traceability.

Driving automation systems, including autonomous driving and advanced driver assistance, are an important safety-critical domain. Such systems often incorporate perception systems that use machine learning to analyze the vehicle environment. We explore new or differing topics and challenges experienced by practitioners in this domain, which relate to requirements engineering (RE), quality, and systems and software engineering. We have conducted a semi-structured interview study with 19 participants across five companies and performed thematic analysis of the transcriptions. Practitioners have difficulty specifying upfront requirements and often rely on scenarios and operational design domains (ODDs) as RE artifacts. RE challenges relate to ODD detection and ODD exit detection, realistic scenarios, edge case specification, breaking down requirements, traceability, creating specifications for data and annotations, and quantifying quality requirements. Practitioners consider performance, reliability, robustness, user comfort, and—most importantly—safety as important quality attributes. Quality is assessed using statistical analysis of key metrics, and quality assurance is complicated by the addition of ML, simulation realism, and evolving standards. Systems are developed using a mix of methods, but these methods may not be sufficient for the needs of ML. Data quality methods must be a part of development methods. ML also requires a data-intensive verification and validation process, introducing data, analysis, and simulation challenges. Our findings contribute to understanding RE, safety engineering, and development methodologies for perception systems. This understanding and the collected challenges can drive future research for driving automation and other ML systems.

Researchers have proposed numerous tools, methods, and techniques for establishing and maintaining software traceability. Despite its acknowledged importance, researchers argue that traceability is still “a sought-after, yet often elusive quality in software-intensive systems”. We have little evidence regarding how creating, managing, and using traceability links vary depending on factors such as organizational contexts, software development practices, and project types. We conduct an empirical study where software development practitioners express their perception regarding the value of software traceability. Via an online survey, 55 participants provided information related to their current traceability practices and needs. Furthermore, we interviewed 14 practitioners to gain a more in-depth understanding. Our study investigates the effect of two independent variables: the software development paradigm and the type of developed software system. Among the several identified findings, our analysis reveals that, although the traceability costs are an inhibitor for adopting more mature traceability practices, the respondents believe that the expected benefits still outweigh envisioned costs. Traceability is mainly performed manually: not only are automated trace retrieval tools scarce, but their offered automation is not expected to replace human involvement.