Overview
The natural language that people use to express themselves is frequently prone to ambiguity. Misunderstandings occur due to a statement having two or more interpretations. In the software engineering domain, clarity of expression when specifying the requirements of software systems is one situation where absence of ambiguity is important. Dromey’s Behavior Engineering is a formal method that reduces or eliminates ambiguity in software requirements. Exploratory research suggests Behavior Engineering might be effective at eliminating ambiguities in process models.
Behavior Engineering (BE) creates a link between systems engineering processes and software engineering processes. It has proven highly effective in practical, industry-based situations when applied to large complex systems. BE clarifies the system and software requirements.
The practices now described as behaviour engineering evolved from earlier work in which an approach for clarifying and integrating requirements for complex systems was developed. This remains a significant application of the approach; however, as the technique evolved, it became apparent that it could be applied to more general descriptions of systems behaviour.
What is Behaviour Engineering?
Essentially, Behaviour Engineering is a method for assembling individual pieces to form an integrated component architecture. Each requirement is translated into its corresponding ‘behaviour tree’ which describes unambiguously the precise behaviours of this particular requirement. The ‘tree’ is built up from (a) components, (b) states the components become, (c) events and decisions/constraints associated with the components, and (d) the causal, logical and temporal dependencies associated with the component.
When each component is modelled in this way, and then integrated into a larger whole, a clear pattern of intersections become evident. The individual components fit together like a jig-saw puzzle to form a coherent component architecture in which the integrated behaviour of the components is evident. One component establishes a precondition for another component to perform its function and so on. This allows a software system to be constructed out of its requirements, rather than merely satisfying its requirements.
Duplications and redundancies are identified and can be removed, for example, when the same requirement is expressed twice using different language in different places. Another benefit is that traceability becomes more manageable.
Research strategy
Where complexity and ambiguity create challenges for the developers of complex systems, Behavior Engineering seeks to provide a solution.