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

have as an output a specification document describing which concerns were found by
the tool (crosscutting or not) with their respective requirements and describe this
information in a simple way that was easy to understand by Siemens' developers.
The aim of our case study was that, by the end of our analysis, we would have a
document that Siemens' developers would be able to use as a guide to their
implementation. When we conducted the case study there was already an ongoing
implementation of the prototypical system with aspects and the developers already
had an initial understanding about the requirements.
Siemens' main goal, on the other hand, was to check how our approach could
contribute to what they had already done in terms of requirements analysis and
implementation. More specifically they wanted to check if our approach could help
them find relevant concerns that they hadn't already thought about that could impact
their existing architecture and implementation.
Table 6 shows the concerns we identified using EA-Miner. The concerns are
organised by type where base means the concerns that group requirements that are
central to the functionalities of the system. The early aspects (functional and non-
functional) constrain the base concerns by applying restrictions on requirements.
Remember that for each type of concern the previous identification heuristics hold
(use POS tags for noun-identification for base concerns; action verb identification
along with fan-in analysis for functional early aspects; for the identification of non-
functional early aspects the NFR lexicon and semantic tags are used).
The list of concerns presented in Table 6 was obtained after we used EA-Miner's
editing, filtering and sorting features to cut down the initial list suggested by the tool.
We also used the guidelines in sect. 4.3 discarding concerns that were too general and
some concerns whose frequency was too low. While we were discarding some
concerns we had to take care and check if they might be important concepts despite
their low frequency. One example we found was related to the Back office concern
(ETBO). Most documents used the term ETBO to refer to this concept while just one
document referred to it as back office. The reason for this might be due to the fact that
the documents were written by different developers, but what is important to highlight
is that when we observed the requirements the tool allocated to back office we
immediately realised that this term was the same as ETBO and we used a merging
operation in EA-Miner to make the concepts synonyms.

Table 6. List of Identified Concerns

Type of Concern List of Identified Concerns
Base Concern Road, Vehicle, Driver, On-board Unit (OBU),
Payment Back Office (ETBO), Enforcement
Devices, Payment
Non-Functional Early Aspect Scalability, Reliability, Security, Compatibility,
Error-Handling, Persistence, Concurrency, Legal
Issues

Functional Early Aspect Charge Calculation, Monitoring, Logging,

Connect/Disconnect , Transaction Management,
Communication Trigger