Search

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

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. [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]

Requirements engineering remains a discipline that is faced with a large number of challenges, including the implementation of a requirements elicitation process in industry. Although several proposals have been suggested by researchers and academics, little is known of the practices that are actually followed in industry. Our objective is to investigate the state-of-practice with respect to requirements elicitation, by closely examining practitioners' current practices. To this aim, we focus on the techniques that are used in industry, the roles that requirements elicitation involves, and the challenges that the requirements elicitation process is faced with. As method, we conducted an interview-based survey study involving 24 practitioners from 12 different Swedish IT companies, and we recorded the interviews and analyzed these recordings by using quantitative and qualitative methods. Several results emerged from the studies. Group interaction techniques, including meetings and workshops, are the most popular type of elicitation techniques that are employed by the practitioners, except in the case of small projects. Additionally, practitioners tend to use a variety of elicitation techniques in each project. We noted that customers are frequently involved in the elicitation process, except in the case of market-driven organizations. Technical staff (for example, developers and architects) are more frequently involved in the elicitation process compared to the involvement of business or strategic staff. Finally, we identified a number of challenges with respect to stakeholders. These challenges include difficulties in understanding and prioritizing their needs. Further, it was noted that requirements instability (i.e., caused by changing needs or priorities) was a predominant challenge. These observations need to be interpreted in the context of the study. We conclude that the relevant observations regarding the survey participants' experiences should be of interest to the industry; experiences that should be analyzed in the practitioners' context. Researchers may find evidence for the use of academic results in practice, thereby inspiring future theoretical work, as well as further empirical studies in the same area. [ABSTRACT FROM AUTHOR]

Modern software development relies on a combination of development and re-use of technical asset, e.g., software components, libraries, and APIs. In the past, re-use was mostly conducted with internal assets but today external; open source, customer off-the-shelf (COTS), and assets developed through outsourcing are also common. This access to more asset alternatives presents new challenges regarding what assets to optimally chose and how to make this decision. To support decision-makers, decision theory has been used to develop decision models for asset selection. However, very little industrial data has been presented in literature about the usefulness, or even perceived usefulness, of these models. Additionally, only limited information has been presented about what model characteristics determine practitioner preference toward one model over another. The objective of this work is to evaluate what characteristics of decision models for asset selection determine industrial practitioner preference of a model when given the choice of a decision model of high precision or a model with high speed. An industrial questionnaire survey is performed where a total of 33 practitioners, of varying roles, from 18 companies are tasked to compare two decision models for asset selection. Textual analysis and formal and descriptive statistics are then applied on the survey responses to answer the study's research questions. The study shows that the practitioners had clear preference toward the decision model that emphasized speed over the one that emphasized decision precision. This conclusion was determined to be because one of the models was perceived faster, had lower complexity, was more flexible in use for different decisions, and was more agile on how it could be used in operation, its emphasis on people, its emphasis on "good enough" precision and ability to fail fast if a decision was a failure. Hence, we found seven characteristics that the practitioners considered important for their acceptance of the model. Industrial practitioner preference, which relates to acceptance, of decision models for asset selection is dependent on multiple characteristics that must be considered when developing a model for different types of decisions such as operational day-to-day decisions as well as more critical tactical or strategic decisions. The main contribution of this work are the seven identified characteristics that can serve as industrial requirements for future research on decision models for asset selection. [ABSTRACT FROM AUTHOR]

Component-based software engineering is a common approach in the development and evolution of contemporary software systems. Different component sourcing options are available, such as: (1) Software developed internally (in-house), (2) Software developed outsourced, (3) Commercial off-the-shelf software, and (4) Open-Source Software. However, there is little available research on what attributes of a component are the most important ones when selecting new components. The objective of this study is to investigate what matters the most to industry practitioners when they decide to select a component. We conducted a cross-domain anonymous survey with industry practitioners involved in component selection. First, the practitioners selected the most important attributes from a list. Next, they prioritized their selection using the Hundred-Dollar ($100) test. We analyzed the results using compositional data analysis. The results of this exploratory analysis showed that cost was clearly considered to be the most important attribute for component selection. Other important attributes for the practitioners were: support of the component, longevity prediction, and level of off-the-shelf fit to product. Moreover, several practitioners still consider in-house software development to be the sole option when adding or replacing a component. On the other hand, there is a trend to complement it with other component sourcing options and, apart from cost, different attributes factor into their decision. Furthermore, in our analysis, nonparametric tests and biplots were used to further investigate the practitioners' inherent characteristics. It seems that smaller and larger organizations have different views on what attributes are the most important, and the most surprising finding is their contrasting views on the cost attribute: larger organizations with mature products are considerably more cost aware. [ABSTRACT FROM AUTHOR]

Context: Start-up companies have become an important supplier of innovation and software-intensive products. The flexibility and reactiveness of start-ups enables fast development and launch of innovative products. However, a majority of software start-up companies fail before achieving any success. Among other factors, poor software engineering could be a significant contributor to the challenges experienced by start-ups. However, the state-of-practice of software engineering in start-ups, as well as the utilization of state-of-the-art is largely an unexplored area.Objective: In this study we investigate how software engineering is applied in start-up context with a focus to identify key knowledge areas and opportunities for further research.Method: We perform a multi-vocal exploratory study of 88 start-up experience reports. We develop a custom taxonomy to categorize the reported software engineering practices and their interrelation with business aspects, and apply qualitative data analysis to explore influences and dependencies between the knowledge areas.Results: We identify the most frequently reported software engineering (requirements engineering, software design and quality) and business aspect (vision and strategy development) knowledge areas, and illustrate their relationships. We also present a summary of how relevant software engineering knowledge areas are implemented in start-ups and identify potentially useful practices for adoption in start-ups.Conclusions: The results enable a more focused research on engineering practices in start-ups. We conclude that most engineering challenges in start-ups stem from inadequacies in requirements engineering. Many promising practices to address specific engineering challenges exists, however more research on adaptation of established practices, and validation of new start-up specific practices is needed. [ABSTRACT FROM AUTHOR]

Software Engineering activities are information intensive. Research proposes Information Retrieval (IR) techniques to support engineers in their daily tasks, such as establishing and maintaining traceability links, fault identification, and software maintenance. We describe an engineering task, test case selection, and illustrate our problem analysis and solution discovery process. The objective of the study is to gain an understanding of to what extent IR techniques (one potential solution) can be applied to test case selection and provide decision support in a large-scale, industrial setting. We analyze, in the context of the studied company, how test case selection is performed and design a series of experiments evaluating the performance of different IR techniques. Each experiment provides lessons learned from implementation, execution, and results, feeding to its successor. The three experiments led to the following observations: 1) there is a lack of research on scalable parameter optimization of IR techniques for software engineering problems; 2) scaling IR techniques to industry data is challenging, in particular for latent semantic analysis; 3) the IR context poses constraints on the empirical evaluation of IR techniques, requiring more research on developing valid statistical approaches. We believe that our experiences in conducting a series of IR experiments with industry grade data are valuable for peer researchers so that they can avoid the pitfalls that we have encountered. Furthermore, we identified challenges that need to be addressed in order to bridge the gap between laboratory IR experiments and real applications of IR in the industry. [ABSTRACT FROM AUTHOR]

It has been shown that potential business benefits could be achieved by assessing and improving the requirements engineering (RE) process. However, process assessment models such as CMMI and ISO9000 only cover RE shallowly. Tailored models such as REGPG and REPM, on the other hand, do not cover market-driven requirements engineering. Other attempts such as MDREPM covers market-driven requirements engineering, but correspondingly neglects bespoke requirements engineering. Moreover, the area itself has evolved so practices that once were cutting edge are now commonplace. In this article, we develop and evaluate a unified requirements engineering process maturity model (Uni-REPM) that can be used in a market-driven as well as a bespoke context. This model is based on REPM, but has evolved to reflect contemporary requirements engineering practices. Uni-REPM is primarily created based on a systematic literature review of market-driven requirements engineering practices and a literature review of bespoke practices. Based on the results, Uni-REPM is formulated. The objective of Uni-REPM is twofold. Firstly, it is expected to be applicable for assessing the maturity of RE processes in various scenarios where an organisation would use different development approaches. Secondly, it instructs practitioners about which RE practices to perform and their expected benefits. As an assessment instrument, Uni-REPM provides a simple and low-cost solution for practitioners to identify the status of their RE process. As a guidance tool, Uni-REPM lessens the gap between theoretical and practical worlds by transferring the available RE technologies from research to industry practice. [ABSTRACT FROM AUTHOR]

Weak alignment of requirements engineering (RE) with verification and validation (VV) may lead to problems in delivering the required products in time with the right quality. For example, weak communication of requirements changes to testers may result in lack of verification of new requirements and incorrect verification of old invalid requirements, leading to software quality problems, wasted effort and delays. However, despite the serious implications of weak alignment research and practice both tend to focus on one or the other of RE or VV rather than on the alignment of the two. We have performed a multi-unit case study to gain insight into issues around aligning RE and VV by interviewing 30 practitioners from 6 software developing companies, involving 10 researchers in a flexible research process for case studies. The results describe current industry challenges and practices in aligning RE with VV, ranging from quality of the individual RE and VV activities, through tracing and tools, to change control and sharing a common understanding at strategy, goal and design level. The study identified that human aspects are central, i.e. cooperation and communication, and that requirements engineering practices are a critical basis for alignment. Further, the size of an organisation and its motivation for applying alignment practices, e.g. external enforcement of traceability, are variation factors that play a key role in achieving alignment. Our results provide a strategic roadmap for practitioners improvement work to address alignment challenges. Furthermore, the study provides a foundation for continued research to improve the alignment of RE with VV. [ABSTRACT FROM AUTHOR]

A large percentage of the cost of rework can be avoided by finding more faults earlier in a software test process. Therefore, determination of which software test phases to focus improvement work on has considerable industrial interest. We evaluate a number of prediction techniques for predicting the number of faults slipping through to unit, function, integration, and system test phases of a large industrial project. The objective is to quantify improvement potential in different test phases by striving toward finding the faults in the right phase. The results show that a range of techniques are found to be useful in predicting the number of faults slipping through to the four test phases; however, the group of search-based techniques (genetic programming, gene expression programming, artificial immune recognition system, and particle swarm optimization-based artificial neural network) consistently give better predictions, having a representation at all of the test phases. Human predictions are consistently better at two of the four test phases. We conclude that the human predictions regarding the number of faults slipping through to various test phases can be well supported by the use of search-based techniques. A combination of human and an automated search mechanism (such as any of the search-based techniques) has the potential to provide improved prediction results. [ABSTRACT FROM AUTHOR]

Software products are usually developed for either a specific customer (bespoke) or a broader market (market-driven). Due to their characteristic, bespoke and market-driven development face different challenges, especially concerning requirements engineering. Many challenges are caused by an inadequate requirements engineering process, and hence there is a need for process improvement frameworks based on empirical research and industry needs. In a previous article we introduced Uni-REPM, a lightweight requirements engineering process assessment framework based on a review of empirically motivated practices in market-driven and bespoke requirements engineering literature. In this article, we validate this framework in academia as well as industry, in order to prepare Uni-REPM for widespread industry use. We conduct two validations; a static validation based on interviews with seven academic experts and a dynamic validation where Uni-REPM is applied in four industrial organisations. Uni-REPM is refined according to the feedback obtained in the validations. The study shows that Uni-REPM is a quick, simple, and cost-effective solution to assess the maturity level of the requirements engineering process of projects. Moreover, the assessment method using checklists is highly usable and applicable in various international development environments. [ABSTRACT FROM AUTHOR]

One of the main goals of an applied research field such as software engineering is the transfer and widespread use of research results in industry. To impact industry, researchers developing technologies in academia need to provide tangible evidence of the advantages of using them. This can be done trough step-wise validation, enabling researchers to gradually test and evaluate technologies to finally try them in real settings with real users and applications. The evidence obtained, together with detailed information on how the validation was conducted, offers rich decision support material for industry practitioners seeking to adopt new technologies and researchers looking for an empirical basis on which to build new or refined technologies. This paper presents model for evaluating the rigor and industrial relevance of technology evaluations in software engineering. The model is applied and validated in a comprehensive systematic literature review of evaluations of requirements engineering technologies published in software engineering journals. The aim is to show the applicability of the model and to characterize how evaluations are carried out and reported to evaluate the state-of-research. The review shows that the model can be applied to characterize evaluations in requirements engineering. The findings from applying the model also show that the majority of technology evaluations in requirements engineering lack both industrial relevance and rigor. In addition, the research field does not show any improvements in terms of industrial relevance over time. [ABSTRACT FROM AUTHOR]

One of the main goals of an applied research field such as requirements engineering is the transfer of research results to industrial use. To promote industrial adoption of technologies developed in academia, researchers need to provide tangible evidence of the advantages of using them. This can be done through industry validation, enabling researchers to test and validate technologies in a real setting with real users and applications. The evidence obtained, together with detailed information on how the validation was conducted, offers rich decision support material for industrial practitioners seeking to adopt new technologies. This paper presents a comprehensive systematic literature review of all papers published in the Requirements Engineering journal containing any type of technology evaluation. The aim is to gauge the support for technology transfer, i.e., to what degree industrial practitioners can use the reporting of technology evaluations in the journal as decision support for adopting the technologies in industrial practice. Findings show that very few evaluations offer full technology transfer support, i.e., have a realistic scale, application or subjects. The major improvement potential concerning support for technology transfer is found to be the subjects used in the evaluations. Attaining company support, including support for using practitioners as subjects, is vital for technology transfer and for researchers seeking to validate technologies. [ABSTRACT FROM AUTHOR]

Software requirements are often formulated on different levels and hence they are difficult to compare to each other. To address this issue, a model that allows for placing requirements on different levels has been developed. The model supports both abstraction and refinement of requirements, and hence requirements can both be compared with each other and to product strategies. Comparison between requirements will allow for prioritization of requirements, which in many cases is impossible if the requirements are described on different abstraction levels. Comparison to product strategies will enable early and systematic acceptance or dismissal of requirements, minimizing the risk for overloading. This paper presents an industrial evaluation of the model. It has been evaluated in two different companies, and the experiences and findings are presented. It is concluded that the requirements abstraction model provides helpful improvements to the industrial requirements engineering process. [ABSTRACT FROM AUTHOR]

Software requirements arrive in different shapes and forms to development organizations. This is particularly the case in market-driven requirements engineering, where the requirements are on products rather than directed towards projects. This results in challenges related to making different requirements comparable. In particular, this situation was identified in a collaborative effort between academia and industry. A model, with four abstraction levels, was developed as a response to the industrial need. The model allows for placement of requirements on different levels and supports abstraction or break down of requirements to make them comparable to each other. The model was successfully validated in several steps at a company. The results from the industrial validation point to the usefulness of the model. The model will allow companies to ensure comparability between requirements, and hence it generates important input to activities such as prioritization and packaging of requirements before launching a development project. [ABSTRACT FROM AUTHOR]