Conference Paper

Preventing Incomplete/Hidden Requirements: Reflections on Survey Data from Austria and Brazil

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

[Context] Many software projects fail due to problems in requirements engineering (RE). [Goal] The goal of this paper is analyzing a specific and relevant RE problem in detail: incomplete/hidden requirements. [Method] We replicated a global family of RE surveys with representatives of software organizations in Austria and Brazil. We used the data to (a) characterize the criticality of the selected RE problem, and to (b) analyze the reported main causes and mitigation actions. Based on the analysis, we discuss how to prevent the problem. [Results] The survey includes 14 different organizations in Austria and 74 in Brazil, including small, medium and large sized companies, conducting both, plan-driven and agile development processes. Respondents from both countries cited the incomplete/hidden requirements problem as one of the most critical RE problems. We identified and graphically represented the main causes and documented solution options to address these causes. Further, we compiled a list of reported mitigation actions. [Conclusions] From a practical point of view, this paper provides further insights into common causes of incomplete/hidden requirements and on how to prevent this problem.

No full-text available

... Regarding the state-of-practice of elicitation techniques, the results of these surveys indicate that the most frequently used elicitation techniques are (1) interviews, (2) facilitated meetings including workshops, and (3) prototyping [45]. With respect to the challenges that RE is faced with, the NaPiRE surveys conducted in Austria and Brazil [15] reported that the most frequently mentioned challenges are (1) the existence of incomplete and/or hidden requirements; (2) moving targets (i.e., rapid changes in the requirements); (3) time boxing; (4) the difficulties faced by stakeholders in separating requirements from previous solutions; (5) requirements that are too abstract and allow for various interpretations; and (6) existence of communication flaws between project team and customer. ...
... We distinguished 3 broad categories of role in the context of a holistic perspective of each organization. This approach is adopted either because some subjects did not know all of the details of the elicitation process, especially Internal Strategic [8] Technical [15] Organization (not specified) [8] Developer / Development team / Scrum team [4] Analyst (Business analyst) [7] Customer Proxy (invented customer) [1] Market unit [4] Generic (Technicians/Technical team) [4] Technical/System manager [2] Consultant (internal) [3] Software architect [1] System / Lead engineers [2] Requirements-related [11] Project manager [1] Business team [1] Interaction designers [1] Web editors [1] Function owner [1] Product owner [1] Owner [2] External Customer (requester) [15] Third-party [3] End-user [4] Real [2] Citizen (potential user) [2] Service providers (carrier) [2] Customers of customers [1] Consultant (specialist) [2] Fig. 2 Roles that participate in requirements elicitation: A classification 4 Note that both interview subjects work for the same company, a public transport administration. in big companies (e.g., S7(D) who indicated that: "The business requirements are gathered from the customers by another part of the organization", or because no clear roles had been defined for conducting the elicitation process. ...
... We distinguished 3 broad categories of role in the context of a holistic perspective of each organization. This approach is adopted either because some subjects did not know all of the details of the elicitation process, especially Internal Strategic [8] Technical [15] Organization (not specified) [8] Developer / Development team / Scrum team [4] Analyst (Business analyst) [7] Customer Proxy (invented customer) [1] Market unit [4] Generic (Technicians/Technical team) [4] Technical/System manager [2] Consultant (internal) [3] Software architect [1] System / Lead engineers [2] Requirements-related [11] Project manager [1] Business team [1] Interaction designers [1] Web editors [1] Function owner [1] Product owner [1] Owner [2] External Customer (requester) [15] Third-party [3] End-user [4] Real [2] Citizen (potential user) [2] Service providers (carrier) [2] Customers of customers [1] Consultant (specialist) [2] Fig. 2 Roles that participate in requirements elicitation: A classification 4 Note that both interview subjects work for the same company, a public transport administration. in big companies (e.g., S7(D) who indicated that: "The business requirements are gathered from the customers by another part of the organization", or because no clear roles had been defined for conducting the elicitation process. ...
Preprint
Context. 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. Objective. We investigate the SoTA with respect to requirements elicitation, examining practitioners' practices. We focus on the techniques, the roles involved, and the challenges associated to the process. Method. We conducted an interview-based survey study involving 24 practitioners from 12 different Swedish IT companies. Results. We found that 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. 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. Conclusion. 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.
... Regarding the state-of-practice of elicitation techniques, the results of these surveys indicate that the most frequently used elicitation techniques are (1) interviews, (2) facilitated meetings including workshops, and (3) prototyping [45]. With respect to the challenges that RE is faced with, the NaPiRE surveys conducted in Austria and Brazil [15] reported that the most frequently mentioned challenges are (1) the existence of incomplete and/or hidden requirements; (2) moving targets (i.e., rapid changes in the requirements); (3) time boxing; (4) the difficulties faced by stakeholders in separating requirements from previous solutions; (5) requirements that are too abstract and allow for various interpretations; and (6) existence of communication flaws between project team and customer. ...
... We distinguished 3 broad categories of role in the context of a holistic perspective of each organization. This approach is adopted either because some subjects did not know all of the details of the elicitation process, especially Internal Strategic [8] Technical [15] Organization (not specified) [8] Developer / Development team / Scrum team [4] Analyst (Business analyst) [7] Customer Proxy (invented customer) [1] Market unit [4] Generic (Technicians/Technical team) [4] Technical/System manager [2] Consultant (internal) [3] Software architect [1] System / Lead engineers [2] Requirements-related [11] Project manager [1] Business team [1] Interaction designers [1] Web editors [1] Function owner [1] Product owner [1] Owner [2] External Customer (requester) [15] Third-party [3] End-user [4] Real [2] Citizen (potential user) [2] Service providers (carrier) [2] Customers of customers [1] Consultant (specialist) [2] Fig. 2 Roles that participate in requirements elicitation: A classification in big companies (e.g., S7(D) who indicated that: "The business requirements are gathered from the customers by another part of the organization", or because no clear roles had been defined for conducting the elicitation process. Consider, for example, S4(B)'s observation: "The workshops involve different people in the organization". ...
... We distinguished 3 broad categories of role in the context of a holistic perspective of each organization. This approach is adopted either because some subjects did not know all of the details of the elicitation process, especially Internal Strategic [8] Technical [15] Organization (not specified) [8] Developer / Development team / Scrum team [4] Analyst (Business analyst) [7] Customer Proxy (invented customer) [1] Market unit [4] Generic (Technicians/Technical team) [4] Technical/System manager [2] Consultant (internal) [3] Software architect [1] System / Lead engineers [2] Requirements-related [11] Project manager [1] Business team [1] Interaction designers [1] Web editors [1] Function owner [1] Product owner [1] Owner [2] External Customer (requester) [15] Third-party [3] End-user [4] Real [2] Citizen (potential user) [2] Service providers (carrier) [2] Customers of customers [1] Consultant (specialist) [2] Fig. 2 Roles that participate in requirements elicitation: A classification in big companies (e.g., S7(D) who indicated that: "The business requirements are gathered from the customers by another part of the organization", or because no clear roles had been defined for conducting the elicitation process. Consider, for example, S4(B)'s observation: "The workshops involve different people in the organization". ...
Article
Full-text available
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.
... Finally, in [19], we concentrated on the often mentioned problem of Incomplete and / or hidden requirements and investigated common causes for this problem based on the Austrian and Brazilian data. The most common causes we found were Missing qualification of RE team members, Lack of experience, Missing domain knowledge, Unclear business needs and Poorly defined requirements. ...
... Finally, the data sets from Brazil and Austria was used to investigate in detail the incomplete / hidden requirements problem [19]. The causes found there are also included in the results of this article. ...
... The distribution over the categories of causes changed slightly from a strong focus on people (40%) to input (34%) and method (33%). Yet, the results of this article contain far more causes than we found in [19]. ...
Article
Full-text available
Requirements Engineering (RE) has received much attention in research and practice due to its importance to software project success. Its inter-disciplinary nature, the dependency to the customer, and its inherent uncertainty still render the discipline dicult to investigate. This results in a lack of empirical data. These are necessary, however, to demonstrate which practically relevant RE problems exist and to what extent they matter. Motivated by this situation, we initiated the Naming the Pain in Requirements Engineering (NaPiRE) initiative which constitutes a globally distributed, bi-yearly replicated family of surveys on the status quo and problems in practical RE. In this article, we report on the qualitative analysis of data obtained from 228 companies working in 10 countries in various domains and we reveal which contemporary problems practitioners encounter. To this end, we analyse 21 problems derived from the literature with respect to their relevance and criticality in dependency to their context, and we complement this picture with a cause-e↵ect analysis showing the causes and e↵ects surrounding the most critical problems. Our results give us a better understanding of which problems exist and how they manifest themselves in practical environments. Thus, we provide a first step to ground contributions to RE on empirical observations which, until now, were dominated by conventional wisdom only.
... All up-to-date information on NaPiRE together with links to all publications, the instruments used for each replication, links to the published open data sets, as well as the steering manifesto of the initiative is available on the web site http://www.napire.org. Article on the Prevention of Incomplete/Hidden Requirements [27] Article on Causes of RE Problems [28] Preliminary report on Design and First Run [41] Main Article on Design, Theory and First Run [42] Comparison of Brazil and Germany [44] Main Article on Problems, Causes and E ects from Second Run [43] Fig. 1. Timeline of the major NaPiRE activities A preliminary version of the report on the first run was published in [41] and the detailed data and descriptive analysis is available as a technical report [40]. ...
... In [27], we focused on the often mentioned problem of Incomplete and/or hidden requirements and investigated common causes for this problem based on the Austrian and Brazilian data. The most common causes we found were Missing qualification of RE team members, Lack of experience, Missing domain knowledge, Unclear business needs and Poorly defined requirements. ...
... Finally, we describe the analysis of the part of the questionnaire on contemporary problems, their causes and effects in the corresponding main article [43]. In the current article, we use the same data set (and therefore the same context factors such as application domains) as in [27,28,43]. Yet, we use a part of the data set not covered in the previous papers: the parts on the participants use of practices in requirements elicitation, requirements documentation, requirements change and alignment and their use of requirements engineering standards as well as their improvement. ...
Article
Full-text available
Context: Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. Objective: We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. Method:We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries world-wide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. Results: In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents is common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Conclusion: Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.
... Again incomplete/hidden requirements and poor communication were among the most critical reported RE problems. Finally, in [13], we took a first step into RE problem prevention by further analysing the reported common causes and mitigation actions for the specific problem of incomplete/hidden requirements based on the Austrian and Brazilian data. ...
... In this paper we significantly extend the effort done in [13] based on the findings in [12], by looking at the complete data set, identifying and analysing critical problems, causes and mitigation actions, independently of the country. Therefrom we aim at deriving guidelines for organisations to help them in preventing the problems. ...
Conference Paper
Full-text available
Abstract—[Context] Problems in Requirements Engineering (RE) can lead to serious consequences during the software development lifecycle. [Goal] The goal of this paper is to propose empirically-based guidelines that can be used by different types of organisations according to their size (small, medium or large) and process model (agile or plan-driven) to help them in preventing such problems. [Method] We analysed data from a survey on RE problems answered by 228 organisations in 10 different countries. [Results] We identified the most critical RE problems, their causes and mitigation actions, organizing this information by clusters of size and process model. Finally, we analysed the causes and mitigation actions of the critical problems of each cluster to get further insights into how to prevent them. [Conclusions] Based on our results, we suggest preliminary guidelines for preventing critical RE problems in response to context characteristics of the companies.
... We also made a detailed qualitative analysis of the experienced problems and how they manifest themselves. For the second run, we have published several papers [18,19,20,21] concentrating on specific aspects and the data from only one or two countries and one paper [5] focusing on RE problems, causes and effects based on the complete data set covering data reported by 228 companies. An analysis of the data with a focus on risk management and evidence-based risk management in RE has not been published so far. ...
... They also strengthened our confidence in continuing the envisioned future work. This work includes running a field study which is currently in preparation and enriching our approach with a set of recommendations associated with context-sensitive risk factors as shown in previous work on guidelines to prevent RE problems [20,25]. ...
Conference Paper
Full-text available
Background: The sensitivity of Requirements Engineering (RE) to the context makes it difficult to efficiently control problems therein, thus, hampering an effective risk management devoted to allow for early corrective or even preventive measures. Problem: There is still little empirical knowledge about context-specific RE phenomena which would be necessary for an effective context-sensitive risk management in RE. Goal: We propose and validate an evidence-based approach to assess risks in RE using cross-company data about problems, causes and effects. Research Method: We use survey data from 228 companies and build a probabilistic network that supports the forecast of context-specific RE phenomena. We implement this approach using spreadsheets to support a light-weight risk assessment. Results: Our results from an initial validation in 6 companies strengthen our confidence that the approach increases the awareness for individual risk factors in RE, and the feedback further allows for disseminating our approach into practice.
... In [21], we focused on the often mentioned problem of Incomplete and/or hidden requirements and investigated common causes for this problem based on the Austrian and Brazilian data. The most common causes we found were Missing qualification of RE team members, Lack of experience, Missing domain knowledge, Unclear business needs and Poorly defined requirements. ...
... In our preliminary publications on this run of the survey, we compared countries and regions [21,32]. Therefore, we initially also analysed the complete dataset in total as well as divided by country and region. ...
Preprint
Full-text available
Requirements Engineering (RE) has established itself as a software engineering discipline during the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirically-based theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and valid foundation for a theory of RE, which helps software engineers establish effective and efficient RE processes. We designed a survey instrument and theory that has now been replicated in 10 countries world-wide. We evaluate the propositions of the theory with bootstrapped confidence intervals and derive potential explanations for the propositions. We report on the underlying theory and the full results obtained from the replication studies with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirically-based theory of RE giving insights into current practices with RE processes. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents is common, requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly intrinsically motivated. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.
... Table 9 shows primary studies grouped by related research topic areas. Notice that the number of studies in Table 9 (215) is greater than the number of primary studies (137) because Topic Area Primary studies #Studies TEST [43], [45], [47], [49], [53], [54], [63], [64], [65], [69], [75], [83], [85], [94], [96], [103], [104], [107], [109], [114], [115], [117], [122], [131], [133], [134], [135], [143], [145], [147], [152], [156], [157], [160], [163], [167], [173], [174] 38 REQS [41], [44], [46], [52], [58], [59], [60], [71], [73], [79], [80], [84], [86], [87], [88], [93], [99], [100], [101], [102], [112], [116], [119], [121], [124], [126], [127], [136], [154], [159], [160], [164], [166], [168], [169] 35 CONS [47], [50], [67], [68], [70], [72], [73], [76], [85], [95], [97], [102], [106], [107], [120], [122], [123], [128], [129], [130], [132], [137], [138], [140], [141], [142], [146], [147], [150], [153], [156], [157], [161], [162], [165] 35 DESG [42], [48], [54], [68], [70], [76], [81], [82], [83], [88], [94], [98], [99], [108], [110], [112], [114], [125], [136], [159], [164], [168], [170], [172], [173], [175], [176] 27 QUAL [40], [41], [43], [45], [51], [53], [63], [64], [65], [66], [69], [76], [77], [85], [91], [104], [112], [115], [118], [139], [144], [148], [156], [171] 24 METH [42], [55], [56], [57], [61], [77], [78], [108], [111], [137], [144], [149], [163], [164], [166], [170], [175] 17 MAIN [46], [50], [59], [60], [72], [81], [92], [97], [98], [134], [141], [142], [149], [150] 14 ...
... Primary studies #Studies EX [41], [42], [43], [44], [46], [47], [48], [49], [50], [53], [54], [55], [56], [57], [59], [60], [61], [63], [64], [65], [68], [70], [71], [72], [74], [75], [76], [77], [78], [81], [83], [88], [89], [90], [92], [93], [94], [95], [96], [97], [98], [99], [100], [101], [102], [104], [107], [110], [111], [112], [115], [117], [120], [121], [122], [124], [125], [127], [128], [129], [131], [132], [133], [134], [135], [136], [138], [139], [140], [141], [142], [143], [144], [145], [146], [147], [149], [151], [152], [154], [155], [156], [157], [159], [160], [161], [162], [163], [164], [165], [166], [167], [168], [169], [170], [171], [172], [173], [174], [175], [176] 101 (73,72%) CS [45], [51], [62], [66], [69], [73], [82], [84], [85], [86], [87], [91], [103], [109], [113], [118], [119], [130], [153] 19 (13,87%) SV [58], [79], [80], [105], [106], [108], [114], [116], [123], [126], [137], [158] 12 (8,76%) QE [40], [52], [67], [148], [150] ...
Article
Full-text available
Context: In any discipline, replications of empirical studies are necessary to consolidate the acquired knowledge. In Software Engineering, replications have been reported since the 1990s, although their number is still small. The difficulty in publishing, the lack of guidelines, and the unavailability of replication packages are pointed out by the community as some of the main causes. Objective: Understanding the current state of replications in Software Engineering studies by evaluating current trends and evolution during the last 6 years. Method: A Systematic Mapping Study including articles published in the 2013–2018 period that report at least one replication of an empirical study in Software Engineering. Results: 137 studies were selected and analysed, identifying: i) forums; ii) authors, co-authorships and institutions; iii) most cited studies; iv) research topics addressed; v) empirical methods used; vi) temporal distribution of publications; and vii) distribution of studies according to research topics and empirical methods. Conclusions: According to our results, the most relevant forums are the Empirical Software Engineering and Information and Software Technology journals, and the Empirical Software Engineering and Measurement conference. We observed that, as in previous reviews by other researchers, most of the studies were carried out by European institutions, especially Italian, Spanish, and German researchers and institutions. The studies attracting more citations were published mainly in journals and in the International Conference on Software Engineering. Testing, requirements, and software construction were the most frequent topics of replication studies, whereas the usual empirical method was the controlled experiment. On the other hand, we identified research gaps in areas such as software engineering process, software configuration management, and software engineering economics. When analysed together with previous reviews, there is a clear increasing trend in the number of published replications in the 2013–2018 period.
... The previous installments of the NaPiRe survey have been successful in sparking complementing research into several viewpoint of requirements engineering. For instance, to compare requirements engineering practices across geographical regions [22] [17] or by development method [28] [29]. We argue that, although NaPiRE data has been extensively analyzed, it has so far not been analyzed with regards to practitioners' perceptions about handling NFRs. ...
Preprint
Background: To adequately attend to non-functional requirements (NFRs), they must be documented; otherwise, developers would not know about their existence. However, the documentation of NFRs may be subject to Technical Debt and Waste, as any other software artefact. Aims: The goal is to explore indicators of potential Technical Debt and Waste in NFRs documentation. Method: Based on a subset of data acquired from the most recent NaPiRE (Naming the Pain in Requirements Engineering) survey, we calculate, for a standard set of NFR types, how often respondents state they document a specific type of NFR when they also state that it is important. This allows us to quantify the occurrence of potential Technical Debt and Waste. Results: Based on 398 survey responses, four NFR types (Maintainability, Reliability, Usability, and Performance) are labelled as important but they are not documented by more than 22% of the respondents. We interpret that these NFR types have a higher risk of Technical Debt than other NFR types. Regarding Waste, 15% of the respondents state they document NFRs related to Security and they do not consider it important. Conclusions: There is a clear indication that there is a risk of Technical Debt for a fixed set of NFRs since there is a lack of documentation of important NFRs. The potential risk of incurring Waste is also present but to a lesser extent.
... On the other hand, there are also surveys trying to investigate the problems in software projects, e.g., [20] from which we can learn on which practices to focus. ...
Chapter
Full-text available
Context. Among many Agile software development practices, over 30 concern Requirements Engineering (RE). However, none of them mentions explicitly non-functional requirements (NFRs). The question arises – how important are NFRs in Agile software projects? | Method. We conducted a survey asking Agile software development practitioners how they perceive the importance of having NFRs defined in their projects. Then, we juxtaposed the answers with their opinions on the perceived importance of 31 Agile RE practices. Results. The opinions of 118 respondents from a wide range of countries around the globe allowed us to determine how important it is to define NFRs. Moreover, we showed their importance from the perspective of the ranking of Agile RE practices. We also identified some relationships between the demographic data such as experience and the perceived importance of requirements concerning quality. Conclusions. We found that over 77% of respondents perceive having NFRs defined in Agile software project as at least important, and for 30% it is critical. Also, the perceived importance of NFRs increases with the increase of respondents’ experience.
... The previous installments of the NaPiRe survey have been successful in sparking complementing research into several viewpoint of requirements engineering. For instance, to compare requirements engineering practices across geographical regions [22] [17] or by development method [28] [29]. We argue that, although NaPiRE data has been extensively analyzed, it has so far not been analyzed with regards to practitioners' perceptions about handling NFRs. ...
Conference Paper
Background: It is important to pay attention to non-functional requirements (NFRs). To adequately attend to NFRs, they must be documented - otherwise, developers would not know about their existence. We assume that there exists a positive correlation between the level of importance of an NFR and its documentation. Aims: The goal is to explore the relationship between the level of importance and degree of documentation for NFRs. Method: Based on a subset of data acquired from the most recent NaPiRE (Naming the Pain in Requirements Engineering) survey, we calculate for a standard set of NFR types comprising Compatibility, Maintainability, Performance, Portability, Reliability, Safety, Security, and Usability how often respondents state they document a specific type of NFR when they also state that this type of NFR is important. In addition, we calculate the occurrence of potential Technical Debt and Waste. Results: Our analyses based on 398 survey responses indicate that for four NFR types (Maintainability, Reliability, Usability, and Performance), more than 22% of the 398 survey respondents who labelled those NFR types as important stated that they did not document them. We interpret this as an indication that these NFR types have a higher risk of Technical Debt than other NFR types. Regarding Waste, the problem is less frequent, with the exception of Security with 15% of respondents stating that they document requirements which they do not consider important. Conclusions: There is a clear indication that for a fixed set of NFRs lack of documentation of important NFRs occurs often, suggesting a risk of Technical Debt. The potential risk of incurring Waste is also present but to a lesser extent.
... These findings were based on the 400 respondents who answered the questionnaire, the respondents were chosen randomly from different Egyptian organizations within the software industry; the sample was based on the respondents' role; to benefit from their real life empirical experience. The findings obtained from this research indicate that the organizations with the finest requirement specifications quality are the organizations with higher success rates in software development, which congruent with the results in [51][52][53][54]. Moreover, Organizations with lower percentage of requirements volatility accomplished more software development success, yet it shouldn't be presumed that the use of high quality requirements specifications alone ensures the accomplishment of such success. ...
... First, according to Yusop et al. [31] in the web development domain developers are those who elicit requirements including NFRs. Secondly, according to Kalinowski et al. [32] many employees of software development companies are not experts in RE, they miss experience and qualification, which is one of the most commonly reported cause of problems in software projects connected to RE. ...
Article
Context. Non-functional requirements (NFRs) are not easy to elicit and formulate. Therefore, some experts advocate using templates, i.e., statement patterns with parameters and optional parts. Unfortunately, there is still scarcity of evidence showing the benefits of this approach. Objective.We aim at evaluating the usefulness of catalog of NFR templates in the context of inexperienced requirements elicitors and the effort required to maintain such catalog. Method.To investigate the usefulness of NFR templates, an experiment was conducted with 107 participants. The participants, individually or in teams, elicited NFRs based on a business case concerning an e-commerce system. To study the maintenance effort, we analyzed 2231 NFRs, 41 industrial projects to simulate the development of a catalog of NFR templates. We investigated how the characteristics of the catalog, essential from the maintenance perspective, change over a series of projects (a counterpart of elapsing time). Results.The participants using NFR templates provided NFRs that were more complete, less ambiguous, more detailed, and better from the point of view of verifiability than their counterparts using the ad hoc approach. However, the catalog of templates did not speed up the elicitation process. As regards the maintenance effort, we introduced the notion of mature catalog. In our case, ca. 40 projects were needed to make the catalog mature and then it contained 400 templates but less than 10% of them were used by a single project. The mature catalog subjected to the Pareto principle—about 20% of templates resulted in almost 80% of NFRs. Moreover, when updating the catalog after each project, less than 10% of templates had to be modified or added. Conclusions.Catalog of NFR templates seems useful. It increases the quality of NFRs and does not hinder elicitation speed. However, it takes time to make such catalog mature.
... For the second run, we have published three papers [10][11] [16] concentrating on specific aspects and the data from only one or two countries and one paper [17] focusing on RE problems, causes and effects based on the complete data set. An analysis of the data with a focus on the state of practice of RE in agile projects was recently published [19]. ...
Article
Full-text available
Requirements Engineering (RE) is being treated differently in agile development when compared to more traditional development processes. Yet, there is little empirical knowledge on the state of the practice and contemporary problems in agile RE. As part of a bigger survey initiative (Naming the Pain in Requirements Engineering), the main goal of this paper is to build an empirical basis on such aspects of agile RE, based on the responses of representatives from 92 different organisations. Our survey data analyses revealed that agile RE concentrates on free-text documentation of requirements elicited with a variety of techniques. The backlog is the central means to deal with changing requirements. Commonly traces between requirements and code are explicitly managed and testing and RE are typically aligned. Furthermore, continuous improvement of RE is performed due to intrinsic motivation and RE standards are commonly practiced. Among the main problems, we highlight incomplete requirements, communication flaws and moving targets. Those problems were reported to happen commonly in agile projects and to have critical consequences, including project failure. Overall, our findings show that most organisations conduct RE in a way we would expect and that agile RE is in several aspects not so different from RE in other development processes.
... We also made a detailed qualitative analysis of the experienced problems and how they manifest themselves. For the second run, we have published three papers [9,10,14] concentrating on specific aspects and the data from only one or two countries and one paper [15] focusing on RE problems, causes and effects based on the complete data set. An analysis of the data with a focus on the state of practice of RE in agile projects has not been published so far. ...
Conference Paper
Full-text available
Requirements engineering (RE) is considerably different in agile development than in traditional development processes. Yet, there is little empirical knowledge on the state of the practice and contemporary problems in agile RE. As part of a bigger survey initiative (Naming the Pain in Requirements Engineering), we build an empirical basis on such aspects of agile RE. Based on the responses of representatives from 92 different organisations, we found that agile RE concentrates on free-text documentation of requirements elicited with a variety of techniques. Often, traces between requirements and code are explicitly managed and also software testing and RE are aligned. Furthermore, continuous improvement of RE is performed due to intrinsic motivation. Important experienced problems include unclear requirements and communication flaws. Overall, we found that most organisations conduct RE in a way we would expect and that agile RE is in several aspects not so different from RE in other development processes.
... Furthermore, it has to be mentioned that the study was only conducted in the DACH region and that the validity of the results is therefore limited to that region. But due to the facts that similar surveys were initially performed in the DACH region and then replicated in other regions with similar results [16,17] and that we could not find significant differences between the results from Germany, Austria and Switzerland, we think that the survey will deliver similar results in other regions as well. However, a replication in other regions, which is already planned as future work, is required to confirm this statement. ...
Conference Paper
Full-text available
Context: Quality assurance performed during the implementation phase, e.g., by coding guidelines, static analysis or unit testing, is of high importance to ensure quality of software, but there is a lack of common knowledge and best practices on it. Objective: The goal of this paper is to investigate the state-of-practice of quality assurance during the implementation phase in software houses. Method: For this purpose, we conducted a survey in Germany, Austria, and Switzerland where 57 software houses participated. The questionnaire comprised questions regarding techniques, tools, and effort for software quality assurance during implementation as well as the perceived quality after implementation. The results were complemented by interviews and results from other surveys on software quality in general. Results: Results from the survey show that the most common software quality assurance techniques used during implementation are unit testing, code reviews and coding guidelines. Most tool support is used in the areas of bug tracking, version control and project management. Due to relationships between the used tool types, it seems that the introduction of one tool leads to the adoption of several others. Also quality assurance techniques and tools are correlated. Bug fixing takes a significant ratio of the overall project effort assigned to implementation. Furthermore, we found that the more developers a software company has, the more effort is spent on bug fixing. Finally, more than half of all companies rated the quality after implementation as rather good to good. Conclusion: For the most important quality assurance techniques and supporting tool types clear usage patterns can be seen and serve as a basis to provide guidelines on their application in practice.
... For the second run, we have published three papers [10,11,12] so far, concentrating on specific aspects and the data from only one or two countries. An analysis of the data with a focus on the state of practice of RE in agile projects as well as a study based on data from all 10 countries has not been published so far. ...
Article
Full-text available
Requirements engineering (RE) is considerably different in agile development than in traditional processes. Yet, there is little empirical knowledge on the state of the practice and contemporary problems in agile RE. As part of a bigger survey initiative (Naming the Pain in Requirements Engineering), we build an empirical basis on such aspects of agile RE. Based on the responses from 92 people representing 92 organizations, we found that agile RE concentrates on free-text documentation of requirements elicited with a variety of techniques. Many manage explicit traces between requirements and code. Furthermore, the continuous improvement of RE is done because of intrinsic motivation. Important experienced problems include unclear requirements and communication flaws. Hence, agile RE is in several aspects not so different from RE in other development processes. We plan to investigate specific techniques, such as acceptance-test-driven development, in a future survey to better capture what is special in agile RE.
... Kalinowski, et al. [18] presented a study on incomplete and hidden requirements based on a survey called Naming the Pain in Requirements Engineering (NaPiRE) in Austria and Brazil from 14 and 74 companies respectively, both used plan-driven (waterfall) and agile methodology (scrum), they stated many problems in requirements which some of them are: missing qualifications of requirements engineering team members, lack of experience, missing domain knowledge, unclear business needs and poorly defined requirements, and introduced solutions to them, but the most remarkable problem was incomplete and hidden requirements that occupied the top of the list in Austria and the second in Brazil. ...
Article
Full-text available
Requirements engineering processes aim to acquire functions, services and constraints. These processes are important to satisfy the customer by applying correctness, completeness through consistency according to the control instructions to achieve product quality. Both functions and services face changeability issue that is hard to regulate, depending on the precise request of the customer. This research addresses the achievement of correctness, completeness, and consistency by applying an automated approach. The evaluation is established using a standard use case diagram from the UML official website. The proposed approach detects the incorrect requirement specifications to enhance Software quality. The proposed approach includes three levels; the first level is the Structured Document, the second level is the Dynamic Language, which describes the transforming of use case diagram as dynamic, and the third level is the completeness checking procedures, which is based on the implemented standard rules. The approach is supported by a programmed tool on MS excel and XML due to IBM Rational Rose and Visual Paradigm and experimented "Online Shopping" use case diagram as a case study.
Article
There has been significant interest in automatically generating test cases from a non-deterministic finite state machine (FSM). Most approaches check that the behaviours of the system under test (SUT) are allowed by the specification FSM; they therefore test for reduction. However, sometimes one wants all of the behaviours, and so features, of the specification to be implemented and then one is testing for equivalence. In this paper we first note that in order to test for equivalence one must effectively be able to observe the SUT not being able to produce an output $y$ in response to an input $x$ after trace $\sigma$; we model this as the absence of an output. We prove that the problem of testing for equivalence to FSM $M$ can be mapped to testing for reduction to an FSM $R(M)$ that extends $M$ with absences. Thus, one can use techniques developed for testing for reduction when testing for equivalence. We then consider the case where the specification is partial, generalising the result to quasi-equivalence. These results are proved for observable specifications and so we also show how a partial FSM can be mapped to an observable partial FSM from which we can test.
Chapter
Background: To adequately attend to non-functional requirements (NFRs), they must be documented; otherwise, developers would not know about their existence. However, the documentation of NFRs may be subject to Technical Debt and Waste, as any other software artefact. Aims: The goal is to explore indicators of potential Technical Debt and Waste in NFRs documentation. Method: Based on a subset of data acquired from the most recent NaPiRE (Naming the Pain in Requirements Engineering) survey, we calculate, for a standard set of NFR types, how often respondents state they document a specific type of NFR when they also state that it is important. This allows us to quantify the occurrence of potential Technical Debt and Waste. Results: Based on 398 survey responses, four NFR types (Maintainability, Reliability, Usability, and Performance) are labelled as important but they are not documented by more than 22% of the respondents. We interpret that these NFR types have a higher risk of Technical Debt than other NFR types. Regarding Waste, 15% of the respondents state they document NFRs related to Security and they do not consider it important. Conclusions: There is a clear indication that there is a risk of Technical Debt for a fixed set of NFRs since there is a lack of documentation of important NFRs. The potential risk of incurring Waste is also present but to a lesser extent.
Conference Paper
[Context] Defect Causal Analysis (DCA) represents an efficient practice to improve software processes. While knowledge on cause-effect relations is helpful to support DCA, collecting cause-effect data may require significant effort and time. [Goal] We propose and evaluate a new DCA approach that uses cross-company data to support the practical application of DCA. [Method] We collected cross-company data on causes of requirements engineering problems from 74 Brazilian organizations and built a Bayesian network. Our DCA approach uses the diagnostic inference of the Bayesian network to support DCA sessions. We evaluated our approach by applying a model for technology transfer to industry and conducted three consecutive evaluations: (i) in academia, (ii) with industry representatives of the Fraunhofer Project Center at UFBA, and (iii) in an industrial case study at the Brazilian National Development Bank (BNDES). [Results] We received positive feedback in all three evaluations and the cross-company data was considered helpful for determining main causes. [Conclusions] Our results strengthen our confidence in that supporting DCA with cross-company data is promising and should be further investigated.
Conference Paper
Full-text available
[Context] Petrobras is Brazil's largest publicly-held company, operating in the oil, natural gas, and energy industry. Internal efforts enabled Petrobras to identify Digital Transformation (DT) opportunities to further promote their operational excellence. While addressing these opportunities typically requires Research and Development (R&D) uncertainties that could lead traditional R&D cooperation terms to be negotiated in years, there are time-to-market constraints for fast-paced deliveries to experiment solution options. Having this in mind, they partnered up with PUC-Rio to establish a new DT initiative. [Goal] The goal of this paper is to present the Lean R&D approach, tailored within the new initiative to meet the aforementioned DT needs. [Method] We designed Lean R&D integrating the following building blocks: (i) Lean Inceptions, to allow stakeholders to jointly outline a Minimal Viable Product (MVP); (ii) parallel technical feasibility assessment and conception phases, allowing to 'fail fast'; (iii) scrum-based development management; and (iv) strategically aligned continuous experimentation to test business hypotheses. We report on first experiences of applying Lean R&D in practice. [Results] Lean R&D enabled addressing research-related uncertainties early and to efficiently deliver valuable MVPs within fast-paced four months cycles. [Conclusions] In our first experiences Lean R&D showed itself suitable for supporting DT initiatives. However, more formal case studies are needed. The business strategy alignment and the continuous support of a highly qualified research team were considered key success factors.
Article
Full-text available
Conference Paper
Full-text available
[Context] Many software projects fail due to problems in Requirements Engineering (RE). [Objective] The goal of this paper is to gather information on relevant RE problems and to represent knowledge on their most common causes. [Method] We replicated a global family of RE surveys in Brazil and used the data to identify critical RE problems and to build probabilistic cause-effect diagrams to represent knowledge on their common causes. [Results] The survey was answered by 74 different organizations, including small, medium and very large sized companies, conducting both, plan-driven and agile development. The most critical RE problems, according to those organizations, are related to communication and to incomplete or underspecified requirements. We provide the full probabilistic cause-effect diagrams with knowledge on common causes of the most critical identified RE problems online. [Conclusion] We believe that the knowledge presented in the diagrams can be helpful to support organizations in conducting causal analysis sessions by providing an initial understanding on what usually causes critical RE problems.
Conference Paper
Full-text available
[Context] In December 2003 the MPS.BR Program was launched aiming at establishing and disseminating a software process reference model – the MPS-SW – allowing both micro, small and medium-sized enterprises and large organizations to achieve the benefits of process improvement. Nowadays, ten years later, the achieved results exceed MPS.BR’s predefined benchmarks in several ways. [Objective] This paper aims at providing an overview on the MPS-SW model and presenting these results, describing its nationwide adoption in Brazil (more than 500 assessments spread across the country) and outcomes of two recent surveys concerning the impact of such adoption in the software industry. [Method] We planned surveys to capture the impact from two different and complementary points of view: the qualitative perception of the customers (sponsors of MPS-SW adopting organizations) and the performance results of organizations that adopted the model (e.g. concerning productivity, quality and estimation accuracy). [Results] Results of the qualitative survey indicated that the adoption was motivated by both, business and technical reasons and that most sponsors (91%) are satisfied with the obtained improvements and would recommend the MPS-SW model. Results of the survey on performance results indicated higher productivity, quality and estimation accuracy for organizations assessed in higher maturity levels.
Conference Paper
Full-text available
Context: For many years, we have observed industry struggling in defining a high quality requirements engineering (RE) and researchers trying to understand industrial expectations and problems. Although we are investigating the discipline with a plethora of empirical studies, those studies either concentrate on validating specific methods or on single companies or countries. Therefore, they allow only for limited empirical generalisations. Objective: To lay an empirical and generalisable foundation about the state of the practice in RE, we aim at a series of open and reproducible surveys that allow us to steer future research in a problem-driven manner. Method: We designed a globally distributed family of surveys in joint collaborations with different researchers from different countries. The instrument is based on an initial theory inferred from available studies. As a long-term goal, the survey will be regularly replicated to manifest a clear understanding on the status quo and practical needs in RE. In this paper, we present the design of the family of surveys and first results of its start in Germany. Results: Our first results contain responses from 30 German companies. The results are not yet generalisable, but already indicate several trends and problems. For instance, a commonly stated problem respondents see in their company standards are artefacts being underrepresented, and important problems they experience in their projects are incomplete and inconsistent requirements. Conclusion: The results suggest that the survey design and instrument are well-suited to be replicated and, thereby, to create a generalisable empirical basis of RE in practice.
Conference Paper
Full-text available
Defect causal analysis (DCA) has shown itself an efficient means to improve the quality of software processes and products. A DCA approach exploring Bayesian networks, called DPPI (Defect Prevention-Based Process Improvement), resulted from research following an experimental strategy. Its conceptual phase considered evidence-based guidelines acquired through systematic reviews and feedback from experts in the field. Afterwards, in order to move towards industry readiness the approach evolved based on results of an initial proof of concept and a set of primary studies. This paper describes the experimental strategy followed and provides an overview of the resulting DPPI approach. Moreover, it presents results from applying DPPI in industry in the context of a real software development lifecycle, which allowed further comprehension and insights into using the approach from an industrial perspective.
Article
Full-text available
Default causal analysis (DCA) or defect prevention is required by higher-maturity-level software development processes such as the Brazilian Software Process Improvement Reference Model and Capability Maturity Model Integration. The authors ask and answer questions about implementing it in lower-maturity organizations. In the related web extra entitled “Evidence-Based Guidelines on Defect Causal Analysis,” authors Marcos Kalinowski, David N. Card, and Guilherme H. Travassos discuss the basics of research protocol.
Conference Paper
Full-text available
Defect causal analysis (DCA) has shown itself an efficient means to obtain product-focused software process improvement. A DCA approach, called DPPI, was assembled based on guidance acquired through systematic reviews and feedback from experts in the field. To our knowledge, DPPI represents an innovative approach integrating cause-effect learning mechanisms (Bayesian networks) into DCA meetings, by using probabilistic cause-effect diagrams. The experience of applying DPPI to a real Web-based software project showed its feasibility and provided insights into the requirements for tool support. Moreover, it was possible to observe that DPPI’s Bayesian diagnostic inference predicted the main defect causes efficiently, motivating further investigation. This paper describes (i) the framework built to support the application of DPPI and automate the generation of the probabilistic cause-effect diagrams, and (ii) the results of an experimental study aiming at investigating the benefits of using DPPI’s probabilistic cause-effect diagrams during DCA meetings.
Conference Paper
Full-text available
Defect causal analysis (DCA) is a means of product focused software process improvement. A systematic literature review to identify the DCA state of the art has been undertaken. The systematic review gathered unbiased knowledge and evidence and identified opportunities for further investigation. Moreover, some guidance on how to efficiently implement DCA in software organizations could be elaborated. This paper describes the initial concept of the DBPI (Defect Based Process Improvement) approach. It represents a DCA based approach for process improvement, designed considering the results of the systematic review and the obtained guidance. Its main contributions are tailoring support for DCA based process improvement and addressing an identified opportunity for further investigation by integrating organizational learning mechanisms regarding cause-effect relations into the conduct of DCA.
Article
Full-text available
In this paper we discuss our study of the problems 12 software companies experienced in software development. In total we present qualitative data collected from 45 focus groups that involved over 200 software staff. We look at how different practitioner groups respond to software process improvement problems. We show our classification and analysis of this data using correspondence analysis. Correspondence analysis is a graphical data representation method new to software development research. The aim of the work we present is to develop a more holistic understanding of the problems practitioners are experiencing in their attempts to improve their software processes. Our main finding is that there is an association between a company's capability maturity and patterns of reported problems. Organizational problems are more associated with high maturity companies than with low maturity companies. Low maturity companies are closely linked to problems relating directly to projects such as documentation, timescales, tools and technology. Our findings also confirm differences in practitioner group problems. Senior managers cite problems with goals, culture and politics. Project managers are concerned with timescales, change management, budgets and estimates. Developers are experiencing problems with requirements, testing, documentation, communication, tools and technology. These associations are displayed graphically through correspondence analysis maps.
Article
Full-text available
A study of the problems experienced by twelve software companies in their requirements process is discussed. The aim of the work is to develop a more holistic understanding of the requirements process, so that companies can more effectively organise and manage requirements. The findings suggest that most requirements problems are organisational rather than technical, and that there is a relationship between companies' maturity and patterns of requirements problems.
Conference Paper
This paper reports on a study investigating the current state of requirements engineering problems and practice amongst small and medium software companies in Thailand. The main objective of the study was to determine areas to improve in requirements engineering processes. Data was collected through semi-structured interviews with eleven small and medium enterprises (SMEs). Results show that software firms in Thailand encounter common problems such as clarity, correctness, completeness, change management, and customer communication. The result also shows the development needs in SMEs such as software process improvement, RE knowledge, requirements management tools, training, and knowledge transfer.
Article
Context For many years, we have observed industry struggling in defining a high quality requirements engineering (RE) and researchers trying to understand industrial expectations and problems. Although we are investigating the discipline with a plethora of empirical studies, they still do not allow for empirical generalisations. Objective To lay an empirical and externally valid foundation about the state of the practice in RE, we aim at a series of open and reproducible surveys that allow us to steer future research in a problem-driven manner. Method We designed a globally distributed family of surveys in joint collaborations with different researchers and completed the first run in Germany. The instrument is based on a theory in the form of a set of hypotheses inferred from our experiences and available studies. We test each hypothesis in our theory and identify further candidates to extend the theory by correlation and Grounded Theory analysis. Results In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from Germany with participants from 58 companies. The results reveal, for example, a tendency to improve RE via internally defined qualitative methods rather than relying on normative approaches like CMMI. We also discovered various RE problems that are statistically significant in practice. For instance, we could corroborate communication flaws or moving targets as problems in practice. Our results are not yet fully representative but already give first insights into current practices and problems in RE, and they allow us to draw lessons learnt for future replications. Conclusion Our results obtained from this first run in Germany make us confident that the survey design and instrument are well-suited to be replicated and, thereby, to create a generalisable empirical basis of RE in practice.
Conference Paper
This paper presents about a study conducted to investigate the current state of Requirements Engineering (RE) problems and practices amongst the software development companies in Malaysia. The main objective of the study is to determine areas in RE process that should be addressed in future research in order to improve the process. Information required for the study was obtained through a survey, questionnaires distributed to project managers and software developers who are working at various software development companies in the country. Results show that software companies in this study are still facing great challenges in getting their requirements right due to organizational and technical factors. Also, we found out that high-maturity ratings do not generally correlate better performance and do not indicate effective, high-maturity practices especially to the RE practices. The findings imply that we must consider both human and technical problems, with extra care should be given to the technical issues and all the RE practices in our future research which is to re-build a specialized RE process improvement model.
Conference Paper
Adequate software functionality and quality is a crucial issue in a society that vitally depends on software systems. The rising expectations of software users, the distribution of software over networks, size and complexity of today’s software systems bring our engineering abilities to limits. Functionality, the cost and the quality of software critically depend on an adequate requirements engineering. We argue in favor of systematic requirements engineering that is model-based, targeting comprehensive system architectures and deeply integrated into software life cycle models.
Conference Paper
Requirements engineering has gained growing attention in both academia and industry, as today's software intensive systems are expected to provide highly user-centric functions and qualities. Thus, it is important to understand under what situations existing requirements engineering practice is not working well. Continuing our probe into the industrial practices status quo, this paper reports the results from a recent survey of requirements practices in China in 2009. The web-based survey of requirements engineering practices focuses on requirements elicitation techniques, requirements representation techniques. Although purporting to report on the state-of-the-art of requirements engineering in China, it is likely to portray the state-of-the-art of RE worldwide as well.
Article
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. 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. 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. 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.
Article
In this paper we discussed the project success figures reported on by Standish Group. In 1994 Standish published the Chaos report that showed a shocking 16% project success. This and renewed figures by Standish are often used to indicate information technology is in a troublesome state. However, some authors have raised questions about the validity of these figures. In this paper we showed that Standish’s successful and challenged project results are indeed meaningless for benchmarking. Our research on 12187 forecasts of 1741 real-world projects of in total 1059 million euro showed that IT forecasts have political biases. Yet, Standish’s numbers, which depend on IT forecasts, do not account for these biases. Therefore, these figures have very limited use for benchmarking as we demonstrated using our real-world data.
Software e Serviços de TI: A Indústria Brasileira em Perspectiva
• Softex
Softex: Software e Serviços de TI: A Indústria Brasileira em Perspectiva. Observatório Softex (ISSN 1984-6797), vol. 2 (2012).
Results of 10 Years of Software Process Improvement in Brazil Based on the MPS-SW Model
• M Kalinowski
• K Weber
• N Franco
• V Duarte
• G Santos
• G Travassos
Kalinowski, M., Weber, K., Franco, N., Duarte, V., Santos, G., Travassos, G.: Results of 10 Years of Software Process Improvement in Brazil Based on the MPS-SW Model. In: International Conference on the Quality in Information and Communications Technology (QUATIC), pp.28-37 (2014).