Quality of Requirements Specifications
A Framework for Automatic Validation of Requirements
Alberto Rodrigues da Silva
Engenharia Informática, Instituto Superior Técnico, 1049-001 Lisboa, Portugal
INESC-ID, Rua Alves Redol, 9, 1000-029 Lisboa, Portugal
Keywords: Requirements Specification, Quality of Requirements Specification, Requirements Validation.
Abstract: Requirements specifications describe multiple technical concerns of a system and are used throughout the
project life-cycle to help sharing a common understanding among the stakeholders. In spite a lot of interest
has been given to manage the requirements lifecycle, which resulted in numerous tools and techniques
becoming available, however, little work has been done that address the quality of requirements
specifications. Most of this work still depends on human-intensive tasks made by domain experts that are
time-consuming and error prone, and have negative consequences in the success of the project. This paper
proposes an automatic validation approach that, with proper tool support, can help to mitigate some of these
limitations and therefore can increase the quality of requirements specifications, in particular those that
concerns consistency, completeness, and unambiguousness.
1 INTRODUCTION
Requirements Engineering (RE) intends to provide a
shared vision and understanding of the system to be
developed between business and technical
stakeholders (Pohl, 2010; Sommerville and Sawyer,
1997; Robertson and Robertson, 2006). The adverse
consequences of disregarding the importance of the
early activities covered by RE are well-known
(Emam and Koru, 2008; Davis, 2005). System
requirements specification, software requirements
specification or just requirements specifications
(SRS) is a document that describes multiple
technical concerns of a software system (Pohl, 2010;
Sommerville and Sawyer, 1997; Robertson and
Robertson, 2006). An SRS is used throughout
different stages of the project life-cycle to help
sharing the system vision among the main
stakeholders, as well as to facilitate communication
and the overall project management and system
development processes.
For achieving an effective communication,
everyone should be able to communicate by means
of a common language, and natural language
provides the foundations for such language. Natural
language is flexible, universal, and humans are
proficient at using it to communicate with each
other. Natural language has minimal adoption
resistance as a requirements documentation
technique (Pohl, 2010; Robertson and Robertson,
2006). However, although natural language is the
most common and preferred form of requirements
representation (Kovitz, 1998), it also exhibits some
intrinsic characteristics that often present themselves
as the root cause of many requirements quality
problems, such as incorrectness, inconsistency,
incompleteness and ambiguousness (Pohl, 2010;
Robertson and Robertson, 2006). From these causes,
in this paper we emphasize inconsistency and
incompleteness because avoiding – or at least
mitigating – them requires significant human effort
due to the large amount of information to process
when combined with inadequate tool support,
namely to perform the typical requirements
linguistic analysis. On the other hand, although
ambiguity and incorrectness – by definition – cannot
be fixed without human validation (IEEE Computer
Society, 1998), we consider that the tasks required to
minimize the effects of both inconsistency and
incompleteness (and also ambiguity at some extent)
can be automated if requirements are expressed in a
suitable language, and if adequate tool support is
provided.
In our recent research we consider the RSLingo
approach (Ferreira and Silva, 2012) as a starting
point for it. RSLingo is a recent and ambitious
approach for the formal specification of software
requirements that uses lightweight Natural Language
96
Rodrigues da Silva A..
Quality of Requirements Specifications - A Framework for Automatic Validation of Requirements.
DOI: 10.5220/0004951900960107
In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 96-107
ISBN: 978-989-758-028-4
Copyright
c
 2014 SCITEPRESS (Science and Technology Publications, Lda.)

Processing (NLP) techniques (Bird, et al., 2009) to
translate informal requirements – originally stated in
unconstrained natural language by business
stakeholders – into a formal representation provided
by a language specifically designed for RE. Unlike
other RE approaches, which use languages that
typically pose some difficulties to business
stakeholders (namely graphical modeling languages
such as UML or SysML, whose target audience are
engineers), RSLingo encourages business
stakeholders to actively contribute to the RE process
in a collaborative manner by directly authoring
requirements in natural language. To achieve this
goal, RSLingo provides (1) a language for defining
linguistic patterns that frequently occur in
requirements specifications written in natural
language (the RSL-PL language), (2) a language that
covers most RE concerns, in order to enable the
formal specification of requirements (the RSL-IL
language), and (3) an information extraction
mechanism that, based on the linguistic patterns
defined in RSL-PL, translates the captured
information into a formal requirements specification
encoded in RSL-IL (Ferreira and Silva, 2013).
However, RSLingo does not provide yet any
guarantees that the RSL-IL specifications have the
required quality. So, our research starts from
requirements specified in RSL-IL, and not in natural
language, because the challenges to produce RSL-IL
specifications from natural language specifications
was already discussed and proposed (Ferreira and
Silva, 2012; Ferreira and Silva, 2013; Ferreira and
Silva, 2013a). Therefore, the main contribute of this
research is to propose and discuss that, with proper
tool support, we can increase the overall quality of
SRSs as well as the productivity associated to
documentation and validation tasks. To the best of
our knowledge, and apart from our recent poster on
this issue (Silva, 2014), no further works have been
proposed before in relation to this complex approach
and the way we support automatic validation of
SRSs.
The structure of this paper is as follows. Section
2 introduces the background underlying this
research. Section 3 introduces a simple running
example that was carried out to validate the research.
Section 4 describes the proposed approach for
automatic validation of RSL-IL specifications.
Section 5 describes the main aspects of the
SpecQuA (Requirements Specification Quality
Analyzer) tool with the purpose to show and discuss
the practicability of the proposed approach. Section
6 discusses some tests that are being implemented in
the context of the toolset, in particular related to
consistency, completeness and unambiguousness.
Finally, Section 7 presents the conclusion and ideas
for future work.
2 BACKGROUND
This section briefly introduces the definition for
SRS’s quality attributes, overviews requirements
specification languages, introduces some
considerations on requirements validation, and
briefly introduces the RSLingo approach.
2.1 SRS’s Quality Attributes
Writing good requirements is a human-intensive and
error prone task. Hooks summarize the most
common problems in that respect (Hooks, 1993):
making bad assumptions, writing implementation
(How) instead of requirements (What), describing
operations instead of writing requirements, using
incorrect terms, using incorrect sentence structure or
bad grammar, missing requirements, and over-
specifying. To achieve quality SRSs must embody
several characteristics. For example, the “IEEE
Recommended Practice for Software Requirements
Specifications” is a popular reference which states
that a good-quality SRS should be (IEEE Computer
Society, 1998): correct, unambiguous, complete,
consistent, prioritized, verifiable, modifiable, and
traceable. From all of them, we briefly discuss those
that are most relevant for the scope of this paper.
Complete. A SRS is considered complete if it
fulfills the following conditions: (1) Everything that
the system is supposed to do is included in the SRS;
this can lead us to a never ending cycle of
requirements gathering; (2) Syntatic structures filled,
e.g.: all pages numbered; all figures and tables
numbered, named, and referenced; all terms defined;
all units of measure provided; and all referenced
material present; and (3) No sections or items
marked with "To Be Determined" (TBD) or
equivalent sentences. Completeness is probably the
most difficult quality attribute to guarantee. In spite
that some elements are easy to detect and correct
(e.g., empty sections, TBD references), but one
never knows when the actual requirements are
enough to fully describe the system under
consideration. To achieve completeness, reviews of
the SRS by customer or users are essential.
Prototypes also help raise awareness of new
requirements and help us better understand poorly or
abstractly defined requirements.
Consistent. A SRS is consistent if no
QualityofRequirementsSpecifications-AFrameworkforAutomaticValidationofRequirements
97

requirements described in it conflict among
themselves. Disagreements among requirements
must be resolved before development can proceed.
One may not know which (if any) is consistent until
some research is done. When modifying the
requirements, inconsistencies can slip in undetected
if only the specific change is reviewed and not any
related requirements.
Unambiguous. A SRS is unambiguous if every
requirement stated there has only one possible
interpretation. The SRS should be unambiguous both
to those who create it and to those who use it.
However, these groups of users often do not have
the same background and therefore do not tend to
describe software requirements the same way.
Ambiguity is a very complex phenomenon because
natural language is inherently ambiguous (a simple
word can have multiple meanings) and most of the
times this ambiguity is unintentionally introduced.
The most recommended solution to minimize
ambiguity is the use of formal or semi-formal
specification languages rather than or in complement
to natural languages. Also, the use of checklists and
scenario-based reading are common
recommendations (Kamsties et al., 2001).
2.2 Requirements Specification
Languages
Traditionally, the requirements documentation
activity has consisted in creating a natural language
description of the application domain, as well as a
prescription of what the system should do and
constraints on its behavior (van Lamsweerde, 2009).
However, this form of specification is both
ambiguous and, in many cases, hard to verify
because of the lack of a standard computer-
processable representation (Foster et al., 2004).
Apparently, the usage of formal methods could
overcome these problems. However, this would only
address part of the problem, as we still need to take
care while interpreting the natural language
requirements to create a formal specification, given
that in general engineers often misinterpret natural
language specifications during the design phase. The
same occurs with the attempt to directly create
formal requirements specifications, especially when
the real requirements are not discovered and
validated at first by the business stakeholders
(Young, 2003). Thus, the usage of such formal
languages entails an additional misinterpretation
level due to the typically complex syntax and
mathematical background of formal method
languages (Foster et al., 2004). Given that formal
methods are expensive to apply – because they
require specialized training and are time-consuming
(Sommerville and Sawyer, 1997) –, creating formal
requirements specifications might have a negative
impact.
In the attempt of getting the best from both
worlds – the familiarity of natural language and the
rigorousness of formal language –, one can
document requirements with controlled natural
languages, which are languages engineered to
resemble natural language. However, these
languages are only able to play the role of natural
language to a certain extend: while they are easy to
read, they are hard to write without specialized tools
(Fuchs et al., 2008; Kuhn, 2010).
Finally, there are graphical approaches, such as
UML and SysML for traditional RE modeling, and
i*, KAOS and Tropos notation for Goal-Oriented
RE (Pohl, 2010). However, these graphical
languages are less expressive than natural language
and cannot be regarded as a common language to
communicate requirements, because business
stakeholders still require training to understand
them. Also, despite being “easier to understand”
than formal method languages, these graphical
modeling languages are regarded as less powerful in
terms of analytical capabilities because they often
lack tool support to enforce the implicit semantics of
their modeling elements, or might even intentionally
leave some unspecified parts of the language itself to
ease its implementation by tool vendors, in which
case they are considered as semi-formal. Some
authors even argue that the simplicity of these
languages comes precisely from this lack of
semantic enforcement: it is easy to create models
because “anything goes” (a loose way of saying that
they are not decidable) (Davis, 2005).
Furthermore, the usage of graphical languages
might cause another problem when the modeler
includes too much detail in the diagram, cluttering it
and thus affecting its readability. Therefore, despite
the existence of such graphical approaches, textual
natural language specifications are still regarded by
many as the most suitable, fast, and preferred
manner to initiate the requirements development
process of the envisioned software system.
2.3 Requirements Validation
There is not a consensus in the literature about the
use of the terms “verification” and “validation” in
the context of RE. However, in this paper we adopt
the term as suggested by Pohl and Robertsons, that
define requirements validation as checking
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
98

requirements with the purpose of detecting errors
such as inconsistencies, ambiguities, and ignored
standards. These authors recommend the use of the
term “verification” to denote the formal
(mathematical) proof of properties of a model,
related to properties of concurrent systems, such as
safety or absence of deadlocks (Pohl, 2010;
Robertson and Robertson, 2006).
Considering the premises regarding the current
practices of the requirements documentation and
validation activities – such as inspections,
walkthroughs, checklists, or using scenarios and
prototypes (Pohl, 2010; Sommerville and Sawyer,
1997; Robertson and Robertson, 2006; Santos, et al.,
2010) –, we consider that the quality of a SRS still
strongly depends on the expertise of whoever is
performing this activity. Given that most RE
activities are still manually performed and involve a
large amount of information, to produce a high
quality requirements specification one requires an
experienced requirements engineer with a vast skills
set.
However, to avoid large discrepancies in the
results of the RE process, we advocate that the
quality of requirements specifications and the
productivity of the requirements documentation
activity can be increased through the formalization
of requirements. The computer-processable
requirements specifications that are obtained through
such a formalization process enable the automation
of some manual validations – which must be
performed during the requirements documentation
activity – thus relieving requirements engineers from
the burden of manually handling a large amount of
information to identify requirements quality
problems. Additionally, the degree of formalization
achieved can be employed to generate
complementary artefacts to better support RE tasks,
such as requirements validation.
2.4 The RSLingo Approach
RSLingo is an approach for the formal specification
of software requirements that uses lightweight
Natural Language Processing (NLP) techniques to
(partially) translate informal requirements –
originally stated by business stakeholders in
unconstrained natural language – into a formal
representation provided by a language specifically
designed for RE (Ferreira and Silva, 2012).
The name RSLingo stems from the paronomasia
on "RSL" and "Lingo". On one hand, "RSL"
(Requirements Specification Language) emphasizes
the purpose of formally specifying requirements.
The language that serves this purpose is RSL-IL, in
which "IL" stands for Intermediate Language
(Ferreira and Silva, 2013). On the other hand,
"Lingo" expresses that its design has roots in natural
language, which are encoded in linguistic patterns
used during by the information extraction process
(Cunningham, 2006; Bird, et al., 2009) that
automates the linguistic analysis of SRSs written in
natural language. The language designed for
encoding these RE-specific linguistic patterns is
RSL-PL, in which "PL" stands for Pattern Language
(Ferreira and Silva, 2013a). These linguistic patterns
are used by lightweight NLP techniques and, when
combined with general-purpose linguistic resources
(e.g., WordNet
,
(http://wordnet.princeton.edu), and
VerbNet
(http://verbs.colorado.edu/~mpalmer/
projects/verbnet.html)), enable the extraction of
relevant information from the textual representations
of requirements. Finally, the extracted information
with these lightweight NLP techniques is formally
specified in RSL-IL notation through predefined
transformations from RSL-PL into RSL-IL. Upon a
match of a requirement's textual representation with
one of the RSL-PL linguistic patterns, a
transformation should become active. This
transformation takes into consideration the semantic
roles of each word within the linguistic pattern, and
drives the mapping between RSL-PL and RSL-IL.
RSL-IL provides several constructs that are
logically arranged into viewpoints according to the
specific RE concerns they address (Ferreira and
Silva, 2013). These viewpoints are organized
according to two abstraction levels: business and
system levels.
To properly understand and document the
business context of the system, the business level of
the RSL-IL supports the following business-related
concerns, namely: (1) the concepts that belong to the
business jargon; (2) the people and organizations
that can influence or will be affected by the system;
and (3) the objectives of business stakeholders
regarding the value that the system will bring.
Considering these concerns, business level
requirements comprise respectively the following
viewpoints: Terminology, Stakeholders, and Goals.
On the other hand, at the system level, the RSL-
IL supports the specification of both static and
dynamic concerns regarding the system, namely: (1)
the logical decomposition of a complex system into
several system elements, each with their own
capabilities and characteristics, thus providing a
suitable approach to organize and allocate
requirements; (2) the requirements that express the
desired features of the system, and also the
QualityofRequirementsSpecifications-AFrameworkforAutomaticValidationofRequirements
99

constraints and quality attributes; (3) the data
structures aligned with the business jargon, their
relations, and a logical description of their attributes;
and (4) the actors, functions, event-based state
transitions, and use cases that further detail the
aforementioned requirements. Considering these
concerns, the System Level comprises the following
viewpoints: Architectural; Requirements; Structural;
and Behavioral, respectively.
3 RUNNING EXAMPLE
This example is meant to assist the reader in better
understanding the RSL-IL constructs, and also to
shed some light on the advantages of its application
in a real-world scenario, by presenting RSL-IL
pertaining to a requirements specification developed
for a case study that was carried out to validate this
research. The scope of this project is devoted to
support a web-based community of patients infected
with HIV/AIDS and/or Hepatitis viruses.
Figure 1 shows a very simple example of a RSL-
IL specification, namely including the definition of
some terms and goals.
4 THE GENERAL APPROACH
Figure 2 suggests the general operation of the SRS
validation process with its main input, outputs, and
supporting resources. The major input is the
Requirements Specs file that is the SRS
defined in the RSL-IL concrete syntax like the one
illustrated in Figure 1. The outputs are the
Parsing Log file and the Test Reports file
with the errors and warnings detected by the tool
during its execution, respectively during the
Parsing and the Validation processes.
Additionally, there are some supporting resources
used to better extend and support the tool at run-
time, namely: Quality Tests,
Configuration, and Lexical Resources.
Quality Tests consist in a set of tests
directly implemented in a given programming
language and having additional metadata such as
name, description and quality criteria type. (Figure 7
gives an example of such test directly implemented
in C#.) Configuration is a resource used to
support the validation in a flexible way. For
example, this resource can allow requirements
engineers to configure the level of completeness

A
mongotherstheAIDSPortalprojectshouldsatisfythefollowinggoals:
‐ The AIDSPortal web application must act as a web‐portal aboutHIV/AIDS and Hepatitis,inparticular (i) To publish
scientificpapers,and(ii)Topublishmultimediaresources,
…

(PROJECT id:"prj‐aidsportal" name:"AIDSPortal" description:"This project consists in the development, configuration,
andmigrationoftheAIDSPortalwebsite."
(GLOSSARY

#stakeholderterms
(TERMid:"trm‐sdnt"word:"AIDSnet"
definition:"Anorganizationdevotedtothestudyofinfectiousdiseases."pos:@noun
(SYNONYMS
(TERMid:"trm‐cln‐orgn"word:"clientorganization"synset:"customer.n.01;organization.n.01"definition:"
[aperson]Someone
whopaysforgoodsorservices..."))
)...)

(STAKEHOLDERS
(ORGANIZATIONid:"stk‐sdnt"role:"clientorganization"name:"AIDSnet"category:@business.customer
 description:"Theclientorganizationthatrequested..."...)
 ...)

(GOALS
(GOALid:"gol‐info"text:"TheAIDSPortalwebapplicationmustactasaweb‐portalaboutHIV/AIDSandHepatitis"
source:"clientorganization"criticality:@high
#asimplegoalderivationwithasinglesubgoal
(DECOMPOSITIONtype:@and
(GOALid:"gol‐info‐dcmn"text:"Topublishscientificpapers."
source:"clientorganization"
criticality:@high))
...))
...)
Figure 1: The original specification and the equivalent in RSL-IL.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
100

Figure 2: Overview of the validation process.
Figure 3: SpecQuA Architecture.
needed for their purpose, in a project basis. This
means that different projects may have different
needs regarding completeness of their specifications.
Finally, Lexical Resources are public domain
resources (such as WordNet or VerbNet) that
support some tests, mostly those related with
linguistic issues. Figure 3 depicts the SpecQuA
software architecture in generic terms, with its main
blocks: WebApp, WebAPI and Core.
5 TOOL SUPPORT
The proposed high-level approach has to be
implemented by a concrete software tool in order to
offer a real interest and utility. Due to that we have
implemented the SpecQuA (Requirements
Specification Quality Analyzer) tool with the
purpose to show and discuss the practicability of this
approach.
The SpecQuA has the following objectives. First,
provide SRS's quality reports: for a given RSL-IL
specification, the system should be able to provide
results for quality tests applied to that specification.
Second, easily add and configure new quality tests:
it should be easy to develop and add new quality
tests in order to extend the tool; additionally it
should be easy to configure those tests. Third, Web
collaborative workspace: the tool should be
accessible via a Web browser and should provide the
QualityofRequirementsSpecifications-AFrameworkforAutomaticValidationofRequirements
101

means for multiple users to work together while
specifying, analyzing and validating RSL-IL
specifications. (For the aim of this paper we only
focus on the first SpecQuA’s objective; a
preliminary prototype is available at
http://specqua.apphb.com).
SpecQuA WebApp. The WebApp layer
corresponds to how users interact with the tool. In a
3-tier layer architecture this corresponds to the
presentation layer, although this is more than a
simple frontend: the WebApp is a Web-based
independent application with its own logic that
connects to SpecQuA Core via its API. At the core
of WebApp are AngularJS (http://angularjs.org),
Bootstrap (http://twitter.github.io/bootstrap/), and
jQuery (http://jquery.com/) technologies that
combined make developing frontends painless and
with a modern look and feel.
SpecQuA WebAPI. This intermediate layer
serves as the Application Programming Interface
(API) that exposes all the relevant functions that
Core provides to the outside. The ServiceStack
(http://servicestack.net/) framework was used to
provide all the REST architecture. Besides serving
as a proxy between WebApp and Core, the API can
still be accessed from other clients that do not intend
to use the main frontend but still want to take
advantage of SpecQuA analyses or data resources.
SpecQuA Core. This layer is the kernel of the
SpecQuA tool and this is where all the action takes
place. A key feature for the system SpecQuA is the
ease to add new tests and this is implemented using
two advanced programming techniques (i.e.,
dependency injection and reflection) which
combined make it possible to associate new quality
tests to the tool with minimal effort. At system
startup, and based on referenced assemblies, all
classes that implement a specific interface become
available to the system as new quality tests, and are
logically grouped into analyses. Currently, this
grouping of testing analysis is performed using a
configuration file as exemplified in Fig. 4.
All tests are independent from each other and
may have its own particular configuration. This
configuration is defined in xml format and has no
restriction on the schema level: it is up for those who
develop the test, to define the schema and interpret it
in the respective test. Each test may or may not have
a default configuration.
The Parser component is responsible to parse the
input RSL-IL text and map it to the Domain Model
(in the internal database). This parsing is done by
ANTLR (http://www.antlr.org/) using a grammar
specific for the RSL-IL language. With this
grammar, ANTLR generates a parser and a lexer that
can be used to validate the syntax and the semantic
of a given input. If the input does not have errors,
then the result is a representation of the domain
model entities that can be tested. This grammar has
some similarities with the BNF notation as
expressed in Fig. 5.
6 DISCUSSION
Despite having a simple interface, a lot is done in the
background when carrying out the analysis of a
Figure 4: Example of a SpecQuA’s configuration file.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
102

publicspecificationreturns[ProjectSpecificationSpecification]
:spec=projectDef{$Specification=$spec.specification;};

projectDefreturns[ProjectSpecificationspecification]
:{$specification=newProjectSpecification();}
LPARPROJECT(retAtt=attribute{CollectAttribute($specification,$retAtt.att.Key,…;})*
(LPARgloss=glossary{$specification.Glossary=$gloss.glossary;}RPAR)?
(LPARstk=stakeholders{$specification.Stakeholders=$stk.stakeholders;}
RPAR)?
(LPARgls=goals{$specification.Goals=$gls.goals;}RPAR)?
(LPARsystem{}RPAR)?
RPAR;
…
Figure 5: An excerpt from the RSL-IL grammar for ANTLR.
Figure 6: Excerpt of a Report Test for the AIDSPortal example.
specification. In this case, when the user wants to
validate the specification, it is parsed with the
specific ANTLR grammar. If any syntactic or
semantic error is detected in the specification, the
user is alerted and the process stops. However, if the
specification is successfully parsed, all the
configured tests are run against the specification and
a report is shown to the user such as the example
shown in Figure 6. In the following subsections we
introduce and discuss some tests that are being
implemented in the context of the toolset.
6.1 Consistency Validation
The consistency validation enforces that the
information model underlying the RSL-IL
specification is well-formed, or consistent in
accordance with the RSL-IL metamodel which
involves, for example, the following concrete
validations.
Consistent Attribute Values. The toolset verifies
whether the value assigned to a given attribute is
valid based on the semantics of its RSL-IL construct.
For instance, the toolset can systematically enforce
that every id attribute follows the predefined prefix
of each RSL-IL construct. Also, the toolset can also
provide a short mnemonic for the id attribute based
on the word attribute of the related Term, which is
more meaningful than just a numeric sequence.
The combination of the specific prefix with this
mnemonic allows one to better understand when two
RSL-IL constructs of different types refer to the
same underlying concept (e.g., they describe
different concerns about the same business notion).
Consistent Numeric Sequences. There are
several attributes in RSL-IL constructs that follow a
QualityofRequirementsSpecifications-AFrameworkforAutomaticValidationofRequirements
103

Figure 7: An excerpt of a concrete test.
certain numeric sequence. For instance, the toolset
checks the order attribute of each Sentence within a
given Requirement. Also, the toolset verifies the
values assigned to the label attributes of a given
UseCase’s Steps. In all these cases, the toolset must
ensure that each construct was assigned a unique
numeric value of that sequence, and that all the
assigned numbers follow a monotonic increasing
sequence without gaps.
Referential Integrity. The toolset must check and
enforce that those relationships between different
RSL-IL constructs are properly defined in terms of
the values (i.e., references) assigned to the attributes
that support the establishment of such relationships.
The most obvious case is given by the strong
dependency of most RSL-IL constructs on a Term
that unambiguously defines the semantics of the
underlying concept. Thus, the toolset must check
whether all RSL-IL constructs that depend on the
Terminology viewpoint effectively provide a valid
reference for a previously defined Term through its
id. That is the example of the test shown in Figure 7
that checks if all Stakeholders are referenced as
Terms defined in the glossary.
Another important aspect of this validation is
also to support for the resolution of Term references
based on their acronym or word values, instead of
only relying on the value of its id attribute.
Although we are illustrating this sort of
validations mostly based on the Terminology
viewpoint, there are similar cases in other RSL-IL
viewpoints. For instance, this problem is similar to
the validation performed regarding the source
attribute of a given Goal, which should be resolved
to a well-defined Stakeholder.
6.2 Completeness Validation
The completeness validation is based on the test’s
configuration resource that enables the definition of
the level of completeness required for each RSL-IL
specification. This level of completeness varies on a
project basis or even, for the same project, along the
timeline according the needs of the project team. We
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
104

consider three levels of completeness:
Completeness at Model Level. At the macro
level, one can define which viewpoints are required
for considering a concrete RSL-IL specification to
be complete. For example, during the initial stage of
a project lifecycle, one may only require the
Terminology, Stakeholders, and Goals viewpoints to
consider the specification as being complete. On the
other hand, if the project is running in a more
advanced stage (for instance, after a couple of
iterations), the remaining System Level viewpoints
should be also considered in order to provide a
complete requirements specification.
Completeness at Viewpoint Level. For each
viewpoint one can define which constructs are
mandatory or optional. For example, for the
Behavioral viewpoint one might only consider as
being relevant the existence of the Function
construct (and not of Event) in order to consider that
viewpoint as being complete.
Completeness at Construct Level. For each
construct (e.g., Term, Stakeholder, Goal, Entity, Use
Case) one can define which attributes are mandatory
or optional. For example, for the Goal construct (see
Figure 1) one can define the criticality as a
mandatory attribute and the source (a reference for
the Stakeholder responsible for that goal) as an
optional attribute. Still at construct level, we can
enforce that the names of some of these constructs
(e.g., the names of actors and entities) should be
defined as a unique term in the Terminology
viewpoint.
6.3 Unambiguousness Validation
While in a formal specification (such as in RSL-IL)
inconsistencies and incompleteness can be
automatically detected, ambiguities deal directly
with the meaning of those specifications, thus they
are hard to be detected by automatic processes.
Consequently, ambiguity tends to be detected mostly
by human intervention, for example through analysis
and inspection of the specification and through the
use of prototypes. However, regarding this semantic
level, still some automatic validation can be applied
to reduce ambiguity, such as those discussed below.
Semantic Analysis. First, based on general-
purpose linguistic resources that encode world
knowledge, the toolset can further verify the
semantic validity of relations established between
RSL-IL constructs, especially those strongly related
with the natural language representation of concepts.
For instance, an advanced validation feature consists
in using WordNet to check whether the value of the
word attribute of synonym Terms are indeed
synonyms of the word attribute’s value of the
primary Term to which they are associated. Second,
the information encoded within WordNet can be
used to cross-check whether the Term associated
with a given Stakeholder (through its role attribute)
is aligned with the classification provided by the
StakeholderType enumeration based on the lexname
attribute of the WordNet synset referred by the
synset attribute’s value of that Term. Third, and still
regarding the relations between different
Stakeholders, the toolset must verify the semantics
of the hierarchical composition of these RSL-IL
constructs. For instance, it does not make sense to
specify that a Stakeholder whose type is
“group.organizational” is MemberOf of another
Stakeholder whose type is “individual.person”. This
means that the hierarchical Stakeholders
composition must follow the implicitly semantics
entailed in the values of the StakeholderType
enumeration, which are ordered from broader groups
to more specific entities. Fourth, the toolset can
determine whether the relation between a given
RSL-IL construct and a Term is semantically valid
based on the pos attribute of that Term and the
semantics of the other RSL-IL construct. For
instance, it does not make sense to associate an
Entity with a Term whose part-of-speech (provided
by either its pos or synset attributes) classifies the
Term as a verb, instead of a noun. Fifth, another
example consists in checking whether nouns
associated with the agent thematic relation (e.g., the
subject of natural language sentences in the active
voice) are defined as Actors and, if so, whether they
can be traced back to the respective Stakeholders via
a shared Term.
Terminology Normalization. The RSL-IL
glossary (i.e., its Terminology viewpoint) formally
defined the terms associated with the main concepts
used throughout the requirements specification.
There are different types of relations that can be
established between terms, i.e. relations of type
synonym, antonym, and hyponym. One motivation
for using these relations is to reduce the number of
redundant Terms employed within the RSL-IL
specification, by providing a unique Term for each
concept. So, it is important to avoid the definition of
two or more synonym Terms by clearly stating
which one of them should be classified as the
primary Term, and the other(s) as secondary
Term(s). Based on this information, the toolset can
perform a systematic normalization of Terms
through a common find and replace process and,
consequently, reduce the requirements
QualityofRequirementsSpecifications-AFrameworkforAutomaticValidationofRequirements
105

specification’s ambiguity.
7 CONCLUSIONS
RE comprises several tasks including requirements
elicitation, analysis and negotiation, documentation
and validation. We recognize that natural language
is the most common and popular form to document
SRSs. However, natural language exhibits some
limitations, in particular those related with
requirements specification quality such as
incorrectness, inconsistency, incompleteness and
ambiguousness.
This research extends the RSLingo approach by
considering that the requirements are represented in
RSL-IL automatically extracted from natural
language specifications or authored directly by
users. This paper proposes a generic approach to
automatically validate these specifications and
describes the toolset (i.e., the SpecQuA software
tool) that shows the practicability and utility of this
proposal. The flexibility of the toolset and the cases
studies developed so far allows us to conclude that
the proposed approach helps to mitigate some of the
mentioned limitations, in particular in what respect
inconsistency, incompleteness and ambiguousness.
For future work we plan to develop other
features on the toolset, in particular those related
with the support of the collaborative environment,
allowing end-users to author and validate directly
their requirements (Ferreira and Silva, 2012),
eventually in different representations beyond
natural language and RSL-IL. Additionally, we still
intend to explore the integration of RE with Testing
(Moreira, Paiva and Memon, 2013) and Model
Driven Engineering approaches (Silva et al., 2007;
Savic, 2012; Ribeiro and Silva, 2014) to increase the
quality and productivity of Software Engineering in
general.
ACKNOWLEDGEMENTS
This work was supported by national funds through
FCT – Fundação para a Ciência e a Tecnologia,
under the PEst-OE/EEI/LA0021/2013 project.
Particular thanks to the students David Ferreira and
Joao Marques for their strong participation and
involvement in this research.
REFERENCES
Bird, S., Klein, E., Loper, E., 2009: Natural Language
Processing with Python. O'Reilly Media, 1st edition.
Cunningham, H., 2006. Information Extraction,
Automatic. In Encyclopedia of Language &
Linguistics, volume 5. Elsevier, 2nd edition.
Davis, A. M., 2005. Just Enough Requirements
Management: Where Software Development Meets
Marketing. Dorset House Publishing, 1st edition.
Emam, K., Koru, A., 2008. A Replicated Survey of IT
Software Project Failures. IEEE Software 25(5)
(September 2008) 84–90.
Ferreira, D., Silva, A. R., 2008. Wiki supported
collaborative requirements engineering, Proceedings
of the 4th International Symposium on Wikis. ACM.
Ferreira, D., Silva, A. R., 2012. RSLingo: An Information
Extraction Approach toward Formal Re-quirements
Specifications. In: Proc. of the 2nd Int. Workshop on
Model-Driven Requirements Engineering (MoDRE
2012), IEEE CS.
Ferreira, D., Silva, A. R., 2013. RSL-IL: An Interlingua
for Formally Documenting Requirements. In: Proc. of
the of Third IEEE International Workshop on Model-
Driven Requirements Engineering (MoDRE 2013),
IEEE CS.
Ferreira, D., Silva, A. R., 2013. RSL-PL: A Linguistic
Pattern Language for Documenting Software
Requirements. In: Proc. of the of Third International
Workshop on Requirements Patterns (RePa 2013),
IEEE CS.
Foster, H., Krolnik, A., and Lacey, D., 2004. Assertion-
based Design. Springer.
Fuchs, N. E., Kaljurand, K., Kuhn, T., 2008. Attempto
Controlled English for Knowledge Representation. In
Reasoning Web, Fourth International Summer School
2008, Lecture Notes in Computer Science, 5224,
Springer.
Hooks I., 1993. Writing Good Requirements, Proceedings
of the Third International Symposium of the INCOSE,
Volume 2.
IEEE Computer Society, 1998. IEEE Recommended
Practice for Software Requirements Specifications.
IEEE Std 830-1998.
Kamsties E., Berry D.M. and Paech B., 2001. Detecting
Ambiguities in Requirements Documents Using
Inspections, Proceedings of the First Workshop on
Inspection in Software Engineering.
Kovitz, B., 1998. Practical Software Requirements:
Manual of Content and Style. Manning.
Kuhn, T., 2010. Controlled English for Knowledge
Representation. Ph.D. thesis, Faculty of Economics,
Business Administration and Information Technology
of the University of Zurich.
Moreira, R., Paiva, A. C. R., Memon, A., 2013. A pattern-
based approach for GUI modeling and testing. In IEEE
24th International Symposium on Software Reliability
Engineering (ISSRE), IEEE CS.
Pohl, K., 2010. Requirements Engineering: Fundamentals,
Principles, and Techniques, 1st edition, Springer.
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
106

Ribeiro, A., Silva, A. R., 2014. XIS-Mobile: A DSL for
Mobile Applications. Proceedings of SAC 2014
Conference, ACM.
Robertson, S., Robertson, J. 2006. Mastering the
Requirements Process, 2nd edition. Addison-Wesley.
Santos, J., Moreira, A., Araújo, J., Goulão, M., 2010.
Increasing Quality in Scenario Modelling with Model-
Driven Development. In Proceedings of the QUATIC-
2010 Conference. IEEE CS.
Savic, D., et al., 2012. Use Case Specification at Different
Levels of Abstraction. In Proceedings of
QUATIC’2012 Conference, 2012, IEEE CS.
Silva, A. R., et al., 2007. Integration of RE and MDE
Paradigms: The ProjectIT Approach and Tools. IET
Software Journal,1(6), IET.
Silva, A. R., 2014. Quality of Requirements
Specifications: A Preliminary Overview of an
Automatic Validation Approach. In Proceedings of
ACM SAC’2014 Conference, ACM.
Sommerville, I., Sawyer, P., 1997. Requirements
Engineering: A Good Practice Guide. Wiley.
van Lamsweerde, A., 2009. From Worlds to Machines. In
A Tribute to Michael Jackson. Lulu Press.
Young, R., 2003. The Requirements Engineering
Handbook. Artech Print on Demand.
QualityofRequirementsSpecifications-AFrameworkforAutomaticValidationofRequirements
107