1. Group of Software Engineering
U N I V E R S I D A D D E C U E N C A , E C U A D O R
Lessons Learned on the use of i*
by Non‐Technical Users

2. 2
Outline
• Motivation. Purpose of this work
• The case study
• The lessons learned
• Conclusions

3. 3
Motivation (1/2)
• Early phases of the enterprise engineering process
are oriented to model the enterprise context
• Enterprise context models include environmental
actors and their relationships. Help understanding:
 the purpose of enterprises in their environment
 what is required from them
 how they generate value
Enterprise context models may be difficult to build:
• communicational gaps among technical and
administrative personnel
• limited knowledge of the enterprise structure,
operations and strategy

4. 4
Motivation (2/2)
To deal with these problems, we have used i* as:
• communicational means between stakeholders
• framework to discover business architectures
• language to define enterprise context patterns
In this paper, we focus on the first aspect

5. 5
Purpose of this work
We planned and conducted an empirical validation
case:
• intended to measure the ability of non‐technical
stakeholders to learn and use the i* notation in an
industrial setting

6. 6
Background – DHARMA method
4‐phase method for constructing EAs with i*
D
D
1. Enterprise
context
model (CM)
2. Introdu‐
cing the
system
3. Impact
analysis
4. Architec‐
ting a
solution

7. 7
The case study
• Medium size (10K students) private Ecuadorian univ.
 DHARMA method used to define the IT strategic
plan and project portfolio
• First step was the construction of the i*‐based CM.
 13 Organizational Areas (OA) contributed
 All stakeholders from them were non‐technical:
• operational, mid‐management and management
staff
• lawyers, business administrators, psychologists,
librarians, economists, accountants and
communicators

8. 8
The case study in numbers

9. 9
Lessons learned
Categorized in three phases:
Induction
(3 lessons)
Execution
(5 lessons)
Consolidation
(2 lessons)

10. 10
Lessons learned: Induction (1/3)
Provide a road-
map to perform
the work
Provide a road-
map to perform
the work
Provide basic
training1
22
Provide guide-
lines to improve
quality
Provide guide-
lines to improve
quality33
Focused sessions
Not too ambitious

11. 11
Lessons learned: Induction (2/3)
Provide a road-
map to perform
the work
2
Provide basic
training
Provide basic
training11
Clear outcomes
Precise timeline

12. 12
Lessons learned: Induction (3/3)
Provide basic
training
Provide basic
training11
Provide guide-
lines to
improve quality
3
Provide a road-
map to perform
the work
Provide a road-
map to perform
the work
22
methodology
execution notation

13. 13
Lessons learned: Execution (1/5)
Help users to
manage size4
Break the model
Allow non-graphical representations

14. 14
Lessons learned: Execution (2/5)
Avoid the use
of specialized
tools
Help users to
manage size
Help users to
manage size44 5
Time-consuming and rewardless
Let them draw and excel-ise!
Actor
Dependency
Type
Dependency Direction
Goal Agreements signed →
Resource Agreement Documents ←
Goal Technical formation provided ←
Resource Teachers ←
Resource Infrastructure ←
Goal Syllabus Prepared ←
Resource Curricula & Contents ←
Goal Curricula Approved →
Goal Contents Approved →
Goal Grades and assistance registered →
Resource Grades and assistance records →
Resource Grades and assistance formats →
Goal Enrollment/Inscription recorded →
Goal Admission exams taken →
Resource Regulations and Certificates →
01.03 Institutes

15. 15
Lessons learned: Execution (3/5)
Help users to
manage size
Help users to
manage size44 55
Do not over-
constrain user’s
imagination
6
Avoid the use
of specialized
tools
Avoid the use
of specialized
tools
Methods, notation, …

16. 16
Lessons learned: Execution (4/5)
55
Do not over-
constrain user’s
imagination
Do not over-
constrain user’s
imagination66
Do not expect
excellence7
Avoid the use
of specialized
tools
Avoid the use
of specialized
tools
Help users to
manage size
Help users to
manage size44
1
They have not become experts!
Flaws are easy to identify and correct

17. 17
Lessons learned: Execution (5/5)
55
Do not over-
constrain user’s
imagination
Do not over-
constrain user’s
imagination66
Avoid the use
of specialized
tools
Avoid the use
of specialized
tools
Help users to
manage size
Help users to
manage size44
Do not expect
excellence
Do not expect
excellence77
1
8
Review & pro-
vide feedback
continuosly
Stakeholders will require continuous but decreasing feedback.
Operational profiles require less corrections than managerial
Dependencies
Operational Area (OA)
Nb. of
Participants
Job Position
Nb. Correct
26 30%Treasury 1 Operational
91 28%Research Deanship 1 Operational
52 27%Libraries 1 Operational
39 26%
Administrative Coordination 1 Mid-manager
184 20%Faculties 6 Mid-manager
94 15%
Communications Department 2 Manager / operational
84 14%Students Welfare 3 Manager / operational
56 13%Financial Direction 1 Manager
68 12%Graduate school 1 Mid-manager
54 6%
Professional / Continuing
Education
1 Manager

18. 18
Lessons learned: Consolidation (1/2)
Plan for
validation
activities
9
Reconcile different styles i*-compliant
Manage large scaleExternal
(ECA)
Internal
(ICA)
Total
Goal
Soft‐Goal
Task
Resources
800 550 61 22 167
Type 179 155 3 6 15
Description 448 372 19 8 49
Direction 217 155 17 7 38
Deleted 20 13 1 3 3
Correct 221 90 35 6 90
239 65 45 15 114
Area
Actors Dependencies
Included in CMs by
Total 69 53
Incuded in non‐technical stakeholders CMs
Incorrect
Added by consultant

19. 19
Lessons learned: Consolidation (2/2)
Be aware of
consolidation
activities
10
Plan for
validation
activities
Plan for
validation
activities99
Putting together 13 different models

20. 20
Conclusions
Positive side:
• Set of lessons learned identified
• Stakeholders agreed that the actions described
in this work helped in the successful
conduction of the case
Negative side:
• Still the use of i* without an i* expert remains
a challenge

21. Group of Software Engineering
U N I V E R S I D A D D E C U E N C A , E C U A D O R
Thanks for your attention!