From requirements change to design change: a formal path

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.