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

HAL
open science

Decisioning Workshop 2023

Daniel Andres Feriz Garcia, Luis Freddy Muñoz Sanabria, Cesar Collazos,
Diego Torres, Mario Lezoche, Vanessa Agredo, Pablo Ruiz, Julio Hurtado

► To cite this version:

Daniel Andres Feriz Garcia, Luis Freddy Muñoz Sanabria, Cesar Collazos, Diego Torres, Mario Lezoche, et al. Decisioning Workshop 2023: Collaboration in knowledge discovery and decisioning making. Decisioning workshop 2023, 2023. [https://hal.science/hal-04535962](https://hal.science/hal-04535962)

HAL Id: hal-04535962

https://hal.science/hal-04535962

Submitted on 7 Apr 2024

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
<figure><img src="image_1.png" /></figure>

HAL
open science

Decisioning Workshop 2023

Daniel Andres Feriz Garcia, Luis Freddy Muñoz Sanabria, Cesar Collazos,
Diego Torres, Mario Lezoche, Vanessa Agredo, Pablo Ruiz, Julio Hurtado

► To cite this version:

Daniel Andres Feriz Garcia, Luis Freddy Muñoz Sanabria, Cesar Collazos, Diego Torres, Mario Lezoche, et al.. Decisioning Workshop 2023. Decisioning workshop 2023, 2023. [https://hal.science/hal-04535962](https://hal.science/hal-04535962)

HAL Id: hal-04535962

https://hal.science/hal-04535962v1

Submitted on 7 Apr 2024

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
DECISIONING
2023

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

THE SECOND WORKSHOP ON
"COLLABORATION IN KNOWLEDGE
DISCOVERY AND DECISIONING MAKING"

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

UNIVERSITÉ
DE LORRAINE

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

Lifia

Facultad de Informática - Universidad Nacional de La Plata

Universidad Tecnológica
de Pereira

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

Universidad
del Cauca*

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

FUNDACIÓN
UNIVERSITARIA
DE POPAYÁN

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

Corporación
Universitaria
Comfacauca

Unicomfacauca

VIGILADA MINISTERIO DE EDUCACIÓN
DECISIONING
2023

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

THE SECOND WORKSHOP ON
"COLLABORATION IN KNOWLEDGE
DISCOVERY AND DECISIONING MAKING"

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

UNIVERSITÉ
DE LORRAINE

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

Lifia

Facultad de Informática - Universidad Nacional de La Plata

Universidad Tecnológica
de Pereira

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

Universidad
del Cauca*

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

FUNDACIÓN
UNIVERSITARIA
DE POPAYÁN

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

Corporación
Universitaria
Comfacauca

Unicomfacauca

VIGILADA MINISTERIO DE EDUCACIÓN
# DECISIONING
2023

The second workshop on
“Collaboration in knowledge
discovery and decision making.”

Freddy Muñoz Sanabria · Cesar A Collazos ·
Diego Torres · Mario Lezoche ·
Vanessa Agredo · Pablo H. Ruiz ·
Julio A Hurtado
# DECISIONING
2023

The second workshop on
“Collaboration in knowledge
discovery and decision making.”

Freddy Muñoz Sanabria · Cesar A Collazos ·
Diego Torres · Mario Lezoche ·
Vanessa Agredo · Pablo H. Ruiz ·
Julio A Hurtado
## Editors

Daniel Andres Feriz Garcia

Luis Freddy Muñoz Sanabria

Cesar A. Collazos

## Compilers

Luis Freddy Muñoz Sanabria

Fundación Universitaria de Popayán
Popayán, Colombia

Cesar A. Collazos

Universidad del Cauca
Popayán, Colombia

Diego Torres

Universidad Nacional de La Plata
Argentina

Mario Lezoche

University of Lorraine
Francia

Vanessa Agredo

Corporación Universitaria Comfacauca
Popayán, Colombia

Pablo H Ruiz

Corporación Universitaria Comfacauca
Popayán, Colombia

Julio A Hurtado

Universidad del Cauca
Popayán, Colombia

## Editorial:

Fundación Universitaria de Popayán
ISBN:

2023

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

FUNDACIÓN
UNIVERSITARIA
DE POPAYÁN
## Editors

Daniel Andres Feriz Garcia

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

Luis Freddy Muñoz Sanabria

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

Cesar A. Collazos

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

## Compilers

Luis Freddy Muñoz Sanabria

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

Fundación Universitaria de Popayán
Popayán, Colombia

Cesar A. Collazos

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

Universidad del Cauca
Popayán, Colombia

Diego Torres

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

Universidad Nacional de La Plata
Argentina

Mario Lezoche

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

University of Lorraine
Francia

Vanessa Agredo

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

Corporación Universitaria Comfacauca
Popayán, Colombia

Pablo H Ruiz

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

Corporación Universitaria Comfacauca
Popayán, Colombia

Julio A Hurtado

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

Universidad del Cauca
Popayán, Colombia

## Editorial:

Fundación Universitaria de Popayán
ISBN:

2023

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

FUNDACIÓN
UNIVERSITARIA
DE POPAYÁN
# DECISIONING 2023:

## The second workshop on "Collaboration in knowledge discovery and decision making."

In a knowledge society, the term knowledge must be considered a core resource for organizations. So, beyond being a medium to progress and to innovate, knowledge is one of our most important resources: something necessary to decide. Organizations that are embracing knowledge retention activities are gaining a competitive advantage. Organizational rearrangements from companies, notably outsourcing, increase a possible loss of knowledge, making knowledge retention an essential need for them. When Knowledge is less shared, collaborative decision-making seems harder to obtain insofar as a "communication breakdown" characterizes participants' discourse. At best, stakeholders have to find a consensus according to their knowledge. Sharing knowledge ensures its retention and catalyzes the construction of this consensus.

Our vision of collaborative decision-making aims not only at increasing the quality of the first parts of the decision-making process: intelligence and design, but also at increasing the acceptance of the choice. Intelligence and design will be done by more than one individual and constructed together; the decision is more easily accepted. The decided choice will then be shared. Thereby where decision-making could be seen as a constructed model, collaborative decision-making, for us, is seen as the use of socio-technical media to improve decision-making performance and acceptability. The shared decision making is a core activity in a lot of human activities. For example, the sustainable decision-making is the job of not only governments and institutions but also broader society. Recognizing the urgent need for sustainability, we can argue that to realize sustainable development, it must be considered as a decision-making strategy. The location of knowledge in the realization of collaborative decision-making has to be regarded insofar as knowledge sharing leads to improve collaborative decision-making: a "static view" has to be structured and constitutes the "collaborative knowledge." Knowledge has an important role in individual decision-making, and we consider that for collaborative decision-making, knowledge has to be shared. What is required is a better understanding of the nature of group work". Knowledge has to be shared, but how do we share knowledge?

Decisioning 2023 is the second workshop on Collaboration in knowledge discovery and decision-making: It has been organized by six research teams from France, Argentina, and Colombia to explore the current frontier of knowledge and applications in different areas related to knowledge discovery and decision-making. The format of this workshop is hybrid (face-to-face or virtual), aims at the discussion and knowledge exchange between the academy and industry members. This workshop has been partially supported by STIC-AmSud projects: AGROFAIR (Agro-Knowledge Integration: Developing a FAIR data science approach for adding value to the agricultural supply chain) and AICODA: Artificial Intelligence in Collaborative Decision making Agriculture.
# DECISIONING 2023:

## The second workshop on "Collaboration in knowledge discovery and decision making."

In a knowledge society, the term knowledge must be considered a core resource for organizations. So, beyond being a medium to progress and to innovate, knowledge is one of our most important resources: something necessary to decide. Organizations that are embracing knowledge retention activities are gaining a competitive advantage. Organizational rearrangements from companies, notably outsourcing, increase a possible loss of knowledge, making knowledge retention an essential need for them. When Knowledge is less shared, collaborative decision-making seems harder to obtain insofar as a "communication breakdown" characterizes participants' discourse. At best, stakeholders have to find a consensus according to their knowledge. Sharing knowledge ensures its retention and catalyzes the construction of this consensus.

Our vision of collaborative decision-making aims not only at increasing the quality of the first parts of the decision-making process: intelligence and design, but also at increasing the acceptance of the choice. Intelligence and design will be done by more than one individual and constructed together; the decision is more easily accepted. The decided choice will then be shared. Thereby where decision-making could be seen as a constructed model, collaborative decision-making, for us, is seen as the use of socio-technical media to improve decision-making performance and acceptability. The shared decision making is a core activity in a lot of human activities. For example, the sustainable decision-making is the job of not only governments and institutions but also broader society. Recognizing the urgent need for sustainability, we can argue that to realize sustainable development, it must be considered as a decision-making strategy. The location of knowledge in the realization of collaborative decision-making has to be regarded insofar as knowledge sharing leads to improve collaborative decision-making: a "static view" has to be structured and constitutes the "collaborative knowledge." Knowledge has an important role in individual decision-making, and we consider that for collaborative decision-making, knowledge has to be shared. What is required is a better understanding of the nature of group work". Knowledge has to be shared, but how do we share knowledge?

Decisioning 2023 is the second workshop on Collaboration in knowledge discovery and decision-making: It has been organized by six research teams from France, Argentina, and Colombia to explore the current frontier of knowledge and applications in different areas related to knowledge discovery and decision-making. The format of this workshop is hybrid (face-to-face or virtual), aims at the discussion and knowledge exchange between the academy and industry members. This workshop has been partially supported by STIC-AmSud projects: AGROFAIR (Agro-Knowledge Integration: Developing a FAIR data science approach for adding value to the agricultural supply chain) and AICODA: Artificial Intelligence in Collaborative Decision making Agriculture.
This workshop was organized in the city of Popayan (Colombia) during June 21 to 23 – 2023, and brought together researchers from different countries and regions of Colombia. Seven long articles, five short articles, and two posters were presented in this edition.

## Chairs and Committee

### General Chairs

**Dr. Cesar Collazos**, Universidad del Cauca, Colombia.

<ccollazo@unicauca.edu.co>

**Dr. Diego Torres**, Universidad Nacional de La Plata-Universidad Nacional de Quilmes,

Argentina. <diego.torres@lifia.info.unlp.edu.ar>

**Dr. Mario Lezoche**, University of Lorraine, France

<mario.lezoche@univ-lorraine.fr>

### Organizing Committee

**Dr. Julio Hurtado**, Universidad del Cauca, Colombia.

<ahurtado@unicauca.edu.co>

**Dr. Freddy Muñoz**. Fundación Universitaria de Popayán,

<freddy.munoz@docente.fup.edu.co>

**Dr. Julio César Chavarro**, Universidad Tecnológica de Pereira, Colombia,

<jchavar@utp.edu.co>

**Mag. Clara Eugenia Satizábal Serna**. Fundación Universitaria de Popayán,

<sistemas@fup.edu.co>

**Mag. Daniela Iboth Gutiérrez Idrobo**. Fundación Universitaria de

Popayán, <daniela.gutierrez@docente.fup.edu.co>

**Mag. Luis Alfonso Vejarano**. Fundación Universitaria de Popayán

**Mag. Daniel Andrés Feriz García**. Fundación Universitaria de Popayán

**Mag. Sonia Del Consuelo Gaviria Armero**. Fundación Universitaria de Popayán

### Doctoral Symposium Chair

**Dr. Cesar Collazos**, Universidad del Cauca, Colombia.

<ccollazo@unicauca.edu.co>

**Dr. Alejandro Fernández**, Universidad Nacional de La Plata-Universidad Nacional de Quilmes,

Argentina <alejandro.fernandez@lifia.info.unlp.edu.ar>
This workshop was organized in the city of Popayan (Colombia) during June 21 to 23 – 2023, and brought together researchers from different countries and regions of Colombia. Seven long articles, five short articles, and two posters were presented in this edition.

## Chairs and Committee

### General Chairs

**Dr. Cesar Collazos**, Universidad del Cauca, Colombia.
<ccollazo@unicauca.edu.co>

**Dr. Diego Torres**, Universidad Nacional de La Plata-Universidad Nacional de Quilmes, Argentina.
<diego.torres@lifia.info.unlp.edu.ar>

**Dr. Mario Lezoche**, University of Lorraine, France
<mario. lezoche@univ-lorraine.fr>

### Organizing Committee

**Dr. Julio Hurtado**, Universidad del Cauca, Colombia.
<ahurtado@unicauca.edu.co>

**Dr. Freddy Muñoz**. Fundación Universitaria de Popayán,
<freddy.munoz@docente.fup.edu.co>

**Dr. Julio César Chavarro**, Universidad Tecnológica de Pereira, Colombia,
<jchavar@utp.edu.co>

**Mag. Clara Eugenia Satizábal Serna**. Fundación Universitaria de Popayán,
<sistemas@fup.edu.co>

**Mag. Daniela Iboth Gutiérrez Idrobo**. Fundación Universitaria de Popayán,
<daniela.gutierrez@docente.fup.edu.co>

**Mag. Luis Alfonso Vejarano**. Fundación Universitaria de Popayán

**Mag. Daniel Andrés Feriz García**. Fundación Universitaria de Popayán

**Mag. Sonia Del Consuelo Gaviria Armero**. Fundación Universitaria de Popayán

### Doctoral Symposium Chair

**Dr. Cesar Collazos**, Universidad del Cauca, Colombia.
<ccollazo@unicauca.edu.co>

**Dr. Alejandro Fernández**, Universidad Nacional de La Plata-Universidad Nacional de Quilmes, Argentina
<alejandro.fernandez@lifia.info.unlp.edu.ar>
## Publicity Chairs

**Dr. Vanessa Agredo Delgado**, Corporación Universitaria Comfacauca-Unicomfacauca, Colombia. <vagredo@unicomfacauca.edu.co>

**Dr. Pablo H. Ruiz**, Corporación Universitaria Comfacauca-Unicomfacauca, Colombia. <pruiz@unicomfacauca.edu.co>

**Dr. Leandro Antonelli**, Universidad Nacional de La Plata, Argentina. <leandro.antonelli@lifia.info.unlp.edu.ar>

## Program Committee Members

<table><tr><td>Alfonso</td><td>Infante</td><td>alfonso.infante@decd.uhu.es</td></tr><tr><td>Alicia</td><td>Mon</td><td>amon@unlam.edu.ar</td></tr><tr><td>Ana</td><td>Esteso</td><td>aesteso@cigip.upv.es</td></tr><tr><td>Ana Isabel</td><td>Molina Díaz</td><td>AnaIsabel.Molina@uclm.es</td></tr><tr><td>Ana Paula</td><td>Costa</td><td>apcabral@cdsid.org.br</td></tr><tr><td>Andres</td><td>Rodriguez</td><td>asrodriguez@gmail.com</td></tr><tr><td>Andres</td><td>Rodriguez</td><td>arodrig@lifia.info.unlp.edu.ar</td></tr><tr><td>Antonio</td><td>Silva Sprock</td><td>asilva.sprock@gmail.com</td></tr><tr><td>Carlos</td><td>Buil Aranda</td><td>cbuilaranda@gmail.com</td></tr><tr><td>Claudia</td><td>Pons</td><td>cpons@info.unlp.edu.ar</td></tr><tr><td>Cristina</td><td>Manresa-Yee</td><td>cristina.manresa@uib.es</td></tr><tr><td>Danielle</td><td>Morais</td><td>dcmorais@insid.org.br</td></tr><tr><td>Diego</td><td>Firmenich</td><td>diego.firmenich@gmail.com</td></tr><tr><td>Fernando</td><td>Moreira</td><td>fmoreira@upt.pt</td></tr><tr><td>Francesca</td><td>Pozzi</td><td>pozzi@itd.cnr.it</td></tr><tr><td>Francisco Luis</td><td>Gutiérrez Vela</td><td>fgutierr@ugr.es</td></tr><tr><td>Gabriela</td><td>Arevalo</td><td>gabriela.b.arevalo@gmail.com</td></tr><tr><td>Germán Ezequiel</td><td>Lescano</td><td>gelescano@unse.edu.ar</td></tr><tr><td>Gineth Magaly</td><td>Cerón Rios</td><td>gceron@unicomfacauca.edu.co</td></tr><tr><td>Gustavo</td><td>Constain Moreno</td><td>gustavo CONSTAIN@gmail.com</td></tr><tr><td>Guy</td><td>Camilleri</td><td>Guy.Camilleri@irit.fr</td></tr><tr><td>Horacio</td><td>Del Giorgio</td><td>horacio.delgiorgio@gmail.com</td></tr><tr><td>Horacio</td><td>Del Giorgio</td><td>hdelgiorgio@ing.unlam.edu.ar</td></tr><tr><td>Huizilopoztli</td><td>Luna-García</td><td>hlugar@uaz.edu.mx</td></tr><tr><td>Isabelle</td><td>Linden</td><td>isabelle.linden@unamur.be</td></tr><tr><td>Jaime</td><td>Díaz</td><td>jaime.diaz87@gmail.com</td></tr><tr><td>Jaime</td><td>Muñoz-Arteaga</td><td>jmauaa@gmail.com</td></tr><tr><td>Jason</td><td>Papathanasiou</td><td>jasonp@uom.gr</td></tr><tr><td>Javier Alejandro</td><td>Jiménez Toledo</td><td>javierjx@gmail.com</td></tr><tr><td>Javier</td><td>Berrocal</td><td>jberolm@unex.es</td></tr><tr><td>Jesús</td><td>Gallardo Casero</td><td>jesus.gallardo@unizar.es</td></tr><tr><td>Jose</td><td>García-Alonso</td><td>jgaralo@unex.es</td></tr><tr><td>Jose</td><td>Pow</td><td>japowsang@pucp.pe</td></tr><tr><td>Juan Enrique</td><td>Garrido Navarro</td><td>juanenrique.garrido@udl.cat</td></tr><tr><td>Juan Manuel</td><td>Murillo Rodríguez</td><td>juanmamu@unex.es</td></tr><tr><td>Julián</td><td>Muñoz</td><td>julianfer87@gmail.com</td></tr></table>
## Publicity Chairs

**Dr. Vanessa Agredo Delgado**, Corporación Universitaria Comfacauca-Unicomfacauca, Colombia. <vagredo@unicomfacauca.edu.co>

**Dr. Pablo H. Ruiz**, Corporación Universitaria Comfacauca-Unicomfacauca, Colombia. <pruiz@unicomfacauca.edu.co>

**Dr. Leandro Antonelli**, Universidad Nacional de La Plata, Argentina. <leandro.antonelli@lifia.info.unlp.edu.ar>

## Program Committee Members

<table><tr><td>Alfonso</td><td>Infante</td><td>alfonso.infante@decd.uhu.es</td></tr><tr><td>Alicia</td><td>Mon</td><td>amon@unlam.edu.ar</td></tr><tr><td>Ana</td><td>Esteso</td><td>aesteso@cigip.upv.es</td></tr><tr><td>Ana Isabel</td><td>Molina Díaz</td><td>AnaIsabel.Molina@uclm.es</td></tr><tr><td>Ana Paula</td><td>Costa</td><td>apcabral@cdsid.org.br</td></tr><tr><td>Andres</td><td>Rodriguez</td><td>asrodriguez@gmail.com</td></tr><tr><td>Andres</td><td>Rodriguez</td><td>arodrig@lifia.info.unlp.edu.ar</td></tr><tr><td>Antonio</td><td>Silva Sprock</td><td>asilva.sprock@gmail.com</td></tr><tr><td>Carlos</td><td>Buil Aranda</td><td>cbuilaranda@gmail.com</td></tr><tr><td>Claudia</td><td>Pons</td><td>cpons@info.unlp.edu.ar</td></tr><tr><td>Cristina</td><td>Manresa-Yee</td><td>cristina.manresa@uib.es</td></tr><tr><td>Danielle</td><td>Morais</td><td>dcmorais@insid.org.br</td></tr><tr><td>Diego</td><td>Firmenich</td><td>diego.firmenich@gmail.com</td></tr><tr><td>Fernando</td><td>Moreira</td><td>fmoreira@upt.pt</td></tr><tr><td>Francesca</td><td>Pozzi</td><td>pozzi@itd.cnr.it</td></tr><tr><td>Francisco Luis</td><td>Gutiérrez Vela</td><td>fgutierr@ugr.es</td></tr><tr><td>Gabriela</td><td>Arevalo</td><td>gabriela.b.arevalo@gmail.com</td></tr><tr><td>Germán Ezequiel</td><td>Lescano</td><td>gelescano@unse.edu.ar</td></tr><tr><td>Gineth Magaly</td><td>Cerón Rios</td><td>gceron@unicomfacauca.edu.co</td></tr><tr><td>Gustavo</td><td>Constain Moreno</td><td>gustavo CONSTAIN@gmail.com</td></tr><tr><td>Guy</td><td>Camilleri</td><td>Guy.Camilleri@irit.fr</td></tr><tr><td>Horacio</td><td>Del Giorgio</td><td>horacio.delgiorgio@gmail.com</td></tr><tr><td>Horacio</td><td>Del Giorgio</td><td>hdelgiorgio@ing.unlam.edu.ar</td></tr><tr><td>Huizilopoztli</td><td>Luna-García</td><td>hlugar@uaz.edu.mx</td></tr><tr><td>Isabelle</td><td>Linden</td><td>isabelle.linden@unamur.be</td></tr><tr><td>Jaime</td><td>Díaz</td><td>jaime.diaz87@gmail.com</td></tr><tr><td>Jaime</td><td>Muñoz-Arteaga</td><td>jmauaa@gmail.com</td></tr><tr><td>Jason</td><td>Papathanasiou</td><td>jasonp@uom.gr</td></tr><tr><td>Javier Alejandro</td><td>Jiménez Toledo</td><td>javierjx@gmail.com</td></tr><tr><td>Javier</td><td>Berrocal</td><td>jberolm@unex.es</td></tr><tr><td>Jesús</td><td>Gallardo Casero</td><td>jesus.gallardo@unizar.es</td></tr><tr><td>Jose</td><td>García-Alonso</td><td>jgaralo@unex.es</td></tr><tr><td>Jose</td><td>Pow</td><td>japowsang@pucp.pe</td></tr><tr><td>Juan Enrique</td><td>Garrido Navarro</td><td>juanenrique.garrido@udl.cat</td></tr><tr><td>Juan Manuel</td><td>Murillo Rodríguez</td><td>juanmamu@unex.es</td></tr><tr><td>Julián</td><td>Muñoz</td><td>julianfer87@gmail.com</td></tr></table>
Julio

Julio

Klinge Orlando

Leandro

Leandro

Liliana

Luis Freddy

Luis Mariano

Manuel

Marco Javier

María Del Mar

Maria Dolores

Miguel

Natalia

Nathalie

Oscar

Oscar

Pablo

Pablo

Pablo E.

Pablo Hernando

Patricia

Pascale

Patricio

Pavlos

Philippe

Pierre-mmanuel

Ricardo

Rosanna

Sergio

Silvana

Susana

Wilson Javier

Yasamin

Yosly Caridad

Hurtado

Ponce

Villalba-Condori

Antonelli

Fernandes

Vizzuett

Muñoz Sanabria

Bibbo

Ibarra

Suarez Baron

Alemany-Díaz

Lozano

Redondo

Padilla

Aussenac-Gilles

Revelo Sánchez

Franco

Torres-Carrion

Santana Mansilla

Martínez López

Ruiz Melenje

Paderewski

Zárate

Galdames

Delias

Palanque

Arduin

Tesoriero

Costaguta

Ochoa

Aciar

Bautista

Sarmiento

Eslami

Hernandez

jhurtado@dcc.uchile.cl

julk_cpg@hotmail.com

kvillalbac@unsa.edu.pe

leandro.antonelli@lifia.info.unlp.edu.ar

leandro.fernandes@mackenzie.br

lilianavizz@hotmail.com

lfreddyms@hotmail.com

lmbibbo@lifia.info.unlp.edu.ar

manuelibarra@gmail.com

marcojaviersuarezbaron@gmail.com

mareva@omp.upv.es

maria.lozano@uclm.es

Miguel.Redondo@uclm.es

natalia.padilla@unir.net

aussenac@irit.fr

orevelo@udenar.edu.co

oscarhf2002@hotmail.com

pvtorres@utpl.edu.ec

psantana@unse.edu.ar

fidel@unq.edu.ar

pruiz@unicomfacauca.edu.co

patricia@ugr.es

pascale.zarate@ut-capitole.fr

pgaldames@ubiobio.cl

pdelias@af.ihu.gr

palanque@irit.fr

pierre-emmanuel.arduin@dauphine.psl.eu

ricardo.tesoriero@uclm.es

rcostaguta@hotmail.com

sochoa@dcc.uchile.cl

silvanav.aciar@gmail.com

susana.bautista@ufv.es

wilson.sarmiento@unimilitar.edu.co

yasamin.eslami@ec-nantes.fr

yoslyhernandez@gmail.com
Julio

Julio

Klinge Orlando

Leandro

Leandro

Liliana

Luis Freddy

Luis Mariano

Manuel

Marco Javier

María Del Mar

Maria Dolores

Miguel

Natalia

Nathalie

Oscar

Oscar

Pablo

Pablo

Pablo E.

Pablo Hernando

Patricia

Pascale

Patricio

Pavlos

Philippe

Pierre-mmanuel

Ricardo

Rosanna

Sergio

Silvana

Susana

Wilson Javier

Yasamin

Yosly Caridad

Hurtado

Ponce

Villalba-Condori

Antonelli

Fernandes

Vizzuett

Muñoz Sanabria

Bibbo

Ibarra

Suarez Baron

Alemany-Díaz

Lozano

Redondo

Padilla

Aussenac-Gilles

Revelo Sánchez

Franco

Torres-Carrion

Santana Mansilla

Martínez López

Ruiz Melenje

Paderewski

Zárate

Galdames

Delias

Palanque

Arduin

Tesoriero

Costaguta

Ochoa

Aciar

Bautista

Sarmiento

Eslami

Hernandez

jhurtado@dcc.uchile.cl

julk_cpg@hotmail.com

kvillalbac@unsa.edu.pe

leandro.antonelli@lifia.info.unlp.edu.ar

leandro.fernandes@mackenzie.br

lilianavizz@hotmail.com

lfreddyms@hotmail.com

lmbibbo@lifia.info.unlp.edu.ar

manuelibarra@gmail.com

marcojaviersuarezbaron@gmail.com

mareva@omp.upv.es

maria.lozano@uclm.es

Miguel.Redondo@uclm.es

natalia.padilla@unir.net

aussenac@irit.fr

orevelo@udenar.edu.co

oscarhf2002@hotmail.com

pvtorres@utpl.edu.ec

psantana@unse.edu.ar

fidel@unq.edu.ar

pruiz@unicomfacauca.edu.co

patricia@ugr.es

pascale.zarate@ut-capitole.fr

pgaldames@ubiobio.cl

pdelias@af.ihu.gr

palanque@irit.fr

pierre-emmanuel.arduin@dauphine.psl.eu

ricardo.tesoriero@uclm.es

rcostaguta@hotmail.com

sochoa@dcc.uchile.cl

silvanav.aciar@gmail.com

susana.bautista@ufv.es

wilson.sarmiento@unimilitar.edu.co

yasamin.eslami@ec-nantes.fr

yoslyhernandez@gmail.com
<figure><img src="image_9.png" /></figure>
<figure><img src="image_19.png" /></figure>
Contents

SEMIoTICA - Security Scenarios Modeling forIoT-based Agriculture Solutions............12

<table><tr><td>1</td><td>Introduction</td><td>13</td></tr><tr><td>2</td><td>Background</td><td>14</td></tr><tr><td>3</td><td>Related work</td><td>16</td></tr><tr><td>4</td><td>Our approach</td><td>17</td></tr><tr><td>5</td><td>Assessment of the approach</td><td>20</td></tr><tr><td>6</td><td>Prototype of the tool support</td><td>21</td></tr><tr><td>7</td><td>Conclusion</td><td>21</td></tr><tr><td colspan="2">References</td><td>22</td></tr></table>

Application of the Methodological Framework forDesigning Collaborative Systems with Awareness Mechanisms. Case study of the Miski bakery................................................24

<table><tr><td>1</td><td>Introduction</td><td>24</td></tr><tr><td>2</td><td>Conceptual Framework</td><td>27</td></tr><tr><td>3</td><td>Methodological Framework</td><td>28</td></tr><tr><td>4</td><td>Application of the Methodological Framework to design collaborative systems with awareness mechanisms for the Miski bakery</td><td>29</td></tr><tr><td>5</td><td>Discussion of results</td><td>33</td></tr><tr><td>6</td><td>Conclusions and future work</td><td>36</td></tr><tr><td>7</td><td>References</td><td>36</td></tr></table>

A Method to obtain a Knowledge Representation from a NaturalLanguage Specification of the Domain using the Glossary LEL................................................................................38

<table><tr><td>1.</td><td>Introduction</td><td>38</td></tr><tr><td>2.</td><td>Background</td><td>39</td></tr><tr><td>3.</td><td>Related works</td><td>41</td></tr><tr><td>4.</td><td>The proposed approach</td><td>42</td></tr><tr><td>5.</td><td>Tool support</td><td>45</td></tr><tr><td>6.</td><td>Evaluation</td><td>47</td></tr><tr><td>6.</td><td>Conclusions</td><td>47</td></tr><tr><td colspan="2">Acknowledgment</td><td>48</td></tr><tr><td colspan="2">References</td><td>48</td></tr></table>

Quantum Computing meets Software Engineering: a Road Map for Collaborative Research................................................................................50

<table><tr><td>1</td><td>Introduction</td><td>50</td></tr><tr><td>2</td><td>A research road map</td><td>51</td></tr><tr><td>3</td><td>An Iberoamerican Seedbed for Quantum Software Engineering</td><td>53</td></tr><tr><td colspan="2">Acknowledgements</td><td>53</td></tr><tr><td colspan="2">References</td><td>54</td></tr></table>

Biomechanical Analysis of Basketball Free Throw Shooting Technique in Athletes of The Pedagogical and Technological University of Colombia................................................................55

<table><tr><td>1</td><td>Introduction</td><td>55</td></tr><tr><td>2</td><td>Materials and methods</td><td>56</td></tr></table>

Information processing................................................................................................................57

Learning model ................................................................................................................................................57

<table><tr><td>4</td><td>Conclusions</td><td>61</td></tr><tr><td colspan="2">References</td><td>62</td></tr></table>
Contents

SEMIoTICA - Security Scenarios Modeling forIoT-based Agriculture Solutions............12

<table><tr><td>1</td><td>Introduction</td><td>13</td></tr><tr><td>2</td><td>Background</td><td>14</td></tr><tr><td>3</td><td>Related work</td><td>16</td></tr><tr><td>4</td><td>Our approach</td><td>17</td></tr><tr><td>5</td><td>Assessment of the approach</td><td>20</td></tr><tr><td>6</td><td>Prototype of the tool support</td><td>21</td></tr><tr><td>7</td><td>Conclusion</td><td>21</td></tr><tr><td colspan="2">References</td><td>22</td></tr></table>

Application of the Methodological Framework forDesigning Collaborative Systems with Awareness Mechanisms. Case study of the Miski bakery..................................................24

<table><tr><td>1</td><td>Introduction</td><td>24</td></tr><tr><td>2</td><td>Conceptual Framework</td><td>27</td></tr><tr><td>3</td><td>Methodological Framework</td><td>28</td></tr><tr><td>4</td><td>Application of the Methodological Framework to design collaborative systems with awareness mechanisms for the Miski bakery</td><td>29</td></tr><tr><td>5</td><td>Discussion of results</td><td>33</td></tr><tr><td>6</td><td>Conclusions and future work</td><td>36</td></tr><tr><td>7</td><td>References</td><td>36</td></tr></table>

A Method to obtain a Knowledge Representation from a NaturalLanguage Specification of the Domain using the Glossary LEL................................................................................38

<table><tr><td>1.</td><td>Introduction</td><td>38</td></tr><tr><td>2.</td><td>Background</td><td>39</td></tr><tr><td>3.</td><td>Related works</td><td>41</td></tr><tr><td>4.</td><td>The proposed approach</td><td>42</td></tr><tr><td>5.</td><td>Tool support</td><td>45</td></tr><tr><td>6.</td><td>Evaluation</td><td>47</td></tr><tr><td>6.</td><td>Conclusions</td><td>47</td></tr><tr><td colspan="2">Acknowledgment</td><td>48</td></tr><tr><td colspan="2">References</td><td>48</td></tr></table>

Quantum Computing meets Software Engineering: a Road Map for Collaborative Research................................................................................50

<table><tr><td>1</td><td>Introduction</td><td>50</td></tr><tr><td>2</td><td>A research road map</td><td>51</td></tr><tr><td>3</td><td>An Iberoamerican Seedbed for Quantum Software Engineering</td><td>53</td></tr><tr><td colspan="2">Acknowledgements</td><td>53</td></tr><tr><td colspan="2">References</td><td>54</td></tr></table>

Biomechanical Analysis of Basketball Free Throw Shooting Technique in Athletes of The Pedagogical and Technological University of Colombia ..................................................55

<table><tr><td>1</td><td>Introduction</td><td>55</td></tr><tr><td>2</td><td>Materials and methods</td><td>56</td></tr></table>

Information processing..................................................................................................................57

Learning model ..................................................................................................................................................57

<table><tr><td>4</td><td>Conclusions</td><td>61</td></tr><tr><td colspan="2">References</td><td>62</td></tr></table>
A Bayesian Approach to Duplicate Detection for Real Estate Listings 63

<table><tr><td>1</td><td>Introduction</td><td>63</td></tr><tr><td>2</td><td>Related Work</td><td>64</td></tr><tr><td>3</td><td>Problem Definition</td><td>65</td></tr><tr><td>4</td><td>Knowledge Graph</td><td>66</td></tr><tr><td>5</td><td>Metrics</td><td>68</td></tr><tr><td>6</td><td>Bayesian Approach</td><td>68</td></tr><tr><td>7</td><td>Evaluation</td><td>71</td></tr><tr><td>8</td><td>Conclusions and Future Work</td><td>72</td></tr><tr><td></td><td>References</td><td>73</td></tr></table>

Identification of Collaboration issues during the adoption of Scrum in Software development teams 74

<table><tr><td>1</td><td>Introduction</td><td>74</td></tr><tr><td>2</td><td>Background</td><td>75</td></tr><tr><td>3</td><td>Qualitative Study on the collaborative aspects taken into account by development teams during Scrum adoption</td><td>76</td></tr><tr><td>4</td><td>Conclusions and future work</td><td>81</td></tr><tr><td></td><td>References</td><td>83</td></tr></table>

A literature review to enabling strategic decision support systems for crisis management 84

<table><tr><td>1</td><td>Introduction</td><td>84</td></tr><tr><td>2</td><td>Research Methodology</td><td>85</td></tr><tr><td>3</td><td>Strategic Decision Support Systems</td><td>86</td></tr><tr><td>4</td><td>Discussion</td><td>86</td></tr><tr><td>5</td><td>Conclusion</td><td>87</td></tr><tr><td></td><td>References</td><td>87</td></tr></table>

Rayuela: a pluggable adaptive gamification approach for CLCS 90

<table><tr><td>1</td><td>Introduction</td><td>90</td></tr><tr><td>2</td><td>Approach</td><td>2</td></tr><tr><td>3</td><td>Conclusion and Future work</td><td>6</td></tr><tr><td></td><td>Acknowledgements</td><td>6</td></tr><tr><td></td><td>References</td><td>7</td></tr></table>

Named Entity Extraction in Requirement Specification: A Comparison 4

<table><tr><td>1</td><td>Introduction</td><td>4</td></tr><tr><td>2</td><td>Related Work</td><td>5</td></tr><tr><td>3</td><td>Evaluation Method</td><td>5</td></tr><tr><td>4</td><td>Results</td><td>6</td></tr><tr><td>5</td><td>Conclusions</td><td>7</td></tr><tr><td></td><td>References</td><td>9</td></tr></table>

1 Introduction 11

2 Bibliographic Review 12

3 Methodology 13

3.1 Description of the Data Set 13

3.2 Data Preparation 13

3.3 Random Forest Spatial Interpolation 13

3.4 Accuracy Evaluation 13

4 Final Considerations 14

References 14
A Bayesian Approach to Duplicate Detection for Real Estate Listings 63

<table><tr><td>1</td><td>Introduction</td><td>63</td></tr><tr><td>2</td><td>Related Work</td><td>64</td></tr><tr><td>3</td><td>Problem Definition</td><td>65</td></tr><tr><td>4</td><td>Knowledge Graph</td><td>66</td></tr><tr><td>5</td><td>Metrics</td><td>68</td></tr><tr><td>6</td><td>Bayesian Approach</td><td>68</td></tr><tr><td>7</td><td>Evaluation</td><td>71</td></tr><tr><td>8</td><td>Conclusions and Future Work</td><td>72</td></tr><tr><td></td><td>References</td><td>73</td></tr></table>

Identification of Collaboration issues during the adoption of Scrum in Software development teams 74

<table><tr><td>1</td><td>Introduction</td><td>74</td></tr><tr><td>2</td><td>Background</td><td>75</td></tr><tr><td>3</td><td>Qualitative Study on the collaborative aspects taken into account by development teams during Scrum adoption</td><td>76</td></tr><tr><td>4</td><td>Conclusions and future work</td><td>81</td></tr><tr><td></td><td>References</td><td>83</td></tr></table>

A literature review to enabling strategic decision support systems for crisis management 84

<table><tr><td>1</td><td>Introduction</td><td>84</td></tr><tr><td>2</td><td>Research Methodology</td><td>85</td></tr><tr><td>3</td><td>Strategic Decision Support Systems</td><td>86</td></tr><tr><td>4</td><td>Discussion</td><td>86</td></tr><tr><td>5</td><td>Conclusion</td><td>87</td></tr><tr><td></td><td>References</td><td>87</td></tr></table>

Rayuela: a pluggable adaptive gamification approach for CLCS 90

<table><tr><td>1</td><td>Introduction</td><td>90</td></tr><tr><td>2</td><td>Approach</td><td>2</td></tr><tr><td>3</td><td>Conclusion and Future work</td><td>6</td></tr><tr><td></td><td>Acknowledgements</td><td>6</td></tr><tr><td></td><td>References</td><td>7</td></tr></table>

Named Entity Extraction in Requirement Specification: A Comparison 4

<table><tr><td>1</td><td>Introduction</td><td>4</td></tr><tr><td>2</td><td>Related Work</td><td>5</td></tr><tr><td>3</td><td>Evaluation Method</td><td>5</td></tr><tr><td>4</td><td>Results</td><td>6</td></tr><tr><td>5</td><td>Conclusions</td><td>7</td></tr><tr><td></td><td>References</td><td>9</td></tr></table>

1 Introduction 11

2 Bibliographic Review 12

3 Methodology 13

<table><tr><td>3.1</td><td>Description of the Data Set</td><td>13</td></tr><tr><td>3.2</td><td>Data Preparation</td><td>13</td></tr><tr><td>3.3</td><td>Random Forest Spatial Interpolation</td><td>13</td></tr><tr><td>3.4</td><td>Accuracy Evaluation</td><td>13</td></tr></table>

4 Final Considerations 14

References 14
## Multidimensional Energy Analysis in Agricultural Coffee Production

### Systems to Assess Sustainability..................................................................................................................15

1 Introduction..................................................................................................................................................................................15

2 Methodology..................................................................................................................................................................................16

3 Results and Discussion..................................................................................................................................................................17

4 Conclusions..................................................................................................................................................................................20

References..................................................................................................................................................................................................................21

## Un sistema de recomendación para la reutilización de fármacos utilizando embeddings

### sobre Grafos de Conocimiento..................................................................................................................26

1 Introducción..................................................................................................................................................................................26

2 Trabajos Relacionados ..................................................................................................................................................2

3 Problemática..................................................................................................................................................................................2

4 Contexto..................................................................................................................................................................................2

5 Propuesta..................................................................................................................................................................................3

6 Conclusión..................................................................................................................................................................................3

References..................................................................................................................................................................................................................4

## Collaborative Framework for the Implementation of Digital Transformation Processes in

### Higher Education..................................................................................................................................................4

1 Introduction..................................................................................................................................................................................4

2 State of the art..................................................................................................................................................................................4

3 Problem statement and contributions ..................................................................................................................................5

4 Methodology and research approach..................................................................................................................................5

5 Evaluation plan ..................................................................................................................................................................................5

6 Preliminary or intermediate results........................................................................................................................................5

7 Conclusions and Lessons Learned........................................................................................................................................5

8 Doctor. Stage: Early........................................................................................................................................................................5
## Multidimensional Energy Analysis in Agricultural Coffee Production

### Systems to Assess Sustainability..................................................................................................................15

1. Introduction..................................................................................................................................................................................15

2. Methodology..................................................................................................................................................................................16

3. Results and Discussion..................................................................................................................................................................17

4. Conclusions..................................................................................................................................................................................20

References..................................................................................................................................................................................................................21

## Un sistema de recomendación para la reutilización de fármacos utilizando embeddings

### sobre Grafos de Conocimiento..................................................................................................................26

1. Introducción..................................................................................................................................................................................26

2. Trabajos Relacionados..................................................................................................................................................2

3. Problemática..................................................................................................................................................................................2

4. Contexto..................................................................................................................................................................................2

5. Propuesta..................................................................................................................................................................................3

6. Conclusión..................................................................................................................................................................................3

References..................................................................................................................................................................................................................4

## Collaborative Framework for the Implementation of Digital Transformation Processes in

### Higher Education..................................................................................................................................................4

1. Introduction..................................................................................................................................................................................4

2. State of the art..................................................................................................................................................................................4

3. Problem statement and contributions ..................................................................................................................................5

4. Methodology and research approach..................................................................................................................................5

5. Evaluation plan..................................................................................................................................................................................5

6. Preliminary or intermediate results........................................................................................................................................5

7. Conclusions and Lessons Learned........................................................................................................................................5

8. Doctor. Stage: Early........................................................................................................................................................................5
SEMIoTICA - Security Scenarios Modeling
forIoT-based Agriculture Solutions

Julio Ariel Hurtado¹, Leandro Antonelli², Santiago López¹, Adriana Gómez³, Juliana Delle Ville², Frey Giovanny Zambrano¹, Andrés Solis¹,⁴, Marta Cecilia Camacho⁵, Miguel Solinas⁶, Gladys Kaplan⁷, and Freddy Muñoz⁸

¹ IDIS, Universidad del Cauca, Colombia

{ahurtado, santiagolopez94, freyzambrano, afsolis}@unicauca.edu.co.edu.co

² Lifia - Facultad de Informática, Universidad Nacional de La Plata, Argentina
{lanto, jdelleville} @lifia.info.unlp.edu.ar

³ universidad Tecnológica de Pereira, Colombia
adrianagomezr@utp.edu.co

⁴ Corporacion Universitaria Comfacauca, Colombia

⁵ Institución Universitaria Colegio Mayor del Cauca, Colombia
cecamacho@unimayor.edu.co

⁶ LARYC, FCEFyN, Universidad Nacional de Cordoba, Argentina
miguel.solinas@unc.edu.ar

⁷ Universidad Nacional de La Matanza, Argentina
gladyskaplan@gmail.com

⁸ Fundacion Universitaria de Popayan, Colombia
lfreddyms@gmail.com

**Abstract.** Agriculture is a vital human activity contributing to sustain- able development. A few decades ago, the agricultural sector introduced the Internet of Things (IoT), playing a relevant role in precision and smart farming. IoT developments in farms require a lot of connected devices working cooperatively. It increases the vulnerability of IoT de- vices mostly because it lacks the necessary built-in security due to their constrained context and computational capacity. Additionally, storage and data processing connecting with edge or cloud servers are the rea- son for many security threats. To ensure that IoT-based solutions meet functional and non-functional requirements, particularly security, soft- ware companies should adopt a security-focused approach to their spec- ification. This paper proposes a method for specifying security scenarios integrating requirements and architecture viewpoints in the context of the IoT in agriculture solutions. The method comprises four activities. First, the description of scenarios for the intended software. After that, scenarios with incorrect system use should be described. Then, these are translated into security scenarios using a set of rules. Finally, the security scenarios are improved. Additionally, this paper describes a preliminary validation of the approach, which software engineers in Argentina and Colombia performed. The results show that the approach proposed al- lows software engineers to define and analyze security scenarios in the IoT and agriculture contexts with good results.

**Keywords:** IoT · Quality Scenario · IoT Requirements · Smart Farming Industry 4.0
SEMIoTICA - Security Scenarios Modeling
forIoT-based Agriculture Solutions

Julio Ariel Hurtado¹, Leandro Antonelli², Santiago López¹, Adriana Gómez³, Juliana Delle Ville², Frey Giovanny Zambrano¹, Andrés Solis¹,⁴, Marta Cecilia Camacho⁵, Miguel Solinas⁶, Gladys Kaplan⁷, and Freddy Muñoz⁸

¹ IDIS, Universidad del Cauca, Colombia

{ahurtado, santiagolopez94, freyzambrano, afsolis}@unicauca.edu.co.edu.co

² Lifia - Facultad de Informática, Universidad Nacional de La Plata, Argentina
{lanto, jdelleville} @lifia.info.unlp.edu.ar

³ universidad Tecnológica de Pereira, Colombia
adrianagomezr@utp.edu.co

⁴ Corporacion Universitaria Comfacauca, Colombia

⁵ Institución Universitaria Colegio Mayor del Cauca, Colombia
cecamacho@unimayor.edu.co

⁶ LARYC, FCEFyN, Universidad Nacional de Cordoba, Argentina
miguel.solinas@unc.edu.ar

⁷ Universidad Nacional de La Matanza, Argentina
gladyskaplan@gmail.com

⁸ Fundacion Universitaria de Popayan, Colombia
lfreddyms@gmail.com

**Abstract.** Agriculture is a vital human activity contributing to sustain- able development. A few decades ago, the agricultural sector introduced the Internet of Things (IoT), playing a relevant role in precision and smart farming. IoT developments in farms require a lot of connected devices working cooperatively. It increases the vulnerability of IoT de- vices mostly because it lacks the necessary built-in security due to their constrained context and computational capacity. Additionally, storage and data processing connecting with edge or cloud servers are the rea- son for many security threats. To ensure that IoT-based solutions meet functional and non-functional requirements, particularly security, soft- ware companies should adopt a security-focused approach to their spec- ification. This paper proposes a method for specifying security scenarios integrating requirements and architecture viewpoints in the context of the IoT in agriculture solutions. The method comprises four activities. First, the description of scenarios for the intended software. After that, scenarios with incorrect system use should be described. Then, these are translated into security scenarios using a set of rules. Finally, the security scenarios are improved. Additionally, this paper describes a preliminary validation of the approach, which software engineers in Argentina and Colombia performed. The results show that the approach proposed al- lows software engineers to define and analyze security scenarios in the IoT and agriculture contexts with good results.

**Keywords:** IoT · Quality Scenario · IoT Requirements · Smart Farming Industry 4.0
# 1 Introduction

The International Telecommunication Union (ITU) defines IoT (Internet of the Things) as a "global infrastructure for the information society that provides advanced services through the connection of objects (physical and virtual) relying on the interoperability of current and future knowledge and communication tech-nologies" [31]. According to [17] as an interconnected network, IoT contributes to making decisions based on the information collected, and its interaction does not need human intervention. The definition includes the concept of a Cyber- Physical system, which is a complex abstraction that requires a conceptual map [5] rather than a simple definition to state its concept.

Regarding software development, requirements analysis is a critical activity for defining software functionalities, attributes, and quality properties. This process is particularly different for software construction by using emergent tech-nologies like IoT. Traditional software development practices must adapt to these new technologies and business contexts [17]. Requirements engineering involves collaboration between clients and development teams for incorporating the right features into the finished product [27]. Inconsistencies between initial requirements and the final product can lead to re-engineering processes, increasing the project scope and cost [26]. Requirements engineering works with both types of knowledge, explicit and tacit [1]. Tacit knowledge is difficult to communicate because experts and development teams often have different backgrounds and use distinct terminologies [20], making it challenging to elicit information from stakeholders.

Software products are defined by a set of functional and non-functional requirements. The latter is responsible for the software product's quality and is most frequently considered when developing an IoT system according to its specific application domain [17]. A way to specify software requirements is to describe use scenarios through storytelling techniques. This approach is effective because it is a way to incorporate details that are essential to provide a rich consolidation of knowledge. Scenarios employ natural language, allowing experts to use them without complex formalisms. This makes them highly effective in promoting communication and collaboration among diverse groups of experts [3].

The main challenges associated with these requirements in developing these products are limited processing and storage capacity, performance reliability, availability, accessibility, interoperability, security, privacy, scalability flexibility, and context awareness [17, 19]. Following this reasoning, security is an aspect that is highly relevant in IoT-based software because it protects resources such as modules, code, and others from unauthorized access [19]. With scenarios, experts can describe various situations and work together to improve them, learning from one another in the process. This can be especially valuable when dealing with complex problems that require inputs from multiple perspectives. Overall, scenarios can be a powerful tool for fostering cooperation and achieving better outcomes in a wide range of domains.

The software architect must consider designing the whole system when stakeholders identify security concerns rather than adding security technologies in an ad-hoc manner [15]. As Bruce Schneier points out [25], security is a process and a chain that is only as strong as its weakest link. Therefore, software providers must adopt a security-centric approach to designing and developing IoT-based solutions that conform to functional and non-functional requirements like security [14].

The agricultural sector now requires data collection and advanced technologies to improve production while using limited resources. Sustainable agriculture can help preserve nature without compromising the needs of future generations [6, 13]. The Food and Agriculture Organization (FAO) has identified population growth, resource scarcity, and degradation as key challenges. There is a need to increase efficiency, productivity, and quality in agrifood systems while protecting the environment [24]. To achieve this, new developments and technologies must be introduced to automate traditional farming
# 1 Introduction

The International Telecommunication Union (ITU) defines IoT (Internet of the Things) as a "global infrastructure for the information society that provides advanced services through the connection of objects (physical and virtual) relying on the interoperability of current and future knowledge and communication tech-nologies" [31]. According to [17] as an interconnected network, IoT contributes to making decisions based on the information collected, and its interaction does not need human intervention. The definition includes the concept of a Cyber- Physical system, which is a complex abstraction that requires a conceptual map [5] rather than a simple definition to state its concept.

Regarding software development, requirements analysis is a critical activity for defining software functionalities, attributes, and quality properties. This process is particularly different for software construction by using emergent tech-nologies like IoT. Traditional software development practices must adapt to these new technologies and business contexts [17]. Requirements engineering involves collaboration between clients and development teams for incorporating the right features into the finished product [27]. Inconsistencies between initial requirements and the final product can lead to re-engineering processes, increasing the project scope and cost [26]. Requirements engineering works with both types of knowledge, explicit and tacit [1]. Tacit knowledge is difficult to communicate because experts and development teams often have different backgrounds and use distinct terminologies [20], making it challenging to elicit information from stakeholders.

Software products are defined by a set of functional and non-functional requirements. The latter is responsible for the software product's quality and is most frequently considered when developing an IoT system according to its specific application domain [17]. A way to specify software requirements is to describe use scenarios through storytelling techniques. This approach is effective because it is a way to incorporate details that are essential to provide a rich consolidation of knowledge. Scenarios employ natural language, allowing experts to use them without complex formalisms. This makes them highly effective in promoting communication and collaboration among diverse groups of experts [3].

The main challenges associated with these requirements in developing these products are limited processing and storage capacity, performance reliability, availability, accessibility, interoperability, security, privacy, scalability flexibility, and context awareness [17, 19]. Following this reasoning, security is an aspect that is highly relevant in IoT-based software because it protects resources such as modules, code, and others from unauthorized access [19]. With scenarios, experts can describe various situations and work together to improve them, learning from one another in the process. This can be especially valuable when dealing with complex problems that require inputs from multiple perspectives. Overall, scenarios can be a powerful tool for fostering cooperation and achieving better outcomes in a wide range of domains.

The software architect must consider designing the whole system when stakeholders identify security concerns rather than adding security technologies in an ad-hoc manner [15]. As Bruce Schneier points out [25], security is a process and a chain that is only as strong as its weakest link. Therefore, software providers must adopt a security-centric approach to designing and developing IoT-based solutions that conform to functional and non-functional requirements like security [14].

The agricultural sector now requires data collection and advanced technologies to improve production while using limited resources. Sustainable agriculture can help preserve nature without compromising the needs of future generations [6, 13]. The Food and Agriculture Organization (FAO) has identified population growth, resource scarcity, and degradation as key challenges. There is a need to increase efficiency, productivity, and quality in agrifood systems while protecting the environment [24]. To achieve this, new developments and technologies must be introduced to automate traditional farming
methods and make farm labormore efficient. The Internet of Things (IoT) appears as technology to transform conventional processes [6, 13].

IoT systems encounter distinct security challenges when compared to traditional IT systems primarily due to the presence of resource-constrained devices. These limitations make IoT systems more susceptible to a wide range of attack vectors, posing potential threats to their security [7]. Therefore, accurately identifying and understanding the specific security requirements is crucial when developing such systems.

This paper proposes a scenario-based method for specifying the architecture's security aspects. The method is composed of four essential activities. The first activity consists in describing scenarios of the intended software application. The second activity consists in describing scenarios related to the previous ones but referring to incorrect usage of the application. The third activity consists in applying a set of rules to map attributes from the previous scenario to the architecture scenarios. Finally, the fourth activity consists in describing the architectural scenarios in more detail. Moreover, this document describes a preliminary evaluation of the proposed approach. Given the security challenges facing IoT agriculture, the research question in this paper is: how adequately elicit security requirements in IoT-based smart agriculture solutions?

The paper is organized in the following way. Section 2 describes some background about the scenarios. Then, section 3 describes some related work. Section 4 details our contribution, which is the proposed approach. Section 5 describes the tool to support the proposed method. Section 6 presents the preliminary evaluation. Finally, Section 7 discusses some conclusions.

## 2 Background

This section describes two types of scenarios. First, it describes scenarios that focus on the functionality of a software application. Afterward, the section describes scenarios that focus on architectural security concerns.

### 2.1 Scenarios for describing functionality

A scenario [3] is an artifact that describes situations (in the application or the software domain) using natural language. It describes a specific situation that arises in a certain context to achieve some goal. There is a set of steps (the episodes) to reach that goal. In the episodes, active agents as actors use materials, tools, and data as resources to perform some specific action. Although there are many templates to describe scenarios, this paper will use the scenarios proposed by Leite et al. [21]. Figure 1 summarizes the template.

<figure><img src="image_10.png" /><figcaption>Fig. 1. Template for describing scenarios that focus on functionality.</figcaption></figure>

Let's consider the following example that describes a scenario about how the irrigation system is activated. This task can be done in different ways regarding the technological infrastructure that the farm has. For example, an operator can manually start the irrigation by physically accessing the
methods and make farm labormore efficient. The Internet of Things (IoT) appears as technology to transform conventional processes [6, 13].

IoT systems encounter distinct security challenges when compared to traditional IT systems primarily due to the presence of resource-constrained devices. These limitations make IoT systems more susceptible to a wide range of attack vectors, posing potential threats to their security [7]. Therefore, accurately identifying and understanding the specific security requirements is crucial when developing such systems.

This paper proposes a scenario-based method for specifying the architecture's security aspects. The method is composed of four essential activities. The first activity consists in describing scenarios of the intended software application. The second activity consists in describing scenarios related to the previous ones but referring to incorrect usage of the application. The third activity consists in applying a set of rules to map attributes from the previous scenario to the architecture scenarios. Finally, the fourth activity consists in describing the architectural scenarios in more detail. Moreover, this document describes a preliminary evaluation of the proposed approach. Given the security challenges facing IoT agriculture, the research question in this paper is: how adequately elicit security requirements in IoT-based smart agriculture solutions?

The paper is organized in the following way. Section 2 describes some background about the scenarios. Then, section 3 describes some related work. Section 4 details our contribution, which is the proposed approach. Section 5 describes the tool to support the proposed method. Section 6 presents the preliminary evaluation. Finally, Section 7 discusses some conclusions.

## 2 Background

This section describes two types of scenarios. First, it describes scenarios that focus on the functionality of a software application. Afterward, the section describes scenarios that focus on architectural security concerns.

### 2.1 Scenarios for describing functionality

A scenario [3] is an artifact that describes situations (in the application or the software domain) using natural language. It describes a specific situation that arises in a certain context to achieve some goal. There is a set of steps (the episodes) to reach that goal. In the episodes, active agents as actors use materials, tools, and data as resources to perform some specific action. Although there are many templates to describe scenarios, this paper will use the scenarios proposed by Leite et al. [21]. Figure 1 summarizes the template.

<figure><img src="image_20.png" /><figcaption>Fig. 1. Template for describing scenarios that focus on functionality.</figcaption></figure>

Let's consider the following example that describes a scenario about how the irrigation system is activated. This task can be done in different ways regarding the technological infrastructure that the farm has. For example, an operator can manually start the irrigation by physically accessing the
machine room with the pumps. In this situation, there is no IoT software application. This paper is going to focus on another scenario where a software application performs the activation of the pumps. For example, an agriculture expert evaluates the field conditions to determine whether irrigating is necessary and provides the information to the farm supervisor. Then, the supervisor activates the irrigation pipe through an IoT-based web application. Table 2 summarizes the situation.

<table><caption>Fig. 2. Authorized attempt to start the irrigation system.</caption><thead><tr><th>Attribute</th><th>Scenario title</th><th>Goal</th><th>Context</th><th>Actors</th><th>Resources</th><th>Episodes</th></tr></thead><tbody><tr><td>Description</td><td>Attempt to access the water irrigation infrastructure by an authorized person.</td><td>Protect access to the water irrigation system to ensure responsible use of the water.</td><td>The field counts with an irrigation infrastructure (pipes, tanks, pumps, and valves) to water (irrigate) the field.</td><td>Expert Supervisor</td><td>The checklist to determine whether it is necessary to irrigate the field. The security protocol to access and operate the pump and valves.</td><td>An expert evaluates the conditions of the field to determine whether it is necessary to irrigate. The expert writes a report to the supervisor with the recommendation to irrigate. The supervisor logs in to the IoT web application. The supervisor starts the pump and opens the valves.</td></tr></tbody></table>

The previous scenario describes an authorized person's legitimate use of the software application to activate the irrigation system. This scenario could be similar to Use Cases or User Stories [20]. Nevertheless, the software system can be vulnerable to hack attacks, where a malicious user desires to break into the web software application to start the irrigation system just for fun or to destroy the crop. This incorrect and harmful description of the software application is related to misuse cases [12].

## 2.2 Scenarios for describing architectural security concerns

Software architecture is the designing process of the system's fundamental structure and organization to achieve specific quality attributes, which are the critical non-functional characteristics determining the system's overall effectiveness. Quality attributes are specified through quality scenarios, which define how the system should behave under various conditions. A Quality Attribute (QA) Scenario is a specific, testable scenario that demonstrates how a quality attribute requirement is satisfied. A QA scenario is typically structured with an id, a stimulus that triggers the interaction with the software application, the environment where the interaction occurs, the artifact affected, the response, and some quantitative description of the response. Table 3 summarizes the template.

<table><caption>Fig. 3. Security scenario template.</caption><thead><tr><th>Attribute</th><th>Scenario id</th><th>Source of the stimulus</th><th>Stimulus</th><th>Environment</th><th>Artifact</th><th>Response</th><th>Response measure</th></tr></thead><tbody><tr><td>Description</td><td>Unique identification of the scenario</td><td>Some human, system, or any other actor generates a stimulus to the system.</td><td>It is an input condition that generates a response from the system</td><td>The stimulus occurs under a certain context. The system may have an overload context, normal operation, or some other relevant state. For many systems, "normal" operation can refer to one of a number of modes. For these kinds of systems, the environment should specify in which mode the system is executing</td><td>The stimulated artifact. This may be an ecosystem, a whole system, a component, or some set of components.</td><td>It is the response as the result of the arrival of the stimulus.</td><td>The response should be measurable so that the requirement can be tested.</td></tr></tbody></table>
machine room with the pumps. In this situation, there is no IoT software application. This paper is going to focus on another scenario where a software application performs the activation of the pumps. For example, an agriculture expert evaluates the field conditions to determine whether irrigating is necessary and provides the information to the farm supervisor. Then, the supervisor activates the irrigation pipeline through an IoT-based web application. Table 2 summarizes the situation.

<figure><img src="image_21.png" /><figcaption>Fig. 2. Authorized attempt to start the irrigation system.</figcaption></figure>

The previous scenario describes an authorized person's legitimate use of the software application to activate the irrigation system. This scenario could be similar to Use Cases or User Stories [20]. Nevertheless, the software system can be vulnerable to hack attacks, where a malicious user desires to break into the web software application to start the irrigation system just for fun or to destroy the crop. This incorrect and harmful description of the software application is related to misuse cases [12].

## 2.2 Scenarios for describing architectural security concerns

Software architecture is the designing process of the system's fundamental structure and organization to achieve specific quality attributes, which are the critical non-functional characteristics determining the system's overall effectiveness. Quality attributes are specified through quality scenarios, which define how the system should behave under various conditions. A Quality Attribute (QA) Scenario is a specific, testable scenario that demonstrates how a quality attribute requirement is satisfied. A QA scenario is typically structured with an id, a stimulus that triggers the interaction with the software application, the environment where the interaction occurs, the artifact affected, the response, and some quantitative description of the response. Table 3 summarizes the template.

<figure><img src="image_22.png" /><figcaption>Fig. 3. Security scenario template.</figcaption></figure>
Security refers to the system's capability to defend against danger, ensure its safety, and protect system data from unauthorized disclosure, modification, or destruction. Security involves protecting computer systems themselves through technical and administrative safeguards. Additionally, security can refer to the degree to which a particular security policy is enforced with some level of assurance. The three fundamental types of security concerns are confidentiality, integrity, and availability. Confidentiality refers to the protection of data and processes from unauthorized disclosure or access by individuals or entities that are not authorized to access it. Integrity refers to protecting data and processes from unauthorized modification, intentional or accidental. It includes ensuring that data is not tampered with or corrupted during storage, processing, or transmission. And availability refers to the protection of data and processes from denial of service attacks or other forms of disruption that can prevent authorized users from accessing or using them. This includes ensuring that systems are available and responsive when needed and that they can handle high levels of traffic or activity without becoming overloaded or crashing. Figure 4 describes an example of a security scenario that refers to the same situation of the requirement scenario described in Figure 2.

<figure><img src="image_11.png" /><figcaption>Fig. 4. Security scenario example.</figcaption></figure>

## 3 Related work

The complexity of IoT software applications is a concern identified several researchers. Thus, there are some proposals to deal with this complexity. Nguyen et al. [16] propose FRASAD, a model-driven software development framework to manage the complexity of Internet of Things (IoT) applications. Karadu- man et al. [11] is another proposal to deal with the complexity. Their approach includes activities such as requirements development, domain-specific design, verification, simulation, analysis, calibration, deployment, code generation, and execution. Nevertheless, these proposals do not consider security, which is our main concern.

Some other approaches consider the security issue, but it is considered in terms of implementation, while our proposal considers the security in terms of the specification of requirements. Cardenas et al. [2] propose a process and a tool to apply formal methods in Internet of Things (IoT) applications using the Unified Modeling Language (UML). They have developed a plug-in tool to validate UML software models regarding the design of a secure software application. Slovenec et al. [28] present a taxonomy of security requirements to consider them when designing and implementing the software application. El-Gendy et al. [7] propose a security architecture to provide security enabled IoT services, and provide a baseline for security deployment. The architecture solution outlined in this context plays a crucial role in addressing the security requirements of IoT systems. These security requirements are useful components of our security scenarios proposal. By focusing these requirements, we can effectively establish a robust security
Security refers to the system's capability to defend against danger, ensure its safety, and protect system data from unauthorized disclosure, modification, or destruction. Security involves protecting computer systems themselves through technical and administrative safeguards. Additionally, security can refer to the degree to which a particular security policy is enforced with some level of assurance. The three fundamental types of security concerns are confidentiality, integrity, and availability. Confidentiality refers to the protection of data and processes from unauthorized disclosure or access by individuals or entities that are not authorized to access it. Integrity refers to protecting data and processes from unauthorized modification, intentional or accidental. It includes ensuring that data is not tampered with or corrupted during storage, processing, or transmission. And availability refers to the protection of data and processes from denial of service attacks or other forms of disruption that can prevent authorized users from accessing or using them. This includes ensuring that systems are available and responsive when needed and that they can handle high levels of traffic or activity without becoming overloaded or crashing. Figure 4 describes an example of a security scenario that refers to the same situation of the requirements scenario described in Figure 2.

<figure><img src="image_23.png" /><figcaption>Fig. 4. Security scenario example.</figcaption></figure>

## 3 Related work

The complexity of IoT software applications is a concern identified several researchers. Thus, there are some proposals to deal with this complexity. Nguyen et al. [16] propose FRASAD, a model-driven software development framework to manage the complexity of Internet of Things (IoT) applications. Karadu- man et al. [11] is another proposal to deal with the complexity. Their approach includes activities such as requirements development, domain-specific design, verification, simulation, analysis, calibration, deployment, code generation, and execution. Nevertheless, these proposals do not consider security, which is our main concern.

Some other approaches consider the security issue, but it is considered in terms of implementation, while our proposal considers the security in terms of the specification of requirements. Cardenas et al. [2] propose a process and a tool to apply formal methods in Internet of Things (IoT) applications using the Unified Modeling Language (UML). They have developed a plug-in tool to validate UML software models regarding the design of a secure software application. Slovenec et al. [28] present a taxonomy of security requirements to consider them when designing and implementing the software application. El-Gendy et al. [7] propose a security architecture to provide security enabled IoT services, and provide a baseline for security deployment. The architecture solution outlined in this context plays a crucial role in addressing the security requirements of IoT systems. These security requirements are useful components of our security scenarios proposal. By focusing these requirements, we can effectively establish a robust security
framework at requirements level. Sotoudeh et al. [29] study aims to establish security requirements for IoT systems, with a focus on enhancing the security of smart home applications. The identified requirements complement our proposal as they introduce a significant vocabulary for expressing security scenarios in the IoT and smart farm context. By incorporating these elicited requirements, we can effectively address the specific security challenges and considerations associated with IoT and smart farm environments.

There are some approaches that consider security in requirements, but they do not emphasize the way to specify security requirements precisely. Iqbal et al. [9] present a literature review about an In-Depth Analysis of IoT Security Requirements, but the work they present does not refer about how to specify them. Özkaya et al. [18] proposal deal with different non-functional requirements: security, scalability, and performance. And they try to balance the different requirements or decide which one to satisfy when there is a conflict. Carvalho et al, [4] also deals with conflicts, but their approach deals with non-functional Requirements.

Finally, Kammuller et al. [10] present an approach to specify security requirements for IoT applications. They combine a framework for requirement elicitation with automated reasoning to provide secure IoT for vulnerable users in healthcare scenarios. They map technical system requirements using high-level logical modeling. Then they perform an attack tree analysis. And finally, a security protocol analysis. Their work pays more attention to the tree analysis to identify the situation, while our approach pays attention to how to describe security requirements precisely.

# 4 Our approach

This section is organized in the following manner: firstly, we provide a description of the general approach, followed by a detailed explanation of each step.

## 4.1 Our approach in a nutshell

Our proposed approach consists of several steps. Firstly, we describe scenarios that outline the intended usage of the software. Next, we create scenarios that describe incorrect usage of the application in an attempt to exploit any vulnerabilities. We then establish rules for converting these scenarios into security scenarios. Lastly, we refine and improve the security scenarios. Figure 5 provides a summary of our approach.

## 4.2 Description of the scenarios with the correct use of the indented software application

This step describes the scenarios that focus on the correct use of the software application regarding security concerns. This step should be executed by a requirements engineer or analyst (or a group of them) that must interact with the

<figure><img src="image_12.png" /><figcaption>Fig. 5. Our approach in a nutshell.</figcaption></figure>
framework at requirements level. Sotoudeh et al. [29] study aims to establish security requirements for IoT systems, with a focus on enhancing the security of smart home applications. The identified requirements complement our proposal as they introduce a significant vocabulary for expressing security scenarios in the IoT and smart farm context. By incorporating these elicited requirements, we can effectively address the specific security challenges and considerations associated with IoT and smart farm environments.

There are some approaches that consider security in requirements, but they do not emphasize the way to specify security requirements precisely. Iqbal et al. [9] present a literature review about an In-Depth Analysis of IoT Security Requirements, but the work they present does not refer about how to specify them. Özkaya et al. [18] proposal deal with different non-functional requirements: security, scalability, and performance. And they try to balance the different requirements or decide which one to satisfy when there is a conflict. Carvalho et al, [4] also deals with conflicts, but their approach deals with non-functional Requirements.

Finally, Kammuller et al. [10] present an approach to specify security requirements for IoT applications. They combine a framework for requirement elicitation with automated reasoning to provide secure IoT for vulnerable users in healthcare scenarios. They map technical system requirements using high-level logical modeling. Then they perform an attack tree analysis. And finally, a security protocol analysis. Their work pays more attention to the tree analysis to identify the situation, while our approach pays attention to how to describe security requirements precisely.

# 4 Our approach

This section is organized in the following manner: firstly, we provide a description of the general approach, followed by a detailed explanation of each step.

## 4.1 Our approach in a nutshell

Our proposed approach consists of several steps. Firstly, we describe scenarios that outline the intended usage of the software. Next, we create scenarios that describe incorrect usage of the application in an attempt to exploit any vulnerabilities. We then establish rules for converting these scenarios into security scenarios. Lastly, we refine and improve the security scenarios. Figure 5 provides a summary of our approach.

## 4.2 Description of the scenarios with the correct use of the indented software application

This step describes the scenarios that focus on the correct use of the software application regarding security concerns. This step should be executed by a requirements engineer or analyst (or a group of them) that must interact with the

<figure><img src="image_24.png" /><figcaption>Fig. 5. Our approach in a nutshell.</figcaption></figure>
Experts of the domain (clients, users, and stakeholders in general) to capture the software application's requirements and specify scenarios. Those should describe the functionality of the intended software, and they should also consider security concerns. That is why the analyst eliciting and defining scenarios should have some background in security non-functional requirements to consider this concern in the specification. The result of this step is a set of scenarios that describes the functionality like the one described in Figure 2.

## 4.3 Description of the scenarios with the incorrect use of the indented software application

This step consists in analyzing the scenarios described in the previous step to find security issues and describing the ones that explode the problems and compromise the security of the software application. Ideally, this step should be done by the same requirement engineer (or group of them) that participated in the previous tasks. They should analyze every scenario in detail, and considering guides like the ones proposed by Gupta et al. [8] and Yazdinejad [32], they must describe scenarios of incorrect use of the software application. Basically, they should describe scenarios that explode possible vulnerabilities.

For example, considering the scenario that describes the correct use of the software application to activate the irrigation system (Figure 2), the requirements engineer can determine that the access to the system (and therefore the access to the activation of the pumps) determine a security breach. Hence, the analyst describes a scenario where an unauthorized person gets access to the software application and, consequently to the irrigation infrastructure). Figure 6 describes the complete scenario.

<figure><img src="image_13.png" /><figcaption>Fig. 6. Unauthorized attempt to start the irrigation system.</figcaption></figure>

## 4.4 Derivation of security scenarios

This step describes a set of rules to map the information contained in a scenario that describes the incorrect use of the intended system to obtain a first draft of a scenario to describe security concerns. It is essential to mention that the scenario with incorrect usage will not provide complete information about the security scenario. The rules proposed will use only four attributes (title, context, actors, and resources), and this information will be used to fill four attributes to the security scenario (stimulus, environment, source of the stimulus, and artifact). Therefore, with this information, the following step can refine the security scenario. Figure 7 summarizes the mapping between attributes of both types of scenarios. Following the example of the scenario that describes the incorrect use of the software application described in Figure 6, the scenario obtained applying the proposed rules is the one described in Figure 8. It is important to mention that this scenario (the resulting from the mapping rules) needs to be refined in the following step, which is why this simple mapped security scenario is still far from the security scenario (like the one described in Figure 4).
Experts of the domain (clients, users, and stakeholders in general) to capture the software application's requirements and specify scenarios. Those should describe the functionality of the intended software, and they should also consider security concerns. That is why the analyst eliciting and defining scenarios should have some background in security non-functional requirements to consider this concern in the specification. The result of this step is a set of scenarios that describes the functionality like the one described in Figure 2.

## 4.3 Description of the scenarios with the incorrect use of the indented software application

This step consists in analyzing the scenarios described in the previous step to find security issues and describing the ones that explode the problems and compromise the security of the software application. Ideally, this step should be done by the same requirement engineer (or group of them) that participated in the previous tasks. They should analyze every scenario in detail, and considering guides like the ones proposed by Gupta et al. [8] and Yazdinejad [32], they must describe scenarios of incorrect use of the software application. Basically, they should describe scenarios that explode possible vulnerabilities.

For example, considering the scenario that describes the correct use of the software application to activate the irrigation system (Figure 2), the requirements engineer can determine that the access to the system (and therefore the access to the activation of the pumps) determine a security breach. Hence, the analyst describes a scenario where an unauthorized person gets access to the software application and, consequently to the irrigation infrastructure). Figure 6 describes the complete scenario.

<figure><img src="image_25.png" /><figcaption>Fig. 6. Unauthorized attempt to start the irrigation system.</figcaption></figure>

## 4.4 Derivation of security scenarios

This step describes a set of rules to map the information contained in a scenario that describes the incorrect use of the intended system to obtain a first draft of a scenario to describe security concerns. It is essential to mention that the scenario with incorrect usage will not provide complete information about the security scenario. The rules proposed will use only four attributes (title, context, actors, and resources), and this information will be used to fill four attributes to the security scenario (stimulus, environment, source of the stimulus, and artifact). Therefore, with this information, the following step can refine the security scenario. Figure 7 summarizes the mapping between attributes of both types of scenarios. Following the example of the scenario that describes the incorrect use of the software application described in Figure 6, the scenario obtained applying the proposed rules is the one described in Figure 8. It is important to mention that this scenario (the resulting from the mapping rules) needs to be refined in the following step, which is why this simple mapped security scenario is still far from the security scenario (like the one described in Figure 4).
<table><caption>Fig. 7. Mapping rules between attributes of the incorrect and security scenarios.</caption><thead><tr><th>The attribute of the incorrect usage scenario</th><th>Title</th><th>Context</th><th>Actors</th><th>Resources</th></tr></thead><tbody><tr><td>Attribute of the security scenario</td><td>Stimulus</td><td>Environment + Source of the stimulus</td><td>Sources of the stimulus</td><td>Artifact</td></tr></tbody></table>

<table><caption>Fig. 8. Mapping rules between attributes of the incorrect and security scenarios.</caption><thead><tr><th>Attribute</th><th>Stimulus</th><th>Environment +<br>Source of stimulus</th><th>Source of<br>stimulus</th><th>Artifact</th></tr></thead><tbody><tr><td>Description</td><td>Attempt to access the water irrigation infrastructure by an unauthorized person.</td><td>The field counts with an irrigation infrastructure (pipes, tanks, pumps) to water (irrigate) the field. An unauthorized person attempts to manipulate the pump and the valve to irrigate the field.</td><td>Unauthorized person.</td><td>The checklist to determine whether it is necessary or not to irrigate the field. The security protocol to access and operate the pump and valves.</td></tr></tbody></table>

## 4.5 Refinement of the security scenarios

Some adjustments and improvements should be made to the scenarios derived from the mapping rules in the previous step. Some new information should be added, and some information should be rephrased. Consequently, the requirements engineering should use his experience and knowledge to provide further information and paraphrase some others based on the elicitation meeting and his expertise in the field. For example, the identification of the security scenario should be provided. But this is a minor issue since the indication must be an idto identify the scenario inside the software development process, and it is more related to documentation definitions. Afterward, the attributes of stimulus, environment, source of stimulus, and artifact should be rephrased considering the information obtained in the previous step. The attributes environment and source of stimulus mainly captured data from the same attribute in the incorrect usage scenario, so in the security scenario, the information should be split and divided into two attributes. Finally, the attributes response and response measure should be completed. Although the mapping rules do not provide information to meet these attributes, the information provided in the rest of the scenario provides the context necessary so the requirement engineers can describe these two attributes. It is important to mention that the response measure attribute, in particular, should be described with quantitative measures. Therefore, engineering requirements should pay attention to that, although the tool described in the following section provides some support. Figure 9 summarizes the refinements. Then, the scenario described at the beginning of this paper in Figure 4 is an example of the scenario that this approach pursues to obtain.

<figure><img src="image_14.png" /><figcaption>Fig. 9. Refinement to the security scenarios.</figcaption></figure>

Security scenarios in smart farms and IoT require a specific vocabulary for accurately expressing them. There are several concerns taken into account as part of these scenarios as proposed [29]. One such concern is technology-dependent security for IoT devices (artifact), which refers to the security
<table><caption>Fig. 7. Mapping rules between attributes of the incorrect and security scenarios.</caption><thead><tr><th>The attribute of the incorrect usage scenario</th><th>Title</th><th>Context</th><th>Actors</th><th>Resources</th></tr></thead><tbody><tr><td>Attribute of the security scenario</td><td>Stimulus</td><td>Environment + Source of the stimulus</td><td>Sources of the stimulus</td><td>Artifact</td></tr></tbody></table>

<table><caption>Fig. 8. Mapping rules between attributes of the incorrect and security scenarios.</caption><thead><tr><th>Attribute</th><th>Stimulus</th><th>Environment +<br>Source of stimulus</th><th>Source of<br>stimulus</th><th>Artifact</th></tr></thead><tbody><tr><td>Description</td><td>Attempt to access the water irrigation infrastructure by an unauthorized person.</td><td>The field counts with an irrigation infrastructure (pipes, tanks, pumps) to water (irrigate) the field.<br>An unauthorized person attempts to manipulate the pump and the valve to irrigate the field.</td><td>Unauthorized person.</td><td>The checklist to determine whether it is necessary or not to irrigate the field. The security protocol to access and operate the pump and valves.</td></tr></tbody></table>

## 4.5 Refinement of the security scenarios

Some adjustments and improvements should be made to the scenarios derived from the mapping rules in the previous step. Some new information should be added, and some information should be rephrased. Consequently, the requirements engineering should use his experience and knowledge to provide further information and paraphrase some others based on the elicitation meeting and his expertise in the field. For example, the identification of the security scenario should be provided. But this is a minor issue since the indication must be an idto identify the scenario inside the software development process, and it is more related to documentation definitions. Afterward, the attributes of stimulus, environment, source of stimulus, and artifact should be rephrased considering the information obtained in the previous step. The attributes environment and source of stimulus mainly captured data from the same attribute in the incorrect usage scenario, so in the security scenario, the information should be split and divided into two attributes. Finally, the attributes response and response measure should be completed. Although the mapping rules do not provide information to meet these attributes, the information provided in the rest of the scenario provides the context necessary so the requirement engineers can describe these two attributes. It is important to mention that the response measure attribute, in particular, should be described with quantitative measures. Therefore, engineering requirements should pay attention to that, although the tool described in the following section provides some support. Figure 9 summarizes the refinements. Then, the scenario described at the beginning of this paper in Figure 4 is an example of the scenario that this approach pursues to obtain.

<figure><img src="image_26.png" /><figcaption>Fig. 9. Refinement to the security scenarios.</figcaption></figure>

Security scenarios in smart farms and IoT require a specific vocabulary for accurately expressing them. There are several concerns taken into account as part of these scenarios as proposed [29]. One such concern is technology-dependent security for IoT devices (artifact), which refers to the security
measures required in the IoT context (environment). Another important aspect is the authentication of IoT objects and individuals (sources of stimulus) using various mechanismsto prevent or detect attacks (responses). These responses to potential security threats have several limits (response measurement). Requirements engineerscould use this vocabulary as a lexicon and semiotic tool.

# 5 Assessment of the approach

## 5.1 Assessment Design

Our aim is to assess the acceptance of our approach by security experts in the context of IoT-based smart agriculture, using the Technology Acceptance Model (TAM) to guide our evaluation. Specifically, we are interested in understandinghow much our approach is accepted by this target audience. To evaluate the usefulness and ease of use of our approach, we have adopted the well-known and widely used metrics of Perceived Usefulness and Perceived Ease of Use asdefined in Fred D. Davis's work. To this end, we have designed and administered a survey to a group of expert security professionals who are representative of our target audience and possess experience in eliciting security requirements. By administering the survey to a group of expert security professionals who are representative of our target audience and possess experience in eliciting securityrequirements, we will be able to gather valuable feedback and insights. These insights will help us identify areas of strength and weakness in our approach, and ultimately guide improvements that enhance its overall acceptance.

## 5.2 Survey Application and Data Collection

We conducted a survey with a group of five experts in the software and net-working security field. Prior to the survey, we presented our methodology to thegroup and spent approximately 40 minutes discussing and addressing any ques-tions they had. Once we presented our approach, we administered a survey thatincluded 17 closed-ended questions and three open-ended questions. The survey aimed to gather insights from the experts on the easy to use and usefulness per-ception of our method. Most of the experts found the proposed security scenariomethod to be a useful tool for specifying the requirements of agricultural IoT solutions. Half of the experts surveyed agreed that the proposed method simplifies the process of specifying security requirements, resulting in better quality and control of the specification. The experts noted that the proposed method iswell-defined, easy to understand, and flexible, making it ideal for defining sce-narios. Additionally, the evaluation revealed that the majority (over 60 percent)found it to be clear, well-structured, and interactive in its development.

## 5.3 Results and Analysis

While the method was generally perceived as useful and easy to use for devel-oping security scenarios, it was suggested that it needs to be more specific to determine its usefulness in practice. The experts suggested that the method canbe enhanced to include specific aspects of cybersecurity, as well as developmentand implementation elements that are essential to ensuring the security of agri-cultural IoT systems. This would enable a complete specification of the securityrequirements of these systems. Furthermore, it was noted that users need to in-teract with the method to remember its steps. During the evaluation, experts identified some areas for improvement such as incorporating vulnerabilities andrisks commonly found in IoT systems, considering different types of users andadversaries, and taking into account various attack vectors.
measures required in the IoT context (environment). Another important aspect is the authentication of IoT objects and individuals (sources of stimulus) using various mechanismsto prevent or detect attacks (responses). These responses to potential security threats have several limits (response measurement). Requirements engineerscould use this vocabulary as a lexicon and semiotic tool.

# 5 Assessment of the approach

## 5.1 Assessment Design

Our aim is to assess the acceptance of our approach by security experts in the context of IoT-based smart agriculture, using the Technology Acceptance Model (TAM) to guide our evaluation. Specifically, we are interested in understandinghow much our approach is accepted by this target audience. To evaluate the usefulness and ease of use of our approach, we have adopted the well-known and widely used metrics of Perceived Usefulness and Perceived Ease of Use asdefined in Fred D. Davis's work. To this end, we have designed and administered a survey to a group of expert security professionals who are representative of our target audience and possess experience in eliciting security requirements. By administering the survey to a group of expert security professionals who are representative of our target audience and possess experience in eliciting securityrequirements, we will be able to gather valuable feedback and insights. These insights will help us identify areas of strength and weakness in our approach, and ultimately guide improvements that enhance its overall acceptance.

## 5.2 Survey Application and Data Collection

We conducted a survey with a group of five experts in the software and net-working security field. Prior to the survey, we presented our methodology to thegroup and spent approximately 40 minutes discussing and addressing any ques-tions they had. Once we presented our approach, we administered a survey thatincluded 17 closed-ended questions and three open-ended questions. The survey aimed to gather insights from the experts on the easy to use and usefulness per-ception of our method. Most of the experts found the proposed security scenariomethod to be a useful tool for specifying the requirements of agricultural IoT solutions. Half of the experts surveyed agreed that the proposed method simplifies the process of specifying security requirements, resulting in better quality and control of the specification. The experts noted that the proposed method iswell-defined, easy to understand, and flexible, making it ideal for defining sce-narios. Additionally, the evaluation revealed that the majority (over 60 percent)found it to be clear, well-structured, and interactive in its development.

## 5.3 Results and Analysis

While the method was generally perceived as useful and easy to use for devel-oping security scenarios, it was suggested that it needs to be more specific to determine its usefulness in practice. The experts suggested that the method canbe enhanced to include specific aspects of cybersecurity, as well as developmentand implementation elements that are essential to ensuring the security of agri-cultural IoT systems. This would enable a complete specification of the securityrequirements of these systems. Furthermore, it was noted that users need to in-teract with the method to remember its steps. During the evaluation, experts identified some areas for improvement such as incorporating vulnerabilities andrisks commonly found in IoT systems, considering different types of users andadversaries, and taking into account various attack vectors.
By doing so, the proposed method can be further refined to better meet the needs of users and
enhance the security of agricultural IoT systems, particularly adding this information in the lexicon
associated.

## 6 Prototype of the tool support

A software tool was prototyped in order to provide support to the proposed approach. The tool was implemented in Python [22] using libraries such as Spacy [30], an nlp processing library and textblob [23]. This tool consists of a web application, that can be used on desktop computers as well as mobile phones. The application manages different projects and different kinds of artifacts using natural language. Scenarios are one kind of artifact, but the application can be extended easily to manage other artifacts (User Stories, Use Cases, etc.). The prototype provides support for the different activities of the approach. The prototype provides some edition form to allow users to write scenarios of correct and incorrect use of the software application.

The prototype also provides a form to list all the scenarios describing the functionality of the intended software, and by selecting one or more scenarios, the prototype performs the derivation of security scenarios by applying the mapping rules proposed. Then, the security scenarios can be edited in order to improve their description.

The prototype includes some natural language processing tools that make it possible to provide support to assist the requirements engineering to describe the security scenarios. For example, the prototype can verify the use of terms that belong to a glossary. Thus, using Lemmatization and Stemming techniques, the prototype can verify whether certain expressions are used. This is very important in the attributes of response to ensure the use of the correct technique to cope with the issue the scenario is describing. Another feature is the identification of quantitative descriptions. Natural language processing tools make it possible to assess whether this type of expression is present (for example, in the response measure attribute) to be sure that the scenario is correctly written.

## 7 Conclusion

This paper proposed an approach to describing security scenarios to design a robust software architecture considering IoT technology in the agricultural domain. Developers of IoT applications should be concerned about security (and some other non-functional requirements) since the risk of exposing physical artifacts to intruders is considerable. Moreover, it is difficult to identify the threat and design a countermeasure. Generally, these issues are identified when it is too late when some intruder explodes the vulnerability. Therefore, this paper presents a lightweight approach that begins with a description of the functional requirements. The misuse of the application is identified in order to design meaningful measures to deal with it. The paper also described a prototype tool to help apply the proposed approach. Finally, a preliminary assessment was also provided.

The survey applied to five security experts found that the proposed security scenario method is generally useful for specifying agricultural IoT solutions, but needs improvement in certain areas. Experts suggested incorporating specific cybersecurity aspects, vulnerabilities and risks commonly found in IoT systems, and different types of users and adversaries. They also noted the method need to be more specific and interactive for users to remember its steps. The results provide valuable insights for refining and improving the method to meet user needs and enhance security.
By doing so, the proposed method can be further refined to better meet the needs of users and
enhance the security of agricultural IoT systems, particularly adding this information in the lexicon
associated.

## 6 Prototype of the tool support

A software tool was prototyped in order to provide support to the proposed approach. The tool was implemented in Python [22] using libraries such as Spacy [30], an nlp processing library and textblob [23]. This tool consists of a web application, that can be used on desktop computers as well as mobile phones. The application manages different projects and different kinds of artifacts using natural language. Scenarios are one kind of artifact, but the application can be extended easily to manage other artifacts (User Stories, Use Cases, etc.). The prototype provides support for the different activities of the approach. The prototype provides some edition form to allow users to write scenarios of correct and incorrect use of the software application.

The prototype also provides a form to list all the scenarios describing the functionality of the intended software, and by selecting one or more scenarios, the prototype performs the derivation of security scenarios by applying the mapping rules proposed. Then, the security scenarios can be edited in order to improve their description.

The prototype includes some natural language processing tools that make it possible to provide support to assist the requirements engineering to describe the security scenarios. For example, the prototype can verify the use of terms that belong to a glossary. Thus, using Lemmatization and Stemming techniques, the prototype can verify whether certain expressions are used. This is very important in the attributes of response to ensure the use of the correct technique to cope with the issue the scenario is describing. Another feature is the identification of quantitative descriptions. Natural language processing tools make it possible to assess whether this type of expression is present (for example, in the response measure attribute) to be sure that the scenario is correctly written.

## 7 Conclusion

This paper proposed an approach to describing security scenarios to design a robust software architecture considering IoT technology in the agricultural domain. Developers of IoT applications should be concerned about security (and some other non-functional requirements) since the risk of exposing physical artifacts to intruders is considerable. Moreover, it is difficult to identify the threat and design a countermeasure. Generally, these issues are identified when it is too late when some intruder explodes the vulnerability. Therefore, this paper presents a lightweight approach that begins with a description of the functional requirements. The misuse of the application is identified in order to design meaningful measures to deal with it. The paper also described a prototype tool to help apply the proposed approach. Finally, a preliminary assessment was also provided.

The survey applied to five security experts found that the proposed security scenario method is generally useful for specifying agricultural IoT solutions, but needs improvement in certain areas. Experts suggested incorporating specific cybersecurity aspects, vulnerabilities and risks commonly found in IoT systems, and different types of users and adversaries. They also noted the method need to be more specific and interactive for users to remember its steps. The results provide valuable insights for refining and improving the method to meet user needs and enhance security.
Currently, the most widely used development process is agile development, but we propose a complementary and lightweight technique specifically for IoT applications in the smart farm field. As future work, we aim to enrich the proposal with additional guidelines for writing scenarios for each stage. Additionally, fur- ther experimentation is necessary before we make the approach more complex. However, we firmly believe that the approach should be strengthened and made more robust.

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

**References**

1. Ahmed, U.: A review on knowledge management in requirement engineering. IEEE 5 (2018)

2. Cardenas, H., Zimmerman, R., Viesca, A.R., Al Lail, M., Perez, A.J.: Formal uml-based modeling and analysis for securing location-based iot applications. In: 2022 IEEE 19th International Conference on Mobile Ad Hoc and Smart Systems (MASS). pp. 722–723 (2022). https://doi.org/10.1109/MASS56207.2022.00109

3. Carrol, J.: Five reasons for scenario-based design. In: Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences. 1999. HICSS-

4. Abstracts and CD-ROM of Full Papers. vol. Track3, pp. 11 pp.– (1999). https://doi.org/10.1109/HICSS.1999.772890

5. Carvalho, R.M.: Dealing with conflicts between non-functional requirements of ubi-comp and iot applications. In: 2017 IEEE 25th International Requirements Engineering Conference (RE). pp. 544–549 (2017). https://doi.org/10.1109/RE.2017.51

6. CPS2023: Cyber-physical systems. https://ptolemy.berkeley.edu/projects/cps/(2023)

7. Dhanaraju, M., Chenniappan, P., Ramalingam, K., Pazhanivelan, S., Kaliaperu- mal, R.: Smart farming: Internet of things (iot)-based sustainable agriculture. Agri-culture 12(10), 1745 (2022)

8. El-Gendy, S., Azer, M.A.: Security framework for internet of things (iot). In: 2020 15th International Conference on Computer Engineering and Systems (ICCES). pp. 1–6 (2020). https://doi.org/10.1109/ICCES51560.2020.9334589

9. Gupta, M., Abdelsalam, M., Khorsandroo, S., Mittal, S.: Security and privacy in smart farming: Challenges and opportunities. IEEE Access 8, 34564–34584 (2020). https://doi.org/10.1109/ACCESS.2020.2975142

10. Iqbal, W., Abbas, H., Daneshmand, M., Rauf, B., Bangash, Y.A.: An in-depth analysis of iot security requirements, challenges, and their countermeasures via software-defined security. IEEE Internet of Things Journal 7(10), 10250–10276 (2020). https://doi.org/10.1109/JIOT.2020.2997651

11. Kammüller, F., Augusto, J.C., Jones, S.: Security and privacy requirements engineering for human centric iot systems using efriend and is-abelle. In: 2017 IEEE 15th International Conference on Software Engineering Research, Management and Applications (SERA). pp. 401–406 (2017). https://doi.org/10.1109/SERA.2017.7965758

12. Karaduman, B., Mustafiz, S., Challenger, M.: Ftg+pm for the model-driven development of wireless sensor network based iot systems. In: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). pp. 306–316 (2021). https://doi.org/10.1109/MODELS-C53483.2021.00052

13. Khamaiseh, S., Xu, D.: Software security testing via misuse case modeling. In: 2017 IEEE 15th Intl Conf on Dependable, Autonomic and Secure Computing, 15th Intl Conf on Pervasive Intelligence and Computing, 3rd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress (DASC/PiCom/DataCom/CyberSciTech). pp. 534–541 (2017). https://doi.org/10.1109/DASC-PiCom-DataCom-CyberSciTec.2017.98
Currently, the most widely used development process is agile development, but we propose a complementary and lightweight technique specifically for IoT applications in the smart farm field. As future work, we aim to enrich the proposal with additional guidelines for writing scenarios for each stage. Additionally, fur- ther experimentation is necessary before we make the approach more complex. However, we firmly believe that the approach should be strengthened and made more robust.

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

**References**

1. Ahmed, U.: A review on knowledge management in requirement engineering. IEEE 5 (2018)

2. Cardenas, H., Zimmerman, R., Viesca, A.R., Al Lail, M., Perez, A.J.: Formal uml-based modeling and analysis for securing location-based iot applications. In: 2022 IEEE 19th International Conference on Mobile Ad Hoc and Smart Systems (MASS). pp. 722–723 (2022). https://doi.org/10.1109/MASS56207.2022.00109

3. Carrol, J.: Five reasons for scenario-based design. In: Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences. 1999. HICSS-

4. Abstracts and CD-ROM of Full Papers. vol. Track3, pp. 11 pp.– (1999). https://doi.org/10.1109/HICSS.1999.772890

5. Carvalho, R.M.: Dealing with conflicts between non-functional requirements of ubi-comp and iot applications. In: 2017 IEEE 25th International Requirements Engineering Conference (RE). pp. 544–549 (2017). https://doi.org/10.1109/RE.2017.51

6. CPS2023: Cyber-physical systems. https://ptolemy.berkeley.edu/projects/cps/(2023)

7. Dhanaraju, M., Chenniappan, P., Ramalingam, K., Pazhanivelan, S., Kaliaperu- mal, R.: Smart farming: Internet of things (iot)-based sustainable agriculture. Agri-culture 12(10), 1745 (2022)

8. El-Gendy, S., Azer, M.A.: Security framework for internet of things (iot). In: 2020 15th International Conference on Computer Engineering and Systems (ICCES). pp. 1–6 (2020). https://doi.org/10.1109/ICCES51560.2020.9334589

9. Gupta, M., Abdelsalam, M., Khorsandroo, S., Mittal, S.: Security and privacy in smart farming: Challenges and opportunities. IEEE Access 8, 34564–34584 (2020). https://doi.org/10.1109/ACCESS.2020.2975142

10. Iqbal, W., Abbas, H., Daneshmand, M., Rauf, B., Bangash, Y.A.: An in-depth analysis of iot security requirements, challenges, and their countermeasures via software-defined security. IEEE Internet of Things Journal 7(10), 10250–10276 (2020). https://doi.org/10.1109/JIOT.2020.2997651

11. Kammüller, F., Augusto, J.C., Jones, S.: Security and privacy requirements engineering for human centric iot systems using efriend and is-abelle. In: 2017 IEEE 15th International Conference on Software Engineering Research, Management and Applications (SERA). pp. 401–406 (2017). https://doi.org/10.1109/SERA.2017.7965758

12. Karaduman, B., Mustafiz, S., Challenger, M.: Ftg+pm for the model-driven development of wireless sensor network based iot systems. In: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). pp. 306–316 (2021). https://doi.org/10.1109/MODELS-C53483.2021.00052

13. Khamaiseh, S., Xu, D.: Software security testing via misuse case modeling. In: 2017 IEEE 15th Intl Conf on Dependable, Autonomic and Secure Computing, 15th Intl Conf on Pervasive Intelligence and Computing, 3rd Intl Conf on Big Data Intelligence and Computing and Cyber Science and Technology Congress (DASC/PiCom/DataCom/CyberSciTech). pp. 534–541 (2017). https://doi.org/10.1109/DASC-PiCom-DataCom-CyberSciTec.2017.98
14. Khan, N., Ray, R.L., Sargani, G.R., Ihtisham, M., Khayyam, M., Ismail, S.: Current progress and future prospects of agriculture technology: Gateway to sustainable agriculture. Sustainability **13**(9), 4883 (2021)

15. Martin, T., Geneiatakis, D., Kounelis, I., Kerckhof, S., Nai Fovino, I.: Towards a formal iot security model. Symmetry **12**(8) (2020). https://doi.org/10.3390/sym12081305, https://www.mdpi.com/2073-8994/12/8/1305

16. Myagmar, S., Lee, A.J., Yurcik, W.: Threat modeling as a basis for security requirements. In: Symposium on Requirements Engineering for Information Security (SREIS). University of Pittsburgh (August 2005), http://d-scholarship.pitt.edu/16516/

17. Nguyen, X.T., Tran, H.T., Baraki, H., Geihs, K.: Frasad: A framework for model-driven iot application development. In: 2015 IEEE 2nd World Forum on In- ternet of Things (WF-IoT). pp. 387-392 (2015). https://doi.org/10.1109/WF-IoT.2015.7389085

18. Ojo-Gonzalez, K., Bonilla-Morales, B.: Requerimientos no funcionales para sistemas temas basados en el internet de las cosas (iot): Una revisión. I+D Tecnológico **17**(2), 30-40 (2021)

19. Ozkaya, O., Ors, B.: Model based node design methodology for secure iot applications. In: 2018 26th Signal Processing and Communications Applications Conference (SIU). pp. 1-4 (2018). https://doi.org/10.1109/SIU.2018.8404490

20. Pal, S., Hitchens, M., Rabehaja, T., Mukhopadhyay, S.: Security requirements for the internet of things: A systematic approach. Sensors **20**(20), 5897 (2020)

21. Potts, C.: Using schematic scenarios to understand user needs. In: Proceedings of the 1st Conference on Designing Interactive Systems: Processes, Practices, Methods, and Techniques. p. 247-256. DIS '95, Association for Computing Machinery, New York, NY, USA (1995). https://doi.org/10.1145/225434.225462, https://doi.org/10.1145/225434.225462

22. do Prado Leite, J.C.S., Hadad, G.D.S., Doorn, J.H., Kaplan, G.N.: A scenario construction process. Requirements Engineering **5**, 38-61 (2000)

23. Python: Python framework. https://www.python.org/ (2023), accessed: 2023-03-11

24. Python: Textblob library. https://pypi.org/project/textblob/ (2023), accessed: 2023-03-11

25. Rose, D.C., Wheeler, R., Winter, M., Lobley, M., Chivers, C.A.: Agriculture 4.0: Making it work for people, production, and the planet. Land use policy **100**, 104933(2021)

26. Schneier, B.: Cryptography is harder than it looks. IEEE Security & Privacy **14**(1), 87-88 (2016). https://doi.org/10.1109/MSP.2016.7

27. Serna M, E., Serna A, A.: Proceso y progreso de la formalización de requisitos en ingeniería del software. Ingeniare. Revista chilena de ingeniería **28**(3), 411-423 (2020)

28. Shankar, P., Morkos, B., Yadav, D., Summers, J.D.: Towards the formalization of non-functional requirements in conceptual design. Research in engineering design **31**, 449-469 (2020)

29. Slovenec, K., Vuković, M., Salopek, D., Mikuc, M.: Securing iot services based on security requirement categories. In: 2022 International Conference on Software, Telecommunications and Computer Networks (SoftCOM). pp. 1-6 (2022). https://doi.org/10.23919/SoftCOM55329.2022.9911319

30. Sotoudeh, S., Hashemi, S., Garakani, H.G.: Security framework of iot-based smart home. In: 2020 10th International Symposium on Telecommunications (IST). pp. 251-256 (2020). https://doi.org/10.1109/IST50524.2020.9345886

31. Spacy: Spacy library. https://spacy.io/ (2023), accessed: 2023-03-11

31. Y.2060, I.T.: Itu-t y.2060. https://handle.itu.int/11.1002/1000/11559 (2012)

32. Yazdinejad, A., Zolfaghari, B., Azmoodeh, A., Dehghantanha, A., Karimipour, H., Fraser, E.D.G., Green, A.G., Russell, C., Duncan, E.: A review on security of smart farming and precision agriculture: Security aspects, attacks, threats and countermeasures. Applied Sciences (2021)
14. Khan, N., Ray, R.L., Sargani, G.R., Ihtisham, M., Khayyam, M., Ismail, S.: Current progress and future prospects of agriculture technology: Gateway to sustainable agriculture. Sustainability **13**(9), 4883 (2021)

15. Martin, T., Geneiatakis, D., Kounelis, I., Kerckhof, S., Nai Fovino, I.: Towards a formal iot security model. Symmetry **12**(8) (2020). https://doi.org/10.3390/sym12081305, https://www.mdpi.com/2073-8994/12/8/1305

16. Myagmar, S., Lee, A.J., Yurcik, W.: Threat modeling as a basis for se- curity requirements. In: Symposium on Requirements Engineering for Infor- mation Security (SREIS). University of Pittsburgh (August 2005), http://d- scholarship.pitt.edu/16516/

17. Nguyen, X.T., Tran, H.T., Baraki, H., Geihs, K.: Frasad: A framework for model- driven iot application development. In: 2015 IEEE 2nd World Forum on In- ternet of Things (WF-IoT). pp. 387–392 (2015). https://doi.org/10.1109/WF- IoT.2015.7389085

18. Ojo-Gonzalez, K., Bonilla-Morales, B.: Requerimientos no funcionales para sis- temas basados en el internet de las cosas (iot): Una revisión. I+ D Tecnológico **17**(2), 30–40 (2021)

19. Ozkaya, O., Ors, B.: Model based node design methodology for secure iot applica- tions. In: 2018 26th Signal Processing and Communications Applications Confer- ence (SIU). pp. 1–4 (2018). https://doi.org/10.1109/SIU.2018.8404490

20. Pal, S., Hitchens, M., Rabehaja, T., Mukhopadhyay, S.: Security requirements for the internet of things: A systematic approach. Sensors **20**(20), 5897 (2020)

21. Potts, C.: Using schematic scenarios to understand user needs. In: Proceed- ings of the 1st Conference on Designing Interactive Systems: Processes, Prac-tices, Methods, and Techniques. p. 247–256. DIS ’95, Association for Computing Machinery, New York, NY, USA (1995). https://doi.org/10.1145/225434.225462, https://doi.org/10.1145/225434.225462

22. do Prado Leite, J.C.S., Hadad, G.D.S., Doorn, J.H., Kaplan, G.N.: A scenario construction process. Requirements Engineering **5**, 38–61 (2000)

23. Python: Python framework. https://www.python.org/ (2023), accessed: 2023-03-11

24. Python: Textblob library. https://pypi.org/project/textblob/ (2023), accessed: 2023-03-11

25. Rose, D.C., Wheeler, R., Winter, M., Lobley, M., Chivers, C.A.: Agriculture 4.0: Making it work for people, production, and the planet. Land use policy **100**, 104933(2021)

26. Schneier, B.: Cryptography is harder than it looks. IEEE Security & Privacy **14**(1), 87–88 (2016). https://doi.org/10.1109/MSP.2016.7

27. Serna M, E., Serna A, A.: Proceso y progreso de la formalización de requisitosen ingeniería del software. Ingeniare. Revista chilena de ingeniería **28**(3), 411–423(2020)

28. Shankar, P., Morkos, B., Yadav, D., Summers, J.D.: Towards the formalization of non-functional requirements in conceptual design. Research in engineering design **31**, 449–469 (2020)

29. Slovenec, K., Vuković, M., Salopek, D., Mikuc, M.: Securing iot services basedon security requirement categories. In: 2022 International Conference on Soft- ware, Telecommunications and Computer Networks (SoftCOM). pp. 1–6 (2022). https://doi.org/10.23919/SoftCOM55329.2022.9911319

30. Sotoudeh, S., Hashemi, S., Garakani, H.G.: Security framework of iot-based smart home. In: 2020 10th International Symposium onTelecommunications (IST). pp. 251–256 (2020). https://doi.org/10.1109/IST50524.2020.9345886

31. Spacy: Spacy library. https://spacy.io/ (2023), accessed: 2023-03-11

31. Y.2060, I.T.: Itu-t y.2060. https://handle.itu.int/11.1002/1000/11559 (2012)

32. Yazdinejad, A., Zolfaghari, B., Azmoodeh, A., Dehghantanha, A., Karimipour, H., Fraser, E.D.G., Green, A.G., Russell, C., Duncan, E.: A review on securityof smart farming and precision agriculture: Security aspects, attacks, threats and countermeasures. Applied Sciences (2021)
Application of the Methodological Framework for Designing
Collaborative Systems with Awareness Mechanisms. Case study
of the Miski bakery

Arboleda, J.D.¹ César A. Collazos²

¹ Universidad del Cauca, Facultad de Ingeniería Electrónica y Telecomunicaciones. Maestría en Computación. Popayán, Cauca. juanarboleda@unicauca.edu.co

2 Grupo IDIS, Universidad del Cauca, Facultad de Ingeniería Electrónica y Telecomunicaciones. Popayán, Cauca, ccollazo@unicauca.edu.co

**Abstract.** In the commercial processes of companies specialized in the elabora- tion of customized cakes, a negotiation activity is performed with the client to collaboratively create the design of the decoration of the product. Currently, this activity is performed through different digital communication channels, mainly WhatsApp chat and social network chats such as Facebook and Instagram, as these allow the exchange of images, facilitate synchronous or asynchronous com- munication, and a record of the conversations remains in the history. The current dynamics of e-commerce mark a trend oriented to the digital transformation of business processes, which is why the need to design a software tool that facilitates computer-assisted cooperative work has been identified. The objective of this re-search paper is to apply a methodological framework to incorporate Awareness mechanisms to the design of a software that will provide strategic support in the collaborative negotiation process with the purpose of improving communication and shared understanding among the actors of the pastry shop. To achieve the objective, the methodological framework proposed by the Awareness theory is applied for the development of the groupware, which is composed of five stages: Identify the objective of the Awareness information in the process to be inter- vened. Identify the components of the Awareness information in the communi- cation context. Modeling of the software process to achieve an integration of Awareness mechanisms in the business process to be intervened. Design of the information distribution strategy among the actors involved in the process. Creation of the user interface with Awareness mechanisms.

**Keywords:** Awareness, CSCW, Cake Decoration.

# 1 Introduction.

## 1.1 Context.

In Colombia in 2022 it was determined [1] that 80% of Micro, Small and Medium En-terprises (MSMEs) are in a state of digital transformation, which consists mainly in the tactical appropriation of technologies that allow them to be more competitive, improve their productivity levels and better adapt to the dynamics, trends and challenges im- posed by e-commerce.

For the case study, a microenterprise in the city of Popayán called Miski Pastelería was selected. The bakery is currently conducting a diagnosis of the digital status of the business [2] in order to start the process of formulating the digital transformation path, which will allow it to implement technological solutions relevant to its cultural context [3]. An analysis of all the processes involved in the elaboration of a customized cake in the Miski bakery was carried out. To facilitate the interpretation of its context, a modeling of the processes is made in Business Process Modeling Notation (BPMN)[4], which allows to identify graphically and categorically, the beginning (Customer Need), the three macro- processes: Strategic (Commercial), Productive, Support, and the end of the process (customer satisfaction).
Application of the Methodological Framework for Designing
Collaborative Systems with Awareness Mechanisms. Case study
of the Miski bakery

Arboleda, J.D.¹ César A. Collazos²

¹ Universidad del Cauca, Facultad de Ingeniería Electrónica y Telecomunicaciones. Maestría en Computación. Popayán, Cauca. juanarboleda@unicauca.edu.co

² Grupo IDIS, Universidad del Cauca, Facultad de Ingeniería Electrónica y Telecomunicaciones. Popayán, Cauca, ccollazo@unicauca.edu.co

**Abstract.** In the commercial processes of companies specialized in the elabora- tion of customized cakes, a negotiation activity is performed with the client to collaboratively create the design of the decoration of the product. Currently, this activity is performed through different digital communication channels, mainly WhatsApp chat and social network chats such as Facebook and Instagram, as these allow the exchange of images, facilitate synchronous or asynchronous com- munication, and a record of the conversations remains in the history. The current dynamics of e-commerce mark a trend oriented to the digital transformation of business processes, which is why the need to design a software tool that facilitates computer-assisted cooperative work has been identified. The objective of this re-search paper is to apply a methodological framework to incorporate Awareness mechanisms to the design of a software that will provide strategic support in the collaborative negotiation process with the purpose of improving communication and shared understanding among the actors of the pastry shop. To achieve the objective, the methodological framework proposed by the Awareness theory is applied for the development of the groupware, which is composed of five stages: Identify the objective of the Awareness information in the process to be inter- vened. Identify the components of the Awareness information in the communi- cation context. Modeling of the software process to achieve an integration of Awareness mechanisms in the business process to be intervened. Design of the information distribution strategy among the actors involved in the process. Creation of the user interface with Awareness mechanisms.

**Keywords:** Awareness, CSCW, Cake Decoration.

# 1 Introduction.

## 1.1 Context.

In Colombia in 2022 it was determined [1] that 80% of Micro, Small and Medium En-terprises (MSMEs) are in a state of digital transformation, which consists mainly in the tactical appropriation of technologies that allow them to be more competitive, improve their productivity levels and better adapt to the dynamics, trends and challenges im- posed by e-commerce.

For the case study, a microenterprise in the city of Popayán called Miski Pastelería was selected. The bakery is currently conducting a diagnosis of the digital status of the business [2] in order to start the process of formulating the digital transformation path, which will allow it to implement technological solutions relevant to its cultural context [3]. An analysis of all the processes involved in the elaboration of a customized cake in the Miski bakery was carried out. To facilitate the interpretation of its context, a modeling of the processes is made in Business Process Modeling Notation (BPMN)[4], which allows to identify graphically and categorically, the beginning (Customer Need), the three macro- processes: Strategic (Commercial), Productive, Support, and the end of the process (customer satisfaction).
<figure><img src="image_15.png" /><figcaption>Fig. 1. Model of the pastry processes.</figcaption></figure>

## 1.2 Brief description of the pastry processes.

The process starts with the customer's need for the bakery. Regarding the needs of the pastry shop's customers, it was identified that 81% of the customer phenotype corresponds to women, 70% of whom are mothers, and 57% are between 25 and 34 yearsof age. These customers need 60% of the time a birthday cake for children between 0 and 10 years old. The design of a customized cake is the result of a collaborative processbetween the client and different members of the bakery, which is why each product is unique and unrepeatable.

Strategic Processes (Business Processes). This macro-process is composed of four processes: Promotion, Contact, Negotiation and Sale. The Promotion process corresponds to all advertising activities, positioning and visibility in social networks and Internet search engines. In addition, marketing strategy activities (Get, Keep, Grow) are carried out to capture the interest, loyalty and recommendation of the customer ar-chetype described. The contact process is developed through various communication channels, the customer can go directly to the store and talk to the seller or can use digitalmedia when they are geographically dispersed. In the Miski pastry shop 60% of con-tacts are made through the chat of (WhatsApp 40%, Instagram 35%, Facebook 25%), 10% by e-mail, 20% by phone calls, and 10% through the web. The activity carried out by the company in this process is to apply the customer service protocol; which, mainly consists of giving timely response to the quotations made and helping the cus-tomer to make decisions in front of the product. The customer frequently uses images of reference cakes that he/she has previously searched for on the Internet, or that he/shehas seen in the bakery's catalog. The image is a support tool that allows the customer to express his desires, expectations and requirements for the customized product, and satisfies the limitations of natural language representation [5].

In the Negotiation process, a mediation is made between the customer's requirements(imagined cake object of desire), the company's production capacity, and the customer'spurchasing power (what he is willing to pay) this activity is known as quotation. This negotiation is a collaborative process [6], as the customer, the vendor and the pastry chef have a common goal, to design a customized cake decoration for a special event.

The negotiation process ends when a mutual agreement is reached regarding the formal characteristics of the product and its price. It is the duty of the bakery's salespersonto initiate the activities that correspond to the formal survey of the requirements of the customized cake. The requirements gathering is documented through the use of a paperform called an order form. The order form is in charge of storing the customer information (Id, contact...), the product delivery and distribution information (date, time...),and the information of the formal characteristics of the cake (Size, Flavor, Color, Typeof Decoration).
<figure><img src="image_27.png" /><figcaption>Fig. 1. Model of the pastry processes.</figcaption></figure>

## 1.2 Brief description of the pastry processes.

The process starts with the customer's need for the bakery. Regarding the needs of the pastry shop's customers, it was identified that 81% of the customer phenotype corresponds to women, 70% of whom are mothers, and 57% are between 25 and 34 yearsof age. These customers need 60% of the time a birthday cake for children between 0 and 10 years old. The design of a customized cake is the result of a collaborative processbetween the client and different members of the bakery, which is why each product is unique and unrepeatable.

Strategic Processes (Business Processes). This macro-process is composed of four processes: Promotion, Contact, Negotiation and Sale. The Promotion process corresponds to all advertising activities, positioning and visibility in social networks and Internet search engines. In addition, marketing strategy activities (Get, Keep, Grow) are carried out to capture the interest, loyalty and recommendation of the customer ar-chetype described. The contact process is developed through various communication channels, the customer can go directly to the store and talk to the seller or can use digitalmedia when they are geographically dispersed. In the Miski pastry shop 60% of con-tacts are made through the chat of (WhatsApp 40%, Instagram 35%, Facebook 25%), 10% by e-mail, 20% by phone calls, and 10% through the web. The activity carried out by the company in this process is to apply the customer service protocol; which, mainly consists of giving timely response to the quotations made and helping the cus-tomer to make decisions in front of the product. The customer frequently uses images of reference cakes that he/she has previously searched for on the Internet, or that he/shehas seen in the bakery's catalog. The image is a support tool that allows the customer to express his desires, expectations and requirements for the customized product, and satisfies the limitations of natural language representation [5].

In the Negotiation process, a mediation is made between the customer's requirements(imagined cake object of desire), the company's production capacity, and the customer'spurchasing power (what he is willing to pay) this activity is known as quotation. This negotiation is a collaborative process [6], as the customer, the vendor and the pastry chef have a common goal, to design a customized cake decoration for a special event.

The negotiation process ends when a mutual agreement is reached regarding the formal characteristics of the product and its price. It is the duty of the bakery's salespersonto initiate the activities that correspond to the formal survey of the requirements of the customized cake. The requirements gathering is documented through the use of a paperform called an order form. The order form is in charge of storing the customer information (Id, contact...), the product delivery and distribution information (date, time...),and the information of the formal characteristics of the cake (Size, Flavor, Color, Typeof Decoration).
The productive macro-processes correspond to the materialization of the design of the cake product of the negotiation. To carry out this task, seven processes are carried out, categorized as follows: Production Process 1: Good Manufacturing Practices. Pro-ductive Process 2: Preparation of raw materials. Productive Process 3: Baking. Produc-tive Process 4: Decoration. Productive Process 5: Photographic Registration. Produc- tive Process 6: Packaging and storage. Productive Process 7: Distribution. At the end of the productive macro-processes, the project of elaboration of a personalized cake isfinished, thus achieving the satisfaction of the needs of the company's client. To guar- antee the success of the productive macro-processes, there are the support macro-pro- cesses, whose core is composed of administrative processes, accounting management processes, human management processes, and resource management processes.

1.3 Description of the observed problem.

Particularly, ambiguities have been identified in the use of natural language to de- scribe the chromatic characteristics of the cake, for example: "I need it to be blue", the problem is that, with the colorants used in food, more than 50 different shades of blue can be achieved, therefore, there is a high probability that the blue color imagined by the baker is different from the color imagined by the customer. The decoration of a personalized cake obeys the theme of the event, and is loaded with a high symbolic [7]and emotional value [8], the emotional aspects of cake decoration make the client have very high design expectations, which generally imply a high degree of technical diffi- culty for the decorator, which translates into a high selling price of the product, and sometimes customers are not willing to pay such a high value, which is why the cus- tomer with the help of the seller and the pastry chef begin to make more realistic ex- pectations of the product and initiate a process of co- creation to design the right cake for the customer's needs and budget, and that is within the production capabilities of the company.

The paper format plays a fundamental role in the production processes; in addition to storing the customer's requirements, it is a communication object [9] that interacts with the different actors, processes and production units of the bakery. It was observed that copies of the order form are generated and sent to the accounting processes, wherethe information is recorded in the cash flow, daily balance, and income forms. Anothercopy goes to the client and is delivered as an invoice/ticket to receive the cake. The lastcopy goes to the production processes to be interpreted by the pastry chef/decorator [10].

When the pastry chef must read and interpret [11], [12] the paper format, problems of understanding arise due to different factors such as: the order form must be filled outin calligraphy by the salesperson, the salesperson must fill in more than 90 boxes wheredifferent data are requested to create a written description of the customer's wishes, thelayout of the visual elements that make up the order form are subject to the size of the paper, This results in illegible texts due to the size of the font, or tight spaces, which, when filling out manually, force the overlapping of lines when writing, or that the writ-ten words overflow the margins of the form. These factors make it difficult for the baker to interpret the requirements, since the elicitation of requirements through paper formsis constantly susceptible to human error.

The requirements documentation process, which is carried out in a traditional (hand-made) way, causes frequent spelling errors, legibility problems and crossings out, prob-lems for easy reading and interpretation due to the high rate of grammatical, syntax, semantic or pragmatic errors made by the person in charge, which directly affects the production processes, hinders mental processes related to hermeneutics [13] and there-fore reduces the understanding of the tasks to be performed by the pastry chef/decora-tor. This causes that the customized product is not elaborated under the requested re- quirements, and, therefore, generates a high degree of dissatisfaction, frustration and sadness [11] in the customer at the moment of receiving the product. For traditional bakeries, this situation manifests itself as a critical problem of communication and un-derstanding between production units, since the main processes depend on paper for- mats [10]. Therefore, it is presumed that the design of these
The productive macro-processes correspond to the materialization of the design of the cake product of the negotiation. To carry out this task, seven processes are carried out, categorized as follows: Production Process 1: Good Manufacturing Practices. Pro-ductive Process 2: Preparation of raw materials. Productive Process 3: Baking. Produc-tive Process 4: Decoration. Productive Process 5: Photographic Registration. Produc- tive Process 6: Packaging and storage. Productive Process 7: Distribution. At the end of the productive macro-processes, the project of elaboration of a personalized cake isfinished, thus achieving the satisfaction of the needs of the company's client. To guar- antee the success of the productive macro-processes, there are the support macro-pro- cesses, whose core is composed of administrative processes, accounting management processes, human management processes, and resource management processes.

1.3 Description of the observed problem.

Particularly, ambiguities have been identified in the use of natural language to de- scribe the chromatic characteristics of the cake, for example: "I need it to be blue", the problem is that, with the colorants used in food, more than 50 different shades of blue can be achieved, therefore, there is a high probability that the blue color imagined by the baker is different from the color imagined by the customer. The decoration of a personalized cake obeys the theme of the event, and is loaded with a high symbolic [7]and emotional value [8], the emotional aspects of cake decoration make the client have very high design expectations, which generally imply a high degree of technical diffi- culty for the decorator, which translates into a high selling price of the product, and sometimes customers are not willing to pay such a high value, which is why the cus- tomer with the help of the seller and the pastry chef begin to make more realistic ex- pectations of the product and initiate a process of co- creation to design the right cake for the customer's needs and budget, and that is within the production capabilities of the company.

The paper format plays a fundamental role in the production processes; in addition to storing the customer's requirements, it is a communication object [9] that interacts with the different actors, processes and production units of the bakery. It was observed that copies of the order form are generated and sent to the accounting processes, wherethe information is recorded in the cash flow, daily balance, and income forms. Anothercopy goes to the client and is delivered as an invoice/ticket to receive the cake. The lastcopy goes to the production processes to be interpreted by the pastry chef/decorator [10].

When the pastry chef must read and interpret [11], [12] the paper format, problems of understanding arise due to different factors such as: the order form must be filled outin calligraphy by the salesperson, the salesperson must fill in more than 90 boxes wheredifferent data are requested to create a written description of the customer's wishes, thelayout of the visual elements that make up the order form are subject to the size of the paper, This results in illegible texts due to the size of the font, or tight spaces, which, when filling out manually, force the overlapping of lines when writing, or that the writ-ten words overflow the margins of the form. These factors make it difficult for the baker to interpret the requirements, since the elicitation of requirements through paper formsis constantly susceptible to human error.

The requirements documentation process, which is carried out in a traditional (hand-made) way, causes frequent spelling errors, legibility problems and crossings out, prob-lems for easy reading and interpretation due to the high rate of grammatical, syntax, semantic or pragmatic errors made by the person in charge, which directly affects the production processes, hinders mental processes related to hermeneutics [13] and there-fore reduces the understanding of the tasks to be performed by the pastry chef/decora-tor. This causes that the customized product is not elaborated under the requested re- quirements, and, therefore, generates a high degree of dissatisfaction, frustration and sadness [11] in the customer at the moment of receiving the product. For traditional bakeries, this situation manifests itself as a critical problem of communication and un-derstanding between production units, since the main processes depend on paper for- mats [10]. Therefore, it is presumed that the design of these
formats does not allow the generation of a representation of an efficient mental model of the user [10], thus causing confusion, reprocessing and errors in repetitive tasks.

To approach this problem, Section 2 of the article establishes a conceptual frame- work, which allows us to analyze the state of the art of the existing literature on the situation of the pastry industry. Section 3 defines a methodological approach to identify and apply awareness mechanisms in collaborative processes. In section 4, the method-ological framework defined is applied in the Miski bakery. Section 5 discusses the re- sults, and section 6 discusses future work.

## 2 Conceptual Framework.

It is necessary to investigate the existing literature to identify trends in technologies and methodologies that can contribute to the closing of technological gaps identified in the communication processes where customers and micro enterprises of the niche cor-responding to Bakeries / Pastry Shops participate collaboratively.

The aim is to provide a possible solution approached from a scientific (Computing) and methodological (Design) approach, to the communication problems that affect the different actors when working as a team, due to cultural aspects [14] representation and understanding, which arise in business processes, and hinder understanding when cap-turing data related to the requirements for the development of customized cakes (FoodIndustry).

**Nucleus 1: Computer Science.** The research in this area of knowledge focuses on software engineering. Emphasis is placed on the search of scientific literature related to the processes of elicitation and requirements analysis. In addition, it is important to inquire about modeling languages. It is desired to know the application of models, methods and tools provided by collaboration engineering; therefore, it is important to investigate about the concepts related to Groupware, Awareness, Thinklets and socially to shared understanding in virtual environments.

**Nucleus 2: Communication and graphic design.** It is very useful to learn about methodologies and processes related to user-centered design (UCD) and culture-centered design (CCD), since these methodologies allow a detailed and empathetic understanding of the context of the actors involved in the process to be intervened. In addition, these methodologies favor the creation of software models with better levels of communication and understanding between users, thus generating a better interaction.

**Nucleus 3: Business Administration / Food Industry.** In this area of knowledge, it is of interest for the research to analyze the trends, dynamics and processes of companies in the gastronomic sector, particularly in the market niche corresponding to pastry shops specialized in the elaboration of customized cakes, for this reason, it is necessary to investigate the existing literature on the food industry and the technological innovations that exist in this field such as 3D printing of food, biodegradable packaging, and environmentally friendly manufacturing. It is necessary to know case studies where optimization or automation of production systems is performed through software, to analyze the impact of digital transformation in supply chains, in the manufacture of customized artifacts, and in customer service processes, and thus, to obtain references of technologies applied to the food industry.

**Systematic literature mapping.** For the selection of the subject of the systematic map-ping a research protocol [15] consisting of three phases was designed: First, the preparatory phase, whose activities consist of: Identifying the thematic nuclei related to the situation or problem to be addressed. Perform a critical and strategic analysis of each thematic nucleus. Analyze the key words, categorize them and make a list of selected words. Second, execution phase: Create and apply inclusion and exclusion criteria. Construct the final search string. Execute the search string. Select the database. Compile found studies. Narrow down articles. Perform snowball sampling. Third, documentation phase: Categorize articles by level of relevance and contribution. Conduct a literature review. Analysis of main findings and trends. Draw conclusions.
formats does not allow the generation of a representation of an efficient mental model of the user [10], thus causing confusion, reprocessing and errors in repetitive tasks.

To approach this problem, Section 2 of the article establishes a conceptual frame- work, which allows us to analyze the state of the art of the existing literature on the situation of the pastry industry. Section 3 defines a methodological approach to identify and apply awareness mechanisms in collaborative processes. In section 4, the method-ological framework defined is applied in the Miski bakery. Section 5 discusses the re- sults, and section 6 discusses future work.

## 2 Conceptual Framework.

It is necessary to investigate the existing literature to identify trends in technologies and methodologies that can contribute to the closing of technological gaps identified in the communication processes where customers and micro enterprises of the niche cor-responding to Bakeries / Pastry Shops participate collaboratively.

The aim is to provide a possible solution approached from a scientific (Computing) and methodological (Design) approach, to the communication problems that affect the different actors when working as a team, due to cultural aspects [14] representation and understanding, which arise in business processes, and hinder understanding when cap-turing data related to the requirements for the development of customized cakes (FoodIndustry).

**Nucleus 1: Computer Science.** The research in this area of knowledge focuses on software engineering. Emphasis is placed on the search of scientific literature related to the processes of elicitation and requirements analysis. In addition, it is important to inquire about modeling languages. It is desired to know the application of models, methods and tools provided by collaboration engineering; therefore, it is important to investigate about the concepts related to Groupware, Awareness, Thinklets and socially to shared understanding in virtual environments.

**Nucleus 2: Communication and graphic design.** It is very useful to learn about methodologies and processes related to user-centered design (UCD) and culture-centered design (CCD), since these methodologies allow a detailed and empathetic understanding of the context of the actors involved in the process to be intervened. In addition, these methodologies favor the creation of software models with better levels of communication and understanding between users, thus generating a better interaction.

**Nucleus 3: Business Administration / Food Industry.** In this area of knowledge, it is of interest for the research to analyze the trends, dynamics and processes of companies in the gastronomic sector, particularly in the market niche corresponding to pastry shops specialized in the elaboration of customized cakes, for this reason, it is necessary to investigate the existing literature on the food industry and the technological innovations that exist in this field such as 3D printing of food, biodegradable packaging, and environmentally friendly manufacturing. It is necessary to know case studies where optimization or automation of production systems is performed through software, to analyze the impact of digital transformation in supply chains, in the manufacture of customized artifacts, and in customer service processes, and thus, to obtain references of technologies applied to the food industry.

**Systematic literature mapping.** For the selection of the subject of the systematic map-ping a research protocol [15] consisting of three phases was designed: First, the preparatory phase, whose activities consist of: Identifying the thematic nuclei related to the situation or problem to be addressed. Perform a critical and strategic analysis of each thematic nucleus. Analyze the key words, categorize them and make a list of selected words. Second, execution phase: Create and apply inclusion and exclusion criteria. Construct the final search string. Execute the search string. Select the database. Compile found studies. Narrow down articles. Perform snowball sampling. Third, documentation phase: Categorize articles by level of relevance and contribution. Conduct a literature review. Analysis of main findings and trends. Draw conclusions.
The key words of each core are listed and categorized from the most general to the most specific thematic areas according to their level of contribution to the project. A superficial search is performed in the meta-search engine Scopus, using the filter: (Search within: Article title, Abstrack, Keywords). This work was carried out for each term to estimate its potential in terms of number of publications. For the construction of the search string, the keywords considered to be of greatest relevance and contribution to the research should be selected, and it should also be verified that there is a considerable number of articles.

**Search chain.** (( ( "Awareness" AND "groupware" AND "CSCW" AND "Work- space" ) ) OR ("Cake design" OR ("Gastronomy" AND "Supply Chain")) OR ("Foodindustry" AND "Bakery" AND "software") OR ("collaborative cooking" OR "cake Decoration")) OR (("Semiotic Engineering" AND "Usability") OR ("User Experience"AND "Web Design" AND "User Interfaces" AND "User Centered Design") OR ("Se-miotic Engineering" AND "collaborative design"))) ANDNOT ("health" OR "Farm- ing" OR "farm" OR "Agriculture" OR "Chemical" OR "tourism" OR "Video" OR "Medical" OR "chemistry" OR "Healthcare" OR "School" OR "Medical images" OR"fruits"))

A total of 114 related documents were obtained as a result of applying the search string. An analysis was carried out and those articles considered to contribute to the interests of the project were selected. Twenty-three articles were identified that are aligned with the research interests of the project. This is equivalent to 20.17% of the total number of documents resulting from the search chain. The articles were evaluated and categorized according to their level of contribution in order to narrow down the research. At the time of narrowing down the 23 resulting articles, the following result were obtained: 6 articles categorized as being of greater relevance and contribution (26.08%). 7 articles were identified as highly relevant (30.43%). 5 articles defined as medium relevance (21.73%). 5 articles identified as low relevance (21.73%). It can be concluded that 56.51% of the articles delimited are considered for in-depth literature review. In the process of analysis and documentation of the findings, researches such as CakeVr [16] validate the relevance of the communication problem identified in the collaborative activities of cake shops. A language pattern for collaborative cooking [17], and interactive cake decorating models [18] were identified. The most important theoretical contribution is related to the methodological framework for designing collaborative systems with awarenes mechanisms [19].

On the other hand, in the area of software process engineering [20], the main contribution is in the understanding and identification [21] of critical processes that can be supported through software. In the area of Semiotic Engineering the contributions are related to the construction of graphical interfaces oriented to communicability and understanding [22] based on elements of Culture-Centered Design [22] & User-Centered Design [23] and tools were discovered to perform an emotional evaluation of the usability [24], Interaction [25] and Accessibility of the software model.

# 3 Methodological Framework.

Collaborative work involves the effort of two or more people to achieve a common goal [26], collaborative work increases group efficiency, fosters social relationships and improves individual well-being [27]. Understanding the characteristics of group work enables the design of appropriate information technology to support collaborative work processes. CSCW studies the impact of technology on group interaction within shared virtual spaces [19]. For efficient interaction, it is important that members feel part of the group and obtain sufficient information to perceive, understand and adapt to the shared work environment. This contextual information, which group members need to reduce metacognitive effort, is known as awareness [19]. Awareness mechanisms require the identification of the type of information that is needed for the group members to understand and adapt to the shared work environment.

Awareness mechanisms require identifying the type of information to be provided, information distribution strategies, and a method of representing contextual information. Group members interact through artifacts or direct communication channels and must be aware of other group members
The key words of each core are listed and categorized from the most general to the most specific thematic areas according to their level of contribution to the project. A superficial search is performed in the meta-search engine Scopus, using the filter: (Search within: Article title, Abstrack, Keywords). This work was carried out for each term to estimate its potential in terms of number of publications. For the construction of the search string, the keywords considered to be of greatest relevance and contribution to the research should be selected, and it should also be verified that there is a considerable number of articles.

**Search chain.** (( ( "Awareness" AND "groupware" AND "CSCW" AND "Work- space" ) ) OR ("Cake design" OR ("Gastronomy" AND "Supply Chain")) OR ("Foodindustry" AND "Bakery" AND "software") OR ("collaborative cooking" OR "cake Decoration")) OR (("Semiotic Engineering" AND "Usability") OR ("User Experience"AND "Web Design" AND "User Interfaces" AND "User Centered Design") OR ("Se-miotic Engineering" AND "collaborative design"))) ANDNOT ("health" OR "Farm- ing" OR "farm" OR "Agriculture" OR "Chemical" OR "tourism" OR "Video" OR "Medical" OR "chemistry" OR "Healthcare" OR "School" OR "Medical images" OR"fruits"))

A total of 114 related documents were obtained as a result of applying the search string. An analysis was carried out and those articles considered to contribute to the interests of the project were selected. Twenty-three articles were identified that are aligned with the research interests of the project. This is equivalent to 20.17% of the total number of documents resulting from the search chain. The articles were evaluated and categorized according to their level of contribution in order to narrow down the research. At the time of narrowing down the 23 resulting articles, the following result were obtained: 6 articles categorized as being of greater relevance and contribution (26.08%). 7 articles were identified as highly relevant (30.43%). 5 articles defined as medium relevance (21.73%). 5 articles identified as low relevance (21.73%). It can be concluded that 56.51% of the articles delimited are considered for in-depth literature review. In the process of analysis and documentation of the findings, researches such as CakeVr [16] validate the relevance of the communication problem identified in the collaborative activities of cake shops. A language pattern for collaborative cooking [17], and interactive cake decorating models [18] were identified. The most important theoretical contribution is related to the methodological framework for designing collaborative systems with awarenes mechanisms [19].

On the other hand, in the area of software process engineering [20], the main contribution is in the understanding and identification [21] of critical processes that can be supported through software. In the area of Semiotic Engineering the contributions are related to the construction of graphical interfaces oriented to communicability and understanding [22] based on elements of Culture-Centered Design [22] & User-Centered Design [23] and tools were discovered to perform an emotional evaluation of the usability [24], Interaction [25] and Accessibility of the software model.

## 3 Methodological Framework.

Collaborative work involves the effort of two or more people to achieve a common goal [26], collaborative work increases group efficiency, fosters social relationships and improves individual well-being [27]. Understanding the characteristics of group work enables the design of appropriate information technology to support collaborative work processes. CSCW studies the impact of technology on group interaction within shared virtual spaces [19]. For efficient interaction, it is important that members feel part of the group and obtain sufficient information to perceive, understand and adapt to the shared work environment. This contextual information, which group members need to reduce metacognitive effort, is known as awareness [19]. Awareness mechanisms require the identification of the type of information that is needed for the group members to understand and adapt to the shared work environment.

Awareness mechanisms require identifying the type of information to be provided, information distribution strategies, and a method of representing contextual information. Group members interact through artifacts or direct communication channels and must be aware of other group members
(activities, changes, states...). In groupware, people can communicate information either explicitly, or implicitly through interaction with shared artifacts, which involve non-verbal, more symbolic communication.

The methodological framework for designing collaborative systems with awareness mechanisms [19] is based on five stages: Awareness goals and support: consists of identifying the type of information that the members of the work group should perceive, and the context in which it is produced. Awareness Information identification: allows to obtain a semantic interpretation of the information model and to give it meaning. Modeling, it is necessary to define and model the information to be provided and its content once the awareness objectives have been established. Distribution allows to have an explicit knowledge of the information and its mechanisms for socialization. awareness User Interfaces: define how the awareness information is going to be represented to be used.

# 4 Application of the Methodological Framework to design collaborative systems with awareness mechanisms for the Miski bakery.

The methodology is applied to the case study of the pastry shop Miski in the city of Popayán.

## PHASE 1: Awareness Information Goals.

It is necessary to determine the most important type of Awareness to successfully perform the activity of negotiating the requirements of the customized product. To design the decoration of a cake in a collaborative manner requires synchronous or asynchronous interaction between the three main actors identified in the process, which are geographically dispersed: the customer, the seller and the baker. At the beginning of this process, it is necessary for the client to obtain information regarding the status of the other members of the group, i.e. the client wants to know if there is another human being accompanying him/her in the process, who that person is, what expertise he/she has, what position he/she holds, will he/she understand my tastes and desires for the cake, etc. Another relevant factor is the level of urgency with which the customer needs the product, if the level is low, the communication is generally asynchronous, but if the level of urgency is high, the communication is synchronous.

The cultural context in which the customer's special event takes place directly influences the customer's imaginary construct of the cake. Due to the limitations to describe the cake through natural language, the client uses images of reference, which visually allow him to make explicit his requirements regarding the product, for this reason, it is important that the client is informed about the shared work space, because that is where the decoration design is going to be made, therefore, first, he must be able to visualize the cake (work area), second, the client must know the different tools and decoration possibilities that the software allows (context), as well as its restrictions and third, the client must have a practical understanding of each of the steps (Activities) that are followed for the elaboration of a personalized cake, thus, through the information provided by the software, the client is guided or immersed in the decoration process. Each element used in the workspace is a visual metaphor that emulates the elements and utensils used in the decoration station, therefore, it must provide a context and a background meaning, so that the client can use them and thus achieve the desired design, also generating a good user experience.

Every time a client generates a design, this information is available so that the pastry chef, from his perspective and expertise, can make recommendations to improve the aesthetic quality of the product, to achieve this activity, it is necessary to have clear information about the preferences and interests shared by the client.
(activities, changes, states...). In groupware, people can communicate information either explicitly, or implicitly through interaction with shared artifacts, which involve non-verbal, more symbolic communication.

The methodological framework for designing collaborative systems with awareness mechanisms [19] is based on five stages: Awareness goals and support: consists of identifying the type of information that the members of the work group should perceive, and the context in which it is produced. Awareness Information identification: allows to obtain a semantic interpretation of the information model and to give it meaning. Modeling, it is necessary to define and model the information to be provided and its content once the awareness objectives have been established. Distribution allows to have an explicit knowledge of the information and its mechanisms for socialization. awareness User Interfaces: define how the awareness information is going to be represented to be used.

# 4 Application of the Methodological Framework to design collaborative systems with awareness mechanisms for the Miski bakery.

The methodology is applied to the case study of the pastry shop Miski in the city of Popayán.

## PHASE 1: Awareness Information Goals.

It is necessary to determine the most important type of Awareness to successfully perform the activity of negotiating the requirements of the customized product. To design the decoration of a cake in a collaborative manner requires synchronous or asynchronous interaction between the three main actors identified in the process, which are geographically dispersed: the customer, the seller and the baker. At the beginning of this process, it is necessary for the client to obtain information regarding the status of the other members of the group, i.e. the client wants to know if there is another human being accompanying him/her in the process, who that person is, what expertise he/she has, what position he/she holds, will he/she understand my tastes and desires for the cake, etc. Another relevant factor is the level of urgency with which the customer needs the product, if the level is low, the communication is generally asynchronous, but if the level of urgency is high, the communication is synchronous.

The cultural context in which the customer's special event takes place directly influences the customer's imaginary construct of the cake. Due to the limitations to describe the cake through natural language, the client uses images of reference, which visually allow him to make explicit his requirements regarding the product, for this reason, it is important that the client is informed about the shared work space, because that is where the decoration design is going to be made, therefore, first, he must be able to visualize the cake (work area), second, the client must know the different tools and decoration possibilities that the software allows (context), as well as its restrictions and third, the client must have a practical understanding of each of the steps (Activities) that are followed for the elaboration of a personalized cake, thus, through the information provided by the software, the client is guided or immersed in the decoration process. Each element used in the workspace is a visual metaphor that emulates the elements and utensils used in the decoration station, therefore, it must provide a context and a background meaning, so that the client can use them and thus achieve the desired design, also generating a good user experience.

Every time a client generates a design, this information is available so that the pastry chef, from his perspective and expertise, can make recommendations to improve the aesthetic quality of the product, to achieve this activity, it is necessary to have clear information about the preferences and interests shared by the client.
<table><caption>**Table 1.** Different types of awareness in pastry business processes.</caption><thead><tr><td>Awareness</td><td>Importance</td><td>Explanation</td></tr></thead><tbody><tr><td>Group</td><td>High</td><td>The customer wants to know about her cake design partners.</td></tr><tr><td>Workspace</td><td>Very High</td><td>The customer must be able to visualize the cake and interact with the decoration elements in the shared workspace.</td></tr><tr><td>Context</td><td>Very High</td><td>The customer must be familiar with the tools and elements that make up the shared workspace.</td></tr><tr><td>Peripheral</td><td>Low</td><td>For the time being, they are not considered important.</td></tr><tr><td>Activity</td><td>Very High</td><td>For the pastry chef, it is important to know and visualize the customer's requirements and the latest modifications to the product.</td></tr><tr><td>Availability</td><td>High</td><td>The customer wants to know when the salesperson or pastry chef is available to provide support if needed.</td></tr><tr><td>Perspective</td><td>Very High</td><td>The salesperson needs to capture and understand the customer's expectations and desires for the cake.</td></tr><tr><td>Community</td><td>High</td><td>The customer expresses his ideas in front of the cake, the baker helps to make aesthetic decisions and the salesperson calculates and informsthe costs of the product.</td></tr><tr><td>Presence</td><td>Medium</td><td>The salesperson must be informed each time a customer enters the shared workspace.</td></tr><tr><td>Rhythm</td><td>Medium</td><td>The customer wants to track the processing status of his product.</td></tr></tbody></table>

## PHASE 2: Awareness Information Identification.

### Component 1: People.

2.1.1. *People's Structure: Social norms, Conventions, and roles.* In the negotiation process, the three main actors of the process (Client, Pastry Chef, Salesperson) interactdirectly. The salesperson must act according to customer service protocol, must respondas quickly as possible, and must be very courteous and polite following social norms. The salesperson is the mediator between the natural language used by the customer andthe technical language used by the pastry chef and must also capture all the customer'srequirements for the product in order to calculate the costs. The pastry chef is the expertin decoration, his role is to guide the customer in the decoration decisions, to achieve aesthetic quality levels, and to capture all the requirements, expectations and desires ofthe imagined product. The client is the actor who initiates the process, needs a cake, gets in touch, shares information about how he imagines the product object of desire, and expects his expectations to be fully satisfied. In short, the customer communicateshis ideas, the pastry chef cooperates with his expertise in the design of the cake deco- ration, and the seller coordinates the requirements, costs, and available resources.

2.1.2 *People's State: Availability, activity and emotions.* The salesperson needs to beinformed about the customer's emotions during the interaction with the shared work- space artifacts, e.g., is everything going well, is the customer confused, does the cus- tomer need help? The customer must know if he/she has the company of a human in the process. The pastry chef must understand the customer's need for support and knowthe degree of satisfaction with the product decoration. All stakeholders must visualize the current status of the customized cake.

2.1.3. *People's Location: Presence, distance, visibility, space-place, and metaphors.* The negotiation process is done through digital media because they are geographicallydispersed, the shared workspace to be designed for the software is a metaphor of the processes, it is based on the production logic followed by the company, it simulates inthe virtual environment the elements of decoration, the utensils that are used in the company, and the decoration space, which gives context to the artifacts with which thecustomer interacts when designing the cake.

2.1.4. *People's actions: events and distortion (aggregation, animation, etc.).* The pastry chef must be informed and updated regarding changes made by the client to thedecoration of the product. Likewise, he/she must be informed about the raw material inventories that are necessary for the elaboration of the product, he/she must know theavailability of human resources, time and raw materials during the negotiation processwith the client in order to determine the production capacity of
<table><caption>**Table 1.** Different types of awareness in pastry business processes.</caption><thead><tr><td>Awareness</td><td>Importance</td><td>Explanation</td></tr></thead><tbody><tr><td>Group</td><td>High</td><td>The customer wants to know about her cake design partners.</td></tr><tr><td>Workspace</td><td>Very High</td><td>The customer must be able to visualize the cake and interact with the decoration elements in the shared workspace.</td></tr><tr><td>Context</td><td>Very High</td><td>The customer must be familiar with the tools and elements that make up the shared workspace.</td></tr><tr><td>Peripheral</td><td>Low</td><td>For the time being, they are not considered important.</td></tr><tr><td>Activity</td><td>Very High</td><td>For the pastry chef, it is important to know and visualize the customer's requirements and the latest modifications to the product.</td></tr><tr><td>Availability</td><td>High</td><td>The customer wants to know when the salesperson or pastry chef is available to provide support if needed.</td></tr><tr><td>Perspective</td><td>Very High</td><td>The salesperson needs to capture and understand the customer's expectations and desires for the cake.</td></tr><tr><td>Community</td><td>High</td><td>The customer expresses his ideas in front of the cake, the baker helps to make aesthetic decisions and the salesperson calculates and informsthe costs of the product.</td></tr><tr><td>Presence</td><td>Medium</td><td>The salesperson must be informed each time a customer enters the shared workspace.</td></tr><tr><td>Rhythm</td><td>Medium</td><td>The customer wants to track the processing status of his product.</td></tr></tbody></table>

## PHASE 2: Awareness Information Identification.

### Component 1: People.

2.1.1. *People's Structure: Social norms, Conventions, and roles.* In the negotiation process, the three main actors of the process (Client, Pastry Chef, Salesperson) interactdirectly. The salesperson must act according to customer service protocol, must respondas quickly as possible, and must be very courteous and polite following social norms. The salesperson is the mediator between the natural language used by the customer andthe technical language used by the pastry chef and must also capture all the customer'srequirements for the product in order to calculate the costs. The pastry chef is the expertin decoration, his role is to guide the customer in the decoration decisions, to achieve aesthetic quality levels, and to capture all the requirements, expectations and desires ofthe imagined product. The client is the actor who initiates the process, needs a cake, gets in touch, shares information about how he imagines the product object of desire, and expects his expectations to be fully satisfied. In short, the customer communicateshis ideas, the pastry chef cooperates with his expertise in the design of the cake deco- ration, and the seller coordinates the requirements, costs, and available resources.

2.1.2 *People's State: Availability, activity and emotions.* The salesperson needs to beinformed about the customer's emotions during the interaction with the shared work- space artifacts, e.g., is everything going well, is the customer confused, does the cus- tomer need help? The customer must know if he/she has the company of a human in the process. The pastry chef must understand the customer's need for support and knowthe degree of satisfaction with the product decoration. All stakeholders must visualize the current status of the customized cake.

2.1.3. *People's Location: Presence, distance, visibility, space-place, and metaphors.* The negotiation process is done through digital media because they are geographicallydispersed, the shared workspace to be designed for the software is a metaphor of the processes, it is based on the production logic followed by the company, it simulates inthe virtual environment the elements of decoration, the utensils that are used in the company, and the decoration space, which gives context to the artifacts with which thecustomer interacts when designing the cake.

2.1.4. *People's actions: events and distortion (aggregation, animation, etc.).* The pastry chef must be informed and updated regarding changes made by the client to thedecoration of the product. Likewise, he/she must be informed about the raw material inventories that are necessary for the elaboration of the product, he/she must know theavailability of human resources, time and raw materials during the negotiation processwith the client in order to determine the production capacity of
the company. The Client must be aware that each action performed in the cake decoration activity in the sharedspace work has a cost, for example; each figure or decoration motif that is added to the cake has a price, therefore, the more figures, the higher the monetary value of the cake. The client with his actions, and if he is well informed, can adjust the price of the cake to his purchasing power or established budget. The salesperson in his role as coordinator is in charge of generating the order form according to customer requirements and decoration elements used in the shared space, and his duty is to guide the customer's actions so that the process is satisfactory.

2.1.5. *People's activity: activity and goals.* The software design is based on the production logic where first the size of the cake is chosen from different options ranging from ¼ of a pound (8 portions for the client) to 4 pounds and can be from 1 floor to 3, also its shape is defined (round or square). Second, the flavor is chosen, where the customer must select their favorite flavors, and even make combinations, or choose any type of filling available. Third, the customer must choose the base color, and finally the type of decoration is chosen, each activity is sequential, and the change of activity, task to be performed, and the tasks performed, or achievements obtained are explicitly reported.

## 2.2. Component 2: Task or project.

2.2.1. *Task structure: process planning.* The salesperson should guide the customer and let him/her know how the shared workspace behavior works. The client in the shared workspace must be able to easily understand the dynamics and mechanics of decorating a cake virtually. The pastry chef must know the complexity of the decoration to be able to organize his work team in production (number of people in the team, expertise of the work team).

2.2.2. *Task or project state: state-based workflow.* The customer must obtain information regarding each phase of decoration performed, and must be able to evaluate the interaction experience, and ask for help if necessary. The salesperson must follow up and must know when all the tasks have been completed in order to generate the order form, and the Pastry Chef needs to be updated to know in which task the customer needs support, or if he/she can start the productive macro-processes.

## 2.3. Component 3: Resources.

2.3.1. *Resource structure: spatial and semantic networks.* In the shared virtual work-space, interaction artifacts that emulate furnishing elements and utensils are in charge of providing information regarding their use, value and formal characteristics. It is the task of the vendor to familiarize the customer with the concepts assigned to each inter-active artifact, creating a network of meanings associated with each phase of cake decoration. Being able to visualize the cake in the shared work area allows to generate a shared understanding among the actors involved in the process.

2.3.2. *Resources state: availability.* Make informed decisions and plan contingent actions by knowing the state of resources, e.g., knowing how many decoration elements are being used and their cost.

2.3.3. *Resources location: availability and resource discovery.* In the shared virtual space, artifacts are virtual representations of physical objects that are available for the customer to decorate his cake.
the company. The Client must be aware that each action performed in the cake decoration activity in the sharedspace work has a cost, for example; each figure or decoration motif that is added to the cake has a price, therefore, the more figures, the higher the monetary value of the cake. The client with his actions, and if he is well informed, can adjust the price of the cake to his purchasing power or established budget. The salesperson in his role as coordinator is in charge of generating the order form according to customer requirements and decoration elements used in the shared space, and his duty is to guide the customer's actions so that the process is satisfactory.

2.1.5. *People's activity: activity and goals.* The software design is based on the production logic where first the size of the cake is chosen from different options ranging from ¼ of a pound (8 portions for the client) to 4 pounds and can be from 1 floor to 3, also its shape is defined (round or square). Second, the flavor is chosen, where the customer must select their favorite flavors, and even make combinations, or choose any type of filling available. Third, the customer must choose the base color, and finally the type of decoration is chosen, each activity is sequential, and the change of activity, task to be performed, and the tasks performed, or achievements obtained are explicitly reported.

## 2.2. Component 2: Task or project.

2.2.1. *Task structure: process planning.* The salesperson should guide the customer and let him/her know how the shared workspace behavior works. The client in the shared workspace must be able to easily understand the dynamics and mechanics of decorating a cake virtually. The pastry chef must know the complexity of the decoration to be able to organize his work team in production (number of people in the team, expertise of the work team).

2.2.2. *Task or project state: state-based workflow.* The customer must obtain information regarding each phase of decoration performed, and must be able to evaluate the interaction experience, and ask for help if necessary. The salesperson must follow up and must know when all the tasks have been completed in order to generate the order form, and the Pastry Chef needs to be updated to know in which task the customer needs support, or if he/she can start the productive macro-processes.

## 2.3. Component 3: Resources.

2.3.1. *Resource structure: spatial and semantic networks.* In the shared virtual work-space, interaction artifacts that emulate furnishing elements and utensils are in charge of providing information regarding their use, value and formal characteristics. It is the task of the vendor to familiarize the customer with the concepts assigned to each inter-active artifact, creating a network of meanings associated with each phase of cake decoration. Being able to visualize the cake in the shared work area allows to generate a shared understanding among the actors involved in the process.

2.3.2. *Resources state: availability.* Make informed decisions and plan contingent actions by knowing the state of resources, e.g., knowing how many decoration elements are being used and their cost.

2.3.3. *Resources location: availability and resource discovery.* In the shared virtual space, artifacts are virtual representations of physical objects that are available for the customer to decorate his cake.
## PHASE 3: Modeling.

To model a collaborative process in UML, a collaboration diagram can be used. This diagram shows how the elements interact with each other to achieve a common goal. First, the key elements must be identified: start by identifying the key elements involved in the collaborative process, such as users, systems and resources. Then a collaboration diagram is created. Add awareness information elements to the diagram. The interactions between the elements are established, showing the communications and data exchanges that occur during the collaborative process. Then labels are added to the communications and data exchanges to describe the type of message being sent. Implement constraints. If there are constraints on the process, such as response time or resource availability, the diagram is analyzed for constraints. The diagram is reviewed and validated.

It is important to keep in mind that collaborative processes are often complex and may require several collaboration diagrams to fully model all interactions. It is also important to document the collaborative process in a specification or requirements document so that all stakeholders can clearly understand how it works.

## PHASE 4: Distribution.

The following are used for the distribution of awareness information:

4.1 *Notification Mechanisms*. Notification mechanisms are very important to guide the client during the decoration process through the graphical interface.

4.2. *User-driven discovery*. The information design allows the user to discover within the interface the Logical Model to decorate a cake, the client is guided through a series of steps.

## PHASE 5: Awareness User Interfaces.

A prototype of a graphical interface is designed where the awareness mechanisms are applied. The interface is a metaphor that simulates in a virtual way the work space that exists in a pastry shop, simulates the tools and utensils necessary for the decoration, and invites the client to follow a collaborative design process, where he has the possibility to interact and visualize 3D graphics with the rendering of the cake decoration. The interface must be composed of the following awareness mechanisms.

*People structure:* It is necessary to identify the role of each actor in the cake design process. For the client it is important to differentiate the seller from the baker. The graphic interface will make use of avatars to identify each actor, and the tasks in which each actor can actively collaborate, and their hierarchy will be presented in a kind of organization chart.

*People's status:* Different people's statuses can be represented, the first one is the availability status, which determines if the communication is going to be synchronous or not. When the actor is available, a green circle will light up around the avatar image, blue when the actor is busy or slow to respond, and gray when the actor is not available. It is important to evaluate the emotional states of the actors, mainly that of the custom-ers, since they are not as familiar with the interface as the bakery workers. In this case, the avatar will have the ability to represent emotions through its facial gestures, so it can represent emotions that can be generated at the time of design as: Confusion if you do not understand the task to be developed, or can represent sadness if the customer is frustrated because it fails to successfully complete a task, or can represent happiness, if everything is going in order. If a group member notices a negative emotion in the client's avatar, it is his or her duty to go immediately. To generate support for the task being performed in order to generate a good user experience.
## PHASE 3: Modeling.

To model a collaborative process in UML, a collaboration diagram can be used. This diagram shows how the elements interact with each other to achieve a common goal. First, the key elements must be identified: start by identifying the key elements involved in the collaborative process, such as users, systems and resources. Then a collaboration diagram is created. Add awareness information elements to the diagram. The interactions between the elements are established, showing the communications and data exchanges that occur during the collaborative process. Then labels are added to the communications and data exchanges to describe the type of message being sent. Implement constraints. If there are constraints on the process, such as response time or resource availability, the diagram is analyzed for constraints. The diagram is reviewed and validated.

It is important to keep in mind that collaborative processes are often complex and may require several collaboration diagrams to fully model all interactions. It is also important to document the collaborative process in a specification or requirements document so that all stakeholders can clearly understand how it works.

## PHASE 4: Distribution.

The following are used for the distribution of awareness information:

4.1 *Notification Mechanisms*. Notification mechanisms are very important to guide the client during the decoration process through the graphical interface.

4.2. *User-driven discovery*. The information design allows the user to discover within the interface the Logical Model to decorate a cake, the client is guided through a series of steps.

## PHASE 5: Awareness User Interfaces.

A prototype of a graphical interface is designed where the awareness mechanisms are applied. The interface is a metaphor that simulates in a virtual way the work space that exists in a pastry shop, simulates the tools and utensils necessary for the decoration, and invites the client to follow a collaborative design process, where he has the possibility to interact and visualize 3D graphics with the rendering of the cake decoration. The interface must be composed of the following awareness mechanisms.

*People structure:* It is necessary to identify the role of each actor in the cake design process. For the client it is important to differentiate the seller from the baker. The graphic interface will make use of avatars to identify each actor, and the tasks in which each actor can actively collaborate, and their hierarchy will be presented in a kind of organization chart.

*People's status:* Different people's statuses can be represented, the first one is the availability status, which determines if the communication is going to be synchronous or not. When the actor is available, a green circle will light up around the avatar image, blue when the actor is busy or slow to respond, and gray when the actor is not available. It is important to evaluate the emotional states of the actors, mainly that of the custom-ers, since they are not as familiar with the interface as the bakery workers. In this case, the avatar will have the ability to represent emotions through its facial gestures, so it can represent emotions that can be generated at the time of design as: Confusion if you do not understand the task to be developed, or can represent sadness if the customer is frustrated because it fails to successfully complete a task, or can represent happiness, if everything is going in order. If a group member notices a negative emotion in the client's avatar, it is his or her duty to go immediately. To generate support for the task being performed in order to generate a good user experience.