Rapid requirements checks with requirements smells: two case studies

Abstract

Bad requirements quality can have 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.We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard.We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts.While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.

Improving agile requirements: the Quality User Story framework and tool

“…Their proposed light-weight approach uses POStagging, morphological analysis, and dictionaries to detect linguistic errors in requirements. In an evaluation with industry experts, they obtained positive feedback despite the inability to fulfill the Perfect Recall Condition [16].…”

Defect Types and Software Inspection Techniques: A Systematic Mapping Study

“…2014 IEEE Xplore Table 3. 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.…”

Analysis of Natural Language Scenarios

“…183 Table 35 -Analysis of Correctness using the C&L -Lua. 184 Table 36 -Characteristics of the Admission System Case Study 186 Table 52 -Quality Indicators of ARM (Wilson et al, 1997) 224 Table 53 -Expressiveness Quality Model of QuARS (Gnesi et al, 2005) 224 Table 54 -Ambiguity Indicators of SRRE (Tjong, 2008) 225 Table 55 -Requirements language criteria (IEEE, 2011;Femmer et al, 2014) 225 Table 56 -Potentially problematic constructs (from Berry et al, 2012) 225 Table 57 -Quality User Story Framework (Lucassen et al, 2015) 226 Table 58 -Taxonomy of defects in use case models (Anda and Sjoberg, 2002) 226 Table 59 -Scenario Checklist (Leite et al, 2000;Leite et al, 2005) 227 (Sinha et al, 2010) 230 Table 63 -Common use case defects (Liu et al, 2014) 230 Table 64 -Consistency and Completeness in CMPN (Lee et al,1998) 230 Table 65 -Faults Detected by Time Petri-Nets (Lee et al, 2001) 231 Table 66 -Use Case Defect Classification (Denger et al, 2005) 231 Table 67 -Properties of UC-LTSs (Sinnig et al, 2009) 231 Table 68 -Properties of Timed and Controlled Petri-Nets (Zhao and Duan, 2009) 231 Table 69 -Properties of Reactive Petri-Nets (Somé, 2010) 231…”

“…avoid ambiguous adverbs, vague pronouns, subjective language, and so on). Some researches classify these "don'ts" as indicators or smells of ambiguity (Wilson et al, 1997;Gnesi et al, 2005;Tjong, 2008;Femmer et al, 2014).…”

“…In addition to checking template conformance, they use NLP for detecting and warning about several potentially problematic constructs, also called requirements smells (Femmer et al, 2014), that may be signs of vagueness or ambiguity in requirements statements. Table 57 in Appendix 2) to assess the quality of user stories (conform to the format of Cohn, 2004).…”