Interactive systems construction requires customized development processes (with respect to main stream software engineering)  making more salient the implication of users throughout the various phases and especially during requirements elicitation and evaluation for which evaluation with users is critical. In the same way these development processes advocate the design of multiple solutions (in order to foster users’ involvement) providing users with various kinds of prototypes (both low-fidelity and high-fidelittty). The fact that several prototypes, either paper or software, are proposed and evaluated, increases the communication between designers and users and also increases usability of the system. However, this proliferation of options and solutions makes ration-ale management much more cumbersome.
In the field of safety critical interactive software, such as Air Traffic Control workstations or interactive cockpits, rationale management be-comes more and more critical. Incidents/accidents investigation and certification prior to deployment are two main reasons for such an interest in the rationale for selected design options. Our approach focuses mainly on safety critical systems to provide high-quality decisions.
Since 1990 we have been working in the field of formal description techniques for safety critical interactive distributed software. This work encompasses the definition of a formalism called Interactive Cooperative Objects based on High-level Petri nets and objects [3,4] specific extensions for distributed interactive systems [5, 6] and a CASE tool called PetShop [17, 18] for the edition, formal analysis and execution of the models.
Our notation and tools have been applied to several application domains such as satellite command and control workstations , Air Traffic Control workstation for en-route air traffic management , interactive mili-tary cockpits (RAFALE Aircraft)  or interactive civil aircraft cockpits (Airbus A380) .
Applying our research results to several domains has brought a new light on our work by showing that providing a reliable solution is not more valuable than providing the detailed rationale for that particular solution. Adding rationale behind decision improves the quality of interactive systems (see Sect. 1.4.3.). For approximately three years now, we have been working on a project for finding ways of providing the various participants throughout the development process of interactive safety critical software with notations and tools for the rationale management. The first version of the notation called TEAM (Traceability, Exploration and Analysis Mode) and its CASE tool (called DREAM for Design Rationale Environment for Argumentation and Modeling) are available on the web at the following address http://liihs.irit.fr/dream. They have been applied to several case studies and the aim of the chapter is to present those results in detail.