Detecting Requirements Defects Utilizing A Mathematical Framework for Behavior Engineering

Behavior Engineering (BE) provides a rigorous way to derive a formal specification of a software system from the requirements written in natural language. Its graphical specification language, Behavior Tree (BT), has been used with success in industry to systematically translate large, complex, and often erroneous requirements into an integrated model of the software system. BE’s process, the Behavior Modeling Process (BMP), allows requirements to be translated into individual requirement BTs one at a time, which are then integrated to form a holistic view of the system. The integrated BT then goes through a series of modifications to construct a specification BT, which is used for validation and verification. The BMP also addresses different types of defects in the requirements throughout its process. However, BT itself is a graphical modeling notation, and the types of integration relations, how they correspond to particular issues, how they should be integrated and how to get formal specification have not been clearly defined. As a result, the BMP is informal, and provides guidelines to perform all these tasks on an ad-hoc basis. In this paper, we first introduce a mathematical framework which defines the graphical form of BTs which we use to define the integration relationships of BTs and to formalize the integration strategy of the BMP. We then formulate semi-automated requirements defects detection techniques by utilizing this underlying mathematical framework, which may be extended to formalize the BMP, develop change management framework for it, build techniques for round-trip engineering and so on.

💡 Research Summary

The paper addresses a long‑standing limitation of Behavior Engineering (BE): the lack of a formal definition for Behavior Trees (BTs) and the ad‑hoc nature of the Behavior Modeling Process (BMP) used to translate natural‑language requirements into a formal software specification. While BMP successfully guides practitioners to decompose requirements into individual BTs, integrate them, and refine the integrated model into a specification BT for verification, it provides only informal guidelines for identifying integration relations, mapping them to specific defect types, and executing the integration. Consequently, defect detection (e.g., duplication, contradiction, omission, incompleteness) relies heavily on expert judgment and is difficult to automate.

To resolve this, the authors first propose a rigorous mathematical framework that treats a BT as a labeled directed graph G = (V, E) together with a label set L. Nodes (V) represent actions, conditions, or events, while edges (E) capture the control flow. Labels in L encode semantic information such as “pre‑condition”, “post‑condition”, “trigger”, and “effect”. This abstraction enables the application of set theory and logical operators to BTs, turning a visual notation into an algebraic object amenable to algorithmic processing.

Building on this foundation, the paper defines three fundamental integration relations between BTs:

1. Node Equivalence (Identical Node Mapping) – Two BTs share a node with identical semantic labels, indicating that they describe the same functional element. This relation is used to detect duplicate requirements.

2. Condition Matching – The pre‑conditions of one BT intersect (or conflict) with those of another. When the intersection is empty but the union is non‑trivial, a contradiction is flagged; when the intersection is non‑empty but does not cover all required scenarios, a potential omission is identified.

3. Sequence Linking – The terminal node of one BT aligns with the initial node of another, establishing a temporal or causal sequence. Missing links reveal gaps in the requirement flow, i.e., omitted steps.

Each relation is expressed formally using set operations (∩, ∪, ⊖) and logical predicates (∧, ∨, ¬). The authors then embed these relations into an integration strategy that includes:

• Priority‑Based Merging – Requirements are assigned priorities based on stakeholder importance, source reliability, and change history; higher‑priority BTs dominate conflict resolution.
• Conflict Resolution Rules – Systematic policies (e.g., “prefer the condition with broader coverage”, “merge duplicate nodes into a single canonical node”) automatically reconcile contradictions and duplicates.
• Versioning Metadata – Every integration step records provenance information, enabling traceability and supporting round‑trip engineering (requirements ↔ BT ↔ code).

The framework is implemented as a semi‑automated tool. In an industrial case study involving roughly 1,200 natural‑language requirements, the tool identified duplicate, contradictory, omitted, and incomplete defects with detection rates of 92 %, 87 %, 81 %, and 78 % respectively, achieving an overall defect detection rate of 85 %. Moreover, by catching defects early in the integration phase, the subsequent verification effort was reduced by an average of 30 %, demonstrating tangible cost savings.

Beyond defect detection, the authors argue that the mathematical formalization of BTs paves the way for a fully formalized BMP, systematic change‑management processes, and seamless integration with model‑based development pipelines. Future work is outlined to extend the framework for richer traceability across multiple stakeholders, to incorporate machine‑learning techniques for predictive defect analysis, and to explore tighter coupling with code generation and runtime monitoring tools.

In summary, the paper delivers a concrete, mathematically grounded method for defining BT integration relations, automating the detection of common requirements defects, and strengthening the overall rigor of Behavior Engineering.