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

were domain experts but is also capable of revealing concerns that may have been
missed in analysis of large requirements sets.
6 Discussion
The main goal of EA-Miner is to offer automation for costly activities in the AORE
process which are mainly done manually such as identification and structuring. The
previous sections have clarified the role of EA-Miner in the process, its mining
analysis techniques, how it works in practice as well as an evaluation showing its
time-effectives and accuracy. Next we summarize some important issues about EA-
Miner that can be misunderstood.
The Degree of automation provided by EA-Miner as we mentioned before is not
provided with the intent of doing 100% of the work and replacing the requirements
engineer. EA-Miner automates costly activities and provides several features and
guidelines that help the users do their job efficiently and accurate as shown in our
evaluation.
Some might think that because EA-Miner focuses the attention of the engineer in
some identified abstractions and can offer filtering based on relevance (e.g., sort
viewpoints by frequency) that completeness is compromised and that the engineer
might miss relevant information and skip several requirements. This is not the case as
EA-Miner can also offer the full information (e.g., complete list of viewpoints)
showing, for example, a view that contains all the requirements originally obtained
from the input document. The goal of the tool is always to preserve the information
and offer functionalities that aid the user in visualizing and getting the best
understanding of the requirements.
Another misconception might be that the lexicon expansion of the tool might be
cumbersome. A mechanism for expanding the lexicon based on some known sources
of common broadly-scoped properties can offer partial automation for this task.
Moreover, when the lexicon gets populated with enough entries the need for other
updates becomes rare and easier.
The extensibility of EA-Miner to incorporate other AORE approaches is addressed
in two dimensions. In the tool dimension it is necessary to extend the tool's
architecture to offer the specific parsers and views (Fig. 4). For example if a new
AORE model (e.g., use-case based AORE) needs to be incorporated in the tool, the
first thing is to think about the mining techniques (e.g., a use case candidate is an
action verb—Sect. 3). After that, the specific parser for that model needs to be
implemented (basically a new class with an overridden parse method—Fig. 4).
Moreover, the internal representation of the model as java classes also needs to be
built (e.g., a use case can have several requirements and relationships with other use
cases).
Having a common meta-model to represent AORE models and a domain specific
language enables a higher level extension (e.g., defining what is a concern, what is a
crosscutting relationship, what are the general mining rules for that concern) of EA-
Miner's architecture. From this perspective, the requirements engineers using EA-
Miner can have some extension points in the plug-in where they are able to
incorporate new AORE models without having to change the code directly.