text: Abstract Bad requirements quality can cause expensive consequences during the software development lifecycle, especially if iterations are long and feedback comes late. 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.
  @cite_61: Requirements engineering, the first phase of any software development project, is the Achilles' heel of the whole development process, as requirements documents are often inconsistent and incomplete. In industrial requirements documents natural language is the main presentation means. In such documents the system behavior is specified in the form of use cases and their scenarios, written as a sequence of sentences in natural language. For the authors of requirements documents some facts are so obvious that they forget to mention them. This surely causes problems for the requirements analyst. Missing information manifests itself, for example, in sentences in passive voice: such sentences just say that some action is performed, but they do not say who performs the action. In the case of requirement analysis this poses a serious problem, as in every real system there is an actor for every performed action. There already exists an approach able to guess missing actors and actions. However, the existing approach is able to handle sentences containing exactly one verb only. The approach presented in this paper extends the existing one by treatment of compound sentences and passive voice. Feasibility of the presented approach to the treatment of passive and conjunctions was confirmed in a case study.
  @cite_35: Use cases are a popular way of specifying functional requirements of computer-based systems. Each use case contains a sequence of steps which are described with a natural language. Use cases, as any other description of functional requirements, must go through a review process to check their quality. The problem is that such reviews are time consuming. Moreover, effectiveness of a review depends on quality of the submitted document - if a document contains many easy-to-detect defects, then reviewers tend to find those simple defects and they feel exempted from working hard to detect difficult defects. To solve the problem it is proposed to augment a requirements management tool with a detector that would find easy-to-detect defects automatically.
  @cite_67: User requirements are usually written in textual form. Dealing with natural language textual specifications is complex. Analysts 1 have to cover all aspects of the requirements engineering process when working with the customer, such as work flows, psychological issues, and linguistic problems. We show how analysts can be supported during requirements elicitation and documentation. We present an approach to improve natural language requirements specifications using ontologies. We demonstrate by several examples from real requirements how an ontological reasoner called RESI 2 can uncover gaps, inaccuracies, ambiguities and ask the user to clarify them. In many cases, it supports the analyst by giving a small number of reasonable suggestions to choose from. The implementation of RESI is currently in progress.
  @cite_26: 
  @cite_8: [Context and motivation] Ambiguous requirements are often seen as a cause for project failure, however there is little empirical data to support this claim. [Question problem] In this research we study the effect of a highly ambiguous requirements document on project success. [Principal ideas results] The studied project was a complex data processing system that took about 21 man year to develop. First, we determined the level of ambiguity by three independent tests. Next, we did a root cause analysis on a selection of the main issues to establish if ambiguous requirements were a significant cause. Surprisingly, this case study shows that only one of the examined failures was caused by ambiguous requirements. Both the independent test team and the third party development team found ways to cope with the high level of ambiguity. For the development team this required a substantial investment to clarify requirements. [Contribution] The main contributions of this paper are the counterintuitive findings, the collected empirical data and the method used to collect these data.
  @cite_58: Requirements engineering can solve and cause many problems in a software development cycle. The difficulties in understanding and eliciting the desired functionality from the customer and then delivering the correct implementation of a software system lead to delays, mistakes, and high costs. Working with requirements means handling incomplete or faulty textual specifications. It is vital for a project to fully understand the purpose and the functionality of a software. The earlier specifications are corrected and improved, the better. We created a tool called RESI to support requirement analysts working with textual specifications. RESI checks for linguistic defects [1, 2] in specifications and offers a dialog-system which makes suggestions to improve the text. It points out to the user which parts of the specification are ambiguous, faulty or inaccurate and therefore need to be changed. For this task, RESI needs additional semantic information which is inherent to natural language specifications. It receives this information by utilizing ontologies.
  @cite_44: Abstract—Working with requirements means dealing with problems related to incomplete or faulty textual specifications. Specifications are created in various types and combinations such as models, drawings, and textual documents. The information gap between the specification and the implementation of any (software) system leads to delays, mistakes, and high costs due to problems in the production stages. Therefore, the earlier specifications are corrected and improved, the better. We providea tool called RESI to support analysts while working with textual specifications. RESI considers many of the directives to be followed when processing customer specifications. It offers a dialog-system which makes suggestions and inquires the user when parts of the specification are ambiguous, faulty or inaccurate. RESI utilizes various ontologies to discover such problems and to deliver common sense solutions.
  @cite_74: 
  @cite_16: This paper proposes a two-step approach to identifying ambiguities in natural language (NL) requirements specifications (RSs). In the first step, a tool would apply a set of ambiguity measures to a RS in order to identify potentially ambiguous sentences in the RS. In the second step, another tool would show what specifically is potentially ambiguous about each potentially ambiguous sentence. The final decision of ambiguity remains with the human users of the tools. The paper describes several requirements-identification experiments with several small NL RSs using four prototypes of the first tool based on linguistic instruments and resources of different complexity and a manual mock-up of the second tool.
  @cite_12: The complexity of today's software systems is constantly increasing. As a result, requirements for these systems become more comprehensive and complicated. In this setting, requirements engineers struggle to capture consistent and complete requirements of high quality. We propose a feedback-centric requirements editor to help analysts controlling the information overload. Our HeRA tool provides analysts with important data from various feedback facilities. The feedback is directly given based on the input to the editor. On the one hand, it is based on heuristic rules, on the other hand, on automatically derived models. Thus, when new requirements are added, the analyst gets important information on how consistent these requirements are with the existing ones.
summary: The remaining approaches listed in Table aim at detecting ambiguities in unconstraint natural language. Since the quality defects detected by the approaches by @cite_35 , Kof @cite_61 , HeRA by @cite_74 @cite_12 , @cite_16 , RESI by K " @cite_67 @cite_58 @cite_44 , and Alpino by @cite_8 are not the ones discussed in ISO 29148 and since we could not find an evaluation of precision and recall of these approaches, we omit discussing these approaches in-depth here. An analysis of what these approaches focus on in detail as well as their evaluation can be found in short in Table and in full length in our supplementary material online @cite_26 . In the following, we first report on those publications that focus on criteria different from ISO 29148, but which report precision or recall. Afterwards, we describe publications that aim at detecting quality violations of ISO 29148 (see Table ).