Requirements engineering meets physiotherapy: an experience with motion-based games (draft)

Transcription

1 Requirements engineering meets physiotherapy: an experience with motion-based games (draft) Written by Pasquale, L., Spoletini, P., Pometto, D., Blasi, F., & Redaelli, T. (2013). Reviewed by de Feijter, Rico. Place: Utrecht University: Utrecht University Student nr.: Group: 1 Student assistant: Floor Aarnoutse Method: RE-FIT Technique: FLAGS

2 1 Introduction This paper examines the RE-FIT (Requirements Engineering For physiotherapy) method and the incorporated FLAGS technique, which are described in the paper from Pasquale, Spoletini, Pometto, Blasi and Redaelli (2013). The purpose of this paper is to analyse the work from Pasquale, Spoletini, Pometto, Blasi and Redaelli. Analysing is done first by describing the process of the method in the remainder of this chapter. Second, by giving an example of the application of the FLAGS technique in chapter 2. Third, by describing the process deliverable diagrams and the related activity and concept tables in chapter 3. Finally, by explaining the related literature to position the method and technique in chapter 4. Moreover, templates with instructions and filled in with the example and references are also part of this paper and can be consulted in chapter 4, 5 and 7. The paper from Pasquale, Spoletini, Pometto, Blasi and Redaelli (2013) puts forward that requirements engineering related to the design of games for physiotherapy is very hard since the physiotherapy requirements of the medical staff, the fun factor for patients and the technical restrictions of the system have to be taken into account. Therefore, a method has been thought of so that the concerns of the several parties involved can be met easier. This method contributes to the development of physiotherapeutic games by identifying, modelling and validating requirements in a collaborative manner. This is concretely done in the following way. The method starts with a brainstorming phase on the survey, which consists of questions related to physiotherapy goals (e.g. what physiotherapy goals need to be achieved?), patient s entertainment goals (e.g. what entertainment goals do you want to achieve?), movement (e.g. what movements does the patient have to perform?) and the physiotherapeutic environment (e.g. what movements need to be supported?). Moreover, this brainstorm phase on the survey involves the medical staff, software designers and the patients, which communicate possible concerns from all parties during the session. In the second step, patients and medical staff need to fill in the patient survey and the medical staff survey in order to capture requirements from both the medical staff and the patients. The third step encompasses observation. That is, in case the software designer cannot identify the movements described by the patients in the survey, it is needed to observe them to get acquainted with their movements. Obviously, it is very important that the software designer is familiar with these movements, since the application to be developed must meet the requirements of the patients and the medical staff. After the elicitation phase (step 1-3), requirements modelling and validation (step 4-7) takes place. The gathered requirements are modelled with the FLAGS (Fuzzy Live Adaptive Goals for Self- adaptive systems) technique in step 4. But before requirements can be modelled, the FLAGS metamodel may need to be altered, so that the requirements can be modelled for the specific situation. In this case several classes (movement, aid, controller, agent) and relations are added, so that it can be used as a base on which several physiotherapeutic games can be developed. When modelling the FLAGS meta-model is done, one can start modelling the requirements in a FLAGS goal model (step 5). In this model, the gathered requirements can be modelled in the form of goals, aid, movement and controller elements. After modelling, the model is validated in practice, through use of mock-ups; here, it may occur that the model does not meet the patient and medical staff s needs. When such a scenario takes place, it is key that both the medical staff and the software designers discuss the FLAGS goal model in another brainstorm session (step 6). Once agreement between the two parties on the model is reached, the software designers can start formalizing the model using Fuzzy temporal logic (FTL), which is also part of the FLAGS technique (step 7). It may also be the case that some elements used in the FLAGS goal model are already validated in preceding case studies. Another validation on the validated elements would then be redundant; therefore, these validated elements can directly be formalized after realising the model. To make the cohesion between 1

3 the aforementioned steps clearer, a BPMN model is made, which is expressed in Figure 1 and shows all the method steps in the form of a process. Figure 1: RE-FIT method steps displayed in BPMN The creators of the method are Liliana Pasquale, Paola Spoletini, Dario Pometto, Francesco Blasi and Tiziana Redaelli. Liliana Pasquale holds a PhD in Information and Communication Technology, whereas Paola Spoletini possesses a PhD in Computer Science. Francesco Blasi is more active in the pharmacology and the neuroscience field. He possesses a PhD in Neuroscience. Dario Pometto and Tiziana Redaelli have also contributed to the development of RE-FIT as they are both active in the medical field and work at the Spinal Unit of Niguarda Hospital. 2 Example The technique described in the paper to model and formalize requirements in the RE-FIT method is called FLAGS. FLAGS offers the possibility to model and formalize fuzzy goals, besides crisp goals. Distinctive about these fuzzy goals is that they cannot be concretely achieved, whereas crisp goals can. Instead, the achievability of these goals is vague and therefore they cannot either be satisfied or not, but they can be satisfied to a certain extent. Think of saving fuel while driving a car as a goal. It is not clear when this goal is concretely achieved. That is, fuel consumption can only be small, but that doesn t state whether the goal is clear-cut achieved or not. Instead, it is only satisfied to a certain extent, namely when a car only uses a small amount of fuel. The same way of thinking is applied to physiotherapy by modelling these kind of goals to evaluate the speed and correctness of movements realized by a person, which can only be done properly when the FLAGS goal model elements are formalized. A few steps need to be followed in order to apply FLAGS. These steps can be found in table 1 and will be further elaborated in this chapter by describing an example in which an application is defined on how to learn a robot to move like a human being. Table 1: Steps FLAGS technique. Step% 1.%Identify%requirements% 2.%Extend%FLAGS%metaCmodel% 3.%Choose%symbols%to%display%elements% 4.%Model%requirements%in%the%form%of% elements% 5.%Formalize%elements% % Description% Identify%requirements%by%observing% patients%and%analyzing%filled%in%surveys.% Extend%FLAGS%metaCmodel%to%the% situation.% Choose%correct%symbols%to%make%the% model%understandable%for%everyone% involved%in%the%situation.% Model%elements%based%on%the%information% gathered%through%the%elicitation%phase.% Take%into%account%the%modeling%of%goals,% movements,%agents,%decomposition%of% goals,%controllers%etc.% Formalize%elements%using%FuzzyCtime% Temporal%Logic.% 2

4 As the example concerns a robot application, and thus describes another situation, the FLAGS metamodel from Pasquale et al. (2013) is extended to the example described in this chapter. This extended FLAGS meta-model can be consulted in Figure 6. Furthermore, for the example it is assumed that the requirements are already identified and gave input to the FLAGS meta-model and the FLAGS goal model, which is explained later on. As can be seen in Figure 6, the FLAGS meta-model consists of several classes that describe the composition of the FLAGS goal model at an abstract level. It explains that either crisp goals (clear goals) or fuzzy goals (achievable to a specific extent) can be modeled. Besides, goals can influence each other (influenced by relationship) and can be decomposed into sub goals (decomposed by relationship). Achieving these goals is important for both the person and the robot, which are modelled as agents. Moreover, domain assumptions (conditions) and operations are adopted in the FLAGS meta-model and a person uses a controller to monitor his or her movements so that the robot can respond to these movements. After the meta-model is created, a FLAGS goal model can be set up according to the classes described in the meta-model. This model can be found in Figure 7, in which the FLAGS goal model of a robot application, including its adapted symbols, is given. In this model, the board and the hand controller use a specific controller symbol and the hand and feet movement use a specific movement symbol. The model shows a person who wants to satisfy entertainment goals and a robot that wants to satisfy robot goals. These goals can influence one another as well. As Figure 7 depicts, the learn goal of the robot can positively influence the see robot improving goal of the patient. Besides, the goals can also be broken down into sub goals. For example, a robot wants to learn how to rotate (sub goal, which belongs to the main goal learn ). In order to satisfy this goal, a person uses a board to perform feet movements so that a robot can replicate the person s movement as closely as possible. To make this all happen, the person needs to turn a certain angle to a certain direction. Then, the robot turns to a certain angle in that direction as well. Note that domain assumptions are not part of the model in this example as it is assumed that there are no further environmental conditions of importance, while executing the application. Looking further at the goals in the FLAGS goal model, a fuzzy goal, namely learn to rotate (assuming that a robot is never able to rotate the exact same degrees as a person), can be satisfied to a certain extent i.e. a robot rotates a few degrees to a specific direction, either left or right, depending on the feet movement of the person. This can be formalized using a Fuzzy-time Temporal Logic formula that applies to the board element: G(rotate_right α r_rotate_right(α)) The formula states that when a person turns an amount of degrees (α) to right, the robot should turn an amount of degrees to right as well. Moreover, it can be measured to what extent the goal is satisfied by comparing the difference between the angles from the person and the robot after turning. The papers from Baresi, Pasquale and Spoletini (2010) and Zadeh (1965) can be consulted for a more comprehensive explanation on the Fuzzy-time Temporal Logic subject. 3

5 3 Process Deliverable Diagrams This chapter describes both the PDD for the method RE-FIT and the PDD for its technique FLAGS. The term PDD is described in the paper from Weerd and Brinkkemper (2008) and is a meta-modelling technique that enables processes and their deliverables to be modelled. In such a diagram processes are modelled on the left side whereas deliverables are modelled on the right side. Below, the PDDs of the RE-FIT method and the FLAGS technique can be found in respectively Figure 2 and Figure 3. Figure 2: Process Deliverable Diagram RE-FIT method. As can be perceived in the method PDD, the first activity is about gathering data and is needed to be performed in order to process requirements, which is the second activity. Note that this activity is called requirements modelling in the paper from (Pasquale et al., 2013). Here the name Process requirements is apprehended for this activity, because requirements not only need to be modelled, but they also first need to be identified by the software designer before modelling can take place. This identification of REQUIREMENTs can either be done through OBSERVATION of the patient movements or by finding REQUIREMENTs in the filled in medical surveys. After identifying the REQUIREMENTs, they are processed in a so-called FLAGS GOAL MODEL, which subsequently, gives input to the fourth activity that concerns the validation of the FLAGS GOAL MODEL. Note that this is only needed in case the model doesn t fully consist of already validated elements. When it turns out during validation that there is a disagreement on the model, a brainstorm session is needed to discuss the shortcomings of the model. After discussing the shortcomings, the model needs to be 4

6 updated to make sure that everybody agrees on the model (note the conditional activities). Finally, the elements in the model need to be formalized. This can either be done after validating the model or in an earlier stage, directly after processing the requirements when they are already validated. Furthermore, while carrying out all of the aforementioned activities, several deliverables are produced. The first deliverables are the DISCUSSED MEDICAL STAFF SURVEY and the DISCUSSED PATIENT SURVEY. These are in the second activity used by the medical staff and the patients who fill in the surveys to realize FILLED IN MEDICAL STAFF SURVEYs and FILLED IN PATIENT SURVEYs. Then the software designers use these filled in surveys to gather REQUIREMENTs. Software designers can also observe patients resulting in an OBSERVATION that leads to zero or more REQUIREMENTs. Subsequently, these requirements are modelled in one or more FLAGS GOAL MODELs (one or more, because some requirements can be re-used in other FLAGS GOAL MODELs), which after realization is subjected to a validation in practice. When the FLAGS GOAL MODEL is validated, a VALIDATED FLAGS GOAL MODEL, which corresponds to one FLAGS GOAL MODEL, is yielded. The last activity is then concerned with formalizing the elements of which the FLAGS GOAL MODEL consists. In doing so, elements in the model become FORMALIZED ELEMENTs. Figure 3: Proces Deliverable Diagram FLAGS technique. In Figure 3 the FLAGS PDD can be found. This PDD is made in accordance with the RE-FIT PDD as the open activity Process requirements is elaborated by depicting its sub-activities and its deliverables that are relevant at this level of abstraction. First, the open activity starts with identifying the REQUIREMENTs by analysing the filled in surveys (deliverables that are not shown in this PDD). 5

7 Second, the REQUIREMENTs are used to give form to the EXTENDED FLAGS META-MODEL. Third, SYMBOLs must be made in order to make the FLAGS GOAL MODEL and its contents understandable for medical staff and patients. Fourth, when all this is done, the REQUIREMENTs can be modelled. Last but not least, the formalize elements activity is again adopted in this technique PDD, because formalizing is part of the FLAGS technique as well. The technique activities also produce deliverables, which are also in line with the open Process requirements deliverables in the RE-FIT PDD. The difference here is that the specific technique deliverables that are related to the method deliverables are given. For example, both types of REQUIREMENTs are depicted. Besides, the EXTENDED FLAGS META-MODEL is mentioned, which describes multiple FLAGS GOAL MODELs that in turn consist of ELEMENTs, AGENTs, REQUIREMENTs and SYMBOLs. Furthermore, the relationships in the FLAGS GOAL MODELs are made clear on meta-level. For instance, an AGENT connects to one or more ELEMENTs and an ELEMENT connects to one AGENT. Additionally, an ELEMENT connects to zero or more ELEMENTs and an ELEMENT is always connected by zero or more ELEMENTs. Other relevant information about goal influences and goal decomposition is shown in the additional rule box in the PDD s top right corner. 3.1 Activity table The process side of the PDDs can be elaborated by using an activity table. This table gives an overview of all the processes modelled in the PDDs. Important to note is that these processes are described in the form of activities and sub-activities. Therefore, Table 2 displays three columns with activities, sub-activities and their descriptions. This construction is adopted from table 1 in the paper from Weerd and Brinkkemper (2008). Table 2: Activity table Process Deliverable Diagrams RE-FIT and FLAGS. Activity Sub-activity Description Elicitation phase Brainstorm on the survey Medical staff, software designers and patients need to brainstorm on the survey to discuss and eliminate possible ambiguities regarding the questions in the survey. This produces a DISCUSSED MEDICAL STAFF SURVEY and a DISCUSSED PATIENT SURVEY. Fill in survey Medical staff fill in the DISCUSSED MEDICAL STAFF SURVEY and patients fill in the DISCUSSED PATIENT SURVEY to gather requirements, which can be used later on in the process requirements activity. For each medical staff member and patient this respectively yields a FILLED IN MEDICAL SURVEY and a FILLED IN PATIENT SURVEY. Observe patient In case answers in the surveys regarding movement are unclear, the patient(s) must be observed by the software designer to get a better understanding of the execution of their movements. This all happens under guidance of a physiotherapist (member of the medical staff). Observing the patient helps the software designer to identify MEDICAL STAFF REQUIREMENTS and PATIENT Process requirements Identify requirements Extend FLAGS meta- REQUIREMENTS. Besides observing the patient, software designers extract requirements from the FILLED IN MEDICAL SURVEYs and FILLED IN PATIENT SURVEYs. This produces MEDICAL STAFF REQUIREMENTs and PATIENT REQUIREMENTs. To model the gathered REQUIREMENTs, it is of 6

8 Validate FLAGS goal model Brainstorm on FLAGS goal model Formalize elements model Make symbols Model requirements importance that the FLAGS meta-model is extended to the physiotherapeutic situation. Therefore, a software designer has to adapt the meta-model. This produces an EXTENDED FLAGS META-MODEL. Software designers need to make SYMBOLs in order to model the requirements in a FLAGS GOAL MODEL. This is needed to make the FLAGS GOAL MODEL understandable for the medical staff and the patients who must be able to read the model in order to validate it. After giving the SYMBOLs form, software designers can start modelling the MEDICAL STAFF REQUIREMENTs and PATIENT REQUIREMENTs in the form of ELEMENTs in a FLAGS GOAL MODEL. When the FLAGS GOAL MODEL doesn t contain validated elements already, a validation in practice needs to be done. During such a validation medical staff and patients test the FLAGS GOAL MODEL in practice using mock-ups of the game to be developed. If it is not needed to validate the model, because it already contains validated ELEMENTs, software designers can directly start with formalizing the ELEMENTs belonging to the model. If it turns out after validating that the FLAGS GOAL MODEL doesn t comply with the needs of the medical staff and the patients, the medical staff and the software designers have to brainstorm on the model in order to discuss the shortcomings of the model. This produces a DISCUSSED FLAGS GOAL MODEL. After the discussion, the software designers can start updating the model according to the medical staff and patient s wishes. After the FLAGS GOAL MODEL is validated, the ELEMENTs in it can be formalized. This yields FORMALIZED ELEMENTs. Software designers are the ones who take care of the formalization. 3.2 Concept table The concept table provides information on the deliverables produced by the activities in the method and its FLAGS technique. The table consists of two columns, namely the concept and the description columns, which explain the definition of the concept and elaborate on the properties of concepts. In Table 3, the concepts and their descriptions related to the PDDs of RE FIT and FLAGS can be perceived. Again, setting up this table is done the same way as described in the paper from Weerd and Brinkkemper (2008). Table 3: Concept table Process Deliverable Diagram RE-FIT and FLAGS. Concept DISCUSSED MEDICAL STAFF SURVEY Description A medical staff survey that is discussed between the medical staff and the software designers before filling in. It consists of a DISCUSSED MEDICAL STAFF SURVEY id (Dmssid), to make a medical staff survey for a specific game unique. Furthermore, it contains categories pertained to the game (e.g. main objectives, pathology, environment in which the game is executed, movement, forbidden entertainment goals and data to be stored) and questions for the medical staff that are 7

9 DISCUSSED PATIENT SURVEY FILLED IN MEDICAL STAFF SURVEY FILLED IN PATIENT SURVEY OBSERVATION REQUIREMENT MEDICAL STAFF REQUIREMENT PATIENT REQUIREMENT EXTENDED FLAGS META-MODEL SYMBOL FLAGS GOAL MODEL VALIDATED FLAGS GOAL MODEL assigned to these categories (e.g. movement - what parameters of the patient should be measured to get more information of the correctness of the movement?) (Pasquale et al., 2013). A patient survey that is discussed between the patients and the software designers before filling in. It consists of a DISCUSSED PATIENT SURVEY id (Dpsid), to make a patient survey for a specific game unique. Furthermore, it contains categories pertained to the game (e.g. environment in which the game is executed, movement, entertainment goals and data to be stored) and questions for the patients that are assigned to these categories (e.g. movement - what movement do you want to carry out?) (Pasquale et al., 2013). A DISCUSSED MEDICAL SURVEY, which is filled in by a medical staff member after discussion. The properties Dmssid, Medicalstaffid (an id related to a medical staff member) and Answer are added to this concept, so that a unique FILLED IN MEDICAL STAFF SURVEY can be made (combination of Dmssid and Medicalstaffid), a relation can be made between the concerning DISCUSSED MEDICAL STAFF SURVEY and the FILLED IN MEDICAL STAFF SURVEY and an answer can be coupled to a specific question that belongs to a certain category (Pasquale et al., 2013). A DISCUSSED PATIENT SURVEY, which is filled in by a patient after discussion. The properties Dpsid, Patientid (an id related to a patient) and Answer are added to this concept, so that a unique filled in patient survey can be made (combination of Dpsid and Patientid), a relation can be made between the concerning DISCUSSED PATIENT SURVEY and the FILLED IN PATIENT SURVEY and an answer can be coupled to a specific question that belongs to a certain category (Pasquale et al., 2013). An OBSERVATION is a perception from a software designer of one or more movements performed by a patient. (Pasquale et al., 2013). REQUIREMENTs are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system (Sommerville and Sawyer, 1997). REQUIREMENTs from the medical staff. REQUIREMENTs from the patients. THE EXTENDED FLAGS META-MODEL is an extended version of the FLAGS meta-model so that it can be used in a specific domain (Pasquale et al., 2013). A template of an EXTENDED FLAGS META- MODEL with instructions is shown in Figure 4 and a filled in template of an EXTENDED FLAGS META-MODEL with example data from chapter 2 is shown in Figure 6. SYMBOLs are visualizations of the ELEMENTs in the FLAGS GOAL MODEL (Pasquale et al., 2013). THE FLAGS GOAL MODEL is a REQUIREMENTs model that consists of AGENTs, ELEMENTs (visualized by SYMBOLs) and their relations (Pasquale et al., 2013). A template of a FLAGS GOAL MODEL with instructions is shown in Figure 5 and a filled in template of a FLAGS GOAL MODEL with example data from chapter 2 is shown in Figure 7. THE VALIDATED FLAGS GOAL MODEL is a FLAGS GOAL MODEL that is validated in practice by medical staff and patients 8

10 DISCUSSED FLAGS GOAL MODEL AGENT ELEMENT OPERATIONS ELEMENT CONTROLLER ELEMENT AID ALEMENT GOAL ELEMENT ENTERTAINMENT GOAL PHYSIOTHERAPY GOAL FORMALIZED ELEMENT (Pasquale et al., 2013). The DISCUSSED FLAGS GOAL MODEL is a FLAGS GOAL MODEL that is discussed between the medical staff and the software designers. It is used to improve the FLAGS GOAL MODEL. AGENTs represent physical persons who express a sub-set of the goals and the requirements of the game (Pasquale et al., 2013). ELEMENTs categorize REQUIREMENTs in the form of PHYSIOTHERAPY GOALs to be satisfied by the physiotherapist, ENTERTAINMENT GOALs to be satisfied by the patient, movements to be performed by a patient (MOVEMENT ELEMENTs), controllers to be used while playing the game (CONTROLLER ELEMENTs) and aids to support the patient (AID ELEMENTs) (Pasquale et al., 2013). The OPERATIONS ELEMENT expresses movement of the patient (Pasquale et al., 2013). The CONTROLLER ELEMENT expresses a controller (e.g. a board or a camera) used in the game to detect movements (Pasquale et al., 2013). The AID ELEMENT expresses objects used for support (e.g. a cushion on which a patient can sit so that a movement can still be performed) (Pasquale et al., 2013). An ELEMENT that expresses goals to be satisfied, while playing the game (Pasquale et al., 2013). ENTERTAINMENT GOALs aim at having fun, while playing the game (e.g. fun and play in teams) (Pasquale et al., 2013). PHYSIOTHERAPY GOALs aim at carrying out the exercises properly, while playing the game (Pasquale et al., 2013). A FORMALIZED ELEMENT is a formally specified ELEMENT that is formalized using Fuzzy-time Temporal Logic (Pasquale et al., 2013). 9

11 4 Related literature Requirements engineering has been around for a long time and is not only carried out within the physiotherapeutic domain. In fact, requirements engineering occurs on large scale. This means that it is carried out in various software development domains. To give a few examples; Weber and Weisbrod (2002) describe requirements engineering in the automotive domain. Another paper, which underpins this, is the paper from Kamsties, Hörmann and Schlich (1998) who describe how requirements engineering can be deployed in small and medium-sized enterprises. When examining the requirements engineering field further, it also becomes apparent that, besides FLAGS, many other modelling techniques are used to model requirements. For instance, Šilingas and Butleris (2009) show that requirements can be modelled using use case diagrams and activity diagrams in UML, which is a well-known standard to model requirements. But not only UML is used for modelling. In fact, there are a variety of other requirements modelling techniques. For example, Mayr and Kop (2002) describe a modelling technique that is called KCPM. This modelling technique is semantically oriented, while UML is object oriented, which makes UML harder to learn. Another paper from Goldsby, Sawyer, Bencomo, Cheng and Hughes (2008) shows how a goal modelling technique can be maintained to model adaptive system requirements. Modelling requirements for self-adaptive systems is also exactly what FLAGS is capable of. FLAGS has its origins in KAOS. Bertrand, Darimont, Delor, Massonet and Lamsweerde (1997, p. 612) describe KAOS as a specification language for capturing why, who and when aspects in addition to the usual what requirements. The language does this by decomposing goals into sub-goals using AND-refinement on the one hand, and OR-refinement on the other hand to describe multiple ways of realizing goals. In addition to KAOS, FLAGS also has its origin in temporal logic, described in (Whittle, Sawyer, Bencomo, Cheng, & Bruel, 2009) and in the fuzzy sets from Zadeh (2010), which both contributed to the formation of Fuzzy-time Temporal Logic. Although FLAGS is a comprehensive technique, it has not yet been applied in other domains outside the scope of physiotherapy. Still, the underlying thought of the technique, namely using and formalizing fuzzy goals, is used for other purposes. For example, to let a system explain how it meets its requirements (Welsh, Bencomo, Sawyer, & Whittle, 2014). Furthermore, other goal modelling techniques have been applied in different domains throughout the years. This is shown in the papers from Krogstie (2008) and Donzelli and Bresciani (2003) in which is stated how goal modelling has been used in organizations and in the field of information systems. Also, more recently several researches show that researchers are still active in developing and improving goal-modelling techniques for several purposes. For instance, a very recent paper shows that goal modelling is used to model government regulations (Ghanavatti, Amyot, & Rifaut, 2014). 10

12 5 Templates with instructions This chapter contains templates of the extended FLAGS meta-model and the FLAGS goal model. The templates are based on the example described in chapter 2 and contain only abstract information so that both models can be applied in other domains. Figure 4: Template of an extended FLAGS meta-model. Figure 4 shows the template of the extended FLAGS meta-model. The template describes the composition of a FLAGS goal model on meta-level in the form of classes and relations. Filling in these classes with situational specific attributes makes it possible to adapt the meta-model to a particular situation for which a FLAGS goal model can be made afterwards. A further explanation of the meaning of the classes can be found in chapter 2. FunctionalGoal FunctionalGoal Operations Element Controller Element Agent Figure 5: Template of a FLAGS goal model. Figure 5 shows a template of a FLAGS goal model, which adheres to the extended FLAGS metamodel from Figure 4. This template can be used to realize a situational specific FLAGS goal model by defining the goal elements (functional goals), operation elements, controller elements and the agents. 11

13 6 Templates filled in with example An example is defined in chapter 2 in which a robot application is explained. The figures to which chapter 2 refers, can be found below where both templates from chapter 5 are filled in with the example data from chapter 2. Figure 6: FLAGS meta-model describing the FLAGS goal model of a robot application. Have fun Robot AND See robot improving + Learn Robot goal Entertain ment AND Entertainment goal Person Learn to rotate Learn to rotate hands Movement Controller Feet movement Hand movement Agent Board Board Figure 7: FLAGS goal model of a robot application. 7 References Baresi, L., Pasquale, L., & Spoletini, P. (2010). Fuzzy goals for requirements-driven adaptation. Proceedings of the requirements Engineering Conference (RE), th IEEE International, Milano, Italy,

14 Bertrand, P., Darimont, R., Delor, E., Massonet, P., & van Lamsweerde, A. (1997). GRAIL/KAOS: an environment for goal-driven requirements engineering. Proceedings of the 19th international conference on Software engineering, New York, USA, Donzelli, P., & Bresciani, P. (2003). Goal-oriented requirements engineering: a case study in e- government. Proceedings of the Advanced Information Systems Engineering, Berlin, Germany, Ghanavati, D., Amyot, A., & Rifaut A. (2014). Goal- oriented compliance with multiple regulations. Proceedings of the 6th International Workshop on Modeling in Software Engineering, New York, USA, 1-6. Goldsby, H. J., Sawyer, P., Bencomo, N., Cheng, B. H., & Hughes, D. (2008). Goal-based modelling of dynamically adaptive system requirements. Proceedings of the 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, Belfast, UK, Kamsties, E., Hörmann, K., & Schlich, M. (1998). Requirements engineering in small and medium enterprises. Requirements engineering, 3(2), Krogstie, J. (2008). Using EEML for combined goal and process oriented modelling: A case study. Proceedings of EMMSAD, Trondheim, Norway, Mayr, H. C., & Kop, C. (2002). A User Centered Approach to Requirements Modelling. In M. Glinz, G. Müller-Luschnat (Eds.), Modellierung 2002 (pp ). Tutzing, Germany: Springer. Pasquale, L., Spoletini, P., Pometto, D., Blasi, F., & Redaelli, T. (2013). Requirements engineering meets physiotherapy: an experience with motion-based games. Proceedings of the Requirements Engineering: Foundation for Software Quality conference, Berlin, Germany, Šilingas, D., & Butleris, R. (2009). Towards implementing a framework for modelling software requirements in MagicDraw UML. Information Technology and Control, 38(2), Sommerville, I., & Sawyer, P. (1997). Requirements engineering: a good practice guide. New York: John Wiley & Sons. Weber, M., & Weisbrod, J. (2002). Requirements engineering in automotive development-experiences and challenges. Proceedings of the IEEE Joint International Conference on requirements engineering (RE 02), Essen, Germany, Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (pp ). Hershey: Idea Group Publishing. Welsh, K., Bencomo, N., Sawyer, P., & Whittle, J. (2014). Self-explanation in adaptive systems based on runtime goal-bassed models. In R. Kowalczyk, & N.T. Nguyen (Eds.), Transactions on Computational Collective Intelligence XVI (pp ). Berlin: Springer. Whittle, J., Sawyer, P., Bencomo, N., Cheng, B. H., & Bruel, J. M. (2009). Relax: Incorporating uncertainty into the specification of self-adaptive systems. Proceedings of the Requirements Engineering Conference, RE'09. 17th IEEE International, Georgia, USA, Zadeh, L.A. (1965). Fuzzy sets. Information and Control, 8(3),