From Requirements Change to Design Change: A Formal Path

View/ Open
Author(s)
Wen, L
Dromey, RG
Griffith University Author(s)
Year published
2004
Metadata
Show full item recordAbstract
The ideal we seek when responding to a change in the functional requirements for a system is that we can quickly determine (1) where to make the change (2) how the change affects the architecture of the existing system (3) which components of the system are affected by the change (4) and, what behavioral changes will need to be made to the components (and their interfaces) that are affected by the change. The change problem is complicated because requirements changes are specified in the problem domain, whereas the design response and the implementation changes that need to be made are in the solution domain. ...
View more >The ideal we seek when responding to a change in the functional requirements for a system is that we can quickly determine (1) where to make the change (2) how the change affects the architecture of the existing system (3) which components of the system are affected by the change (4) and, what behavioral changes will need to be made to the components (and their interfaces) that are affected by the change. The change problem is complicated because requirements changes are specified in the problem domain, whereas the design response and the implementation changes that need to be made are in the solution domain. Requirements and design representations vary significantly in the support they provide for accommodating requirements changes. An important way of cutting down the memory overload and difficulties associated with making changes is to use the same representation for requirements and the initial design response to the change. In this paper we use a formal component-state representation called behavior trees for this purpose. It allows individual functional requirements to be translated into their corresponding behavior trees; these trees are composed, one at a time, to create an integrated design behavior tree (DBT). The architecture, the component interfaces and the component behaviors of each component in the system are all emergent properties of the DBT. We extend this design approach, by proposing a formal method for mapping changes in a system's functional requirements, to changes in the architecture, the behavior of individual components and their interfaces. Such changes are shown visually on the work products of the design process that are affected. A tool is used to implement the change process.
View less >
View more >The ideal we seek when responding to a change in the functional requirements for a system is that we can quickly determine (1) where to make the change (2) how the change affects the architecture of the existing system (3) which components of the system are affected by the change (4) and, what behavioral changes will need to be made to the components (and their interfaces) that are affected by the change. The change problem is complicated because requirements changes are specified in the problem domain, whereas the design response and the implementation changes that need to be made are in the solution domain. Requirements and design representations vary significantly in the support they provide for accommodating requirements changes. An important way of cutting down the memory overload and difficulties associated with making changes is to use the same representation for requirements and the initial design response to the change. In this paper we use a formal component-state representation called behavior trees for this purpose. It allows individual functional requirements to be translated into their corresponding behavior trees; these trees are composed, one at a time, to create an integrated design behavior tree (DBT). The architecture, the component interfaces and the component behaviors of each component in the system are all emergent properties of the DBT. We extend this design approach, by proposing a formal method for mapping changes in a system's functional requirements, to changes in the architecture, the behavior of individual components and their interfaces. Such changes are shown visually on the work products of the design process that are affected. A tool is used to implement the change process.
View less >
Conference Title
PROCEEDINGS OF THE SECOND INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING AND FORMAL METHODS
Publisher URI
Copyright Statement
© 2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.