This paper describes a research activity aiming at extracting variability information from ambiguities and vagueness of generic requirement documents, written in Natural Language. The proposed activity continues a research stream focusing on techniques to extract variability information from requirement documents. Here, we study the introduction of a process able to distinguish structural from functional variability, both in the extracted variability model and in the derived lower-level requirements. The problem is stated with reference to an example, a solution proposal is sketched together with related research questions, and a validation path is envisaged.
Copyright c 2019 by the paper's authors. Copying permitted for private and academic purposes.
Our previous work in this area has focused on the most e ective way of extracting potential variability in requirements, looking for the most suitable textual indicators and for the analysis tools able to detect such indicators. Following the common practice in SPLE, we have hence modeled variability using features and feature diagrams [KCH+90]. We considered real detailed requirement documents coming both from industry and academia and the purpose of the research was to detect the ambiguities still present in these documents, intrinsic in natural language usage, and to understand if these could hide some variability.
In this paper we re ne this approach by considering instead high level/generic requirements documents, in which requirements are given at a high abstraction level, like the declarative description of a main functionality, or the very rst, coarse grained, physical description of a system. The idea is that high level requirements can hide a family of di erent products, so that they may be seen as generic requirements of a potential family of systems, and their specialization may correspond to product speci c requirements. In this paper, variability extraction is based on the observation that a high level requirement document may describe what a potential family of systems will do, and variability is given by di erent choices among the implementation alternatives.
Another novelty of the present work is that variability is extracted by separating functional and structural perspectives by means of di erent feature diagrams: according to the functional perspective, a feature is a function or service o ered by the system, and its sub-features represent special cases or di erent variants of such a functionality; according to the structural perspective, the feature diagram de nes a domain or an architectural organization.
Speci cally, the idea underlying this research activity is to combine: our approach to variability identi cation through the use of a NLP tool; the classi cation of features as functional and structural as introduced in [IR14], that improve features description with respect to the practice of mixing up in a single diagram concepts that would rather be separated; the idea that the specialization processes of functional and structural requirements are interwound. Figure 1 illustrates this double specialization in a UML like formalism: on the top line there are an abstract domain element and a generic functional requirement referring to it; on the bottom line there are the re nements.
This paper aims at describing this combined approach, showing the relevant issues and de ning a process that, moving from generic requirements documents, builds two feature diagrams expressing variability along the di erent perspectives. We illustrate the approach on a small case study, leaving the validation e ort on requirement documents coming from industrial case studies to further work.
This paper is structured as follows: background for this paper is given in Section 2, including more detailed reference to our previous work. Section 3 describes the proposed approach with a simple example and in more general terms. Section 4 discusses the prospected research activity, formulating speci c research questions and envisaging a validation plan, recurring to available industrial case studies. 2.1
Feature models have been extensively used in the area of product line engineering. Product line engineering provides a way to manage variability during the entire design process and is an important means for identifying variability needs early on.
Feature models are visually represented by means of feature diagrams, introduced in [KCH+90] as a graphical formalism, and /or hierarchy of features, to describe in a uniform way a variety of di erent possible implementations of a system. The variability depends on which features are included and which ones are not. The features are represented as the nodes of a tree. Features come in several avours, (Figure 2 illustrates the graphical constructs):
Alternative features are a set of features among which one and only one is present in a system, provided their parent is present.
Constraints may be added to a feature diagram permitting for example to express that the presence of a feature requires the presence of another one. In previous works [FGS17, FFGS18a, FFGS18b], we have de ned an approach to extract variability issues from requirement documents using Natural Language analysis tools. These tools are aimed at revealing the ambiguity defects of the NL sentences in the requirements document.
In line with this stream of research, in [FGS17] we concentrated on the correspondence between ambiguity indicators and feature diagram fragments, to de ne a systematic way of building a feature diagram from a set of variability points extracted with a NLP tool. In particular we have focused on using tools aimed at revealing the ambiguity defects of the NL sentences in the requirements document. The underlying intuition is that often ambiguity in requirements is due to the (conscious or subconscious) need to postpone choices for later decisions in the implementation of the system. Ambiguity in NL has been largely studied in requirements engineering (RE), and several approaches have been developed to automatically detect defective expressions that can be interpreted in di erent ways by the stakeholders who have to read the requirements [TB13, GCK10, BK04, RFG+17, FFWE17]. These approaches focus on identifying typically vague terms, such as adjectives and adverbs (e.g., [TB13, GCK10]), and ambiguous syntactic construction due to the use of pronouns [YDRG+10], or coordinating conjunctions such as \and" or \or" [YWDRN10, CNDRW06]. Our work considers ambiguity not as a defect, but as a means to enlighten possible variation points in an early phase of software and system development, and to give space for a range of di erent products.
Then, in [FFGS18a] we initiated a validation of the approach with the QuARS (Quality Analyser for Requirements Speci cations) NLP tool [GLT05], in order to better assess the relation between ambiguity detection by QuARS and potential variation points. The evaluation has shown that some ambiguous terms, such as \and/or" \or", and weak terms such as \may" or \could" are more likely to indicate variability rather than ambiguity. Instead, typically vague terms, such as \adequate", \signi cant", etc. are more likely to indicate ambiguity. In [FFGS18b] we have analysed the ambiguities returned by the tool on three di erent sets of requirements, classifying them in false positives, real ambiguities, and variation points.
From ambiguities in the domain/structure to specialization and variability of the requirements The work cited in the previous section has mostly regarded the search for the most e ective way of extracting potential variability in requirements, looking at the most suitable indicators, and on the analysis tools able to detect such indicators. Only [FGS17] included the construction of a feature diagram to express the variability revealed by the considered techniques.
To advance our research on the topic, we now focus back on modeling the revealed variability, introducing the distinction between di erent perspectives (typically, structural and functional perspectives) according to which variability can be interpreted. The idea is that generic requirements can hide a family of di erent products, that can be revealed looking at di erent specializations both under a structural and a functional perspective. 3.1
In order to introduce a systematic variability extraction process based on the above principles, we discuss a simple example. The starting point is a high level, generic, set of requirements. For instance, the following can likely be two high level requirements of a generic mobile phone:
The two requirements describe two generic functionalities that a mobile phone shall o er to the user: entering a text, and seeing the text that she is entering. Observing them from a structural perspective, they say that a mobile phone must have an input interface and a screen, that can be considered as structural, mandatory, features: this is summarized by the feature diagram of Figure 3.a.
Considering them from a functional perspective, they mandate that the system o ers two functions, again represented as two mandatory features in Figure 3.b. When analyzing the requirements Rg1 and Rg2, looking for vague and underspeci ed terms according to [FFGS18b], suitable is detected as a vague word that needs to be specialized. In our case, the suitable interface is intended to be a structural feature of the system, for which two alternatives could be identi ed: touchscreen keyboard and microphone.
Moreover, screen is also detected as an underspeci ed term that needs to be instantiated, in this case the analyst decides instantiations to be touchscreen and non-touch screen.
As a rst outcome of this analysis e ort, we can hence add two requirements, each describing two alternatives: Rs1. The input modalities in a mobile phone device are the touchscreen or the old style 3x4 physical keyboard. Rs2. The output modalities in a mobile phone device are the touchscreen or the non-touch screen.
The information that has been added to the description of the mobile phone family induces a re nement of the functional part of requirements Rg1 and Rg2 to consider the new structural elements. The analyst decides to o er normal editing and, optionally, also speech recognition: Rs3. The mobile phone shall permit the user to enter a text through the touchscreen keyboard or through the 3x4 physical keyboard.
Rs4. The mobile phone may (optionally) permit the user to enter a text through voice dictation. Rs5. The phone shall echo the inserted characters on the touch or non-touch screen as they are inserted. Rs6. The phone may (optionally) echo the dictated words on the touchscreen as they are recognized.
These requirements introduce di erent variants of the functional features. They also require to consider the microphone among the standard inputs. Even though speech recognition is optional, we consider the microphone as a mandatory element since it is included in all phones, and re ne Rs1 in Rs1' Rs1'. The input modalities in a mobile phone device are the touchscreen or the old style 3x4 physical keyboard, and the microphone.
In terms of feature diagrams, the structural re nement is described in Figure 4, and the functional variants can be expressed by the feature diagram of Figure 5.
We observe that the features in the diagrams in Fig 4 correspond to those in the diagram in Fig. 5 and could be (almost) pairwise related by inter-diagram requires dependencies: each functional feature requires a corresponding structural entity: e.g., enter a text requires a standard input; enter a text through the touchscreen keyboard requires a touchscreen keyboard, echoing characters or words on the touchscreen requires a touchscreen. We document these dependencies in Figure 6, where, to simplify the picture, we consider only a fragment of the each feature diagrams.
We propose a requirements re nement process, that begins with a list of (generic) requirements.
A generic requirement consists of key generic functionalities and implementations that can become a di erentiating factor for a user. A requirement can be generic because: 1. it describes a functionality, in terms of what the system is supposed to do, and not about how it does so; the functionality is a high level functionality and does not take into account special cases, alternatives, etc. Examples are: The phone shall permit to send a message, The phone shall o er the possibility to enter a text. 2. it predicates about a domain element that has still to be better detailed (by inheritance or by composition).
As an example: The phone shall include a screen.
In all these cases, the re nement process can reveal variability points and can lead to lower level requirements that de ne a family of products that di er in the implementation platform, in the o ered functionalities, or in the adopted physical elements (that roughly correspond to di erent domain elements).
The requirement re nement process can be given a more systematic description as shown in Figure 7 and discussed below: 1. The rst step of the process runs a NLP tool to analyze the generic requirements and to look for indicators of under-speci cations and of vagueness. We recall from [FFGS18b] that under-speci ed requirements are detected looking for terms needing to be instantiated (e.g.: information, interface, access, button, message, screen, ...), and vague requirements are those including undetermined adjectives and adverbs like: clear, easy, strong, good, bad, useful, signi cant, adequate, recent, ....
With reference to the mobile phone example, this means to run the tool on Rg1 and Rg2. We used QuARS to this purpose, having screen and suitable detected as defective words. 2. Once the under-speci ed or vague requirements have been singled out, their analysis (second step of the process) is guided by the questions: \Is this a false positive?", \Is this just an ambiguity?", or \Can this requirement hide a variation point?". More concretely, both in the case of vagueness and in the case of under-speci cation, the criterion to identify a variability is the existence of more than one possible instance of the defective term.
This is a manual step, made by an analyst with some knowledge of the domain. In our running example, both the screen and the suitable interface were considered as possible variability points.
(a) In the case of generic and vague functionality, the requirement is specialized by a set of concrete functionalities. For instance the requirement \The phone shall permit to send a message" may be re ned
in a mandatory feature \send a SMS message" and two optional features: \send a MMS message" and \send a WhatsApp message". The specialization may need the de nition of structural/architectural aspects of the system, that may in turn lead to a further re nement of the functionalities if there are still some vaguenesses or under-speci cations. (b) In the case of a requirement containing a defective term that denotes a domain entity we consider all the possible specializations of the generic term and re ne the structural description. This leads in almost all the cases to a re nement in the functional perspective, to take into account the newly introduced concrete domain elements.
This is the case of our running example, where di erent input interfaces have been considered: the keyboard and the microphone, that are both mandatory in a phone, and where the keyboard can be either on the touchscreen or the 3x4 physical keyboard. The considered screens have been the touchscreen and the not touch screen. This re nement has led to Rs1 and Rs2.
In general, the third step of the process is iterative and alternates structural and functional specializations. In the case of the mobile phone, the structural re nement has naturally driven the functional re nement step (Figure 5): after having described the phone structure, it has been clear that the functionality enter a text could have been implemented by editing on a touch or on a traditional keyboard (Rs3). The analysis has also singled out a third choice, namely voice dictation (Rs5). Each choice has a corresponding echoing modality (Rs4 and Rs6). Finally, speech recognition has induced a further structural re nement, to consider the microphone (Rs1').
The nal result is a pair of feature diagrams, one in functional and the other in structural perspective. These diagrams can be connected through requires dependencies, relating a functional feature with the structural entity(-ies) needed to implement it, as exempli ed in in Figure 6 and generalized in Figure 8. 4
We have presented the current status of a research activity aiming at driving the elicitation of a family of products from an initial set of generic requirements written in Natural Language. The approach is based on extracting variability information from ambiguities and vagueness of the generic requirement documents.
When specializing generic requirements of a (potential) family of systems, variability is typically introduced both on a structural and on a functional perspective, hence there is the need to introduce a process able to distinguish the structural from the functional perspectives in eliciting variability, both in the extracted variability model and in the derived lower-level requirements. We have presented the problem by means of a simple example and we have sketched a solution proposal.
We plan to validate the presented approach by application to industrial case studies. Our research agenda hence consists in taking some real world requirements document, apply a NL processing tool to look for underspeci cations and vaguenesses, and perform the analysis and re nement step, to answer to the following research questions:
Research Question 1: Is there a preferred order in the process of variability identi cation? i.e. is it better to rst address re nement of the structural features rather than the functional ones, or viceversa? Or the two parallel processes should actually interleave?
Research Question 2: How well can the approach be accepted in industry? How much industrial users will appreciate this approach in terms of perceived usefulness and perceived ease-of-use (regarding both aspects of using NLP analysis tools and of distinguishing functional and structural models)?
Regarding the rst research question, we have already identi ed an interesting candidate case study in the Clarus Weather System. Clarus is an initiative sponsored by the Federal Highway Administration (FHWA) to organize and make more e ective environmental and road condition observation capabilities. The list of requirements of the Clarus system is organised in two documents: high level and detailed system requirements. These are considered suitable to validate the capabilities of the NLP tools to indicate potential variability: any detected variability should be re ected, either under a structural or a functional perspective, to specialized requirements. We plan to use them as a testbed for our approach applying the re nement process to the generic requirements and comparing the outcome with their detailed requirements. An example of generic requirement is the one telling that \the Clarus system shall employ industrial standards". The under-speci ed wording industrial standard calls for an analysis and re nement e ort. Indeed, we found a comment specifying the family of standards of interest, and in the detailed document the defective requirement is substituted by 10 di erent requirements, one for each concrete standard.
Other industrial case studies will then be needed to be able to generalize the answers to the question.
The second research question will require a longer term collaboration with one or more companies, in order to involve requirement engineers and analysts in an investigation including pilot projects and interviews, within an established technology acceptance model. [BK04]
D. M. Berry and E. Kamsties. Ambiguity in requirements speci cation. In Perspectives on software
requirements, pages 7{44.
N. H. Bakar, Z. M. Kasirun, and N. Salleh. Feature extraction approaches from natural language requirements for reuse in software product lines: A systematic literature review. Journal of Systems and Software, 106:132{149, 2015.
Lianping Chen, M. A. Babar, and N. Ali. Variability management in software product lines: a systematic review. In Proc. of the 13th Int. Software Product Line Conference, pages 81{90.
Carnegie Mellon University, 2009. [CNDRW06] F. Chantree, B. Nuseibeh, A. De Roeck, and A. Willis. Identifying nocuous ambiguities in natural language requirements. In Requirements Engineering, 14th IEEE International Conference, pages 59{68. IEEE, 2006.
A. Fantechi, A. Ferrari, S. Gnesi, and L. Semini. Hacking an ambiguity detection tool to extract
variation points: an experience report. In Proc. of the 12th International Workshop on Variability
Modelling of Software-Intensive Syste
A. Fantechi, A. Ferrari, S. Gnesi, and L. Semini. Requirement engineering of software product lines: Extracting variability using NLP. In 26th IEEE Int. Requirements Engineering Conference, RE 2018, Ban , AB, Canada, Aug. 2018, pages 418{423. IEEE Computer Society.
H. Femmer, D. Mendez Fernandez, S. Wagner, and S. Eder. Rapid quality assurance with requirements smells. Journal of Systems and Software, 123:190{213, 2017.
A. Fantechi, S. Gnesi, and L. Semini. Ambiguity defects as variation points in requirements. In Proc. of the 11th International Workshop on Variability Modelling of Software-intensive Systems, VAMOS '17, pages 13{19, 2017. ACM.
A. Ferrari, G. O. Spagnolo, and F. Dell'Orletta. Mining commonalities and variabilities from natural language documents. In Proc. of the 17th International Software Product Line Conference, pages 116{120. ACM, 2013.
B. Gleich, O. Creighton, and L. Kof. Ambiguity detection: Towards a tool explaining ambiguity sources. Requirements Engineering: Foundation for Software Quality, pages 218{232, 2010. [IR14] [KCH+90] [NBA+17] [PKS04] [RFG+17]