There seems to be a consensus that dealing with intentionality at early stages of software projects is a reasonable idea. i* Framework [9] models have been receiving greater attention from several researchers [1], [2] as an infrastructure to deal with intentionality. Although i* has been cited and used in different research projects, most of their users agree that i* models are complex artifacts [7]. Although comprised of few elements, the semantics involved in using them can make i* models prone to errors [7].
The majority of the work has been focused on i* modeling and how to use this information on later stages of software production. Our goal is to focus on analyzing i* models proposing a quality assurance process to produce better i* models. Process quality focuses on defect prevention rather than looking for defects on test phase. We propose an analysis technique to enhance the quality of i* models.
We illustrate our proposal using "The Expert Committee System" (EC System) exemplar [3], a system to support the organization of a conference program.
Figure 1 ( right ) shows the basic structure of an SRconstruct, which is formed by a goal (the goal's name is the SRconstruct's name) (as being the end) and at least by one task (as being the means to achieve the end). Therefore, all components (and subcomponents) needed by tasks (subtasks, resources, softgoals, and goals) should appear in the structure. Despite the fact that the goal is only one part of the SRconstruct, we identify each SRconstruct by the name of the goal that it fulfills. That is because there is only one goal (as being the END) in each SRconstruct.
Figure 1 ( left ) shows that one actor (CHAIR) and another actor (REVIEWER) can have multiple dependencies in each SDsituation Situations of dependency that occur in the organizational environment and the central idea of SDsituations is: "each dependency link (goal, softgoal, task or resource) that involves actors is not isolated"; it is part of one well defined situation of collaboration called one "strategic dependency situation" or one SDsituation [6].
The i* Diagnoses examine each canonical structure (SDsituations and SRconstructs) of a given model in order to bring questions that challenge the model consistency and completeness. The main idea is to focus on parts of an i* model and from these parts conduct an inquiry into the given construct.
Our process comprises 3 main sub-processes: IDENTIFY CONSTRUCTS, APPLY (INQUIRY) FRAMEWORK, and INTEGRATE QUESTIONS. The strategy is applied both to the Strategic Dependency Diagrams and to the Strategic Rationale Diagrams of i*.
The activity IDENTIFY CONSTRUCTS consists of breaking down the i* diagrams into constructs (SDsituations and SRconstructs). The activity APPLY (INQUIRY) FRAMEWORK consists of applying the inquiry framework to each construct. The activity INTEGRATE QUESTIONS consists of merging the questions to analyze them. The aim of each diagnose framework is to turn coupled SDsituations and SRconstructs inside out looking for problems, faults, deficiencies and potential improvements. "Diagnoses are important to deeply understand the problem before looking for the solution."
Given the basic structures of SDsituations and SRconstructs, general questions are proposed to each element. In real cases these "hot-spots" or "place-holders" would be replaced in Templates 3.1 and 3.2 by the actual names used in the model. 7. What are the problems with the task "meanTask's name"? Why? 8. For the task "meanTask's name" what are the components needed to achieve "endGoal's name"? a) Case: resource -What are "resource's name" problems of availability? (Time, accuracy). When? How? b) Case: subGoal -What are "subGoal's name" problems to be achieved by "dependee/actor"? (Time, ability). When? How? c) Case: softgoal -What are "softgoal's name" problems to be satisficed by "dependee/actor"? (Capability) Is there "softgoal's name" at the end of "SRconstruct goal's name"? Why? What are the contribution links to and from this "sofgoal´s name"? d) Case: subTask -Can "dependee/actor" perform "task's name"? (Time, ability) 9. Is there any softgoal details omitted, not fully operational or without operationalization? What kind? Why? How? How much? 10. Is there any resource missing? What kind? What if a resource is not available?
The first benefit of using i* canonic structures (SDsituations and SRconstructs) is managing complexity. Using SDsituations and SRconstructs, i* models can be divided into small pieces avoiding common misuses that appear in i* models [4] and also improving the stakeholders' understanding.
Our strategy provides a verification based analysis for i* models so as to assure better quality models overall. The verification analysis is performed on composing the constructs with well known general questions, the 5w2h framework [5] and with the ideas of Potts, Takahashi and Anton [8].
According to Moody [10], although software quality proposals have been concentrated at the end of the process, empirical works demonstrate that the majority of defects occur during the requirements phase.
We plan to continue the work in this direction as we will frame our diagnoses approach as a reading strategy for the inspection of i* models. By performing more analysis using the proposed i* diagnoses, we hope to improve the quality of the questions as they are today. We also foresee a possible automation, by generating the set of questions, given a set of i* models. Moreover, we plan to evaluate how this work may scale up to larger models.