EA-Miner: Towards Automation in Aspect-Oriented Requirements Engineering - Transactions on Aspect-Oriented Software Development - page 35

methods (e.g., action verbs) and attributes (e.g., adjectives). Moreover, the NL-OOPS
approach does not clarify if there is some support for filtering the initial list of
candidates in terms of the tool's features and guidelines.
Recently, some work has focused [7, 8] on using information retrieval techniques
based on similarity measure for establishing links between requirements. In [8] a tool
called ReqSimile offers support for automatically assigning links between marketing
requirements (i.e., a customer wish) and business requirements (i.e., product
requirements) based on a similarity analysis calculated on the basis of comparing the
words contained in the requirements. The comparison is based on a technique called
“vector space model” which represents each requirement as a vector of words that can
be compared. The tool was evaluated using requirements of the Bann company
showing encouraging results (51% of correct links could be identified and 66% of
effort was saved).
Similar to [7, 8] the approach described in [42] shows successful results of
applying “vector space model” based similarity analysis to establish links between
source code and input documents such as user manuals.
Therefore, the previous approaches show that using NLP and information retrieval
techniques can provide a great deal of contribution on automating requirements
engineering. One problem that none of the previous approaches address is how to
identify and deal with crosscutting concerns at the requirements level. Moreover, our
approach is based on a precise and scalable NLP processor that offers part-of-speech
and semantic tagging that are the base for our automation heuristics.
The work addressing crosscutting in requirements can be represented by
Viewpoint-based AORE [16, 17], scenario-based AORE [18] as well as recent work
on goals and aspects [19], Theme/Doc [15] and multidimensional separation of
concerns [25]. Among these approaches the only one that supports automation for
identification of requirements concepts is Theme/Doc that provides a tool for semi-
automatic identification of crosscutting behaviours from requirements specification.
In this approach the developer has to read through input documentation and manually
provide a list of action words and their related entities as input to the Theme/Doc tool.
The advantage of EA-Miner over the above AORE mentioned approaches is the
use of precise part-of-speech and semantic tagging that helps to improve the
identification of concepts at the requirements level. Moreover, EA-Miner offers
mining capabilities for different AORE models as well as handles requirements
documents of varied structure (e.g., user manuals, interviews and others). Therefore,
EA-Miner can be seen as complementary to current AORE approaches offering
automation for their costly activities. For instance, we could implement a plug-in that
facilitates mining for themes which are subsequently modelled and analyzed using
Theme/Doc.
Regarding code level aspect mining approaches such as [36], what is important to
consider is how some techniques such as Fan-in analysis can be adapted to be used at
the requirements level. Aspect mining at RE level helps to achieve earlier separation
of concerns that can minimize refactorings at later stages such as code. However,
some crosscutting concerns (e.g., the code of a design pattern) can only be detected at
code level since they don't make sense at the requirements level. Therefore,
requirements and code aspect mining are complementary approaches that can be
applied whenever it suits best the problem at hand.