Skip to main content
SpringerLink
Log in

Understanding what is important in iStar extension proposals: the viewpoint of researchers

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

iStar is a goal-based requirements modelling language, being used in both industrial and academic projects of different domains. Often the language is extended to incorporate new constructs related to a particular application domain or to adjust it to practical situations during requirements modelling. Currently, the language is undergoing standardisation, and several studies have focused on the analysis of iStar variations to identify similarities and to define a core. This does not imply or constrain the need for iStar to continue to be extended. This paper contributes to the understanding of how iStar is extended by analysing how iStar researchers perform iStar extensions. To address this question, we followed a qualitative approach based on interviews involving 20 researchers from different research groups that proposed iStar extensions. The analysis revealed a good understanding about what extending a modelling language means and pointed out differences about how extensions are proposed. We discovered categories that impact positively on iStar extensions (such as reusing existing extensions, proposing extensions in abstract and concrete syntaxes, and creating new modelling tools), and other categories that impact negatively (such as modifying representations of the original constructs, proposing extensions in an ad hoc fashion and not carefully choosing graphical representations). We also evaluated the findings of interviews through an online survey answered by 30 iStar researchers. Finally, we proposed a set of guidelines to support the proposal for better future iStar extensions.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10

Similar content being viewed by others

Notes

  1. According to Strauss and Corbin [59], the term “Qualitative research” means any research that produces findings not obtained through statistical procedures or other means of quantification, so the sample should be small to enable the analysis. It can refer to research about experiences, behaviours and perspectives about a theme and is used to understand a phenomenon [59].

  2. We used the term “iStar” throughout the paper to refer to this modelling language, although the extensions presented in Sect. 2.3 extended the first version of the language, which was referred in the literature as “i*”.

  3. According to Van Lamsweerde [62], reasoning is an area studied extensively in Artificial Intelligence to generate conclusions from available knowledge. This method is used in many iStar extensions to generate a formal representation from the models.

  4. The term ad hoc is used throughout the paper, so we presented the meaning of this phrase according to Cambridge dictionary (https://dictionary.cambridge.org/dictionary/english/ad-hoc and https://dictionary.cambridge.org/dictionary/learner-english/ad-hoc) and Merriam-Webster dictionary (https://www.merriam-webster.com/dictionary/ad%20hoc): not regular or planned, only for a particular purpose or case without consideration of wider application.

  5. RStudio is a tool to perform statistical analysis based on commands in R. It is available to download at www.rstudio.com.

References

  1. Alencar F, Moreira A, Araújo J, Castro J, Silva C, Mylopoulos J (2006) Towards an approach to integrate i* with aspects. In: 8th International bi-conference workshop on agent oriented information system in 18th international conference on advanced information systems engineering

  2. Alencar F, Castro J, Lucena M, Santos E, Silva C, Araújo J, Moreira A (2010) Towards modular i* models. In: ACM symposium on applied computing, pp 292–297

  3. Ali R, Dalpiaz F, Giorgini P (2008) Location-based software modelling and analysis: Tropos-based approach. In: International conference on conceptual modelling, Lecture Notes in Computer Science, volume 5231. pp 169–182

  4. Ali R, Dalpiaz F, Giorgini P (2014) Requirements-driven deployment. In: Software and systems modelling. Springer, Berlin, pp 433–456

  5. Amyot D, Ghanavati S, Horkoff J, Mussbacher G, Peyton L, Yu E (2010) Evaluating goal models within the goal-oriented requirement language. Int J Intell Syst 25(8):841–877

    Article  Google Scholar 

  6. Asnar Y, Giorgini P, Mylopoulos J (2011) Goal-driven risk assessment in requirements engineering. Requir Eng J 16(2):101–116

    Article  Google Scholar 

  7. Babar Z, Nalchigar S, Lessard L, Horkoff J, Yu E (2015) Instructional experiences with modeling and analysis using the i* framework. In: iStar teaching workshop in 27th international conference on advanced information systems engineering, pp 31–36

  8. Brambilla M, Cabot J, Wimmer M (2012) Model-driven software engineering in practice. In: Morgan and Claypool publishers series synthesis lectures on software engineering

  9. Bennaceur A, Lockerbie J, Horkoff J (2015) On the Learnability of i*: experiences from a new teacher. In: iStar teaching workshop in 27th international conference on advanced information systems engineering, pp 43–48

  10. Borba C, Silva C (2009) A comparison of goal-oriented approaches to model software product lines variability. In: Workshop on requirements, intentions and goals in conceptual modeling in 28th international conference on conceptual modeling, advances in conceptual modeling: challenging perspectives, Lecture Notes in Computer Science, volume 5833. Springer, Berlin, pp 244–253

  11. Bresciani P, Perini A, Giorgini P, Giunchiglia F, Mylopoulos J (2004) Tropos: an agent-oriented software development methodology. Auton Agents Multi Agent Syst 8(3):203–236

    Article  MATH  Google Scholar 

  12. Burnay C, Jureta I, Faulkner S (2014) An exploratory study of topic importance in requirements elicitation interviews. In: 26th international conference on advanced information systems engineering, lecture notes in computer science, volume 8484. Springer, Berlin, pp 180–195

  13. Cares C, Franch X (2011) A metamodeling approach for i* model translations. In: 23th international conference on advanced information systems engineering. Lecture notes in computer science, volume 6741. Springer, Berlin, pp 337–351

  14. Chung V (2006) Considering role-based conflicts of interest in analysing and designing e-health systems with goal-oriented methodologies. In: International conference on privacy, security and trust, paper 78

  15. Chung L, Nixon B, Yu E, Mylopoulos J (2000) Non-functional requirements in software engineering. In: International series on software engineering, vol 5. Springer, US

  16. Creswell J (2014) A concise introduction to mixed methods research. Sage Publications, Thousand Oaks

    Google Scholar 

  17. Dalpiaz F, Paja E, Giorgini P (2011) Security requirements engineering via commitments. In: 1st workshop on socio-technical aspects in security and trust, pp 1–8

  18. Dalpiaz F, Franch X, Horkoff J (2016) iStar 2.0 language guide. arXiv:1605.07767. Available in https://sites.google.com/site/istarlanguage/. Accessed 20 July 2017

  19. Dardenne A, van Lamsweerde A, Fickas S (1993) Goal-directed requirements acquisition. Sci Comput Program 20(3):3–50

    Article  MATH  Google Scholar 

  20. De Kinderen S, Ma Q (2015) Requirements engineering for the design of conceptual modelling languages. Appl Ontol 10(1):7–24

    Article  Google Scholar 

  21. Elahi G, Yu E, Zannone N (2010) A vulnerability-centric requirements engineering framework: analysing security attacks, countermeasures, and requirements based on vulnerabilities. Requir Eng 15(1):41–62

    Article  Google Scholar 

  22. France R, Rumpe B (2007) Model-driven development of complex software: a research roadmap. In: Conference on future of software engineering. IEEE Computer Society, pp 37–54

  23. Franch X (2012) The i* framework: the way ahead. In: 6th International conference on research challenges in information science, pp 1–3

  24. Gans G, Lakemeyer G, Jarke M, Vits T (2006) SNet: a modelling and simulation environment for agent networks based on i* and ConGolog. In: 14th international conference on advanced information systems engineering. Springer, Berlin, pp 328–343

  25. Ghanavati S, Amyot D, Rifaut A (2014) Legal goal-oriented requirement language for modelling regulations. In: 6th International workshop on modelling in software engineering in 36th international conference on software engineering, pp 1–6

  26. Giorgini P, Rizzi S, Garzetti M (2005) Goal-oriented requirement analysis for data warehouse design. In: 8th ACM international workshop on data warehousing and OLAP, pp 47–56

  27. Gonçalves E, Heineck T, Castro J, Araújo J (2018) A systematic literature review of iStar extensions. J Syst Softw 137:1–33

    Article  Google Scholar 

  28. Guzman A, Martinez A, Agudelo F, Estrada H, Perez J, Ortiz J (2016) A methodology for modeling Ambient Intelligence applications using i* framework. In: International iStar workshop in IEEE international requirements engineering conference, pp 61–66

  29. He X, Ma Z, Shao W, Li G (2007) A metamodel for the notation of graphical modeling languages. In: 31th international computer software and applications conference, vol 1. IEEE Computer Society, pp 219–224

  30. Horkoff J, Elahi G, Abdulhadi S, Yu E (2008) Reflective analysis of the syntax and semantics of the i* framework. In: 27th International conference on conceptual modeling, lecture notes in computer science, volume 5232. Springer, Berlin, pp 249–260

  31. Horkoff J, Yu E (2010) Finding solutions in goal models: an interactive backward reasoning approach. In: 29th International conference on conceptual modeling, lecture notes in computer science, volume 6412. Springer, Berlin, pp 59–75

  32. Ingolfo S, Siena A, Mylopoulos J, Susi A, Perini A (2013) Arguing regulatory compliance of software requirements. Data Knowl Eng 87:279–296

    Article  Google Scholar 

  33. Ingolfo S, Jureta I., Siena A., Perini A., Susi A. (2014) Nomos 3: legal compliance of roles and requirements. In: 33th international conference on conceptual modeling, Lecture Notes in Computer Science, volume 8824. Springer, Berlin, pp 275–288

  34. Ingolfo S, Siena A, Mylopoulos J (2014) Goals and compliance in Nòmos 3. In: 7th international i* workshop in 26th international conference on advanced information systems engineering

  35. Islam S, Mouratidis H, Kalloniatis C, Hudic A, Zechner L (2012) Model based process to support security and privacy requirements engineering. Int J Secure Softw Eng 3(3):1–22

    Article  Google Scholar 

  36. Kelly S, Tolvanen J (2008) Domain-specific modelling: enabling full code generation. Wiley, Hoboken

    Book  Google Scholar 

  37. Kitchenham B, Pfleeger S (2002) Principles of survey research. Softw Eng Notes 26(6):16–27

    Google Scholar 

  38. Lapouchnian A, Yu Y, Liaskos S, Mylopoulos J (2006) Requirements-driven design of autonomic application software. In: 16th conference of the center for advanced studies on collaborative research, pp 80–94

  39. Lapouchnian A, Mylopoulos J (2009) Modelling domain variability in requirements engineering with contexts. In: 28th international conference on conceptual modeling, Lecture Notes in Computer Science, volume 5829, Springer, Berlin, pp 115–130

  40. Li T, Horkoff J, Mylopoulos J (2014) Integrating security patterns with security requirements analysis using contextual goal models. In: IFIP working conference on the practice of enterprise modelling, Lecture Notes in Business Information Processing, volume 197, pp 208–223

  41. Liaskos S, McIlraith S, Mylopoulos J (2009) Towards augmenting requirements models with preferences. In: 24th IEEE/ACM international conference on automated software engineering, pp 565–569

  42. Liaskos S, Mylopoulos J (2010) On temporally annotating goal models. In: 4th international i* workshop in 22th international conference on advanced information systems engineering, pp 62–66

  43. Lima P, Vilela J, Gonçalves E, Pimentel J, Holanda A, Castro J, Alencar F, Lencastre M (2016) An extended systematic mapping study about the scalability of i* models. CLEI Electron J 19(3):1–6

    Article  Google Scholar 

  44. Marosin D, Ghanavati S, Van Der Linden D (2014) A principle-based goal-oriented requirements language (GRL) for enterprise architecture. In: 7th international i* workshop in 26th international conference on advanced information systems engineering

  45. Mate A, Trujillo J, Franch X (2014) Adding semantic modules to improve goal-oriented analysis of data warehouses using I-star. J Syst Softw 88:102–111

    Article  Google Scholar 

  46. Mellado D, Mouratidis H, Fernandez-Medina E (2014) Secure Tropos framework for software product lines requirements engineering. Comput Stand Interfaces 36(4):711–722

    Article  Google Scholar 

  47. Merriam S (2009) Qualitative research: a guide to design and implementation. Jossey-Bass, San Francisco

    Google Scholar 

  48. Miles R, Hamilton K (2006) Learning UML 2.0. O’Reilly, Newton

    Google Scholar 

  49. Moody D (2009) The physics of notations: toward a scientific basis for constructing visual notations in software engineering. IEEE Trans Softw Eng 35(6):756–779

    Article  Google Scholar 

  50. Moody D, Heymans P, Matulevičius R (2010) Visual syntax does matter: improving the cognitive effectiveness of the i* visual notation. Requir Eng J 15(2):131–175

    Article  Google Scholar 

  51. Morandini M, Penserini L, Perini A, Marchetto A (2015) Engineering requirements for adaptive systems. Requir Eng J 22(1):77–103

    Article  Google Scholar 

  52. Mouratidis H, Giorgini P (2007) Secure tropos: a security-oriented extension of the tropos methodology. Int J Softw Eng Knowl Eng 17(2):285–309

    Article  Google Scholar 

  53. Mouratidis H, Islam S, Kalloniatis C, Gritzalis S (2013) A framework to support selection of cloud providers based on security and privacy requirements. J Syst Softw 86(9):2276–2293

    Article  Google Scholar 

  54. Mylopoulos J, Chung L, Yu E (1999) From object-oriented to goal-oriented requirements analysis. Commun ACM 42(1):31–37

    Article  Google Scholar 

  55. Murukannaiah P, Singh M (2014) Xipho: extending tropos to engineer context-aware personal agents. In: 13th international conference on autonomous agents and multi-agent systems, pp 309–316

  56. Siena A, Maiden N, Lockerbie J, Karlsen K, Perini A, Susi A (2008) Exploring the effectiveness of normative i* modelling: results from a case study on food chain traceability. In: 20th international conference on advanced information systems engineering, Lecture Notes on Computer Science, volume 5074. Springer, pp 182–196

  57. Siena A, Mylopoulos J, Perini A, Susi A (2009) Designing law-compliant software requirements. In: International conference on conceptual modeling, Lecture Notes in Computer Science, volume 5829. Springer, pp 472–486

  58. Siena A, Jureta I, Ingolfo S, Susi A, Perini A, Mylopoulos J (2012) Capturing variability of law with nomos 2. In: 31st international conference on conceptual modelling, Lecture Notes on Computer Science, volume 7532. Springer, pp 383–396

  59. Strauss A, Corbin J (2007) Basics of qualitative research: 2nd edn. In: Techniques and procedures for developing grounded theory, 3rd edn. Sage Publications, Inc

  60. Schulz F, Meissner J, Rossak W (2013) Tracing the interdependencies between architecture and organization in goal-oriented extensible models. In: 3rd Eastern European regional conference on the engineering of computer based systems, pp 25–32

  61. Teruel M, Navarro E, López-Jaquero V, Montero F, González, P (2011) CSRML: a goal-oriented approach to model requirements for collaborative systems. In: 33rd international conference on conceptual modeling, Lecture Notes on Computer Science, volume 6998, pp 33–46

  62. Van Lamsweerde A (2008) Systematic requirements engineering: from systems goals to UML models to software specifications. Wiley, Hoboken

    Google Scholar 

  63. Yu E (1995) Modelling strategic relationships for process reengineering. Ph.D. Thesis on Computer Science, University of Toronto

  64. Yu E. (1997) Towards modelling and reasoning support for early phase requirements engineering. In: 3rd IEEE international symposium on requirements engineering, pp 226–235

  65. Yu E, Giorgini P, Maiden N, Mylopoulos J (eds) (2011) Social modelling for requirements engineering. MIT Press, Cambridge

    Google Scholar 

Download references

Acknowledgements

The authors thank all participants of this study. We also thank CNPQ/Brazil (Conselho Nacional de Desenvolvimento Científico e Tecnológico) for the financial support to the execution of this work, Universidade Federal do Ceará (UFC), LER-Universidade Federal de Pernambuco (LER/UFPE) and NOVA LINCS Research Laboratory (Ref. UID/CEC/04516/2013).

Author information

Authors and Affiliations

  1. CIn, Universidade Federal de Pernambuco—UFPE, Av. Jornalista Aníbal Fernandes, s/n - Cidade Universitária (Campus Recife), Recife, PE, 50740-560, Brazil

    Enyo Gonçalves & Jaelson Castro

  2. Universidade Federal do Ceará - Campus Quixadá, Quixadá, CE, 63900-000, Brazil

    Enyo Gonçalves, Marcos Antônio de Oliveira & Ingrid Monteiro

  3. NOVA LINCS, FCT, Universidade Nova de Lisboa, Lisbon, Portugal

    João Araújo

Authors
  1. Enyo Gonçalves
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Marcos Antônio de Oliveira
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Ingrid Monteiro
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Jaelson Castro
    View author publications

    You can also search for this author in PubMed Google Scholar

  5. João Araújo
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding authors

Correspondence to Enyo Gonçalves or Jaelson Castro.

Appendices

Appendix A: Script interview (complete version)

This is the complete interview script used to conduct the interviews. It is composed of 11 questions structured in 4 parts.

1.1 Part 1. Profile: pre-survey

  • What is your current occupation (Professor/Researcher/Developer)?

  • How many years of experience do you have using iStar?

  • We identified the following iStar extensions proposed by you. (Show the list of iStar extensions of author identified). Are there any extensions to IStar done by you that we have not mentioned?

1.2 Part 2. Experience on iStar and extensions

  1. 1.

    Based on your experience, what is extending a modelling language?

  2. 2.

    How would you describe the process followed in the creation of your extension(s)? In other words, what were the tasks/activities performed since the moment of identification of the necessity of extending, up to the moment when the extension was done?

  3. 3.

    Contextualization: With your extension(s), new concepts were introduced in iStar through new forms of representation/modification of existing representations. How were these new concepts selected/chosen?

    • The identification was made based on the bibliography/references in the field? Systematic Literature Review? Others’ studies?

  4. 4.

    Contextualization: Generally, a modelling language creation/extension involves the proposal of its abstract syntax and concrete syntax.

The abstract syntax is a way to represent the concepts involved in the modelling language in a structured way. This is done through a metamodel and well-formedness rules that are used to verify the correctness of the models to be created. The figure below shows an iStar metamodel (Fig. 11).

Fig. 11
figure 11

iStar metamodel

Full size image

The concrete syntax is a graphical representation of a modelling language. Below is an example of a model that uses the concrete syntax of iStar (Fig. 12).

Fig. 12
figure 12

Illustration of usage of concrete syntax of iStar

Full size image

Considering the concepts presented above, how were these syntaxes specified in your extensions (abstract/concrete/both)?

  • In case the abstract syntax has not been considered: Have you considered the representation of the extension in the abstract syntax? Why?

  • In case the abstract syntax had been considered: How do you evaluate the importance of using the abstract syntax in your extension?

  • There was some concern in maintaining consistency between the concrete and abstract syntaxes? In the case the response is yes, How? If the interviewed has difficulty: Through traceability between metaclasses of the metamodel and related graphical representation, for example.

  • Do you think that it is important to maintain the consistence between them?

  • Do you think that it is important to maintain the consistence between the extension and iStar syntaxes? In other words, is it important to represent the abstract and concrete syntaxes completely in the way we have defined?

  1. 5.

    What were the difficulties when defining the abstract and concrete syntaxes for your iStar extension(s)?

    • Have you reused some graphical representations of an existing extension? Why/why not?

    • How was chosen the graphical representation for the new constructs?

    • Do you consider important a carefuly chosen the graphical representation?

  2. 6.

    What are the advantages of providing a modelling tool that supports the extension?

    • What can be done to help researchers to implement its extensions in tools?

  3. 7.

    Cite one iStar extension that you consider that was well done and why. Cite an example of an extension that you consider not so good and tell us why.

1.3 Part 3. Inconsistency analysis

  1. 8.

    Given the following two hypothetical scenarios related to iStar extensions to model multi-agent systems:

Hypothetical Scenario 1: Suppose there are two extensions that represent the same concept in two different graphical forms. For example:

  • The Extension A add a diamond to represent Commitment;

  • The Extension B uses a pentagon to represent Commitment.

Hypothetical Scenario 2: Suppose that there are two extensions that represent two different concepts using the same graphical form. For example:

The Extension A adds a triangle to represent Norm;

The Extension B uses a triangle to represent Predicate (Fig. 13).

Fig. 13
figure 13

Problems in a hypothetical situation of iStar extensions

Full size image

Comment on the problems described in those scenarios in the following situations:

A user that receives an iStar diagram with norms and predicate.

A researcher that wants to reuse the notation of commitment in new extensions.

1.4 Part 4. Finalisation

  1. 9.

    Which actions could be done to ease the process of extending iStar?

  2. 10.

    Is there something about the extensions that we did not mention in the interview and you would like to talk about?

  3. 11.

    Do you have some question about the interview?

Appendix B: Responses to survey

The responses to survey of Sect. 6 are presented in Table 5.

Table 5 Responses to evaluation survey
Full size table

Appendix C: Evaluation survey data

We are interested in investigating if it is possible to consider the statements important to the iStar extensions researchers, so we considered the following hypotheses for each statement:

  • H0: The statement is important to iStar researchers.

  • H1: The statement is not important to iStar researchers.

We chose the Wilcoxon test to test the hypotheses. The results of hypotheses tests are presented in Table 6. We tested H0, that is, if the statement is important (greater than three). Following that, we tested H1, that is, if the statement is not important (less than three).

Table 6 Results of hypotheses tests
Full size table

When the p value is lower than 0.05 it means that hypotheses tested is true at a confidence level of 95%. The results of the hypotheses tests confirmed that S1–S17 are important (H0) with 95% of confidence.

According to the results of S12 (Proposing new graphical representation only to represent constructs in the same abstraction level of intentional elements, actors and iStar relationships) and S15 (Reusing other existing extensions to improve the understanding and acceptance of new extensions), it is not possible conclude with 95% of confidence that they are important (H0) or not important (H1).

The results of the hypotheses tests if S12 was not conclusive for the H0 and H1. In extensions related to practical aspects, sometimes a different abstraction level is necessary for the constructs, such as modules, information about time and cardinality. These representations are useful to iStar, but they can be considered in a different abstraction level of intentional elements, actors and iStar relationships.

The results of the hypotheses tests of S15 were also not conclusive for the H0 and H1. We can understand the divergence of responses to this statement by the example given in the following. Considers two existing iStar extension E1 and E2, where E1 was well defined and E2 was not well defined. On the one hand, E1 is clear, complete, without inconsistencies and conflicts. On the other hand, E2 is unclear, incomplete and with inconsistencies and conflicts. Therefore, when E1 is reused, it can improve the acceptance and understanding of new extensions. When E2 is reused, however, probably it will not contribute to improve the acceptance and understanding of new extensions.

The scripts used to perform these tests using RStudioFootnote 5 are presented in Table 7.

Table 7 Script of RStudio to evaluate data of survey
Full size table

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Gonçalves, E., de Oliveira, M.A., Monteiro, I. et al. Understanding what is important in iStar extension proposals: the viewpoint of researchers. Requirements Eng 24, 55–84 (2019). https://doi.org/10.1007/s00766-018-0302-5

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-018-0302-5

Keywords

Search

Navigation