Explore the vast range of titles available.

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.

Requirements specification is a core activity in the requirements engineering phase of a software development project. Researchers have contributed extensively to the field of requirements specification, but the extent to which their proposals have been adopted in practice remains unclear. We gathered evidence about the state of practice in requirements specification by focussing on the artefacts used in this activity, the application of templates or guidelines, how requirements are structured in the specification document, what tools practitioners use to specify requirements, and what challenges they face. We conducted an interview-based survey study involving 24 practitioners from 12 different Swedish IT companies. We recorded the interviews and analysed these recordings, primarily by using qualitative methods. Natural language constitutes the main specification artefact but is usually accompanied by some other type of instrument. Most requirements specifications use templates or guidelines, although they seldom follow any fixed standard. Requirements are always structured in the document according to the main functionalities of the system or to project areas or system parts. Different types of tools, including MS Office tools, are used, either individually or combined, in the compilation of requirements specifications. We also note that challenges related to the use of natural language (dealing with ambiguity, inconsistency, and incompleteness) are the most frequent challenges that practitioners face in the compilation of requirements specifications. These findings are contextualized in terms of demographic factors related to the individual interviewees, the organization they are affiliated with, and the project they selected to discuss during our interviews. A number of our findings have been previously reported in related studies. These findings show that, in spite of the large number of notations, models and tools proposed from academia for improving requirements specification, practitioners still mainly rely on plain natural language and general-purpose tool support. We expect more empirical studies in this area in order to better understand the reason of this low adoption of research results.

Although agile software development (ASD) has been adopted in the industry, requirements approaches for ASD still neglect non-functional requirements. Privacy has become a concern due to new user demands and data protection laws. Hence, privacy needs to be properly specified, but agile requirements engineering techniques do not explicitly represent privacy requirements and, therefore, are not able to proper analyze such requirements. In this context, Privacy Criteria Method (PCM), an approach to specify privacy in requirements activities, was proposed to produce more complete and detailed privacy requirements. By considering PCM a promising approach to be used in ASD and the importance of empirical evaluation of new methods, we have as objectives: 1 evaluate the ability of PCM to support systems analysts in specifying privacy requirements when used in conjunction with some agile specification methods; and 2 show our lessons learned in conducting empirical research based on an mix-method approach defined to empirically evaluate the suitability of a requirements specification in specifying privacy requirements. Mixed-method approach is a controlled experiment as a quantitative evaluation and a feasibility study (questionnaire and task analysis based) study as a qualitative and quantitative evaluation. The requirements specifications following PCM allow to represent privacy aspects, such as user’s personal data and the privacy mechanism that can be used to mitigate a privacy risk scenario. We also observed that some extra time is necessary to specify privacy requirements with PCM, but it does not imply a greater perceived effort. Specifications produced with PCM are of good quality and more privacy detailed. Additionally, we attest to the importance of conducting empirical research to evaluate new methods. PCM assists in specifying more complete and detailed in relation to traditional techniques used in ASD, which facilitates communication between the requirements analysts and developers.

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.

This study presents three structures for clearly expressing functional requirements (FRs) and quantitative non-functional requirements (qt-NFRs). Expressing requirements with these structures will allow the understanding of requirements by stakeholders and software developers. The first structure is the SURE format, which is composed of three main sections: a title, a short definition, and a detailed description. The second proposed structure is a template to facilitate the definition of the title and description of unambiguous FRs. It is based on the application of CRUD operations on a certain entity, calling it the “CRUDE” structure. Finally, the third structure serves as a template to make it easier to clearly define the description and title of qt-NFRs. It is based on the application of system properties to computer events or actions, calling it the “PROSE” structure. In this, it is very important to specify those metric values that are desired or expected by the stakeholder. To know how much the definition of FRs and qt-NFRs improved when the proposed structures were used, 46 requirement specification documents elaborated as homework by students of the “Requirement Engineering” course offered at the University of Guayaquil between 2020 and 2022 were evaluated by five experts with more than 10 years of experience in software development for Ecuadorian companies. The findings showed that students reduced the percentage of unambiguous FRs and qt-NFRs from over 80% to about 10%. In conclusion, the findings demonstrate how crucial the three structures proposed in this paper are to helping students develop the ability to clearly express requirements.

Defects in requirement specifications can have severe consequences during the software development life cycle. Some of them may result in poor product quality and/or time and budget overrun due to incorrect or missing quality characteristics, such as security. This characteristic requires special attention in web applications because they have become a target for manipulating sensible data. Several concerns make security difficult to deal with. For instance, security requirements are often misunderstood and improperly specified due to lack of security expertise and emphasis on security during early stages of software development. This often leads to unspecified or ill-defined security-related aspects. These concerns become even more challenging in agile contexts, where lightweight documentation is typically produced. To tackle this problem, we designed an approach for reviewing security-related aspects in agile requirements specifications of web applications. Our proposal considers user stories and security specifications as inputs and relates those user stories to security properties via natural language processing. Based on the related security properties, our approach identifies high-level security requirements from the Open Web Application Security Project (OWASP) to be verified and generates a reading technique to support reviewers in detecting defects. We evaluate our approach via three experimental trials conducted with 56 novice software engineers, measuring effectiveness, efficiency, usefulness and ease of use. We compare our approach against using: (1) the OWASP high-level security requirements and (2) a perspective-based approach as proposed in contemporary state of the art. The results strengthen our confidence that using our approach has a positive impact (with large effect size) on the performance of inspectors in terms of effectiveness and efficiency.

Reverse engineering Unified Modeling Language (UML) artifacts from Software Requirements Specification (SRS) and Software Design Description (SDD) documents remains difficult because requirement statements, use cases, scenario steps, and design representations are often created separately and drift semantically over time. This study develops a traceability-oriented pipeline for the IdVar4CL Unified Specification Document (USD) that combines rule-based text preprocessing with Siamese Bidirectional Long Short-Term Memory (BiLSTM) pair classification. The pipeline performs tokenization, normalization, stopword removal, stemming, semantic pair construction, and binary classification across Functional Requirement–Use Case (FR–UC), Use Case–Step Performed (UC–SP), and Functional Requirement–Step Performed (FR–SP) artifact pairs. A case dataset consisting of 15 labeled IdVar4CL documents was expanded into 75 inter-document pairs through a one-to-many relationship scheme. Stratified five-fold validation yielded an average accuracy of 0.9733 ± 0.0435, precision of 0.9542 ± 0.0728, recall of 1.0000 ± 0.0000, F1-score of 0.9754 ± 0.0396, and ROC-AUC of 1.0000 ± 0.0000. The predicted links were then transformed into explicit FR→UC→SP paths, producing an updated USD with end-to-end traceability between requirements and behavioral descriptions. The case study shows that Siamese BiLSTM can support consistent artifact linkage in small but structured specification datasets. Remaining false positives indicate that stronger negative-pair sampling, semantic validation, and human review are still needed before wider deployment.

In recent years, the field of security requirements specification by formal methods has changed radically. The security requirement specification is now one of the widely recognized as well as actively pursued research challenges in both requirement engineering and security engineering communities. In this paper, we focus on the research metadata to find the state of the art in the field of security requirements specification using the formal approach. In order, a review was taken up to perform metadata, obtained from frequently used databases. In total, 200 publications were retrieved; out of which 110 were found to be relevant to our research questions. The results of metadata provided an insight into the main contributions of the field, research gaps, and challenges, which motivated the discussion for important research direction in the future.

When acquiring information systems, public entities face a dilemma. On the one hand, they want to procure the system that best suits their needs, which often requires lengthy dialogues with vendors. At the same time, they are restricted by government regulations that mandate limited dialogue in the interests of transparency and equal opportunities for all vendors. To examine how public entities deal with this, we followed three procurement projects in Norway. We show that this dilemma manifests itself as a dialectic between the thesis of getting the system requirements right and the antithesis of strictly adhering to regulations. Public entities search for a resolution of this dialectic through two syntheses: selecting an appropriate tendering procedure, and learning how to specify requirements through networks of peer public entities. Our findings reveal that the syntheses are possible because the dialectic is actually complimentary, both the thesis and the antithesis are needed to create the joint outcome that satisfies both. The resolution of the dialectic unfolds differently over time. Our study contributes to the relatively neglected stream of IS research on dialectics that explicitly searches for a synthesis while revealing the complementarity of the dialectic. We show how time plays a nuanced role in the resolution of the dialectic situation.

Requirements Engineering in the industry is expertise-driven, heavily manual, and centered around various types of requirement specification documents being prepared and maintained. These specification documents are in diverse formats and vary depending on whether it is a business requirement document, functional specification, interface specification, client specification, and so on. These diverse specification documents embed crucial product knowledge such as functional decomposition of the domain into features, feature hierarchy, feature types and their specific feature characteristics, dependencies, business context, etc. Moreover, in a product development scenario, thousands of pages of requirement specification documentation is created over the years. Comprehending functionality and its associated context from large volumes of specification documents is a highly complex task. To address this problem, we propose to digitalize the requirement specification documents into processable models. This paper discusses the salient aspects involved in the digitalization of requirements knowledge from diverse requirement specification documents. It proposes an AI engine for the automatic transformation of diverse text-based requirement specifications into machine-processable models using NLP techniques and the generation of context-sensitive user stories. The paper describes the key requirement abstractions and concepts essential in an industrial scenario, the conceptual meta-model, and DizReq engine (AI engine for digitalizing requirements) implementation for automatically transforming diverse requirement specifications into user stories embedding the business context. The evaluation results from digitalizing specifications of an IT product suite are discussed: mean feature extraction efficiency is 40 features/file, mean user story extraction efficiency is 71 user stories/file, feature extraction accuracy is 94%, and requirement extraction accuracy is 98%.