Information Technology Reference
In-Depth Information
However, in some real scenarios the requirements engineers do not have the
opportunity to have much contact with the stakeholders, for example, in mass market
application development (e.g., web and off-the-shelf software) [4] where the number
and diversity of users can be extremely high. In these cases the requirements
engineers have to elicit the requirements based on previous knowledge about the
domain or based on available documentation such as marketing studies, legacy
specifications and user manuals.
In both cases the goal of the requirements engineers is to make a transition from
understanding the “problem world” and creating a requirements specification that
represents the system under investigation and that will help developers to build the
system in the “solution world” [2, 5]. During this transition process several documents
with various structures (e.g., interview transcripts, user manuals, marketing analysis and
legacy specifications) can be used to inform the requirements engineer.
Generally this transition process is done manually which can be very time-
consuming depending on the size and complexity of the system. For example,
consider that the input to the requirements specification and analysis task is a 60 page
contract document and a 50 page legacy user manual. Given that the standard average
rate of reading is between 250 and 350 words per minute, it is not difficult to realize
that reading all the information and transforming it into a more structured RE model
demands a huge effort. Therefore, in order to reduce this effort, it is vital to provide
automated support.
As most documents used in RE are written in natural language, some researchers
[6-14] have found promising results in automating RE tasks by building tools that
apply natural language processing (NLP) techniques with requirements-related
documents as input in order to automatically identify concepts and build RE models.
Applying NLP in requirements interpretation is also challenging as natural language
is not as precise as design and implementation languages containing lots of
ambiguities and complex semantics.
Regarding structuring of requirements, recently, some researchers [15-19] have
proposed the adoption of aspect-oriented requirements engineering (AORE) as an
effective approach to achieve separation of concerns. AORE is based on the
observation that, similar to what was evidenced by the AOP community, requirements
artifacts can contain tangling and scattering that need special treatment. This
treatment is provided by adapting current RE approaches with new abstractions
(called early aspects) that modularize crosscutting concerns at RE level, thus bringing
the following benefits [15-19]:
•
Facilitate detection of conflicts between broadly-scoped requirements;
•
Simplify analysis of interactions between early aspects (e.g., the impact that
security can have on response time);
Facilitate mapping to later stages (e.g., architecture, design and code) thus
providing homogeneity in an aspect-oriented development process.
Even though separation of crosscutting concerns provides benefits, building an
AORE specification with existing AORE approaches suffers from the same problems
as for classical RE techniques mentioned above. In the case of AORE it is even more
challenging since the identification and structuring of requirements level aspects, base
abstractions and crosscutting relationships is harder due to these concepts being
•
Search WWH ::
Custom Search