Information Technology Reference
In-Depth Information
The top of Fig. 1 shows the general activities (1-4) common to most AORE
processes while the bottom shows an adaptation of activities 2 and 3 based on
viewpoint-based AORE. Depending on the AORE approach used, each activity is
adapted accordingly (e.g., had we considered [18] we would identify scenarios instead
of viewpoints in activity 2.1).
The reason we highlighted activities 2 and 3 is that these are the ones that represent
the core focus of EA-Miner and also where it significantly contributes to existing
AORE approaches, as current tool support for most AORE approaches does not
address identification of concepts from requirement elicitation documents and
mapping into an AORE model. We use Viewpoint-based AORE to discuss the
features of EA-Miner. An overview of each activity, the artifacts involved and the
role of EA-Miner is discussed below:
(1)
Eliciting requirements from stakeholders and documents:
As discussed in
Sect. 1 elicitation can be partly done by interacting with stakeholders or, when they
are not available, by reading available documentation or both. In this sense EA-Miner
can help providing quick feedback while identifying the concepts in the next activity
by offering views that show key information on the documents provided as input.
(2)
Identification of requirements model concepts:
EA-Miner helps in automating
activity 2, using the documents produced in activity 1 as input, of identifying model
concepts (e.g., viewpoints, early aspects, use cases and others) and presenting them to
the user. Some characteristics about the identification are:
•
Rule-based and NLP-based:
For each AORE model considered, the mining
technique utilized can be different. For example, for the Viewpoint model, part-of-
speech NLP technique is used to identify nouns as viewpoint candidates while for a
use case approach we can consider action verbs as candidate use cases. Section 3
explains this in detail while Sect. 4 shows how this is realized in EA-Miner.
•
Every concept identified is a candidate:
EA-Miner identifies the model concepts
and considers them to be candidates. The tool offers several features to show
information about the candidates (e.g., their frequency of occurrence in the text,
their meaning) as well as process guidelines to help the requirements engineer
accept or reject that concept.
•
Process guidelines can be used:
As mentioned before EA-Miner does not replace
the work of the requirements engineer and is not aimed at 100% automation. For
this reason, guidelines documenting previous experience and best practices can be
used to assist the requirements engineer by prescribing some “tips” on how the
information and features of EA-Miner can be used effectively. Guidelines can be
customized according to AORE model to give an idea on how the requirements
engineer can make an informed decision (e.g., what constitutes a “good” viewpoint
or use case). Section 4.3 gives more details about guidelines.
(3)
Structuring the Requirements specification:
This activity constitutes editing
the initial model produced in the previous activity by discarding irrelevant concepts,
adding new ones not identified, and generating a structured model (e.g., a
specification document based on the Viewpoint-based AORE approach). EA-Miner
also provides features such as filtering (e.g., show the 10 most relevant viewpoints
based on frequency) and process guidelines as discussed above to help the
requirements engineer.
Search WWH ::
Custom Search