Search

Various approaches toward the development of sustainable software systems have been proposed by the requirements engineering community over the last decade. We conducted a systematic mapping study, analyzed 55 publications, and identified 29 approaches that have been published since the year 2000. We analyzed how the approaches evolved over time and how the publications and authors are influenced by each other. Furthermore, the approaches are analyzed in terms of their supported requirements engineering activities, along with the evidence provided in the publications. Additionally, we also analyzed which sustainability definitions have been used, if an iterative application of the approaches is discussed, and if the approaches also provide a tool-support for practitioners. We noticed an increase of publications on requirements engineering approaches toward sustainability in the last years, whereas a majority discuss sustainability based on the same multi-dimensional concept. Although different case studies have been already conducted, we noticed a lack of an industrial application. Our main findings concern the need of an evaluation on how the proposed requirements engineering approaches can also be applied in agile software development processes. Additionally, we also promote the development of supporting software tools to support practitioners in adapting the proposed approaches. [ABSTRACT FROM AUTHOR]

Attention is currently being focused on DevOps, which aims to reduce software development time by means of close collaboration between the development and operations areas. However, little effort has been made to determine the role of requirements management in DevOps. The objective of this study is to help both researchers and practitioners by providing an overview of the best practices regarding requirements engineering in DevOps and identifying which areas still need to be investigated. A multivocal mapping study has, therefore, been carried out in order to study which methodologies, techniques and tools are used to support requirements management in DevOps environments. After applying the review protocol, 37 papers from formal literature and 14 references from grey literature were selected for analysis. The general conclusions obtained after analysing these papers were that, within DevOps, more attention should be paid to: (1) the reuse of requirements in order to identify systems and software artefacts that can serve as a basis for the specification of new projects; (2) the communication of requirements between the different areas of an organisation and the stakeholders of a project; (3) the traceability of requirements in order to identify the relationship with other requirements, artefacts, tasks and processes; (4) non-functional requirements in order to identify the requirements of the operations area in the early phases of a project; and finally (5) specific requirements tools that should be seamlessly integrated into the DevOps toolchain. All these issues must be considered without ignoring the agile and continuous practices of development, operations and business teams. More effort must also be made to validate new methodologies in industry so as to assess and determine their strengths and weaknesses. [ABSTRACT FROM AUTHOR]

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. [ABSTRACT FROM AUTHOR]

The Brazilian General Data Protection Law (LGPD) implementation has impacted activities carried out by the software development teams. Due to it, developers had to become aware of the existing techniques and tools to carry out privacy requirements elicitation. Extending our previous work, we have investigated the actions taken by organizations regarding the LGPD, specifically in software development, considering the perception of agile development teams after two years of the LGPD implementation. In addition, we also investigated the perception of an agile team regarding the practices, techniques, and tools previously cited by practitioners as potential solutions for use in this context, along with techniques already in use in the current context. We have conducted a systematic literature review (SLR) and selected 36 primary studies. Furthermore, we have conducted a survey with 53 IT practitioners and semi-structured interviews with ten practitioners. The LGPD principles are known by most agile teams and are being implemented by the organizations, although the existing tools to support privacy requirements elicitation are still underused by agile teams. Moreover, agile teams consider that software requirements and software construction are the most impacted areas of knowledge by the LGPD, and most of them use user stories in privacy requirements elicitation. Our findings reveal that agile teams and Brazilian organizations are more concerned with user data privacy issues after the LGPD became effective. However, agile teams still face challenges in privacy requirements elicitation. [ABSTRACT FROM AUTHOR]

A common way to describe requirements in Agile software development is through user stories, which are short descriptions of desired functionality. Nevertheless, there are no widely accepted quantitative metrics to evaluate user stories. We propose a novel metric to evaluate user stories called instability, which measures the number of changes made to a user story after it was assigned to a developer to be implemented in the near future. A user story with a high instability score suggests that it was not detailed and coherent enough to be implemented. The instability of a user story can be automatically extracted from industry-standard issue tracking systems such as Jira by performing retrospective analysis over user stories that were fully implemented. We propose a method for creating prediction models that can identify user stories that will have high instability even before they have been assigned to a developer. Our method works by applying a machine learning algorithm on implemented user stories, considering only features that are available before a user story is assigned to a developer. We evaluate our prediction models on several open-source projects and one commercial project and show that they outperform baseline prediction models. [ABSTRACT FROM AUTHOR]

Organizations have increasingly applied agile project management; however, they face challenges in scaling up this approach to large projects. Thus, this study investigates the key barriers and benefits of scaling agile methods to large projects. The research approach is a literature review, applying bibliometrics and content analysis with Bibliometrix and UCINET software. We conducted a sampling process in the Web of Science and Scopus databases and surveyed 76 articles in depth. The results identified 53 barriers clustered into six main categories: organizational issues, managerial issues, agile method-specific barriers, product/process issues, customer issues, and team issues. Thirty-two benefits were coded and clustered into three categories: business, project, and team. Requirement management appears as a core topic, impacting both barriers and benefits for scaling agile project management. We identified a strong relationship between the barriers and benefits. These results can be used to create questionnaires to explore these barriers and benefits in practice. [ABSTRACT FROM AUTHOR]

Software traceability, the ability to relate software development artifacts such as requirements, design models and code to each other, is an important aspect in software development. It yields a number of benefits such as facilitating impact analysis and tracking software changes. However, for companies to reap these benefits, a proper traceability strategy—a plan for how traceability should be managed—needs to be defined and implemented. Existing literature lacks concrete guidelines for practitioners to systematically define such a strategy. In this study, we address this gap by defining a Traceability Introduction Methodology (TracIMo), which is a methodology for systematically designing, implementing and evaluating software traceability in practice. We used design science research to design TracIMo and evaluated it in a case study with an agile development team of a company in the finance domain. Our results show that TracIMo is feasible as it allows incremental definition and evaluation of a traceability strategy that is aligned with the company's traceability goals and the existing development process. We also report practical challenges encountered when designing a traceability strategy such as defining the right level of granularity and the need for defining intermediate development artifacts. [ABSTRACT FROM AUTHOR]

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. [ABSTRACT FROM AUTHOR]

Traceability is crucial for many activities in software and systems engineering including monitoring the development progress, and proving compliance with standards. In practice, the use and maintenance of trace links are challenging as artifacts undergo constant change, and development takes place in distributed scenarios with multiple collaborating stakeholders. Although traceability management in general has been addressed in previous studies, there is a need for empirical insights into the collaborative aspects of traceability management and how it is situated in existing development contexts. The study reported in this paper aims to close this gap by investigating the relation of collaboration and traceability management, based on an understanding of characteristics of the development effort. In our multiple exploratory case study, we conducted semi-structured interviews with 24 individuals from 15 industrial projects. We explored which challenges arise, how traceability management can support collaboration, how collaboration relates to traceability management approaches, and what characteristics of the development effort influence traceability management and collaboration. We found that practitioners struggle with the following challenges: (1) collaboration across team and tool boundaries, (2) conveying the benefits of traceability, and (3) traceability maintenance. If these challenges are addressed, we found that traceability can facilitate communication and knowledge management in distributed contexts. Moreover, there exist multiple approaches to traceability management with diverse collaboration approaches, i.e., requirements-centered, developer-driven, and mixed approaches. While traceability can be leveraged in software development with both agile and plan-driven paradigms, a certain level of rigor is needed to realize its benefits and overcome challenges. To support practitioners, we provide principles of collaborative traceability management. The main contribution of this paper is empirical evidence of how culture, processes, and organization impact traceability management and collaboration, and principles to support practitioners with collaborative traceability management. We show that collaboration and traceability management have the potential to be mutually beneficial—when investing in one, also the other one is positively affected. [ABSTRACT FROM AUTHOR]

Automotive manufacturers have historically adopted rigid requirements engineering processes. This allowed them to meet safety-critical requirements when producing a highly complex and differentiated product out of the integration of thousands of physical and software components. Nowadays, few software-related domains are as rapidly changing as the automotive industry. In particular, the needs of improving development speed are increasingly pushing companies in this domain toward new ways of developing software. In this paper, we investigate how the goal to increase development speed impacts how requirements are managed in the automotive domain. We start from a manager perspective, which we then complement with a more general perspective. We used a qualitative multiple-case study, organized in two steps. In the first step, we had 20 semi-structured interviews, at two automotive manufacturers. Our sampling strategy focuses on manager roles, complemented with technical specialists. In the second step, we validated our results with 12 more interviews, covering nine additional respondents and three recurring from the first step. In addition to validating our qualitative model, the second step of interviews broadens our perspective with technical experts and change managers. Our respondents indicate and rank six aspects of the current requirements engineering approach that impact development speed. These aspects include the negative impact of a requirements style dominated by safety concerns as well as decomposition of requirements over many levels of abstraction. Furthermore, the use of requirements as part of legal contracts with suppliers is seen as hindering fast collaboration. Six additional suggestions for potential improvements include domain-specific tooling, model-based requirements, test automation, and a combination of lightweight upfront requirements engineering preceding development with precise specifications post-development. Out of these 12 aspects, seven can likely be addressed as part of an ongoing agile transformation. We offer an empirical account of expectations and needs for new requirements engineering approaches in the automotive domain, necessary to coordinate hundreds of collaborating organizations developing software-intensive and potentially safety-critical systems. [ABSTRACT FROM AUTHOR]

In agile software development projects, software engineers prioritize implementation over documentation. Is the cost of missing documentation greater than the cost of producing unnecessary or unused documentation? Agile software engineers must still maintain other software artifacts, such as tickets in an issue tracking system or source code committed to a version control system (VCS). Do these artifacts contain useful knowledge? In this paper, we examine undocumented knowledge in a multi-case exploratory case study of industrial agile software development projects. The first is an internal project with 159 source code commits and roughly 8000 lines of code. The second is an external project with 760 source code commits and roughly 50,000 lines of code. We introduce a ticket-commit network chart (TCC) that visually represents time-series commit activities along with filed issue tickets. We also implement a tool to generate the TCC using both commit log and ticket data. Our case study revealed that software engineers committed source code to the VCS without a corresponding issue ticket in a non-trivial minority of instances. If these commits were based on and linked to individual issue tickets, then these “unissued” tickets would have accounted for a non-trivial minority (5-21%) of the knowledge needed for future software modification and operations. End users and requirements engineers also evaluated the contents of these commits. They found that the omission of links to individual tickets had an important impact on future software modification or operation with between 22 and 49% of these instances resulting in undocumented knowledge. [ABSTRACT FROM AUTHOR]

Extracting conceptual models from natural language requirements can help identify dependencies, redundancies, and conflicts between requirements via a holistic and easy-to-understand view that is generated from lengthy textual specifications. Unfortunately, existing approaches never gained traction in practice, because they either require substantial human involvement or they deliver too low accuracy. In this paper, we propose an automated approach called Visual Narrator based on natural language processing that extracts conceptual models from user story requirements. We choose this notation because of its popularity among (agile) practitioners and its focus on the essential components of a requirement: Who? What? Why? Coupled with a careful selection and tuning of heuristics, we show how Visual Narrator enables generating conceptual models from user stories with high accuracy. Visual Narrator is part of the holistic Grimm method for user story collaboration that ranges from elicitation to the interactive visualization and analysis of requirements. [ABSTRACT FROM AUTHOR]

Requirements communication plays a vital role in development projects in coordinating the customers, the business roles and the software engineers. Communication gaps represent a significant source of project failures and overruns. For example, misunderstood or uncommunicated requirements can lead to software that does not meet the customers' requirements, and subsequent low number of sales or additional cost required to redo the implementation. We propose that requirements engineering (RE) distance measures are useful for locating gaps in requirements communication and for improving on development practice. In this paper, we present a case study of one software development project to evaluate this proposition. Thirteen RE distances were measured including geographical and cognitive distances between project members, and semantic distances between requirements and testing artefacts. The findings confirm that RE distances impact requirements communication and project coordination. Furthermore, the concept of distances was found to enable constructive group reflection on communication gaps and improvements to development practices. The insights reported in this paper can provide practitioners with an increased awareness of distances and their impact. Furthermore, the results provide a stepping stone for further research into RE distances and methods for improving on software development processes and practices. [ABSTRACT FROM AUTHOR]

User stories are a widely adopted requirements notation in agile development. Yet, user stories are too often poorly written in practice and exhibit inherent quality defects. Triggered by this observation, we propose the Quality User Story (QUS) framework, a set of 13 quality criteria that user story writers should strive to conform to. Based on QUS, we present the Automatic Quality User Story Artisan (AQUSA) software tool. Relying on natural language processing (NLP) techniques, AQUSA detects quality defects and suggest possible remedies. We describe the architecture of AQUSA, its implementation, and we report on an evaluation that analyzes 1023 user stories obtained from 18 software companies. Our tool does not yet reach the ambitious 100 % recall that Daniel Berry and colleagues require NLP tools for RE to achieve. However, we obtain promising results and we identify some improvements that will substantially improve recall and precision. [ABSTRACT FROM AUTHOR]

Agile software development methodologies are increasingly adopted by organizations because they focus on the client's needs, thus safeguarding business value for the final product. At the same time, as the economy and society move toward globalization, more organizations shift to distributed development of software projects. From this perspective, while adopting agile techniques seems beneficial, there are still a number of challenges that need to be addressed; among these notable is the effective cooperation between the stakeholders and the geographically distributed development team. In addition, data collection and validation for requirements engineering demands efficient processing techniques in order to handle the volume of data as well as to manage different inconsistencies, when the data are collected using online tools. In this paper, we present 'PBURC,' a patterns-based, unsupervised requirements clustering framework, which makes use of machine-learning methods for requirements validation, being able to overcome data inconsistencies and effectively determine appropriate requirements clusters for optimal definition of software development sprints. [ABSTRACT FROM AUTHOR]

gile development processes are adaptive rather than predictive. Therefore, agile processes emphasize operational system code rather than its documentation. To overcome the absence of comprehensive documentation artifacts, agile methods require constant interaction between the system stakeholders. Ironically, however, some traditional documentation artifacts come to support this kind of interaction. In this study, we examine the relationship between software and documentation. We develop an approach that enables incorporating domain documentation to agile development, while keeping the processes adaptive. We also provide a system design that actively uses domain knowledge documentation. These ideas have been applied through the implementation and use of agile documentation support components. [ABSTRACT FROM AUTHOR]

gile development processes are adaptive rather than predictive. Therefore, agile processes emphasize operational system code rather than its documentation. To overcome the absence of comprehensive documentation artifacts, agile methods require constant interaction between the system stakeholders. Ironically, however, some traditional documentation artifacts come to support this kind of interaction. In this study, we examine the relationship between software and documentation. We develop an approach that enables incorporating domain documentation to agile development, while keeping the processes adaptive. We also provide a system design that actively uses domain knowledge documentation. These ideas have been applied through the implementation and use of agile documentation support components. [ABSTRACT FROM AUTHOR]

In agile development processes, the rewards from acceptance testing are maximized by using the practice to drive the development process. Traditionally, User Stories are used in agile projects to describe a system’s usage scenarios and are utilized as a basis for developing acceptance tests. This paper introduces a technique that aims to achieve the benefits of acceptance testing within large-scale development projects that deploy a V-model development process, specifically those that utilize use case models. The approach is based on utilizing a number of artifacts: use case models supported by robustness diagrams and domain models. The feasibility of the proposed approach is demonstrated by applying it to a real-world system—the RestoMapper system. The results show that a comprehensive set of acceptance tests can be developed based upon use case models. [ABSTRACT FROM AUTHOR]

An introduction is presented in which the editor discusses articles in the issue which are extended versions of the best papers from the magazine's 2017 conference, on topics including agile software, user requirements quality, and user rationale in software engineering.