23.02.2015 Views

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

D.3.3 ALGORITHMS FOR INCREMENTAL ... - SecureChange

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

6 Conclusions<br />

In this paper we have presented an approach for handling change propagation and analyzing<br />

the mutual impact between the requirement engineering and risk analysis domains.<br />

Change propagation is based on conceptual mappings between the two domains<br />

and a set of well-defined mapping rules that handle the change propagation at the model<br />

level.<br />

An important advantage of the approach is separation of concerns. Enforcing this<br />

principle has the advantage that the respective processes can leverage on each other<br />

while being conducted separately, and that the risk analysts do not need thorough expertise<br />

in the requirement domain or the requirement modeling language, and vice versa.<br />

They only need to have a high-level understanding of the mapped concepts. The changedriven<br />

interplay is supported by the formalization of the mappings as VIATRA2 graph<br />

transformation rules. The execution of the rules ensures the preservation of model consistency<br />

between the two domains under change.<br />

In this paper the approach has been applied to the SI* requirement framework and<br />

the CORAS risk framework, although it is applicable also to alternative (competing) instantiations.<br />

Indeed, the concepts that are mapped in the former – such as goal, resource,<br />

and task – are in common to other goal-oriented approaches to requirement engineering.<br />

The same holds for asset and treatments that are key concepts in other risk analysis<br />

approaches. Thus, the validity of our approach goes beyond the demonstrated instantiations<br />

in this paper; alternative approaches to requirement engineering and risk analysis<br />

with similar underlying conceptual frameworks can be orchestrated by following the<br />

same approach.<br />

In risk analysis, one of the objectives is to identify and document treatments the<br />

implementation of which ensures that the residual risk level is within the acceptable<br />

threshold, whereas requirements engineering aims at achieving the identified goals to an<br />

acceptable level. Thus, as future work, we plan to extend the framework with mapping<br />

rules for relating the residual risk level with the achievement level such that propagations<br />

are triggered also by changes to these. We moreover plan to extend the framework<br />

in order to handle more complex changes than the atomic ones. A further topic for<br />

future work is the definition of methods to handle conflicting changes such as a new<br />

requirement contradicting existing treatments.<br />

Acknowledgments. This work has been partially supported by the European Commission<br />

under the 7th Framework Programme via the <strong>SecureChange</strong> (231101) project and<br />

the NESSoS (256980) network of excellence.<br />

References<br />

1. Alberts, C.J., Davey, J.: OCTAVE criteria version 2.0. Technical report CMU/SEI-2001-TR-<br />

016, Carnegie Mellon University (2004)<br />

2. Asnar, Y., Giorgini, P., Mylopoulos, J.: Goal-driven risk assessment in requirements engineering.<br />

Requirements Engineering 16(2), 101–116 (2011)

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!