EA-Miner: a Tool for Automating Aspect-Oriented
Requirements Identification
Américo Sampaio Ruzanna Chitchyan
Lancaster University Lancaster University
Computing Department, InfoLab21 Computing Department, InfoLab21
Building, South Drive, Lancaster Building, South Drive, Lancaster
University Lancaster LA1 4WA UK University Lancaster LA1 4WA UK
00 44 (0) 1524 510346 00 44 (0) 1524 510499
a.sampaio@comp.lancs.ac.uk rouza@comp.lancs.ac.uk
ABSTRACT
Aspect-Oriented requirements engineering helps to achieve early
separation of concerns by supporting systematic analysis of
broadly-scoped properties such as security, real-time constraints,
etc. The early identification and separation of aspects and base
abstractions crosscut by them helps to avoid costly refactorings at
later stages such as design and code. However, if not handled
effectively, the aspect identification task can become a bottleneck
requiring a significant effort due to the large amount of, often
poorly structured or imprecise, information available to a
requirements engineer. In this paper, we describe a tool, EA-
Miner, that provides effective automated support for identifying
and separating aspectual and non-aspectual concerns as well as
their crosscutting relationships at the requirements level. The tool
utilises natural language processing techniques to reason about
the properties of the concerns and model their structure and
relationships.
Categories and Subject Descriptors
D.2.1 [Requirements/Specifications]: tools. I.7.5 [Document
Capture]: document analysis. K.6.3 [Software Management]:
software development, software process.
General Terms
Management.
Keywords
Aspect oriented requirements engineering, AORE, aspect-oriented
software development, AOSD, aspect mining and identification,
tool support, automation, concern identification.
1. INTRODUCTION
Recently, some researchers [1-3] proposed the adoption of aspect-
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
ASE’05, November 7–11, 2005, Long Beach, California, USA.
Copyright 2005 ACM 1-58113-993-4/05/0011...$5.00.
352
Awais Rashid Paul Rayson
Lancaster University
Computing Department, InfoLab21
Building, South Drive, Lancaster
University Lancaster LA1 4WA UK
00 44 (0) 1524 510316
{marash, paul}
@comp.lancs.ac.uk
oriented requirements engineering (AORE) as an effective
approach to deal with requirements engineering tasks. The
benefits brought by aspect-oriented approaches were first
evidenced at the implementation level and recently at other stages,
such as requirements and design.
Aspects are abstractions used to modularise crosscutting concerns,
e.g., security, distribution, real-time constraints, etc., in software
development. AORE helps to effectively achieve separation of
crosscutting concerns at the requirements level and results in
improved modularity of requirement artefacts facilitating their
creation, composition/decomposition and evolution [1-3].
Moreover, early identification and separation of aspects and base
abstractions crosscut by them helps to avoid costly refactorings at
later stages, such as design and code.
One crucial point in adopting AORE is having an effective and
scalable mechanism to deal with its most complex and time
consuming activities, such as identification and analysis of base
and crosscutting concerns and their crosscutting relationships.
Identifying crosscutting concerns in requirements documents of
varying size and structure is a complex task due to the massive
amount of information and the tangled nature of requirements
sources (e.g., interview transcripts, legacy documentation,
manuals, etc). Even structured requirements specifications written
with non-AORE methods (e.g., use case descriptions) can be hard
to analyse for the purpose of identifying early aspects because
they also can contain scattered and tangled concerns in a large
volume of information.
Some research has focused on the problem of providing tool
support for identifying crosscutting concerns most notably
Theme/Doc [2]. It provides a tool for semi-automatic
identification of crosscutting behaviours in requirements
specifications. However, with this approach a developer has to
manually provide a list of action words from the input document
implying that s/he has to previously read the complete set of
documents to scan for these words. Considering, for example, that
the rate of reading is between 250-350 words per minute a person
would take about 20 minutes just to read a 5,000 words document
and also spend more time to decide what words to add to the
action words list and then to add them to the tool. Despite the
important contributions of this approach it does not scale well for
complex projects with large documents.
This paper describes a tool (EA-Miner) that provides effective
automated support for identifying and separating aspectual (called
early aspects) and non-aspectual concerns as well as their
crosscutting relationships at the requirements level. The tool
utilises natural language processing techniques (part-of-speech
and semantic tagging, word frequencies, etc.) to reason about the
properties of the concerns and model their structure and
crosscutting relationships. The remainder of this paper is
structured as follows: Section 2 shows our approach for
identifying aspects while Section 3 describes in more detail how
the tool works. Finally Section 4 concludes the paper.
2. EA-MINER TOOL AND APPROACH
The EA-Miner tool uses the WMATRIX [5] natural language
processor to pre-process the input documents and get relevant
information. WMATRIX uses part-of-speech and semantic
tagging, frequency analysis and concordances to identify concepts
of potential significance in the domain. Part-of-speech analysis
automates the extraction of syntactic categories from the text (e.g.,
nouns, verbs).
EA-Miner is a web-based tool that utilises NLP features from
WMATRIX to identify base concerns, early aspects and
crosscutting relationships between them. For the purpose of the
tool base concerns are any matter of interest at the requirements
level that can be decomposed in a unit of the chosen
decomposition model. For example, if the chosen decomposition
model is viewpoint-oriented, a base concern is a viewpoint while
if the technique used is UML-based, a base concern can be a use
case or a scenario (at a finer-grained level). An early aspect is a
requirements-level aspect; an entity that semantically crosscuts a
concern. The early aspect modularises responsibilities that would
otherwise be scattered across several concerns or tangled inside
one concern if the aspectual model was not applied. Therefore,
early aspects provide a means for modularising the crosscutting
behaviour at the requirements level and applying it to the base
concerns using a composition mechanism.
EA-Miner helps to achieve separation of concerns at the
requirements level by modularising crosscutting concerns as early
aspects. This helps to improve requirements maintainability by
facilitating change management.
Figure 1 shows a high level view of EA-Miner architecture to
highlight how it has been designed to be model independent so
that different techniques can be supported. Currently, there is
support for the viewpoint-based AORE model in [1].
The Web-based GUI component is a normal web browser
(IExplorer, Mozilla) that handles GUI interactions with the user.
The Controller is responsible for checking the state of the tagging
process in WMATRIX and instantiating the specific internal
model parser (e.g., Viewpoint parser) which parses the
requirements document and generates the specific internal model.
After the internal model is created the web-based GUI can use the
view generator component to produce a specific view (e.g.,
viewpoint-based view as in Figure 5) for the user.
Besides model independence, some other advantages of using EA-
Miner are as follows:
• It helps to automate time consuming and error-prone
activities, such as identification of concerns, early aspects
and their relationships.
353
• It can easily provide support for model refinement and
specification generation.
• It enables the requirements engineer to get a quick
understanding of the system by showing the key abstractions
and relevant information.
View Generator
W eb-based GUI
Viewpoint Other Model
View View
W MATRIX Controller
Internal model
Viewpoint Other
Requirements to internal
model parser
Viewpoint Other Model
parser parser
Figure 1 - EA-Miner high level architecture
Having said that, it is important to present a more detailed
explanation of how the identification of base concerns, early
aspects and crosscutting relationships is carried out in a
requirements engineering approach using EA-Miner. Figure 2
presents a detailed view of how the tool works within the
requirements engineering process.
The four main RE activities supported by EA-Miner are
elicitation, identification, presentation of results and screening out
of irrelevant abstractions. EA-Miner supports the elicitation
activity by helping the requirements engineer to focus on specific
parts of the input documents while the following activities are
executed and assisting him/her in getting a quick understanding of
the system.
In the identification activity, EA-Miner parses the input files
(different types and structures) provided by the engineer and
sends them to WMATRIX for part-of-speech (POS) and semantic
tagging. WMATRIX then generates an XML file consisting of the
input file with POS and semantic annotations. This file is passed
to EA-Miner in order to produce an internal representation of the
file as Java objects. This internal model is produced for a specific
technique (e.g., viewpoint, scenario based, etc.) selected
previously by the user. In the presentation of results activity the
requirements engineer can view the internal model in different
ways (e.g., diagrams, textual representations, etc.) represented in
the specific AORE model selected previously (e.g., viewpoints-
based). During the screening out and specification generation
activity the previous AORE model can be refined by discarding
irrelevant abstractions previously identified or by adding new
ones. Moreover, the tool helps to generate part of the
requirements specification document by translating the refined
model into several formats such as XML, DOC, etc. Due to lack
of space, in Section 3 we will focus on describing in detail the
identification task of Figure 2 which represents the core of the
approach.

Figure 2 - Approach supported by EA-Miner
3. HOW IT WORKS
In Figure 3 EA-Miner displays the file used as input that is further
tagged by WMATRIX. The file contains a partial description of
the requirements of a toll collection system for the Portuguese
highways [1].
Figure 3 - Simple description of a system
Figure 4(a) shows a list of some nouns identified by WMATRIX.
The bottom of Figure 4(a) displays the concordance of the word
“vehicle” so that the user can inspect its surrounding context in
the text. Figure 4(b) shows how semantic analysis groups related
words and multi-word expressions into semantic fields e.g., “M3”
or “vehicles and transport or land” and also provides statistical
data such as LL (log-likelihood) showing that this is the most
significant category. The “permission category” is highlighted to
show that it contains the word “authorised” that might be related
to the non-functional requirement “security”. From this example
we can see how the information produced by WMATRIX can be
used by EA-Miner to make inferences about the identification of
base (e.g., nouns can be used to identify viewpoint candidates
such as vehicle and gizmo) and crosscutting concerns (e.g., words
whose meaning pertains to a non-functional concept such as
“authorised” meaning permission).
WMATRIX produces an XML file containing part of speech and
semantic tagging for each word of the input file. The main output
of the identification task, the internal representation, starts to be
354
built as soon as WMATRIX tagging is finished. EA-Miner detects
this and starts parsing the XML file generated by WMATRIX.
The XML file is structured in sentences (<s> </s>) containing
groups of words with part-of-speech and semantic annotations.
For instance, (<w pos=”JJ” sem=”S7.4+”> authorised </w>)
means that the word “authorised” is tagged with the “JJ” part of
speech tag which represents “general adjective” and the semantic
tag “S7.4+” which represents permission (Figure 4(b)).
(a)
(b)
Figure 4 (a): Part of speech tagging in WMATRIX; (b):
Semantic tagging in WMATRIX
While the XML file is parsed the java objects are created and
populated based on the selected technique (e.g., viewpoint-based).
Note that each abstraction contains specific heuristics for its
identification in a given model (e.g., each noun is a viewpoint
candidate in the viewpoint model). Each sentence is treated as a
requirement decomposition unit that can be used later on during
abstraction identification. This approach is common in NLP-based
requirements engineering as can be seen in [7,8]. For abstraction
identification (e.g., base concerns, early aspects, and crosscutting
relationships) the tool currently implements the AORE model
based on viewpoints [1]. Below, for each of the abstractions in the
model we describe heuristics for identifying them.
Base Concern: In this model the base concerns are represented by
the viewpoints. The basic rule for identifying them is: if the word
POS tag represents a noun (pos tag = “NN1” or “NN2”) then the
word is selected and a new Viewpoint object is created in the Java
model. The viewpoint class contains a Java collection that
represents the requirements of that viewpoint. Each sentence that
contains the identified viewpoint (e.g., gizmo) is then instantiated
as a “Requirement” object and added to the collection. The
problem with the list of viewpoints (Figure 5) is that, depending
on its size, a document can contain numerous nouns. Also, the
noun-based identification leads to classification of the same
concepts as different viewpoints due to variations, such as
“driver” and “drivers”. These problems are minimized with some
adjustments done in the “Screening out” activity such as using
lemmatization to recognize words that have the same root (driver
and drivers) and also using a dictionary of synonyms to catch
different words with the same meaning. Moreover, the frequency
lists produced by WMATRIX can be used to list only the most
significant candidates in the context of the requirements
document. Figure 5 shows, on the top left hand side, a list of some
candidate viewpoints identified by EA-Miner. When the user
clicks on a specific viewpoint, the right hand side (the Java
collection of Requirement objects) is updated. For the example
shown, the “gizmo” word occurs in sentences 3, 5, 6.
Figure 5 - Identified Abstractions
Early Aspect: The early aspect identification is based on a domain
specific lexicon (XML file) that was built observing non-
functional related words (e.g., the “authorised” word with
meaning of permission) existing in the NFR framework catalogues
[4]. The task of the tool is to compare if each word in the
document is “equalTo” a NFR concept. The “equalTo” procedure
is defined as: if a word is lexically equal, ignoring case and
suffixes, to the word in the lexicon AND the word has the same
semantic class as a word in lexicon. The comparison after the
AND avoids identifying words in the text that have the same
spelling but are used with a completely different meaning (e.g.,
the word performance can be used to indicate a constraint on a
software or to indicate the act of a dancer or artist in a show). The
“EarlyAspect” object also contains a collection of “Requirement”
objects representing sentences where the aspect occurs.
Crosscutting Relationships: When the user clicks on an early
aspect (e.g., “authorised” word of type security) candidate from
the list on the left hand side, the viewpoints list in the centre is
updated to show which viewpoints that specific early aspect
crosscuts. This is currently identified by verifying, for each
viewpoint, the intersection of the set of its requirements (e.g.,
sentences {1, 4, 10} for “vehicles”) with the set of the early aspect
requirements (e.g., sentences {1, 4, 8} for “authorised” word).
The result of the intersection {1, 4} is used to determine the
crosscutting points. During the screening out and specification
generation activity the models produced in the previous activities
can be refined to exclude irrelevant abstractions or to add relevant
ones that were not found. It will be common at this step to
add/exclude specific requirements to/from the early aspects
because the ones contained in its collection are more likely to
pertain to the viewpoints but are helpful to indicate the
crosscutting points. Also, it is likely that different viewpoints will
contain the same requirements but this can also be detected by the
tool and corrected by the requirements engineer until the model is
refined enough to generate the requirements specification in
different formats.
355
4. CONCLUSIONS
Aspect-oriented requirements engineering (AORE) provides an
effective way for modularising concerns, aspectual requirements
(early aspects) and their crosscutting relationships. However, the
variety of requirements related documents (e.g., interview
transcripts, user manuals, legacy documents) of varying size and
structure imposes serious difficulties on the task of identifying
and modularising the crosscutting properties.
Therefore, to effectively support this task it is imperative to
provide automated support to reduce the burden on identifying
and structuring base concerns, aspects and their crosscutting
relationships. In this paper we presented the EA-Miner tool and
described how the tool automates parts of the requirements
process helping to reduce the complexity and effort required to
perform these tasks. Regarding scalability, we have tested the
approach with several requirements documents and the tools takes
just a few minutes to process and display the results even
considering large documents (tens of thousands of words).
Our future work will focus on further improving the identification
of early aspects (both functional and non-functional) as well as
the screening out functionalities to minimise even more the effort
of the requirements engineer. Also, we will investigate how other
approaches [2,3] can be supported by the tool and how the tool
can be extended to address other activities of later stages of
development such as architecture and design.
5. ACKNOWLEDGMENTS
This work is supported by European Commission grant IST-2-
004349: European Network of Excellence on Aspect-Oriented
Software Development (AOSD-Europe), 2004-2008.
6. REFERENCES
[1] A. Rashid, A. Moreira, and J. Araujo, "Modularisation and
Composition of Aspectual Requirements," presented at 2nd
International Conference on Aspect Oriented Software
Development (AOSD), Boston, USA, 2003.
[2] E. Baniassad and S. Clarke, "Theme: An Approach for
Aspect-Oriented Analysis and Design," presented at
International Conference on Software Engineering,
Edinburgh, Scotland, UK, 2004.
[3] J. Whittle and J. Araujo, "Scenario Modeling with Aspects,"
IEE Proceedings - Software, vol. 151, pp. 157-172, 2004.
[4] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non-
Funcitonal Requirements in Software Engineering: Kluwer
Academic Publishers, 2000.
[5] P. Sawyer, P. Rayson, and R. Garside, "REVERE: Support
for Requirements Synthesis from Documents," Information
Systems Frontiers, vol. 4, pp. 343-353, 2002.
[6] A. Sampaio, N. Loughran, A. Rashid, and P. Rayson,
"Mining Aspects in Requirements," presented at Early
Aspects 2005: Aspect-Oriented Requirements Engineering
and Architecture Design Workshop (held with AOSD 2005),
Chicago, Illinois, USA, 2005.
[7] V. Ambriola and V. Gervasi, "Processing natural language
requirements," presented at International Conference on
Automated Software Engineering, Los Alamitos, 1997.
[8] L. Goldin and D. Berry, "AbstFinder: A Prototype Natural
Language Text Abstraction Finder for Use in Requirements
Elicitation," Automated Software Engineering, vol. 4, 1997.