Field study on requirements engineering: Investigation of artefacts, project parameters, and execution strategies

Abstract

Context: Requirements Engineering (RE) is a critical discipline mostly driven by uncertainty, since it is influenced by the customer domain or by the development process model used. Volatile project environments restrict the choice of methods and the decision about which artefacts to produce in RE.Objective: We aim to investigate RE processes in successful project environments to discover characteristics and strategies that allow us to elaborate RE tailoring approaches in the future.Method: We perform a field study on a set of projects at one company. First, we investigate by content analysis which RE artefacts were produced in each project and to what extent they were produced. Second, we perform qualitative analysis of semi-structured interviews to discover project parameters that relate to the produced artefacts. Third, we use cluster analysis to infer artefact patterns and probable RE execution strategies, which are the responses to specific project parameters. Fourth, we investigate by statistical tests the effort spent in each strategy in relation to the effort spent in change requests to evaluate the efficiency of execution strategies.Results: We identified three artefact patterns and corresponding execution strategies. Each strategy covers different project parameters that impact the creation of certain artefacts. The effort analysis shows that the strategies have no significant differences in their effort and efficiency.Conclusions: In contrast to our initial assumption that an increased effort in requirements engineering lowers the probability of change requests or project failures in general, our results show no statistically significant difference between the efficiency of the strategies. In addition, it turned out that many parameters considered as the main causes for project failures can be successfully handled. Hence, practitioners can apply the artefact patterns and related project parameters to tailor the RE process according to individual project characteristics.

Towards Building Knowledge on Causes of Critical Requirements Engineering Problems

“…During these meetings, the online environment (EFS survey tool 3 ) was presented and some general guidelines for conducting the survey were provided. We decided to translate all instruments to Portuguese, the participants' native language.…”

“…RE constitutes a holistic key to successful development projects [2]. However, industry is still struggling to apply high-quality RE practices [3] and getting a further understanding on common RE problems and their causes is of great interest to both industry and academy. Therefore, many researchers have addressed identifying and analyzing RE problems faced by industry [4] [5].…”

Criteria for software process tailoring: a systematic review

“…We use a primary set of publications and manually search for secondary references that are based on the contributions' references sections to find further contributions. This first re- [52] Méndez Fernández et al [33] search step was implemented in the context of a cooperation project with the T-Systems International GmbH, the Telekom Laboratories (T-Labs), and the Technische Universität München 1 , and resulted in a set of standard contributions used for testing research questions, search strings, and structuring the publication flora. For this primary search, we refer to the authors and publications summarized in Table 1, which later on also serve as control values.…”

“…degree of innovation or complexity. The most frequently mentioned criterion is team size (eight mentions: [52,15,16,22,33,7,2,14]). …”

“…Those criteria consider a specific project situation from different perspectives, e.g., if the management does not support a project, it does not matter whether the management is available, whereas given management availability does not necessarily imply a (useful) support. Other criteria, e.g., client availability [24,23] and user availability [7,22,14] can represent-depending on the actual project setting-the same stakeholder focus group, and, furthermore, the criterion stakeholder availability [52,33] can be a means to generalize concrete stakeholder focus groups, e.g., the management, the client, the users.…”