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_47: Use-cases perform an important role in capturing and analys-ing software requirements in the IT industry. A number of guidelines have been proposed in the literature on how to write use-cases. Structural defects can occur when use-cases are written without following such guidelines. We develop a taxonomy of structural defects and analyse a sample of 360 industrial use-cases to understand the nature of defects in them. Our sample comes from both client-based projects and in-house projects. The results show that, compared to a sample of theoretical use-cases that follow Cockburn's guidelines, industrial use-cases on the average exhibit defects such as complex structures, lack of customer focus and missing actors. Given the shortage of analysis of real industry samples, our results make a significant contribution towards the understanding of the strengths and weaknesses in industrial use-cases in terms of structural defects. The results will be useful for industry practitioners in adopting use-case modelling standards to reduce the defects as well as for software engineering researchers to explore the reasons for such differences between the theory and the practice in use-case modelling.
  @cite_22: 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. >
  @cite_15: Because defects constitute an unavoidable aspect of software development, discovering and removing them early is crucial. Overlooked defects (like faults in the software system requirements, design, or code) propagate to subsequent development phases where detecting and correcting them becomes more difficult. At best, developers will eventually catch the defects, but at the expense of schedule delays and additional product-development costs. At worst, the defects will remain, and customers will receive a faulty product. The authors explain their perspective based reading (PBR) technique that provides a set of procedures to help developers solve software requirements inspection problems. PBR reviewers stand in for specific stakeholders in the document to verify the quality of requirements specifications. The authors show how PBR leads to improved defect detection rates for both individual reviewers and review teams working with unfamiliar application domains.
  @cite_70: One of the main tasks of requirements engineering (RE) is the creation of a requirements document that precisely, consistently, and completely describes the functional and non-functional properties of the system to be built. At some point during the RE process, the requirements are written down using a natural language or a requirements specification language. On one hand, natural language is flexible, universal, and wide-spread. On the other hand, natural language requirements are recognized widely as being incomplete, inconsistent, and inherently ambiguous. Semi-formal and formal requirements specification techniques, such as UML [13] or SCR [5], have been proposed to overcome these deficiencies. Completeness and consistency of these specifications can be tackled to some degree mechanically by tools. However, as a recent study shows, ambiguity rarely surfaces during the development of a requirements model [10]. Thus, since a requirements specification technique enforces precision, the resulting requirements model becomes unambiguously wrong. In this paper, we show how to detect ambiguities in natural language requirements using a checklist. We distinguish between linguistic and RE-specific ambiguities. Linguistic ambiguities are those ambiguities that are usually discussed in RE textbooks such as ambiguous pronoun references. RE-specific ambiguities occur with respect to the RE context, which includes the application domain and the system domain. For example, the requirement (1) If the bank customer maintains a minimum balance in his or her checking account, there is no monthly service charge. is ambiguous not because of its linguistic representation, but because of the operational environment and application domain. In the requirements documents that we have investigated, RE-specific ambiguities account for the majority of ambiguities, while pure linguistic ambiguities played a less significant role. In this paper, we present also an approach that allows identifying types of RE-specific ambiguity from a metamodel, e.g., of a requirements specification technique. Based on the identified types of ambiguity, we have developed an improved inspection technique for natural language requirements on the basis of checklists and scenario-based reading.
  @cite_19: 
  @cite_43: 
  @cite_59: A use case model describes the functional requirements of a software system and is used as input to several activities in a software development project. The quality of the use case model therefore has an important impact on the quality of the resulting software product. Software inspection is regarded as one of the most efficient methods for verifying software documents. There are inspection techniques for most documents produced in a software development project, but no comprehensive inspection technique exists for use case models. This paper presents a taxonomy of typical defects in use case models and proposes a checklist-based inspection technique for detecting such defects. This inspection technique was evaluated in two studies with undergraduate students as subjects. The results from the evaluations indicate that inspections are useful for detecting defects in use case models and motivate further studies to improve the proposed inspection technique.
  @cite_50: Natural language is the most used representation for stating requirements on computer-based systems in industry. However, natural language is inherently ambiguous. Customers and software developers can disagree on the interpretation of a requirement without being aware of this fact. This disagreement can result in disastrous software failures. We argue that ambiguity is a more complex phenomenon than is often recognized in the literature. While inconsistencies and some types of incompleteness can be mechanically detected in formal specifications, ambiguities in informal specicifications often result in incorrect formal specifications. These misinterpretations can be detected only by execution or inspection of the formal specification. We suggest an inspection technique for detecting ambiguities in informal requirement documents before formal specifications are produced in order to avoid misinterpretations, rather than searching for them afterwards. We show how this technique can be tailored to different project contexts with the help of metamodels to increase its effectiveness. Finally, we report on experimental validation of the technique.
  @cite_46: In most current industrial software engineering projects, the majority of requirements documents are written almost entirely in natural language. However, specifying the requirements in natural language has one major drawback, namely the inherent imprecision, i.e., ambiguity, incompleteness, and inaccuracy, of natural language. Since the requirements document forms the basis of the whole development process, such defects can have severe consequences for the whole project. Therefore, it is important to deal with these defects in a requirements specification right from the start. We present an approach for reducing the problem of imprecision in natural language requirements specifications with the use of natural language patterns, which allow formulating requirements sentences in a less ambiguous, more complete, and more accurate way. To ensure the applicability of our approach we based our patterns on a metamodel for requirements statements for embedded systems. With this metamodel, we ensure that all forms of requirements statements are described with the patterns. We validated the effectiveness of the patterns by using them to rewrite a substantial, previously written, requirements specification to eliminate its imprecisions.
summary: Various authors have worked on QA for software requirements by applying manual techniques. Some put their focus on the classification of quality into characteristics @cite_22 , others develop comprehensive checklists @cite_59 @cite_19 @cite_43 @cite_70 @cite_50 . Regarding QA, some develop constructive QA approaches, such as creating new RE languages, e.g. @cite_46 , to prevent issues up front, others develop approaches to make analytic QA, such as reviews, more effective @cite_15 . In a recent empirical study on analytical QA, @cite_47 manually investigate the presence of defects in use cases. To sum it up, these works on manual QA provide analytical and constructive methods, as well as (varying) lists for defects. They strengthen our confidence that today's requirements artifacts are vulnerable to quality defects.