Requirements Engineering最新文献

Rapid changes in customer needs (CNs) and technology force businesses to develop new products to compete. Functional requirements (FRs) and non-functional requirements (NFRs) are created when CNs are correctly interpreted. FRs specify what the product must do, whereas NFRs specify how a system must behave. The study presents a comprehensive framework that helps product developers accurately and quickly extract the essential NFRs. This is because there is still no agreement in the requirements engineering community regarding which NFRs should be elicited for developing a system and how they should be applied and documented. Moreover, the majority of research in this area has either concentrated more on the field of software development or given more attention to applying FRs and less attention to NFRs. The presented framework applies the integrated approaches of QFD, DSM, and hesitant fuzzy sets (HFS). Design for eXcellence is also used to ensure that system quality attributes, such as NFRs, are considered during the development process. The framework was used to develop a solar power system, and the results indicated that the primary NFRs essential for system development are availability, reliability, maintainability, modularity, flexibility, and extensibility.

Evolving software with an increasing number of features poses challenges in terms of comprehensibility and usability. Traditional software release planning has pre- dominantly focused on orchestrating the addition of features, contributing to the growing complexity and maintenance demands of larger software systems. In mobile apps, an excess of functionality can significantly impact usability, maintainability, and resource consumption, necessitating a nuanced understanding of the applicability of the law of continuous growth to mobile apps. Previous work showed that the deletion of functionality is common and sometimes driven by user reviews. For most users, the removal of features is associated with negative sentiments, prompts changes in usage patterns, and may even result in user churn. Motivated by these preliminary results, we propose Radiation to input user reviews and recommend if any functionality should be deleted from an app’s User Interface (UI). We evaluate Radiation using historical data and surveying developers’ opinions. From the analysis of 190,062 reviews from 115 randomly selected apps, we show that Radiation can recommend functionality deletion with an average F-Score of 74% and if sufficiently many negative user reviews suggest so. We conducted a survey involving 141 software developers to gain insights into the decision-making process and the level of planning for feature deletions. Our findings indicate that 77.3% of the participants often or always plan for such deletions. This underscores the importance of incorporating feature deletion planning into the overall release decision-making process.

Various semi-formal syntax templates for natural language requirements foster to reduce ambiguity while preserving human readability. Existing studies on their effectiveness focus on individual notations only and do not allow to systematically investigate quality benefits. We strive for a comparative benchmark and evaluation of template systems to assist practitioners in selecting appropriate ones and enable researchers to work on pinpoint improvements and domain-specific adaptions. We conduct comparative experiments with five popular template systems—EARS, Adv-EARS, Boilerplates, MASTeR, and SPIDER. First, we compare a control group of free-text requirements and treatment groups of their variants following the different templates. Second, we compare MASTeR and EARS in user experiments for reading and writing. Third, we analyse all five meta-models’ formality and ontological expressiveness based on the Bunge-Wand-Weber reference ontology. The comparison of the requirement phrasings across seven relevant quality characteristics and a dataset of 1764 requirements indicates that, except SPIDER, all template systems have positive effects on all characteristics. In a user experiment with 43 participants, mostly students, we learned that templates are a method that requires substantial prior training and that profound domain knowledge and experience is necessary to understand and write requirements in general. The evaluation of templates systems’ meta-models suggests different levels of formality, modularity, and expressiveness. MASTeR and Boilerplates provide high numbers of variants to express requirements and achieve the best results with respect to completeness. Templates can generally improve various quality factors compared to free text. Although MASTeR leads the field, there is no conclusive favourite choice, as most effect sizes are relatively similar.

Organisations are becoming concerned with effectively dealing with privacy-related requirements. Existing Requirements Engineering methods based on structured natural language suffer from several limitations both in eliciting and specifying privacy requirements. In our previous study, we proposed a structured natural-language approach called the “Privacy Criteria Method” (PCM), which demonstrates potential advantages over user stories. Our goal is to present a PCM evaluation that focused on the opinions of software practitioners from different companies on PCM’s ability to support the specification of privacy requirements and the quality of the privacy requirements specifications produced by these software practitioners. We conducted a multiple case study to evaluate PCM in four different industrial contexts. We gathered and analysed the opinions of 21 practitioners on PCM usage regarding Coverage, Applicability, Usefulness, and Scalability. Moreover, we assessed the syntactic and semantic quality of the PCM artifacts produced by these practitioners. PCM can aid developers in elaborating requirements specifications focused on privacy with good quality. The practitioners found PCM to be useful for their companies’ development processes. PCM is considered a promising method for specifying privacy requirements. Some slight extensions of PCM may be required to tailor the method to the characteristics of the company.

The present landscape of adverse drug reactions (ADRs) cases paints a somber picture, with statistics indicating that a substantial proportion of hospital admissions result from patients experiencing drug side effects. The existing solutions for preventing and monitoring ADRs, however, seem to operate in isolation. Addressing these gaps calls for the creation of a fully integrated platform for preventing and monitoring ADRs. Central to the success of such a platform is understanding user needs. This research focused on identifying functional needs for physicians and patients, along with non-functional requirements from hospital information system providers. This study employs a user-centered design methodology structured around a series of key steps that collectively guide the process of user needs and requirement identification and analysis. For an overarching view of the functional requirements, questionnaires were utilized to engage both physicians and patients. For gathering non-functional requirements interviews were conducted with Hospital Information System Providers. 37 physicians and 40 patients participated in the survey. Physicians favored Drug Information Checker, Drug-to-Drug Interaction Checker, Patient ADR Report history-based drug checker, and other general features. Patients prioritized ADR Reporting, Medication Reminders, and mobile platform accessibility. Additionally, two hospital system experts highlighted non-functional prerequisites, including interoperability, security, usability, availability, and performance. This study focus encompassed three pivotal actors: physicians, patients, and hospital information system providers. Physicians and patients lent insights into functional requirements that mirror their clinical and personal journeys, respectively. Meanwhile, the contributions of hospital information system providers illuminated the non-functional aspects imperative for a seamlessly integrated platform.

Data protection compliance is critical from a requirements engineering (RE) perspective, both from a software development lifecycle (SDLC) perspective and regulatory compliance. Not including these requirements from the early phases of the SDLC can prove costly and challenging afterward. The general data protection regulation (GDPR) from the European Union (EU) sets a list of requirements that organizations working within its scope should satisfy. However, these requirements are complex to work with, as legal prose tends to be vague and imprecise, and not all requirements have received the same attention from researchers. This study aims to identify the research published in RE for helping compliance with regulatory data protection requirements. We gathered and analyzed 90 articles from 2016 to 2022 through a systematic mapping study. We analyzed key trends in the sample, such as year of publication, publication venue, type of research, interdisciplinarity in the author’s background, GDPR focus of compliance element, and type of proposal. Our main findings show ongoing interest, mostly published in conferences, in achieving overall compliance with the GDPR and consent as the most popular topics. Other topics, such as cookies or children’s data, did not receive significant attention. Research over the whole RE process has been done. 20 (22%) of the papers have authors affiliated with non-computer science; however, most research seems not interdisciplinary. We finally discuss gaps in the literature, possible future areas of research, and the importance of interdisciplinary research for regulatory data protection requirements in RE.

The benefits of traceability have widely been discussed in research. However, studies have also shown that traceability practices are still not prevalent in industrial settings due to the high manual effort and lack of tool support. In this paper, we explore the feasibility of using eye tracking to automatically detect trace links to reduce manual effort and thereby increase practical applicability. We conducted a two-stage interview study in industry. In Stage 1 we interviewed 20 practitioners to provide an overview of how traceability is established in practice and how an eye tracking approach would need to be applied in order to be useful. In Stage 2 we conducted interviews with 16 practitioners from one project context to elicit role-specific workflows and analyzed which activities are suitable to obtain useful traceability links based on gaze data. As there is no one-fits-all solution to traceability, and technical limitations of eye tracking still exist, we collected information on used artifact types, tools and requirements management practices to adjust an approach to actual traceability stakeholders’ needs. We report on perspectives from different roles in software projects and give an overview of traced artifacts, current traceability experiences, as well as benefits and doubts concerned with using eye tracking to obtain links automatically. We discuss the implications for the evaluation and implementation of an automatic tracing approach in practice and how eye tracking can support requirements engineering activities.

Recent approaches have investigated assisting users in making early trade-off decisions when the future evolution of project elements is uncertain. These approaches have demonstrated promise in their analytical capabilities; yet, stakeholders have expressed concerns about the readability of the models and resulting analysis, which builds upon Tropos. Tropos is based on formal semantics enabling automated analysis; however, this creates a problem of interpreting evidence pairs. The aim of our broader research project is to improve the process of model comprehension and decision-making by improving how analysts interpret and make decisions. We extend and evaluate a prior approach, called EVO, which uses color to visualize evidence pairs. In this article, we explore the effectiveness of EVO with and without the impacts of tooling through a two-phased empirical study. All subjects in both phases were untrained modelers, given training at study time. First, we conduct an experiment to measure any effect of using colors to represent evidence pairs. Second, we explore how subjects engage in decision-making activities (with or without color) through a user study. We find that the EVO color visualization significantly improves the speed of model comprehension and is perceived as helpful by study subjects.

Requirements Technical Debt (RTD) applies the Technical Debt (TD) metaphor to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we developed a conceptual model, the Requirements Technical Debt Quantification Model (RTDQM). Our work is grounded in the literature found via a systematic mapping study and informed by prior work modeling the quantification of software code-related TD types. The key finding is that although RTD is similar to code-related TD in many aspects, it also has its own components. RTD can be incurred regardless of the presence of code-related TD. Unlike code-related TD, RTD has a feedback loop involving the user. RTD can have a cascading impact on other development activities, such as design and implementation, apart from the extra costs and efforts incurred during requirements engineering activities; this is modeled by the RTD Interest constituents in our model. The model was used to compare and analyze existing quantification approaches. It helped identify what RTD quantification concepts are discussed in the existing approaches and what concepts are supported by metrics for their quantification. The model serves as a reference for practitioners to select existing or to develop new quantification approaches to support informed decision-making for RTD management.

Software systems and product lines often use configurable features to specify a portfolio of product variants from a common core. Typically, their requirements also include constraints on which combinations of features are valid. Especially for larger systems and systems where the specifications are scattered among documents, the analysis of a new product’s variability-related requirements is challenging. To address this, we introduce a scalable, tool-supported framework that uses a variability model to automate checks for missing and inconsistent features and constraints. Our approach also extends and scales traditional variability requirements engineering by incorporating combinatorial interaction testing techniques to build valid product variants covering all configurations in the variability model and to automatically discover faulty feature settings in failed builds. Results from evaluation on two configurable systems show that our framework is effective both at early detection of missing, incorrect, and inconsistent variability requirements and at later finding faulty feature configurations.