The utility and practicality of iStar framework can be afected by various factors, such as its conceptual model, ways of modeling, and supporting tools. In this paper, we report our ongoing empirical work that aims to investigate the experience of iStar beginners, based on which we explore how beginners can learn and use iStar framework more easily. In particular, we present a research design of this work and discuss initial results from a specific case. In the future, we plan to conduct a series of case studies, based on which we want to propose a practically eficient iStar modeling procedure and a corresponding CASE tool.
Requirements modeling is an efective way for requirements analysis, and i* modeling is one of
the powerful means and gets widely recognized [
Last year we conducted a controlled experiment aimed to compare graphical and textual
modeling in iStar framework [
Abrahão et al. [
In this paper, we systematically design a case study protocol, with the aim of exploring beginners’ experience with iStar 2.0. We then conduct a specific case, and report its results. We focus on investigating an easy way to learn and use iStar framework from a beginner’s perspective. In the remaining parts of this paper, we introduce the case study protocol we designed in Section 2. Then we present the initial results from a specific case in Section 3 and discuss threats to validity in Section 4. Finally, we conclude and describe future work in Section 5.
We plan to perform a case study to attain beginners’ experience of learning to use iStar 2.0. For
conducting the case study, we followed the guidelines of Wohlin et al. [
Improving the learning experience of beginners can efectively promote the widespread adoption of iStar. Thus, we want to find out how to make it easier for beginners to learn and use iStar 2.0. To this end, we formulate six research questions (RQs).
• RQ1: How dificult is it for beginners to learn iStar 2.0, and what are the reasons for this? • RQ2: What is an efective way to teach beginners iStar 2.0? • RQ3: What are the modeling processes adopted by beginners? • RQ4: What are the dificulties of iStar modeling in practice? • RQ5: Can these dificulties be mitigated or solved by a tool? • RQ6: What requirements do beginners have for an iStar modeling tool?
To answer the six RQs, we design our case study process as shown in Figure 1, which consists of eight steps, falling into three parts. In the current section, we will detail the design of the ifrst two parts, Planning, and Operation in the following two subsections, i.e., Section 2.3 and Section 2.4. As for the third part, we report the initial results we got from a specific case in the next section.
In the planning part, we first selected the participants. Then we designed the iStar 2.0 tutorial, modeling and interview sessions for our participants. The titles of papers should be either all use the emphasizing capitalized style or they should all Planning
Operation 1. Participants External data selection iStar 2.0
tutorial slides 2. Tutorial
design 3. Modeling session design 4. Interview design
Tutorial
plan Modeling plan
Main questions 5. Introduction to iStar 2.0 6. iStar 2.0 modeling 7. Interview iStar model Interview results
Analysis
Data flow 8. Results analysis
We performed the eight steps of the three parts according to the serial number.
The selection of participants determines the validity of the whole case study. Here we make a
balance between operability and representativeness. We plan to select students at our university
who have developed software with real users as participants. Although they are students, we
believe their experience is similar to engineers new to the industry. These students’ experience
in practical software development is just the right thing to build a bridge between academia
and industry. We plan to carry out our case study with such students one by one until we reach
saturation status, i.e., the status we cannot gain any new information or viewpoint from new
participants [
We choose the iStar 2.0 Tutorial slides1 as our handouts. The explanation is partial without involving quality and relations associated with it to simplify this procedure. We assign one of our authors to teach iStar 2.0 to participants. During the tutorial, we allow participants to ask questions at any time. We do not limit the length of the tutorial. We will not end this session until participants have no more questions about iStar 2.0.
For each participant, the modeling scenario is the actual application scenario of the software the participant has developed. If a participant has developed more than one software in practical use, we will choose the largest one. For modeling, we plan to use a whiteboard way. We believe that the whiteboard modeling is a pure approach and will allow us to exclusively focus on the conceptual model of iStar framework rather than various usability issues of modeling tools. Specifically, we provide several sheets of white A4 paper, a black pen, and a red pen to 1https://www.dropbox.com/s/4l2k4tbywb8wekk/iStar-tutorial-online.pdf?dl=0 participants for modeling. Here we choose black and red pens as they are the two pen colors we use most often in our daily lives. During the modeling process, participants could refer to the tutorial slides and ask questions at any time. Similar to the tutorial, we still have no time limit here. The modeling session will not end until participants think they have finished modeling. In addition, as a final result of the modeling session, we ask each participant to provide an iStar model that we can fully understand.
Referring to the work of Ournani et al. [
ThWeetietlxepseocft pthaepevrisewshsoeuxldprbeesseeidthbeyr atlhleupseartthieciepmanpthsaisnizoiungr icnatpeirtvaileizwedcosutylldeboer athbeleytsohoanusldwaelrl tahnedRQs, so we set the main questions in the interview according to our RQs. Figure 2 shows tFheosrethqeuesestcioonnds oabnjdechtoivwe,thweeyfroerlmatuelattoetahneoRthQesr tawndo roeusrearercsheaqruchesotibojnesc.tiavneds.
Making it easier for beginners to learn iStar 2.0 RQ1: How difficult is it for beginners to learn iStar 2.0, and what are the reasons for this? 1. What models have you built during your practice of software engineering? For the models, which are easy to learn? 2. What characteristics do you think would make these models easy to learn? 3. What similarities and differences do you think between iStar and the other models? 4. Do you think iStar is easy to learn or not? RQ2: What is an effective way to teach beginners iStar 2.0? 5. What are the priorities do you think to learn iStar? 6. Do you think your previous modeling experience has helped you in your iStar learning? If so, how has it helped you? Making it easier for beginners to use iStar 2.0 RQ3: What are the modeling processes used by beginners? 7. What is the process you used in iStar modeling? Can you think of any other processes? What is your preference? RQ4: What are the difficulties of iStar modeling in practice? 8. Is the iStar framework itself easy to use? Are there any problems with using iStar to model and analyze requirements? RQ5: Can these difficulties be mitigated or solved by a tool? 9. Can these problems be mitigated by the capabilities of certain modeling tools with specific interaction designs? RQ6: What requirements do beginners have for an iStar modeling tool? 10. If you can use a tool when modeling, what features would you like to see in it? Which interactions would you like to use in which tasks? Research objective Research question
Interview main question
One of our authors experimented with one participant. The author recorded the whole process with the consent of the participant. The author first introduced iStar 2.0 to the participant and then accompanied the participant in modeling. Finally, the author interviewed the participant. In the end, it took 20 minutes to the tutorial, 50 minutes to modeling, and an hour to interview. In addition to the audio recordings, the author took note of what the participants said during the interview. It is worth noting that what the author took down had been confirmed with the participant to ensure that these notes were what the participant wanted to express.
We report the interview results from a specific case in this section.
For privacy and confidentiality purposes, we use a code name P1 as the participant’s name. P1 is a fourth-year undergraduate at Beijing University of Technology, majoring in computer science. In the past three years, P1 has developed and operated a modeling platform. To date, the platform has been running for two years and has over 200 unique real users. P1 acknowledges the importance of requirements modeling and has some experiences with use case modeling, but has no experience with iStar modeling.
For the modeling session of our experiment, we asked P1 to use iStar to model and analyze the requirements in the scenario based on real situations where users are currently using P1’s modeling platform. The final iStar model P1 built has 4 actors, 20 intentional elements, 21 intentional element links, and 8 dependencies, 53 model elements in total.
According to our interview design in Section 2.3.4, P1’s responses in the interview should answer the RQs. Therefore, we report the interview results in the order of the RQs as following.
RQ1: How dificult is it for beginners to learn iStar 2.0, and what are the reasons for this? P1 believes that of all models P1 has built, the UML class diagrams, Entity-relationship diagrams, Data flow diagrams, Use case diagrams, and iStar 2.0 are in ascending order of dificulty to learn. For P1, UML class diagrams are easy to learn since they are very similar to code structures. P1’s experience in programming exactly can help P1 learn UML class diagrams. P1 explained that requirements modeling is usually more dificult than design modeling, and the complexity of the iStar modeling framework makes it even more dificult than use case diagrams.
RQ2: What is an efective way to teach beginners iStar 2.0?
P1 believes that it is important and dificult to extract requirements from users’ perspectives when first starting to model. If we want to teach beginners iStar 2.0 efectively, we should focus on it. In addition, P1 said that the similarities between the learned model and iStar could generate help in learning iStar.
RQ3: What are the modeling processes used by beginners?
Regarding the modeling process, P1 stated that P1 would list only the user requirements at the beginning, and then the user requirements would elicit the system requirements. In addition, P1 said that it was also a way to list a user requirement and then immediately analyze its corresponding system requirements for modeling. However, P1 believes that such a process can easily lead to confusion.
RQ4: What are the dificulties of iStar modeling in practice? RQ5: Can these dificulties be mitigated or solved by a tool? RQ6: What requirements do beginners have for an iStar modeling tool?
P1 thinks that iStar modeling is tough to get started, but the modeling results are helpful. P1 believes that the use of tools can mitigate some of the dificulties. For instance, an intelligent modeling tool that can extract model elements from requirements text automatically.
In this section, we discuss threats that might afect the validity of our research result. Here we
adopt a classification scheme from Runeson et al. [
Construct validity In our interviews, misunderstandings and misinterpretations of the iStar framework or question descriptions can afect construct validity. To mitigate these threats, we encourage participants to think aloud so that we can correct them if necessary. Another aspect is whether the dificulties originate from the iStar metamodel or are rather inherent to goal modeling and goal orientation. As the start of a long-term study, we plan to make the distinction after we have figured out the dificulties of the iStar framework as comprehensively as possible. In other words, this is part of our future work.
Internal validity Our experiment requires participants to have software development experience, so the selection of participants is not random, which could pose a threat to internal validity. The quality of the requirements involved in the modeling session may also afect the results of the experiment. Ambiguous requirements descriptions may also make iStar modeling dificult.
External validity Although our participants are only students, their real software development experience can mitigate the threat to external validity to some extent. However, the external validity still needs to be further demonstrated through experimentation in industry settings.
Conclusion validity The small sample size is a general threat to conclusion validity. We will mitigate this threat by conducting experiments with much more participants in our future work.
In this paper, we present the design of a case study that we plan to conduct to explore the experiences of iStar beginners. We intend to find an easier way for beginners to learn and use iStar framework based on the results from the case study. Specifically, we have carefully designed a research protocol and conducted the study through a specific case. We report our initial results from that case.
As for future work, firstly, there is no doubt that we will continue the research with more participants. In addition, based on the experience we gained in this experiment with the specific case, we need to ensure the quality of the requirements for modeling before our case study. Secondly, we will also analyze the data from the modeling session. Specifically, these data include the mistakes made by participants, the time they spent on each procedure throughout the modeling process, and the questions they asked during the modeling session. Lastly, we will also analyze the content of the modeling results from participants, including how they use the red and black pens during their modeling. Based on the results, we plan to propose an iStar modeling procedure and a corresponding CASE tool. We expect these will be efective in practice.
This work is partially supported by the National Natural Science of Foundation of China (No.61902010), and the Project of Beijing Municipal Education Commission (No.KM202110005025), and the International Research Cooperation Talent Introduction and Cultivation Project of Beijing University of Technology (No.2021C01).