Variability Specification and Resolution of Textual Requirements
Alberto Rodrigues da Silva and João Costa Fernandes
INESC-ID, Instituto Superior Técnico, Universidade de Lisboa, Portugal
Keywords: Requirements Specification, Variability Modelling, Reusability, Software Product Line.
Abstract: Since software product lines emerged, various techniques have provided for commonality and variability
modelling of functionally similar products within a given domain. However, so far the emphasis of
variability modelling proposals has mostly been on the solution rather than the requirements level, which is
mainly due to stakeholders often associating variability with the software implementation instead of the
problem analysis. Taken into consideration the positive impact that a high-quality system requirements
specification plays within a software project, this paper proposes and evaluates an innovative approach for
the modelling and management of variability at the requirements level, based on the Common Variability
Language (CVL), the OMG proposal for a domain-independent variability modelling standard. This
approach has been implemented as a core feature of the ITBox system, a Web-based collaborative platform
for the management of technical documentation.
1 INTRODUCTION
In order to meet specific customer needs, companies
often begin with developing customer-specific
versions of their original products by changing
and/or adding features. On one hand, defining a
product by a hierarchized structure of functional
capabilities, such as a feature model, does not
include neither cross-cutting capabilities, nor
multiple abstraction levels and constructs or views
(for instance, a traditional billing system can be
break-down into features such as customers,
suppliers, invoices, payments, products and services,
whereas a requirements specification for the same
product would involve not only those functional
capabilities, but also cross-cutting capabilities such
as non-functional requirements like security,
availability, usability, etc.) On the other hand, a high
number of customer-specific versions demands for a
high effort in variability and even project
management e.g. the specification of variation points
and respective variants. OMG’s CVL (Common
Variability Language) is the proposal of a domain-
independent language for specifying and resolving
variability (OMG, 2012).
Diverse authors argue that the activity of
variability modelling shall be initiated as early as
during the RE (Requirements Engineering) stage
(Coplien et al., 1998; Verelst et al., 2013; Silva et
al., 2014; Blanes et al., 2014). Given the vital role
that a well-defined SRS (System Requirements
Specification) document plays in the success of a
project (Davis, 2005), rigorous means of expressing
variability concerns in those documents are of
extreme importance. Despite this, little research has
investigated ways of applying the concepts of CVL
to the RE spectrum, which does not stand for a
recognition of OMG’s effort to establish a standard
targeted at the representation of variability. The
approach proposed in this paper, however, is
targeted at specifying the C&V (Commonalities and
Variabilities) of RE concepts.
Fernandes (2016) and Silva, Fernandes, and
Azevedo (2017) proposed an approach for
leveraging the concepts of CVL and its domain-
independence to the specification and resolution of
variability in the context of RE, specifically in
structured SRS documents defined with a rigorous
RSL (Requirements Specification Language). This
paper discusses how this approach was translated
into a core feature of the ITBox system, a Web-
based collaborative platform for the management of
SRSs. That feature is focused on the reusability of
requirements starting from C&V modelling.
The remainder of this paper is structured as
follows. Section 2 refers to the ITLingo initiative,
the RSL and the OMG’s CVL. Section 3 introduces
the ITBox collaborative platform. Section 4 details
the CVL-based variability approach to requirements
modelling supported by the ITBox. Section 5
Rodrigues da Silva, A. and Fernandes, J.
Variability Specification and Resolution of Textual Requirements.
DOI: 10.5220/0006810801570168
In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 157-168
ISBN: 978-989-758-298-1
Copyright
c
2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
157
provides for a demonstration case of that approach.
Section 6 presents and discusses the evaluation of
the proposed approach. Section 7 analyses some
related work. Finally, section 8 presents some
concluding remarks and future work.
2 BACKGROUND
2.1 RSLingo Initiative
RSLingo is a long-term research initiative in the
Requirements Engineering area (Ferreira and Silva,
2012; Silva, 2017). It is a linguistic approach to
improve the quality of requirements specifications.
Although being the most common and preferred
form of representing requirements, natural language
is prone to producing ambiguous and inconsistent
documents, hard to automatically validate or
transform into other kinds of artefacts.
Originally, RSLingo proposed two languages:
the RSL-PL (Pattern Language) (Ferreira and Silva,
2013a), designed to support the encoding of RE
linguistic patterns, and RSL-IL (Intermediate
Language) (Ferreira and Silva, 2013), a domain-
specific language designed to primarily support the
elaboration of SRSs. Together, these two languages
allow domain knowledge written in natural language
to be extracted, parsed and converted into a more
structure format, reducing its original ambiguity, and
creating a new and more rigorous SRS document
(Silva, 2015a). This process of extracting knowledge
and converting it into a more rigorous representation
has in itself a way of providing business
stakeholders with a better understanding of natural
language statements that represent requirements.
2.2 RSL
Recently, broader language, called RSL, has been
designed (Silva, 2017; Silva, 2018). It is a
comprehensive domain-specific language (Silva,
2015) designed to address general-purpose RE
activities such as the rigorous specification,
automatic validation, persistence and management
of software requirements. It is based on other
languages such as Pohl’s (Pohl, 2010), XIS* (Silva
et al. 2007; Ribeiro and Silva, 2014; Ribeiro and
Silva, 2014a) and SilabReq (Savić et al., 2015).
RSL is, in fact, a controlled natural language to
help with the production of SRSs in a more
systematic, rigorous and consistent way. It is a
language that includes a rich set of constructs
logically arranged into views according to multiple
RE-specific constructs situated either at the business
or at the system abstraction levels. These constructs
are defined as linguistic patterns and textually
represented by mandatory or optional fragments
(text snippets). For example, people and
organizations that can influence or can be affected
by the system are represented by the construct
Stakeholder. Likewise, the goals of business
stakeholders towards the system and the value it
represents to them are represented by the construct
BusinessGoal.
RSL is a process- and tool-independent language
that can be used and adapted by multiple users or
organizations with different processes, as well as
supported by multiple types of software tools.
However, in practical terms, RSL has been
implemented with the Xtext (http://www.eclipse.org/
Xtext/) framework (Bettini, 2016), which means that
RSL specifications are rigorous, and can be
automatically validated and transformed into other
representations and formats. A lightweight tool
support is provided with the ITLingo RSL Excel
Template (https://github.com/RSLingo/RSL-Excel-
Template) publicly available at GitHub. This Excel
template encloses different viewpoints (shortly
views) organized into sheets and described by a set
of properties for each one of them. As an example,
the key properties of the Goals view are shown in
Table 1.
Table 1: Properties of the Goals view from RSL.
Name
Description
Type/Values
Id
Unique identifier of
the goal
string
Name
Descriptive name of
the goal
string
Type
Type of goal
Concrete;
Abstract
Source
Reference to the
stakeholder who has
or defined the goal
<stakeholder id>
PartOf
Reference from the
current goal to its
parent goal
<parent goal id>
Description
Description of the
goal
string
Priority
Level of priority for
the goal
Must; Should;
Could; Won’t
Progress
Current status of the
development
process
Plan; Design;
Develop; Test;
Deploy;
Concluded
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
158
2.3 CVL
CVL is the OMG’s proposal of a domain-
independent language for specifying and resolving
variability over models of any MOF-based language
(OMG, 2012). Figure 1 shows the CVL execution
(or materialization) process, which involves the
following models: the Base Model, the Variability
Model, Resolution Models and Resolved Models.
Although involved in the CVL execution process,
the Base Model is not part of the CVL. It consists of
the definition of the product line in any MOF-
compliant language. This compliance makes of CVL
a domain-independent language. The Variability
Model is a collection of variation points, VSpecs
(further explained in section 3) and constraints used
in the specification of variability over the Base
Model. These concepts and the integration between
them constitute the core of the CVL. The Resolution
Model consists of a collection of VSpec resolutions
that resolve the VSpecs of a Variability Model.
Finally, the Resolved Model is a model produced by
the materialization of the Base Model according to a
Resolution Model.
Figure 1: Overview of the models involved in the CVL
execution process (extracted from (OMG, 2012)).
3 THE ITBox PLATFORM
ITBox is a Web-based collaborative platform for the
management of SRSs and other technical
documents. Although ITBox can support multiple
types of documents, this paper focuses only on
SRSs. Figure 2 shows a screenshot of ITBox. The
users of this platform can author, review and
validate requirements based on the constructs of the
RSL. Given that RE processes involve an intense
cooperation between many stakeholders (e.g.
customers, domain experts, requirements engineers
and software developers), the key design goals of
ITBox were the following.
Figure 2: The ITBox (variability point’s selection screen).
Provide for a collaborative environment to
support the management of SRSs with an easy to
learn and easy to use interface
The major purpose of ITBox is to provide for a
collaborative editor of SRS documents. Spreadsheet
editors, although lacking many of the fundamental
features of the commercial RE-dedicated tools, have
always been a popular choice to manage SRSs due
to their widespread availability and simple interface,
making them a good baseline tool for nontechnical
stakeholders. Until recently, one of the main
problems with this desktop software was to maintain
synchronized and updated versions of documents in
decentralized projects that require multiple
concurrent changes. However, recent cloud storage
services, such as Google Drive or OneDrive, offer
collaborative means to manage this type of
documents like automatic synchronization and
lightweight versioning. In that sense, ITBox uses
Google Drive and Google Sheets APIs to provide for
authoring in a cooperative environment. The first is
used for uploading the local copies of SRS
documents, sharing them and granting access
permissions to its users, whereas the second offers
all the data manipulation functions for extracting and
editing the information contained within the
documents.
Integrate with ITLingo concepts and
technologies
This key design goal is related to the adoption of
the constructs defined in the RSL. Although ITBox
allows for the usage of any format of SRS
document, all the features that involve data
manipulation expect the current version of the RSL
Excel template.
Variability Specification and Resolution of Textual Requirements
159
Figure 3: The ITBox Variability Modelling approach (represented as a BPMN diagram).
Include reusability and variability capabilities
The variability features have to do with the
variability modelling approach based on the CVL
that this paper reports, which is described in more
depth in the next section. It is of utter importance to
note that a model in not necessarily a graphical,
rather a representation of requirements and their
variability, in the case of this paper. The reusability
features provided by the ITBox contemplate the
management of SRS templates and of SRS libraries.
The former (management of SRS templates) allows
any previously developed template (defined in the
format of a spreadsheet) to be uploaded into the
platform and later used to create new SRSs based on
the structure of that template. The later
(management of SRS libraries) allows the creation
of libraries of coarse grained and potentially generic
requirements that can afterwards be added (and
edited if necessary) to any new project. The ITBox
variability modelling process is intimately related to
the management of SRS libraries.
4 THE ITBox VARIABILITY
MODELLING APPROACH
The ITBox variability modelling process closely
follows the approach proposed by CVL, as Figure 3
depicts. Complementarily, Figure 4 illustrates the
main concepts of the approach and the relationships
between them. A detailed description of the process
is presented below.
4.1 Create Variability Model
The variability modelling process begins with the
user selecting the SRS document (or SRS library) to
be used as Base Model. In ITBox the Base Model is
a SRS document based on the RSL Excel Template.
That document can either be part of a project already
in the platform or manually uploaded into the
platform (it has, though, to conform to the RSL).
ITBox, then, automatically parses the document and
extracts the requirements for each of the views
supported by RSL (e.g. Goals, Functional
Requirements and Quality Requirements).
Afterwards, the user can define variation points over
the extracted requirements. As defined by CVL,
variation points are specifications of “concrete”
variability in the Base Model and are part of
Variability Models. They indicate modifications that
the Base Model suffers during materialization.
Variation points are bound to VSpecs, which means
that the application of a variation point to a Base
Model, during materialization, implies the resolution
of a VSpec.
According to CVL, a VSpec is a specification of
“abstract” variability and is also part of a Variability
Model. In order to materialize a Base Model, a
Variability Model is applied over it and VSpecs are
resolved. The nature of the dependency is specific to
Business Process REBox Variability Modeling Approach - Business Process View
«RSL Excel»
Base Model
Create Variability Model
Complete Variability Model
with Constraints
Execute the Materialization
Process
«ITBox Variab...
Variability Model
«ITBox Resolu...
Resolution Model(s)
«RSL Excel»
Resolved Model(s)
Create Resolution Model(s)
Variability model creation (executed once)
Resolved model creation (executed multiple times, once per project)
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
160
Figure 4: The ITBox Variability Model (represented as a UML class diagram).
the type of variation point. In ITBox, variation
points can be defined over (1) requirements
themselves and (2) their properties. Variation points
defined over a requirement are of the Existence
type, meaning that, during materialization, they will
be bound to a Choice VSpec. Variation points
defined over a requirement property are of Value
Assignment type, meaning that, during
materialization, they will be bound to a Variable
VSpec. Once the user has defined all the variation
points over the Base Model, ITBox automatically
generates the first part of the Variability Model: the
VarSpecs view. In CVL, each variation point
references a single VSpec. Figure 4 details the
variability binding model used by ITBox. VarSpec is
the name given by the ITBox approach to the
concept of VSpec in CVL. Table 2 presents the key
properties of the VarSpecs view. This view
introduces a new concept associated with VarSpecs
(which refers also to the concept of VSpec in CVL):
the VarToken. VarTokens are children VarSpecs
associated with a particular property of the
requirement in the Base Model. Due to space
limitations, we are not presenting a table with the
key properties of the VarTokens view. A VarSpec
can have any number of VarTokens, depending on
the number of properties previously considered as
variation points. VarSpecs, which associated with
requirements, are defined as of type Choice, which
means that, during materialization, its resolution
requires a binary (yes/no, true/false) decision to
define if that particular requirement is going to exist
in the Resolved Model. VarTokens are of type
Variable, which means that, during
materialization, its resolution requires providing a
resolution value of their specified type.
Table 2: Properties of the VarSpecs view from RSL.
Name
Description
Type/Values
Id
Unique
identifier
String
Name
Descriptive
name
String
Type
VarSpec type
VSReqGoal;
VSReqFunctional;
VSReqQuality
ElementId
The associated
Requirement id
<Requirement Id>
ElementName
The associated
Requirement
Name
<Requirement
Name>
VarTokens
List of
VarTokens
List of
<VarTokens>
Description
Description of
the VarSpec
String
4.2 Complete Variability Model with
Constraints
After the first part of the Variability Model is
generated, the user is able to define constraints over
the VarSpecs that were created. In CVL, constraints
are used to restrict the allowed resolutions of
VSpecs and can be defined either globally or in the
context of a particular VSpec. To achieve this, CVL
relies on a restricted subset of the OCL (Object
Constraint Language). Both parent VarSpecs, as
Requirement
Attribute
VSpec
VarSpec
- Id: string
- Name: string
- Description: string
- Type: enum
VarSpecConstraint
- Id: string
- Name: string
- Type: enum
- VSpecsIds: .var.spec.Id
VSpec
VarToken
- Token: Requirement Attribute
Requirement
Id; Name; Description;
Source; PartOf; Priority
Goals; Functional
Requirements;
Quality Requirements. etc.
Variability Model
1..*
0..*
+Existence
1
+Choice
0..1
1..* 0..*
*
1
*
1
1
+Variable
0..*
Variability Specification and Resolution of Textual Requirements
161
Figure 5: An example case of the definition of variation points in ITBox, and the associated VSpecs and constraints,
together with a representation of the corresponding VSpecs tree.
well as their children VarTokens can be used when
defining the logical formulas or expressions that
express those constraints. An in-depth example of
this process is shown in section 5, as well as the
VarSpecsConstraints view from RSL.
4.3 Create Resolution Model and
Execute Materialization Process
The CVL-based variability modelling approach of
ITBox ends with the materialization process. As
stated in CVL, this process consists of transforming
a Base Model into a new document by resolving the
variation points in that model. Materialization is
driven by a Resolution Model which provides for
resolutions of VSpecs to which variation points are
bound. In ITBox, the information in the Variability
Model is stored in the database of the system. From
that moment on, whenever a new SRS document
creation process starts, the user is given the option
to, instead of creating a new empty document,
generate a new document by defining a set of
resolution values (i.e. creating the Resolution
Model) for an existing Variability Model. When this
happens, the platform crosses the information
contained in the Variability Model with the
Resolution Model provided by the user and checks
every constraint for possible inconsistencies. If no
inconsistency is found, a new Resolved Model is
produced.
5 RUNNING EXAMPLE
Figure 5 depicts a simple, yet effective example of
application of the proposed CVL-based variability
modelling approach of ITBox to a set of reliability-
specific quality requirements, which defines the
expected uptime of a system throughout a 1-year
period, required maintenance procedures and fault
logging details.
5.1 Create a Variability Model
5.1.1 Base Model
The first table in Figure 5 presents the Quality
Requirements view with the quality requirements
extracted from the SRS document of the example
case. This view uses a set of properties to
characterize each quality requirement: unique
identifier, name, type, subtype, metric and
corresponding value (if applicable), stakeholder who
owns the requirement, parent requirement (if
applicable), description and, finally, priority.
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
162
5.1.2 Variability Model
The second table in Figure 5 shows an example of
the manual configuration of variation points. To
define a requirement as a variation point, the user
checks the VarPoint? field in the row
corresponding to that requirement. This action will
mark that requirement as an Existence variation
point, meaning that it will be bound to a Choice
VSpec. Furthermore, the field VarTokens is
intended for the user to select which of the
properties of that requirement will be modelled as
children variation points of the type Value
Assignment. In the example, from the five initial
requirements, two were selected as variation points:
QR_R_1 and QR_R_3. The first one has two
properties modelled as children variation points:
Description and Priority. However, not all
of the content from the Description field is to be
considered for variability purposes, only the
substring 99%, denoted by the suffix .value#99%.
The third table of Figure 5 depicts a simplified
version of the VarSpecs view (for the sake of space,
some of the properties mentioned in Table 2 were
omitted). This view is automatically generated by
the ITBox from the variation points previously
selected by the user. In the example, the user
selected the requirements QR_R_1 and QR_R_3,
which were transformed by ITBox into selected
variation points VS_1 and VS_2, respectively. This
process corresponds to the binding process of CVL,
in which each of the variation points is linked to its
abstract representation in the Variability Model (or
VSpec).
To the right of the third table in Figure 5 is the
tree representation of the VarSpecs, VarTokens and
VarSpecsConstraints in the example case. The
parent element corresponds to the system itself.
QR_R_1 and QR_R_3 requirements are represented
as Choice VSpecs. These elements are linked with
their parent by a dashed association, representing a
false IsImpliedByParent value, which means
that their materialization value is independent from
the one their parent takes. In the third level of the
tree three children VSpecs of type Variable
reside. They were generated by the VarTokens
defined in the third table and their corresponding
types.
The fourth table of Figure 5 illustrates a
simplified version of the VarSpecsConstraints view.
The constraints are neither generated by the ITBox
system, nor could they be since they are user-defined
by definition. The user defined constraints based on
the VSpecs defined in the VarSpecs table and on the
context of the system under specification. In Figure
5, a propositional constraint determines whether
(during materialization) the annual uptime of the
example case is greater than or equal to 99.9%. If so,
the value defined for the Priority VSpec has to
be Must. Note that both VSpecs involved in the
constraint are children of the same VSpec (QR_R_1,
with id VS_1). Thus, the constraint was defined in
the context of the parent node. It is possible,
however, to combine multiple parent VSpecs and
their children (e.g. VS_1->VS_2:Description
= “something”, which means that if QR_R_1
(VS_1) is resolved as true, then the Description
of QR_R_3 (VS_2) must be resolved to the string
“something”).
5.2 Create Resolved Models
As depicted in Figure 3, various Resolved Models
can semiautomatically be produced from a pair of
Base and Variability Models, and various resolution
models, with an appropriate tool support. For
instance, considering the example case, two
Resolved Models could be produced for two distinct
systems (system A and system B) as suggested in the
Tables 3 and 4, where the yellow background (or
grey in grayscale printings) of some text snippets
corresponds to the materialization process.
Table 3: Resolved Model for system A.
Name (*)
Description
System
Uptime
The system should assure an
annual Uptime of 66%.
Fault
Logging
The system shall register all
the faults occurred at runtime
in the log file of system A.
Table 4: Resolved Model for system B.
Name (*)
Description
System
Uptime
The system should assure an
annual Uptime of 90%.
6 ITBox EVALUATION
To evaluate the approach to the modelling and
management of variability at the SRS level
supported by the ITBox platform, a pilot user test
session was conducted. The assessment focused on
three aspects of ITBox: (1) the overall usability and
Variability Specification and Resolution of Textual Requirements
163
the quality of its features; (2) its capabilities in what
requirements variability is concerned; and (3) the
general approach enclosed in the platform.
The session involved a group of 7 participants
with ages ranging from 22 to 28 years-old and with
at least a Bachelor of Science degree. All
participants had previous knowledge and academic
experience in the field of RE and half of them had
professional experience in the same field. The
session was conducted under the following
conditions: (1) it took place in a laboratory, therefore
a controlled environment; (2) the assigned tasks
were performed without previous use or learning of
the platform; (3) all participants had a computer with
a Web browser and Internet access; (4) while
participants performed the assigned tasks, their
behaviour and performance was directly observed;
and (5) participants were free to think out loud and
share ideas. All participants received a 20-minute
presentation of the ITBox fundamentals (concepts
and features), particularly its variability modelling
capabilities. Afterwards, they were given a script
describing a simple case study (the Billing System
example) and its corresponding SRS document in
the RSL-IL Excel template. The task consisted in
uploading the template into ITBox and used it to test
all the features of the platform within 40 minutes. In
the end, participants were asked to fill in a
questionnaire to rate the ITBox platform, its
variability capabilities and the overall RE approach.
The answers were expressed in the following scale:
0 (Not Applicable or Do Not Know), 1 (Very Low),
2 (Low), 3 (Medium), 4 (High) and 5 (Very High).
The evaluation of the overall usability of ITBox and
the quality of its features included 4 questions:
QP.1. How do you rate the overall usability of the
Web platform?
QP.2. How do you rate the usefulness of the main
RE productivity features (RSDoc Spreadsheet
Editor, Template Manager and RSLibrary)?
QP.3. How easy to learn (or how familiar) was the
main document editing tool (Google Sheets)?
QP.4. How suitable is the platform for a
collaborative management of Requirements
Specifications?
Table 5 summarizes the average score of the
answers to the questions regarding the overall
usability of ITBox and the quality of its features. In
general, scores were very positive, which implies
that the platform was successful at accomplishing its
general goals. The lowest score was given to
question QP.1, which demonstrates that the usability
of ITBox can still be improved, however the answers
to the other three questions were very positive,
which indicates that the participants considered the
features of ITBox to be useful and easy to learn.
Furthermore, the platform itself was considered very
suitable for the collaborative management of SRSs.
Table 5: Average score (in a scale of 0-5), by question, for
the overall usability of ITBox and the quality of its
features.
QP.1
QP.2
QP.3
QP.4
4
4.29
4.29
4.71
The evaluation of the capabilities of ITBox in
what requirements variability is concerned included
5 questions:
QV.1. How easy to understand was the overall
variability modelling process?
QV.2. How easy to understand were the concepts
(VarSpecs, VSpecs, VarTokens,
VarSpecsConstraints, etc.)?
QV.3. How do you rate the usefulness of the
variability modelling approach?
QV.4. How do you rate the simplicity of the
Variability Model creation phase?
QV.5. How do you rate the simplicity of the
Resolved Model creation phase?
Table 6 summarizes the average score of the
answers to the questions regarding the capabilities of
ITBox in what requirements variability is concerned.
Similarly to the previous questions package, in
general, scores were very positive, which means that
the platform was successful at accomplishing its
requirements variability goals. However, the scores
were slightly lower than the ones of the previous
questions package, especially those of questions
QV.1 and QV.2. This indicates that the participants
considered both the variability modelling process
and its concepts sometimes hard to understand,
which is relatively understandable since the proposal
is innovative and the participants were not
familiarized with it. Despite that, ITBox can still
incorporate informative tooltips and a detailed user
guide to better convey the variability process and its
terms.
Table 6: Average score (in a scale of 0-5), by question, for
the capabilities of ITBox in what requirements variability
is concerned.
QV.1
QV.2
QV.3
QV.4
QV.5
3.48
3.43
4.57
4
4.14
Finally, the evaluation of the general approach
enclosed in ITBox included 2 questions:
QA.1. How do you rate the productivity of ITBox
when compared to the traditional requirements
specification process?
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
164
QA.2. How likely would you use this platform on
your own Requirements Engineering projects?
Finally, Table 7 summarizes the average score of
the answers regarding to the questions regarding the
general approach enclosed in ITBox. The score
obtained for both questions was highly positive,
which demonstrates that the participants considered
ITBox to be quite productive to specify requirements
as well as useful.
Table 7: Average score (in a scale of 0-5), by question, for
the general approach enclosed in ITBox.
QA.1
QA.2
4.43
4.43
As illustrated in Table 8, the results of the pilot
user test session were generally encouraging, with
positive scores in all of the 3 aspects of ITBox
analysed. Nevertheless, the variability modelling
process and its concepts can still be improved with
regards to its simplicity towards the user. Regarding
the relatively low number of participants, studies
have noted that a group of 5 testers is enough to
uncover over 80% of the usability problems in a
proposed solution (Nielsen and Landauer, 1993), so
the conclusion that the results extracted from the
pilot user test session are representative of what
could be expected from a bigger number of
participants can be drawn. Also, we believe 7
participants is a reasonable number for an
exploratory assessment to identify challenges
associated with the overall usability and features of
ITBox, its variability requirements approach and the
general approach enclosed in the platform.
Table 8: Average score (in a scale of 0-5) for each of the
aspects of ITBox analysed.
Platform
Variability
Approach
4.32
3.92
4.43
7 RELATED WORK
Coplien et al. (1998) argued that the analysis
decisions on C&V shall be made during the
requirements analysis stage, rather than during the
implementation stage by professionals who are not
so familiar with the implications and impact of such
decisions. They referred that early decisions on
C&V contribute to large-scale reuse and the
automated generation of family members. In 2002,
Bosch et al. also mentioned the need for describing
C&V within different modelling levels such as the
requirements one (Bosch et al., 2002).
Table 9 synthetizes prior research contributions
in what C&V at the analysis stage is concerned,
namely at the level of requirements representation
(e.g. with use case models). The most recent effort
to establish a unified variability language is CVL.
However, given that CVL is relatively new, not
much research has yet been conducted to define
clear ways of applying its concepts to the RE
domain. Research contributions referred in Table 9
between #1 and #9 are prior to the CVL, therefore,
they convey different approaches over variability
representation, including at the requirements point of
view, and they have contributed to the existence of
CVL.
Particularly research contribution #10, like RSL,
covers a comprehensive set of RE concepts and
relationships between them, and avoids having to
keep the consistency between requirements models
and variability models, yet it is not compliant with
CVL. The same goes for the research contribution
#11 in what compliance with the CVL is concerned.
So far, CVL has not been specifically applied to RE.
The approach proposed in this paper, however, is
targeted at specifying the C&V of RE concepts in
compliance with CVL. It achieves this because RSL
allows encoding rigorous SRSs, but also because it
is possible to associate variability points in a non-
intrusive way for many of the RSL constructs (e.g.
goals, quality requirements, actors and use cases).
8 CONCLUSION
This paper discusses a CVL-based approach for
modelling variability in requirements specification
documents. The approach was integrated into the
ITBox
1
platform and uses the SRS template based on
the multiview architecture defined in the RSL as its
Base Model. RSL is a language that includes a rich
set of constructs logically arranged into views
according to multiple RE-specific constructs situated
either at the business or at the system abstraction
levels. Those constructs are defined as linguistic
patterns and textually represented by mandatory or
optional fragments (Silva, 2017; Silva, 2018).
RSL is a process- and tool-independent language
that can be used and adapted by multiple users or
organizations with different processes, as well as
supported by multiple types of software tools.
However, in practical terms, RSL has been
1
ITBox currently available at http://itbox.inesc-id.pt
Variability Specification and Resolution of Textual Requirements
165
Table 9: Research contributions concerned with the representation of requirements variability.
#
Author,
year
[reference]
Super-
structure
Concepts related to C&V
Key Contribution
1
Muthig
(2002)
UML: use
cases
«variant» use cases
The «variant» stereotype, targeted at representing
variability in use cases
2
Maßen and
Lichter
(2002)
UML: use
cases
Option, alternative and optional
alternative use cases
Extension to the UML metamodel to incorporate two
new relationships to represent variability at the level of
requirements modelling with use cases
3
Halmans and
Pohl (2003)
UML: use
cases
Mandatory and optional variation
points
Extensions to use case diagrams to represent and
communicate variability relevant to the customer
(additional graphical elements proposed to explicitly
represent variation points and variability cardinality in
use case diagrams)
4
Gomaa
(2004)
UML: use
cases
«kernel», «optional» and
«alternative» use cases
«common feature», «optional feature»
and «alternative feature»
«zero-or-one-of feature group» and
«exactly-one-of feature group»
PLUS (Product Line UML-based Software engineering),
a model-driven approach for variability analysis, namely
at the requirements (use cases) level
5
Gomaa and
Shin (2004)
UML: use
cases
Kernel use case
Optional use case
Alternative use case
Multiple-view variability metamodeling approach, using
UML, namely in use case modelling
6
Webber and
Gomaa
(2004)
VPM
Four types of variation points:
Parameterization
Information hiding
Inheritance
Callback
VPM (Variation Point Model), a method that
contemplates a modelling view to capture requirements
together with variation points during the domain analysis
phase
7
Bachmann et
al. (2004)
No
specific
name
Variation point
Variant
Asset
Rationale
Variation (meta)model for the representation of
variability as a dedicated view connected to all the other
views of a system, namely the requirements view (e.g.
use cases)
8
Bühne et al.
(2005)
No
specific
name
Mandatory/optional variation point
Variant
Requirements artefact
Metamodel representing the structure of variability
information used for the documentation of requirements
across a single SPL or a set of SPLs, based on the
metamodel of Bachmann et al.
9
Bayer et al.
(2006)
CVM
Model and variation elements
Variability specification (variability
constraint and transformer)
Variation and resolution models
(resolution elements: value resolution
and type resolution)
CVM (Consolidated Variability Metamodel), which
systematizes different kinds of variability recurrently
present in SPL models and contemplates different
approaches of variability capturing, namely UML and
DSLs
10
Moros
(2008)
REMM
Requirement
Mandatory level type
Reusable and product catalogues
Reusable and product requirements
Parameter and parameter instance
REMM (Requirements Engineering MetaModel), which
allows specifying catalogues of reusable requirements
models, as well as defining specific product
requirements, namely by reusing previously modelled
requirements; furthermore, REMM allows requirements
engineers to define, in the same model, both optional
and parameterized requirements, which usually are
represented in feature models on the side
11
Alférez et al.
(2010)
VML4RE
Commonalities
Variabilities (optional feature,
variation point and variant)
VML4RE (Variability Modelling Language for
Requirements), which provides for a SPL requirements
modelling approach, comprised of variability
identification at the feature modelling level, as well as of
domain requirements description by means of use cases
and activity diagrams, and ultimately a (meta)model to
relate modelled features and requirements
12
Rouillé et al.
(2012)
No
specific
name
C&V concepts inherited from the CVL
Model-driven approach for the automatic derivation of
processes from software process lines using CVL to bind
requirements variability to process variability
13
Oliveira et
al. (2013)
FeDRE
Mandatory, optional and alternative
(OR or XOR) features
Requirement, requirements
specification, use case…
FeDRE (Feature-Driven Requirements Engineering)
approach, in which variability modeled through features
is realized into functional requirements, as well as
features themselves are further taken as input for use
case specification
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
166
implemented with the Xtext framework, which
means that RSL specifications are rigorous, and can
be automatically validated and transformed into
other representations and formats. A lightweight tool
support is provided with the ITLingo RSL Excel
template
2
publicly available at GitHub.
To provide for distributed access to its SRS
documents, as well as data manipulation features,
the ITBox Web-based platform extensively uses two
Google Web APIs: Google Drive API and Google
Sheets API. Thanks to this, the ITBox variability
modelling approach can automatically extract the
information in a SRS document, modify it, and
generate new documents and views if necessary.
This allowed automating the application of CVL
concepts to the context of RE Future work will focus
on expanding the views supported by RSL, allowing
to progress from modelling variability at the level of
Goals, Functional Requirements and Quality
Requirements to modelling variability at the level of
Stakeholders, Entities, Use Cases, etc., enabling a
much wider scope of variability points within the
spectrum of RE concerns. Furthermore, the long-
term goal of this research is to fully integrate this
variability modelling process within the ITLingo
approach for domain knowledge extraction from
natural language documents, expanding the source
of the variability modelling process from semiformal
SRS documents to more unstructured ad-hoc SRSs
in natural language.
ACKNOWLEDGEMENTS
This work was partially supported by national funds
under FCT projects UID/CEC/50021/2013 and
CMUP-EPB/TIC/0053/2013.
REFERENCES
Alferez, M., et al., 2010. Multi-view composition
language for software product line requirements.
LNCS, 5969:103122.
Bachmann, F., et al., 2004. A Meta-model for
Representing Variability in Product Family
Development. 5th International Workshop on Product-
Family Engineering (PFE-5) Springer-Verlag.
Bayer, J. et al., 2006. Consolidated Product Line
Variability Modeling," in Software Product Lines -
Research Issues in Engineering and Management,
Springer-Verlag.
2
https://github.com/RSLingo/RSL-Excel-Template
Bettini, L., 2016. Implementing Domain-Specific
Languages with Xtext and Xtend. Packt Publishing
Ltd.
Blanes, D., González-Huerta, J., and Insfran, E., 2014. A
multimodel approach for specifying the requirements
variability on software product lines. 23rd
International Conference on Information Systems
Development, 329336.
Bosch, J., et al., 2002, "Variability Issues in Software
Product Lines," in 4th International Workshop on
Product Family Engineering (PFE-4) Bilbao, Spain:
Springer-Verlag.
Bühne, S., Lauenroth, Pohl, K., 2005. Modelling
Requirements Variability across Product Lines," in
13th IEEE International Conference on Requirements
Engineering, IEEE Computer Society.
Coplien, J., Hoffman, D., Weiss, D., 1998. Commonality
and Variability in Software Engineering, IEEE
Software, vol. 15, pp. 37-45.
Davis, A., 2005. Just enough requirements management:
Where Software Development Meets Marketing.
Fernandes, J., 2016. REBox: Collaborative Environment
for Requirements Engineering, MSc Thesis, IST,
Universidade de Lisboa.
Ferreira, D., Silva, A. R. 2013a. RSL-PL: A Linguistic
Pattern Language for Documenting Software
Requirements, in Proceedings of RePa’13, IEEE CS.
Ferreira, D., Silva, A.R, 2012. RSLingo: An Information
Extraction Approach toward Formal Requirements
Specifications. In Proc. of the 2nd MoDRE workshop.
IEEE, 39-48.
Ferreira, D., Silva, A.R., 2013. RSL-IL: An Interlingua for
Formally Documenting Requirements. In Proc. of the
3rd MoDRE workshop. IEEE CS.
Gomaa, H., 2004. Designing Software Product Lines with
UML: From Use Cases to Pattern-Based Software
Architectures. Addison-Wesley.
Gomaa, H., Shin, M. E., 2004. Multiple-View Meta-
modeling Approach for Variability Management in
Software Product Lines," in 8th International
Conference on Software Reuse (ICSR-8), Springer-
Verlag.
Halmans, G. Pohl, K., 2003. Communicating the
Variability of a Software-Product Family to
Customers, Software and Systems Modeling, vol. 2,
pp. 15-36.
Maßen, T. v. d., Lichter, H., 2002. Modeling Variability
by UML Use Case Diagrams, in International
Workshop on Requirements Engineering for Product
Lines (REPL 2002).
Moros, B., Vicente-Chicote, C., Toval, A., 2008.
Metamodeling variability to enable requirements
reuse. CEUR Workshop Proceedings, 337:140154.
Muthig, J. D., 2002. Product Line Modeling with Generic
Use Cases, in Workshop on Techniques for Exploiting
Commonality Through Variability Management,
Springer-Verlag.
Nielsen, J., Landauer, T. K., 1993. A Mathematical Model
of the Finding of Usability Problems. In Proceedings
of the INTERACT '93 and CHI '93. ACM.
Variability Specification and Resolution of Textual Requirements
167
Oliveira, R. P., et al., 2013. A feature-driven requirements
engineering approach for software Product Lines.
Proceedings of 7th Brazilian Symposium on Software
Components, Architectures and Reuse.
OMG, 2012. OMG Common Variability Language (CVL)
OMG Revised Submission.
Pohl, K., 2010. Requirements Engineering: Fundamentals,
Principles, and Techniques, Springer.
Ribeiro, A., Silva, A. R., 2014. XIS-Mobile: A DSL for
Mobile Applications, Proceedings of the 29th Annual
ACM Symposium on Applied Computing (SAC),
ACM.
Ribeiro, A., Silva, A. R., 2014a. Evaluation of XIS-
Mobile, a Domain Specific Language for Mobile
Application Development. Journal of Software
Engineering and Applications, 7(11), 906-919.
Rouille, E., et al., 2012. Leveraging CVL to manage
variability in software process lines. Proceedings Asia-
Pacific Software Engineering Conference, APSEC,
1:148157, 2012.
Savić, D., et al., 2015. Use Case Specification Using the
SILABREQ Domain Specific Language, in
Computing and Informatics Journal, 34(4):877910.
Silva, A. R., et al., 2014. Towards a System Requirements
Specification Template that Minimizes Combinatorial
Effects, Proceedings of QUATIC’2014 Conference,
IEEE CS.
Silva, A. R., 2015. Model-driven engineering: A survey
supported by the unified conceptual model. Computer
Languages, Systems & Structures, 43(October 2015),
139-155.
Silva, A. R., 2015a. SpecQua: Towards a Framework for
Requirements Specifications with Increased Quality,
in Lecture Notes in Business Information Processing
(LNBIP), LNBIP 227, Springer.
Silva, A. R., 2017. Linguistic Patterns and Linguistic
Styles for Requirements Specification (I): An
Application Case with the Rigorous RSL/Business-
Level Language, Proceedings of EuroPLOP’2017,
ACM, 2017.
Silva, A. R., 2018. Rigorous Requirements Specification:
Specification of Use Cases with the RSLingo RSL
Language. INESC-ID Technical Report.
Silva, A. R., et al., 2007. XIS UML Profile for eXtreme
Modeling Interactive Systems, in Proceedings of the
MOMPES 2007, IEEE Computer Society.
Silva, A. R., Fernandes, J., Azevedo, S., 2017. Variability
Aspects at a Textual Requirements Specification
Level. IEEE 25th International Requirements
Engineering Conference Workshops (REW), IEEE
Computer Society.
Verelst, J., et al., 2013. Identifying Combinatorial Effects
in Requirements Engineering, Proceedings of Third
Enterprise Engineering Working Conference (EEWC
2013), Advances in Enterprise Engineering, LNBIP,
Springer.
Webber, D. L., Gomaa, H., 2004. Modeling Variability in
Software Product Lines with the Variation Point
Model, Science of Computer Programming, vol. 53,
pp. 305-331.
ICEIS 2018 - 20th International Conference on Enterprise Information Systems
168