Information Technology Reference
In-Depth Information
6 Limitation
Obviously there are limitations in this work:
-
Real world applicability.
Even though we work on a real world case study,
this work is still pure theory. It needs to be elaborated and then evaluated
with the industry. We plan to prove our work in the field of Air Trac
Management (ATM), where we interact with designers and stakeholder of
an ATM system, and get their feedback for validation.
-
Obtaining probability.
Since evolution probabilities are obtained from stake-
holder, they are individual opinions. To deal with the problem, we shall work
on an interaction protocol with stakeholder to minimize inaccuracy, as well
as equip an appropriate mathematic foundation (
e.g.,
Dempster and Shafer's
theory) for our reasoning.
-
Independence of evolution.
Complex models may require many probabilities
that are not independent. This breaks the assumptions discussed in
5. Even
though designers can solve this problem by manually combining dependent
evolutions, we still need a more systematic way to deal with them.
ยง
7 Related Works
A majority of approaches to software evolution has focused on the evolution
of architecture and source code level. However, in recent years, changes at the
requirement level have been identified as one of the drivers of software evolu-
tion [4, 12, 31]. As a way to understand how requirements evolve, research in
PROTEUS [24] classifies changing requirements (that of Harker et al [11]) into
five types, which are related to the development environment, stakeholder, devel-
opment processes, requirement understanding and requirement relation. Later,
Lam and Loomes [15] present the EVE framework for characterizing changes,
but without providing specifics on the problem beyond a meta model.
Several approaches have been proposed to support requirements evolution.
Zowgi and Offen [31] work at meta level logic to capture intuitive aspects of
managing changes to requirement models. Their approach involves modeling
requirement models as theories and reasoning changes by mapping changes be-
tween models. However, this approach has a limitation of overhead in encoding
requirement models into logic.
Russo et al [26] propose an analysis and revision approach to restructure re-
quirements to detect inconsistency and manage changes. The main idea is to
allow evolutionary changes to occur first and then, in the next step, verify their
impact on requirement satisfaction. Also based on this idea, Garcez et al [4] aim
at preserving goals and requirements during evolution. In the analysis, a spec-
ification is checked if it satisfies a given requirement. If it does not, diagnosis
information is generated to guide the modification of specification in order to
satisfy the requirement. In the revision, the specification is changed according
to diagnosis information generated. Similar to Garcez et al, Ghose's [9] frame-
work is based on formal default reasoning and belief revision, aims to address
