No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Naming the Pain in Requirements Engineering: A Design for a Global Family of Surveys and First Results from Germany
Abstract
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.
... Requirements Engineering (RE) is highly volatile and inherently complex by nature [1]. Given this complexity, organisations may face several problems during the RE process, leading to severe implications, including project failure [2] [3]. ...
... In order to better understand the status quo on RE practice and its critical problems, a project named NaPiRE (Naming the Pain in Requirements Engineering) was launched in 2012 involving researchers from different countries [1]. The NaPiRE project comprises the design of a family of surveys on RE and its goal is to lay an empirical foundation about practical problems and needs of RE to allow directing future research in a problem-driven manner [1]. ...
... In order to better understand the status quo on RE practice and its critical problems, a project named NaPiRE (Naming the Pain in Requirements Engineering) was launched in 2012 involving researchers from different countries [1]. The NaPiRE project comprises the design of a family of surveys on RE and its goal is to lay an empirical foundation about practical problems and needs of RE to allow directing future research in a problem-driven manner [1]. The last survey round (2014)(2015) was answered by in total 228 organisations from 10 different countries around the globe, including organisations of different sizes and following different process models. ...
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.
... In consequence, the individual particularities of the contexts hamper an effective risk management devoted to allow for early corrective or even preventive measures. Hence, it is not surprising that despite the importance of excellence in RE, we can still observe various problems in industrial environments rooted all in insufficient RE [4,5]. Requirements Engineering risk factors which might be typical for one project setting, might not be valid for others; for instance, while one project might be characterised by frequent changes in the requirements, the requirements in another project might be stable. ...
... Requirements Engineering risk factors which might be typical for one project setting, might not be valid for others; for instance, while one project might be characterised by frequent changes in the requirements, the requirements in another project might be stable. Another factor to be considered is the currently weak state of empirical evidence in RE [4,5]. The lack of proper empirical figures that would demonstrate what phenomena occur in practical settings, what problems practitioners face, and what success factors we can infer for the various contexts makes it impossible for available risk management approaches to consider context-sensitive risk factors and related corrective and even preventive measures for RE. ...
... All up-to-date information on NaPiRE together with links to instruments used, the data, and all publications is available on the web site http://www.re-survey.org. The first run in Germany together with the overall study design was published in [4]. It already covered the spectrum of status quo and problems. ...
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.
... Solemon et al. [11] conducted a study to identify Malaysia's most common RE problems. The sample size was 64 respondents. ...
... Obtained survey results enable us to compare a list of requirements-related problems in the Ukrainian context with those in other countries specified in related works (Section 2). Even though direct comparison in some cases [10,11] is impossible due to different approaches in definitions of the problems, we can still match the problems in terms of general meaning. Table 5 shows the results of a comparison of the results in terms of business analysis problems with papers [10,11,13]. ...
... Even though direct comparison in some cases [10,11] is impossible due to different approaches in definitions of the problems, we can still match the problems in terms of general meaning. Table 5 shows the results of a comparison of the results in terms of business analysis problems with papers [10,11,13]. The comparison is made for the ten most relevant problems that scored 24 % or more within the framework of this study. ...
The subject matter of this article is business analysis and requirement engineering (BA/RE) in software projects. The goal is to identify the challenges faced by Ukrainian business analysts and requirement engineers in software development projects and investigate the possible reasons and negative consequences of these issues. The tasks to be solved are: create and conduct a survey on the practices of BA/RE in IT projects, define the most critical problems in BA/RE, their causes and implications, and define how project context influences problems in business analysis and requirement engineering. The methods used are: a survey (N = 324) was performed among business analysts and requirement engineers in Ukraine regarding problems in BA/RE and the context of IT projects in which they manifest. The Chi-Square test of independence and Cramer's V effect size measure were applied to define statistically significant dependencies between project context and BA/RE problems. The following results were obtained: the most critical problems in BA/RE, their causes, and their implications were defined and compared with other comprehensive studies. Twelve statistically significant associations for pairs "project context – BA/RE problem" were found (based on the p-value and Cramer's V effect size measure). Conclusion: 1) A comparison of the results of this study with similar studies conducted in other contexts has shown that the issues identified by Ukrainian BA/RE professionals are similar to those found by other researchers in other countries; 2) it is concluded that project context influences particular BA/RE problems, and these dependencies allow us to develop recommendations for risk management for particular problems depending on the project context.
... Choosing the proper techniques and ensuring that each technique is carried out correctly is extremely important for the elicitation activity's success. Best practices and recommendations in the field of elicitation techniques are defined by international standards [5], industrial bodies of knowledge [1], [7], [8], and international empirical studies [9], [10]. ...
... Based on feedback received from business analyst experts during survey review sessions and survey structure from [10], the following techniques were added: ...
... However, after studying the existing questionnaires developed for international surveys, we realized the necessity of adjusting them to Ukrainian IT companies' specifics. It was decided to take the questions' basis from the NaPIRE initiative [9], [10] and rework it concerning mentioned above sources such as [1], [6], [7], [8]. Survey items were carefully written using the business analysis vocabulary, mostly from BABOK. ...
The subject of research in the article is requirements elicitation practices in IT projects. The goal of the work is to define how project context influences requirement elicitation technique selection and identify dependencies between requirement elicitation techniques. The following tasks are solved in the article: examine the industrial standards and experience of business analysts and requirements engineers in requirements acquisition activities, create and conduct a survey on practices in requirement elicitation activities in IT projects, define practitioners’ preferences regarding elicitation techniques, and define how project context influences requirement elicitation technique selection, identify dependencies between requirement elicitation techniques. The following methods are used: a survey was performed among business analysts and requirement engineers in Ukraine regarding their use of requirement elicitation techniques and the context of using them. The Chi-Square test of independence and Cramer’s V effect size measure were applied to define statistically significant dependencies between project context and elicitation techniques, as well as dependencies between techniques. The following results were obtained: Top elicitation techniques were identified and compared with other comprehensive studies. Twenty statistically significant associations for pairs "project context – elicitation technique" and "elicitation technique – elicitation technique" were found (based on the p-value and Cramer’s V effect size measure). Conclusion: It is concluded that project context influences particular elicitation technique selection in IT projects. There are also dependencies between requirements elicitation techniques. These dependencies can guide the selection of an initial set of techniques or adjust a set of used elicitation techniques during business analysis planning and monitoring activities.
... However, after studying the existing questionnaires developed for international surveys, we realized the necessity of adjusting them to Ukrainian IT companies' specifics. It was decided to take the questions' basis from NaPIRE initiative [18] and rework it concerning mentioned above sources such as [1, 2, 6, 7]. Survey items were carefully written using the business analysis vocabulary, mostly from BABOK. ...
... In the given article we focus on the Elicitation and Collaboration topic in the context of general information questions about respondents' backgrounds. The result regarding the current state of requirements elicitation techniques in different software project contexts and statistically significant relationship between project context's attributes and elicitation techniques were described in [18]. Q1: General Information. ...
... 2. The main industrial sector of the current project. The set of industrial sectors was taken from [18] and reworked to domain areas within which services are offered by most of the Ukrainian IT Companies. 3. Company type: IT or non-IT. ...
Project Scope Management is one of the ten knowledge areas described in PMBOK. It refers to the set of processes that ensures a project’s scope is accurately defined and mapped. Elicitation is a critical part of the “Collect Requirements” process of the Scope Management that helps to derive and extract information from stakeholders or other sources. The results of elicitation are used as inputs for requirement analysis and management activities. Multiple elicitation techniques may be applied alternatively or in conjunction with other techniques to accomplish the elicitation. Business analysts can modify existing techniques or create new ones to adjust the project context. The selection of the best-suited techniques influences the business analysis approach, which is an important part of the scope management plan. This paper is intended to analyze the current practice of elicitation techniques application in the software development projects, define factors influencing technique selection based on the two-classification Machine Learning model, and predict the usage of a particular elicitation technique depending on the project attributes and business analyst background. We conducted a survey study involving 328 specialists from Ukrainian IT companies. Gathered data was used to build and evaluate the prediction models.
... It proposes a survey to be conducted periodically so as to investigate the state-of-practice and the current problems that RE practitioners are faced with. NaPiRE has been conducted twice so far; one NaPiRE survey was conducted in Germany [25], and the second survey was conducted in a group of 10 countries [45]. 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]. ...
... As can be seen in the table, group interaction techniques were the most frequently used approach for RE by our respondents. This observation is in agreement with Méndez et al.'s study [25], where the most commonly used elicitation technique was reported to be the use of workshops. This is also very similar to Wagner et al.' study [44] where meetings were the second most frequently mentioned technique. ...
... However, a fundamental difference between the present study and these two studies exist. In the present study, our interview subjects reported on a lack of stakeholder involvement, which was not the case in Méndez et al. [25] and Wagner et al.'s [44] studies. In these studies, stakeholder involvement was reported as commonplace. ...
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.
... It proposes a survey to be conducted periodically so as to investigate the state-of-practice and the current problems that RE practitioners are faced with. NaPiRE has been conducted twice so far; one NaPiRE survey was conducted in Germany [25], and the second survey was conducted in a group of 10 countries [45]. 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]. ...
... As can be seen in the table, group interaction techniques were the most frequently used approach for RE by our respondents. This observation is in agreement with Méndez et al.'s study [25], where the most commonly used elicitation technique was reported to be the use of workshops. This is also very similar to Wagner et al.' study [44] where meetings were the second most frequently mentioned technique. ...
... However, a fundamental difference between the present study and these two studies exist. In the present study, our interview subjects reported on a lack of stakeholder involvement, which was not the case in Méndez et al. [25] and Wagner et al.'s [44] studies. In these studies, stakeholder involvement was reported as commonplace. ...
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.
... Choosing the right techniques and ensuring each technique is performed correctly is extremely important to the success of the elicitation activity. The best practices and recommendation regarding elicitation techniques are defined in international standards [8], industrial bodies of knowledge [1], [9], [10], International empirical studies [11], [12]. ...
... However, after studying of the existing questionnaries developed for international surveys, we realized the necessity of adjusting them to Ukrainian IT companies' specifics. It was decided to take questions' basis from NaPIRE initiative [12] and rework it with respect to mentioned above sources such as [1], [8], [9], [10]. Survey items were carefully written using the business analysis vocabulary, mostly from BABOK. ...
... • Main industrial sector of the current project. Set of industrial sectors was taken from[12] and reworked with respect to domain areas within which services are offered by most of the Ukrainian IT Companies. ...
Elicitation is a core business analysis/requirement
engineering activity that provides inputs for another one: analysis, specification, confirmation, management. There is a significant number of specialized techniques that are used for requirement elicitation. The selection of the appropriate techniques
considerably influences a project plan and success of a change
as a whole. This paper is intended to analyse the industrial
standards and experience of business analysts and requirement
engineers in part of elicitation activities. We conducted a survey
study involving 328 specialists from Ukrainian IT companies and
a series of interviews with experts to interpret survey results.
Furthermore, this paper provides the guideline in selecting a
particular elicitation technique with respect to the type of project
and situation.
... Choosing the right techniques and ensuring each technique is performed correctly is extremely important to the success of the elicitation activity. The best practices and recommendation regarding elicitation techniques are defined in international standards [8], industrial bodies of knowledge [1], [9], [10], International empirical studies [11], [12]. ...
... However, after studying of the existing questionnaries developed for international surveys, we realized the necessity of adjusting them to Ukrainian IT companies' specifics. It was decided to take questions' basis from NaPIRE initiative [12] and rework it with respect to mentioned above sources such as [1], [8], [9], [10]. Survey items were carefully written using the business analysis vocabulary, mostly from BABOK. ...
... • Main industrial sector of the current project. Set of industrial sectors was taken from[12] and reworked with respect to domain areas within which services are offered by most of the Ukrainian IT Companies. ...
Elicitation is a core business analysis/requirement engineering activity that provides inputs for another one: analysis, specification, confirmation, management. There is a significant number of specialized techniques that are used for requirement elicitation. The selection of the appropriate techniques considerably influences a project plan and the success of a change as a whole. This paper is intended to analyze the industrial standards and experience of business analysts and requirement engineers in part of elicitation activities. We conducted a survey study involving 328 specialists from Ukrainian IT companies and a series of interviews with experts to interpret survey results. Furthermore, this paper provides the guideline in selecting a particular elicitation technique with respect to the type of project and situation.
... Requirements elicitation can be considered a complex task that often requires the participation of different stakeholders. These stakeholders contribute with different knowledge in this process, Fernandez and Wagner (2015). Recently, the identification of UX requirements during requirements elicitation has become a trend, Castro et al. (2008);Ferreira et al. (2015Ferreira et al. ( , 2018a; Choma et al. (2016a,b). ...
... Therefore, it can be inferred that the knowledge of both are complementary. Our findings restate the need of an interdisciplinary participation of various stakeholders, Fernandez and Wagner (2015). ...
... By comparing which UX requirements are presented in the storyboards we saw that the proto-personas+ of both types of stakeholders (i.e., pedagogues and software engineers) provide information that these artifacts supported the developers in the design of solutions. Additionally, the findings from storyboards analysis reaffirmed that both stakeholders provided complementary information Fernandez and Wagner (2015). ...
Context: Requirements elicitation is a software development phase that should investigate both functional and user experience (UX) requirements. Proto-persona is a technique that encourages the attention on the needs of a group of users. Usually, its elaboration is conducted by software specialists, technical stakeholders. However, non-technical stakeholders usually know more about target users and frequently do not take part in proto-persona elaboration. Objective: This work has the goal of investigating the contribution of non-technical stakeholders in the specification of UX requirements by using the proto-persona technique. For this, we explored the construction of the proto-personas and the use of these to the prototyping of solutions. Method: We carried out an empirical study in two rounds from which we analyzed and compared the contribution that technical and non-technical stakeholders had on the specification of UX requirements. In the first, 8 non-technical and 5 technical stakeholders built proto-personas. Afterwards, 18 pairs of software developers created low fidelity prototypes by using the information of proto-personas.~For the two rounds, we conducted a qualitative analysis exploring which UX requirements were described and used. Results: Our results revealed that both stakeholders have written up details of UX requirements on the artifact, however, throughout different and complementary perspectives. We also could observe that proto-personas produced by both were used on the prototyping activity. Conclusion: Our paper contributed to demonstrate that non-technical stakeholders were able to contribute to the specification of UX requirements and that proto-persona can boost such activity.
... tool support (John et al., 1999). Practitioners see a benefit in standardizing artifact models for requirements engineering, but also the need to tailor models to individual projects (Méndez Fernández and Wagner, 2015). ...
... As mentioned before, RIMs can be used to standardize RE practices, but can also be tailored to individual projects (Méndez Fernández and Wagner, 2015). Our second research question is concerned with how RIMs enable the balance of alignment and diversity in practice. ...
... Neither of the two extremes is right "for all companies, or even for all projects within any one company" (Davis, 2013). RIMs are promising to look at when examining the trade-off between diversity and alignment of teams, as they have been used to standardize RE practices, but also to allow individual adjustments according to a project's needs (Méndez Fernández and Wagner, 2015). Moreover, RIMs have been found useful to support communication between the members of multiple projects when discussing RE processes (Doerr et al., 2004). ...
In large-scale automotive companies, various requirements engineering (RE) practices are used across teams. RE practices manifest in Requirements Information Models (RIM) that define what concepts and information should be captured for requirements. Collaboration of practitioners from different parts of an organization is required to define a suitable RIM that balances support for diverse practices in individual teams with the alignment needed for a shared view and team support on system level. There exists no guidance for this challenging task. This paper presents a mixed methods study to examine the role of RIMs in balancing alignment and diversity of RE practices in four automotive companies. Our analysis is based on data from systems engineering tools, 11 semi-structured interviews, and a survey to validate findings and suggestions. We found that balancing alignment and diversity of RE practices is important to consider when defining RIMs. We further investigated enablers for this balance and actions that practitioners take to achieve it. From these factors, we derived and evaluated recommendations for managing RIMs in practice that take into account the lifecycle of requirements and allow for diverse practices across sub-disciplines in early development, while enforcing alignment of requirements that are close to release.
... tool support (John et al., 1999). Practitioners see a benefit in standardizing artifact models for requirements engineering, but also the need to tailor models to individual projects (Méndez Fernández and Wagner, 2015). ...
... As mentioned before, RIMs can be used to standardize RE practices, but can also be tailored to individual projects (Méndez Fernández and Wagner, 2015). Our second research question is concerned with how RIMs enable the balance of alignment and diversity in practice. ...
... Neither of the two extremes is right "for all companies, or even for all projects within any one company" (Davis, 2013). RIMs are promising to look at when examining the trade-off between diversity and alignment of teams, as they have been used to standardize RE practices, but also to allow individual adjustments according to a project's needs (Méndez Fernández and Wagner, 2015). Moreover, RIMs have been found useful to support communication between the members of multiple projects when discussing RE processes (Doerr et al., 2004). ...
... All up-to-date information on NaPiRE together with links to instruments used, the data, and all publications is available on the web site http://www.resurvey.org. The first run in Germany together with the overall study design was published in [13] with the detailed data and descriptive analysis available as technical report [12]. It already covered the spectrum of status quo and problems. ...
... Yet, we use them to substantiate the discussion and interpretation of the ranking of importance of the problems. The overall NaPiRE endeavor includes several procedures for checking validity, i.e., concerning the data collection and analysis phases, as described in detail in our previously published material [13]. ...
Requirements engineering (RE) is considerably different in agile development than in 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), 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.
... The number of respondents who passed verification was 69. Largescale surveys in requirement engineering areas were conducted by the NaPiRE initiative [9]. There are a set of researches in modern requirements specification techniques as User stories and other Agile-oriented methods [10,11]. ...
... This article briefly describes the questionnaire design and concentrates on its Analysis and Design section. The questionnaire basis was taken from the NaPIRE initiative [9] and reworked considering such sources as [1,3,4,14,15]. ...
The success of development and testing activities depends on the qual-ity of the requirement engineering and business analysis deliverables. The most important part of them is requirement and design specification. Requirement and design specifications are usually created based on organizational template and selected business analysis approach. These documents may include structured text, matrices, and diagrams. There are many specification and modeling tech-niques that may be used alternatively or in conjunction with others to accomplish a particular business analysis document. Business analysts should select the most appropriate techniques based on the project context, their previous experience, considering budget and time restrictions. The paper aims to analyze the current practices of requirement specification in modeling and define dependencies be-tween project attributes and techniques. We conducted a survey study involving 328 specialists from Ukrainian IT companies and a series of interviews with ex-perts to interpret the survey results. The survey results analysis allows identifying a set of statistically significant dependencies between project context and speci-fication and modeling techniques.
... Another survey suggests that only 12.7% out of (nearly) thousand software projects were successful. According to survey main reason for the software project failure was unclear and incomplete requirements [14]. These survey and reports also suggests that for successful requirement engineering, requirement elicitation phase should be carried out in such a way that all the effective requirements are gathered which lead to the successful software projects. ...
... In order to improve success rate in software developed an efficient and effective approach is needed for requirement elicitation. In Elicitation process there are number techniques available still it is difficult for requirement elicitor to decide which technique is most suited for the task [13] [14]. It is due to inability to understand the available techniques. ...
Requirement Elicitation is key activity of requirement engineering and has a strong impact on design and other phases of software development life cycle. Poor requirement engineering practices lead to project failure. A sound requirement elicitation process is the foundation for the overall quality of software product. Due to criticality and high impact of this phase on overall success and failure of projects, it is very necessary to perform the requirements elicitation activities in a perfect and specific manner. The most difficult and demanding jobs during Requirement Elicitation phase is to select appropriate and specific technique from a wide array of techniques and tools. In this paper, a new approach is proposed using an artificial neural network for selection of requirement elicitation technique from a wide variety of tools and techniques that are available. The training of Neural Network is done by back propagation algorithm. The trained and resultant network can be used as a base for selection of requirement elicitation techniques.
... Another survey suggests that only 12.7% out of (nearly) thousand software projects were successful. According to survey main reason for the software project failure was unclear and incomplete requirements [14]. These survey and reports also suggests that for successful requirement engineering, requirement elicitation phase should be carried out in such a way that all the effective requirements are gathered which lead to the successful software projects. ...
... In order to improve success rate in software developed an efficient and effective approach is needed for requirement elicitation. In Elicitation process there are number techniques available still it is difficult for requirement elicitor to decide which technique is most suited for the task [13] [14]. It is due to inability to understand the available techniques. ...
Requirement Elicitation is key activity of requirement engineering and has a strong impact on design and other phases of software development life cycle. Poor requirement engineering practices lead to project failure. A sound requirement elicitation process is the foundation for the overall quality of software product. Due to criticality and high impact of this phase on overall success and failure of projects, it is very necessary to perform the requirements elicitation activities in a perfect and specific manner. The most difficult and demanding jobs during Requirement Elicitation phase is to select appropriate and specific technique from a wide array of techniques and tools. In this paper, a new approach is proposed using an artificial neural network for selection of requirement elicitation technique from a wide variety of tools and techniques that are available. The training of Neural Network is done by back propagation algorithm. The trained and resultant network can be used as a base for selection of requirement elicitation techniques.
... Dichos inconvenientes están relacionados con requisitos incompatibles e incompletos y con el manejo inadecuado de herramientas de gestión de requisitos [18]. Daniel Méndez, investigador de NaPiRE [19], señala que la obtención, especificación y validación de requisitos precisos y apropiados para las partes interesadas, son un factor crítico de la calidad del software; no obstante, también menciona que los requisitos son altamente volatiles e inherentemente complejos por naturaleza [20]. ...
... Como resultado de esta actividad se obtuvieron 36 estudios (denominados estudios seleccionados). A paso seguido se accedió al texto completo de los estudios, los cuales fueron revisados por al menos dos investigadores y a través de una validación cruzada seleccionaron finalmente 8 estudios [20] [31], que fueron denominados estudios primarios. Con el propósito de dar respuesta a las preguntas de investigación planteadas, la información más relevante para la investigación contenida en los estudios primarios fue extraída (ver sección 4). ...
Background: Research in Requirements Engineering (RE) has increased significantly in the last few years, due to requirements are the first primary input into the software development process. However, there remain severe problems regarding requirements that even have caused the failure of several software development projects. Aim: To structure an artifact that provides a panoramic view of problems regarding the RE, its causes and the characteristics of solutions proposed. Method: We conduct the preliminary stages of a systematic mapping study (SMS). Results: From the information available on 8 primary studies we find that implicit activities of requirements engineering have been subject to an arduous research work, which has been intensified over the last years. Conclusions: Despite the importance of RE in the software development process and a significant amount of research carried out in this field; there is no a robust model to guide the practice of RE based on a vast base of empirical knowledge.
... Fourth, validate the requirements to ensure that requirements meet the needs of the stakeholders. Finally, Requirements management is the last activity to manage all requirements-related activities [4] [5]. Further, the requirements are written in natural text format, requirements should be thoroughly analyzed to generate the software requirements specifications needed to validate and verify the final product. ...
... Finally, Requirements management is the last activity to manage all requirements-related activities. [5]. ...
... The "Chaos Report" is a biannual survey conducted by the Standish Group with an overview of the failure and success rate of software projects. As the report shows, project failure often results from problems in initial tasks of the requirements engineering process, crucial to systems development (Méndez and Wagner 2015). ...
... It is also a systematic process of eliciting, understanding, analyzing, and documenting the requirements. The process is practical and systematic to ensure that the system requirements are complete, consistent, and relevant (Méndez and Wagner 2015). Moreover, it is recognized as the costliest regarding a negative impact when problems arise (Mayer et al. 2014). ...
Resilience engineering provides concepts and methods for assessing the ability of socio-technical systems to adjust their functioning before, during, or after changes or disturbances. As such, this field of study has great potential to contribute to software engineering—particularly for the requirements specification for information systems—that deals with variability, unpredictability, and adaptation in complex contexts. Despite software engineers’ efforts, the requirements phase is still challenging, especially in complex socio-technical systems. In these systems, the software must be more resilient and adaptable to deal with uncertain situations. Thus, this study aimed to investigate the contributions of resilience engineering to requirements engineering to identify software requirements for complex systems. Two experiments were performed with software professionals to produce requirements specifications in healthcare. The participants used information from the functional resonance analysis method (FRAM) compared to business process modeling notation (BPMN). Both experiments were supported by a systematic approach called MacKnight. This study indicates innovative strategies to gather resilient software requirements from FRAM models for complex systems.
... When building prediction models for software, for example, a factor analysis seems to be recommended [11], but in softer software engineering aspects it is not standard practice and many authors get survey studies published without such validation of scales (see e.g. [4,2,7]). When it comes to human factors research in software engineering, it seems to be more depending on the statistical knowledge of the author then common practice for publication, i.e. many human factors survey studies have such tests in software engineering (see e.g. ...
In this paper we describe the usefulness of statistical validation techniques for human factors survey research. We need to investigate a diversity of validity aspects when creating metrics in human factors research, and we argue that the statistical tests used in other fields to get support for reliability and construct validity in surveys, should also be applied to human factors research in software engineering more often. We also show briefly how such methods can be applied (Test-Retest, Cronbach's {\alpha}, and Exploratory Factor Analysis).
... Defects in requirements, such as ambiguities or incomplete requirements, can lead to time and cost overruns in a project [56]. Some of the issues require specific domain knowledge to be uncovered. ...
Bad requirements quality can cause expensive consequences during the software development lifecycle, especially if iterations are long and feedback comes late. %-- the faster a problem is found, the cheaper it is to fix. This makes explicit the need of a lightweight detection mechanism of requirements quality violations. We aim at a light-weight static requirements analysis approach that allows for rapid checks immediately when requirements are written down. We transfer the concept of code smells to Requirements Engineering as Requirements Smells. To evaluate the benefits and limitations, we define Requirements Smells, realize our concepts for a smell detection in a prototype called Smella and apply Smella in a series of cases provided by three industrial and a university context. The automatic detection yields an average precision of 59% at an average recall of 82% with high variation. The evaluation in practical environments indicates benefits such as an increase of the awareness of quality defects. Yet, some smells were not clearly distinguishable. Lightweight smell detection can uncover many practically relevant requirements defects in a reasonably precise way. Although some smells need to be defined more clearly, smell detection provides a helpful means to support quality assurance in Requirements Engineering, for instance, as a supplement to reviews.
... In response to this problem, we initiated the Naming the Pain in Requirements Engineering (NaPiRE) initiative 1 hosted under the umbrella of the International Software Engineering Research Network 2 . NaPiRE constitutes a globally distributed family of surveys on the state of RE practices including problems practitioners experience in RE as well as their causes and effects [4]. The resulting knowledge base shall allow us to get a better understanding about the relevance of particular problems and to establish means to mitigate problems in the long run. ...
As part of the Naming the Pain in Requirements Engineering (NaPiRE) initiative, researchers compared problems that companies in Brazil and Germany encountered during requirements engineering (RE). The key takeaway was that in RE, human interaction is necessary for eliciting and specifying high-quality requirements, regardless of country, project type, or company size.
... Asian countries took second place in the contribution, The empirical data from the selected 85 studies could not be generalized due to the uneven distribution of authors across geographic regions. Therefore, there is a need for location-based studies like that of [87] to empirically establish state-of-the-art research in most continents regarding automated RE and software engineering generally. Geographical, psychological, and sociological factors may influence how anything is interpreted and understood when described in natural language [88]. ...
Requirements Engineering (RE) has undergone several transitions over the years, from traditional methods to agile approaches emphasising increased automation. In many software development projects, requirements are expressed in natural language and embedded within large volumes of text documents. At the same time, RE activities aim to define software systems' functionalities and constraints. However, manually executing these tasks is time-consuming and prone to errors. Numerous research efforts have proposed tools and technologies for automating RE activities to address this challenge, which are documented in published works. This review aims to examine empirical evidence on automated RE and analyse its impact on the RE sub-domain and software development. To achieve our goal, we conducted a Systematic Literature Review (SLR) following established guidelines for conducting SLRs. We aimed to identify, aggregate, and analyse papers on automated RE published between 1996 and 2022. We outlined the output of the support tool, the RE phase covered, levels of automation, development approach, and evaluation approaches. We identified 85 papers that discussed automated RE from various perspectives and methodologies. The results of this review demonstrate the significance of automated RE for the software development community, which has the potential to shorten development cycles and reduce associated costs. The support tools primarily assist in generating UML models (44.7%) and other activities such as omission of steps, consistency checking, and requirement validation. The analysis phase of RE is the most widely automated phase, with 49.53% of automated tools developed for this purpose. Natural language processing technologies, particularly POS tagging and Parser, are widely employed in developing these support tools. Controlled experimental methods are the most frequently used (48.2%) for evaluating automated RE tools, while user studies are the least employed evaluation method (8.2%). This paper contributes to the existing body of knowledge by providing an updated overview of the research literature, enabling a better understanding of trends and state-of-the-art practices in automated RE for researchers and practitioners. It also paves the way for future research directions in automated requirements engineering.
... Requirements Engineering (RE) artifacts play a central role in many systems and software engineering projects. Due to that central role, the quality of RE artifacts is widely considered a success factor, both in academia, e.g. by Boehm [1] or Lawrence [2], and also by practitioners [3]. ...
[Context] The quality of requirements engineering artifacts, e.g. requirements specifications, is acknowledged to be an important success factor for projects. Therefore, many companies spend significant amounts of money to control the quality of their RE artifacts. To reduce spending and improve the RE artifact quality, methods were proposed that combine manual quality control, i.e. reviews, with automated approaches. [Problem] So far, we have seen various approaches to automatically detect certain aspects in RE artifacts. However, we still lack an overview what can and cannot be automatically detected. [Approach] Starting from an industry guideline for RE artifacts, we classify 166 existing rules for RE artifacts along various categories to discuss the share and the characteristics of those rules that can be automated. For those rules, that cannot be automated, we discuss the main reasons. [Contribution] We estimate that 53% of the 166 rules can be checked automatically either perfectly or with a good heuristic. Most rules need only simple techniques for checking. The main reason why some rules resist automation is due to imprecise definition. [Impact] By giving first estimates and analyses of automatically detectable and not automatically detectable rule violations, we aim to provide an overview of the potential of automated methods in requirements quality control.
... Our results in this domain are in accordance with those of [26] study, which states that most practitioners apply some form or another of classification system in their requirements specification work. However, Méndez et al.'s study does not provide details on what aspects of the requirements such classification systems are based on or whether they are used across different projects. ...
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.
... This article briefly describes the questionnaire design and concentrates on its Analysis and Design section. The questionnaire basis was taken from the NaPIRE initiative described in detail by Fernandez and Wagner [21,22] and reworked considering sources from Section 2. Related works. 43 questions were divided into the following categories: ...
The quality of specified and modeled requirements is critical for IT project success. A significant number of specialized techniques are used for documenting the requirements. The selection of the appropriate technique considerably influences a project plan and the success of a change as a whole. This paper aims to examine practitioners’ industrial standards and experience in the requirements specification activities and identify factors influencing the choice of specific techniques. To get the data from business analysis practitioners, we carried out a survey involving 328 specialists from Ukrainian IT companies and a series of interviews with experts. A list of specification and modelling techniques is selected based on international standards and bodies of knowledge. Project context and participants’ background influence on the probability of particular technique selection are analyzed. A set of dependencies are identified using the Chi-Square test for association and Cramer’s V. Results can be used as guidelines for building a framework for business analysis techniques selection in IT projects.
... Ela é considerada a etapa mais importante, decisiva e ao mesmo tempo mais crítica do desenvolvimento de software [Christel and Kang 1992], pois afeta todo o processo da Engenharia de Requisitos (ER). O processo da ER é formado por atividades que derivam, validam e atualizam o documento de requisitos do software [Méndez Fernández and Wagner 2015]. ...
A tarefa de elicitação de requisitos ainda é considerada crítica, principalmente quando se trata de sistemas complexos (não lineares), que necessitam de suporte tecnológico com desempenho mais resiliente. Ou seja, softwares capazes de lidar com situações de incerteza. O Método de Análise da Ressonância Funcional (FRAM), método de modelagem proveniente da Engenharia de Resiliência, é usado para representar os aspectos associados ao “trabalho como feito”, tornando mais evidente as imprevisibilidades das tarefas. Esse trabalho, como uma versão estendida de outro artigo publicado no SBSI 2021, pretende detalhar aspectos relacionados à aplicação da Design Science Research na projeção de um modelo heurístico destinado à elicitação de requisitos de software para sistemas complexos como a Saúde com suporte de uma ferramenta computacional, o ReqFRAM. Assim, espera-se mostrar com mais detalhes os passos do estudo realizado, as heurísticas propostas e suas contribuições para a Engenharia de Requisitos, à luz dos conceitos da Engenharia de Resiliência.
... Four diverse surveys were conducted related to RE practices in Germany, New Zealand, Malaysia and Australia simultaneously. In these studies they focused most practiced RE process and RE activities in the software houses of these countries [18], [19], [20],and [21] . Maturity of RE practices was checked as well as comparison of industry practices with literature was done. ...
Software Requirement Engineering (RE) has been considered as the most significant part of software development life cycle (SDLC). It impacts the overall project progress and quality of the final product. Spending insufficient amount of time and effort in requirement engineering phase can increase the cost of errors in next phases of SDLC. Many approaches and techniques have been proposed by researchers so far, but all of them have not been practiced very widely in the industry. In order to further refine and improve requirement engineering process, problems faced in contemporary practice needs to be understood. General objective of this research is to identify and analyze requirement engineering practices in Pakistani Software Industry. Survey is used to gather data from local software industry. The analysis presents how frequently a particular type of RE practice is being used by local industry experts. The ultimate goal is to suggest best practices in requirement engineering and give recommendations to upcoming researchers regarding methods and techniques in this research area.
... Os requisitos se dividem basicamente em [16]: I) funcionais (RF), que são declarações sobre as ações do software e descrevem como ele deve reagir com entradas específicas e como deve se comportar em determinadas situações; II) não funcionais (RNF), que são comportamentos ou qualidades específicas que o sistema de informação deve ter. O processo da Engenharia de Requisitos (ER) é formado por atividades que derivam, validam e atualizam o documento de requisitos do software [18]. A elicitação é a primeira tarefa do processo de requisitos e corresponde à descoberta das necessidades do software, identificação das fontes de informação, coleta de fatos e comunicação [20]. ...
Despite all efforts, the requirements elicitation task is still considered non-trivial, especially for complex (non-linear) systems. In these systems, technological support must perform more resiliently, that is, be more adaptable to deal with uncertain situations. The Resilience Engineering provides the Functional Resonance Analysis Method (FRAM) to model these systems based on a description of the actual work (Work-As-Done - WAD). Therefore, unexpected events commonly associated with variability and improvisations become more explicit with that method. Thus, a multidisciplinary approach can contribute to requirements elicitation, since FRAM models deal with variability, unpredictability, and adaptation in complex sociotechnical systems. This study applies the Design Science Research to project a heuristic model to gather information from FRAM models to elicit functional and nonfunctional requirements, showing the contributions of Resilience Engineering to Requirements Engineering to identify software requirements for complex systems.
... Acceptance or qualification testing determines whether a system satisfies its acceptance criteria, usually by check ing desired system behaviours against the customer's requirements [8], Issues in software requirements, such as ambiguity or incom plete requirements specification may influence the acceptance test ing activities. This may lead to time and cost overrun in a project [13]. Issues in a software requirement specification need to be detected as early as possible since the issue that found late in the project is more expensive than if it was found early [7]. ...
... Furthermore, we found BA13 (cultural differences) as a major barrier in the RE process in the GSD domain. In GSD, the development teams are geographically and culturally distinct [69]. The team member for different cultures hesitates to share the information [2]. ...
Abstract Software industry is adopting global software development (GSD) due to its potential to produce quality products at a lower cost. However, the GSD firms face many challenges that make development activities more complicated, especially related to the requirements engineering (RE) process. The objectives of this article are to investigate and prioritize the barriers faced by the GSD organizations during the RE process. First, we identified 17 barriers related to the RE process in the GSD projects. Next, the identified barriers were further validated with real‐world GSD practitioners using a questionnaire survey. Finally, we applied the analytical hierarchy process to prioritize the investigated barriers with respect to their significance for the RE process in the GSD domain. The results show that coordination is the most significant barrier category for the RE process in GSD projects. Lack of standard and procedure for RE in GSD, lack of synchronized communication infrastructure, and lack of mutual understanding between the overseas RE teams are also high‐ranked barriers for the RE process in GSD. The authors believe that the findings of this study will assist practitioners and researchers in developing effective strategies and plans for the successful implementation of the RE process in the GSD context.
... Incomplete, unverifiable, incorrect, and ambiguous are several examples of issues in software requirements that influence the acceptance testing of software. This may lead to overruns in project time and costs, Fernández and Wagner, (2015). The cost of bugs that found late is more expensive than if it found early. ...
Software Requirements Specification (SRS) is considered a highly critical artifact in the software development. All phases in software development are influenced by this artifact. Defects in software requirements may higher the risk of project overschedule that contributes to cost overrun of the project.Researchers have shown that finding defects in the initial software development phase is important becausethe cost of the bug is cheaper if it is fixed early. Hence, our main goal is to provide a platform for requirement engineers to produce better requirement specifications. We propose AmbiDetect, a (prototype) tool toautomatically classify ambiguous software requirements. AmbiDetect combines text mining and machine learning for ambiguous requirement specification detection. The text mining technique is used to extract classification features as well as generating the training set.AmbiDetect usesa machine learning technique to perform the ambiguous requirement specification detection. From an initial user study to validate the tool, the result indicates that the accuracy of detection is reasonably acceptable.Although AmbiDetect is an early experimental tool, we optimist that this tool can be a platform to improve SRS quality.
... Finding 1: Identified challenges are partly similar to known problems from non-Agile projects. Poor formulation of requirements and lack of traceability between artifacts are well-known problems from traditional projects [17]. Interestingly, we have also identified these two problems in our survey. ...
Background: The artifacts used in Agile software testing and the reasons why these artifacts are used are fairly well-understood. However, empirical research on how Agile test artifacts are eventually designed in practice and which quality factors make them useful for software testing remains sparse.
Aims: Our objective is two-fold. First, we identify current challenges in using test artifacts to understand why certain quality factors are
considered good or bad. Second, we build an Activity-Based Artifact Quality Model that describes what Agile test artifacts should look like.
Method: We conduct an industrial survey with 18 practitioners
from 12 companies operating in seven different domains.
Results: Our analysis reveals nine challenges and 16 factors describing the quality of six test artifacts from the perspective of Agile testers. Interestingly, we observed mostly challenges regarding language and traceability, which are well-known to occur in non-Agile projects.
Conclusions: Although Agile software testing is becoming the norm, we still have little confidence about general do’s and don’ts going beyond conventional wisdom. This study is the first to distill a list of quality factors deemed important to what can be considered as useful test artifacts.
... The SRS document contains a detailed description of the system to be built and its expected behaviour including both functional and non functional requirements [3]. Improper requirements -requirements with defects -lead to an increase in the development time and cost of the system and can be the cause of major operational failures [4]. Defected requirements typically includes quality issues and mistakes causing problems in the consequent phases of system development [5], [6]. ...
... In the vendor organisation category, we noted that SF25 (resistance management, 89%) was the most important SF for collecting pure requirements in an OSDO context. Owing to internal political factors and some personal benefits attributed to client organisations, workers and administration may not want to provide perfect information to the RE engineer, as they do not want to update the system [62]. Documentation checks are a most important activity in an RE process, though the team members may not want to allow access to some important documentation, thus eventually leading to poor requirements collection. ...
Offshore Software Development Outsourcing (OSDO) is one of the popular development paradigm in the software industry. There are number of challenges associated with OSDO including the challenges related to Requirements Engineering (RE) process. The objective of this study is to identify Success Factors (SFs) associated with RE processes in the OSDO context. A total of twenty-five SFs were identified, using Systematic Literature Review (SLR), and the identified SFs were further validated with practitioners using a questionnaire-based survey. We also examined the identified RE challenges with respect to their relevance for different organization types (client and vendor) and sizes (small, medium and large) with an aim to provide a clear understanding of the RE process and its SFs in the context of various OSDO organizations. We also conducted a comparative analysis between the SLR and questionnaire findings and the results indicate that there is a moderately positive correlation between the datasets. We believe that the findings of this study will provide a comprehensive model to help OSDO organizations assess and improve the effectiveness and efficiency of their RE activities.
... Finding 1: Identified challenges are partly similar to known problems from non-Agile projects. Poor formulation of requirements and lack of traceability between artifacts are well-known problems from traditional projects [17]. Interestingly, we have also identified these two problems in our survey. ...
Background: The artifacts used in Agile software testing and the reasons why these artifacts are used are fairly well-understood. However, empirical research on how Agile test artifacts are eventually designed in practice and which quality factors make them useful for software testing remains sparse. Aims: Our objective is two-fold. First, we identify current challenges in using test artifacts to understand why certain quality factors are considered good or bad. Second, we build an Activity-Based Artifact Quality Model that describes what Agile test artifacts should look like. Method: We conduct an industrial survey with 18 practitioners from 12 companies operating in seven different domains. Results: Our analysis reveals nine challenges and 16 factors describing the quality of six test artifacts from the perspective of Agile testers. Interestingly, we observed mostly challenges regarding language and traceability, which are well-known to occur in non-Agile projects. Conclusions: Although Agile software testing is becoming the norm, we still have little confidence about general do's and don'ts going beyond conventional wisdom. This study is the first to distill a list of quality factors deemed important to what can be considered as useful test artifacts.
... When functional requirements modeling, tacit and explicit knowledge are both needed [5,21,45,50]. Also, many researchers have yet to agree on the best methods for its management, and additionally suggest that where tacit knowledge is owned by experts in a problem domain, requirements elicitation techniques are not guaranteed to capture tacit knowledge [8,10,12,22,29,31,45,50]. ...
The research in this paper adds to the discussion linked to the challenge of capturing and modeling tacit knowledge throughout software development projects. The issue emerged when modeling functional requirements during a project for a client. However, using the design science research methodology at a particular point in the project helped to create an artifact, a functional requirements modeling technique, that resolved the issue with tacit knowledge. Accordingly, this paper includes research based upon the stages of the design science research methodology to design and test the artifact in an observable situation, empirically grounding the research undertaken. An integral component of the design science research methodology, the knowledge base, assimilated structuration and semiotic theories so that other researchers can test the validity of the artifact created. First, structuration theory helped to identify how tacit knowledge is communicated and can be understood when modeling functional requirements for new software. Second, structuration theory prescribed the application of semiotics which facilitated the development of the artifact. Additionally, following the stages of the design science research methodology and associated tasks allows the research to be reproduced in other software development contexts. As a positive outcome, using the functional requirements modeling technique created, specifically for obtaining tacit knowledge on the software development project, indicates that using such knowledge increases the likelihood of deploying software successfully.
Grounded theory (GT) has been extensively used in social studies through surveys and interviews. However, its application in software development has not been appropriately categorized, limiting its in-depth study in this field. Additionally, the qualitative analysis provided by GT is in increasing demand in software engineering, presenting a significant opportunity to further investigate this topic. This article discusses the identification and analysis of key GT elements beyond traditional data sources, such as research results, engineering artifacts, and written documents, and introduces the role of basic coding, master core category, and the theory emerging, thus showing a way to present the results of GT studies in software development. The study provides valuable insights for researchers and practitioners interested in applying GT in software development. The article also explores the crucial role of constant comparison until saturation and the challenges it presents. Additionally, the integration of Glaserian grounded theory (GGT) with systematic mapping study (SMS) is examined, resulting in a novel approach called Glaserian systematic mapping study (GSMS), which defines saturation through three equations, providing a set of components that satisfactorily categorize GT in software development. This article discusses the identification and analysis of key grounded theory (GT) elements beyond traditional data sources in the context of software development.
The principal focus of software product management is to ensure the economic success of the product, which means to prolong the product life as much as possible with modest expenditures to maximizs profits. Software product managers play an important role in the software development organization while being responsible for the strategy, business case, product roadmap, high-level requirements, product deployment (release-management), and retirement plan. This article explores the problems that affect the software product management process, their perceived frequency and perceived severity. The data were collected by a systematic literature review (5 main databases were analyzed), interviews (10 software product managers from IT companies), and surveys (89 participants). 95 software product management problems assigned nonexclusively to 7 areas were identified. 27 commonly mentioned software product management problems were evaluated for their perceived frequency and perceived severity. The problems perceived as the most frequent are: determining the true value of the product that the customer needs, strategy and priorities change frequently, technical debt, working in silos, and balancing between reactive and proactive work. In total, 95 problems have been identified which have been narrowed down to 27 problems based on their occurrence in at least 3 interviews. These selected problems were prioritized by perceived frequency and perceived severity. Some of the identified problems spanned beyond the software product management process itself, but they all affect the work of software product managers.
Effective Requirements Engineering is a crucial activity in software-intensive development projects. The human-centric working mode of Design Thinking is considered a powerful way to complement such activities when designing innovative systems. Research has already made great strides to illustrate the benefits of using Design Thinking for Requirements Engineering. However, it has remained mostly unclear how to actually realize a combination of both. In this chapter, we contribute an artifact-based model that integrates Design Thinking and Requirements Engineering for innovative software-intensive systems. Drawing from our research and project experiences, we suggest three strategies for tailoring and integrating Design Thinking and Requirements Engineering with complementary synergies.
Effective Requirements Engineering is a crucial activity in softwareintensive development projects. The human-centric working mode of Design Thinking is considered a powerful way to complement such activities when designing innovative systems. Research has already made great strides to illustrate the benefits of using Design Thinking for Requirements Engineering. However, it has remained mostly unclear how to actually realize a combination of both. In this chapter, we contribute an artifact-based model that integrates Design Thinking and Requirements Engineering for innovative software-intensive systems. Drawing from our research and project experiences, we suggest three strategies for tailoring and integrating Design Thinking and Requirements Engineering with complementary synergies.
Die Flexibilisierung von Produktionsanlagen ist notwendig, um in einem volatilen Marktumfeld erfolgreich sein zu können. Durch die Bereitstellung und Pflege geeigneter Schnittstellen und Betriebsmodi, sowie dem Umbau von Anlagen, kann auf geänderte Anforderungen an die Produktion reagiert werden. Für die Realisierung derartiger hochflexibler und rekonfigurierbarer Anlagen ist ein erhöhter Engineering- und Testaufwand notwendig. Jede zusätzliche Funktion samt aller damit verbundener Abhängigkeiten müssen vor Inbetriebnahme mehrfach von Herstellern, Integratoren und Betreibern überprüft werden. Damit der resultierende erhöhte Testaufwand auch zukünftig handhabbar bleibt, werden in dieser Veröffentlichung folgende Ansätze vorgestellt, um ein effizientes und wirkungsvolles Testen im Bereich der flexiblen Produktion zu ermöglichen: Zum einen lässt sich durch eine auf Richtlinien basierende Modularisierung von Anlagen und Komponenten der Testaufwand reduzieren. Auch sorgen Agile Teams für eine verbesserte Kommunikation zwischen Entwicklungs- und Testabteilungen. Überdies ermöglicht die Anwendung von Digitalen Zwillingen einen effektiveren Informationsaustausch zwischen den Stakeholdern und Modellbasiertes Testen ermöglicht Vorteile bei der Testautomatisierung. Alle Ansätze sind jeweils eigenständig wirksam, aber zusammengenommen ergeben sich zusätzliche Synergieeffekte.
Implementing security and privacy requirements at every level of the software development cycle is imperative for ensuring optimum usability as well as the users’ satisfaction. Software development must consider and comply effectively with the risks involved in the privacy and protection of confidential data. This research study endeavors to integrate the standards of data protection along with the Security Threat Oriented Requirements Engineering (STORE) methodology in order to recognize the potential threats to privacy requirements. The proposed extension of the STORE methodology, called the P-STORE, is validated by a case study of the Healthcare Management Software (HMS) system project. Furthermore, we have used the integrated fuzzy AHP with fuzzy TOPSIS technique for the usability assessment of different privacy requirements engineering approaches including the P-STORE methodology. The study demonstrates that the P-STORE approach has the capability to elicit more efficient privacy requirements and that it allows the software engineer to arrange privacy requirements efficaciously.
Die Medienpädagogik öffnet sich zunehmend interdisziplinären Zugängen und wird von unterschiedlichen Bereichen wie den Digital Humanities angefragt, ihre Expertise einzubringen. Dabei kennzeichnet die Digital Humanities eine intensive interdisziplinäre Zusammenarbeit und innovative wissenschaftliche Fragstellungen. Die Forschungssoftware, mit der diese innovativen Fragestellungen bearbeiten werden sollen, muss entsprechend flexibel sein, um sich mit den evolvierenden Aufgaben zu entwickeln. Dies birgt für die Softwareentwicklung in diesem Bereich vielfältige Unwägbarkeiten. Komplexitätssteigernd wirkt, dass hier nicht einfache Software für den Alltag erarbeitet werden muss. Vielmehr gilt es, digitalen Umgebungen für sich stetig weiterentwickelnde Forschungen gerecht zu werden und je nach Projektkontext unterschiedlichen Anforderungen zu genügen. Diese Anforderungen sind für Nicht-Softwareentwickler häufig nicht leicht zu verbalisieren. In diesem Beitrag stehen die interdisziplinäre Bearbeitung und Bündelung unterschiedlicher Expertisen im Vordergrund, um subjektorientierte Lösungen für solch komplexe Fragestellungen zu entwickeln. Der Beitrag diskutiert diese Themen beispielhaft anhand der interdisziplinären Projektarbeit der Medienforschung, der Medienpädagogik und der Informatik zur Softwareunterstützung digitaler Musikeditionen und somit der Verarbeitung von textuellen und nichttextuellen Daten. Hierbei steht die Methode zur Erforschung impliziten Wissens und deren Transfer für die Softwareentwicklung im Mittelpunkt der Diskussion. Daraus werden abschliessend medienpädagogische Empfehlungen für die Softwareentwicklung und für die Bildungsbedarfe in diesen Bereichen formuliert.
While being an important and often used research method, survey research has been less often discussed on a methodological level in empirical software engineering than other types of research. This chapter compiles a set of important and challenging issues in survey research based on experiences with several large-scale international surveys. The chapter covers theory building, sampling, invitation and follow-up, statistical as well as qualitative analysis of survey data and the usage of psychometrics in software engineering surveys.
Planning and managing of requirement change management (RCM) process in global software development (GSD) are a complicated task, but the RCM plays a significant role in developing the quality software within time and budget. The key aim of this study is to prioritize the factors that could positively influence the RCM program in GSD context. To achieve the study objective, the questionnaire survey study was conducted to get the feedback of the practitioners concerning the success factors of RCM in GSD context. Moreover, the fuzzy analytical hierarchy process (FAHP) was applied. The application of FAHP is novel in this research domain as it has been effectively applied previously in various other research areas, for example, supplier selection, electronics and electrical, personnel selection, and agile software development. The results of this study will provide the prioritization‐based taxonomy of RCM success factors and also contribute by introducing the novel FAHP approach in the research domain of RCM in GSD. The FAHP approach assists the practitioners to reduce the uncertainty and vague opinions of RCM experts.
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.
When it comes to designing a software process, we have experienced two major strategies. Process engineers can either opt for the strategy in which they focus on designing a process using an artefact model as backbone or, on the other hand, they can design it around activities and methods. So far, we have first studies that directly analyse benefits and shortcomings of both approaches in direct comparison to each other, without addressing the questions relevant to pro-cess engineers and which implications the selection of a particular design strategy has on the process consumption. We contribute a first controlled investigation on the perceived value of both strategies from the perspectives of process engineers and process consumers. While our results underpin the artefact-oriented design strategy to be an advantageous instrument for process engineers, process con-sumers do not evidently care about the selected design strategy. Furthermore, our first investigation performed in an academic environment provides a suitable em-pirical basis, which we can use to steer further replications and investigations in practical environments.
Requirements engineering (RE) is a key discipline in software development and several methods are available to help assess and improve RE processes. However, these methods rely on prescriptive models of RE; they do not, like other disciplines within software engineering, draw directly on stakeholder perceptions and subjective judgments. Given this backdrop, we present an empirical study in RE process assessment. Our aim was to investigate how stakeholder perceptions and process prescriptions can be combined during assessments to effectively inform RE process improvement. We first describe existing methods for RE process assessment and the role played by stakeholder perceptions and subjective judgments in the software engineering and management literature. We then present a method that combines perceptions and prescriptions in RE assessments together with an industrial case study in which the method was applied and evaluated over a three-year period at TelSoft. The data suggest that the combined method led to a comprehensive and rich assessment and it helped TelSoft consider RE as an important and integral part of the broader engineering context. This, in turn, led to improvements that combined plan-driven and adaptive principles for RE. Overall, the combined method helped TelSoft move from Level 1 to Level 2 in RE maturity, and the employees perceived the resulting engineering practices to be improved. Based on these results, we suggest that software managers and researchers combine stakeholder perceptions and process prescriptions as one way to effectively balance the specificity, comparability, and accuracy of software process assessments.
The importance of continuously improving requirements engineering (RE) has been recognised for many years. Similar to available software process improvement approaches, most RE improvement approaches focus on a normative and solution-driven assessment of companies rather than on a problem-driven RE improvement. The approaches dictate the implementation of a one-size-fits-all reference model without doing a proper problem investigation first, whereas the notion of quality factually depends on whether RE achieves company-specific goals. The approaches furthermore propagate process areas and methods, without proper awareness of the quality in the created artefacts on which the quality of many development phases rely. Little knowledge exists about how to conduct a problem-driven RE improvement that gives attention to the improvement of the artefacts. A promising solution is to start an improvement with an empirical investigation of the RE stakeholders, goals, and artefacts in the company to identify problems while abstracting from inherently complex processes. The RE improvement is then defined and implemented in joint action research workshops with the stakeholders to validate potential solutions while again concentrating on the artefacts. In this paper, we contribute an artefact-based, problem-driven RE improvement approach that emerged from a series of completed RE improvements. We discuss lessons learnt and present first result from an ongoing empirical evaluation at a German company. Our results suggest that our approach supports process engineers in a problem-driven RE improvement, but we need deeper examination of the resulting RE company standard, which is in scope of the final evaluation.
[Context and Motivation]
Based on published output in the premium RE conferences and journals, we observe a growing body of research using both quantitative and qualitative research methods to help understand which RE technique, process or tool work better in which context. Also, more and more empirical studies in RE aim at comparing and evaluating alternative techniques that are solutions to common problems. However, until now there have been few meta studies of the current state of knowledge about common practices carried out by researchers and practitioners in empirical RE. Also, surprisingly little has been published on how RE researchers perceive the usefulness of these best practices.
[Objective]
The goal of our study is to improve our understanding of what empirical practices are performed by researchers and practitioners in RE, for the purpose of understanding the extent to which the research methods of empirical software engineering are adopted in the RE community.
[Method]
We surveyed the practices that participants of the REFSQ conference have been using in their empirical research projects. The survey was part of the REFSQ 2012 Empirical Track.
[Conclusions]
We found that there are 15 commonly used practices out of a set of 27. The study has two implications: first it presents a list of practices that are commonly used in the RE community, and a list of practices that still remain to be practiced. Researchers may now make an informed decision on how to extend the practices they use in producing and executing their research designs, so that their designs get better. Second, we found that senior researchers and PhD students do not always converge in their perceptions about the usefulness of research practices. Whether this is all right and whether something needs to be done in the face of this finding remains an open question.
Requirements elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements for computer based systems. It is generally understood that requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements in the elicitation process. Requirements elicitation is a complex process involving many activities with a variety of available techniques, approaches, and tools for performing them. The relative strengths and weaknesses of these determine when each is appropriate depending on the context and situation. The objectives of this chapter are to present a comprehensive survey of important aspects of the techniques, approaches, and tools for requirements elicitation, and examine the current issues, trends, and challenges faced by researchers and practitioners in this field.
Winner of the Best Paper Award. You may download this paper from: http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDAQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.60.8950%26rep%3Drep1%26type%3Dpdf&ei=QicqUfSQD4WXhQe8sYEo&usg=AFQjCNG8N-GqV9-elalNfkDGl8SpbqPZoA&sig2=mmf9OFzExq_fTLZVP0kTiA&bvm=bv.42768644,d.ZG4&cad=rja
Because requirements engineering is recognized as critical to successful software projects we surveyed a number of software practitioners regarding theirbn software development practices during recent software projects. Relationships between requirements practices and software project outcomes enable us to better understand requirements issues and their relationship with project success. We asked three sets of questions directly related to requirements issues: 1) requirements practices, 2) the sponsor and customers/users, and 3) project management. Our respondents were from
business organizations in the U.S. and Australia, and were almost exclusively involved in in-house software development. The most significant factors from each question set were: 1) the requirements were good, 2) there was a high level of Customer/User involvement, and 3) the requirements were managed effectively. Overall, the best predictor of project success was that the requirements were good together with the requirements were managed effectively (93% of projects were predicted correctly). Our survey shows that effective project management is fundamental to effective requirements engineering.
Technology transfer to small-and medium-sized enterprises has failed to achieve its full potential in the requirements engineering (RE) field. Most companies do not know how to start their RE improvement efforts even if they are aware of the problems in this field. The state-of-the-practice survey presented in this paper gives a realistic view of how marginal technology transfer from the research community to the industry has been. It also reveals that the key development needs in industry are (1) development of own RE process adaptations, (2) RE process improvement, and (3) automation of RE practices. Directing efforts to these areas would substantially improve the chances of successful technology transfer and process improvement efforts in industry.
Software development methodologies may be described in the context of an underpinning metamodel, but the precise mechanisms
that permit them to be defined in terms of their metamodels are usually difficult to explain and do not cover all needs. For
example, it is difficult to devise a way that allows the definition of properties of the elements that compose the methodology
and, at the same time, of the entities (such as work products) created when the methodology is applied. This article introduces
a new approach to constructing metamodels and deriving methodologies from them based on the concept of powertype. It combines key advantages of other metamodelling approaches and allows the seamless integration of process, modelling and
documentational aspects of methodologies. With this approach, both methodology components and project entities can be described
directly by the same metamodel.
Experiment replication is a key component of the scientific paradigm. The purpose of replication is to verify previously observed findings. Although some Software Engineering (SE) experiments have been replicated, yet, there is still disagreement about how replications should be run in our field. With the aim of gaining a better understanding of how replications are carried out, this paper examines different replication types in other scientific disciplines. We believe that by analysing the replication types proposed in other disciplines it is possible to clarify some of the question marks still hanging over experimental SE replication.
Although software process proposals appear continuously, it is difficult to fit any of them into a given company as they are. Thus, some kind of adaptation or tailoring is always necessary. The goal of software process tailoring is to adapt an "off-the-shelf" software process to meet the needs of a specific organization or project. Although process tailoring is a mandatory activity in most software process proposals, it is usually carried out by following an ad-hoc approach, and the amount of research done on this topic to date can be considered small. This paper presents a systematic review of software process tailoring, analyzing the existing approaches towards this activity, discussing the main issues related to the problem, and providing an up-to-date and complete framework in which to position new research activities.
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.
Grounded Theory is a research method that generates theory from data and is useful for understanding how people resolve problems that are of concern to them. Although the method looks deceptively simple in concept, implementing Grounded Theory research can often be confusing in practice. Furthermore, despite many papers in the social science disciplines and nursing describing the use of Grounded Theory, there are very few examples and relevant guides for the software engineering researcher. This paper describes our experience using classical (i.e., Glaserian) Grounded Theory in a software engineering context and attempts to interpret the canons of classical Grounded Theory in a manner that is relevant to software engineers. We provide model to help the software engineering researchers interpret the often fuzzy definitions found in Grounded Theory texts and share our experience and lessons learned during our research. We summarize these lessons learned in a set of fifteen guidelines.
Requirements Engineering (RE) processes are highly volatile due to dependencies on customers' capabilities or used process models, both complicating a standardised RE process. A promising solution is given by artefactorientation that emphasises the results rather than dictating a strict development process. At such a basis one is able to incorporate domain-specific methods for producing artefacts without having to take into account the variability of process definitions. Although artefacts are known to support customisable development processes, there still is no common agreement about the structure and semantics of artefact-based methodologies. In this paper we discuss different interpretations of the term artefact considering aspects like process integration capabilities and necessities within individual project environments. We contribute a meta model for artefact-orientation that is inferred from two RE models elaborated within industrial cooperation projects of our research group. We conclude with a discussion of performed case studies and ongoing work.
[Background:] Nowadays, industries are facing the problem that the Requirements Engineering (RE) process is highly volatile, since it depends on project influences from the customer's domain or from process models used. Artefact-based approaches promise to provide guidance in the creation of consistent artefacts in volatile project environments, because these approaches concentrate on the artefacts and their dependencies, instead of prescribing processes. Yet missing, however, is empirical evidence on the advantages of applying artefact-based RE approaches in real projects. [Aim:] We developed a customisable artefact-based RE approach for the domain of business information systems. Our goal is to investigate the advantages and limitations of applying this customisable approach in an industrial context. [Method:] We conduct a case study with our artefact-based RE approach and its customisation procedure. For this, we apply it at a software development project at Siemens following the steps of the customisation procedure. We assess our approach in direct comparison with the previously used RE approach considering possible improvements in the process and in the quality of the produced artefacts. [Results:] We show that our approach is flexible enough to respond to the individual needs in the analysed project environment. Although the approach is not rated to be more productive, we find an improvement in the syntactic and the semantic quality of the created artefacts. [Conclusions:] We close a gap in the RE literature by giving empirical evidence on the advantages of artefact orientation in RE in an industrial setting.
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.
Empirically based theories are generally perceived as foundational to science. However, in many disciplines, the nature, role and even the necessity of theories remain matters for debate, particularly in young or practical disciplines such as software engineering. This article reports a systematic review of the explicit use of theory in a comprehensive set of 103 articles reporting experiments, from of a total of 5,453 articles published in major software engineering journals and conferences in the decade 1993-2002. Of the 103 articles, 24 use a total of 40 theories in various ways to explain the cause-effect relationship(s) under investigation. The majority of these use theory in the experimental design to justify research questions and hypotheses, some use theory to provide post hoc explanations of their results, and a few test or modify theory. A third of the theories are proposed by authors of the reviewed articles. The interdisciplinary nature of the theories used is greater than that of research in software engineering in general. We found that theory use and awareness of theoretical issues are present, but that theory-driven research is, as yet, not a major issue in empirical software engineering. Several articles comment explicitly on the lack of relevant theory. We call for an increased awareness of the potential benefits of involving theory, when feasible. To support software engineering researchers who wish to use theory, we show which of the reviewed articles on which topics use which theories for what purposes, as well as details of the theories' characteristics
Product quality is rapidly becoming an important competitive issue.
In this article, the author reviews and synthesizes the varying definitions of product quality arising from philosophy, economics, marketing, and operations management. He then goes on to build an eight-dimensional framework to elaborate on these definitions. Using this framework, he addresses the empirical relationships between quality and variables such as price, advertising, market share, cost, and profitability.
This is a highly practical book which introduces the whole range of grounded theory approaches. Unlike most existing books in this area, which are written from a particular philosophical standpoint, this text provides a comprehensive description of the strategies and techniques employed in this methodology.
Birks and Mills accessible and highly-readable text is driven by practical case examples throughout to help the reader get to grips with the process of doing grounded theory analysis for themselves. The book deploys a variety of educational activities to guide readers through both the principles and the application of grounded theory, making this an ideal starter text for those new to the approach.
This is an ideal first introduction to grounded theory for any student or researcher looking to use grounded theory approaches in their analysis for the first time.
Requirements standards and textbooks typically classify require-ments into functional requirements on the one hand and attributes or non-func-tional requirements on the other hand. In this classification, requirements given in terms of required operations and/or data are considered to be functional, while performance requirements and quality requirements (such as require-ments about security, reliability, maintainability, etc.) are classified as non-functional. In this paper, we present arguments why this notion of non-functional require-ments is flawed and present a new classification of requirements which is based on four facets: kind (e.g. function, performance, or constraint), representation (e.g. operational, quantitative or qualitative), satisfaction (hard or soft), and role (e.g. prescriptive or assumptive). We define the facets, discuss typical combi-nations of facets and argue why such a faceted classification of requirements is better than the traditional notion of functional and non-functional requirements.
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.
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.
Early inspections of software requirements specifications (SRS) are known to be an effective and cost-efficient quality assurance technique. However, inspections are often applied with the underlying assumption that they work equally well to assess all kinds of quality attributes of SRS. Little work has yet been done to validate this assumption. At Capgemini sd&m, we set up an inspection technique to assess SRS, the so called ldquospecification quality gaterdquo (QG-Spec). The QG-Spec has been applied to a series of large scale commercial projects. In this paper we present our lessons learned and discuss, which quality attributes are effectively assessed by means of the QG-Spec - and which are not. We argue that our results can be generalized to other existing inspection techniques. We came to the conclusion that inspections have to be carefully balanced with techniques for constructive quality assurance in order to economically arrive at high quality SRS.
This paper explores why organizations do not adopt CMMI (Capability Maturity Model Integration), by analysing two months of sales data collected by an Australian company selling CMMI appraisal and improvement services. The most frequent reasons given by organizations were: the organization was small; the services were too costly, the organization had no time, and the organization was using another SPI approach. Overall, we found small organizations not adopting CMMI tend to say that adopting it would be infeasible, but do not say it would be unbeneficial. We comment on the significance of our findings and research method for SPI research.
Software process improvement (SPI) is challenging, particularly for small and medium sized enterprises. Most existing SPI frameworks are either too expensive to deploy, or do not take an organizations’ specific needs into consideration. There is a need for light weight SPI frameworks that enable practitioners to base improvement efforts on the issues that are the most critical for the specific organization.This paper presents a step-by-step guide to process assessment and improvement planning using improvement framework utilizing light weight assessment and improvement planning (iFLAP), aimed at practitioners undertaking SPI initiatives. In addition to the guide itself the industrial application of iFLAP is shown through two industrial cases. iFLAP is a packaged improvement framework, containing both assessment and improvement planning capabilities, explicitly developed to be light weight in nature. Assessment is performed by eliciting improvements issues based on the organization’s experience and knowledge. The findings are validated through triangulation utilizing multiple data sources. iFLAP actively involves practitioners in prioritizing improvement issues and identifying dependencies between them in order to package improvements, and thus establish a, for the organization, realistic improvement plan. The two cases of iFLAP application in industry are presented together with lessons learned in order to exemplify actual use of the framework as well as challenges encountered.
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.
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.
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.
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.
Requirements engineering is an important component of effective software engineering, yet more research is needed to demonstrate the benefits to development organizations. While the existing literature suggests that effective requirements engineering can lead to improved productivity, quality, and risk management, there is little evidence to support this. We present empirical evidence showing how requirements engineering practice relates to these claims. This evidence was collected over the course of a 30-month case study of a large software development project undergoing requirements process improvement. Our findings add to the scarce evidence on RE payoffs and, more importantly, represent an in-depth explanation of the role of requirements engineering processes in contributing to these benefits. In particular, the results of our case study show that an effective requirements process at the beginning of the project had positive outcomes throughout the project lifecycle, improving the efficacy of other project processes, ultimately leading to improvements in project negotiation, project planning, and managing feature creep, testing, defects, rework, and product quality. Finally, we consider the role collaboration had in producing the effects we observed and the implications of this work to both research and practice.
Most writing on sociological method has been concerned with how accurate facts can be obtained and how theory can thereby be more rigorously tested. In The Discovery of Grounded Theory, Barney Glaser and Anselm Strauss address the equally Important enterprise of how the discovery of theory from data--systematically obtained and analyzed in social research--can be furthered. The discovery of theory from data--grounded theory--is a major task confronting sociology, for such a theory fits empirical situations, and is understandable to sociologists and laymen alike. Most important, it provides relevant predictions, explanations, interpretations, and applications. In Part I of the book, "Generation Theory by Comparative Analysis," the authors present a strategy whereby sociologists can facilitate the discovery of grounded theory, both substantive and formal. This strategy involves the systematic choice and study of several comparison groups. In Part II, The Flexible Use of Data," the generation of theory from qualitative, especially documentary, and quantitative data Is considered. In Part III, "Implications of Grounded Theory," Glaser and Strauss examine the credibility of grounded theory. The Discovery of Grounded Theory is directed toward improving social scientists' capacity for generating theory that will be relevant to their research. While aimed primarily at sociologists, it will be useful to anyone Interested In studying social phenomena--political, educational, economic, industrial-- especially If their studies are based on qualitative data.
Requirements engineers can make use of a great many techniques to elicit user needs. However, there is no comprehensive practica! guide on how to select the best techniques for a particular contextúa! situation within a software development project. We propose a framework to support developer decisión making on which are the best elicitation techniques for the project at hand. Our framework identifies which elicitation technique responds better to certain project features.
Although the term 'non-functional requirement' has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. On the other hand, there is a unanimous consensus that non-functional requirements are important and can be critical for the success of a project. This paper surveys the existing definitions of the term, highlights and discusses the problems with the current definitions, and contributes concepts for overcoming these problems.
Numerous treatises exist that define appropriate qualities that
should be exhibited by a well written software requirements
specification (SRS). In most cases these are vaguely defined. The paper
explores thoroughly the concept of quality in an SRS and defines
attributes that contribute to that quality. Techniques for measuring
these attributes are suggested
Little contemporary data exists for document actual practices of software professionals for software requirements elicitation, requirements specification, document development, and specification validation. This exploratory survey and its quantitative results offer opportunities for further interpretation and comparison.
High-profile disasters and the ensuing debates in the press are alerting more people to the crucial nature of software quality in their everyday lives. This should prompt software professionals to take a second look at how they define software quality. In this task of assessing 'adequate' quality in a software product, context is important. Errors tolerated in word-processing software may not be acceptable in control software for a nuclear power plant. Thus, the meanings of 'safety-critical' and 'mission-critical' must be reexamined in the context of software's contribution to the larger functionality and quality of products and businesses. At the same time, software professionals must ask themselves who is responsible for setting quality goals, and make sure they are achieved.
It is argued that, in general, requirements engineering produces one large document, written in a natural language, that few people bother to read. Projects that do read and follow the document often build systems that do not satisfy needs. The reasons for the current state of the practice are listed. Research areas that have significant payoff potential, including improving natural-language specifications, rapid prototyping and requirements animation, requirements clustering, requirements-based testing, computer-aided requirements engineering, requirements reuse, research into methods, knowledge engineering, formal methods, and a unified framework, are outlined.< >
Requirements traceability is intended to ensure continued alignment between stakeholder requirements and various outputs of the system development process. To be useful, traces must be organized according to some modeling framework. Indeed, several such frameworks have been proposed, mostly based on theoretical considerations or analysis of other literature. This paper, in contrast, follows an empirical approach. Focus groups and interviews conducted in 26 major software development organizations demonstrate a wide range of traceability practices with distinct low-end and high-end users of traceability. From these observations, reference models comprising the most important kinds of traceability links for various development tasks have been synthesized. The resulting models have been validated in case studies and are incorporated in a number of traceability tools. A detailed case study on the use of the models is presented. Four kinds of traceability link types are identified and critical issues that must be resolved for implementing each type and potential solutions are discussed. Implications for the design of next-generation traceability methods and tools are discussed and illustrated
While empirical studies in software engineering are beginning to
gain recognition in the research community, this subarea is also
entering a new level of maturity by beginning to address the human
aspects of software development. This added focus has added a new layer
of complexity to an already challenging area of research. Along with new
research questions, new research methods are needed to study
nontechnical aspects of software engineering. In many other disciplines,
qualitative research methods have been developed and are commonly used
to handle the complexity of issues involving human behaviour. The paper
presents several qualitative methods for data collection and analysis
and describes them in terms of how they might be incorporated into
empirical studies of software engineering, in particular how they might
be combined with quantitative methods. To illustrate this use of
qualitative methods, examples from real software engineering studies are
used throughout
Success – Erfolgs-und Misserfolgsfaktoren bei der Durchführung von Hard-und Softwareentwicklungsprojekten in Deutschland
- R Buschermöhle
- H Eekhoff
- B Josko
R. Buschermöhle, H. Eekhoff, B. Josko, Success – Erfolgs-und Misserfolgsfaktoren bei der Durchführung von Hard-und Softwareentwicklungsprojekten in Deutschland, ISBN-13 978-3-8142-2035-2, BIS-Verlag der Carl von Ossietzky Universität Oldenburg, 2006.