Communication Analysis modelling techniques

This report describes and illustrates several modelling techniques proposed by Communication Analysis; namely Communicative Event Diagram, Message Structures and Event Specification Templates. The Communicative Event Diagram is a business process modelling technique that adopts a communicational perspective by focusing on communicative interactions when describing the organizational work practice, instead of focusing on physical activities1; at this abstraction level, we refer to business activities as communicative events. Message Structures is a technique based on structured text that allows specifying the messages associated to communicative events. Event Specification Templates are a means to organise the requirements concerning a communicative event. This report can be useful to analysts and business process modellers in general, since, according to our industrial experience, it is possible to apply many Communication Analysis concepts, guidelines and criteria to other business process modelling notations such as BPMN. Also, Message Structures can complement business process models created with other notations different than Communicative Event Diagram.

💡 Research Summary

The paper presents a concise yet thorough exposition of three modelling techniques that constitute the Communication Analysis (CA) methodology: the Communicative Event Diagram (CED), Message Structures, and Event Specification Templates. Unlike traditional business‑process modelling approaches that focus on physical activities, CA adopts a communication‑centric perspective, treating each interaction that conveys information as a “communicative event.” The CED visualises these events as nodes linked by precedence, triggers, and external interfaces, thereby exposing the flow of messages and decision points rather than the execution of tasks. This abstraction enables analysts to capture who exchanges what information, when, and under which conditions, which is especially valuable for complex organisational settings where information flow drives the process more than the physical actions themselves.

Message Structures complement the diagram by providing a structured textual specification of each message associated with a communicative event. Using a hierarchical, XML‑like syntax, the technique defines fields, data types, constraints, default values, and optional non‑functional attributes such as security or transactional requirements. Because the specification is machine‑readable, it can be directly leveraged for data‑model generation, interface design, and even automatic code scaffolding, reducing the gap between requirements engineering and implementation. Moreover, messages can be defined as reusable components, promoting consistency across multiple events and facilitating contract‑first development in service‑oriented architectures.

Event Specification Templates serve as a standardized repository for all artefacts related to a communicative event. The template captures the event’s purpose, actors, pre‑ and post‑conditions, input and output messages, functional and non‑functional requirements, and exception flows. By enforcing a uniform structure, the templates improve traceability, support systematic validation, and simplify communication among stakeholders, thereby mitigating the risk of ambiguous or missing requirements.

A significant contribution of the paper is the discussion on how CA artefacts can be mapped onto established notations such as BPMN. Communicative events correspond to BPMN tasks or message‑flow elements, while Message Structures can be attached to BPMN Message objects. This mapping allows practitioners to enrich existing BPMN models with a communication layer, yielding a more complete representation of both control flow and information exchange. The authors cite industrial experience where augmenting BPMN diagrams with CA‑derived message specifications prevented data‑flow omissions and streamlined downstream design activities.

The authors also acknowledge limitations. Over‑abstraction in CED may obscure concrete operational steps, making it harder for developers to translate the model into executable processes. The text‑based nature of Message Structures can become unwieldy for deeply nested data, necessitating specialised tooling for visualization and management in large‑scale projects. Finally, while Event Specification Templates promote consistency, they can be rigid; domain‑specific extensions may be required to capture unique business nuances.

In conclusion, the paper argues that Communication Analysis offers a pragmatic bridge between requirements elicitation and process modelling by foregrounding information exchange. Its techniques are especially relevant for modern micro‑service and API‑first environments where contracts and message semantics are central. Future work suggested includes the development of automated transformation tools, meta‑model integration, and empirical studies on scaling the methodology in large organisations.