*Placement of people:* The idea is to generate a visual metaphor in the virtual environment that simulates the cake decorating station, so that the customer can interact with the design artifacts and can immersivity decorate the cake.

*People actions:* The customer can logically interact with the artifacts that are used in the cake decorating process, each interaction with a design element. Each time an object is interacted with, it responds by enlarging its size to make it easy to identify and manipulate. In the interface a diagram is designed that represents the activities and tasks and indicates in certain tasks what actions have been performed by the actors in the process.

*People's activity:* An activity log is generated that allows the actors to track changes and modifications made in each activity and its corresponding tasks, this allows group members to be informed of developments against the product design.

*Task structure:* A structure of activities is created whose workflow is similar to the decoration process in the real environment, through four basic steps such as choosing the size, choosing the flavor, choosing the topping and its color, and choosing the dec-oration design. Each of the activities is supported by a series of tasks that allow at the end of the process to have an accurate visual representation of the requirements that the customer has in front of the cake.

*Resource structure:* Each task is related to a particular type of resource, for example, when choosing the flavor of the cake, the available flavors must be shown in the interface, and so each structured activity is in charge of its own resources.

*Status of resources:* For the customer it is important to know the availability of dec-oration elements that he has to achieve his goal, he must also know the value of each element, for this task, an element counter is designed that adds up the price of each object used exactly, so that the customer can know when the type of decoration chosen exceeds his budget, and so he can have control over his expenses. In the same way, the pastry chef must know what resources he has available for the elaboration of the cake.

# 5 Discussion of results.

By applying the methodological framework, it was possible to identify the actors involved, their roles within the process, their specific activities and tasks, and to categorize the activities into three types: individual, cooperative, or collaborative.

By identifying the roles and tasks of each actor (Table 2), the awareness mechanisms necessary to support the collaborative process can be established.

Table 3 shows the type of awareness mechanisms assigned to each activity of the negotiation process. The process of defining the elements of decoration is used to exemplify the type of awareness elements that were used at the time of designing the prototype of the client interface for this activity (Figure 2).

To satisfy the client's needs for awareness information during the process of defining decoration elements, a low-resolution prototype of the client's interface was designed, where the semiotic representation of the awareness mechanisms applied and the type of information, they transmit can be graphically visualized (Table 4). When validating the graphical user interfaces designed with awareness mechanisms with the actors involved, a high degree of acceptance was identified by the users because the design of the metaphor that simulates the virtual environment of decorating a cake is based on business logic, and takes part of the symbolic language of the environment to generate a shared vocabulary, which allows generating a better understanding compared to the paper format, since the groupware tool to be designed allows visualizing in real time how the personalized cake looks like.
*Placement of people:* The idea is to generate a visual metaphor in the virtual environment that simulates the cake decorating station, so that the customer can interact with the design artifacts and can immersivity decorate the cake.

*People actions:* The customer can logically interact with the artifacts that are used in the cake decorating process, each interaction with a design element. Each time an object is interacted with, it responds by enlarging its size to make it easy to identify and manipulate. In the interface a diagram is designed that represents the activities and tasks and indicates in certain tasks what actions have been performed by the actors in the process.

*People's activity:* An activity log is generated that allows the actors to track changes and modifications made in each activity and its corresponding tasks, this allows group members to be informed of developments against the product design.

*Task structure:* A structure of activities is created whose workflow is similar to the decoration process in the real environment, through four basic steps such as choosing the size, choosing the flavor, choosing the topping and its color, and choosing the dec-oration design. Each of the activities is supported by a series of tasks that allow at the end of the process to have an accurate visual representation of the requirements that the customer has in front of the cake.

*Resource structure:* Each task is related to a particular type of resource, for example, when choosing the flavor of the cake, the available flavors must be shown in the interface, and so each structured activity is in charge of its own resources.

*Status of resources:* For the customer it is important to know the availability of dec-oration elements that he has to achieve his goal, he must also know the value of each element, for this task, an element counter is designed that adds up the price of each object used exactly, so that the customer can know when the type of decoration chosen exceeds his budget, and so he can have control over his expenses. In the same way, the pastry chef must know what resources he has available for the elaboration of the cake.

# 5 Discussion of results.

By applying the methodological framework, it was possible to identify the actors involved, their roles within the process, their specific activities and tasks, and to categorize the activities into three types: individual, cooperative, or collaborative.

By identifying the roles and tasks of each actor (Table 2), the awareness mechanisms necessary to support the collaborative process can be established.

Table 3 shows the type of awareness mechanisms assigned to each activity of the negotiation process. The process of defining the elements of decoration is used to exemplify the type of awareness elements that were used at the time of designing the prototype of the client interface for this activity (Figure 2).

To satisfy the client's needs for awareness information during the process of defining decoration elements, a low-resolution prototype of the client's interface was designed, where the semiotic representation of the awareness mechanisms applied and the type of information, they transmit can be graphically visualized (Table 4). When validating the graphical user interfaces designed with awareness mechanisms with the actors involved, a high degree of acceptance was identified by the users because the design of the metaphor that simulates the virtual environment of decorating a cake is based on business logic, and takes part of the symbolic language of the environment to generate a shared vocabulary, which allows generating a better understanding compared to the paper format, since the groupware tool to be designed allows visualizing in real time how the personalized cake looks like.
<table><caption>**Table 2.** Table of participation in the negotiation process of a cake.</caption><thead><tr><th>Activity / Roles</th><th>Custome<br>r</th><th>Salesperso<br>n</th><th>Pastry<br>chef</th><th>type</th></tr></thead><tbody><tr><td>Request for quote</td><td>x</td><td></td><td></td><td>Individual</td></tr><tr><td>Respond to request</td><td></td><td>x</td><td></td><td>Individual</td></tr><tr><td>Define delivery conditions</td><td>x</td><td>x</td><td></td><td>Cooperative</td></tr><tr><td>Define type of celebration</td><td>x</td><td>x</td><td></td><td>Cooperative</td></tr><tr><td>Define cake flavor</td><td>x</td><td>x</td><td>x</td><td>Collaborative</td></tr><tr><td>Define cake size</td><td>x</td><td>x</td><td>x</td><td>Collaborative</td></tr><tr><td>Define decoration elements</td><td>x</td><td>x</td><td>x</td><td>Collaborative</td></tr><tr><td>Define price of the cake.</td><td>x</td><td>x</td><td>x</td><td>Cooperative</td></tr></tbody></table>

<table><caption>**Table 3.** Table of Awareness mechanisms used in each activity within the negotiation process of a customized cake.</caption><thead><tr><th rowspan="2">Activity / Roles</th><th colspan="3">Awareness Mechanisms</th></tr><tr><th>Customer</th><th>Salesperson</th><th>Pastry chef</th></tr></thead><tbody><tr><td>Request for quote</td><td>- People's State: Availability</td><td></td><td></td></tr><tr><td>Respond to request</td><td></td><td>- People's State: Availability<br>- People's action: Event alert<br>- People's Activity: goals</td><td></td></tr><tr><td>Define delivery conditions</td><td>People's action: Event alert<br>- Norms: Time constraint</td><td>- People's action: Event alert<br>- Resources state: Availability</td><td></td></tr><tr><td>Define type of celebration</td><td>- People's State: Availability<br>- Task Structure: workflow<br>- Task State: started / in process / done</td><td>- People's State: Availability<br>- Task State: started / in process / done</td><td>- People's State: Availability<br>- Task State<br>- People's State: Emotions</td></tr><tr><td>Define cake flavor</td><td>- Task Structure: Workflow.<br>- Resources State: Availability<br>- People's Actions: decision tracking.<br>- Task State: started / in process / done</td><td>- Task Structure: Workflow.<br>- Resources State: Availability<br>- People's Actions: decision tracking.<br>- Task State: started / in process / done</td><td>- Task Structure: Workflow.<br>- Resources State: Availability<br>- People's Actions: decision tracking.<br>- Task State: started / in process / done</td></tr><tr><td>Define cake size</td><td>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: decision tracking.</td><td>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: decision tracking.</td><td>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: decision tracking.</td></tr><tr><td>Define Decoration elements</td><td>- People's State: Availability<br>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: Event Modify (add, move, quit)<br>- Task State: started / in process / done<br>- People's Action: Perspective.</td><td>- People's Actions: decision tracking.<br>- Task State: Done</td><td>- People's action: Event alert<br>- People's Action: Perspective.<br>- People's State: Availability<br>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: Event (modify).<br>- Task State: started / in process / done<br>- People's State: Emotions<br>- People's</td></tr><tr><td>Define price of the cake.</td><td>- Task Structure: Workflow.<br>- People's Actions: price tracking.<br>- Task State: Done</td><td>- People's Actions: decision tracking.<br>- Task State: Done</td><td>- Actions: decision tracking.<br>- People's State: Emotions<br>- Task State: Done</td></tr></tbody></table>
<table><caption>**Table 2.** Table of participation in the negotiation process of a cake.</caption><thead><tr><th>Activity / Roles</th><th>Custome<br>r</th><th>Salesperso<br>n</th><th>Pastry<br>chef</th><th>type</th></tr></thead><tbody><tr><td>Request for quote</td><td>x</td><td></td><td></td><td>Individual</td></tr><tr><td>Respond to request</td><td></td><td>x</td><td></td><td>Individual</td></tr><tr><td>Define delivery conditions</td><td>x</td><td>x</td><td></td><td>Cooperative</td></tr><tr><td>Define type of celebration</td><td>x</td><td>x</td><td></td><td>Cooperative</td></tr><tr><td>Define cake flavor</td><td>x</td><td>x</td><td>x</td><td>Collaborative</td></tr><tr><td>Define cake size</td><td>x</td><td>x</td><td>x</td><td>Collaborative</td></tr><tr><td>Define decoration elements</td><td>x</td><td>x</td><td>x</td><td>Collaborative</td></tr><tr><td>Define price of the cake.</td><td>x</td><td>x</td><td>x</td><td>Cooperative</td></tr></tbody></table>

<table><caption>**Table 3.** Table of Awareness mechanisms used in each activity within the negotiation process of a customized cake.</caption><thead><tr><th rowspan="2">Activity / Roles</th><th colspan="3">Awareness Mechanisms</th></tr><tr><th>Customer</th><th>Salesperson</th><th>Pastry chef</th></tr></thead><tbody><tr><td>Request for quote</td><td>- People's State: Availability</td><td></td><td></td></tr><tr><td>Respond to request</td><td></td><td>- People's State: Availability<br>- People's action: Event alert<br>- People's Activity: goals</td><td></td></tr><tr><td>Define delivery conditions</td><td>People's action: Event alert<br>- Norms: Time constraint</td><td>- People's action: Event alert<br>- Resources state: Availability</td><td></td></tr><tr><td>Define type of celebration</td><td>- People's State: Availability<br>- Task Structure: workflow<br>- Task State: started / in process / done</td><td>- People's State: Availability<br>- Task State: started / in process / done</td><td>- People's State: Availability<br>- Task State<br>- People's State: Emotions</td></tr><tr><td>Define cake flavor</td><td>- Task Structure: Workflow.<br>- Resources State: Availability<br>- People's Actions: decision tracking.<br>- Task State: started / in process / done</td><td>- Task Structure: Workflow.<br>- Resources State: Availability<br>- People's Actions: decision tracking.<br>- Task State: started / in process / done</td><td>- Task Structure: Workflow.<br>- Resources State: Availability<br>- People's Actions: decision tracking.<br>- Task State: started / in process / done</td></tr><tr><td>Define cake size</td><td>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: decision tracking.</td><td>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: decision tracking.</td><td>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: decision tracking.</td></tr><tr><td>Define Decoration elements</td><td>- People's State: Availability<br>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: Event Modify (add, move, quit)<br>- Task State: started / in process / done<br>- People's Action: Perspective.</td><td>- People's Actions: decision tracking.<br>- Task State: Done</td><td>- People's action: Event alert<br>- People's Action: Perspective.<br>- People's State: Availability<br>- Task Structure: Workflow.<br>- Resources state: Availability<br>- People's Actions: Event (modify).<br>- Task State: started / in process / done<br>- People's State: Emotions<br>- People's</td></tr><tr><td>Define price of the cake.</td><td>- Task Structure: Workflow.<br>- People's Actions: price tracking.<br>- Task State: Done</td><td>- People's Actions: decision tracking.<br>- Task State: Done</td><td>- Actions: decision tracking.<br>- People's State: Emotions<br>- Task State: Done</td></tr></tbody></table>
<table><caption>**Table 4.** Association of the information needs of the client, the assigned awareness mechanism, and its graphical representation in the interface.</caption><thead><tr><th colspan="3">Activity Define decoration elements</th></tr><tr><th>Customer needs</th><th>Awareness Mechanisms</th><th>Graphical representation on the interface</th></tr></thead><tbody><tr><td>The customer needs to know if the pastry chef is available.</td><td>- People's State: Availability</td><td></td></tr><tr><td>The customer needs to know where he is in the process and what the tasks are.</td><td>- Task Structure: Workflow.</td><td></td></tr><tr><td>The customer needs to know what resources are available to perform the task.</td><td>- Resources state: Availability</td><td></td></tr><tr><td>The customer needs to visualize the effect of his actions.</td><td>- People's Actions: Event Modify (add, move, quit)</td><td></td></tr><tr><td>The client should be aware of the cost of his choices before finalizing the process.</td><td>- Task State: started / in process / done</td><td></td></tr></tbody></table>

<figure><img src="image_16.png" /></figure>

<figure><img src="image_17.png" /></figure>

<figure><img src="image_18.png" /></figure>

Elige la cobertura

Sabores frutales

<figure><img src="image_19.png" /></figure>

Todos los colores

<figure><img src="image_20.png" /></figure>

Todos los colores

Colores pastel

Colores clásicos

<figure><img src="image_21.png" /></figure>

2. Elige la cobertura

<figure><img src="image_22.png" /></figure>

Todos los colores

<figure><img src="image_23.png" /></figure>

Ajouter

<figure><img src="image_24.png" /></figure>

Colorecer

<figure><img src="image_25.png" /></figure>

Piso 1

Piso 2

VALOR TOTAL
$ 37.000

Siguiente

<figure><img src="image_26.png" /><figcaption>**Fig. 2.** prototype image of graphical user interface with awareness mechanisms.</figcaption></figure>
<table><caption>**Table 4.** Association of the information needs of the client, the assigned awareness mechanism, and its graphical representation in the interface.</caption><thead><tr><th colspan="3">Activity Define decoration elements</th></tr><tr><th>Customer needs</th><th>Awarenes Mechanisms</th><th>Graphical representation on the interface</th></tr></thead><tbody><tr><td>The customer needs to know if the pastry chef is available.</td><td>- People's State: Availability</td><td></td></tr><tr><td>The customer needs to know where he is in the process and what the tasks are.</td><td>- Task Structure: Workflow.</td><td></td></tr><tr><td>The customer needs to know what resources are available to perform the task.</td><td>- Resources state: Availability</td><td></td></tr><tr><td>The customer needs to visualize the effect of his actions.</td><td>- People's Actions: Event Modify (add, move, quit)</td><td></td></tr><tr><td>The client should be aware of the cost of his choices before finalizing the process.</td><td>- Task State: started / in process / done</td><td></td></tr></tbody></table>

<figure><img src="image_28.png" /></figure>

<figure><img src="image_29.png" /></figure>

<figure><img src="image_30.png" /></figure>

Elige la cobertura

Sabores frutales

<figure><img src="image_31.png" /></figure>

Todos los colores

<figure><img src="image_32.png" /></figure>

Todos los colores

<figure><img src="image_33.png" /></figure>

Colores pastel

<figure><img src="image_34.png" /></figure>

Colores clásicos

<figure><img src="image_35.png" /></figure>

2. Elige la cobertura

<figure><img src="image_36.png" /></figure>

Todos los colores

<figure><img src="image_37.png" /></figure>

Amstrong

<figure><img src="image_38.png" /></figure>

Colores

<figure><img src="image_39.png" /></figure>

Piso 1

Piso 2

VALOR TOTAL
$ 37.000

Siguiente

<figure><img src="image_40.png" /><figcaption>**Fig. 2.** prototype image of graphical user interface with awareness mechanisms.</figcaption></figure>
<figure><img src="image_27.png" /><figcaption>**Fig. 3.** Avatar representing the pastry chef during the decoration process, this awareness information mechanism allows to guide the customer during the activities.</figcaption></figure>

# 6 Conclusions and future work.

The prototype was validated with the actors of the bakery, and feedback was received to improve the interface and the workflow. The importance of the articulation of the natural and technical language within the processes and their graphic representation was emphasized.

Using awareness mechanisms in the negotiation process of the bakery improves the understanding and comprehension of the requirements of the customized cake. It allows the customer to make informed decisions regarding the cost of his requirements, increases motivation since he can visualize the imagined product, strengthens relationships between people since the customer does not feel alone, on the contrary, he knows that he can count on the support of experts whenever necessary and generates an improvement in satisfaction levels due to the reduction of misunderstandings caused by communication problems.

A clear example is the awareness mechanism that allows the client to be informed about the cost of his decoration decisions. The placement of this element before the "next" button (end activity) allows the client to reflect and mediate between his expectations and his budget before moving on to the next activity.

In the future, it is expected to be more formal in the notation and to be able to apply more precise methodologies [28], when describing collaborative processes that need awareness mechanisms within a groupware system.

# 7 References

1. MinTIC and Innpulsa, "Centros de transformación digital empresarial," https://www.centrosdetransfor-maciondigital.gov.co/695/w3-channel.html, 2023.

2. MinTIC and Innpulsa, "MODELO DE MADUREZ PARA LA TRANSFORMACIÓN DIGITAL INNPULSA COLOMBIA-INNPULSA DIGITAL MINTIC-DIRECCION DE TRANSFORMACIÓN DIGITAL," 2019.

3. C. A. Collazos and R. Gil, "Using cross-cultural features in web design patterns," in *Proceedings - 2011 8th International Conference on Information Technology: New Generations, ITNG 2011*, IEEE Computer Society, 2011, pp. 514-519. doi: 10.1109/ITNG.2011.95.

4. T. Djatna, M. F. Koswara, and D. K. R. Kuncoro, "A system analysis and design for mobile digital business traceability at a food manufacturing," in *IOP Conference Series: Earth and Environmental Science*, Institute of Physics, 2022. doi: 10.1088/1755-1315/1063/1/012051.

5. P. Bourdieu, *Capital Cultural, Escuela y Espacio Social* ISBN. 968-23-2054-2, Primera. 1997.

6. D. Marc Kilgour Colin Eden, "Second Edition Handbook of Group Decision and Negotiation."

7. E. Johansson and D. Berthelsen, "The birthday cake: Social relations and professional practices around mealtimes with toddlers in child care," in *Lived Spaces of Infant-Toddler Education and Care: Exploring Diverse Perspectives on Theory, Research and Practice*, Springer Netherlands, 2014, pp. 75-88. doi: 10.1007/978-94-017-8838-0_6.

8. S. R. Charsley, "Wedding cakes and cultural history ISBN 0-203-40414-9 Master e-book ISBN," 1992.
<figure><img src="image_41.png" /><figcaption>**Fig. 3.** Avatar representing the pastry chef during the decoration process, this awareness information mechanism allows to guide the customer during the activities.</figcaption></figure>

# 6 Conclusions and future work.

The prototype was validated with the actors of the bakery, and feedback was received to improve the interface and the workflow. The importance of the articulation of the natural and technical language within the processes and their graphic representation was emphasized.

Using awareness mechanisms in the negotiation process of the bakery improves the understanding and comprehension of the requirements of the customized cake. It allows the customer to make informed decisions regarding the cost of his requirements, increases motivation since he can visualize the imagined product, strengthens relationships between people since the customer does not feel alone, on the contrary, he knows that he can count on the support of experts whenever necessary and generates an improvement in satisfaction levels due to the reduction of misunderstandings caused by communication problems.

A clear example is the awareness mechanism that allows the client to be informed about the cost of his decoration decisions. The placement of this element before the "next" button (end activity) allows the client to reflect and mediate between his expectations and his budget before moving on to the next activity.

In the future, it is expected to be more formal in the notation and to be able to apply more precise methodologies [28], when describing collaborative processes that need awareness mechanisms within a groupware system.

# 7 References

1. MinTIC and Innpulsa, "Centros de transformación digital empresarial," https://www.centrosdetransfor-maciondigital.gov.co/695/w3-channel.html, 2023.

2. MinTIC and Innpulsa, "MODELO DE MADUREZ PARA LA TRANSFORMACIÓN DIGITAL INNPULSA COLOMBIA-INNPULSA DIGITAL MINTIC-DIRECCION DE TRANSFORMACIÓN DIGITAL," 2019.

3. C. A. Collazos and R. Gil, "Using cross-cultural features in web design patterns," in *Proceedings - 2011 8th International Conference on Information Technology: New Generations, ITNG 2011*, IEEE Computer Society, 2011, pp. 514-519. doi: 10.1109/ITNG.2011.95.

4. T. Djatna, M. F. Koswara, and D. K. R. Kuncoro, "A system analysis and design for mobile digital business traceability at a food manufacturing," in *IOP Conference Series: Earth and Environmental Science*, Institute of Physics, 2022. doi: 10.1088/1755-1315/1063/1/012051.

5. P. Bourdieu, *Capital Cultural, Escuela y Espacio Social* ISBN. 968-23-2054-2, Primera. 1997.

6. D. Marc Kilgour Colin Eden, "Second Edition Handbook of Group Decision and Negotiation."

7. E. Johansson and D. Berthelsen, "The birthday cake: Social relations and professional practices around mealtimes with toddlers in child care," in *Lived Spaces of Infant-Toddler Education and Care: Exploring Diverse Perspectives on Theory, Research and Practice*, Springer Netherlands, 2014, pp. 75-88. doi: 10.1007/978-94-017-8838-0_6.

8. S. R. Charsley, "Wedding cakes and cultural history ISBN 0-203-40414-9 Master e-book ISBN," 1992.
9. H. Fuks, A. Raposo, M. A. Gerosa, M. Pimental, and C. J. P. Lucena, "The 3C collaboration model," in *Encyclopedia of E-Collaboration*, IGI Global, 2007, pp. 637-644. doi: 10.4018/978-1-59904-000-4.ch097.

10. J. Iván and T. Arbelaez, "Generación de la interfaz de usuario de negocio a partir de patrones de negocios basadas en los fundamentos metodológicos de TD-MBUID," 2016.

11. L. Correa, "Revista Faz / N° 2 - Julio 2008."

12. S. Valtolina, B. R. Barricelli, and Y. Dittrich, "Participatory knowledge-management design: A semiotic approach," *J Vis Lang Comput*, vol. 23, no. 2, pp. 103-115, Apr. 2012, doi: 10.1016/JJVLC.2011.11.007.

13. G. Stahl, "Group Cognition Computer Support for Building Collaborative Knowledge Acting with Tech- nology Series MIT Press 2006 Contents Group Cognition: Computer Support for Building Collaborative Knowledge."

14. F. Dong, S. Sterling, D. Schaefer, and H. Forbes, "BUILDING the HISTORY of the FUTURE: A TOOL for CULTURE-CENTRED DESIGN for the SPECULATIVE FUTURE," in *Proceedings of the Design Society: DESIGN Conference*, Cambridge University Press, 2020, pp. 1883-1890. doi: 10.1017/dsd.2020.63.

15. K. Petersen, S. Vakkalanka, and L. Kuzniarz, "Guidelines for conducting systematic mapping studies in software engineering: An update," *Inf Softw Technol*, vol. 64, pp. 1-18, Aug. 2015, doi: 10.1016/j.infsof.2015.03.007.

16. Y. Mei, J. Li, H. De Ridder, and P. Cesar, "Cakevr: A social virtual reality (vr) tool for co-designing cakes," *Conference on Human Factors in Computing Systems - Proceedings*, May 2021, doi: 10.1145/3411764.3445503.

17. T. Isaku and T. Iba, "Creative cocooking patterns: A pattern language for creative collaborative cooking," in *ACM International Conference Proceeding Series*, Association for Computing Machinery, Jul. 2015. doi: 10.1145/2855321.2855366.

18. M. Miyatake, A. Watanabe, and Y. Kawahara, "Interactive Cake Decoration with Whipped Cream," vol. 5, no. 20, 2020, doi: 10.1145/3379175.

19. C. A. Collazos, F. L. Gutiérrez, J. Gallardo, M. Ortega, H. M. Fardoun, and A. I. Molina, "Descriptive theory of awareness for groupware development," *J Ambient Intell Humaniz Comput*, vol. 10, no. 12, pp. 4789-4818, Dec. 2019, doi: 10.1007/s12652-018-1165-9.

20. J. Münch, O. Armbrust, M. Soto, and M. Kowalczyk, "Software Engineering for Embedded Systems Software Process Definition and Improvement."

21. L. García-Borgoñón, M. A. Barcelona, J. A. García-García, M. Alba, and M. J. Escalona, "Software pro- cess modeling languages: A systematic literature review," *Information and Software Technology*, vol. 56, no. 2. pp. 103-116, Feb. 2014. doi: 10.1016/j.infsof.2013.10.001.

22. C. A. Collazos, M. Paula González, A. Neyem, and C. Sturm, "LNCS 4560 - Guidelines to Develop Emotional Awareness Devices from a Cultural-Perspective: A Latin American Example," 2007. [Online]. Available: http://www.we-make-money-not-art.com/archives/007274.php

23. A. Moquillaza et al., "Developing an ATM Interface Using User-Centered Design Techniques," 2017, doi: 10.1007/978-3-319-58640-3_49.

24. T. Clemmensen, Q. Shi, J. Kumar, H. Li, X. Sun, and P. Yammiyavar, "LNCS 4559 - Cultural Usability Tests - How Usability Tests Are Not the Same All over the World," 2007.

25. F. Nake and S. Grabowski, "Human-computer interaction viewed as pseudo-communication," *Knowl Based Syst*, vol. 14, no. 8, pp. 441-447, Dec. 2001, doi: 10.1016/S0950-7051(01)00140-X.

26. A. Herrera, D. Rodríguez, and R. García-Martínez, "Taxonomía de Mecanismos de Awareness."

27. C. Collazos, A. Solano, and H. M. Fardoun, "Collaboration engineering: Supporting the collaborative processes design for the accessible and usable interactive systems design," in *ICSOF 2018 - Proceedings of the 13th International Conference on Software Technologies*, SciTePress, 2019, pp. 786-793. doi: 10.5220/0006941407860793.

28. J. Gallardo, C. Bravo, and A. I. Molina, "A framework for the descriptive specification of awareness support in multimodal user interfaces for collaborative activities," *Journal on Multimodal User Interfaces*, vol. 12, no. 2, pp. 145-159, Jun. 2018, doi: 10.1007/s12193-017-0255-x.
9. H. Fuks, A. Raposo, M. A. Gerosa, M. Pimental, and C. J. P. Lucena, "The 3C collaboration model," in *Encyclopedia of E-Collaboration*, IGI Global, 2007, pp. 637-644. doi: 10.4018/978-1-59904-000-4.ch097.

10. J. Iván and T. Arbelaez, "Generación de la interfaz de usuario de negocio a partir de patrones de negocios basadas en los fundamentos metodológicos de TD-MBUID," 2016.

11. L. Correa, "Revista Faz / N° 2 - Julio 2008."

12. S. Valtolina, B. R. Barricelli, and Y. Dittrich, "Participatory knowledge-management design: A semiotic approach," *J Vis Lang Comput*, vol. 23, no. 2, pp. 103-115, Apr. 2012, doi: 10.1016/JJVLC.2011.11.007.

13. G. Stahl, "Group Cognition Computer Support for Building Collaborative Knowledge Acting with Tech- nology Series MIT Press 2006 Contents Group Cognition: Computer Support for Building Collaborative Knowledge."

14. F. Dong, S. Sterling, D. Schaefer, and H. Forbes, "BUILDING the HISTORY of the FUTURE: A TOOL for CULTURE-CENTRED DESIGN for the SPECULATIVE FUTURE," in *Proceedings of the Design Society: DESIGN Conference*, Cambridge University Press, 2020, pp. 1883-1890. doi: 10.1017/dsd.2020.63.

15. K. Petersen, S. Vakkalanka, and L. Kuzniarz, "Guidelines for conducting systematic mapping studies in software engineering: An update," *Inf Softw Technol*, vol. 64, pp. 1-18, Aug. 2015, doi: 10.1016/j.infsof.2015.03.007.

16. Y. Mei, J. Li, H. De Ridder, and P. Cesar, "Cakevr: A social virtual reality (vr) tool for co-designing cakes," *Conference on Human Factors in Computing Systems - Proceedings*, May 2021, doi: 10.1145/3411764.3445503.

17. T. Isaku and T. Iba, "Creative cocooking patterns: A pattern language for creative collaborative cooking," in *ACM International Conference Proceeding Series*, Association for Computing Machinery, Jul. 2015. doi: 10.1145/2855321.2855366.

18. M. Miyatake, A. Watanabe, and Y. Kawahara, "Interactive Cake Decoration with Whipped Cream," vol. 5, no. 20, 2020, doi: 10.1145/3379175.

19. C. A. Collazos, F. L. Gutiérrez, J. Gallardo, M. Ortega, H. M. Fardoun, and A. I. Molina, "Descriptive theory of awareness for groupware development," *J Ambient Intell Humaniz Comput*, vol. 10, no. 12, pp. 4789-4818, Dec. 2019, doi: 10.1007/s12652-018-1165-9.

20. J. Münch, O. Armbrust, M. Soto, and M. Kowalczyk, "Software Engineering for Embedded Systems Software Process Definition and Improvement."

21. L. García-Borgoñón, M. A. Barcelona, J. A. García-García, M. Alba, and M. J. Escalona, "Software pro- cess modeling languages: A systematic literature review," *Information and Software Technology*, vol. 56, no. 2. pp. 103-116, Feb. 2014. doi: 10.1016/j.infsof.2013.10.001.

22. C. A. Collazos, M. Paula González, A. Neyem, and C. Sturm, "LNCS 4560 - Guidelines to Develop Emotional Awareness Devices from a Cultural-Perspective: A Latin American Example," 2007. [Online]. Available: http://www.we-make-money-not-art.com/archives/007274.php

23. A. Moquillaza et al., "Developing an ATM Interface Using User-Centered Design Techniques," 2017, doi: 10.1007/978-3-319-58640-3_49.

24. T. Clemmensen, Q. Shi, J. Kumar, H. Li, X. Sun, and P. Yammiyavar, "LNCS 4559 - Cultural Usability Tests - How Usability Tests Are Not the Same All over the World," 2007.

25. F. Nake and S. Grabowski, "Human-computer interaction viewed as pseudo-communication," *Knowl Based Syst*, vol. 14, no. 8, pp. 441-447, Dec. 2001, doi: 10.1016/S0950-7051(01)00140-X.

26. A. Herrera, D. Rodríguez, and R. García-Martínez, "Taxonomía de Mecanismos de Awareness."

27. C. Collazos, A. Solano, and H. M. Fardoun, "Collaboration engineering: Supporting the collaborative processes design for the accessible and usable interactive systems design," in *ICSOF 2018 - Proceedings of the 13th International Conference on Software Technologies*, SciTePress, 2019, pp. 786-793. doi: 10.5220/0006941407860793.

28. J. Gallardo, C. Bravo, and A. I. Molina, "A framework for the descriptive specification of awareness support in multimodal user interfaces for collaborative activities," *Journal on Multimodal User Interfaces*, vol. 12, no. 2, pp. 145-159, Jun. 2018, doi: 10.1007/s12193-017-0255-x.
# A Method to obtain a Knowledge Representation from a Natural Language Specification of the Domain using the Glossary LEL

Leandro Antonelli¹, Mario Lezoche², Juliana Delle Ville¹

¹Lifia, Fac. de Informática, UNLP, La Plata, Bs As, Argentina

²Université de Lorraine, Nancy, Lorraine, France

leandro.antonelli,juliana.delleville}@lifia.info.unlp.edu.armario.lezoche@univ-lorraine.fr

**Abstract**— Good requirements (correct, consistent, unambiguous, etc.) are crucial to software development success. Errors made in the requirements stage can cost up to 200 times if they are discovered once the software is delivered to the client. Natural language artifacts are the most used tool to write requirements, since they are understandable by the both parties that participate in the software development: the stakeholders and the development team. Nevertheless, natural language can introduce many defects (ambiguity, vagueness, generality, etc.). Formal reasoning is a good strategy to check whether requirements satisfy the attributes of good requirements or not, but formal reasoning cannot be applied to natural language specification with defects. Thus, this paper proposes an approach to write a good specification and obtain knowledge from it. The approach uses a particular lexicon, the glossary LEL, and it suggest guidelines to write good specification, and it also suggest rules to obtain knowledge (concepts and relations) from the glossary LEL. The paper also presents a prototype to assist to this approach, and a preliminary evaluation of the approach.

**Keywords**- *Requirements specification, knowledge representation, natural language, artificial intelligence*

## 1. Introduction

Good requirements are crucial to software development success. If requirements are not good, the software application developed from them will not satisfy the need, wishes and expectations of the stakeholders. Moreover, if requirements are not good, a lot of work will need to be done to repair the software application to satisfy their needs. It is estimated that errors made in requirements stage can cost up to 200 times if they are discovered when the software is delivered to the client [7].

The expression “good requirements” has a broad meaning. There are many characteristics that are desirable that a software specification has. Does not matter if the development process is agile with minimum of documentation or if it classic with an orthodox software requirements specification of hundreds of pages. It is desirable that the specification would be correct, consistent, unambiguous, etc. These are called quality attributes. Although it is impossibly to satisfy all of them, since there is a huge effort of rework to correct errors, it is necessary to invest the effort in trying to produce the best specification as possible.

Natural language is the most used tool to write requirements [21]. Requirements are specified usually requirements engineering or business analysts, and they should interact with the stakeholder who has the requirements and the knowledge to include in the software application. And the specification also needs to be understandable and precise enough so the software development team can develop the application from it. Natural language specifications are understandable for these both sides [26]. Nevertheless, natural language can introduce many defects: ambiguity, vagueness, generality, etc. [6].

Formal reasoning means infer knowledge from a specification. For example, considering an agriculture specification that states that “plants need water, and tomato is a plant”, it can be inferred that “tomatoes need water”. It is necessary to have requirements without defects originated by the natural language in order to make possible the forma reasoning [25]. Moreover, with forma reasoning it will be possible to automatize many tasks in order to obtain good requirements [15] [17]. For example, consistency is one of the quality attributes of the specification. And consistency means that there is no contradiction in any given pairs of requirements. Having the specification “plants need water, tomato is a plant, and tomato does not need water” it can inferred that “tomato needs water and tomato does not need water”. Since it is a contradiction, it can be concluded that the specification is not consistent.
# A Method to obtain a Knowledge Representation from a Natural Language Specification of the Domain using the Glossary LEL

Leandro Antonelli¹, Mario Lezoche², Juliana Delle Ville¹

¹Lifia, Fac. de Informática, UNLP, La Plata, Bs As, Argentina

²Université de Lorraine, Nancy, Lorraine, France

leandro.antonelli,juliana.delleville}@lifia.info.unlp.edu.armario.lezoche@univ-lorraine.fr

**Abstract**— Good requirements (correct, consistent, unambiguous, etc.) are crucial to software development success. Errors made in the requirements stage can cost up to 200 times if they are discovered once the software is delivered to the client. Natural language artifacts are the most used tool to write requirements, since they are understandable by the both parties that participate in the software development: the stakeholders and the development team. Nevertheless, natural language can introduce many defects (ambiguity, vagueness, generality, etc.). Formal reasoning is a good strategy to check whether requirements satisfy the attributes of good requirements or not, but formal reasoning cannot be applied to natural language specification with defects. Thus, this paper proposes an approach to write a good specification and obtain knowledge from it. The approach uses a particular lexicon, the glossary LEL, and it suggest guidelines to write good specification, and it also suggest rules to obtain knowledge (concepts and relations) from the glossary LEL. The paper also presents a prototype to assist to this approach, and a preliminary evaluation of the approach.

**Keywords**- *Requirements specification, knowledge representation, natural language, artificial intelligence*

## 1. Introduction

Good requirements are crucial to software development success. If requirements are not good, the software application developed from them will not satisfy the need, wishes and expectations of the stakeholders. Moreover, if requirements are not good, a lot of work will need to be done to repair the software application to satisfy their needs. It is estimated that errors made in requirements stage can cost up to 200 times if they are discovered when the software is delivered to the client [7].

The expression “good requirements” has a broad meaning. There are many characteristics that are desirable that a software specification has. Does not matter if the development process is agile with minimum of documentation or if it classic with an orthodox software requirements specification of hundreds of pages. It is desirable that the specification would be correct, consistent, unambiguous, etc. These are called quality attributes. Although it is impossibly to satisfy all of them, since there is a huge effort of rework to correct errors, it is necessary to invest the effort in trying to produce the best specification as possible.

Natural language is the most used tool to write requirements [21]. Requirements are specified usually requirements engineering or business analysts, and they should interact with the stakeholder who has the requirements and the knowledge to include in the software application. And the specification also needs to be understandable and precise enough so the software development team can develop the application from it. Natural language specifications are understandable for these both sides [26]. Nevertheless, natural language can introduce many defects: ambiguity, vagueness, generality, etc. [6].

Formal reasoning means infer knowledge from a specification. For example, considering an agriculture specification that states that “plants need water, and tomato is a plant”, it can be inferred that “tomatoes need water”. It is necessary to have requirements without defects originated by the natural language in order to make possible the forma reasoning [25]. Moreover, with forma reasoning it will be possible to automatize many tasks in order to obtain good requirements [15] [17]. For example, consistency is one of the quality attributes of the specification. And consistency means that there is no contradiction in any given pairs of requirements. Having the specification “plants need water, tomato is a plant, and tomato does not need water” it can inferred that “tomato needs water and tomato does not need water”. Since it is a contradiction, it can be concluded that the specification is not consistent.
The glossary LEL is a semi structured artifact with the goal of describing the language of the domain. The glossary LEL is easy to learn, it is easy to use, and it has good expressiveness. We have used the glossary LEL in many domains, some of them very complex, and we had good results. Cysneiros et al. [11] report the use of LEL in a complex domain as the health domain. The glossary LEL uses natural language to describe the language, but it also categorizes the vocabulary in 4 categories: subjects, objects, verbs and states. The description of each term is done through two attributes: notion and behavioral responses. Thus, the glossary LEL is more than a simple glossary, it represents the knowledge of a domain (captured through its language) in natural language.

The concept of the kernel sentence was introduced in 1957 by linguist Z.S. Harris [16] and featured in the early work of linguist Noam Chomsky [10]. Kernel sentences are also known as basic sentences. They are declarative constructions, in active voice, always affirmative with only one verb. We argue that the use of kernel sentences in the description of the glossary LEL, as well as some other guidelines to make the natural language near a controlled language, allow us to obtain a good specification.

Having a good specification, it is feasible to perform a formal reasoning to infer new knowledge. Nevertheless, before performing formal reasoning, it is necessary to synthesize the knowledge captured in the language through the glossary LEL. Thus, this paper proposes an approach to obtain the knowledge (concepts and relationships) from a glossary LEL. The inference of the new knowledge is outside the scope of this proposal. This paper also presents a prototype, that is, a tool to assist during the application of the proposed approach. Moreover, a preliminary evaluation of the approach is also described.

The rest of the paper is organized in the following way. Section 2 describes some background about glossary LEL and kernel sentences. Section 3 reviews some related work. Section 4 details our contribution namely, the proposed approach. Section 5 describes the tool to support the process. Section 6 presents the preliminary evaluation. Finally, Section 7 discusses some conclusions.

## 2. Background

This section describes basic concepts of the glossary LEL and the kernel sentences.

### 2.1. Glossary LEL

The Language Extended Lexicon (LEL) is a glossary that describes the language of an application domain, where not necessarily there is a definition of a software application. The glossary LEL is tied to a simple idea: “understand the language of a problem without worrying about the problem” [19]. The language is captured through symbols that can be terms or short expressions. They are defined through two attributes: notion and behavioral responses. Notion describes the denotation, that is, the intrinsic and substantial characteristics of the symbol, while behavioral responses describe symbol connotation, that is, the relationship between the term being described and other terms (Fig. 1). Each symbol of the LEL belongs to one of four categories: subject, object, verb or state. This categorization guides and assists the requirements engineer during the description of the attributes. Table 1 shows each category with its characteristics and guidelines to describe them.

**Category:** symbol

**Notion:** description

**Behavioral responses:**

Behavioral response 1

Behavioral response 2

<caption>**Fig. 1.** Template to describe a LEL symbol</caption>

<table><caption>**Table 1.** Template to describe LEL symbols according to its category</caption><thead><tr><td>Category</td><td>Notion</td><td>Behavioral Responses</td></tr></thead><tbody><tr><td>Subject</td><td>Who is he?</td><td>What does he do?</td></tr><tr><td>Object</td><td>What is it?</td><td>What actions does it receive?</td></tr><tr><td>Verb</td><td>What goal does it pursue?</td><td>How is the goal achieved?</td></tr><tr><td>State</td><td>What situation does it represent?</td><td>How this situation is checked?</td></tr></tbody></table>

Let's consider a bank domain where there are clients that open account in order to save money. The client can deposit money into his account, and he can also withdraw money if the account has a positive balance. In this simple example there are many terms that should be defined into the glossary LEL to capture the language. For example, “client” should be a symbol of subject category. Then, “account”
The glossary LEL is a semi structured artifact with the goal of describing the language of the domain. The glossary LEL is easy to learn, it is easy to use, and it has good expressiveness. We have used the glossary LEL in many domains, some of them very complex, and we had good results. Cysneiros et al. [11] report the use of LEL in a complex domain as the health domain. The glossary LEL uses natural language to describe the language, but it also categorizes the vocabulary in 4 categories: subjects, objects, verbs and states. The description of each term is done through two attributes: notion and behavioral responses. Thus, the glossary LEL is more than a simple glossary, it represents the knowledge of a domain (captured through its language) in natural language.

The concept of the kernel sentence was introduced in 1957 by linguist Z.S. Harris [16] and featured in the early work of linguist Noam Chomsky [10]. Kernel sentences are also known as basic sentences. They are declarative constructions, in active voice, always affirmative with only one verb. We argue that the use of kernel sentences in the description of the glossary LEL, as well as some other guidelines to make the natural language near a controlled language, allow us to obtain a good specification.

Having a good specification, it is feasible to perform a formal reasoning to infer new knowledge. Nevertheless, before performing formal reasoning, it is necessary to synthesize the knowledge captured in the language through the glossary LEL. Thus, this paper proposes an approach to obtain the knowledge (concepts and relationships) from a glossary LEL. The inference of the new knowledge is outside the scope of this proposal. This paper also presents a prototype, that is, a tool to assist during the application of the proposed approach. Moreover, a preliminary evaluation of the approach is also described.

The rest of the paper is organized in the following way. Section 2 describes some background about glossary LEL and kernel sentences. Section 3 reviews some related work. Section 4 details our contribution namely, the proposed approach. Section 5 describes the tool to support the process. Section 6 presents the preliminary evaluation. Finally, Section 7 discusses some conclusions.

## 2. Background

This section describes basic concepts of the glossary LEL and the kernel sentences.

### 2.1. Glossary LEL

The Language Extended Lexicon (LEL) is a glossary that describes the language of an application domain, where not necessarily there is a definition of a software application. The glossary LEL is tied to a simple idea: “understand the language of a problem without worrying about the problem” [19]. The language is captured through symbols that can be terms or short expressions. They are defined through two attributes: notion and behavioral responses. Notion describes the denotation, that is, the intrinsic and substantial characteristics of the symbol, while behavioral responses describe symbol connotation, that is, the relationship between the term being described and other terms (Fig. 1). Each symbol of the LEL belongs to one of four categories: subject, object, verb or state. This categorization guides and assists the requirements engineer during the description of the attributes. Table 1 shows each category with its characteristics and guidelines to describe them.

**Category:** symbol
**Notion:** description
**Behavioral responses:**
Behavioral response 1
Behavioral response 2

<caption>**Fig. 1.** Template to describe a LEL symbol</caption>

<table><caption>**Table 1.** Template to describe LEL symbols according to its category</caption><thead><tr><td>Category</td><td>Notion</td><td>Behavioral Responses</td></tr></thead><tbody><tr><td>Subject</td><td>Who is he?</td><td>What does he do?</td></tr><tr><td>Object</td><td>What is it?</td><td>What actions does it receive?</td></tr><tr><td>Verb</td><td>What goal does it pursue?</td><td>How is the goal achieved?</td></tr><tr><td>State</td><td>What situation does it represent?</td><td>How this situation is checked?</td></tr></tbody></table>

Let's consider a bank domain where there are clients that open account in order to save money. The client can deposit money into his account, and he can also withdraw money if the account has a positive balance. In this simple example there are many terms that should be defined into the glossary LEL to capture the language. For example, “client” should be a symbol of subject category. Then, “account”
should be a symbol of object category. “Deposit” and “withdraw” should be symbols of verb category. Finally, “positive balance” should be a symbol of state category. According to the template described in Table 1, the symbols “client”, “account”, “withdraw” and “positive balance” are described in Table 2.

The behavioral responses of symbol “client” describes just two responsibilities: to open and to withdraw money, but there are other for example to deposit that is not mentioned. Then, the behavioral responses of the account only describes the responsibility of the bank to calculate interest, but the responsibilities of the client: open, deposit and withdraw should also be mentioned if the glossary LEL is complete. Then, the behavioral responses, of the verb “withdraw” describe how the task if performed by the bank, who first reduces the balance, then check if the resulting balance is positive, and in that case provide the money to the client. Otherwise, the balance is increased to its original value and no money is provided to the client. Finally, the behavioral responses of the state “positive balance” describe in detail what “positive” means. In this cases, it means greater or equal to zero.

<table><caption>**Table 2.** Glossary LEL symbols for the banking example</caption><thead><tr><td>Category</td><td>Notion</td><td>Behavioral Responses</td></tr></thead><tbody><tr><td>Subject: Client</td><td>Person that saves money in the bank.</td><td>The client opens an account.<br>The client withdraws money from the account.</td></tr><tr><td>Object: Account</td><td>Instrument used by the client to save money.</td><td>The bank calculates interest for the account.</td></tr><tr><td>Verb: Withdraw</td><td>Act of extracting money from an account.</td><td>The bank reduces the balance of the account.<br>If the account has a positive balance the bank provides the money to the client.<br>If the account has not a positive balance the bank increases the balance of the account.</td></tr><tr><td>State: Positive balance</td><td>Situation where the account has money.</td><td>The balance is greater or equal to zero.</td></tr></tbody></table>

## 2.2. Kernel Sentences

A kernel sentence is a simple construction with only one verb. It is also active, positive and declarative. This basic sentence does not contain any mood. It is termed as “kernel” since it is the basis upon which other more complex sentences are formed.

For example, Fig. 2 describes two kernel sentences. The first one states that a subject (“client”) performs an action (“opens”) on a certain object (“account”). The second sentence has the same structure while it describes a different action (“deposits”) and the object is a little bit more complex because it states that the object “money” is deposited into the object “account”. Fig. 3 shows two sentences that are not kernel. The first sentence (“The client deposits money and calculates interest into the account”) has two verbs, that is why it is not a kernel sentences. Moreover, the sentence is partially correct, since it is true that the client deposits money into the account. But, it is not true that the client calculates the interests. It is the bank who performs this calculation. That is why simple (kernel sentences) are suggested to describe specification. A simple sentence is more probable to be completely true or false. The second sentence (“The account is opened”) is written in passive voice, while kernel sentences should be written in active voice. Since it is written in passive voice, the subject of the sentence (“the account”), is not the subject who performs the action. In fact, the real subject who performs the action is not mentioned. According to the example provided, the real subject should be “the client”, but it could also be the company that the client work for and the company is the one who decided to open an account to pay his salary. These are two simple examples about how can kernel sentences writing style help to improve specifications.
should be a symbol of object category. "Deposit" and "withdraw" should be symbols of verb category. Finally, "positive balance" should be a symbol of state category. According to the template described in Table 1, the symbols "client", "account", "withdraw" and "positive balance" are described in Table 2.

The behavioral responses of symbol "client" describes just two responsibilities: to open and to withdraw money, but there are other for example to deposit that is not mentioned. Then, the behavioral responses of the account only describes the responsibility of the bank to calculate interest, but the responsibilities of the client: open, deposit and withdraw should also be mentioned if the glossary LEL is complete. Then, the behavioral responses, of the verb "withdraw" describe how the task if performed by the bank, who first reduces the balance, then check if the resulting balance is positive, and in that case provide the money to the client. Otherwise, the balance is increased to its original value and no money is provided to the client. Finally, the behavioral responses of the state "positive balance" describe in detail what "positive" means. In this cases, it means greater or equal to zero.

<table><caption>**Table 2.** Glossary LEL symbols for the banking example</caption><thead><tr><td>Category</td><td>Notion</td><td>Behavioral Responses</td></tr></thead><tbody><tr><td>Subject: Client</td><td>Person that saves money in the bank.</td><td>The client opens an account.<br>The client withdraws money from the account.</td></tr><tr><td>Object: Account</td><td>Instrument used by the client to save money.</td><td>The bank calculates interest for the account.</td></tr><tr><td>Verb: Withdraw</td><td>Act of extracting money from an account.</td><td>The bank reduces the balance of the account.<br>If the account has a positive balance the bank provides the money to the client.<br>If the account has not a positive balance the bank increases the balance of the account.</td></tr><tr><td>State: Positive balance</td><td>Situation where the account has money.</td><td>The balance is greater or equal to zero.</td></tr></tbody></table>

## 2.2. Kernel Sentences

A kernel sentence is a simple construction with only one verb. It is also active, positive and declarative. This basic sentence does not contain any mood. It is termed as "kernel" since it is the basis upon which other more complex sentences are formed.

For example, Fig. 2 describes two kernel sentences. The first one states that a subject ("client") performs an action ("opens") on a certain object ("account"). The second sentence has the same structure while it describes a different action ("deposits") and the object is a little bit more complex because it states that the object "money" is deposited into the object "account". Fig. 3 shows two sentences that are not kernel. The first sentence ("The client deposits money and calculates interest into the account") has two verbs, that is why it is not a kernel sentences. Moreover, the sentence is partially correct, since it is true that the client deposits money into the account. But, it is not true that the client calculates the interests. It is the bank who performs this calculation. That is why simple (kernel sentences) are suggested to describe specification. A simple sentence is more probable to be completely true or false. The second sentence ("The account is opened") is written in passive voice, while kernel sentences should be written in active voice. Since it is written in passive voice, the subject of the sentence ("the account"), is not the subject who performs the action. In fact, the real subject who performs the action is not mentioned. According to the example provided, the real subject should be "the client", but it could also be the company that the client work for and the company is the one who decided to open an account to pay his salary. These are two simple examples about how can kernel sentences writing style help to improve specifications.
The client opens an account.
The client deposits money into the account.

<caption>Fig. 2 Kernel Sentences</caption>

The client deposits money and calculates interest into the account.
The account is opened.

<caption>Fig. 3 No Kernel Sentences</caption>

3. Related works

Vu et al. [34] propose a method to transform specification to source code. Their approach systematically extracts the formal semantics of ARM instructions from their natural language specifications. Although ARM is based on RISC architecture and the number of instructions is relatively small, there are various series including Cortex-A, Cortex-M, and Cortex-R. Their approach applies translation rules enriched by the sentences similarity analysis.

Some other proposal deal with more abstract representation of the knowledge, for example data base table, schemas or object oriented designs. Geetha et al. [14] identify the schema and relationship of a data base from the natural language requirements specification. Their work starts with identifying the table schema and their properties. Then the Primary Key attribute is identified based on adjectives. It is done with rules and also with a machine learning component trained with statistical data. The relationships are identified using the primary key to identify the Foreign Key.

Bargui et al. [5] propose and approach to specify requirements through a template that represents the concepts of a decision making process. They also provide a linguistic pattern for the acquisition of analytical queries. This pattern facilitates the automatic analysis of the queries without being too restrictive to the writing styles.

Kuchta et al. [18] propose a method and a tool to extract concepts based on a grammatical analysis of requirements written in English without the need to refer to specialized ontology. These concepts can be further expressed in the class model, which then can be the basis for the object-oriented analysis of the problem. The method uses natural language processing techniques to recognize parts of speech and to divide sentences into phrases and also the WordNet dictionary to search for known concepts and recognize relationships between them.

Rigou et al. [28] are concerned about a formal or a semi-formal model description of functional requirements in the context of a model-driven engineering approach, where a platform-independent model, is used to derive automatically or semi-automatically the source code of a system. They claim that generally, the approaches use a predefined set of rules which impose several restrictions on the way a specification is written. Thus, they propose a deep learning approach.

Then, there are proposal that deals with conceptual model earlier in the software development life cycle. For example, domain models, concepts, and entities, some approaches are based on syntactic rules and some other are enriched with semantic. Shen et al. [31] propose an approach to assist the phases of requirements elicitation and analysis using masked language models, which have been used to learn contextual information from natural language sentences and transfer this learning to natural language processing (NLP) tasks. They claim that the masked language models can be used to predict the most likely missing word in a sentence, and thus be used to explore domain concepts encoded in a word embedding. Their approach extracts domain knowledge from user-authored scenarios using typed dependency parsing techniques. They also explore the efficacy of a complementary approach of using a BERT-based masked language models to identify entities and associated qualities to build a domain model from a single-word seed term.

Szwed et al. [33] propose an approach to extract concepts from unstructured Polish texts with special focus the morphological forms. Since Polish is a highly inflected language, detected names need to be transformed following Polish grammar rules. They propose a method for specification of transformation patterns, which is based on a simple annotations language. Annotations prepared by a user are compiled into transformation rules. During the concept extraction process the input document is split into sentences and the rules are applied to sequences of words comprised in sentences. Recognized strings forming concept names are aggregated at various levels and assigned with scores.
The client opens an account.
The client deposits money into the account.

<caption>Fig. 2 Kernel Sentences</caption>

The client deposits money and calculates interest into the account.
The account is opened.

<caption>Fig. 3 No Kernel Sentences</caption>

## 3. Related works

Vu et al. [34] propose a method to transform specification to source code. Their approach systematically extracts the formal semantics of ARM instructions from their natural language specifications. Although ARM is based on RISC architecture and the number of instructions is relatively small, there are various series including Cortex-A, Cortex-M, and Cortex-R. Their approach applies translation rules enriched by the sentences similarity analysis.

Some other proposal deal with more abstract representation of the knowledge, for example data base table, schemas or object oriented designs. Geetha et al. [14] identify the schema and relationship of a data base from the natural language requirements specification. Their work starts with identifying the table schema and their properties. Then the Primary Key attribute is identified based on adjectives. It is done with rules and also with a machine learning component trained with statistical data. The relationships are identified using the primary key to identify the Foreign Key.

Bargui et al. [5] propose an approach to specify requirements through a template that represents the concepts of a decision making process. They also provide a linguistic pattern for the acquisition of analytical queries. This pattern facilitates the automatic analysis of the queries without being too restrictive to the writing styles.

Kuchta et al. [18] propose a method and a tool to extract concepts based on a grammatical analysis of requirements written in English without the need to refer to specialized ontology. These concepts can be further expressed in the class model, which then can be the basis for the object-oriented analysis of the problem. The method uses natural language processing techniques to recognize parts of speech and to divide sentences into phrases and also the WordNet dictionary to search for known concepts and recognize relationships between them.

Rigou et al. [28] are concerned about a formal or a semi-formal model description of functional requirements in the context of a model-driven engineering approach, where a platform-independent model, is used to derive automatically or semi-automatically the source code of a system. They claim that generally, the approaches use a predefined set of rules which impose several restrictions on the way a specification is written. Thus, they propose a deep learning approach.

Then, there are proposal that deals with conceptual model earlier in the software development life cycle. For example, domain models, concepts, and entities, some approaches are based on syntactic rules and some other are enriched with semantic. Shen et al. [31] propose an approach to assist the phases of requirements elicitation and analysis using masked language models, which have been used to learn contextual information from natural language sentences and transfer this learning to natural language processing (NLP) tasks. They claim that the masked language models can be used to predict the most likely missing word in a sentence, and thus be used to explore domain concepts encoded in a word embedding. Their approach extracts domain knowledge from user-authored scenarios using typed dependency parsing techniques. They also explore the efficacy of a complementary approach of using a BERT-based masked language models to identify entities and associated qualities to build a domain model from a single-word seed term.

Szwed et al. [33] propose an approach to extract concepts from unstructured Polish texts with special focus on the morphological forms. Since Polish is a highly inflected language, detected names need to be transformed following Polish grammar rules. They propose a method for specification of transformation patterns, which is based on simple annotations language. Annotations prepared by a user are compiled into transformation rules. During the concept extraction process the input document is split into sentences and the rules are applied to sequences of words comprised in sentences. Recognized strings forming concept names are aggregated at various levels and assigned with scores.
Lit et al. [20] presents an approach that employs LSTM-CRF model for requirement entity extraction. Their proposal consist of four phases: (i) model construction, where it is built a LSTM-CRF model and an isomorphic LSTM language model for transfer learning; (ii) LSTM language model training, where it is captured the general knowledge and adapt it to requirement context; (iii) LSTM-CRF training, where it is trained the LSTM-CRF model with the transferred layers; (iv) requirement entity extraction, where it is applied the trained LSTM-CRF model to a new-coming requirement, and automatically extracts its requirement entities.

Wang et al. [35] propose an approach that selects frequent verbs from software requirement specification documents in the e-commerce domain, and built the semantic frames for those verbs. Then the selected sentences are labeled manually and the result is used as training examples for machine learning. They also correct the parsing result of the Stanford Parser. During the labeling process, they adopt a sequential way in which the previous labeled results will be used to construct dynamic features for the identification of the subsequent semantic roles.

Sadoun et al. [29] presents an approach that model the domain knowledge through an ontology and to formally represent user requirements by its population. Their approach of ontology population focuses on instance property identification from texts. They use extraction rules automatically acquired from a training corpus and a bootstrapping terminology. These rules aim at identifying instance property mentions represented by triples of terms, using lexical, syntactic and semantic levels of analysis. They are regenerated from recurrent syntactic paths between terms denoting instances of concepts and properties.

Finally, some approaches are concerned in obtaining knowledge representation similar to our proposal.

Schlutter et al. [30] propose a knowledge extraction approach based on an explicit knowledge representation of the content of natural language requirements as a semantic relation graph. Their approach is fully automated and includes an NLP pipeline to transform unrestricted natural language requirements into a graph. They split the natural language into different parts and relate them to each other based on their semantic relation.

An et al. [1] explore a set of state-of-the-art pre-trained general-purpose and domain-specific language models to extract knowledge triples for metal-organic frameworks. They created a knowledge graph benchmark with 7 relations for 1248 published metal-organic frameworks synonyms.

# 4. The proposed approach

This section describes the proposed approach. First, it describes the generality of the approach, that consist of three steps: (i) glossary LEL description, (ii) glossary LEL revision, and (iii) knowledge extraction. Then, every of the step is described in a different subsection.

## 4.1. Our approach in a nutshell

The proposed approach has the objective of obtaining a synthetic representation of the knowledge captured in the language of the application domain captured through the glossary LEL.

The proposed approach needs the knowledge as input and produces a knowledge representation as output. The knowledge can be obtained from different sources. It can be obtained mainly directly from the stakeholders, though interviews or other type of technical (focus group, questionnaires, etc.). But the knowledge can be obtained from documentation.

Thus, the proposed approach is thought to be applied by a requirements engineer or a business analyst who describe the glossary LEL, review it and finally synthetize the knowledge. Moreover, the approach can be used not only by one persona, many people can participate. That is, many requirements engineering can participate describing the glossary LEL in a collaborative way. Moreover, stakeholder experts of the domain can participate writing symbols of the glossary LEL. That is why, the approach consists of three steps: (i) glossary LEL description, (ii) glossary LEL revision, and (iii) knowledge extraction. When more than one person participate of the construction of the LEL, the step (ii) is vital. Nevertheless, when only one person participate, and the volume of information is huge, the step (ii) is also vital. Moreover, the need of a tool to automatize the revision is crucial.
Lit et al. [20] presents an approach that employs LSTM-CRF model for requirement entity extraction. Their proposal consist of four phases: (i) model construction, where it is built a LSTM-CRF model and an isomorphic LSTM language model for transfer learning; (ii) LSTM language model training, where it is captured the general knowledge and adapt it to requirement context; (iii) LSTM-CRF training, where it is trained the LSTM-CRF model with the transferred layers; (iv) requirement entity extraction, where it is applied the trained LSTM-CRF model to a new-coming requirement, and automatically extracts its requirement entities.

Wang et al. [35] propose an approach that selects frequent verbs from software requirement specification documents in the e-commerce domain, and built the semantic frames for those verbs. Then the selected sentences are labeled manually and the result is used as training examples for machine learning. They also correct the parsing result of the Stanford Parser. During the labeling process, they adopt a sequential way in which the previous labeled results will be used to construct dynamic features for the identification of the subsequent semantic roles.

Sadoun et al. [29] presents an approach that model the domain knowledge through an ontology and to formally represent user requirements by its population. Their approach of ontology population focuses on instance property identification from texts. They use extraction rules automatically acquired from a training corpus and a bootstrapping terminology. These rules aim at identifying instance property mentions represented by triples of terms, using lexical, syntactic and semantic levels of analysis. They are regenerated from recurrent syntactic paths between terms denoting instances of concepts and properties.

Finally, some approaches are concerned in obtaining knowledge representation similar to our proposal.

Schlutter et al. [30] propose a knowledge extraction approach based on an explicit knowledge representation of the content of natural language requirements as a semantic relation graph. Their approach is fully automated and includes an NLP pipeline to transform unrestricted natural language requirements into a graph. They split the natural language into different parts and relate them to each other based on their semantic relation.

An et al. [1] explore a set of state-of-the-art pre-trained general-purpose and domain-specific language models to extract knowledge triples for metal-organic frameworks. They created a knowledge graph benchmark with 7 relations for 1248 published metal-organic frameworks synonyms.

# 4. The proposed approach

This section describes the proposed approach. First, it describes the generality of the approach, that consist of three steps: (i) glossary LEL description, (ii) glossary LEL revision, and (iii) knowledge extraction. Then, every of the step is described in a different subsection.

## 4.1. Our approach in a nutshell

The proposed approach has the objective of obtaining a synthetic representation of the knowledge captured in the language of the application domain captured through the glossary LEL.

The proposed approach needs the knowledge as input and produces a knowledge representation as output. The knowledge can be obtained from different sources. It can be obtained mainly directly from the stakeholders, though interviews or other type of technic (focus group, questionnaires, etc.). But the knowledge can be obtained from documentation.

Thus, the proposed approach is thought to be applied by a requirements engineer or a business analyst who describe the glossary LEL, review it and finally synthetize the knowledge. Moreover, the approach can be used not only by one persona, many people can participate. That is, many requirements engineering can participate describing the glossary LEL in a collaborative way. Moreover, stakeholder experts of the domain can participate writing symbols of the glossary LEL. That is why, the approach consists of three steps: (i) glossary LEL description, (ii) glossary LEL revision, and (iii) knowledge extraction. When more than one person participate of the construction of the LEL, the step (ii) is vital. Nevertheless, when only one person participate, and the volume of information is huge, the step (ii) is also vital. Moreover, the need of a tool to automatize the revision is crucial.
Summing up, the proposed approach can be applied in different situations: (i) to summarize documents produced by other people, (ii) to consolidate and summarize documents produced by only one analyst eliciting from multiple sources, and (iii) to consolidate and summarize documents produced collaboratively by a group of analysts or experts.

The three steps that compose the proposed approach are: (i) glossary LEL description, (ii) glossary LEL revision, and (iii) knowledge extraction. The first step proposes a set of guidelines to help people to describe the glossary LEL. The second step proposes a set of guidelines to review some aspects of the description. Some revision (not all of them) are linked with guidelines of the step (i). Finally, the step (iii) provides rules to obtain knowledge from the glossary LEL specified, which is described in terms of concepts and relations. Fig. 4 summarizes the approach.

<figure><img src="image_28.png" /><figcaption>Fig. 4. Our approach in a nutshell</figcaption></figure>

Let's consider the glossary LEL described in Table 2. We can assume that is was described in the step 1 of the proposed approach, and reviewed in the step 2. In fact, the example of the Table 2 satisfies all the guidelines suggested. If step 3 is applied to that LEL it will obtained that the concept “client” and the concept “account” are linked by the relation “withdraw”. Then, the whole relation (“client”, “withdraw”, “account”) is restricted by the condition “positive balance”.

## 4.2. Step 1, guidelines to write the glossary LEL

This section describes every one of the six guidelines proposed to describe the glossary LEL. There are some other proposals about how to describe the glossary LEL. Some of them suggest the basic template described in Table 1 and some other suggests specific structures [2] [3] [Antonelli 2023]. These guidelines reinforce the need to use kernel sentences and reference to symbol already defined, and moreover, this guidelines provides suggestion about how to write compound sentences using subordination (if then), negation (no) and coordination (and). Finally, these guidelines also consider the use of state symbols in subordination expressions. The rest of the section describes and provides example for every one of the guidelines.

**Guideline 1. Sentences to describe behavioral responses must suit kernel sentences philosophy.**

Behavioral responses of every category (subject, object, verb and state) must be written according to the philosophy of kernel sentence, that is, an explicit subject followed by only one verb in turn followed by an object that receives the action. Fig. 2 shows examples of sentences well written according to this guideline that are used to describe the behavioral responses of the symbol “client” in Table 2.

**Guideline 2. Terms used to describe behavioral responses must be defined in the LEL glossary.** This guideline suggests that the subject, the verb and the object mentioned in the previous guidelines, should also be symbols already defined in the glossary LEL. For example, the symbol “client” defined in Table 2, has the following description in the behavioral responses “The client opens an account. The client withdraws money from the account.” If it is considered that Table 2 has a complete description of a glossary LEL, the symbols “client”, “account” and “withdraws” are defined. But the symbol “opens” is not defined and it should be defined according to this guideline.
Summing up, the proposed approach can be applied in different situations: (i) to summarize documents produced by other people, (ii) to consolidate and summarize documents produced by only one analyst eliciting from multiple sources, and (iii) to consolidate and summarize documents produced collaboratively by a group of analysts or experts.

The three steps that compose the proposed approach are: (i) glossary LEL description, (ii) glossary LEL revision, and (iii) knowledge extraction. The first step proposes a set of guidelines to help people to describe the glossary LEL. The second step proposes a set of guidelines to review some aspects of the description. Some revision (not all of them) are linked with guidelines of the step (i). Finally, the step (iii) provides rules to obtain knowledge from the glossary LEL specified, which is described in terms of concepts and relations. Fig. 4 summarizes the approach.

<figure><img src="image_42.png" /><figcaption>Fig. 4. Our approach in a nutshell</figcaption></figure>

Let's consider the glossary LEL described in Table 2. We can assume that is was described in the step 1 of the proposed approach, and reviewed in the step 2. In fact, the example of the Table 2 satisfies all the guidelines suggested. If step 3 is applied to that LEL it will obtained that the concept “client” and the concept “account” are linked by the relation “withdraw”. Then, the whole relation (“client”, “withdraw”, “account”) is restricted by the condition “positive balance”.

## 4.2. Step 1, guidelines to write the glossary LEL

This section describes every one of the six guidelines proposed to describe the glossary LEL. There are some other proposals about how to describe the glossary LEL. Some of them suggest the basic template described in Table 1 and some other suggests specific structures [2] [3] [Antonelli 2023]. These guidelines reinforce the need to use kernel sentences and reference to symbol already defined, and moreover, this guidelines provides suggestion about how to write compound sentences using subordination (if then), negation (no) and coordination (and). Finally, these guidelines also consider the use of state symbols in subordination expressions. The rest of the section describes and provides example for every one of the guidelines.

**Guideline 1. Sentences to describe behavioral responses must suit kernel sentences philosophy.**

Behavioral responses of every category (subject, object, verb and state) must be written according to the philosophy of kernel sentence, that is, an explicit subject followed by only one verb in turn followed by an object that receives the action. Fig. 2 shows examples of sentences well written according to this guideline that are used to describe the behavioral responses of the symbol “client” in Table 2.

**Guideline 2. Terms used to describe behavioral responses must be defined in the LEL glossary.** This guideline suggests that the subject, the verb and the object mentioned in the previous guidelines, should also be symbols already defined in the glossary LEL. For example, the symbol “client” defined in Table 2, has the following description in the behavioral responses “The client opens an account. The client withdraws money from the account.” If it is considered that Table 2 has a complete description of a glossary LEL, the symbols “client”, “account” and “withdraws” are defined. But the symbol “opens” is not defined and it should be defined according to this guideline.
**Guideline 3. Use subordination (if then) in behavioral responses of verb symbols to describe conditions.** Let's consider the example of verb "Withdraw" in Table 2. One of the behavioral responses states "If the account has a positive balance then bank provides the money to the client.". That means that the bank only provides the money to the client, when the account has positive money after reducing the balance with the amount that the client want to withdraw. That is, it is checked whether the balance remains positive after the extraction. It is important to mention that the application of this guideline is not a contradiction to the guideline 1, since the use of a subordination requires kernel sentences, although there are two kernel sentences in the same sentence, there are still kernel sentences associated.

**Guideline 4. State symbols should be used in the condition of a subordinated sentence.** Since the state symbols describes situation, this situation should be used as a condition of the subordinated sentence. Moreover, the condition should be included in the kernel sentence. For example, let's consider the verb "Withdraw" in Table 2. One of the behavioral responses states "If the account has a positive balance then ..., "positive balance" is a state symbol describe in Table 2, and the expression "the account has a positive balance" suit the rules of kernel sentences.

**Guideline 5. Use negation (not) to invert a condition or an action.** For example, the verb "Withdraw" in Table 2 contains a behavioral response that states "If the account has not a positive balance, then ...". Nevertheless, the negation can be used to deny some behavioral response. That is, behavioral response of subject for example, describe all the activities that subject can perform. The symbol "client" defined in Table 2, has the following description in the behavioral responses "The client opens an account. The client withdraws money from the account." Generally, (and according to guideline 1 that recommends the use of kernel sentences that should be positive by definition), behavioral responses should be positive. Nevertheless, some times, it is very important to make explicitly definition that something cannot be done. In this case, the negation can be used. For example, considering a bank that only works with organization and not with private clients, the responsibility of opening account relies on the organization and not into the client. Thus, a behavioral response of a client could state "The client does not open an account".

**Guideline 6. Use coordination (and) to join two subjects, objects or kernel sentences.** Although multiple kernel sentences can be written, using the coordinator "and" more simple and natural sentences can be written. For example, instead of writing "The client deposits money in the account. The bank deposits money in the account", it could be written "The client and the bank deposits money in the account".

## 4.2.- Step 2, guidelines to review the glossary LEL

This section describes some guidelines to review the glossary LEL described with the guidelines of the previous sections. These guidelines are simply a way of checking whether the previous guidelines were used correctly. Although these guidelines can be used as a checklist after some description was done, the following section describes a prototype that can perform these checks automatically.

**Guideline 1. Check for explicit subject and only one verb written in active voice in a behavioral response.** This guideline has the objective to be sure that kernel sentences are used to describe behavioral responses. Thus, the use of only one verb, written in active voice should be used. Moreover, the sentence should have at least one explicit subject.

**Guideline 2. Check for the definition of every subject, verb and object in a behavioral response.** This guideline complements the guideline number 2 of the previous section. The objective is to check that every element (with semantic meaning) used in a sentence is described within the glossary LEL.

**Guideline 3. Check for the definition of every condition of a subordination as a state.** This guideline complements guideline number 4 of the previous section. The objective is similar to the objective of guideline 2 of this section.
**Guideline 3. Use subordination (if then) in behavioral responses of verb symbols to describe conditions.** Let's consider the example of verb "Withdraw" in Table 2. One of the behavioral responses states "If the account has a positive balance then bank provides the money to the client.". That means that the bank only provides the money to the client, when the account has positive money after reducing the balance with the amount that the client want to withdraw. That is, it is checked whether the balance remains positive after the extraction. It is important to mention that the application of this guideline is not a contradiction to the guideline 1, since the use of a subordination requires kernel sentences, although there are two kernel sentences in the same sentence, there are still kernel sentences associated.

**Guideline 4. State symbols should be used in the condition of a subordinated sentence.** Since the state symbols describes situation, this situation should be used as a condition of the subordinated sentence. Moreover, the condition should be included in the kernel sentence. For example, let's consider the verb "Withdraw" in Table 2. One of the behavioral responses states "If the account has a positive balance then ..., "positive balance" is a state symbol describe in Table 2, and the expression "the account has a positive balance" suit the rules of kernel sentences.

**Guideline 5. Use negation (not) to invert a condition or an action.** For example, the verb "Withdraw" in Table 2 contains a behavioral response that states "If the account has not a positive balance, then ...". Nevertheless, the negation can be used to deny some behavioral response. That is, behavioral response of subject for example, describe all the activities that subject can perform. The symbol "client" defined in Table 2, has the following description in the behavioral responses "The client opens an account. The client withdraws money from the account." Generally, (and according to guideline 1 that recommends the use of kernel sentences that should be positive by definition), behavioral responses should be positive. Nevertheless, some times, it is very important to make explicitly definition that something cannot be done. In this case, the negation can be used. For example, considering a bank that only works with organization and not with private clients, the responsibility of opening account relies on the organization and not into the client. Thus, a behavioral response of a client could state "The client does not open an account".

**Guideline 6. Use coordination (and) to join two subjects, objects or kernel sentences.** Although multiple kernel sentences can be written, using the coordinator "and" more simple and natural sentences can be written. For example, instead of writing "The client deposits money in the account. The bank deposits money in the account", it could be written "The client and the bank deposits money in the account".

## 4.2.- Step 2, guidelines to review the glossary LEL

This section describes some guidelines to review the glossary LEL described with the guidelines of the previous sections. These guidelines are simply a way of checking whether the previous guidelines were used correctly. Although these guidelines can be used as a checklist after some description was done, the following section describes a prototype that can perform these checks automatically.

**Guideline 1. Check for explicit subject and only one verb written in active voice in a behavioral response.** This guideline has the objective to be sure that kernel sentences are used to describe behavioral responses. Thus, the use of only one verb, written in active voice should be used. Moreover, the sentence should have at least one explicit subject.

**Guideline 2. Check for the definition of every subject, verb and object in a behavioral response.** This guideline complements the guideline number 2 of the previous section. The objective is to check that every element (with semantic meaning) used in a sentence is described within the glossary LEL.

**Guideline 3. Check for the definition of every condition of a subordination as a state.** This guideline complements guideline number 4 of the previous section. The objective is similar to the objective of guideline 2 of this section.
**Guideline 4. Replace modal verbs with a subordination.** The expression "The client withdraws money from the account" states that the client is allowed to do that and he will do it when he need. If a modal verb is used "The client might withdraw money from the account" it means that there is certain condition. Thus, the sentence should be rewritten as "If (some condition related to the client) then the client withdraw money from the account"

**Guideline 5. Rephrase expressions with "no" to be sure of expressing prohibition.** Guideline 5 of the previous section suggest the use of negation to invert a condition or an action. When it is used to invert an action, that is, to state that some subject does not do some action, it is important to be sure that the description states a prohibition to perform that action. For example, the expression "The client does not open an account" can be rephrased as "The client is not allowed to open an account" to be sure that a prohibition is described.

**Guideline 6. Check for unambiguous terms used in notion.** When technical specification are written, the goal to be precise and unambiguous is naturally pursued, that is why it is not added a complementary guideline in the previous section. Nevertheless, it is important to pay attention to this issue and to consider this guideline for the revision. Although this guideline can be applied manually, maybe the tool support using some tool of word-sense disambiguation is more useful.

### 4.3.- Step 3, knowledge extraction

This section describes some rules to extract knowledge from the glossary LEL described and reviewed with the guidelines of the previous sections.

**Rule 1. Concepts are obtained from symbols of subject and objects categories.** Considering the glossary LEL described in Table 2 two concepts are obtained: "client" and "account", the first one is a subject and the second one is an object, but both of them are concepts.

**Rule 2. Relations are obtained from symbols of verbs categories.** Considering the glossary LEL described in Table 2 one relation is obtained: "withdraw". According to the behavioral response of the symbol "client", this action ("withdraw") relates the concepts "client" and "account".

**Rule 3. Conditions are obtained from symbols of state categories.** Considering the glossary LEL described in Table 2 one condition is obtained: "positive balance".

**Rule 4. Relations obtained by rule 2 are restricted by conditions.** Considering the glossary LEL described in Table 2 the state: "positive balance" gives origin to a condition. This state is mentioned in the "withdraw" verb that gives origin to the relation between "client" and "account". Thus, the whole relation ("client", "withdraw", "account") is restricted by the condition "positive balance".

## 5. Tool support

A software prototype was implemented that can be used to support the application of the proposed approach. The prototype is a web application implemented following a service-oriented architecture. The core of the application and its services are implemented in Python [27], while the web component is implemented with Django [12], and the APis are implemented with Flask [13]. Python [27] is also used to communicate to the Spacy [32] and NTLK libraries [23] used to deal with natural language processing.

The application is responsive, that means, the interface of the application adapts itself to the device used: a computer (desktop or laptop) or mobile device (phone or tablet). Thus, the application provides a variety of platforms to be used and experts will have a wide range of possibilities to contribute with knowledge acquisition.
**Guideline 4. Replace modal verbs with a subordination.** The expression "The client withdraws money from the account" states that the client is allowed to do that and he will do it when he need. If a modal verb is used "The client might withdraw money from the account" it means that there is certain condition. Thus, the sentence should be rewritten as "If (some condition related to the client) then the client withdraw money from the account"

**Guideline 5. Rephrase expressions with "no" to be sure of expressing prohibition.** Guideline 5 of the previous section suggest the use of negation to invert a condition or an action. When it is used to invert an action, that is, to state that some subject does not do some action, it is important to be sure that the description states a prohibition to perform that action. For example, the expression "The client does not open an account" can be rephrased as "The client is not allowed to open an account" to be sure that a prohibition is described.

**Guideline 6. Check for unambiguous terms used in notion.** When technical specification are written, the goal to be precise and unambiguous is naturally pursued, that is why it is not added a complementary guideline in the previous section. Nevertheless, it is important to pay attention to this issue and to consider this guideline for the revision. Although this guideline can be applied manually, maybe the tool support using some tool of word-sense disambiguation is more useful.

### 4.3.- Step 3, knowledge extraction

This section describes some rules to extract knowledge from the glossary LEL described and reviewed with the guidelines of the previous sections.

**Rule 1. Concepts are obtained from symbols of subject and objects categories.** Considering the glossary LEL described in Table 2 two concepts are obtained: "client" and "account", the first one is a subject and the second one is an object, but both of them are concepts.

**Rule 2. Relations are obtained from symbols of verbs categories.** Considering the glossary LEL described in Table 2 one relation is obtained: "withdraw". According to the behavioral response of the symbol "client", this action ("withdraw") relates the concepts "client" and "account".

**Rule 3. Conditions are obtained from symbols of state categories.** Considering the glossary LEL described in Table 2 one condition is obtained: "positive balance".

**Rule 4. Relations obtained by rule 2 are restricted by conditions.** Considering the glossary LEL described in Table 2 the state: "positive balance" gives origin to a condition. This state is mentioned in the "withdraw" verb that gives origin to the relation between "client" and "account". Thus, the whole relation ("client", "withdraw", "account") is restricted by the condition "positive balance".

## 5. Tool support

A software prototype was implemented that can be used to support the application of the proposed approach. The prototype is a web application implemented following a service-oriented architecture. The core of the application and its services are implemented in Python [27], while the web component is implemented with Django [12], and the APis are implemented with Flask [13]. Python [27] is also used to communicate to the Spacy [32] and NTLK libraries [23] used to deal with natural language processing.

The application is responsive, that means, the interface of the application adapts itself to the device used: a computer (desktop or laptop) or mobile device (phone or tablet). Thus, the application provides a variety of platforms to be used and experts will have a wide range of possibilities to contribute with knowledge acquisition.
The prototype implements two roles of users: (i) administrators of the projects and (ii) experts. The administrator of the tool can create project and the experts contribute with knowledge to the projects. The prototype is in fact a framework, since it can manage different type of artifacts based on natural language (Fig. 5). And the prototype also is easily extended to perform different process to derive more information from the artifacts.

Class LelElement():
symbol (length = 255, label "Symbol") category
(length = 10, label "Category")Notion (length = 1000,
label "Notion")
BehavioralResponses (length = 1000, label "Behavioral responses")

<caption>**Fig. 5. Configuration of artifacts**</caption>

The prototype uses Spacy [32] and NLTK [23] libraries to perform natural language processing. The POS (part of speech) tagging is an appropriate tool to determine the revisions suggested by guideline 1 as well as the identification of modal verbs mentioned in guideline 4. Then, word disambiguation is another powerful tool mentioned in guideline 6. Then, guidelines 2 and 3 requires to check the presence of some words as symbols of the glossary LEL. In order to do that, the stemming and lemmatization tools are very useful, since they convert words to their root form in order to make the comparison. Fig. 6 shows how the tool check kernel sentences.

<figure><img src="image_29.png" /><figcaption>**Fig. 6. Kernel sentence checking**</figcaption></figure>

The framework Plant UML [24] is used to display the model (Figure Fig. 7).

<figure><img src="image_30.png" /><figcaption>**Fig. 7. Knowledge represented graphically**</figcaption></figure>
The prototype implements two roles of users: (i) administrators of the projects and (ii) experts. The administrator of the tool can create project and the experts contribute with knowledge to the projects. The prototype is in fact a framework, since it can manage different type of artifacts based on natural language (Fig. 5). And the prototype also is easily extended to perform different process to derive more information from the artifacts.

Class LelElement():
symbol (length = 255, label "Symbol") category
(length = 10, label "Category")Notion (length = 1000,
label "Notion")
BehavioralResponses (length = 1000, label "Behavioral responses")

<caption>Fig. 5. Configuration of artifacts</caption>

The prototype uses Spacy [32] and NLTK [23] libraries to perform natural language processing. The POS (part of speech) tagging is an appropriate tool to determine the revisions suggested by guideline 1 as well as the identification of modal verbs mentioned in guideline 4. Then, word disambiguation is another powerful tool mentioned in guideline 6. Then, guidelines 2 and 3 requires to check the presence of some words as symbols of the glossary LEL. In order to do that, the stemming and lemmatization tools are very useful, since they convert words to their root form in order to make the comparison. Fig. 6 shows how the tool check kernel sentences.

<figure><img src="image_43.png" /><figcaption>Fig. 6. Kernel sentence checking</figcaption></figure>

The framework Plant UML [24] is used to display the model (Figure Fig. 7).

<figure><img src="image_44.png" /><figcaption>Fig. 7. Knowledge represented graphically</figcaption></figure>
## 6. Evaluation

The proposed approach was evaluated, although the prototype was not used in the evaluation because the goal of the evaluation was to assess the perceived usability of the proposed approach instead of evaluating the tool.

The Systems Usability Scale (SUS) was used to perform the evaluation [8] [9] in terms of the usability of the proposed approach. Although SUS is mainly used to assess usability of software systems, it was probe to be effective to assess products and processes [Bangor 2008].

The System Usability Scale (SUS) consists of a 10-item questionnaire; every question must be answered in a five-options scale, ranging from "1" ("Strongly Disagree") to "5" ("Strongly Agree"). Although there are 10 questions, they are related by pairs, asking the same question but in a complementary point of view in order to obtain a result of high confidence. The questions are the following:

1.- I like to use this approach.

2.- I find this approach to be more complicated than it should be.3.-
I think the approach is simple and easy to use.

4.- I need technical support to use this approach.

5.- I find the approach functioning smoothly and is well integrated.6.-
I think there are a lot of irregularities in the approach.

7.- I think most people can learn this approach quickly.8.-
I find this approach to be time-consuming.

9.- I feel confident using this approach.

10.- I think there are a lot of things to learn before I can start using this approach.

The participants of the evaluation were 5 students (with an age average of 24.8 years old) that participate in research project. It is important to mention that all of the students have experience in industry since in Argentina, students generally begin to work in industry in second year of their undergraduate studies. Thus, participants are suitable to this evaluation since they have experience in reading specification and deciding about the understandability of it. So, their opinion about whether the knowledge summarization is good or not to is important to us. They received training on the proposed approach and they were requested to answer the questionnaire.

The calculation of the SUS score is performed in the following way. First, items 1, 3, 5, 7, and 9 are scored considering the value ranked minus 1. Then, items 2, 4, 6, 8 and 10, are scored considering 5 minus the value ranked. After that, every participant's scores are summed up and then multiplied by 2.5 to obtain a new value ranging from 0 to 100. Finally, the average is calculated. The approach can have one of the following results: "Non acceptable" 0-64, "Acceptable" 65-84, and "Excellent" 85-100 [22]. The score obtained was 88.5. Thus, the approach can be considered as "Excellent".

## 6. Conclusions

This paper has presented an approach to obtain knowledge specification from a natural language specification. Particularly, we proposed the use of the glossary LEL to capture the language of the domain, hence, its knowledge. The proposed approach consists in a set of guidelines to help to capture and organize the natural language specification, in order to obtain the knowledge. The knowledge obtained can be used in different way. It synthesizes the glossary LEL, so it can be used to provide a global view. But it also makes possible to infer new knowledge, and this is very important to provide complete and consistent specifications, moreover if we consider that they use natural language. This is our main further work. We plan to extend this proposal to infer new knowledge to be used to add to the glossary LEL so stakeholder can validate and use them. And also to identify inconsistencies and conflict, so they can be solved. Another further work is related to improve the glossary LEL with a categorization of subjects as countable and uncountable. This categorization will make possible to be precise in certain descriptions involving them. We plan to enrich the LEL with magnitudes (numbers with a unit) and categorical elements (a list of possible value). We think that both characteristics are important to write precise specification and obtaining inferred knowledge. Particularly, this will make possible to verify requirements and designing tests from it.
## 6. Evaluation

The proposed approach was evaluated, although the prototype was not used in the evaluation because the goal of the evaluation was to assess the perceived usability of the proposed approach instead of evaluating the tool.

The Systems Usability Scale (SUS) was used to perform the evaluation [8] [9] in terms of the usability of the proposed approach. Although SUS is mainly used to assess usability of software systems, it was probe to be effective to assess products and processes [Bangor 2008].

The System Usability Scale (SUS) consists of a 10-item questionnaire; every question must be answered in a five-options scale, ranging from "1" ("Strongly Disagree") to "5" ("Strongly Agree"). Although there are 10 questions, they are related by pairs, asking the same question but in a complementary point of view in order to obtain a result of high confidence. The questions are the following:

1.- I like to use this approach.

2.- I find this approach to be more complicated than it should be.3.-
I think the approach is simple and easy to use.

4.- I need technical support to use this approach.

5.- I find the approach functioning smoothly and is well integrated.6.-
I think there are a lot of irregularities in the approach.

7.- I think most people can learn this approach quickly.8.-
I find this approach to be time-consuming.

9.- I feel confident using this approach.

10.- I think there are a lot of things to learn before I can start using this approach.

The participants of the evaluation were 5 students (with an age average of 24.8 years old) that participate in research project. It is important to mention that all of the students have experience in industry since in Argentina, students generally begin to work in industry in second year of their undergraduate studies. Thus, participants are suitable to this evaluation since they have experience in reading specification and deciding about the understandability of it. So, their opinion about whether the knowledge summarization is good or not to is important to us. They received training on the proposed approach and they were requested to answer the questionnaire.

The calculation of the SUS score is performed in the following way. First, items 1, 3, 5, 7, and 9 are scored considering the value ranked minus 1. Then, items 2, 4, 6, 8 and 10, are scored considering 5 minus the value ranked. After that, every participant's scores are summed up and then multiplied by 2.5 to obtain a new value ranging from 0 to 100. Finally, the average is calculated. The approach can have one of the following results: "Non acceptable" 0-64, "Acceptable" 65-84, and "Excellent" 85-100 [22]. The score obtained was 88.5. Thus, the approach can be considered as "Excellent".

## 6. Conclusions

This paper has presented an approach to obtain knowledge specification from a natural language specification. Particularly, we proposed the use of the glossary LEL to capture the language of the domain, hence, its knowledge. The proposed approach consists in a set of guidelines to help to capture and organize the natural language specification, in order to obtain the knowledge. The knowledge obtained can be used in different way. It synthesizes the glossary LEL, so it can be used to provide a global view. But it also makes possible to infer new knowledge, and this is very important to provide complete and consistent specifications, moreover if we consider that they use natural language. This is our main further work. We plan to extend this proposal to infer new knowledge to be used to add to the glossary LEL so stakeholder can validate and use them. And also to identify inconsistencies and conflict, so they can be solved. Another further work is related to improve the glossary LEL with a categorization of subjects as countable and uncountable. This categorization will make possible to be precise in certain descriptions involving them. We plan to enrich the LEL with magnitudes (numbers with a unit) and categorical elements (a list of possible value). We think that both characteristics are important to write precise specification and obtaining inferred knowledge. Particularly, this will make possible to verify requirements and designing tests from it.
# Acknowledgment

This paper is partially supported by funding provided by the STIC AmSud program, Project 22STIC-01.

## References

1. An, Y. et al.: "Exploring Pre-Trained Language Models to Build Knowledge Graph for Metal- Organic Frameworks (MOFs)" 2022 IEEE International Conference on Big Data (Big Data), Osaka, Japan, pp. 3651-3658 (2022)

2. Antonelli, L., Leite, J.C.S.P., Oliveros, A., Rossi, G.: "Specification Cases: a lightweight approach based on Natural Language", Workshop in Requirements Engineering (WER), Brasilia, Brasil, Agosto 23 – 27 (2021)

3. Antonelli, L., Fernandez, A., Ruffolo, N., Sansone, E., Torres, D.: "A Collaborative Approach to specify Kernel Sentences using Natural Language", Workshop in Requirements Engineering (WER), Natal, Brasil, Agosto 23 – 26 (2022).

4. Antonelli, L., Delle Ville, J., Dioguardi, F., Fernandez, A., Tanevitch, L., Torres, D.: "An Iterative and Collaborative Approach to Specify Scenarios using Natural Language", Workshop in Requirements Engineering (WER), Natal, Brasil, Agosto 23 – 26 (2022).

5. Bargui, F., Ben-Abdallah, H., Feki, J.: "Multidimensional concept extraction and validation from OLAP requirements in NL," 2009 International Conference on Natural Language Processing and Knowledge Engineering, Dalian, China, pp. 1-8 (2009)

6. Berry, D., Kamsties, E. and M. Krieger. From Contract Drafting to Software Specification:

7. Linguistic Sources of Ambiguity. University of Waterloo. 2003

8. Boehm, B.W.: Software Engineering, Computer society Press, IEEE, 1997.

9. Brooke, J.: "SUS-A quick and dirty usability scale" Usability evaluation in industry, 189(194), pp. 4-7, 1996.

10. Brooke, J: "SUS: a retrospective", Journal of usability studies 8.2, pp.29-40, 2013.

11. Chomsky, N.: The Logical Structure of Linguistic Theory. Plenum Press, New York, 1975.

12. McLellan, S., Muddimer, A., Peres, S. C.: "The effect of experience on System Usability Scale ratings." Journal of usability studies 7.2, pp. 56-67, 2012.

13. NLTK, https://www.nltk.org/, accessed: 2023-03-05

14. PlantUML, available at: https://plantuml.com/, accessed on 27th February 2023

15. K. Pohl, The Three Dimensions of Requirements Engineering, in: Proc. 5th Int. Conf. of Advanced Information Systems Engineering 1993, Paris, Springer, Berlin, pp. 275-292, 1993

16. Potts, C.: "Using schematic scenarios to understand user needs," in Proceedings of the 1st conference on Designing interactive systems: processes, practices, methods, & techniques, 1995

17. Python, https://www.python.org/, accessed: 2023-03-05

18. Rigou, Y., Lamontagne, D., Khriss, I.: "A Sketch of a Deep Learning Approach for Discovering UML Class Diagrams from System's Textual Specification," 2020 1st International Conference on Innovative Research in Applied Science, Engineering and Technology (IRASET), Meknes, Morocco, pp. 1-6 (2020).

19. Sadoun, D., Dubois, C., Ghamri-Doudane, Y., Grau, B.: "From Natural Language Requirements to Formal Specification Using an Ontology," 2013 IEEE 25th International Conference on Tools with Artificial Intelligence, Herndon, VA, USA, pp. 755-760 (2013).

20. Schlutter, A., Vogelsang, A.: "Knowledge Extraction from Natural Language Requirements into a Semantic Relation Graph". In Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshops (ICSEW'20). Association for Computing Machinery, New York, NY, USA, pp 373-379 (2020)

21. Shen, Y., Breaux, T.: "Domain Model Extraction from User-authored Scenarios and Word Embeddings" 2022 IEEE 30th International Requirements Engineering Conference Workshops (REW), Melbourne, Australia, pp. 143-151 (2022)
# Acknowledgment

This paper is partially supported by funding provided by the STIC AmSud program, Project 22STIC-01.

## References

1. An, Y. et al.: "Exploring Pre-Trained Language Models to Build Knowledge Graph for Metal- Organic Frameworks (MOFs)" 2022 IEEE International Conference on Big Data (Big Data), Osaka, Japan, pp. 3651-3658 (2022)

2. Antonelli, L., Leite, J.C.S.P., Oliveros, A., Rossi, G.: "Specification Cases: a lightweight approach based on Natural Language", Workshop in Requirements Engineering (WER), Brasilia, Brasil, Agosto 23 – 27 (2021)

3. Antonelli, L., Fernandez, A., Ruffolo, N., Sansone, E., Torres, D.: "A Collaborative Approach to specify Kernel Sentences using Natural Language", Workshop in Requirements Engineering (WER), Natal, Brasil, Agosto 23 – 26 (2022).

4. Antonelli, L., Delle Ville, J., Dioguardi, F., Fernandez, A., Tanevitch, L., Torres, D.: "An Iterative and Collaborative Approach to Specify Scenarios using Natural Language", Workshop in Requirements Engineering (WER), Natal, Brasil, Agosto 23 – 26 (2022).

5. Bargui, F., Ben-Abdallah, H., Feki, J.: "Multidimensional concept extraction and validation from OLAP requirements in NL," 2009 International Conference on Natural Language Processing and Knowledge Engineering, Dalian, China, pp. 1-8 (2009)

6. Berry, D., Kamsties, E. and M. Krieger. From Contract Drafting to Software Specification:

7. Linguistic Sources of Ambiguity. University of Waterloo. 2003

8. Boehm, B.W.: Software Engineering, Computer society Press, IEEE, 1997.

9. Brooke, J.: "SUS-A quick and dirty usability scale" Usability evaluation in industry, 189(194), pp. 4-7, 1996.

10. Brooke, J: "SUS: a retrospective", Journal of usability studies 8.2, pp.29-40, 2013.

11. Chomsky, N.: The Logical Structure of Linguistic Theory. Plenum Press, New York, 1975.

12. McLellan, S., Muddimer, A., Peres, S. C.: "The effect of experience on System Usability Scale ratings." Journal of usability studies 7.2, pp. 56-67, 2012.

13. NLTK, https://www.nltk.org/, accessed: 2023-03-05

14. PlantUML, available at: https://plantuml.com/, accessed on 27th February 2023

15. K. Pohl, The Three Dimensions of Requirements Engineering, in: Proc. 5th Int. Conf. of Advanced Information Systems Engineering 1993, Paris, Springer, Berlin, pp. 275-292, 1993

16. Potts, C.: "Using schematic scenarios to understand user needs," in Proceedings of the 1st conference on Designing interactive systems: processes, practices, methods, & techniques, 1995

17. Python, https://www.python.org/, accessed: 2023-03-05

18. Rigou, Y., Lamontagne, D., Khriss, I.: "A Sketch of a Deep Learning Approach for Discovering UML Class Diagrams from System's Textual Specification," 2020 1st International Conference on Innovative Research in Applied Science, Engineering and Technology (IRASET), Meknes, Morocco, pp. 1-6 (2020).

19. Sadoun, D., Dubois, C., Ghamri-Doudane, Y., Grau, B.: "From Natural Language Requirements to Formal Specification Using an Ontology," 2013 IEEE 25th International Conference on Tools with Artificial Intelligence, Herndon, VA, USA, pp. 755-760 (2013).

20. Schlutter, A., Vogelsang, A.: "Knowledge Extraction from Natural Language Requirements into a Semantic Relation Graph". In Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshops (ICSEW'20). Association for Computing Machinery, New York, NY, USA, pp 373–379 (2020)

21. Shen, Y., Breaux, T.: "Domain Model Extraction from User-authored Scenarios and Word Embeddings" 2022 IEEE 30th International Requirements Engineering Conference Workshops (REW), Melbourne, Australia, pp. 143-151 (2022)
22. Spacy https://spacy.io/, accessed 2023-03-05

23. Szwed, P.: "Concepts extraction from unstructured Polish texts: A rule based approach," 2015 Federated Conference on Computer Science and Information Systems (FedCSIS), Lodz, Poland, pp. 355-364 (2015).

24. Vu, A.V., Ogawa, M.: "Formal Semantics Extraction from Natural Language Specifications for ARM". In: ter Beek, M., McIver, A., Oliveira, J. (eds) Formal Methods – The Next 30 Years. FM 2019. Lecture Notes in Computer Science (), vol 11800. Springer, Cham (2019)

25. Wang, Y.: "Semantic information extraction for software requirements using semantic role labeling," 2015 IEEE International Conference on Progress in Informatics and Computing (PIC), Nanjing, China, pp. 332-337 (2015)
22. Spacy https://spacy.io/, accessed 2023-03-05

23. Szwed, P.: "Concepts extraction from unstructured Polish texts: A rule based approach," 2015 Federated Conference on Computer Science and Information Systems (FedCSIS), Lodz, Poland, pp. 355-364 (2015).

24. Vu, A.V., Ogawa, M.: "Formal Semantics Extraction from Natural Language Specifications for ARM". In: ter Beek, M., McIver, A., Oliveira, J. (eds) Formal Methods – The Next 30 Years. FM 2019. Lecture Notes in Computer Science (), vol 11800. Springer, Cham (2019)

25. Wang, Y.: "Semantic information extraction for software requirements using semantic role labeling," 2015 IEEE International Conference on Progress in Informatics and Computing (PIC), Nanjing, China, pp. 332-337 (2015)
Quantum Computing meets Software Engineering:
a Road Map for Collaborative Research

Jose Garcia-Alonso¹, Julio Ariel Hurtado Alegria², Juan M. Murillo³, Juan Braña⁴,
and Alejandro Fernandez⁵

¹ Universidad de Extremadura, España

² Universidad del Cauca, Colombia

³ CénitS - COMPUTAEX, España

⁴ I-314, Argentina

⁵ Universidad Nacional de La Plata, Argentina

**Abstract.** Software quantum developers need to implement efficient so- lutions taking advantage of the quantum computing properties. However, quantum computing is still in its early stages, and software development that exploits the advantages of quantum computing remains a challenge, as a lot of methodologies and tools are rooted in the essential concepts of classical computation. In this paper, we introduce the Iberoamerican Seedbed for Quantum Software Engineering initiative, which aims to pro- mote research, innovation, and teaching at the intersection of software engineering and quantum computing. The initiative will facilitate joint research and innovation projects, staff and student exchange programs, and seminars and workshops. It will also establish a network of quantum simulators, create a learning program for quantum software engineering, and disseminate research findings to the scientific community and the public.

**Keywords:** *Quantum Computing* · *Software Engineering* · *Collaborative Research*

# 1 Introduction

The principles of quantum mechanics were established by Max Planck and Niels Bohr. Since then, advances in both quantum hardware and quantum information theory have made Quantum Computing an undeniable reality.

Quantum computers rely on the use of quantum bits or qubits, the basic unit of information in a quantum computer, instead of to the classical bits in traditional computers. These qubits use the quantum concepts of superposition and entanglement to open the gates to a new type of computing. The use of superposition allows qubits to be in multiple states at the same time, until they are measured. While entanglement allows qubits to be related to other qubits in a way that their state cannot be described independently of the state of the others.

The use of these properties allow quantum computers to solve bounded- error quantum polynomial time problems (BQP). A class of decision problems solvable by a quantum computer in polynomial time within a margin of error. It is suspected that BQP contains P and that there are some problems in the BPQ class which are outside the P class.

To be able to address BQP problems, quantum developers need to implement efficient algorithms that take advantage of the quantum properties. There are already some well-known algorithms of this type like Grover algorithm [4] that searches in an unordered database faster than any classical algorithm or Shor algorithm [7] that factorizes an integer faster than any known classical algorithm.
# Quantum Computing meets Software Engineering:
a Road Map for Collaborative Research

Jose Garcia-Alonso<fnref n="1" />, Julio Ariel Hurtado Alegria<fnref n="2" />, Juan M. Murillo<fnref n="3" />, Juan Braña<fnref n="4" />,
and Alejandro Fernandez<fnref n="5" />

**Abstract.** Software quantum developers need to implement efficient so- lutions taking advantage of the quantum computing properties. However, quantum computing is still in its early stages, and software development that exploits the advantages of quantum computing remains a challenge, as a lot of methodologies and tools are rooted in the essential concepts of classical computation. In this paper, we introduce the Iberoamerican Seedbed for Quantum Software Engineering initiative, which aims to pro- mote research, innovation, and teaching at the intersection of software engineering and quantum computing. The initiative will facilitate joint research and innovation projects, staff and student exchange programs, and seminars and workshops. It will also establish a network of quantum simulators, create a learning program for quantum software engineering, and disseminate research findings to the scientific community and the public.

**Keywords:** *Quantum Computing* · *Software Engineering* · *Collaborative Research*

# 1 Introduction

The principles of quantum mechanics were established by Max Planck and Niels Bohr. Since then, advances in both quantum hardware and quantum information theory have made Quantum Computing an undeniable reality.

Quantum computers rely on the use of quantum bits or qubits, the basic unit of information in a quantum computer, instead of to the classical bits in traditional computers. These qubits use the quantum concepts of superposition and entanglement to open the gates to a new type of computing. The use of superposition allows qubits to be in multiple states at the same time, until they are measured. While entanglement allows qubits to be related to other qubits in a way that their state cannot be described independently of the state of the others.

The use of these properties allow quantum computers to solve bounded- error quantum polynomial time problems (BQP). A class of decision problems solvable by a quantum computer in polynomial time within a margin of error. It is suspected that BQP contains P and that there are some problems in the BPQ class which are outside the P class.

To be able to address BQP problems, quantum developers need to implement efficient algorithms that take advantage of the quantum properties. There are already some well-known algorithms of this type like Grover algorithm [4] that searches in an unordered database faster than any classical algorithm or Shor algorithm [7] that factorizes an integer faster than any known classical algorithm.

<footnote n="1">¹ Universidad de Extremadura, España</footnote>

<footnote n="2">² Universidad del Cauca, Colombia</footnote>

<footnote n="3">³ CénitS - COMPUTAEX, España</footnote>

<footnote n="4">⁴ I-314, Argentina</footnote>

<footnote n="5">⁵ Universidad Nacional de La Plata, Argentina</footnote>
However, as classical software engineering has demonstrated, is not enough to develop efficient algorithms. Modern software solutions are complex systems that rely on multiple layers of infrastructure, tools and techniques that allow software engineers to create high quality solutions. Most of these elements are still in a very early stage in quantum computing [2].

The field of quantum software engineering is an emerging topic that focuses bringing the advantages of software engineering to the development of quantum software. Discussion forums like the International Workshop on Quantum Software Engineering at ICSE, the IEEE International Conference on Quantum Software at IEEE Services or the Quantum Software Engineering and Technology Workshop at IEEE Quantum Week are starting to appear.

Nevertheless, additional efforts are needed to advance quantum software engineering [6]. There is still a low critical mass of researchers and, therefore, there is a need for training researchers and students in the specifics of quantum software engineering. The amount of resources needed to develop and test quantum solutions is still important, therefore, there is a need to join efforts between groups and institutions interested in this field. Also, due to the intrinsic interdisciplinary nature of quantum development, with the necessary input from mathematicians and physicists, collaborative approaches are necessary.

Specifically, we propose a road map for the creation of a collaborative research initiative in the field of quantum software engineering. To do that we present a research road map. Then, we propose the creation of a Seedbed for Quantum Software Engineering and provide some initial planning and expected outcomes for this initiative.

# 2 A research road map

As mentioned above, quantum software engineering is still in an early stage of development. Therefore, additional research is needed in almost every aspect of this new discipline [5]. In this section we focus on those topics that we consider the most relevant given the current state of the area.

## 2.1 Software tools to support quantum computing

As a classical software engineering has evolved, so have done the tools that support it. Nowadays, software engineers are used to have at their disposal a wide range of advanced tools, frameworks, and SDKs that help them in their daily task.

To simplify the transitions from classical software engineering to quantum software engineering and to train new quantum software engineers similar tools are needed. Not only because they make life easier to software engineers, but because they help develop software with better quality attributes [3].

Current quantum computing systems rely on initial versions of these tools. Most vendors provide environments and SDKs to help developers. For example, IBM offers developers a set of real hardware quantum computers up to 5 qubits and several simulators up to 5000 qubits for free through its platform" IBM QUANTUM EXPERIENCE". This offering is very useful for developing proof of concept projects, writing academic papers and learning to program quantum computers. Other companies like Google, Microsoft, Amazon and startups around the world provide different SKDs and tools for these tasks.

These SDKs are based on some of the existing quantum programming languages like Qiskit (IBM) and Cirq (Google), both written in Python or "Q-Sharp" (Microsoft). Amazon offers an environment named "Amazon Braket" to get started in the quantum computing world, for academic or commercial projects, and this company also offers one hour of its suite for free to try this technology. Other language that is often used to program Amazon Braket computers is Julia, through its library "Braket.jl". These languages, although usually based on a high-abstraction level programming language like python provide a very low-abstraction level language for the programming of quantum hardware, based on the use of quantum gates and quantum annealing approaches.
However, as classical software engineering has demonstrated, is not enough to develop efficient algorithms. Modern software solutions are complex systems that rely on multiple layers of infrastructure, tools and techniques that allow software engineers to create high quality solutions. Most of these elements are still in a very early stage in quantum computing [2].

The field of quantum software engineering is an emerging topic that focuses bringing the advantages of software engineering to the development of quantum software. Discussion forums like the International Workshop on Quantum Software Engineering at ICSE, the IEEE International Conference on Quantum Software at IEEE Services or the Quantum Software Engineering and Technology Workshop at IEEE Quantum Week are starting to appear.

Nevertheless, additional efforts are needed to advance quantum software engineering [6]. There is still a low critical mass of researchers and, therefore, there is a need for training researchers and students in the specifics of quantum software engineering. The amount of resources needed to develop and test quantum solutions is still important, therefore, there is a need to join efforts between groups and institutions interested in this field. Also, due to the intrinsic interdisciplinary nature of quantum development, with the necessary input from mathematicians and physicists, collaborative approaches are necessary.

Specifically, we propose a road map for the creation of a collaborative research initiative in the field of quantum software engineering. To do that we present a research road map. Then, we propose the creation of a Seedbed for Quantum Software Engineering and provide some initial planning and expected outcomes for this initiative.

# 2 A research road map

As mentioned above, quantum software engineering is still in an early stage of development. Therefore, additional research is needed in almost every aspect of this new discipline [5]. In this section we focus on those topics that we consider the most relevant given the current state of the area.

## 2.1 Software tools to support quantum computing

As a classical software engineering has evolved, so have done the tools that support it. Nowadays, software engineers are used to have at their disposal a wide range of advanced tools, frameworks, and SDKs that help them in their daily task.

To simplify the transitions from classical software engineering to quantum software engineering and to train new quantum software engineers similar tools are needed. Not only because they make life easier to software engineers, but because they help develop software with better quality attributes [3].

Current quantum computing systems rely on initial versions of these tools. Most vendors provide environments and SDKs to help developers. For example, IBM offers developers a set of real hardware quantum computers up to 5 qubits and several simulators up to 5000 qubits for free through its platform" IBM QUANTUM EXPERIENCE". This offering is very useful for developing proof of concept projects, writing academic papers and learning to program quantum computers. Other companies like Google, Microsoft, Amazon and startups around the world provide different SKDs and tools for these tasks.

These SDKs are based on some of the existing quantum programming languages like Qiskit (IBM) and Cirq (Google), both written in Python or "Q-Sharp" (Microsoft). Amazon offers an environment named "Amazon Braket" to get started in the quantum computing world, for academic or commercial projects, and this company also offers one hour of its suite for free to try this technology. Other language that is often used to program Amazon Braket computers is Julia, through its library "Braket.jl". These languages, although usually based on a high-abstraction level programming language like python provide a very low-abstraction level language for the programming of quantum hardware, based on the use of quantum gates and quantum annealing approaches.
Another example, is the intersection between quantum computing and ma-chine learning. Several libraries have been developed for this purpose, one of themost well known framework is” quantum-tensorflow”, published by Google.

Other tools in this domain are the transpilers that allow developers to trans- late their quantum program so it can be run on a different quantum computer using a different set of gates or with a different architecture. Also, some frame- works are starting to appear that focus on the application of quantum computingto specific domains like machine learning or chemistry.

All these tools, although they provide important advantages for the develop- ment of quantum software, are still very limited in terms of software engineering.The low abstraction levels at which quantum hardware is operated and the fo- cus on addressing some of the hardware limitations, like noise or decoherence time, make the concerns about software quality attributes seem very far away. However, as quantum hardware evolve and more advanced quantum software is created, quality attributes of software will rise in relevances, as happended in classsical software engineering, and quantum software engineers will need tool support.

## 2.2 Hybrid quantum-classical systems

Additionally, although quantum computers can solve some problems quicker that classical computers, modern software almost never work in an isolated way.

Current systems usually are created as global, interconnected set of software components. It seems natural, that quantum software would follow a similar pattern in which hybrid system will be the standard way of development [8].

In fact, the initial steps of quantum computing are taking that hybrid shape. Several relevant quantum algorithms already need a classical part. Also, most quantum computers are still managed through classical systems. So efforts are needed to define hybrid architectures for quantum software engineering.

Moreover, most of the existing quantum computers are offered through the cloud. This kind of access is well known for classical software engineers and provide important advantages to software that justify its omnipresence in mod-ern software. Starting from this point it seems reasonable to address quantum software enginerring from a Service Oriented Compunting point of view.

All of these, make clear the relevance of working on hybrid quantum-classicalsystems for a quantum software engineering.

## 2.3 Collaboration and quantum computing

Finally, advances in quantum software engineering need a collaborative ap- proach. Not only between software engineers, which is always a requirementfor complex systems, but also with professional of other disciplines [1]

Nowadays, advances in quantum computing are mostly created by profes- sional with strong backgrounds in mathematics or physics. The low abstraction level at which quantum software is developed make these professionals irreplace-able. However, they lack the skills and the background needed to create softwarewith the appropriate quality attributes. On the other side, software engineers with the abilities to create quality software usually lack the background andskills needed to create quantum software in its current state. Therefore, collab- oration is needed to produce contributions in the quantum software engineeringdomain.

Additionally, other kind of collaborations are needed to develop useful soft- ware. Collaboration with domain experts are needed to understand the domain requirement and co-creation processes have been proven as one of the best ap- proach for that. Also, collaboration with super-computing centers where quan- tum computers or powerfull simulators are hosted are also required in order to obtains access to the resources needed for development.
Another example, is the intersection between quantum computing and ma-chine learning. Several libraries have been developed for this purpose, one of themost well known framework is” quantum-tensorflow”, published by Google.

Other tools in this domain are the transpilers that allow developers to trans- late their quantum program so it can be run on a different quantum computer using a different set of gates or with a different architecture. Also, some frame- works are starting to appear that focus on the application of quantum computingto specific domains like machine learning or chemistry.

All these tools, although they provide important advantages for the develop- ment of quantum software, are still very limited in terms of software engineering.The low abstraction levels at which quantum hardware is operated and the fo- cus on addressing some of the hardware limitations, like noise or decoherence time, make the concerns about software quality attributes seem very far away. However, as quantum hardware evolve and more advanced quantum software is created, quality attributes of software will rise in relevances, as happended in classsical software engineering, and quantum software engineers will need tool support.

## 2.2 Hybrid quantum-classical systems

Additionally, although quantum computers can solve some problems quicker that classical computers, modern software almost never work in an isolated way.

Current systems usually are created as global, interconnected set of software components. It seems natural, that quantum software would follow a similar pattern in which hybrid system will be the standard way of development [8].

In fact, the initial steps of quantum computing are taking that hybrid shape. Several relevant quantum algorithms already need a classical part. Also, most quantum computers are still managed through classical systems. So efforts are needed to define hybrid architectures for quantum software engineering.

Moreover, most of the existing quantum computers are offered through the cloud. This kind of access is well known for classical software engineers and provide important advantages to software that justify its omnipresence in mod-ern software. Starting from this point it seems reasonable to address quantum software enginerring from a Service Oriented Compunting point of view.

All of these, make clear the relevance of working on hybrid quantum-classicalsystems for a quantum software engineering.

## 2.3 Collaboration and quantum computing

Finally, advances in quantum software engineering need a collaborative ap- proach. Not only between software engineers, which is always a requirementfor complex systems, but also with professional of other disciplines [1]

Nowadays, advances in quantum computing are mostly created by profes- sional with strong backgrounds in mathematics or physics. The low abstraction level at which quantum software is developed make these professionals irreplace-able. However, they lack the skills and the background needed to create softwarewith the appropriate quality attributes. On the other side, software engineers with the abilities to create quality software usually lack the background andskills needed to create quantum software in its current state. Therefore, collab- oration is needed to produce contributions in the quantum software engineeringdomain.

Additionally, other kind of collaborations are needed to develop useful soft- ware. Collaboration with domain experts are needed to understand the domain requirement and co-creation processes have been proven as one of the best ap- proach for that. Also, collaboration with super-computing centers where quan- tum computers or powerfull simulators are hosted are also required in order to obtains access to the resources needed for development.
Again, all of these make clear the need of a collaborative approach for research on quantum software engineering.

## 3 An Iberoamerican Seedbed for Quantum Software Engineering

Quantum computing is still in its early stages, and the development of software that exploits the advantages of quantum computing is still a challenge. Existing software development methodologies and tools are based on the computer model proposed by Von Neumann and Turing's conception of a program, which may not be adequate to the quantum computing paradigm. The Iberoamerican Seedbed for Quantum Software Engineering initiative aims to foster research, innovation, and teaching in the intersection of software engineering and quantum computing and explore alternative methods and tools for quantum software engineering. The primary outcomes of this initiative will be:

- Foster the creation of joint research and innovation projects in quantum software engineering, focusing on developing new methodologies and tools that take into account the specific features of quantum computing.

- Promote staff and student exchange programs between Iberoamerican countries to facilitate the exchange of knowledge and expertise in quantum software engineering and alternative methods and tools.

- Conduct joint seminars and workshops to share knowledge and expertise in quantum software engineering and alternative methods and tools.

- Establish a network of quantum simulators in supercomputing centers or other computing infrastructures able of offering to other researchers and to the industry the possibility of exploring the use of quantum technologies.

- Create a learning program for quantum software engineering that includes practical training using simulators or real quantum hardware.

- Disseminate the results of the research and innovation projects and the exploration of alternative methods and tools to the scientific community and the general public.

With this goals in mind, a three stage plans is proposed: planning, implementation, and consolidation. During the planning stage (first year of project) the following activities will be carried out:

- Create a website and social media accounts for the Iberoamerican Seedbed for Quantum Software Engineering.

- Define the research lines and projects that will be developed in the next two years, focusing on developing new methodologies and tools that take into account the specific features of quantum computing.

- Identify and recruit researchers, professionals, and students with expertise in computer science, physics, and engineering to participate in the initiative.

- Define the guidelines for the exchange programs and joint seminars, focusing on the exchange of knowledge and expertise in quantum software engineering and alternative methods and tools.

- Organize a first joint seminar to share knowledge and expertise in quantum software engineering and alternative methods and tools.

- Secure funding for the implementation of staff and student exchange during the second year of the project, and to implement multi-year collaborative research projects.

## Acknowledgements

This work has been financially supported by the Ministry of Economic Affairs and Digital Transformation of the Spanish Government through the QUANTUM ENIA project call - Quantum Spain project, by the Spanish Ministry of Science and Innovation under project PID2021-124054OB-C31, by the Regional Ministry of Economy, Science and Digital Agenda, and the Department of Economy and Infrastructure of the Government of Extremadura under project GR21133, and by the European Union through the Recovery, Transformation and Resilience Plan - NextGenerationEU within the framework of the Digital Spain 2026 Agenda.
Again, all of these make clear the need of a collaborative approach for research on quantum software engineering.

### 3 An Iberoamerican Seedbed for Quantum Software Engineering

Quantum computing is still in its early stages, and the development of software that exploits the advantages of quantum computing is still a challenge. Existing software development methodologies and tools are based on the computer model proposed by Von Neumann and Turing's conception of a program, which may not be adequate to the quantum computing paradigm. The Iberoamerican Seedbed for Quantum Software Engineering initiative aims to foster research, innovation, and teaching in the intersection of software engineering and quantum computing and explore alternative methods and tools for quantum software engineering. The primary outcomes of this initiative will be:

- Foster the creation of joint research and innovation projects in quantum software engineering, focusing on developing new methodologies and tools that take into account the specific features of quantum computing.

- Promote staff and student exchange programs between Iberoamerican countries to facilitate the exchange of knowledge and expertise in quantum software engineering and alternative methods and tools.

- Conduct joint seminars and workshops to share knowledge and expertise in quantum software engineering and alternative methods and tools.

- Establish a network of quantum simulators in supercomputing centers or other computing infrastructures able of offering to other researchers and to the industry the possibility of exploring the use of quantum technologies.

- Create a learning program for quantum software engineering that includes practical training using simulators or real quantum hardware.

- Disseminate the results of the research and innovation projects and the exploration of alternative methods and tools to the scientific community and the general public.

With this goals in mind, a three stage plans is proposed: planning, implementation, and consolidation. During the planning stage (first year of project) the following activities will be carried out:

- Create a website and social media accounts for the Iberoamerican Seedbed for Quantum Software Engineering.

- Define the research lines and projects that will be developed in the next two years, focusing on developing new methodologies and tools that take into account the specific features of quantum computing.

- Identify and recruit researchers, professionals, and students with expertise in computer science, physics, and engineering to participate in the initiative.

- Define the guidelines for the exchange programs and joint seminars, focusing on the exchange of knowledge and expertise in quantum software engineering and alternative methods and tools.

- Organize a first joint seminar to share knowledge and expertise in quantum software engineering and alternative methods and tools.

- Secure funding for the implementation of staff and student exchange during the second year of the project, and to implement multi-year collaborative research projects.

### Acknowledgements

This work has been financially supported by the Ministry of Economic Affairs and Digital Transformation of the Spanish Government through the QUANTUM ENIA project call - Quantum Spain project, by the Spanish Ministry of Science and Innovation under project PID2021-124054OB-C31, by the Regional Ministry of Economy, Science and Digital Agenda, and the Department of Economy and Infrastructure of the Government of Extremadura under project GR21133, and by the European Union through the Recovery, Transformation and Resilience Plan - NextGenerationEU within the framework of the Digital Spain 2026 Agenda.
References

1. Barzen, J., Leymann, F., Falkenthal, M., Vietz, D., Weder, B., Wild, K.: Relevance of near-term quantum computing in the cloud: A humanities perspective. In: Ferguson, D., Pahl, C., Helfert, M. (eds.) Cloud Computing and Services Science. pp. 25–58. Communications in Computer and Information Science, Springer International Publishing (2021). https://doi.org/10.1007/978-3-030-72369-9_2

2. Enrique Moguel, Javier Berrocal, Jose García-Alonso, Juan Manuel Murillo: A roadmap for quantum software engineering: applying the lessons learned from the classics. In: Short Papers Proceedings of the 1st International Workshop on Software Engineering & Technology (Q-SET’20) co-located with IEEE International Conference on Quantum Computing and Engineering (IEEE Quantum Week 2020). vol. 2705. CEUR (2020)

3. Garcia-Alonso, J., Rojo, J., Valencia, D., Moguel, E., Berrocal, J., Murillo, J.M.: Quantum software as a service through a quantum api gateway. IEEE Internet Computing **26*(1), 34–41 (2021)

4. Grover, L.K.: A fast quantum mechanical algorithm for database search (1996). https://doi.org/10.48550/ARXIV.QUANT-PH/9605043, https://arxiv.org/abs/quant-ph/9605043

5. Moguel, E., Rojo, J., Valencia, D., Berrocal, J., Garcia-Alonso, J., Murillo, J.M.: Quantum service-oriented computing: current landscape and challenges. Software Quality Journal **30**(4), 983–1002 (2022)

6. Rojo, J., Valencia, D., Berrocal, J., Moguel, E., Garcia-Alonso, J., Rodriguez,J.M.M.: Trials and tribulations of developing hybrid quantum-classical microser- vices systems. arXiv preprint arXiv:2105.04421 (2021)

7. Shor, P.W.: Algorithms for quantum computation: discrete logarithms and factoring. In: Proceedings 35th annual symposium on foundations of computer science. pp. 124–134. Ieee (1994)

8. Valencia, D., Garcia-Alonso, J., Rojo, J., Moguel, E., Berrocal, J., Murillo, J.M.: Hybrid classical-quantum software services systems: Exploration of the rough edges. In: Quality of Information and Communications Technology: 14th International Con- ference, QUATIC 2021, Algarve, Portugal, September 8–11, 2021, Proceedings 14. pp. 225–238. Springer (2021)
References

1. Barzen, J., Leymann, F., Falkenthal, M., Vietz, D., Weder, B., Wild, K.: Relevance of near-term quantum computing in the cloud: A humanities perspective. In: Ferguson, D., Pahl, C., Helfert, M. (eds.) Cloud Computing and Services Science. pp. 25–58. Communications in Computer and Information Science, Springer International Publishing (2021). https://doi.org/10.1007/978-3-030-72369-9_2

2. Enrique Moguel, Javier Berrocal, Jose García-Alonso, Juan Manuel Murillo: A roadmap for quantum software engineering: applying the lessons learned from the classics. In: Short Papers Proceedings of the 1st International Workshop on Software Engineering & Technology (Q-SET’20) co-located with IEEE International Conference on Quantum Computing and Engineering (IEEE Quantum Week 2020). vol. 2705. CEUR (2020)

3. Garcia-Alonso, J., Rojo, J., Valencia, D., Moguel, E., Berrocal, J., Murillo, J.M.: Quantum software as a service through a quantum api gateway. IEEE Internet Computing **26*(1), 34–41 (2021)

4. Grover, L.K.: A fast quantum mechanical algorithm for database search (1996). https://doi.org/10.48550/ARXIV.QUANT-PH/9605043, https://arxiv.org/abs/quant-ph/9605043

5. Moguel, E., Rojo, J., Valencia, D., Berrocal, J., Garcia-Alonso, J., Murillo, J.M.: Quantum service-oriented computing: current landscape and challenges. Software Quality Journal **30**(4), 983–1002 (2022)

6. Rojo, J., Valencia, D., Berrocal, J., Moguel, E., Garcia-Alonso, J., Rodriguez,J.M.M.: Trials and tribulations of developing hybrid quantum-classical microser- vices systems. arXiv preprint arXiv:2105.04421 (2021)

7. Shor, P.W.: Algorithms for quantum computation: discrete logarithms and factoring. In: Proceedings 35th annual symposium on foundations of computer science. pp. 124–134. Ieee (1994)

8. Valencia, D., Garcia-Alonso, J., Rojo, J., Moguel, E., Berrocal, J., Murillo, J.M.: Hybrid classical-quantum software services systems: Exploration of the rough edges. In: Quality of Information and Communications Technology: 14th International Con- ference, QUATIC 2021, Algarve, Portugal, September 8–11, 2021, Proceedings 14. pp. 225–238. Springer (2021)
Biomechanical Analysis of Basketball Free Throw Shooting
Technique in Athletes of The Pedagogical and Technological
University of Colombia

Jorge Armando Abril¹, Jose Charris
and Marco Javier Suarez Baron

¹ Universidad Pedagogica y Tecnologica de Colombia-UPTC, Sogamoso, Colombia² Faculty of Systems and Computing marco.suarez@uptc.edu.co

**Abstract.** Biomechanics is one of the most complete fields of the study of the metric composition of the human body and its relationship with physical and me-chanical variables characteristic of motion kinematics analysis, which is a great advantage when conducting studies on the performance of athletes and the anal-ysis of their technical and tactical skills, since it gives us a more concrete per- spective on them. For this research process, it has been decided to carry out a series of tests to launch free basketball shots in two athletes from the Pedagogical and Technological University of Colombia.

**Keywords:** Kinetics, Kinematics, Biomechanics, Basketball, Technical ability, Tactical ability.

# 1 Introduction

This section will specify everything related to the development of the field work, such as the classification and selection of the biomechanical variables to be analyzed, in addition to this, the population sample that will be studied for the analysis of the freethrow mechanics will be delimited and the techniques and procedures that will be used for the development of the biomechanical study will be mentioned.

In order to successfully perform the biomechanical analysis of the technical skill of basketball free throw shooting in athletes of the Pedagogical and Technological Uni- versity of Colombia, within the fieldwork, data collection, analysis and procedures, it is proposed:

* To characterize in a specific and adequate way the biomechanical variables that affect the development of the technical-tactical skill in basketball free-throw shooting.

* Establish through a biomechanical analysis methodology, a classification of rou-tines suitable for improving basketball free-throw shooting technique.

* Design a visualization system for anthropometric data and results using ML frameworks

The analysis of the basketball free throw shooting technique is essential to under- stand the success of some athletes, because the effectiveness of this technique has a high impact on this sport. However, the studies that have been conducted on the anthro-pometric and biomechanical relationship to reach an optimal characterization of the variables involved in the technical ability of an athlete are usually focused on other disciplines or are very ambiguous, so that also the use of technological tools and data analytics in such studies is very small, despite being tools that give us great reliability to make forecasts and analysis accurately and effectively.

Throwing is a movement that determines the action of sending an object to another place, this action has its own characteristics of the intention with which it is performed, from this consideration there have been several studies on the biomechanical factors of throwing depending on the specialty to be analyzed, such as the sports and military area, among others. The investigations carried out allow to evidence the incidence of variables such as angles, planes, positions and articulations that adjust to the character-istics of the human body and how they interact with the mechanics required to fulfill the objective of the action [1]
# Biomechanical Analysis of Basketball Free Throw Shooting Technique in Athletes of The Pedagogical and Technological University of Colombia

Jorge Armando Abril¹, Jose Charris
and Marco Javier Suarez Baron

¹ Universidad Pedagogica y Tecnologica de Colombia-UPTC, Sogamoso, Colombia² Faculty of Systems and Computing marco.suarez@uptc.edu.co

**Abstract.** Biomechanics is one of the most complete fields of the study of the metric composition of the human body and its relationship with physical and me-chanical variables characteristic of motion kinematics analysis, which is a great advantage when conducting studies on the performance of athletes and the anal-ysis of their technical and tactical skills, since it gives us a more concrete per- spective on them. For this research process, it has been decided to carry out a series of tests to launch free basketball shots in two athletes from the Pedagogical and Technological University of Colombia.

**Keywords:** Kinetics, Kinematics, Biomechanics, Basketball, Technical ability, Tactical ability.

## 1 Introduction

This section will specify everything related to the development of the field work, such as the classification and selection of the biomechanical variables to be analyzed, in addition to this, the population sample that will be studied for the analysis of the freethrow mechanics will be delimited and the techniques and procedures that will be used for the development of the biomechanical study will be mentioned.

In order to successfully perform the biomechanical analysis of the technical skill of basketball free throw shooting in athletes of the Pedagogical and Technological Uni- versity of Colombia, within the fieldwork, data collection, analysis and procedures, it is proposed:

* To characterize in a specific and adequate way the biomechanical variables that affect the development of the technical-tactical skill in basketball free-throw shooting.

* Establish through a biomechanical analysis methodology, a classification of rou-tines suitable for improving basketball free-throw shooting technique.

* Design a visualization system for anthropometric data and results using ML frameworks

The analysis of the basketball free throw shooting technique is essential to under- stand the success of some athletes, because the effectiveness of this technique has a high impact on this sport. However, the studies that have been conducted on the anthro-pometric and biomechanical relationship to reach an optimal characterization of the variables involved in the technical ability of an athlete are usually focused on other disciplines or are very ambiguous, so that also the use of technological tools and data analytics in such studies is very small, despite being tools that give us great reliability to make forecasts and analysis accurately and effectively.

Throwing is a movement that determines the action of sending an object to another place, this action has its own characteristics of the intention with which it is performed, from this consideration there have been several studies on the biomechanical factors of throwing depending on the specialty to be analyzed, such as the sports and military area, among others. The investigations carried out allow to evidence the incidence of variables such as angles, planes, positions and articulations that adjust to the character-istics of the human body and how they interact with the mechanics required to fulfill the objective of the action [1]
In order to make a biomechanical description of the throwing action, it is necessary to identify the phases that make up the throwing action, and how the athlete's body parts behave within each of these phases, that is, to identify the behavior patterns of the upper limbs and their joints, their measurements, and their variation as the movement is executed [2]. It is essential to bear in mind that the execution of free throws does not have rigid and predetermined standard, however, there are techniques associated with the effectiveness of the free throw [3]. In the anthropometric study of the upper limbs, the values corresponding to the dimensions of the arms, forearms, hands, and their length and extension, among other variables, are treated [5].

The specific study of upper limbs has been widely used for the creation of prostheses as it allows through the results obtained to make products appropriate for the needs of people who have suffered malformations, injuries, or loss of any of their limbs, as it allows to establish ideal characteristics in terms of optimal materials for use, and different components involved in the design and production of prostheses according to ISO 13405-1 standard, such as interface components (interaction with the patient), functional, alignment, structural and cosmetic (appearance as close as possible to a natural human limb) [6]. In this way, the relationship between these dimensions and the execution of movements can be established by means of a dynamic anthropometric analysis of the upper limbs.

# 2 Materials and methods

## 2.1 Method

### Phase 1. Information collection.

Analyses were carried out based on the study of a population sample composed of play-ers of the men's basketball team of the Pedagogical and Technological University of Colombia Sogamoso Sectional Faculty, whose ages range between 17 and 24 years, who also meet the requirement of being active students of an undergraduate career.

For the purpose of this research, the process was segmented into phases as follows.

### Phase 2. Information processing

* Capture of participants movements during the execution of the free-throw shooting technique, using high-definition cameras and motive optitrack software.

* Processing of images collected from high-definition cameras using the Python programming language.

* Storage of data extracted through image processing, this will be done by integrating it with the documentation in flat files obtained in the measurement and anthropometric characterization of the participants.

### Phase 3. Learning model

* Extraction of data obtained in flat files with the motive optitrack software, and subsequent integration with the flat file containing the anthropometric characterization and digital processing data.

* Classification of variables according to successes during motion capture sessions.

* Use of Weka software for data analysis and statistical processing of the data stored in the flat file, according to the classification assigned to the variables. This will allow us to demonstrate by means of correlation matrices the interaction of the variables during the execution of the movement, and its relation with an optimal technique according to the successes or deficiencies in the attainment of scores by the players according to their throwing technique.
In order to make a biomechanical description of the throwing action, it is necessary to identify the phases that make up the throwing action, and how the athlete's body parts behave within each of these phases, that is, to identify the behavior patterns of the upper limbs and their joints, their measurements, and their variation as the movement is executed [2]. It is essential to bear in mind that the execution of free throws does not have rigid and predetermined standard, however, there are techniques associated with the effectiveness of the free throw [3]. In the anthropometric study of the upper limbs, the values corresponding to the dimensions of the arms, forearms, hands, and their length and extension, among other variables, are treated [5].

The specific study of upper limbs has been widely used for the creation of prostheses as it allows through the results obtained to make products appropriate for the needs of people who have suffered malformations, injuries, or loss of any of their limbs, as it allows to establish ideal characteristics in terms of optimal materials for use, and different components involved in the design and production of prostheses according to ISO 13405-1 standard, such as interface components (interaction with the patient), functional, alignment, structural and cosmetic (appearance as close as possible to a natural human limb) [6]. In this way, the relationship between these dimensions and the execution of movements can be established by means of a dynamic anthropometric analysis of the upper limbs.

# 2 Materials and methods

## 2.1 Method

### Phase 1. Information collection.

Analyses were carried out based on the study of a population sample composed of play-ers of the men's basketball team of the Pedagogical and Technological University of Colombia Sogamoso Sectional Faculty, whose ages range between 17 and 24 years, who also meet the requirement of being active students of an undergraduate career.

For the purpose of this research, the process was segmented into phases as follows.

### Phase 2. Information processing

* Capture of participants movements during the execution of the free-throw shooting technique, using high-definition cameras and motive optitrack software.

* Processing of images collected from high-definition cameras using the Python programming language.

* Storage of data extracted through image processing, this will be done by integrating it with the documentation in flat files obtained in the measurement and anthropometric characterization of the participants.

### Phase 3. Learning model

* Extraction of data obtained in flat files with the motive optitrack software, and subsequent integration with the flat file containing the anthropometric characterization and digital processing data.

* Classification of variables according to successes during motion capture sessions.

* Use of Weka software for data analysis and statistical processing of the data stored in the flat file, according to the classification assigned to the variables. This will allow us to demonstrate by means of correlation matrices the interaction of the variables during the execution of the movement, and its relation with an optimal technique according to the successes or deficiencies in the attainment of scores by the players according to their throwing technique.
* From the above, using the software, a classification tree is generated, which will give us results of the behavior of the variables to achieve an optimal launching technique.

**Phase 4. Evaluation and training**

* Finally, a classification of the adequate behavior of the variables in the throwing technique will be made, for the construction of an optimal training methodology, by means of routines, based on the results obtained in the classification tree, for the improvement of the free-throw throwing technique.

* In addition, a teaching/learning process of free throw shooting will be designed, through sessions and routines established according to the optimal characterization made in the study, this will serve as a guide to adequately develop the sports training process, thus making a contribution to basketball instructors and players.

**Phase 5. Design and codification**

* Finally, the methodological design of development, generation of schemes of actions, packages and others corresponding to a software development is planned, where the deductive model is already established with the results in accordance with the objectives, it will be embodied in coding to obtain as an expected result a system where the capture of movement and level of assertiveness of the linguistic sign of the exposed model can be observed

Detailed description of the method steps can be seen in figure 1.

<figure><img src="image_31.png" /><figcaption>Fig 1. Applied Method</figcaption></figure>

**2.2 Measuring instruments and techniques**

* High-definition camera: Which will allow us to perform motion capture in natural environments (basketball court)

* Software Motive Optitrack: The Motive Optitrack software allows us to capture movements by means of a hardware consisting of 12 cameras, and an integration with a system of capture and digital processing of video material, from which a data extraction is performed through flat files that give us detailed information of the behavior of the variables mentioned above.

* Python programming language for digital image processing.

* Anthropometric and goniometric measurement techniques: To obtain the data and characteristics of the upper limbs of each player in the sample under study.

* Weka Software: For analysis of measures of central tendency, correlational analysis of variables (to establish how variables interact and their relationship to an effective technique), and classification trees to analyze results. Motion capture is performed with Motive Optitrack software and hardware or with a high-definition camera as can be seen on figure 2.
* From the above, using the software, a classification tree is generated, which will give us results of the behavior of the variables to achieve an optimal launching technique.

**Phase 4. Evaluation and training**

* Finally, a classification of the adequate behavior of the variables in the throwing technique will be made, for the construction of an optimal training methodology, by means of routines, based on the results obtained in the classification tree, for the improvement of the free-throw throwing technique.

* In addition, a teaching/learning process of free throw shooting will be designed, through sessions and routines established according to the optimal characterization made in the study, this will serve as a guide to adequately develop the sports training process, thus making a contribution to basketball instructors and players.

**Phase 5. Design and codification**

* Finally, the methodological design of development, generation of schemes of actions, packages and others corresponding to a software development is planned, where the deductive model is already established with the results in accordance with the objectives, it will be embodied in coding to obtain as an expected result a system where the capture of movement and level of assertiveness of the linguistic sign of the exposed model can be observed

Detailed description of the method steps can be seen in figure 1.

<figure><img src="image_45.png" /><figcaption>Fig 1. Applied Method</figcaption></figure>

**2.2 Measuring instruments and techniques**

* High-definition camera: Which will allow us to perform motion capture in natural environments (basketball court)

* Software Motive Optitrack: The Motive Optitrack software allows us to capture movements by means of a hardware consisting of 12 cameras, and an integration with a system of capture and digital processing of video material, from which a data extraction is performed through flat files that give us detailed information of the behavior of the variables mentioned above.

* Python programming language for digital image processing.

* Anthropometric and goniometric measurement techniques: To obtain the data and characteristics of the upper limbs of each player in the sample under study.

* Weka Software: For analysis of measures of central tendency, correlational analysis of variables (to establish how variables interact and their relationship to an effective technique), and classification trees to analyze results. Motion capture is performed with Motive Optitrack software and hardware or with a high-definition camera as can be seen on figure 2.
<figure><img src="image_32.png" /><figcaption>Fig 2. Motion capture.</figcaption></figure>

**2.3 Analysis procedure sequence**

* Capture of participants movements during the execution of the free-throw shooting technique, using high-definition cameras and motive optitrack software.

* Processing of images collected from high-definition cameras using the Python programming language.

* Storage of data extracted through image processing, this will be done by integrating it with the documentation in flat files obtained in the measurement and anthropometric characterization of the participants.

* Extraction of data obtained in flat files with the motive optitrack software, and subsequent integration with the flat file containing the anthropometric characterization and digital processing data.

* Classification of variables according to successes during motion capture sessions.

* Use of Weka software for data analysis and statistical processing of the data stored in the flat file, according to the classification assigned to the variables. This will allow us to demonstrate by means of correlation matrices the interaction of the variables during the execution of the movement, and its relation with an optimal technique according to the successes or deficiencies in the attainment of scores by the players according to their throwing technique.

* From the above, using the software, a classification tree is generated, which will give us results of the behavior of the variables to achieve an optimal launching technique. Based on the data collected from the free throw capture as seen in figure 3.

<figure><img src="image_33.png" /><figcaption>Fig 3. Free throw capture</figcaption></figure>
<figure><img src="image_46.png" /><figcaption>Fig 2. Motion capture.</figcaption></figure>

**2.3 Analysis procedure sequence**

* Capture of participants movements during the execution of the free-throw shooting technique, using high-definition cameras and motive optitrack software.

* Processing of images collected from high-definition cameras using the Python pro- gramming language.

* Storage of data extracted through image processing, this will be done by integrating it with the documentation in flat files obtained in the measurement and anthropometric characterization of the participants.

* Extraction of data obtained in flat files with the motive optitrack software, and subsequent integration with the flat file containing the anthropometric characterization and digital processing data.

* Classification of variables according to successes during motion capture sessions.

* Use of Weka software for data analysis and statistical processing of the data stored in the flat file, according to the classification assigned to the variables. This will allow us to demonstrate by means of correlation matrices the interaction of the variables during the execution of the movement, and its relation with an optimal technique according to the successes or deficiencies in the attainment of scores by the players according to their throwing technique.

* From the above, using the software, a classification tree is generated, which will give us results of the behavior of the variables to achieve an optimal launching technique. Based on the data collected from the free throw capture as seen in figure 3.

<figure><img src="image_47.png" /><figcaption>Fig 3. Free throw capture</figcaption></figure>
## 2.4 Data structure for analysis

The data structure presented is non-linear, therefore, it behaves as a tree within which different components are correlated and whose trends and projections in terms of behavior are related to external variables [8].

For this particular case, the level structure of the data is reflected in a first level that represents the general data of the athlete, the next level corresponds to the variables to be analyzed, after this analysis a result of data that affect the behavior of the throwing mechanics is obtained (Incident variables) and those that do not meet this condition are discarded. From this, a weight is assigned to each variable depending on its incidence in the launching technique, from which a probabilistic estimation is made by means of a Poisson distribution, because the result of a free throw launching is subject to several external conditions and the probability of occurrence of a high effectiveness must be taken as an event that occurs, but not in a constant way [9]. Finally, we have the final result corresponding to the execution of the free throws by the athletes. Data structure can be seen in figure 4.

<figure><img src="image_34.png" /><figcaption>Fig 4. Data Structure</figcaption></figure>

# 3 Results and discussion

Anthropometric characterization

An anthropometric characterization of the length of the upper limbs that interact within the mechanics of free-throw shooting was carried out, which provides us with an indicator of the variables analyzed in order to interpret their correlation with the effectiveness of free-throw shooting. The characterization was performed as shown in table 1.
## 2.4 Data structure for analysis

The data structure presented is non-linear, therefore, it behaves as a tree within which different components are correlated and whose trends and projections in terms of behavior are related to external variables [8].

For this particular case, the level structure of the data is reflected in a first level that represents the general data of the athlete, the next level corresponds to the variables to be analyzed, after this analysis a result of data that affect the behavior of the throwing mechanics is obtained (Incident variables) and those that do not meet this condition are discarded. From this, a weight is assigned to each variable depending on its incidence in the launching technique, from which a probabilistic estimation is made by means of a Poisson distribution, because the result of a free throw launching is subject to several external conditions and the probability of occurrence of a high effectiveness must be taken as an event that occurs, but not in a constant way [9]. Finally, we have the final result corresponding to the execution of the free throws by the athletes. Data structure can be seen in figure 4.

<figure><img src="image_48.png" /><figcaption>Fig 4. Data Structure</figcaption></figure>

# 3 Results and discussion

Anthropometric characterization

An anthropometric characterization of the length of the upper limbs that interact within the mechanics of free-throw shooting was carried out, which provides us with an indicator of the variables analyzed in order to interpret their correlation with the effectiveness of free-throw shooting. The characterization was performed as shown in table 1.
<table><caption>**Table 1. Characterization**</caption><thead><tr><th>Athlete</th><th>Height</th><th>Arms length</th><th>Hands length</th><th>Forearm length</th><th>Elbow-Shoulder</th></tr></thead><tbody><tr><td>Player 1</td><td>175 cm</td><td>168 cm</td><td>17 cm</td><td>32.5 cm</td><td>40 cm</td></tr><tr><td>Player 2</td><td>184 cm</td><td>189 cm</td><td>20 cm</td><td>28 cm</td><td>35 cm</td></tr><tr><td>Player 3</td><td>173 cm</td><td>175 cm</td><td>20 cm</td><td>27 cm</td><td>28 cm</td></tr><tr><td>Player 4</td><td>178 cm</td><td>181 cm</td><td>20 cm</td><td>27 cm</td><td>35 cm</td></tr><tr><td>Player 5</td><td>191 cm</td><td>190 cm</td><td>20 cm</td><td>32 cm</td><td>49 cm</td></tr><tr><td>Player 6</td><td>188 cm</td><td>183 cm</td><td>20 cm</td><td>27 cm</td><td>37 cm</td></tr></tbody></table>

**Arm-forearm angle**

The analysis of the angle formed between arm and forearm gives us information about the correct execution of the throwing technique because the angle called a, can oscillate between 45° at the beginning of the movement and 85° at the end of it.

**Wrist flexion**

The flexion of the wrist is analyzed in the final sequence of the free throw, what we intend to measure for the purpose of this study are the initial and final angle corresponding to the flexion from its beginning until the moment in which the player gets rid of the ball.

**Effectiveness analysis by classification**

A classification analysis was performed by means of the J48 algorithm, taking as a reference class the effectiveness presented by the players during the free throw sessions, in which the classification gave us results about the behavior of the variables according to the value of the class, the class was defined as high, medium and low according to the percentage of successes for every 10 free throws made as can be seen in table 2.

<table><caption>**Table 2. Standard definition of classification**</caption><thead><tr><th>Launches</th><th>Successful</th><th>Effectiveness (Class defined)</th></tr></thead><tbody><tr><td>Quantity 10</td><td>0 - 4</td><td>Low</td></tr><tr><td>Quantity 10</td><td>5 - 6</td><td>Regular</td></tr><tr><td>Quantity 10</td><td>7 - 10</td><td>High</td></tr></tbody></table>

Based on this definition, a classification is made with respect to each of the variables, which yields the following results from the analysis carried out with respect to the height of the athletes, which shows a higher effectiveness in athletes with greater stat-ure, and establishes a relationship between those who meet the denomination of effectiveness (Low/Regular/High) for every 5 athletes as shown in table 3.

<table><caption>**Table 3. Analysis of the height variable by classification**</caption><thead><tr><th>Height</th><th>Effectiveness</th><th>Relation (Compliant/Total)</th></tr></thead><tbody><tr><td>&lt;= 175 cm</td><td>Low</td><td>3/5 Low - 2/5 High</td></tr><tr><td>&gt; 175 cm</td><td>High</td><td>1/5 Low - 4/5 High</td></tr></tbody></table>
<table><caption>**Table 1. Characterization**</caption><thead><tr><th>Athlete</th><th>Height</th><th>Arms length</th><th>Hands length</th><th>Forearm length</th><th>Elbow-Shoulder</th></tr></thead><tbody><tr><td>Player 1</td><td>175 cm</td><td>168 cm</td><td>17 cm</td><td>32.5 cm</td><td>40 cm</td></tr><tr><td>Player 2</td><td>184 cm</td><td>189 cm</td><td>20 cm</td><td>28 cm</td><td>35 cm</td></tr><tr><td>Player 3</td><td>173 cm</td><td>175 cm</td><td>20 cm</td><td>27 cm</td><td>28 cm</td></tr><tr><td>Player 4</td><td>178 cm</td><td>181 cm</td><td>20 cm</td><td>27 cm</td><td>35 cm</td></tr><tr><td>Player 5</td><td>191 cm</td><td>190 cm</td><td>20 cm</td><td>32 cm</td><td>49 cm</td></tr><tr><td>Player 6</td><td>188 cm</td><td>183 cm</td><td>20 cm</td><td>27 cm</td><td>37 cm</td></tr></tbody></table>

**Arm-forearm angle**

The analysis of the angle formed between arm and forearm gives us information about the correct execution of the throwing technique because the angle called a, can oscillate between 45° at the beginning of the movement and 85° at the end of it.

**Wrist flexion**

The flexion of the wrist is analyzed in the final sequence of the free throw, what we intend to measure for the purpose of this study are the initial and final angle corresponding to the flexion from its beginning until the moment in which the player gets rid of the ball.

**Effectiveness analysis by classification**

A classification analysis was performed by means of the J48 algorithm, taking as a reference class the effectiveness presented by the players during the free throw sessions, in which the classification gave us results about the behavior of the variables according to the value of the class, the class was defined as high, medium and low according to the percentage of successes for every 10 free throws made as can be seen in table 2.

<table><caption>**Table 2. Standard definition of classification**</caption><thead><tr><th>Launches</th><th>Successful</th><th>Effectiveness (Class defined)</th></tr></thead><tbody><tr><td>Quantity 10</td><td>0 - 4</td><td>Low</td></tr><tr><td>Quantity 10</td><td>5 - 6</td><td>Regular</td></tr><tr><td>Quantity 10</td><td>7 - 10</td><td>High</td></tr></tbody></table>

Based on this definition, a classification is made with respect to each of the variables, which yields the following results from the analysis carried out with respect to the height of the athletes, which shows a higher effectiveness in athletes with greater stat-ure, and establishes a relationship between those who meet the denomination of effectiveness (Low/Regular/High) for every 5 athletes as shown in table 3.

<table><caption>**Table 3. Analysis of the height variable by classification**</caption><thead><tr><th>Height</th><th>Effectiveness</th><th>Relation (Compliant/Total)</th></tr></thead><tbody><tr><td>&lt;= 175 cm</td><td>Low</td><td>3/5 Low - 2/5 High</td></tr><tr><td>&gt; 175 cm</td><td>High</td><td>1/5 Low - 4/5 High</td></tr></tbody></table>
In the same way, analyses were performed with respect to the other variables corresponding to upper limb extension such as elbow-shoulder length, forearm length, and arm length. These variables do not yield results that indicate a direct correlation with respect to the effectiveness of. As described in table 4.

<table><caption>**Table 4.** Analysis of the elbow/shoulder length variable by classification</caption><thead><tr><td>Elbow/shoulder length</td><td>Effectiveness</td><td>Relation (Compliant/Total)</td></tr></thead><tbody><tr><td>&lt;= 35 cm</td><td>High</td><td>2/5 Low - 3/5 High</td></tr><tr><td>&gt; 35 cm</td><td>Low</td><td>3/5 Low - 2/5 High</td></tr></tbody></table>

In addition, a classification analysis was performed for the biomechanical variables established for the study, such as the angle formed between the arm/forearm, and wrist flexion. This can be seen in table 5 and table 6.

<table><caption>**Table 5.** Result of analysis by classification of the arm/forearm angle</caption><thead><tr><td>Arm/forearm angle Initial</td><td>Arm/forearm angle Final</td><td>Effectiveness</td><td>Relation (Compliant/Total)</td></tr></thead><tbody><tr><td>45°</td><td>85°</td><td>High</td><td>1/5 Low - 4/5 High</td></tr><tr><td>55°</td><td>85°</td><td>Regular</td><td>2/5 Low - 3/5 High</td></tr><tr><td>&gt;55°</td><td>&gt;= 85°</td><td>Low</td><td>5/5 Low - 0/5 High</td></tr></tbody></table>

<table><caption>**Table 6.** Result of analysis by classification of the wrist angle</caption><thead><tr><td>Wrist angle Initial</td><td>Wrist angle Final</td><td>Effectiveness</td><td>Relation (Compliant/Total)</td></tr></thead><tbody><tr><td>110°</td><td>95°</td><td>High</td><td>1/5 Low - 4/5 High</td></tr><tr><td>&lt;110°</td><td>&gt;95°</td><td>Low</td><td>3/5 Low - 2/5 High</td></tr><tr><td>&lt;100°</td><td>&gt; 90°</td><td>Low</td><td>4/5 Low - 1/5 High</td></tr></tbody></table>

## 4 Conclusions

The results obtained from the analysis allow us to infer that athletes with a greater height tend to have better effectiveness in terms of free-throw shooting, however, it is perhaps the anthropometric factor that has more impact in relation to the effectiveness and efficiency of the technique, because the anthropometric measurements of upper limbs do not show such a direct relationship and represent only a characterization of the athlete.

The biomechanical variables analyzed, such as the initial and final angles of the wrist, arm and forearm at the moment of executing the technique, have a direct relationship with the effectiveness of the throw, that is, if the technique is effective it is reflected in the behavior of these variables through the angles, this allows us to demonstrate the displacement of the upper limbs during the execution of the technique and subsequent scores.
In the same way, analyses were performed with respect to the other variables corresponding to upper limb extension such as elbow-shoulder length, forearm length, and arm length. These variables do not yield results that indicate a direct correlation with respect to the effectiveness of. As described in table 4.

<table><caption>**Table 4.** Analysis of the elbow/shoulder length variable by classification</caption><thead><tr><td>Elbow/shoulder length</td><td>Effectiveness</td><td>Relation (Compliant/Total)</td></tr></thead><tbody><tr><td>&lt;= 35 cm</td><td>High</td><td>2/5 Low - 3/5 High</td></tr><tr><td>&gt; 35 cm</td><td>Low</td><td>3/5 Low - 2/5 High</td></tr></tbody></table>

In addition, a classification analysis was performed for the biomechanical variables established for the study, such as the angle formed between the arm/forearm, and wrist flexion. This can be seen in table 5 and table 6.

<table><caption>**Table 5.** Result of analysis by classification of the arm/forearm angle</caption><thead><tr><td>Arm/forearm angle Initial</td><td>Arm/forearm angle Final</td><td>Effectiveness</td><td>Relation (Compliant/Total)</td></tr></thead><tbody><tr><td>45°</td><td>85°</td><td>High</td><td>1/5 Low - 4/5 High</td></tr><tr><td>55°</td><td>85°</td><td>Regular</td><td>2/5 Low - 3/5 High</td></tr><tr><td>&gt;55°</td><td>&gt;= 85°</td><td>Low</td><td>5/5 Low - 0/5 High</td></tr></tbody></table>

<table><caption>**Table 6.** Result of analysis by classification of the wrist angle</caption><thead><tr><td>Wrist angle Initial</td><td>Wrist angle Final</td><td>Effectiveness</td><td>Relation (Compliant/Total)</td></tr></thead><tbody><tr><td>110°</td><td>95°</td><td>High</td><td>1/5 Low - 4/5 High</td></tr><tr><td>&lt;110°</td><td>&gt;95°</td><td>Low</td><td>3/5 Low - 2/5 High</td></tr><tr><td>&lt;100°</td><td>&gt; 90°</td><td>Low</td><td>4/5 Low - 1/5 High</td></tr></tbody></table>

## 4 Conclusions

The results obtained from the analysis allow us to infer that athletes with a greater height tend to have better effectiveness in terms of free-throw shooting, however, it is perhaps the anthropometric factor that has more impact in relation to the effectiveness and efficiency of the technique, because the anthropometric measurements of upper limbs do not show such a direct relationship and represent only a characterization of the athlete.

The biomechanical variables analyzed, such as the initial and final angles of the wrist, arm and forearm at the moment of executing the technique, have a direct relationship with the effectiveness of the throw, that is, if the technique is effective it is reflected in the behavior of these variables through the angles, this allows us to demonstrate the displacement of the upper limbs during the execution of the technique and subsequent scores.
References

1. Arora, C., Singh, P., and Varghese, V., "Biomechanics of core musculature on upper extremity performance in basketball players," Journal of Bodywork and Move-ment Therapies, vol. 27, pp. 127-133, 2021.

2. Lam, W. K., Kan, W. H., Chia, J. S., and Kong, P. W., "Effect of shoe modifica-tions on biomechanical changes in basketball: A systematic review," Sports Biome chanics, vol. 21, no. 5, pp. 577-603, 2022.

3. Lempke, L. B., Oh, J., Johnson, R. S., Schmidt, J. D., and Lynall, R. C., "Single-versus dual-task functional movement paradigms: a biomechanical analysis," Journal of Sport Rehabilitation, vol. 30, no. 5, pp. 774-785, 2021.

4. Martínez, S. P. A., Quintero, Y. J. V., Huertas, L. M. R., and Salazar, L. G., "Métodos ergonómicos observacionales para la evaluación del riesgo biomecánico asociado a desordenes musculoesqueléticos de miembros superiores en trabajadores 2014-2019," Revista Colombiana de Salud Ocupacional, vol. 10, no. 2, pp. 31-42, 2020.

5. Medina Cabrera, M. L., Toledo Ríos, R., and Sánchez Oms, A. B., "Procedimiento para el análisis biomecánico de la variabilidad del movimiento en el lanzamiento de disco."

6. Pan, H., Li, J., Wang, H., and Zhang, K., "Biomechanical analysis of shooting performance for basketball players based on Computer Vision," in Journal of Physics:Conference Series, vol. 2024, no. 1, p. 012016, Sept. 2021.

7. Pérez Toasa, R. D., "Evaluación biomecánica en el proceso de aprendizaje de la técnica del lanzamiento libre del baloncesto en escolares de la Unidad Educativa TeresaFlor en el periodo abril-agosto 2021," Bachelor's thesis, Universidad Técnica de Ambato-Facultad de Ciencias Humanas y de la Educación-Carrera de Pedagogía de laActividad Física y Deporte, 2021.

8. Srinivas, T. A. S., Somula, R., Aravind, K., and Manivannan, S. S., "Pattern Pre-diction Using Binary Trees," in Innovations in Computer Science and Engineering: Proceedings of 8th ICICSE, vol. 171, pp. 43, 2021.

9. Yang, C., and Jia, M., "Health condition identification for rolling bearing based on hierarchical multiscale symbolic dynamic entropy and least squares support tensor machine-based binary tree," Structural Health Monitoring, vol. 20, no. 1, pp. 151-172,2021.

10. Zhang, J., Chi, B., Singh, K. M., Zhong, Y., and Ju, C., "A binary-tree elementsubdivision method for evaluation of singular domain integrals with continuous or discontinuous kernel," Engineering Analysis with Boundary Elements, vol. 116, pp. 14-30, 2020.
References

1. Arora, C., Singh, P., and Varghese, V., "Biomechanics of core musculature on upper extremity performance in basketball players," Journal of Bodywork and Move-ment Therapies, vol. 27, pp. 127-133, 2021.

2. Lam, W. K., Kan, W. H., Chia, J. S., and Kong, P. W., "Effect of shoe modifica-tions on biomechanical changes in basketball: A systematic review," Sports Biome chanics, vol. 21, no. 5, pp. 577-603, 2022.

3. Lempke, L. B., Oh, J., Johnson, R. S., Schmidt, J. D., and Lynall, R. C., "Single-versus dual-task functional movement paradigms: a biomechanical analysis," Journal of Sport Rehabilitation, vol. 30, no. 5, pp. 774-785, 2021.

4. Martínez, S. P. A., Quintero, Y. J. V., Huertas, L. M. R., and Salazar, L. G., "Métodos ergonómicos observacionales para la evaluación del riesgo biomecánico asociado a desordenes musculoesqueléticos de miembros superiores en trabajadores 2014-2019," Revista Colombiana de Salud Ocupacional, vol. 10, no. 2, pp. 31-42, 2020.

5. Medina Cabrera, M. L., Toledo Ríos, R., and Sánchez Oms, A. B., "Procedimiento para el análisis biomecánico de la variabilidad del movimiento en el lanzamiento de disco."

6. Pan, H., Li, J., Wang, H., and Zhang, K., "Biomechanical analysis of shooting performance for basketball players based on Computer Vision," in Journal of Physics:Conference Series, vol. 2024, no. 1, p. 012016, Sept. 2021.

7. Pérez Toasa, R. D., "Evaluación biomecánica en el proceso de aprendizaje de la técnica del lanzamiento libre del baloncesto en escolares de la Unidad Educativa TeresaFlor en el periodo abril-agosto 2021," Bachelor's thesis, Universidad Técnica de Ambato-Facultad de Ciencias Humanas y de la Educación-Carrera de Pedagogía de laActividad Física y Deporte, 2021.

8. Srinivas, T. A. S., Somula, R., Aravind, K., and Manivannan, S. S., "Pattern Pre-diction Using Binary Trees," in Innovations in Computer Science and Engineering: Proceedings of 8th ICICSE, vol. 171, pp. 43, 2021.

9. Yang, C., and Jia, M., "Health condition identification for rolling bearing based on hierarchical multiscale symbolic dynamic entropy and least squares support tensor machine-based binary tree," Structural Health Monitoring, vol. 20, no. 1, pp. 151-172,2021.

10. Zhang, J., Chi, B., Singh, K. M., Zhong, Y., and Ju, C., "A binary-tree elementsubdivision method for evaluation of singular domain integrals with continuous or discontinuous kernel," Engineering Analysis with Boundary Elements, vol. 116, pp. 14-30, 2020.