Since the seminal work from Toulmin[27] in the late 1950s, design man-agement and argumentation have been the focus of many research activi-ties.
Interactive systems design (and more broadly speaking the Human–Commmputer Interaction field) promotes a user-centered design approach [21 ] to interactive system engineering thatt involves users in various phases. For instance, task analysis and modeling provide support for capturing and representing user activities [9] while interacting with a system. Such in-formation is then incorporated in many places in the design process as, for instance, in the design phases when the allocation of functions between the system and the users is defined, or later (in the evaluation phases) when the system is tested in order to check whether or not user activities are exhaustively supported by the system.
Our approach in design rationale is related to argumentation as defined in Sect. 1.3. The main notations related to this type of design rationale are IBIS (Issue-Based Information System) [12], see Sect. 1.3.1. and QOC (Questions, Options, Criteria) [14] see Sect. 1.3.2. These notations are able to capture argumentation and alternatives during the design process. These notations cannot store specific information related to interactive systems such as system modeling, task models, etc. Our proposal (detailed in Sect. 7.3) is to provide interactive systems designers with a notation for rationale management able to take into account specificities of interactive systems and more precisely safety critical ones. To this end, our approach focuses on Human–Computer Interaction concepts and how to integrate them. Besides, our approach is tool supported in order to address both scalability and cost/benefit concerns.
TEAM Notation
The TEAM (Traceability, Exploration and Analysis Mode) notation is based on QOC (as stated above introduced by MacLean [14]) and proposes several extensions in order to deal with the specificities of safety critical interactive systems and also to address some of the usability issues of QOC. The rationale for extending QOC is mainly based on its simplicity and readability that makes it understandable by most of the actors involved in interactive systems design such as graphic designers, developers, cus-tomers, certification authorities, etc. This easy to read and write notation, enhances collaboration between the participants as previously defined in Sect. 1.4.1. QOC was designed to support reuse in order to improve the reusability of the models .
