A Rule-Based Change Impact Analysis Approach in Software Architecture for Requirements Changes
📝 Abstract
Software systems usually operate in a dynamic context where their requirements change continuously and new requirements emerge frequently. A single requirement hardly exists in isolation: it is related to other requirements and to the software development artifacts that implement it. When a requirements change is introduced, the requirements engineer may have to manually analyze all requirements and architectural elements for a single change. This may result in neglecting the actual impact of a change. We aim at improving change impact analysis in software architecture for requirements changes by using formal semantics of requirements relations, requirements changes and traces between Requirements & Architecture. In our previous work we presented a technique for change impact analysis in requirements. The technique uses the formal semantics of requirements relations and changes. Its output is a set of candidate requirements for the impact with proposed changes and a propagation path in the requirements model. In this paper we present a complementary technique which propagates requirements changes to software architecture and finds out which architectural elements are impacted by these changes. The formalization of requirements relations, changes and traces between R&A is used to determine candidate architectural elements for the impact of requirements changes in the architecture. The tool support is an extension of our Tool for Requirements Inferencing and Consistency Checking (TRIC). Our approach helps in the elimination of some false positive impacts in change propagation. We illustrate our approach in an industrial example which shows that the formal semantics of requirements relations, changes and traces enables the identification of candidate architectural elements with the reduction of some false positive impacts.
💡 Analysis
Software systems usually operate in a dynamic context where their requirements change continuously and new requirements emerge frequently. A single requirement hardly exists in isolation: it is related to other requirements and to the software development artifacts that implement it. When a requirements change is introduced, the requirements engineer may have to manually analyze all requirements and architectural elements for a single change. This may result in neglecting the actual impact of a change. We aim at improving change impact analysis in software architecture for requirements changes by using formal semantics of requirements relations, requirements changes and traces between Requirements & Architecture. In our previous work we presented a technique for change impact analysis in requirements. The technique uses the formal semantics of requirements relations and changes. Its output is a set of candidate requirements for the impact with proposed changes and a propagation path in the requirements model. In this paper we present a complementary technique which propagates requirements changes to software architecture and finds out which architectural elements are impacted by these changes. The formalization of requirements relations, changes and traces between R&A is used to determine candidate architectural elements for the impact of requirements changes in the architecture. The tool support is an extension of our Tool for Requirements Inferencing and Consistency Checking (TRIC). Our approach helps in the elimination of some false positive impacts in change propagation. We illustrate our approach in an industrial example which shows that the formal semantics of requirements relations, changes and traces enables the identification of candidate architectural elements with the reduction of some false positive impacts.
📄 Content
A Rule-Based Change Impact Analysis Approach in Software Architecture for Requirements Changes ARDA GOKNIL1, IVAN KURTEV2, KLAAS VAN DEN BERG3 1SnT Centre, University of Luxembourg, Luxembourg 2Altran, Limburglaan 24, 5652 AA, Eindhoven, the Netherlands 3University of Twente, 7500 AE Enschede, the Netherlands 1arda.goknil@uni.lu, 2ivan.kurtev@altran.com, 3vdberg.nl@gmail.com
Abstract: Software systems usually operate in a dynamic context where their requirements change continuously and new requirements emerge frequently. A single requirement hardly exists in isolation: it is related to other requirements and to the software development artifacts that implement it. When a requirements change is introduced, the requirements engineer may have to manually analyze all requirements and architectural elements for a single change. This may result in neglecting the actual impact of a change. We aim at improving change impact analysis in software architecture for requirements changes by using formal semantics of requirements relations, requirements changes and traces between Requirements & Architecture. In our previous work we presented a technique for change impact analysis in requirements. The technique uses the formal semantics of requirements relations and changes. Its output is a set of candidate requirements for the impact with proposed changes and a propagation path in the requirements model. In this paper we present a complementary technique which propagates requirements changes to software architecture and finds out which architectural elements are impacted by these changes. The formalization of requirements relations, changes and traces between R&A is used to determine candidate architectural elements for the impact of requirements changes in the architecture. The tool support is an extension of our Tool for Requirements Inferencing and Consistency Checking (TRIC). Our approach helps in the elimination of some false positive impacts in change propagation. We illustrate our approach in an industrial example which shows that the formal semantics of requirements relations, changes and traces enables the identification of candidate architectural elements with the reduction of some false positive impacts. Keywords: Change Impact Analysis; Software Architecture; Traceability; AADL 1 Introduction Today’s software systems usually operate in a dynamic business context where business goals often change. As a result, the requirements of software systems change continuously and new requirements emerge frequently. The integration of the new requirements and the adaptations to the deployed software systems are costly and time consuming. A single requirement hardly exists in isolation: it is related to other requirements and to the software development artifacts that implement it. Thus, even a simple change in a single requirement may have a significant effect on the whole system. Determining such an effect is usually referred to as change impact analysis. In this paper we focus on change impact analysis in software architecture for requirements changes. The need for change impact analysis is observed in both requirements and software architecture. When a change is introduced to a requirement, the requirements engineer needs to find out if any other requirement related to the changed requirement is impacted. After determining the impacted requirements, the software architect needs to identify the impacted architectural elements by tracing the changed requirements to software architecture. It is hard, expensive and error prone to manually trace impacted requirements and architectural elements from the changed requirements. Several commercial tools such as IBM RequisitePro and DOORS use semi-structured format of requirements documents and traces between Requirements (R) and Architecture (A) with support for automatic change impact analysis. Although these tools capture requirements relations and traces between R&A (and also other artifacts) explicitly, the meaning of these relations and traces is often too general and the analysis results may be deficient [10]. For instance, when a requirement is changed in RequisitePro, all reachable elements are considered potentially impacted. The relation types (tracedTo and tracedFrom) provided by RequisitePro indicate only the direction of the relations and traces without their actual meaning. By using only the transitive closure of relations and traces, the software architect may conclude that all architectural elements are impacted. Without any additional semantic information about the requirements relations, changes, and traces, change impact analysis may produce a high number of false positive impacts. This situation is explained by Bohner [1] [2] [3] as explosion of impacts without semantics. It is concluded that change impact analysis must employ additional semantic information to increase the accuracy by eliminat
This content is AI-processed based on ArXiv data.