The requirement to effectively manage change in software projects is quite serious. The penalties of unmanaged or badly managed change is reduced software maintainability. As changes in higher abstraction levels usually pass on to the lower levels, it’s very helpful to manage change not just in code and design, but also in requirements documents and requirements models too. We suggest an approach for managing changes within requirements. This approach draws on maintaining requirements models (expressed in SysML) synchronized with what the stakeholders prefer, often called the application domain. It focusses on figuring out which model elements are affected, the way they are affected and just how the impact needs to be addressed. Modifications in the application domain are determined, a model element is designated to be impacted and from this, the overall influence of the change on the model is determined utilizing the requirement relations as trace links…
Contents: Change management within SysML requirements models
1 Introduction
1.1 Context
1.2 Problem statement
1.3 Approach
1.4 Overview
2 Basic concepts
2.1 MOF
2.1.1 OMG four layered architecture
2.1.2 Purpose of MOF
2.2 UML
2.2.1 Modeling using UML
2.2.2 Customizing UML
2.3 Using OCL with UML
2.4 SysML
2.4.1 SysML diagrams
2.4.2 Modeling requirements in SysML
2.5 Model Driven Engineering
2.6 Change Management
2.7 Summary
3 Classi cation of changes
3.1 Domain
3.2 Domain change
3.3 Model
3.4 Model Change
3.5 External inconsistency
3.6 Internal Inconsistency
3.7 Requirement parts and details
3.8 Summary
4 Impact Analysis Process
4.1 Process
4.2 Relations between terms
4.3 External inconsistency propagation
4.4 Summary
vii5 Formalization of model elements and changes
5.1 Introduction
5.2 Relevant SysML model elements
5.3 Formalizations
5.3.1 Requirement
5.3.2 Formalization of TracedTo
5.3.3 Formalization of DerivedFrom
5.3.4 Formalization of ComposedBy
5.3.5 Formalization of CopyOf
5.4 Domain change case analysis
5.4.1 New requirement added
5.4.2 Existing requirement removed
5.4.3 Requirement made more specific
5.4.4 Requirement made more abstract
5.4.5 Part removed from requirement
5.4.6 New part added to requirement
5.5 Propagation rule derivation
5.5.1 New part added to requirement
5.5.2 Requirement made more abstract
5.6 Discussion of formalization
5.6.1 Using predicates and systems
5.6.2 Using systems only
5.7 Summary
6 Example process usage
6.1 Example Model
6.2 Example changes
6.2.1 Remove setting visibility of archived items
6.2.2 Remove student team support
6.2.3 Add support for removing grades
6.3 Summary
7 Tool Support
7.1 Blueprint
7.1.1 Blueprint capabilities
7.1.2 Blueprint data structure
7.2 Solution location
7.3 Plugin development
7.4 Plugin architecture
7.4.1 AbstractChangeImpactAnalysisAction
7.4.2 PartMadeMoreSpecific
7.4.3 PartMadeMoreAbstract
7.4.4 PartAddedToReq
7.4.5 PartRemovedFromReq
7.4.6 ReqRemoved
7.4.7 ModelQuerier
7.4.8 OCLModelQuerier
7.4.9 RulesManager
7.4.10 PropagationChooser
7.4.11 StdInChooser
4.12 ChangeImpactListener
7.4.13 StdOutListener
7.4.14 AbstractUMIModelCommandAction
7.5 Example usage
7.5.1 Example model
7.5.2 Usage
7.6 Summary
8 Conclusion
8.1 Classification of changes
8.2 Determining and resolving impact
8.2.1 Process workings
8.2.2 Formalization and derivation
8.3 Tool support
8.4 Evaluation
8.4.1 Choice of metamodel
8.4.2 Formalization
8.4.3 Change Impact Analysis Process
8.4.4 Final remarks and future work
A Test Plan…
Source: University of Twente
Download URL 2: Visit Now