Use Cases are an effective technique to express Functional Requirements of a system in a very simple and easy-to-learn way. Use Cases are mainly composed of Natural Language (NL) sentences and the use of NL to describe the behavior of a system is always a critical point, due to the inherent ambiguities originating from the different possible interpretations of NL sentences. We discuss in this paper the application of analysis techniques based on a linguistic approach to detect, within requirements documents, defects related to such inherent ambiguity. Starting from the proposed analysis techniques we will define some metrics that will be used to perform a quality evaluation of requirements documents. Some available automatic tools supporting the linguistic analysis of NL requirements have been used to evaluate an industrial Use Cases document according to the defined metrics. A discussion on the application of linguistic analysis techniques to support semantic analysis of Use Cases is also reported. 1.

Capturing the variations characterizing the set of products belonging to a product line is a key issue for the requirements engineering of this development philosophy. This paper describes ways to extend the well-known Use Case formalism in order to make possible the representation of these variations, in the perspective to make them suitable for an automatic analysis. 1.

In industrial requirements documents natural language is the main presentation means. In such documents, system behavior is specified in the form of scenarios, written as a sequence of sentences in natural language. The scenarios are often incomplete: 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. This paper presents an approach that analyzes textual scenarios with the means of computational linguistics, identifies where communicating objects or whole actions are missing in the text, completes the missing information, and creates a message sequence chart (MSC) including the information missing in the textual scenario. Finally, this MSC is presented to the requirements analyst for validation. The paper presents also a case study in which scenarios from a requirement document based on industrial specifications were translated to MSCs. The case study shows the feasibility of the approach. 1. Document Authors are not Aware that some Information is Missing Some kind of requirements document is usually written at the beginning of every software project. The majority of these documents are written in natural language, as the survey by Mich et al. shows [13]. This results in the fact that the requirements documents are imprecise, incomplete, and inconsistent. The authors of requirements documents are not always aware of these document defects. From the linguistic point of view, document authors introduce three defect types, without perceiving them as defects,

This paper describes a case study on application of natural language processing in very early stages of software development. At this early stage it is very important for the domain expert (who is, most probably, the future user) and the software expert to define a common language, understood by both of them. To define such a common language, we extract terms from the text written by domain expert, classify these terms and build a domain ontology using them. In our previous

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 two requirements-identification case studies with one small NL RS using a prototype of the first tool based on an existing NL processing system and a manual simulation of the second tool. 1

Abstract not found

This paper describes an approach for analysis of natural language requirements documents and two case studies conducted to prove the feasibility of the approach. The goal of the analysis is to define a common language understood both by the domain expert and the software engineer. To define such a common language, it is necessary to extract terms from the text written by domain expert. The extracted terms must be classified to build a taxonomy. This taxonomy is augmented by associations between terms to build a domain ontology. The paper introduces two case studies that illustrate feasibility of the approach. The first case study was conducted to test the approach itself and showed that the approach works, but certain interaction with human analyst is necessary. The second case study showed that this interaction does not consume too much time so that the approach scales to larger documents. 1

Abstract. 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

Use Cases can be employed in system requirements engineering to capture requirements from an external point of view. In product line modeling, commonalities and variabilities of a family of systems have to be described. In order to support variability modeling for product lines with Use Cases, extensions and modifications of Use Cases have to be provided. Capturing the variations characterizing the different products is a key issue for product line requirements engineering. This paper describes an approach to derive product line requirements in the form of Use Cases, starting from the analysis of user documentations of existing systems. We provide a disciplined approach to integrate legacy information found in existing documentation into product line Use Cases and illustrate this with an example.

This paper describes an approach for elicitation of requirements based on existing user documentation. The approach we describe in this paper supports capturing of the information found in user documentation of legacy systems, e.g., user manuals, and the specification of this information in requirements specifications, using, e.g., Use Cases. We propose a conceptual model describing the transition from user documentation to requirements artifacts describing common and variable elements of a product line model or requirements specification. We present heuristics that allow an easy identification of text elements in user documents that are then used to create a significant part of the requirements specification and product line model, respectively.