Table 3 Technique for Inspecting MoLIC Interaction Diagrams (IMID)

Opening point Closing point

Verification item 1: Was the element used in the model to represent the start/end of the interaction? If not, report it as an Omission defect. Generated problem: This defect may impair understanding the beginning/ending of the interaction by the team members.

Verification item 2: If the previous item occurs, does the element represent the beginning / end of the interaction according to the requirements? If not, report it as an Inconsistency defect. Generated problem: This defect may impair the consistency of requirements with the appropriate start/end of the user interaction in the system (e.g. incorrect sequence of interaction scenes with regards to what was described in the requirements).

Scene, Signs, Dialogues and Structures of dialogues

Verification item 3: Are all requirements represented in the interaction model? If not, report it as an Omission defect. Generated problem: This defect may hinder the development of a necessary requirement (e.g. the software engineer did not capture all of the goals that the user could have, considering the requirements used as basis).

Verification item 4: Are there inconsistent requirements in the interaction model? If so, report it as an Inconsistency type defect. Generated problem: This defect may make the software inconsistent with the requirements (e.g. in a sequence of dialogues that should be structured with XOR, the AND structure was used).

Verification item 5: Is there information in the interaction model that is not in the context of the requirements? If so, report it as an Extraneous Information defect. Generated problem: This defect may make the software present irrelevant information (e.g. scenes that were not described in the requirements can be represented in the prototypes).

Verification item 6: Is it possible to understand all the information about the requirements in the interaction model in a clear way? If so, report it as an Ambiguity defect. Generated problem: This defect may cause the insertion of other defects in the developed artifacts, since each team member may have a different interpretation (e.g. description of similar scenes provided multiple interpretations about the user goals.)

Verification item 7: Have all requirements been correctly represented in the interaction model? If not, report it as an Incorrect Fact defect. Generated problem: This defect may hinder the development of correct requirement (e.g. the sign issuers can be attributed to the user or to the designer’s deputy in an incorrect manner with what was described in the requirements - confusion between “d:” and “u:”).

Transition Utterance and

Breakdown recovery utterance

Verification item 8: Are there any omissions on interactions required for the software features? If so, report it as an Omission defect. Generated problem: This defect may impair the user interaction with the system (e.g. lack of transitional utterance when switching from one scene to another, impairing the interaction sequence).

Verification item 9: Is the content of the interactions between the features consistent with the requirements? If not, report it as an Inconsistency defect. Generated problem: This defect may make the user interaction inconsistent from the requirements point of view (e.g. the content “u: play again” regarding the scene that is outside the context of the interaction in the game, such as the “see positive ending” scene).

Verification item 10: Is the content of the interactions between the functionalities in the context of the requirements? If not, report it as an Extraneous Information defect. Generated problem: This defect can also impair the user interaction from the point of view of the requirements (e.g. the content “u: search hotel” is outside the context of the game).

Verification item 11: Does the content of the interactions between the features provide multiple interpretations? If so, report it as an Ambiguity defect. Generated problem: This defect may provide for the insertion of other defects in the developed artifacts, since each team member may have a different interpretation (e.g. the use of two user transition utterances for the same goal, which provided multiple interpretations about the user transition).

Verification item 12: Have all interactions been correctly represented in the interaction model? If not, report it as an Incorrect Fact defect. Generated problem: This defect may hinder the development of correct interactions (e.g. in the breakdown recovery utterance, solid lines can be used, instead of the dashed lines).

System process

Verification item 13: Was the element required for the interpretation of an applied user action? If not, report it as an Omission defect. Generated problem: This defect can impair proper user interaction in the system after a certain action (e.g. an interpretation for the game results regarding the positive ending or negative ending).

Ubiquitous access

Verification item 14: Can the features associated with this element be accessed at any time in the user-system interaction? If not, report it as an Inconsistency defect. Generated problem: This defect may make the user interaction inconsistent from the requirements point of view (e.g. there is not opportunity for the user to change the topic of the conversation from any other scene for the game exit. Therefore the ubiquitous access element should not be related to closing point element).