A framework for software requirement ambiguity avoidance

This research deals with software requirements ambiguity problems. Among these are incomplete, incorrect, improper, inaccurate and unambiguous requirements. Interestingly, published material related to Software Requirements Specifications (SRS) problems discusses ambiguity as one of the most conversed problems. This paper proposes a Software Requirement Ambiguity Avoidance Framework (SRAAF) to assist and support requirement engineers to write unambiguous requirements, by selecting correct elicitation technique based on the evaluation of various attributes and by applying the W6H technique. We explored existing theories and the outcomes of experimental research to construct the framework. On the basis of existing and inferred knowledge, we tried to justify proposed frameworks components. Our selection process focuses on various situational attributes. We added various situational attributes related to project, stakeholders and requirement engineer for the selection process. Newly devised approach chooses techniques other than traditional techniques or most common techniques and deals with ambiguity to capture the correct requirements information from stakeholders. The framework will be able to address the selection and ambiguity issues in a more effective way and can handle vagueness. New evidence related to attributes and adequacy matrix can be easily added to the framework without any inconvenience

Which Requirements Artifact Quality Defects are Automatically Detectable? A Case Study

[Context:] The quality of requirements engineeringartifacts, e.g. requirements specifications, is acknowledged tobe an important success factor for projects. Therefore, manycompanies spend significant amounts of money to control thequality of their RE artifacts. To reduce spending and improvethe RE artifact quality, methods were proposed that combinemanual quality control, i.e. reviews, with automated approaches.[Problem:] So far, we have seen various approaches to auto-matically detect certain aspects in RE artifacts. However, westill lack an overview what can and cannot be automaticallydetected. [Approach:] Starting from an industry guideline forRE artifacts, we classify 166 existing rules for RE artifacts alongvarious categories to discuss the share and the characteristics ofthose rules that can be automated. For those rules, that cannotbe automated, we discuss the main reasons. [Contribution:] Weestimate that 53% of the 166 rules can be checked automaticallyeither perfectly or with a good heuristic. Most rules need onlysimple techniques for checking. The main reason why some rulesresist automation is due to imprecise definition. [Impact:] Bygiving first estimates and analyses of automatically detectable andnot automatically detectable rule violations, we aim to provide anoverview of the potential of automated methods in requirementsquality control