Requirements Defects over a Project Lifetime: An Empirical Analysis of Defect Data from a 5-Year Automotive Project at Bosch

Langenfeld, Vincent; Post, Amalinda; Podelski, Andreas

doi:10.1007/978-3-319-30282-9_10

Cited by 6 publications

(8 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such common defect types existing in the literature occurs in the studies of Anda and Sjøberg (2002;Belgamo et al, 2005;Mello et al, 2010;Alshazly et al, 2014;Saito et al, 2014;Naveed and Ikram, 2015;Langenfeld et al, 2016). The Lopes et al (2015) is another study (non-evidenced) that also addresses the Engineering Requirements domain and such defect types.…”

Section: Research Question 1 (Rq1a and Rq1b)mentioning

confidence: 97%

“…Continue Felderer et al (2014) On the role of defect taxonomy types for testin 2014 IEEE Xplore requirements: Results of a controlled experiment Rodriguez et al (2014) Preliminary comparison of techniques for dealing with 2014 ACM Digital Library imbalance in software defect prediction Femmer et al (2014) Rapid requirements checks with requirements smells: 2014 ACM Digital Library Two case studies Yusop et al (2016) Reporting usability defects: Do reporters report what 2016 ACM Digital Library software developers need? Cavezza et al (2014) Reproducibility of environment-dependent software 2014 IEEE Xplore failures: An experience report Langenfeld et al (2016) Requirements defects over a project lifetime: An 2016 Compendex SpringerLink empirical analysis of defect data from a 5-year automotive project at bosch Saito et al (2014) RISDM: A requirements inspection systems design 2014 IEEE Xplore methodology -perspective-based design of the pragmatic quality model and question set to SRS Travassos (2014) Software defects: Stay away from them. Do inspections!…”

Section: Data Sources X Rqs X Research Typesmentioning

confidence: 99%

“…10. Answering RQ1 based on empirical evidence of final set of selected studies per defect types and environments/domains (Filter #3) Langenfeld et al (2016) identified nine defect sources taking in to account requirements defects analyzed 588 requirements reported on an automotive project at Bosch. The most costly and common defect types are incomplete and inconsistency according to refined IEEE 830 standard (IEEE, 1998a The Object Oriented Design UML Model domain contains 3 studies.…”

Section: Research Question 1 (Rq1a and Rq1b)mentioning

confidence: 99%

“…In summary, the studies presented in this section answered RQ1 and provided defect types taking into account by software inspection techniques, encompassing studies such as: (i) new adapted taxonomies for detect defect types and different artifacts (Anda and Sjøberg, 2002;Travassos et al, 1999); (ii) new inspection techniques evaluated by experiments (e.g., TUCCA (Belgamo et al, 2005), SPLIT (Cunha et al 2012), FMCheck (Mello et al, 2012), PVMCheck (Teixeira et al, 2015;SmartyCheck (Geraldi et al, 2015), AGI (Rocha et al, 2015) and MoLVERIC (Lopes et al, 2015); (iii) experiments that presented defect types based on requirements engineering and compared inspection techniques (Alshazly et al, 2014;Kasubuchi et al, 2015;Langenfeld et al, 2016); and (iv) an overview of existing defect types by Travassos (2014) and emphasis on failures by Munson et al (2006). Figure 11 presents the results obtained that answered RQ2 with regard to which inspection techniques/approaches provide evidence of defect types and has documented evaluation results.…”

Section: Research Question 1 (Rq1a and Rq1b)mentioning

confidence: 99%

See 3 more Smart Citations

Defect Types and Software Inspection Techniques: A Systematic Mapping Study

OliveiraJr¹,

Geraldi²

2017

Journal of Computer Science

View full text Add to dashboard Cite

Software inspection has been used to guarantee and control the quality of products by detecting defects, which can be spread out throughout the entire software life cycle. Therefore, the main premise is to identify and reduce the number of defect types in software artifacts during inspections. This work focuses on providing an up to dated overview of existing defects in the context of software inspection techniques. A systematic mapping was carried out, from which 2096 primary studies were retrieved and 32 were final selected. From the analysis, classification and aggregation of the retrieved studies, important different defect types were identified. Most studies encompass defect types by means of experiments and proposed techniques and approaches. Thus, as a main result, the identification of several different studies with distinct proposals concerned on defect types is evident. Although researchers have conducted studies over time, a general pattern on the detection of defects could not be established. Therefore, the scenario in which this study was carried out provides researchers with the capability of conducting further research in a motivating and challenging research topic, as well as practitioners with the adoption of empirically evaluated inspection techniques and respective defect types.

show abstract

Section: Research Question 1 (Rq1a and Rq1b)mentioning

confidence: 97%

Section: Data Sources X Rqs X Research Typesmentioning

confidence: 99%

Section: Research Question 1 (Rq1a and Rq1b)mentioning

confidence: 99%

Section: Research Question 1 (Rq1a and Rq1b)mentioning

confidence: 99%

See 2 more Smart Citations

Defect Types and Software Inspection Techniques: A Systematic Mapping Study

OliveiraJr¹,

Geraldi²

2017

Journal of Computer Science

View full text Add to dashboard Cite

show abstract

“…For example, at Mercedes-Benz, the size of a building block specification varies from 60 to 2,000 pages and prescribes between 1,000 and 50,000 requirements (Houdek, 2010). Langenfeld et al (2016) report that, at Bosch, the project to develop a commercial DC-to-DC converter for a mild hybrid vehicle required more than 10,000 requirements. At Sony Ericsson, the total volume of market and platform system requirements exceeds 10,000 (Regnell et al, 2008).…”

Section: Problemmentioning

confidence: 99%

Requirement mining for model-based product design

Croué¹,

Véron

Segonds

et al. 2016

IJPLM

View full text Add to dashboard Cite

PLM software applications should enable engineers to develop and manage requirements throughout the product's lifecycle. However, PLM activities of the beginning-of-life and end-of-life of a product mainly deal with a fastidious document-based approach. Indeed, requirements are scattered in many different prescriptive documents (reports, specifications, standards, regulations, etc.) that make the feeding of a requirements management tool laborious. Our contribution is two-fold. First, we propose a natural language processing (NLP) pipeline to extract requirements from prescriptive documents. Second, we show how machine learning techniques can be used to develop a text classifier that will automatically classify requirements into disciplines. Both contributions support companies willing to feed a requirements management tool from prescriptive documents. The NLP experiment shows an average precision of 0.86 and an average recall of 0.95, whereas the SVM requirements classifier outperforms that of naive Bayes with a 76% accuracy rate.Keywords: requirements; unstructured; extraction; classification; natural language processing; NLP; supervised learning; machine learning. 306 R. Pinquié et al.Reference to this paper should be made as follows: Pinquié, R., Véron, R., Segonds, F. and Croué, N. (2016) Frédéric Segonds is an Assistant Professor at Arts et Metiers ParisTech and member of the Product Design and Innovation Laboratory (LCPI). His research interests focus on the early stages of design collaboration, optimisation and collaborative design. This area includes the integration of stakeholders' core competences into the early stages of design, and providing methodologies and tools to support early product design.Nicolas Croué is the Solutions and Consulting Director for the company Keonys and has responsibility for developing business and technical activities in a range of domains including simulation, systems engineering, search-based applications, business intelligence and manufacturing so as to develop solutions for the factory of the future. After graduating from the ESILV in Mechanical and Systems Engineering, he successfully worked for the Petroleum French Institute, SAMTECH and LMS and became an expert in systems engineering. This paper is a revised and expanded version of a paper entitled 'Natural language processing of requirements for model-based product design with ENOVIA/CATIA

show abstract

Automotive Software Development

Staron

2020

Automotive Software Architectures

View full text Add to dashboard Cite

Requirements Defects over a Project Lifetime: An Empirical Analysis of Defect Data from a 5-Year Automotive Project at Bosch

Cited by 6 publications

References 9 publications

Defect Types and Software Inspection Techniques: A Systematic Mapping Study

Defect Types and Software Inspection Techniques: A Systematic Mapping Study

Requirement mining for model-based product design

Automotive Software Development

Contact Info

Product

Resources

About