First year professional Master's students at the Faculty of Information, University of Toronto are taught how to analyze problem domains using i* modeling in the final segment of the introductory course on “Systems Analysis and Process Innovation”. Over the past several years, the course instructors and teaching assistants have had the opportunity to observe and interact with the course students on the learning and use of the i* framework for modeling and analysis which makes it possible to make general observations regarding student experiences with the i* framework in an instructional setting. These observations are broad ranging and cover areas such as pedagogical design, conceptual understanding and proficiency with the i* framework, domain modeling and analysis, and tools for i* modeling.
i* modeling [
Since teaching and learning experiences can vary widely according to contextual factors, we outline the educational setting of the course and the role of i* modeling within the course.
This course is taken primarily by first year professional Master’s students at the Faculty of Information. Students come from a diversity of academic backgrounds, ranging from humanities to social science, to business, and to health sciences. A small number have prior degrees in computing or information systems. Thus for many students, the course is their first exposure to systems analysis and modeling, while at the same time they are learning basic concepts of information technology and computer programming in concurrent courses. Upon graduation, the most common job role for past students of this course is “business analyst”.
The aim of the course is to introduce students to the methods, techniques, and practices of systems analysis, emphasizing the need to characterize as-is and to-be configurations of systems in organizational context at the conceptual level of “requirements” rather than at the level of implementation technology. The course also highlights the varying degrees of change that can result from systems analysis, ranging from “automation” that involves minimal reconfiguration of business processes, to “transformation” that rearranges relationships among key stakeholders, as in business model redesign.
Modeling techniques are introduced as conceptual tools to aid the representational
and analytical activities of the analyst. The emphasis is not on the various languages
per se, but rather on the modeling paradigms that they represent – BPMN and DFD as
illustrating the process-oriented paradigm, ERD and class diagrams for the
dataoriented paradigm, UML for the object-oriented paradigm, and i* as representative of
a goal- and agent-oriented paradigm. The intentional strategic actors perspective of i*
is further contrasted with the value network perspective of VNA [
An important objective is for students to acquire a critical reflective understanding
of a range of modeling paradigms and associated techniques, their capabilities and
limitations, as well as their underlying motivations and suitability for various
contexts. To this end, students engage in real-life case studies for project assignments
rather than rely on exercises and drills. The pedagogical design of the assignments is
further described in a companion paper [
Given the above instructional context for i*, we discuss our experiences, observations, and potential avenues for improvements in several areas. 3.1
The students were generally appreciative of the distinctive line of reasoning of the i*
framework and its complementary nature to other modeling techniques. Over the
duration of the course, students progress from process and data modeling to
agentoriented modeling [
Although the course objective is not to learn the i* language (or any other specific language) per se but to appreciate and experience first-hand the strategic actors thinking expressed through i*, students nevertheless need to acquire a sufficient level of proficiency in the language in order to benefit from the experiential learning in reallife projects.
Despite the limited instructional hours allocated to the i* segment in the course, we found that students were able to construct i* Strategic Dependency (SD) models fairly readily, and Strategic Rationale (SR) models with some extra effort. The following concepts typically require more attention. Most students overcome these conceptual barriers upon clarification during class or project discussions, although misconceptions also appear in final assignment submissions.
For SD models: Differentiating goal dependencies from task dependencies. Similarly for goal dependencies versus soft-goal dependencies. The direction of the dependency relationship between “depender” and “dependee” actors is at times incorrectly indicated. The naming of goals and other intentional elements are often stated according to domain-specific priorities (e.g., “Make more money”) rather than in accordance with naming guidelines for each type of element (e.g., “Profits be increased” for a softgoal vs. “Increase sales revenue” for a task goal). Distinctions among i* actor types (roles, positions and agents) are rarely used, as are IS-A relationships among actors. These are noted as more “advanced” concepts in class, to avoid cognitive overload for beginner learners. Their usage is recommended on an as-needed basis. IT systems are often modeled initially as resources to be used by other actors. The benefits of treating non-humans as actors require further explanation.
For SR models, difficulties often relate to the link types: Decomposition is readily understood, whereas means-ends requires more effort.
Initial models often confuse the two. A high-level goal is often directly decomposed into sub-goals without determining the possible means of achieving that end. This limits exploration of alternatives, and reduces the potential for model analysis, evaluation and alternative selection. Contribution links are generally understood, once the softgoal vs. goals distinction is made; however initial models often confuse means-ends with contribution links. 3.3
Throughout the course, the analytical powers of models are emphasized so that they are not seen as merely descriptive. In student work, such analytical capabilities are typically under-utilized. This applies to the earlier assignments involving process modeling, as well as to the assignment where i* is used. Models serve as descriptions, but conclusions are often drawn based on domain knowledge rather than using the models. The concepts of goal satisfaction analysis are typically not fully exploited; while students typically do perform some type of analysis to fulfill assignment requirements, they do not always use the results of these analyses to make recommendations. The reasons for this could be varied, ranging from incomplete domain models that lead to unhelpful or incorrect results, to students’ inexperience with model evaluation and analysis. As a result, students may be unable to provide strong and justified explanations on how the modeling analysis exercise helped them to come up with redesigned to-be alternatives which solve the issues in the problem domain. 3.4
Managing complexity and layout within i* SD and SR diagrams takes particular care
because of the flexibility of usage that the i* framework provides. It is easy to get
carried away with modeling a domain which can lead to unmanageable models.
Following the layout rules for i* models (such as no intersecting links or dependency
links having a natural flowing line [
Students are introduced to i* through class lectures with detailed examples, and
readings of selected representative papers on i*. The course adopts the version of i* as
described in [
A useful addition to the existing material would be a set of usage scenarios and examples that cover progressively more difficult cases, preferably using a large, realworld problem domain. The series of examples taken as a whole should be comprehensive so that the lesser used or more difficult to understand constructs (like IS-A relationships, different actor types, different contribution links etc.) are also covered. Detailed explanations on the various goal satisfaction analysis methods and their proper usage could then be provided by using this depicted domain model as an example setting. Instructional videos could be made which show the best practices and guidelines for i* modeling and analysis. These could be embedded within the wiki itself or uploaded to a video sharing site such as YouTube. These resources would further help students adjust to the agent- and goal-oriented paradigm in the limited time available to them and help them model and analyze problem domains using i* effectively and comprehensively. Such an endeavor could benefit from collaborative effort from the i* community. 3.6
Typically students in the course create i* SD and SR diagrams using either an i*
stencil for Microsoft Visio [
Recent advances in browser side web technologies, such as HTML5 and JavaScript, have made it possible to have a lightweight i* modeling software tool that runs entirely as a web application in a browser with the main server-side application hosted on a central system (similar to, for example, LucidChart, Gliffy). Any improvements made to this deployed environment would be immediately available to everyone as everyone accesses the same server. In addition to the capabilities of OpenOME and other i* related tools, the new software tool could have capabilities such as immediate checking of syntax and best practice violations, auto layout of i* models, built-in tutorials and examples, cooperative and collaborative modeling for student groups, ability to hide/show segments of the i* model, etc. Some of these features have already been implemented in other tools. Such improvements could make analysis and modeling of the problem domain using i* framework further accessible to students. 3.7
The assignments and studio presentations are structured to encourage reflection,
comparison between multiple modeling techniques and proposal of alternative methods of
achieving organizational objectives. The pedagogical design of the course is covered
in some depth in a companion paper [
The intention of this paper was to review and document our instructional experiences as course instructors and teaching assistants for the “Systems Analysis and Process Innovation” course. By sharing our experiences with the wider i* community, we hope to be able to collectively further develop instructional methods and enhance the in-class learning experience across the many universities where similar courses are on offer. Continuous pedagogical improvements to the course can benefit from systematic analysis of submitted assignments, subject to research ethics protocols. Input from students on specific aspects of the i* framework, through surveys or other means, can also be sought. 5