Um estudo sobre a participação do usuário final no ciclo de vida de desenvolvimento de aplicações de saúde : da análise do estado da arte à proposição de boas práticas de elicitação de requisitos utilizando o padrão arquétipo OpenEHR
Aluno: José Vitor de Abreu Silva Orientador: Prof. Dr. André Magno Costa de Araújo
Versa771o_Final_Dissertac807a771o_-_Vitor.pdf
Documento PDF (22.7MB)
Documento PDF (22.7MB)
UNIVERSIDADE FEDERAL DE ALAGOAS-UFAL
CAMPUS A.C SIMÕES
PROGRAMA DE PÓS GRADUAÇÃO EM INFORMÁTICA - PPGI
JOSÉ VITOR DE ABREU SILVA
UM ESTUDO SOBRE A PARTICIPAÇÃO DO USUÁRIO FINAL NO CICLO DE VIDA
DE DESENVOLVIMENTO DE APLICAÇÕES DE SAÚDE: DA ANÁLISE DO ESTADO
DA ARTE À PROPOSIÇÃO DE BOAS PRÁTICAS DE ELICITAÇÃO DE REQUISITOS
UTILIZANDO O PADRÃO ARQUÉTIPO OPENEHR
MACEIÓ - AL
2024
José Vitor de Abreu Silva
Um Estudo sobre a Participação do Usuário Final no Ciclo de Vida de Desenvolvimento de
Aplicações de Saúde: Da Análise do Estado da Arte à Proposição de Boas Práticas de Elicitação
de Requisitos Utilizando o Padrão Arquétipo openEHR
Dissertação apresentada como requisito parcial para
obtenção do grau de Mestrado em PROGRAMA
DE PÓS GRADUAÇÃO EM INFORMÁTICA PPGI da Universidade Federal de Alagoas - UFAL,
CAMPUS A.C SIMÕES.
Orientador: Prof. Dr. André Magno Costa de
Araújo
Coorientador: Prof. Dr. Fabio José Coutinho
da Silva
MACEIÓ - AL
2024
Catalogação na fonte
Universidade Federal de Alagoas
Biblioteca Central
Divisão de Tratamento Técnico
Bibliotecária: Helena Cristina Pimentel do Vale – CRB4 - 661
S586u
Silva, José Vitor de Abreu.
Um estudo sobre a participação do usuário final no ciclo de vida de
desenvolvimento de aplicações de saúde : da análise do estado da arte à proposição
de boas práticas de elicitação de requisitos utilizando o padrão arquétipo OpenEHR
/ José Vitor de Abreu Silva. – 2025.
102 f.: il.
Orientador: André Magno Costa de Araújo.
Coorientador: Fabio José Coutinho da Silva.
Dissertação (mestrado em Informática) – Universidade Federal de Alagoas,
Instituto de Computação. Maceió, 2024.
Bibliografia: f. 83-89.
Apêndices: f. 90-102.
1. Engenharia de software. 2. Elicitação de requisitos. 3. Ciclo de vida de
desenvolvimento de software. 4. Aplicações de saúde. 5. Arquétipo OpenEHR.
I. Título.
CDU: 004.41
À minha família, tê-los ao meu lado é o códigofonte da minha força.
AGRADECIMENTOS
Este trabalho não teria sido possível sem o apoio e incentivo de muitas pessoas, a quem
expresso minha sincera gratidão. A minha família, por ser o porto seguro de cuidado, amor e
união, especialmente nos momentos mais difíceis. Sem vocês, realizar este sonho teria sido
impossível. A minha mãe, Dirce Abreu, que sempre moveu o mundo para que a educação fosse
uma prioridade em minha vida, minha eterna gratidão. Sua força e coragem me inspiram a olhar
para o futuro com mais esperança. Ao meu pai (in memoriam), que, mesmo ausente, permanece
vivo em minha memória, me lembrando diariamente do valor do caráter e da perseverança. Seus
ensinamentos continuam a me guiar, mostrando que seguir nossos objetivos com integridade traz
significado para nossa jornada.
Aqueles que andam por um caminho mais fácil, muitas vezes seguem passos que outros
antes pavimentaram. No meu caso, essa estrada foi aberta desde cedo pela minha irmã mais
velha, Érika Abreu, cujo incentivo nos estudos, na amizade e na vida me serviu de exemplo
constante. Sou o filho do meio, e agradeço eternamente por ter vindo ao mundo antes de Arthur,
meu irmão mais novo, pois tudo o que faço é pensando em proporcionar a ele o melhor. Você
me proporciona os melhores momentos, sendo meu lugar de paz em meio a correria da vida. Eu
amo vocês. Ao meu parceiro de vida, João, que esteve ao meu lado em cada etapa, dividindo
o peso das incertezas, especialmente quando nem eu sabia ao certo por onde seguir. Obrigado
por ser tudo o que eu preciso (e mais um pouco). Você é meu apoio, sempre oferecendo escuta,
acolhimento e amor. Ter você ao meu lado tornou essa jornada mais leve e significativa, sou
extremamente grato por caminhar ao seu lado.
Aos meus amigos de jornada, Alenilton, Leticia e Rendrikson, agradeço imensamente.
Em cada etapa desta caminhada, nos ajudamos mutuamente, e a presença de vocês fez toda a
diferença. Compartilhar momentos de alegria, angústia e desafios tornou essa trajetória mais
leve e significativa. Nos dias mais difíceis, fomos juntos em busca de forças, com acolhimento,
apoio e leveza, e nos dias felizes, celebramos cada pequena conquista com entusiasmo e carinho.
Estarei sempre aqui para vocês.
Agradeço especialmente ao meu orientador, André Magno, por sua paciência, orientação
e compromisso ao longo desta jornada. Sou profundamente grato por ter me resgatado para o
mestrado e guiado com tanta habilidade, mostrando as possibilidades que eu poderia explorar.
Seu conhecimento, empatia e dedicação foram fundamentais para que eu avançasse e concluísse
esta pesquisa com confiança. Sua contribuição marcou minha trajetória acadêmica, e levo comigo,
com gratidão, todos os ensinamentos e o apoio recebido.
Agradeço também ao meu coorientador Fábio Coutinho e aos professores e colegas do
Programa de Pós-Graduação em informática, que, direta ou indiretamente, contribuíram para
meu aprendizado e crescimento acadêmico. Por fim, sou grato a todos que, de alguma forma,
contribuíram para a realização desta dissertação. A cada um de vocês, o meu muito obrigado.
Não ter medo de passos miúdos - por vezes,
cabe-nos dançar com o tempo para a[s]cender.
RESUMO
Os Sistemas de Informação em Saúde (SIS) desempenham um papel fundamental na sociedade,
fornecendo uma base tecnológica sólida para coletar, armazenar, processar e tomar decisões
no setor de saúde. Devido ao aumento significativo de soluções de software e as limitações
decorrentes das dificuldades associadas ao domínio da saúde, é fundamental a inclusão dos
usuários finais no ciclo de vida de desenvolvimento de sistemas de software. Dentre os processos
presentes no ciclo de vida, a fase de elicitação de requisitos desempenha um papel fundamental,
pois é nesta fase que as necessidades e os objetivos do usuários são identificados e compreendidos,
o que requer a utilização de técnicas que garanta a compreensão mais eficaz das necessidades
do usuário e que atenda às suas expectativas. O padrão OpenEHR, por exemplo, oferece uma
estrutura robusta para a modelagem e representação de informações clínicas, permitindo que os
requisitos dos usuários sejam capturados, o que torna possível o desenvolvimento de sistemas
de software que atendam às necessidades específicas dos profissionais de saúde e dos pacientes.
Dessa forma, este estudo tem como objetivo buscar evidências no estado da arte e da prática
a respeito das fases do processo de desenvolvimento o qual os profissionais de saúde são
inseridos e as técnicas de elicitação de requisitos presentes no ciclo de vida de desenvolvimento
de aplicações de saúde. Este trabalho realizou ainda um estudo com profissionais de saúde e
engenheiros de requisitos para analisar se o conhecimento do especialista do domínio especificado
por meio do arquétipo OpenEHR pode ser útil para representar os requisitos necessários para o
desenvolvimento de aplicações de saúde. A partir de uma análise temática das respostas obtidas
com a condução de entrevistas e aplicação de formulário online, foram identificados desafios e
limitações que são enfrentados com as aplicações utilizadas. Submetendo os dados obtidos à
análises estatísticas, como Alpha de Cronbach, ANOVA e correlação de Spearman, confirmouse que o baixo envolvimento de profissionais da saúde no ciclo de vida do software implica
diretamente na falta de adaptação dessas ferramentas às suas rotinas, pois elas não refletem as
suas reais necessidades. Considerando as perspectivas dos engenheiros de requisitos, ressaltou-se
a importância do estreitamento entre eles e os especialistas de domínio, evidenciando como a
interação pode contribuir para a criação de soluções mais adequadas às exigências clínicas e
mais eficazes a longo prazo. Por fim, estes resultados fundamentam um conjunto de boas práticas
voltadas para a elicitação e validação de requisitos, que se utilizam da capacidade do arquétipo
openEHR de representar cenários e necessidades das partes interessadas com clareza em alto
nível de detalhamento. Essas práticas visam reduzir o distanciamento entre o desenvolvimento
técnico e as necessidades clínicas, promovendo um alinhamento mais preciso e centrado no
usuário final.
Palavras-chave: Engenharia de Software, Elicitação de Requisitos, Ciclo de Vida de Desenvolvimento de Software, Aplicações de Saúde, Arquétipo openEHR.
ABSTRACT
Health Information Systems (HIS) play a fundamental role in society by providing a solid technological foundation for collecting, storing, processing, and making decisions in the healthcare
sector. Due to the significant increase in software solutions and the limitations arising from
the complexities of the healthcare domain, it is essential to include end users in the software
development lifecycle. Among the processes in this lifecycle, the requirements elicitation phase
plays a key role, as it is during this phase that users’ needs and objectives are identified and
understood. This requires the use of techniques that ensure a more effective understanding of
user needs and meet their expectations. The OpenEHR standard, for example, offers a robust
framework for modeling and representing clinical information, allowing user requirements to be
captured, which enables the development of software systems that meet the specific needs of
healthcare professionals and patients. Thus, this study aims to seek evidence in the state of the art
and practice regarding the phases of the development process in which healthcare professionals
are involved and the requirements elicitation techniques present in the healthcare application
development lifecycle. This work also conducted a study with healthcare professionals and
requirements engineers to analyze whether domain expertise specified through the OpenEHR
archetype can be useful in representing the necessary requirements for developing healthcare
applications. Through a thematic analysis of responses obtained from interviews and an online
survey, challenges and limitations faced with current applications were identified. By subjecting
the collected data to statistical analyses, such as Cronbach’s Alpha, ANOVA, and Spearman’s
correlation, it was confirmed that the low involvement of healthcare professionals in the software
lifecycle directly impacts the lack of adaptation of these tools to their routines, as they do
not reflect their real needs. Considering the perspectives of requirements engineers, the study
highlighted the importance of closer collaboration between them and domain experts, showing
how this interaction can contribute to creating solutions that are more suited to clinical demands
and more effective in the long term. Finally, these results support a set of best practices aimed at
requirements elicitation and validation, utilizing the OpenEHR archetype’s ability to represent
stakeholder scenarios and needs with clarity and a high level of detail. These practices aim to
bridge the gap between technical development and clinical needs, promoting a more precise and
user-centered alignment.
Keywords: Software Engineering, Requirements Elicitation, Software Development Lifecycle,
Health Applications, openEHR Archetype.
LISTA DE FIGURAS
Figura 1 – Metodologia da Pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 2 – Representação dos Elementos de um Arquétipo. . . . . . . . . . . . . . . .
Figura 3 – Percurso Metodológico da Revisão da Literatura. . . . . . . . . . . . . . .
Figura 4 – String de Busca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 5 – Critérios de Seleção. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 6 – Seleção dos Estudos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 7 – Categorias dos Estudos. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 8 – Tipos de Stakeholders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 9 – Quantidade e Combinações de Usuários Finais por Estudo. . . . . . . . . .
Figura 10 – Envolvimento dos Usuários Finais . . . . . . . . . . . . . . . . . . . . . .
Figura 11 – Técnicas de Elicitação de Requisitos Encontradas nos Estudos. . . . . . . .
Figura 12 – Métodos de Avaliação Presente nos Estudos. . . . . . . . . . . . . . . . . .
Figura 13 – Lacunas e Desafios Encontrados nos Estudos. . . . . . . . . . . . . . . . .
Figura 14 – Perfil Demográfico e Profissional dos Participantes da Pesquisa . . . . . . .
Figura 15 – Escolaridade e Área . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 16 – Ambiente de Atuação Profissional . . . . . . . . . . . . . . . . . . . . . .
Figura 17 – Finalidade das Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . .
Figura 18 – Participação de Profissionais de Saúde por Especialidade. . . . . . . . . . .
Figura 19 – Aplicação de Arquétipos openEHR na Fase de Elicitação de Requisitos. . .
19
27
30
32
33
35
42
43
44
46
49
50
51
55
56
56
57
62
76
LISTA DE TABELAS
Tabela 1 – Tipos de Técnicas de Elicitação de Requisitos mais Utilizadas. . . . . . . .
Tabela 2 – Questões para Avaliar o Uso de Arquétipos na Elicitação e Validação de
Requisitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tabela 3 – Resultados da ANOVA para os Profissionais de Saúde . . . . . . . . . . . .
25
63
67
LISTA DE ALGORITMOS
1
2
3
4
5
Script do Calculo do Alpha de Cronbach - Respostas dos Profissionais da Saúde 64
Script do Cálculo de ANOVA - Respostas dos Profissionais da Saúde . . . . . . 66
Script do Cálculo de Correlação de Spearman - Respostas dos Profissionais da
Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Script do Cálculo do Alpha de Cronbach - Respostas dos Engenheiros de Requisitos 71
Cálculo da Correlação de Spearman - Respostas dos Engenheiros de Requisitos 72
LISTA DE ABREVIATURAS E SIGLAS
EHR
Registro Eletrônico de Saúde
SIS
Sistemas de Informação em Saúde
IHC
Interação Humano-Computador
ES
Engenharia de Software
UCD
Design Centrado no Usuário
ER
Engenharia de Requisitos
CAPES
Coordenação de Aperfeiçoamento de Pessoal de Nível Superior
SUS
System Usability Scale
SQuaRE
Systems and Software Quality Requirements and Evaluation
UEQ
User Experience Questionnaire
BI
Inteligência de Negócios
GUI
Interface Gráfica do Usuário
SEQ
Single Ease Question
SWEBOK
Guide to the Software Engineering Body of Knowledge
SUMÁRIO
1
INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.1
Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.3.1
Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.3.2
Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.4
Questão de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.5
Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.6
Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2
REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.1
Ciclo de Vida de Aplicações de Softwares . . . . . . . . . . . . . . . . . .
21
2.2
Elicitação de Requisitos de Software . . . . . . . . . . . . . . . . . . . . .
23
2.2.1
Arquétipo OpenEHR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.3
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3
TRABALHOS CORRELATOS . . . . . . . . . . . . . . . . . . . . . . .
30
3.1
Metodologia da Revisão . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Planejamento da Revisão . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.1
Objetivo e Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.2
Definição da Estratégia de Busca . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.3
Definição dos Repositórios de Busca . . . . . . . . . . . . . . . . . . . . .
32
3.2.4
Critérios de Seleção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.5
Execução da String de Busca e Documentação dos Resultados . . . . . . . .
34
3.3
Análise do Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.4
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.4.1
Categoria dos Estudos Selecionados . . . . . . . . . . . . . . . . . . . . . .
41
3.4.2
Participação dos Usuários Finais nas Fases de Desenvolvimento do Software
45
3.4.3
Técnicas de Elicitação de Requisitos Presentes nos Estudos . . . . . . . . .
48
3.4.4
Métodos de Avaliação dos Softwares Presentes nos Estudos . . . . . . . . .
49
3.5
Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.6
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4
INVESTIGANDO O USO DE ARQUÉTIPOS NA FASE DE ELICITAÇÃO DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.1
Aspectos Éticos da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.2
Percurso Metodológico . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.3
Primeiro Estágio: Mapeamento e Construção de Perfil . . . . . . . . . . . .
54
4.3.1
Análise Quantitativa dos Dados . . . . . . . . . . . . . . . . . . . . . . . .
54
4.3.2
Análise Temática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.3.3
Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.4
Segundo Estágio: Experimento Utilizando Arquétipos OpenEHR . . . . . .
62
4.4.1
Experimento com Profissionais de Saúde . . . . . . . . . . . . . . . . . . .
62
4.4.1.1
Percepção dos Profissionais de Saúde . . . . . . . . . . . . . . . . . . . . .
68
4.4.2
Experimento com Engenheiros de Requisitos . . . . . . . . . . . . . . . . .
70
4.4.3
Percepção dos Engenheiros de Requisitos . . . . . . . . . . . . . . . . . . .
72
4.4.4
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5
BOAS PRÁTICAS PARA A ELICITAÇÃO DE REQUISITOS UTILIZANDO ARQUÉTIPOS OPENEHR . . . . . . . . . . . . . . . . . . . .
75
6
CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.1
Principais Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.2
Limitações e Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . .
81
6.3
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
APÊNDICE A – MODELO DO E-MAIL
. . . . . . . . . . . . . . . . . . . . . . .
90
APÊNDICE B – TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO . .
93
APÊNDICE C – COMITÊ DE ÉTICA EM PESQUISA . . . . . . . . . . . . . . .
95
14
1 INTRODUÇÃO
Este capítulo tem como objetivo introduzir o avanço científico acerca do tema de pesquisa
abordado nesta dissertação, e está estruturado da seguinte forma. A Seção 1.1 contextualiza e
discute o cenário atual de desenvolvimento de software, tal como os benefícios com a utilização
de abordagens centradas no usuário. A Seção 1.2 tem por objetivo estimular a reflexão do leitor
acerca do significativo crescimento observado na indústria de produtos de software nos últimos
anos, bem como fornecer uma visão prospectiva das tendências de mercado que se delineiam
para o futuro. A Seção 1.3 delineia os objetivos desta pesquisa, abrangendo tanto os objetivos
gerais quanto aqueles de natureza mais específica. A Seção 1.4, por sua vez, apresenta de maneira
detalhada a metodologia adotada para o desenvolvimento desta proposta de dissertação. Por fim,
a Seção 1.5 aborda a estrutura organizacional dos capítulos desta pesquisa.
1.1
CONTEXTUALIZAÇÃO
O mercado global de produtos de software cresceu significativamente nos últimos anos,
com uma taxa de crescimento anual de 12,5% entre 2022 e 2023 [Company 2023]. A previsão
de crescimento do mercado indica que este continuará a crescer significativamente nos próximos anos, especificamente entre 2023 e 2030 [Reports 2023]. Além disso, espera-se que o
mercado global de software de saúde cresça a uma taxa anual de 19,8% entre 2022 e 2027
[Markets e Market 2023], e esse crescimento é impulsionado pela adoção crescente e constante
de software de registro eletrônico de saúde (RES), telemedicina, mHealth e outras tecnologias
digitais. Dado este ambiente, os avanços tecnológicos transformaram significativamente o cenário
de software de saúde, incorporando cada vez mais sistemas de informação para otimizar os processos de gestão, monitoramento e prestação de serviços [Barbieri et al. 2023, Wu e Trigo 2021].
Neste contexto, os Sistemas de Informação em Saúde (SIS) desempenham um papel
fundamental, fornecendo uma base tecnológica sólida para a especificação, armazenamento, processamento e análise de dados relacionados com este domínio [Freitas et al. 2021]. No entanto,
muitos recursos de software utilizados em ambientes hospitalares, como prontuários eletrônicos
de pacientes, sistemas de telemedicina e sistemas de gestão de saúde, apresentam limitações
significativas em termos qualidade de uso, entre outros fatores que incluem riscos potenciais à
qualidade do software [Pitkänen e Pitkäranta 2016, Bitkina et al. 2020, Meehan 2020].
Por outro lado, o uso dos SIS é mais abrangente do que a manipulação de dados em
ambientes clínicos e administrativos. Um exemplo são os chatbots voltados para a área da
15
saúde, que têm surgido na literatura devido à sua capacidade generativa de serviços; no entanto,
especialistas do domínio apontaram deficiências nas informações médicas geradas a partir do
domínio do conhecimento [Kowatsch et al. 2017].
Com o aumento das soluções de software na área da saúde e as barreiras associadas à sua
complexidade, é essencial buscar melhorias contínuas para o processo de desenvolvimento de
softwares. Uma dessas melhorias está associada à inclusão dos usuários finais no ciclo de vida
de desenvolvimento de aplicações. A inclusão desses usuários finais requer uma abordagem que
considere os requisitos funcionais e não funcionais do sistema, exigindo técnicas específicas e
a aplicação de uma abordagem de Interação Humano-Computador (IHC). Área de estudo que
envolve todos os aspectos relacionados com a interação entre usuários e sistemas computacionais
[Preece et al. 1994, Carroll 2003].
É evidente a importância de se explorar ainda mais as técnicas de elicitação de requisitos
na área da saúde, uma vez que estas desempenham um papel fundamental no desenvolvimento de
sistemas que atendam verdadeiramente às necessidades dos usuários finais [Freitas et al. 2021].
Para além das técnicas utilizadas, a implementação de métodos que buscam a participação
direta dos stakeholders no processo de desenvolvimento de software é considerada essencial
[Bitkina et al. 2020], uma vez que esses profissionais desempenham um papel fundamental na
identificação de requisitos específicos do domínio e na validação prática das soluções propostas.
1.2
MOTIVAÇÃO
Com o crescimento do mercado de software de saúde, observa-se um aumento na depen-
dência de tecnologias de informação para o setor. Neste contexto dinâmico, a participação dos
usuários finais, especialmente profissionais de saúde, no ciclo de vida de desenvolvimento de aplicações de software torna-se cada vez mais necessárias, já que estudos na literatura destacam que
entre os desafios enfrentados nesse domínio, tem-se aqueles relacionados à experiência do usuário
e à usabilidade, além de interfaces de usuário pouco profissionais [Denecke et al. 2023, Li 2019].
O ciclo de vida de desenvolvimento é um processo essencial na criação de qualquer
projeto [Koumpouros 2021, Puspitasari et al. 2018], pois orienta a construção do software desde
a concepção até a entrega final do produto. Dentro deste ciclo, a fase de elicitação de requisitos
desempenha um papel fundamental, pois é nesta que as necessidades e os objetivos dos usuários
são identificados e compreendidos [Zotov et al. 2020, Fico et al. 2019]. Esta fase ainda requer a
participação ativa das partes interessadas para garantir que o produto final esteja alinhado com
suas expectativas e forneça os requisitos necessários.
16
Nesse contexto, a participação de profissionais de saúde, que compreendem as particularidades dos fluxos de trabalho médicos, interações com pacientes e tomada de decisões clínicas,
é indispensável [Melder et al. 2020]. A expertise desses profissionais garante que o software
esteja em conformidade com diretrizes médicas, seja usável, alinhado às necessidades práticas e
contribua para a melhoria no cuidado ao paciente. Envolver os profissionais de saúde (usuários
finais) ao longo do ciclo de desenvolvimento ajuda a reduzir a lacuna entre as especificações técnicas e as aplicações no mundo real, resultando em soluções de saúde mais eficazes e amigáveis
ao usuário [Govella 2019].
É fundamental que os profissionais de saúde participem ativamente na definição e validação dos requisitos das aplicações de software. Sem a sua valiosa contribuição, os desenvolvedores de software podem deixar de perceber desafios e necessidades práticas enfrentadas
diariamente pelos profissionais de saúde [Puspitasari et al. 2018]. Essa falta de envolvimento
pode resultar em softwares que não atendem plenamente às necessidades, possuem interfaces
pouco intuitivas e falham em suportar adequadamente os fluxos de trabalho clínicos. Além
disso, a ausência de especialistas da área de saúde no processo de levantamento de requisitos
pode acarretar problemas de conformidade regulatória e menor satisfação dos usuários finais
[Ghazali et al. 2014, Bitkina et al. 2020].
Evidências identificadas no estado da arte revelam uma notável deficiência na
participação dos profissionais de saúde na validação dos requisitos das aplicações
de software [Jacobs et al. 2018, Nimmolrat et al. 2021, Quinde et al. 2019, Ishak et al. 2021,
Silva et al. 2024, Falcão et al. 2019]. Técnicas tradicionais de engenharia de software muitas
vezes não atendem às necessidades e contextos específicos dos usuários finais na área da saúde, o
que gera desafios para a validação eficaz dos requisitos. Esses métodos convencionais podem não
capturar totalmente as nuances dos fluxos de trabalho clínicos e as demandas práticas enfrentadas
pelos profissionais de saúde.
O Padrão de Arquétipos openEHR surgiu como uma abordagem promissora no desenvolvimento de aplicações de saúde, oferecendo uma estrutura para definir e gerenciar conceitos
clínicos [Oliveira et al. 2022, Min et al. 2018, Araújo et al. 2018]. No entanto, em muitos casos,
os Arquétipos openEHR foram limitados à fase de desenvolvimento do software, baseando-se
fortemente nas especificações dos arquétipos, sem incorporar diretamente a contribuição dos
profissionais de saúde [Araújo et al. 2018, Araujo et al. 2018, Araújo et al. 2019]. Essa lacuna
ressalta a necessidade de processos de validação mais inclusivos, que integrem a expertise dos
usuários finais para garantir que as soluções de software estejam alinhadas com os requisitos
17
clínicos e melhorem a qualidade geral das aplicações de saúde.
Além disso, o estado da arte ainda aponta para algumas técnicas de elicitação de requisitos que, embora variadas, tendem a ser mais voltadas para a validação do que para
a verdadeira compreensão das necessidades dos usuários finais. Dentre as técnicas identificadas, observa-se uma ênfase significativa em entrevistas semi-estruturadas e grupos
focais [Nimmolrat et al. 2021, Ishak et al. 2021, Alabdulhafith et al. 2018, Quinde et al. 2019,
Fico et al. 2019, Chatterjee et al. 2022]. Ademais, foi constatado também que alguns trabalhos
envolvem o usuário final, sejam profissionais ou pacientes, apenas na fase de validação da
ferramenta [Jacobs et al. 2018, Bacungan et al. 2021, Falcão et al. 2019, Roque et al. 2021].
Esta pesquisa investiga o estado atual da prática no que diz respeito ao envolvimento
dos profissionais de saúde no levantamento e validação de requisitos para o desenvolvimento
de aplicações de saúde. Além disso, o estudo examina o potencial do padrão de Arquétipos
openEHR em facilitar o levantamento e a validação do conhecimento específico da área de saúde
por parte dos profissionais. Ao colaborar com esses especialistas, a pesquisa busca determinar se
o padrão de Arquétipos openEHR pode capturar e integrar efetivamente as percepções clínicas
ao ciclo de desenvolvimento de software. Com base nessas investigações, a pesquisa propõe um
conjunto de boas práticas para a fase de levantamento de requisitos, explicitamente voltadas para
aplicações de saúde e utilizando o padrão openEHR.
1.3
1.3.1
OBJETIVOS
Objetivo Geral
Este trabalho tem como objetivo geral investigar a participação do usuário final do
domínio da saúde no ciclo de vida de desenvolvimento de aplicações de softwares. Neste contexto,
busca-se evidências no estado da arte a respeito das fases do processo de desenvolvimento que os
profissionais de saúde têm interação, as categorias de usuários finais presentes nas avaliações das
ferramentas e as técnicas de elicitação de requisitos presentes no ciclo de vida de desenvolvimento
de aplicações de saúde. Este trabalho se propõe ainda a realizar um estudo com profissionais de
saúde e engenheiros de requisitos para analisar se o conhecimento do especialista do domínio
especificado por meio do padrão internacional de saúde denominado arquétipo OpenEHR pode
ser útil para representar os requisitos necessários para o desenvolvimento de aplicações de
saúde. Como contribuição desta pesquisa, espera-se entregar um conjunto de boas práticas que
compreenda a interação do usuário final na fase de elicitação de requisitos de softwares da saúde.
18
1.3.2
Objetivos Específicos
Os objetivos específicos apresentados abaixo delineiam as principais ações a serem
executadas durante o percurso desta pesquisa:
• Investigar na literatura se o domínio do conhecimento de profissionais está sendo levado
em consideração ao desenvolver aplicações da saúde;
• Aplicar questionários a profissionais da saúde com o objetivo de identificar seu perfil e
coletar percepções sobre as ferramentas utilizadas em suas atividades cotidianas;
• Conduzir um estudo exploratório envolvendo profissionais da saúde, no qual estes serão
encarregados de especificar os dados necessários para gerar requisitos em um modelo de
arquétipo OpenEHR;
• Realizar a condução de um estudo exploratório com engenheiros de requisitos, buscando
identificar suas percepções acerca do uso de arquétipos openEHR para elicitar requisitos
de softwares em um ambiente real de desenvolvimento;
• Aplicar testes estatísticos para analisar a significância do arquétipo openEHR como
ferramenta de elicitação de requisitos;
• Propor um conjunto de boas práticas dentro de um ciclo de vida para elicitar requisitos de
softwares na área da saúde utilizando arquétipos openEHR;
1.4
QUESTÃO DE PESQUISA
Assim, este trabalho propõe-se a responder a seguinte questão de pesquisa:
• O uso de arquétipos openEHR na fase de elicitação de requisitos facilita a identificação
e materialização do conhecimento do especialista de domínio no desenvolvimento de
aplicações em saúde?
1.5
METODOLOGIA
O desenho metodológico da pesquisa foi composto por três componentes principais: uma
revisão da literatura e uma abordagem de métodos mistos, que inclui questões com abordagens
qualitativas e quantitativas, além de entrevistas com profissionais da saúde e engenheiros de
requisitos. Essa estrutura é ilustrada na Figura 1.
19
Figura 1 – Metodologia da Pesquisa.
Fonte: Autoria própria, 2024.
A primeira etapa deste estudo consistiu em uma revisão da literatura baseada na proposta
de [Kitchenham 2012], na qual foi realizada uma análise do estado da arte com base na identificação de estudos na área da saúde. Essa análise teve como objetivo identificar os principais
conceitos e contribuições relacionadas à participação de usuários finais no ciclo de vida de desenvolvimento de software na área da saúde, bem como as técnicas utilizadas na fase de elicitação
de requisitos. Os resultados dessa análise foram discutidos e sintetizados, proporcionando uma
base sólida para a proposta desta pesquisa.
A segunda etapa do estudo seguiu uma abordagem de métodos mistos, combinando
métodos qualitativos e quantitativos para compreender melhor os dados coletados a partir de
um formulário aplicado a cento e dezoito profissionais da saúde. Inicialmente, a pesquisa
utilizou uma abordagem quantitativa, focando em perguntas fechadas. Essas perguntas geraram
dados estruturados e facilmente quantificáveis, permitindo a mensuração das respostas. A partir
dessa base de dados, foi construído um perfil, identificando as principais características dos
participantes.
Simultaneamente, foi utilizada uma abordagem qualitativa, com base em perguntas abertas feitas aos participantes para compreender o cotidiano desses profissionais, as ferramentas que
utilizam, seus propósitos e a adequação dessas ferramentas às suas atividades profissionais. Após
a coleta das respostas, os dados qualitativos foram analisados por meio de uma análise temática
20
dedutiva, baseada na proposta de [Braun e Clarke 2006], utilizando temas ou categorias previamente definidas. Essa etapa resultou na identificação de padrões que compõem os resultados
qualitativos da pesquisa.
Na terceira etapa do estudo, foram realizadas entrevistas com vinte profissionais da saúde
e onze engenheiros de requisitos. O foco das entrevistas foi demonstrar arquétipos, simulando sua
aplicação no domínio da saúde, e avaliar a adequação da ferramenta para elicitação de requisitos
de software. Utilizou-se um questionário para coleta dos dados, os quais foram analisados
estatisticamente. Os resultados dessa análise foram discutidos juntamente com os achados das
outras etapas, resultando em uma proposta para a utilização do arquétipo openEHR na fase de
elicitação de requisitos de software.
1.6
ORGANIZAÇÃO DO TRABALHO
A estrutura desta pesquisa consiste em capítulos elaborados com o propósito de proporci-
onar uma compreensão clara e sistematizada do estudo realizado. Este trabalho está estruturado
da seguinte forma:
• O capítulo 2 apresenta o referencial teórico, que corrobora com a compreensão dos
conceitos e definições relevantes para embasar o estudo realizado;
• O capítulo 3 apresenta uma revisão da literatura dos trabalhos correlatos encontrados no
estado da arte, tendo como objetivo identificar se há participação do usuário final durante
o ciclo de desenvolvimento de software de aplicativos da saúde;
• O capítulo 4 apresenta o estado da prática, no qual foi conduzido um experimento com
profissionais da saúde e engenheiros de requisitos. A partir dos dados coletados, foram
aplicadas técnicas estatísticas para analisar a viabilidade do uso do arquétipo openEHR na
elicitação de requisitos;
• O capítulo 5 apresenta boas práticas para a elicitação de requisitos de software utilizando arquétipos openEHR, bem como a representação visual de um ciclo de vida de
desenvolvimento adaptado para o uso dessa técnica;
• Por fim, o capítulo 6 apresenta as conclusões do trabalho, destacando as principais contribuições, as ameaças à validade e as perspectivas para os próximos passos em pesquisas
futuras.
21
2 REFERENCIAL TEÓRICO
No presente capítulo, serão abordados os conceitos fundamentais relacionados ao envolvimento de usuários finais no ciclo de vida de aplicações de software. Nesse contexto, a Seção 2.1
direciona a atenção para a importância da participação dos usuários finais ao longo do ciclo de
vida de aplicações de software. Posteriormente, a Seção 2.2 aborda aspectos relativos à elicitação
de requisitos software. Ainda neste capítulo, mais precisamente na Seção 2.3, é discutido sobre a
estrutura dos arquétipos openEHR. Por fim, na Seção 2.4 é apresentado as considerações finais
deste capítulo.
2.1
CICLO DE VIDA DE APLICAÇÕES DE SOFTWARES
A Engenharia de Software (ES) representa um domínio da ciência da computação res-
ponsável por viabilizar a construção sistemática de softwares por parte dos desenvolvedores
seguindo uma abordagem metodológica [Kumar 2018]. Dessa maneira, surge a representação
conceitual das diferentes fases de desenvolvimento percorridas por um software desde sua concepção, que é caracterizada como o ciclo de vida de software. Este ciclo de desenvolvimento
engloba diversas fases, desde a análise de requisitos até a manutenção, sendo suportado por
diferentes tipos de modelos e metodologias para o planejamento e controle efetivo desse processo
[Leau et al. 2012].
Com isso, existe na literatura diversos modelos de processos de softwares dos quais os
desenvolvedores podem seguir. Esse processo abrange diversas etapas, cada uma com atividades
específicas e objetivos distintos, visando garantir o desenvolvimento, implantação e manutenção
eficientes de uma aplicação. Dentro dessas fases, os profissionais de desenvolvimento de software
aderem a metodologias e práticas específicas para assegurar a qualidade, segurança e funcionalidade da aplicação. Entretanto, independentemente do modelo selecionado, Sommerville (2011)
destaca quatro atividades fundamentais para a ES nesse processo:
• Especificação de software: Nesta fase, as necessidades dos stakeholders são identificadas
e detalhadas de forma clara e compreensível. Isso inclui a definição de requisitos funcionais
(RF) e não funcionais (RNF) que orientarão o desenvolvimento do sistema.
• Projeto e implementação de software: Durante esta fase, os requisitos definidos anteriormente são traduzidos em um design técnico e, posteriormente, implementados em
código.
22
• Validação de software: Nesta fase, o software é submetido a testes e análises rigorosos
para garantir que atenda aos requisitos especificados na fase inicial.
• Evolução de software: Durante essa fase, as atualizações, melhorias e correções são
implementadas para atender às mudanças nas necessidades dos usuários, corrigir falhas
identificadas após o lançamento e incorporar novos recursos.
Com a crescente demanda por flexibilidade e rapidez no desenvolvimento, as metodologias ágeis ganharam destaque nas últimas décadas. As abordagens ágeis, como o Scrum e o
Extreme Programming (XP), propõem ciclos curtos de desenvolvimento, conhecidos como iterações, nos quais os requisitos são refinados e implementados de forma incremental [Tetteh 2024].
O uso dessas tecnologias permite que as equipes respondam rapidamente às mudanças nos
requisitos, garantindo a entrega contínua de valor ao cliente ao longo do ciclo de vida do
software.
Considerando os aspectos citados, para além da preocupação central da ES com o ciclo de
vida do software, a Interação Humano-Computador (IHC) desempenha um papel complementar
quanto aos aspectos de qualidade da solução computacional. Enquanto a engenharia de software
se concentra em aspectos técnicos, como elicitação de requisitos, design, implementação e testes,
a IHC foca na experiência do usuário, considerando fatores como usabilidade, acessibilidade
e satisfação [Barbosa e Silva 2010]. Essa colaboração é essencial em várias fases do ciclo de
vida, especialmente na prototipação e nas fases de validação e refinamento, onde o feedback
dos usuários desempenha um papel crucial na adaptação do software às suas necessidades reais.
Assim, a integração entre as duas áreas permite o desenvolvimento de sistemas não apenas
funcionais, mas também intuitivos e fáceis de usar, garantindo a qualidade tanto do ponto de
vista técnico quanto da interação humana.
A IHC se baseia na compreensão de que o contexto social do indivíduo influencia a forma
como ele enxerga e se comporta perante um sistema de software. Logo, é importante considerar
o contexto social nas atividades de desenvolvimento [Peres e Morais 2021]. Assim, o Design
Centrado no Usuário (UCD), enquanto método de IHC, considera no ciclo de desenvolvimento
a participação ampla do usuário e de outras partes interessadas em atividades iterativas, que
considerem suas expectativas como base de conhecimento para a tomada de decisão, num
processo amplamente colaborativo [Govella 2019].
Em suma, uma abordagem centrada no usuário preconiza que, ao integrar o usuário final
nos processos de desenvolvimento sob uma perspectiva de IHC, em contraste com as abordagens
23
tradicionais da Engenharia de Software, ele não é mais consultado apenas durante a validação.
Em vez disso, é considerado desde as fases iniciais de concepção, ao longo do desenvolvimento
e até mesmo durante a manutenção. Isso inclui atividades que promovem o feedback contínuo,
tornando-se uma maneira de identificar problemas e oportunidades de melhoria ao longo de
todo o processo. Esse ciclo de feedback contínuo permite realizar ajustes e refinamentos para
atender de maneira mais eficaz às necessidades dos usuários, mantendo a tecnologia atualizada e
alinhada às expectativas em constante evolução [Govella 2019].
Voltando às fases do ciclo de vida do software, nas atividades de especificação, a IHC tem
um papel imprecíndivel no que diz respeito a elicitação de requisitos, pois coloca o usuário no centro do processo. Dessa forma, entender como técnicas voltadas a inclusão do usuário final, como
entrevistas, testes de usabilidade e observações, são úteis para identificar requisitos que, muitas
vezes, não são evidentes a partir de uma abordagem puramente técnica [Ferreira et al. 2007].
2.2
ELICITAÇÃO DE REQUISITOS DE SOFTWARE
A IHC enfatiza a participação ativa do usuário final em todas as suas atividades e etapas
de tomada de decisão, apresentando como solução um processo de aprendizagem mais ágil,
que impacta positivamente tanto na qualidade da solução quanto na identificação e correção de
possíveis problemas [Rogers et al. 2013]. Por outro lado, ao considerar processos que não aderem
às abordagens de design de IHC, a qualidade do sistema fica comprometida no que diz respeito à
usabilidade ao analisar a experiência do usuário durante suas interações [Couto et al. 2020].
Uma forma alternativa de abordar o envolvimento do usuário final no ciclo de vida
do software é adotar uma metodologia que ouça as necessidades do usuário, desde a elicitação dos requisitos até a fase final da aplicação, considerando o entendimento do domínio do
problema, e aumentando a aceitação, uso, e fidelidade do sistema ao ambiente natural de uso
[Abras et al. 2004, Stafford et al. 2003, Govella 2019]. A elicitação de requisitos busca compreender as necessidades dos usuários, buscando identificar corretamente os fatos que compõem
as funcionalidades para que haja correção e completude de entendimento do que é requerido
[Leite 1994].
Assim, a Engenharia de Requisitos (ER), área da ES encarregada pela atividade de
elicitação, tem um papel fundamental no desenvolvimento de software. Esta área abrange sete
tarefas distintas, conforme categorização proposta por Pressman (2011), as quais consistem em:
• Concepção: Nesta tarefa, são identificadas as necessidades iniciais do sistema, e a equipe
24
se dedica a compreender o contexto e os objetivos do projeto. A ênfase está na definição
preliminar do escopo e na compreensão das expectativas dos stakeholders.
• Levantamento: A equipe busca coletar informações detalhadas sobre as demandas dos
stakeholders. Utilizando diversas técnicas, o objetivo é obter de maneira abrangente e
precisa os requisitos funcionais e não funcionais que irão orientar o desenvolvimento do
software.
• Elaboração: Nesta tarefa, são trabalhadas as informações coletadas em especificações mais
detalhadas e compreensíveis. Esta etapa identifica relações entre requisitos, a resolução de
conflitos e a definição de prioridades.
• Negociação: As partes interessadas e a equipe de desenvolvimento colaboram para alcançar um consenso sobre os requisitos. Neste processo, conflitos são gerenciados, e
compromissos são estabelecidos, garantindo que as expectativas dos stakeholders sejam
equilibradas com as capacidades e restrições do sistema.
• Especificação: Esta tarefa envolve a documentação detalhada dos requisitos identificados.
Essa documentação serve como base para o design e implementação do software. É crucial
que os requisitos sejam expressos de forma clara, sem ambiguidades, para garantir que a
equipe de desenvolvimento compreenda e implemente as funcionalidades desejadas de
maneira precisa.
• Validação: Nesta tarefa, os requisitos são revisados, verificados e validados quanto à sua
completude, consistência e alinhamento com os objetivos do projeto. Essa etapa ajuda a
evitar problemas futuros durante a implementação.
• Gestão: Envolve o acompanhamento, controle e adaptação dos requisitos à medida que o
projeto evolui. Mudanças nos requisitos são gerenciadas de forma estruturada, garantindo
que o software permaneça alinhado com as necessidades dos stakeholders mesmo diante
de alterações no ambiente ou objetivos do projeto.
Dessa maneira, o levantamento de requisitos é a atividade primária na área de ER, uma
vez que, é nessa etapa que as informações necessárias para o desenvolvimento do software
são obtidas, contribuindo para que haja uma visão clara e abrangente do sistema que vai ser
construído [Kotonya e Sommerville 1998], o que a torna uma tarefa complexa, já que envolve a
25
interpretação de diversas perspectivas e a comunicação eficiente entre membros da equipe de
desenvolvimento e os stakeholders.
Tabela 1 – Tipos de Técnicas de Elicitação de Requisitos mais Utilizadas.
Nome
Entrevistas
Prototipação
JAD
Brainstorming
Questionários
Cenários
Entrevistas em grupo
Técnicas de Elicitação
Descrição
As entrevistas envolvem conversas individuais entre um membro da equipe e o stakeholder, com perguntas diretas para documentar
fatores relacionados aos requisitos.
A prototipação é a criação de uma versão inicial do produto, usada para coletar feedback
dos stakeholders e identificar ajustes para a
próxima versão.
Essa técnica permite coletar muita informação em pouco tempo, exigindo planejamento
antecipado e a presença dos participantes
chave. Eles compartilham opiniões sobre o
que deve ser feito e ajustado.
É uma discussão informal onde os participantes expressam livremente suas ideias para o
desenvolvimento de um novo sistema.
São usados principalmente como uma ferramenta simples, com perguntas abertas ou fechadas na fase inicial da elicitação de requisitos. O objetivo é coletar o máximo de informações de diferentes pessoas, mesmo que
estejam em locais distintos.
Cenários representam as interações dos usuários com o sistema e são usados para criar
narrativas e descrições detalhadas dos processos atuais e futuros necessários para o desenvolvimento do software.
Nesta técnica, um grupo de stakeholders é
reunido para uma consulta coletiva, onde são
discutidas as práticas atuais e as expectativas
para o projeto.
Tipo de Técnica
Tradicional
Grupo
Grupo
Grupo
Tradicional
Grupo
Tradicional
A complexidade inerente aos requisitos de software exige abordagens sistemáticas e
eficazes para garantir que todas as expectativas dos usuários sejam identificadas de maneira
abrangente. Nesse contexto, diversas técnicas de elicitação de requisitos emergem como instrumentos fundamentais, oferecendo métodos estruturados para coletar informações indispensáveis
no contexto do usuário [Barbosa e Silva 2010]. Nesse sentido, a Tabela 1 sintetiza através do
trabalho de [Ignácio et al. 2018] as principais técnicas utilizadas nos últimos anos para elicitar
26
requisitos de software.
A estruturação das técnicas de elicitação é essencial para garantir que os requisitos de
um projeto sejam entendidos de forma clara e precisa desde o início. Sem uma abordagem bem
definida, há o risco de omitir informações cruciais ou interpretar incorretamente as necessidades
dos stakeholders, o que pode levar a retrabalho, atrasos e até ao fracasso do projeto. Técnicas
bem estruturadas, como entrevistas, prototipação e brainstorming, facilitam a comunicação entre
as partes envolvidas e asseguram que os requisitos sejam capturados de maneira completa e
objetiva [Mesquita et al. 2023].
Além disso, essa estruturação permite a coleta de feedback contínuo, promovendo a
adaptação rápida a mudanças e garantindo que o produto final esteja alinhado com as expectativas
e necessidades do cliente. Além disso, a análise da perspectiva de diferentes stakeholders dentro
de um processo de elicitação é um dos principais desafios dessa etapa, já que uma abordagem
com foco no usuário final abrange não apenas aspectos tecnológicos, mas também considera
elementos sociais, indivíduais, informacionais e contextos diferentes [Belgamo e Martins 2000].
2.2.1
Arquétipo OpenEHR
Arquétipo openEHR é um padrão aberto projetado para apoiar o desenvolvimento
de prontuários eletrônicos de saúde (PES) interoperáveis e outras aplicações de saúde
[Palojoki et al. 2024]. Seu principal objetivo é fornecer uma estrutura que garanta uma representação de dados consistente e de alta qualidade, facilitando a troca de informações de saúde entre
diferentes sistemas e plataformas [Badr 2019].
Arquétipos são modelos predefinidos que descrevem conceitos clínicos específicos e os
elementos de dados associados [Moner et al. 2018]. Eles oferecem uma forma estruturada de
capturar e representar o conhecimento médico, como sintomas do paciente, critérios diagnósticos
ou planos de tratamento. Cada arquétipo é projetado para ser flexível e reutilizável, permitindo
uma representação consistente dos dados, ao mesmo tempo que acomoda variações na prática
clínica e nos requisitos [Araújo et al. 2019, Palojoki et al. 2024, Badr 2019, Moner et al. 2018,
Ferreira e Souza 2023].
Os arquétipos, no contexto do openEHR, são ferramentas extremamente robustas para a
representação estruturada e padronizada de informações clínicas. Cada arquétipo é composto
por vários elementos fundamentais que, ao trabalharem em conjunto, garantem uma captura e
representação consistentes de dados clínicos em diversos cenários de saúde. Esses elementos
são responsáveis por definir as regras e limites de cada pedaço de informação, facilitando a
27
interoperabilidade e a compreensão entre diferentes sistemas e profissionais da saúde. A Figura
2 ilustra cada elemento no arquétipo de Avaliação Diagnóstica, cuja explicação é dada abaixo.
Figura 2 – Representação dos Elementos de um Arquétipo.
Fonte: Autoria Própria, 2024.
• Elementos de Dados: São a base do arquétipo e incluem informações como medições
fisiológicas (por exemplo, pressão arterial), observações clínicas (como febre ou nível
de dor) e atributos do paciente (idade, sexo, histórico médico). Esses elementos são
organizados de maneira lógica dentro do arquétipo, de forma que cada informação clínica
relevante possa ser registrada e acessada de maneira precisa e detalhada. Eles são essenciais
para a construção de um prontuário eletrônico completo, permitindo que o sistema capture
toda a variedade de dados necessários para o cuidado ao paciente.
• Restrições: Esse componente define as regras para o preenchimento dos elementos de
dados. Restrições especificam os valores permitidos para cada dado, como faixas aceitáveis
para determinados parâmetros clínicos (por exemplo, uma restrição que permita apenas
valores de pressão arterial dentro de um intervalo clínico considerado normal). Além
disso, as restrições também controlam a relação entre os elementos de dados, garantindo
que os valores sejam coerentes e que as combinações de dados respeitem as diretrizes
clínicas. Isso evita erros e promove a uniformidade dos dados coletados, uma vez que
os profissionais da saúde estarão utilizando as mesmas regras para o preenchimento de
informações.
28
• Terminologias: Esse elemento garante que os dados clínicos capturados estejam conectados a terminologias médicas padronizadas, como SNOMED CT, LOINC, ICD-10, entre
outras. Essas terminologias são fundamentais para garantir a interoperabilidade entre
diferentes sistemas de saúde, pois permitem que os dados registrados em um sistema
possam ser compreendidos por outros, independentemente de onde o paciente esteja sendo
tratado. Por exemplo, o diagnóstico de uma condição em um país poderá ser facilmente
compreendido e utilizado em outro, desde que ambos os sistemas utilizem as mesmas
vinculações terminológicas. Isso facilita não só a comunicação entre sistemas, mas também
a troca de informações entre profissionais e instituições de saúde, tornando o tratamento
do paciente mais eficiente e seguro.
Os arquétipos têm sido amplamente adotados no desenvolvimento de aplicações de
saúde, com diversas implementações demonstrando sua eficácia [Araújo et al. 2019, Leslie 2020,
Chen et al. 2009]. Por exemplo, os arquétipos têm sido usados para padronizar sistemas de prontuários de pacientes, apoiar ferramentas de tomada de decisão clínica e facilitar a integração de
dados de saúde provenientes de várias fontes [Palmer e Simms-Cendan 2012, Ding et al. 2023,
Garcia et al. 2014]. Essas aplicações demonstraram que os arquétipos podem melhorar a qualidade dos dados, aprimorar a interoperabilidade dos sistemas e fornecer insights valiosos para
clínicos e pacientes.
Embora os Arquétipos openEHR tenham sido amplamente utilizados no desenvolvimento
e padronização de aplicações de saúde, há evidências limitadas sobre sua aplicação na elicitação
e validação do conhecimento de especialistas de domínio dentro do ciclo de desenvolvimento
de software. O foco principal tem sido o uso de arquétipos para garantir a consistência e
interoperabilidade dos dados, em vez de envolver especialistas do setor na refinação e validação
dos modelos [Wang et al. 2015, Bicer et al. 2005]. Essa lacuna destaca a necessidade de uma
investigação mais aprofundada sobre como os arquétipos podem ser efetivamente empregados
para engajar profissionais de saúde no processo de requisitos, assegurando que as soluções de
software resultantes reflitam com precisão as práticas clínicas e atendam às necessidades dos
usuários finais.
2.3
CONSIDERAÇÕES FINAIS
Concluindo este capítulo, destaca-se que a Seção 2.1 direcionou a atenção para a impor-
tância da participação do usuário final ao longo do ciclo de vida das aplicações de software. A
29
Seção 2.2, por sua vez, explorou aspectos relacionados à elicitação de requisitos, apresentando
métodos e práticas essenciais para compreender as necessidades dos usuários. Além disso, foi
discutida a estrutura dos arquétipos openEHR.
30
3 TRABALHOS CORRELATOS
Este capítulo delineia a revisão da literatura relacionada ao problema de pesquisa abordado nesta dissertação, estruturando-se da seguinte maneira. A Seção 3.1 expõe a metodologia
empregada na condução da revisão. A Seção 3.2 delineia o planejamento da revisão, seguido pela
Seção 3.3, que aborda a análise do estado da arte. A Seção 3.4 apresenta os resultados obtidos,
seguida pela Seção 3.5, na qual se desenvolve a discussão desses resultados. Por fim, a Seção 3.6
aponta as considerações finais deste capítulo.
3.1
METODOLOGIA DA REVISÃO
Este estudo empregou uma abordagem metodológica baseada no processo estrutu-
rado de uma revisão da literatura, o qual parte de uma pergunta de pesquisa bem definida
e emprega métodos sistemáticos e explícitos para a identificação, seleção e avaliação crítica de estudos pertinentes, envolvendo a coleta e análise de dados provenientes dos estudos
[Moher et al. 2009]. Neste estudo, adotou-se uma abordagem metodológica adaptada daquela
empregada por [Petersen et al. 2015], o qual tem como premissa a divisão do percurso metodológico da revisão em três etapas: Planejamento, Execução e Avaliação.
Figura 3 – Percurso Metodológico da Revisão da Literatura.
Fonte: Autoria própria, 2024.
A Figura 3 ilustra o procedimento metodológico empregado na identificação de trabalhos
31
relacionados, conforme adotado para mapear o cenário atual de pesquisa. Na fase de planejamento, foi definido o objetivo, uma questão de pesquisa foi formulada, seguida da definição da
estratégia de busca, seleção dos repositórios de busca e critérios de seleção. Posteriormente, a
fase de execução compreendeu a aplicação da estratégia de busca nas bases de dados pertinentes,
com a subsequente coleta dos dados resultantes. Por fim, na etapa de avaliação, o que culminou
na seleção e análise dos trabalhos pertinentes.
3.2
PLANEJAMENTO DA REVISÃO
Esta seção delineia o planejamento da revisão da literatura proposta. Nesse sentido, a
Subseção 3.2.1 apresenta os objetivos da pesquisa e suas questões, enquanto a Subseção 3.2.2
define a estratégia de busca. A Subseção 3.2.3 aborda os repositórios de busca utilizados, seguida
pela Subseção 3.2.4, que discorre sobre os critérios de seleção adotados. Por fim, a Subseção
3.2.5 demonstra a execução da estratégia de busca e documenta os resultados obtidos.
3.2.1
Objetivo e Questões de Pesquisa
Esta revisão pesquisa na literatura evidências do envolvimento do usuário final no ciclo de
vida de desenvolvimento de aplicativos de saúde. Especificamente, investiga se o conhecimento
do usuário final sobre o domínio do problema foi considerado ao elicitar requisitos e construir
interfaces gráficas de usuário. Também examina quais técnicas foram utilizadas na especificação
e validação das ferramentas, além de identificar quais categorias de usuários finais do setor de
saúde estão presentes nos estudos. Ao final da pesquisa, pretende-se responder às seguintes
questões:
• Q1: Existem evidências da participação do usuário final no ciclo de vida de desenvolvimento de aplicações de saúde?
• Q2: Os desafios encontrados no estado da arte estão relacionados ao uso (ou não) de
técnicas de IHC no desenvolvimento de aplicações em saúde?
3.2.2
Definição da Estratégia de Busca
A estratégia de busca foi definida considerando os principais tópicos da pesquisa, utili-
zando a combinação de palavras-chave relevantes e operadores booleanos. O primeiro termo utilizado foi "HCI"ou "HUMAN-COMPUTER INTERACTION", buscando artigos que abordam a interação humano-computador. Em seguida, os termos "USABILITY"ou "REQUIREMENT"foram
32
incluídos para identificar estudos focados na usabilidade e nos requisitos funcionais, aspectos
essenciais para a experiência do usuário em sistemas de informação em saúde.
O termo "HEALTHCARE"foi adicionado para garantir que os artigos estejam relacionados ao contexto dos cuidados de saúde, enquanto "INFORMATION SYSTEMS"foi inserido para
buscar artigos sobre sistemas de informação, componente central da análise. Por fim, os termos
"HEALTHCARE APPLICATION"ou "HEALTH INFORMATION SYSTEMS"foram incluídos
para identificar artigos que mencionam especificamente aplicativos de saúde ou sistemas de
informação em saúde, fornecendo uma abordagem mais específica ao contexto da pesquisa.
Figura 4 – String de Busca.
Fonte: Autoria própria, 2024.
Desse modo, a string de busca resultante foi: (HCI OR “HUMAN-COMPUTER INTERACTION”) AND (USABILITY OR REQUIREMENT) AND HEALTHCARE AND “INFORMATION SYSTEMS” AND (“HEALTHCARE APPLICATION” OR “HEALTH INFORMATION SYSTEMS”). Para melhor visualização, a Figura 4 ilustra a string de busca com os termos
utilizados e sua conexão lógica.
3.2.3
Definição dos Repositórios de Busca
Com a string de busca previamente estabelecida, procedeu-se à seleção das bases de
dados, sendo definidas as quatro principais referentes ao domínio da computação, sendo elas:
ACM Digital Library, Springer, IEEE Xplore e ScienceDirect. Adicionalmente, optou-se pela
inclusão da base de dados PubMed, em virtude da fronteira existente entre as áreas da saúde e da
computação, o que resulta na publicação de artigos em ambos os campos. Além da significativa
33
relevância inerente a tais repositórios, a seleção desses recursos também encontra justificativa na
viabilidade de acesso institucional por meio do Portal de Periódicos da CAPES (Coordenação de
Aperfeiçoamento de Pessoal de Nível Superior).
3.2.4
Critérios de Seleção
Nesta fase, a aplicação de critérios de inclusão e exclusão desempenhou um papel
essencial no filtro dos resultados, com o objetivo de identificar estudos alinhados com o escopo
da pesquisa. A utilização desses critérios foi necessária para assegurar que apenas as publicações
mais relevantes fossem selecionadas para análise, possibilitando a construção de uma base
de conhecimento sólida sobre a temática e uma compreensão aprofundada do estado atual da
pesquisa.
Para os critérios de inclusão, foram considerados artigos que estão disponíveis em texto
completo, não fossem duplicados e estivessem diretamente relacionados à pesquisa. Já para os
critérios de exclusão, restringiu-se a seleção a estudos publicados em periódicos ou revistas,
escritos em inglês, que descrevessem o desenvolvimento de software na área de saúde, e que
tivessem sido publicados no período de 2018 a 2023.
Figura 5 – Critérios de Seleção.
Fonte: Autoria própria, 2024.
34
A escolha do recorte temporal de cinco anos (2018–2023) justifica-se pela rápida evolução
tecnológica na área de desenvolvimento de software para saúde. Esse período permite uma
análise atualizada das soluções, identificando mudanças recentes que impactam diretamente o
desenvolvimento de soluções em saúde. Por fim, a etapa seguinte do processo consistiu na leitura
integral de todos os estudos previamente selecionados, permitindo a descrição das contribuições
e o desenvolvimento de cada trabalho. A Figura 5 ilustra os critérios de inclusão e exclusão
adotados para a seleção dos estudos.
3.2.5
Execução da String de Busca e Documentação dos Resultados
Na sua totalidade, os 307 estudos identificados resultaram da consulta às cinco bases
de dados selecionadas, distribuídos da seguinte forma: 56 da base de dados da ACM, 160 da
Springer, 32 da IEEE Xplore, 56 da ScienceDirect e 3 da PubMed. Entretanto, após a leitura do
resumo e resultados, foram inicialmente escolhidos para a fase subsequente, sendo que apenas 27
destes foram considerados pertinentes e, portanto, selecionados para integrar a revisão. A Figura
6 representa o esboço da identificação desses estudos, que examinou e descreveu cuidadosamente
as principais contribuições e a execução do desenvolvimento individual em cada estudo.
Deste modo, a seção subsequente aborda uma análise dos trabalhos identificados no
estado da arte que se relacionam com a proposta apresentada nesta dissertação. Isso permitirá
uma compreensão aprofundada das contribuições existentes e dos avanços já alcançados na área
de pesquisa em questão, ao mesmo tempo em que evidenciará como o presente trabalho se insere
e contribui para o desenvolvimento desse campo do conhecimento.
35
Figura 6 – Seleção dos Estudos.
Fonte: Autoria própria, 2024.
3.3
ANÁLISE DO ESTADO DA ARTE
A constante criação de soluções computacionais com diferentes propósitos e escopos
evidencia a diversidade de aplicações de software no setor de saúde. Essa investigação identificou
vinte e sete estudos, que puderam ser categorizados em quatro tipos diferentes de software:
software de cuidados em saúde, redesenho de software, comunicação e informação em saúde, e
sistemas de gestão em saúde. Essa categorização foi realizada com o objetivo de agrupar estudos
com objetivos semelhantes, estabelecendo conexões dentro de cada grupo identificado. Além
disso, a análise consistiu em quatro fases primárias do processo do ciclo de vida do software:
elicitação de requisitos, prototipação, desenvolvimento de aplicações e avaliação.
Para resolver falhas de comunicação dos profissionais da saúde durante a fase de administração de medicamentos, o estudo de [Alabdulhafith et al. 2018] desenvolve o aplicativo
"Medication Administration Communication (MAC)"para melhorar a comunicação entre enfermeiros, médicos e farmacêuticos durante a administração de medicamentos. Na fase de elicitação
de requisitos, apenas enfermeiros participaram das entrevistas semiestruturadas. A participação
do usuário final foi mencionada apenas nas etapas de elicitação de requisitos e avaliação do soft-
36
ware, com foco na usabilidade, utilizando os modelos "Health-ITUEM"e "Health-ITUES"para
avaliar a facilidade de uso e a utilidade do sistema.
Por outro lado, [Jacobs et al. 2018] apresenta o aplicativo "MyPath", voltado para pacientes diagnosticados com câncer, que são os usuários finais. No entanto, o trabalho não detalha
a metodologia usada para elicitação de requisitos ou avaliação do sistema. A participação do
usuário final foi mencionada apenas na fase de avaliação, sem envolvimento nas demais etapas
do desenvolvimento.
Da mesma forma, [Koumpouros 2021] desenvolveram o "PainApp", voltado para pacientes com dor crônica ou aguda e seus médicos, utilizando a metodologia centrada no usuário
(UCD). Os usuários finais participaram de todas as etapas de desenvolvimento do software,
incluindo a fase de elicitação de requisitos por meio de grupos focais. No entanto, não foi
utilizado nenhum método formal de avaliação da usabilidade. A avaliação do aplicativo foi
realizada através de um processo de reflexão em voz alta pelos usuários finais, com a geração de
feedbacks para trabalhos futuros.
Outro estudo, conduzido por [Ishak et al. 2021], explorou a viabilidade de integrar tecnologias de nuvem na saúde, desenvolvendo um sistema protótipo com base no feedback de
administradores do sistema, pacientes e médicos. A fase de elicitação de requisitos foi realizada
por meio de entrevistas, mas não está claro se todos os três grupos de usuários finais participaram
dessa etapa. A usabilidade foi avaliada com base nas diretrizes de Nielsen e uma avaliação
semiótica, envolvendo os três grupos de usuários, mas o estudo não especifica se houve uma
avaliação separada para cada grupo.
O redesenho do site do Departamento de Saúde de Surabaya, descrito no estudo de
[Puspitasari et al. 2018] contou com o envolvimento de provedores de saúde, governo e comunidade. A fase de elicitação de requisitos contou com entrevistas com o gestor do site e os próprios
usuários. A avaliação de usabilidade foi realizada através de um questionário heurístico com
dez indicadores, medidos pela escala Likert, envolvendo os usuários finais apenas na fase de
avaliação.
Em uma abordagem distinta, [Falcão et al. 2019] propuseram um aplicativo para prevenir
doenças transmitidas pelo mosquito Aedes aegypti, envolvendo a população como usuário final.
No entanto, o artigo não inclui uma fase de elicitação de requisitos com os usuários finais,
baseando-se apenas em uma revisão de literatura sobre Interação Humano-Computador (IHC)
e usabilidade. A avaliação do aplicativo foi realizada por meio de um questionário aplicado
aos usuários para medir seu conhecimento sobre prevenção de doenças e suas opiniões sobre o
37
software, sem a utilização de métodos específicos para validar a usabilidade.
Na área de comunicação, [Hefny et al. 2021] apresentaram o chatbot Chansey, desenvolvido para fornecer informações sobre a COVID-19. Não foi realizada uma elicitação de requisitos
diretamente com os usuários finais, sendo os requisitos baseados em uma revisão heurística de
24 chatbots existentes. Durante o desenvolvimento, não houve a participação de profissionais
da saúde para validar as informações fornecidas. A usabilidade foi avaliada apenas na fase de
validação do software, utilizando a escala System Usability Scale (SUS), sendo esta a única
interação direta com os usuários finais.
Adicionalmente, [Roque et al. 2021] desenvolveram o chatbot BotCovid para orientar
a população e combater a desinformação sobre a COVID-19. A elicitação de requisitos não
foi explicitamente realizada com os usuários finais, sendo o sistema concebido a partir de uma
revisão da literatura. A avaliação foi realizada utilizando a SUS, e os usuários participaram apenas
na fase de validação, sem o envolvimento de profissionais de saúde durante o desenvolvimento.
Por outro lado, o software JointCalc, descrito por [Zotov et al. 2020], foi desenvolvido
para pacientes que consideram a substituição de articulações. Os pacientes foram incluídos em
todas as fases do desenvolvimento, desde a concepção até a validação. A análise de requisitos foi
realizada por meio de consultas diretas com os pacientes, proporcionando feedback contínuo que
ajudou a identificar e corrigir falhas no design.
O estudo de [Rezaei-Hachesu et al. 2018] desenvolve um sistema de vigilância da Resistência Antimicrobiana (RAM) para Unidades de Terapia Intensiva Neonatal (UTINs) no Irã,
com os prestadores de cuidados de saúde como principais usuários. Não houve participação de
profissionais de saúde na fase de elicitação de requisitos. A usabilidade foi avaliada através do
User Experience Questionnaire (UEQ) por 11 usuários qualificados, e a participação do usuário
final foi registrada apenas na fase de validação do software.
Em outro contexto, [Martini et al. 2022] conduziram uma avaliação do redesenho de um
software para um robô na área de saúde, focado no aprimoramento do processo de medicação.
Os usuários finais incluem profissionais de farmácia e estudantes da área da saúde. Embora o
trabalho trate de um redesenho, não houve um desenvolvimento centrado no usuário durante a
concepção da nova versão do software, "RoboGen2". A fase de elicitação de requisitos não foi
detalhada, pois o sistema original, "RoboGen", já estava em uso. A avaliação da usabilidade foi
realizada com o System Usability Scale (SUS) e entrevistas semiestruturadas com farmacêuticos,
coletando percepções e necessidades dos usuários, focadas na comparação entre as versões
RoboGen e RoboGen2.
38
Em relação à decisão clínica, [Fico et al. 2019] propuseram a adoção de um Sistema de
Apoio à Decisão Clínica para o tratamento de diabetes tipo 2 (DT2), destinado a profissionais
de saúde, como médicos, gestores e enfermeiros. A análise de requisitos foi realizada de forma
abrangente, utilizando grupos focais clínicos e o processo de hierarquia analítica, com a participação de profissionais de diversas áreas. A avaliação do sistema envolveu as Heurísticas de
Nielsen, o questionário AttrakDiff e o System Usability Scale (SUS), garantindo uma análise
completa da usabilidade e experiência do usuário, focada nas necessidades dos profissionais de
saúde.
Outro exemplo é o desenvolvimento de um aplicativo farmacêutico voltado para deficientes visuais, proposto por [Nimmolrat et al. 2021]. A análise de requisitos foi realizada por meio
de entrevistas, envolvendo ativamente os usuários finais em todas as fases do desenvolvimento.
A usabilidade foi uma prioridade, guiada por diretrizes de Interação Humano-Computador (IHC)
e validada por meio de entrevistas com os usuários. No entanto, não houve envolvimento de
profissionais de saúde no processo de desenvolvimento do aplicativo.
Por sua vez, [Chatterjee et al. 2022] propuseram o aplicativo ProHealth eCoach, projetado para promover um estilo de vida saudável. A análise de requisitos foi realizada através
de grupos focais com profissionais de saúde e pacientes. A equipe de desenvolvimento incluiu
especialistas em Interação Humano-Computador (IHC) e informática em saúde, adotando uma
abordagem de Design Centrado no Usuário (UCD). No entanto, não foram realizados testes de
usabilidade ou mencionadas técnicas de validação do software, sendo sugeridas para pesquisas
futuras.
O aplicativo "Life Beyond", descrito por [Veale et al. 2019], foi desenvolvido para pessoas afetadas pelo câncer. A elicitação de requisitos foi realizada por meio de entrevistas
semiestruturadas com os usuários finais. O desenvolvimento contou com a colaboração de nutricionistas, profissionais de saúde, clínicos gerais e oncologistas, garantindo uma abordagem
multidisciplinar. A usabilidade do aplicativo foi avaliada utilizando a Escala de Usabilidade do
Sistema (SUS) e complementada com entrevistas para obter feedback detalhado dos usuários
sobre diferentes aspectos da aplicação.
Já o aplicativo "Thea", desenvolvido por [Francese et al. 2021], foi direcionado para
cuidadores e familiares de crianças com Transtorno do Espectro Autista (TEA). A elicitação
de requisitos foi realizada por meio de grupos focais, envolvendo tanto cuidadores quanto
profissionais da área, garantindo uma compreensão detalhada das necessidades dos usuários. Os
cuidadores participaram ativamente em todas as fases do desenvolvimento. A usabilidade foi
39
avaliada utilizando o User Experience Questionnaire (UEQ) e a escala Likert, proporcionando
tanto dados qualitativos quanto quantitativos sobre a experiência do usuário.
Para a avaliação de saúde relacionada à asma, [Quinde et al. 2019] desenvolveram uma
solução baseada no Asthma Control Questionnaire (ACQ). A elicitação de requisitos foi realizada
por meio de uma revisão da literatura e entrevistas com usuários finais, incluindo pessoas com
asma e seus cuidadores. A usabilidade foi abordada apenas na fase de avaliação, utilizando o
modelo Health-ITUEM. Não houve envolvimento de profissionais médicos no desenvolvimento.
Um dos principais resultados foi a proposta de melhorias na interface gráfica do usuário (GUI),
visando torná-la mais intuitiva e fácil de usar, especialmente em um contexto de saúde.
Ademais, [Islam et al. 2023] apresentaram um sistema vestível para prever riscos de
doenças cardiovasculares com base em monitoramento em tempo real. A coleta de requisitos foi
realizada por meio de uma revisão da literatura. A usabilidade do sistema foi avaliada utilizando
a Escala de Usabilidade do Sistema (SUS), com a participação de médicos e pacientes na fase de
avaliação. No entanto, a participação de médicos e usuários finais se concentrou na validação e
avaliação do sistema, sem envolvimento significativo nas demais etapas de desenvolvimento.
O aplicativo PowerFIT, descrito por [Ladwa et al. 2018], focou na prevenção da obesidade, utilizando princípios de design persuasivos. A coleta de requisitos foi realizada em duas
iterações com grupos focais, sem a participação de profissionais de saúde durante o desenvolvimento. A usabilidade foi avaliada na etapa de avaliação, utilizando o Think Aloud Protocol
como método de avaliação individual.
O estudo de [Marinho et al. 2019] desenvolve o Sistema de Apoio à Gestão de Informações de Biobancos e Biorrepositórios (SIBIBio), uma aplicação móvel. A análise de requisitos
foi baseada exclusivamente em uma revisão da literatura, sem participação ativa dos usuários
finais, representados por profissionais de pesquisa em saúde, durante o desenvolvimento. A
participação dos usuários ocorreu apenas na fase de avaliação, utilizando o System Usability
Scale (SUS) para medir a usabilidade do sistema.
A ferramenta HAVEN, desenvolvida por [Dahella et al. 2020] foi projetada para identificar precocemente pacientes em estado de deterioração e prevenir internações não programadas
na UTI. A análise de requisitos foi conduzida com entrevistas de análise de tarefas cognitivas e
Card Sort, envolvendo a equipe clínica. Os principais usuários incluem cuidadores, enfermeiros
e médicos. No entanto, os autores não especificaram métodos de Interação Humano-Computador
(IHC) ou usabilidade, nem a participação dos usuários finais no desenvolvimento, mencionando
apenas o uso de feedbacks da equipe clínica para melhorias futuras.
40
O estudo de [Maeda et al. 2019] desenvolveu um serviço de assistência à memória utilizando agentes virtuais, voltado para idosos com desafios de perda de memória. Não houve
participação direta dos usuários finais ou de profissionais de saúde na fase de elicitação de
requisitos, nem a aplicação de técnicas de Interação Humano-Computador (IHC) nesse processo.
A única interação com os usuários ocorreu na fase de avaliação, mas sem a documentação de
técnicas de usabilidade utilizadas.
O estudo de [Giachelle et al. 2021] apresenta o MedTAG, uma ferramenta de anotação
biomédica personalizável e colaborativa. A definição de requisitos foi baseada na análise de
ferramentas existentes, sem a participação dos profissionais biomédicos, que são os usuários
finais, em nenhuma fase do desenvolvimento. Não foram estabelecidos requisitos de Interação
Humano-Computador (IHC), e a usabilidade não foi um foco da aplicação, resultando na ausência
de avaliação sob essa perspectiva.
O estudo de [Lehmann et al. 2022] apresenta o AINA, um aplicativo de Inteligência
Artificial para auxiliar no diagnóstico da Esquistossomose Genital Feminina. Os usuários finais, incluindo médicos, enfermeiras e parteiras, participaram ativamente de todas as fases do
desenvolvimento do software. A análise de requisitos envolveu entrevistas com os usuários,
criação de personas e fluxogramas de tarefas. A usabilidade foi uma prioridade, com avaliação
baseada nas heurísticas de Nielsen, videoconferências participativas, o método "pensar em voz
alta"e considerações de Material Design. Essa abordagem destacou o foco na usabilidade e na
incorporação das perspectivas dos usuários finais.
Outro exemplo é o aprimoramento do StuntingDB, com o módulo "Stassy", descrito por
[Rahutomo et al. 2022]. A análise de requisitos foi realizada em reuniões Scrum e com a criação
de personas para entender as necessidades dos usuários. Embora tenha sido utilizado o Ágil
UX no desenvolvimento, os autores não detalham a participação efetiva dos usuários finais nas
diversas etapas, e não houve envolvimento de profissionais de saúde. Além disso, a metodologia
de avaliação do sistema não foi especificada, dificultando a análise do rigor na avaliação da
usabilidade e eficácia do módulo.
O estudo de [Faizzati e Arifiansyah 2022] desenvolve um Aplicativo de Rastreamento de
Fertilidade (FTA) com foco na resolução de problemas de design de interação enfrentados pelas
usuárias. A abordagem centrada no usuário (UCD), baseada na norma ISO 9241-210, envolveu
usuárias em todas as etapas do desenvolvimento, com a análise de requisitos realizada por meio
de avaliações de ferramentas existentes, pesquisas quantitativas e entrevistas. No entanto, não
houve participação de profissionais de saúde no desenvolvimento. A usabilidade foi avaliada
41
utilizando as métricas Single Ease Question (SEQ) e System Usability Scale (SUS).
Por fim, no estudo de [Bacungan et al. 2021], foi desenvolvido um aplicativo web e
móvel para tele-reabilitação combinada, voltado para pacientes com hipertensão, profissionais de
saúde e um administrador. No entanto, o estudo não apresentou uma análise formal de requisitos,
baseando-se em uma conversa informal com os usuários finais. Além disso, os usuários finais
não participaram efetivamente do desenvolvimento da aplicação, o que pode ter impactado
a usabilidade e relevância. A avaliação do sistema envolveu apenas profissionais de saúde,
excluindo os pacientes, com a usabilidade medida pela System Usability Scale (SUS).
3.4
RESULTADOS
Nesta seção, são apresentados os resultados obtidos por meio da análise do estado da
arte dos estudos destacados na Seção 3.3. As subseções a seguir são categorizadas e organizadas
da seguinte maneira: A Subseção 3.3.1 aborda os estudos selecionados por categoria, incluindo
os tipos de usuários finais identificados e a quantidade observada em cada estudo. Em seguida,
a Subseção 3.3.2 oferece uma análise detalhada da participação dos usuários finais na fase de
construção do software, bem como o envolvimento de profissionais da saúde nesse processo. A
Subseção 3.3.3 explora as técnicas de elicitação de requisitos identificadas nos estudos, enquanto
a Subseção 3.3.4 apresenta uma análise detalhada dos métodos de avaliação de softwares
encontrados na literatura revisada.
3.4.1
Categoria dos Estudos Selecionados
A diversidade de aplicações na área da saúde é evidenciada pela constante criação
de softwares com diferentes propósitos e abrangências. Nesse contexto, para aprofundar a
compreensão dos estudos abordados neste trabalho, tornou-se essencial identificar e categorizálos. A análise criteriosa desses estudos permitiu a identificação de vinte e sete trabalhos no
total, onde puderam ser categorizados em quatro tipos diferentes de softwares: softwares de
assistência em saúde, redesenho de software, informação e comunicação em saúde, e sistemas
de gerenciamento em saúde. Essa categorização foi realizada de maneira a agrupar estudos
que possuíam objetivos semelhantes, estabelecendo conexões entre eles dentro de cada grupo
identificado.
Dessa maneira, foi possível identificar um total de 14 Softwares de Assistência em Saúde,
os quais agregam estudos voltados para o desenvolvimento de aplicações destinadas a auxiliar
profissionais da saúde no atendimento a pacientes, diagnósticos, tratamentos ou acompanhamento
42
de tratamentos. O principal objetivo desses estudos é aprimorar o suporte oferecido e a qualidade
do cuidado prestado em diversas áreas da saúde. Além disso, dois estudos foram identificados
como pertencentes à categoria de Redesenho de Software, abordando trabalhos que buscam
melhorias na usabilidade, eficiência operacional ou a incorporação de novas funcionalidades
para atender a demandas no contexto da saúde, não abordadas na versão anterior.
Outros oito trabalhos foram categorizados como pertencentes ao grupo de Informação
e Comunicação em Saúde, abrangendo estudos direcionados ao desenvolvimento de sistemas
que facilitam a troca de informações entre profissionais de saúde, instituições e pacientes, ou
ainda sistemas destinados a informar o paciente sobre determinadas condições de saúde. Por
fim, foram identificados três estudos pertencentes à categoria de Sistemas de Gerenciamento em
Saúde, os quais se concentram em softwares dedicados ao gerenciamento eficaz de informações
e à administração de serviços de saúde. A Figura 7 ilustra esses dados para melhor visualização.
Figura 7 – Categorias dos Estudos.
Fonte: Autoria própria, 2024.
Considerando a natureza dos softwares na área da saúde, seis tipos de Usuários Finais
foram identificados. Neste estudo, conforme demonstra a Figura 8 foram classificados dois
núcleos distintos: o Núcleo da Saúde, composto por usuários finais do tipo paciente, estudantes
43
da área da saúde e profissionais da saúde; e o Núcleo Administrativo, composto por usuários do
tipo governo, oficiais de saúde pública e administradores. É válido ressaltar que, embora esses
usuários tenham sido identificados nos estudos, não necessariamente estão todos presentes em
cada pesquisa analisada.
É importante ressaltar que, no contexto dos usuários do tipo profissionais da saúde, em
alguns estudos, é observada a presença de mais de um tipo de usuário final nessa categoria. Tal
diversidade pode abranger diferentes profissões, incluindo médicos, enfermeiros e farmacêuticos.
Diante dessa complexidade, optou-se por categorizar em um único tipo de usuário, mas quantificar
para a informação não ser perdida. Dessa forma, foi desenvolvida a Figura 9 com o intuito de
facilitar a visualização dessas informações. A Figura foi concebida para proporcionar uma
representação gráfica que será utilizada como base para discussão na Seção 3.4 do presente
estudo.
Figura 8 – Tipos de Stakeholders.
Fonte: Autoria própria, 2024.
Ainda nesse contexto, a Figura 9 é desenvolvida para representar a quantidade de tipos de
usuários finais presentes nos estudos, fornecendo uma quantificação visual. Foram identificados
18 trabalhos que possuem apenas 1 tipo de usuário final, 2 trabalhos que possuem 2 usuários
finais e 7 estudos que possuem 3 tipos de usuários finais distintos. Além disso, observa-se a
presença de oito agrupamentos distintos de tipos de usuários finais em cada estudo. Estes agrupamentos incluem estudos que têm exclusivamente o paciente como usuário final, estudos que têm
apenas profissionais da saúde como usuários finais, estudos que envolvem tanto profissionais da
saúde quanto estudantes da área, estudos que possuem pacientes e profissionais da saúde como
usuários finais, estudos que contemplam unicamente oficiais de saúde pública como usuários
finais, estudos que envolvem profissionais da saúde e administradores, estudos que incluem
44
pacientes, profissionais da saúde e administradores, e, por fim, estudos que abrangem pacientes,
administradores e governo como tipos distintos de usuários finais.
Ademais, destaca-se a evidente demanda e contribuições em aplicações que têm como
usuário final o paciente, uma vez que essa categoria está presente de forma exclusiva em 14 dos
27 trabalhos analisados e de forma colaborativa com outros tipos de usuários finais em mais 4,
totalizando 18 aplicações direcionadas a esse público. Em contrapartida, apenas 6 softwares têm
como usuário final exclusivamente os profissionais da saúde, sendo que destes, 5 são classificados
como de assistência em saúde. No entanto, é importante ressaltar que os profissionais da saúde
estão presentes de forma colaborativa em outros 6 softwares, totalizando assim 12 trabalhos em
que essa categoria de usuários está envolvida. Seguindo este contexto, a Seção 3.3.2 descreve o
envolvimento desses usuários finais nas fases de desenvolvimento de software, que vão desde a
concepção até a avaliação.
Figura 9 – Quantidade e Combinações de Usuários Finais por Estudo.
Fonte: Autoria própria, 2024.
45
3.4.2
Participação dos Usuários Finais nas Fases de Desenvolvimento do Software
A apresentação dos dados relacionados à participação dos usuários finais no ciclo de
vida do software é de suma importância nesse estudo. Os resultados apresentados é importante,
não apenas pelo quanto os usuários estão envolvidos, mas também oferecem insights valiosos
sobre como essa colaboração influencia diretamente a qualidade e a relevância do software final.
Essa análise destaca a variabilidade nos níveis de envolvimento do usuário final ao longo das
diferentes fases do desenvolvimento de software, evidenciando nuances nas práticas adotadas
pelos estudos examinados.
A Figura 10 apresenta a identificação dos estudos, ano de publicação e a fase do ciclo de
vida em que pelo menos um tipo de usuário final está ativamente envolvido nesse processo. É
relevante destacar que as fases foram categorizadas de acordo com o ciclo de vida padrão de
desenvolvimento de software. Neste contexto, a Fase 1 corresponde a elicitação de requisitos,
a Fase 2 equivale a criação de protótipos da aplicação, a Fase 3 abrange o desenvolvimento da
aplicação, e, por fim, a avaliação da ferramenta é representada pela Fase 4 na tabela.
46
Figura 10 – Envolvimento dos Usuários Finais
Fonte: Autoria própria, 2024.
Ao realizar uma análise individual, observa-se que, dentre os 27 estudos, apenas 15
envolvem ativamente o usuário final durante a fase de elicitação de requisitos. Ademais, 10
47
estudos evidenciam a participação do usuário final na etapa de prototipagem do software, e
esses mesmos 10 demonstram a interação do usuário final durante a fase de desenvolvimento. É
notável ainda uma predominância onde 21 estudos mostram a inclusão do usuário final na fase
de avaliação da ferramenta.
Ao analisar os dados de forma mais ampla, pode-se perceber que dois trabalhos não
incluem o usuário final em nenhuma etapa específica do ciclo de vida do software, contrastando
com os oito estudos que englobam a participação do usuário final em todas as fases do ciclo
de vida da aplicação. Além disso, dois trabalhos envolvem o usuário final apenas na fase de
elicitação de requisitos, e dez trabalhos apenas na avaliação de ferramentas. Não há estudos que
envolvem usuário apenas na prototipação ou apenas no desenvolvimento da ferramenta, sendo
possível notar que todos os estudos em que há participação do usuário na fase 2, automaticamente,
há participação na fase 3.
Para além desses dados, a identificação de tipos distintos de usuários finais, aliada à
evidente variedade na quantidade de categorias de usuários por aplicação, conforme apresentado
na Subseção 3.3.1, surgiu a necessidade de investigar se todos os tipos de usuários finais
participam das fases específicas do ciclo de vida do software nas quais são inseridos. Além disso,
considerando a natureza dos softwares abordados nesta investigação, e focando no domínio do
conhecimento, já que estes pertencem à área da saúde, buscou-se destacar se houve a presença
e participação de profissionais da saúde nesse processo. Ademais, um enfoque adicional foi
direcionado para compreender se esses profissionais foram considerados, simultaneamente, como
usuários finais das aplicações em questão.
A elaboração da segunda parte da tabela é importante nesse contexto por diversos
motivos. A coluna (QdT+UsE) identifica a quantidade de tipos de usuários finais por estudo,
sendo importante para avaliar a inclusão de diferentes perspectivas durante o desenvolvimento de
software. A coluna (PtT+UsE) permite avaliar se todos os tipos de usuários finais identificados
participaram nas fases específicas do ciclo de vida do software em que sua presença foi destacada.
Isso contribui para a análise da abrangência do envolvimento do usuário ao longo do processo de
desenvolvimento;
Por conseguinte, a coluna (PtPSaúde) é importante ao considerar a natureza dos softwares
na área da saúde, pois identifica se houve participação de profissionais da saúde no processo
de desenvolvimento. E, por fim, a coluna (PdS+UsF) verifica se os profissionais de saúde que
participaram dos estudos também foram considerados usuários finais da aplicação. Esse aspecto
é significativo para compreender a integralidade da participação dos profissionais de saúde, que
48
busca incorporar as experiências práticas e de domínio do conhecimento no ambiente de soluções
na área da saúde.
Este estudo evidencia que, dentre os 27 trabalhos analisados, 25 incorporaram o usuário
final em ao menos uma etapa do ciclo de desenvolvimento de software. Contudo, uma análise
mais detalhada, considerando a inclusão de todos os tipos de usuários finais nesse processo,
revela que somente 20 desses trabalhos contemplaram essa abordagem. Além disso, entre os 27
trabalhos examinados, apenas 11 incorporaram algum profissional da saúde em suas fases de
desenvolvimento.
Vale ressaltar que, mesmo quando quatro trabalhos identificaram profissionais da saúde
como usuários finais, estes não estavam ativamente envolvidos no processo de desenvolvimento.
Adicionalmente, observou-se que em nove trabalhos, houve uma participação conjunta de todos
os tipos de usuários finais, incluindo profissionais da saúde, independentemente destes últimos
serem ou não usuários finais da aplicação em desenvolvimento. Essas constatações indicam
variações significativas na inclusão de usuários finais e profissionais da saúde ao longo dos
estudos investigados.
3.4.3
Técnicas de Elicitação de Requisitos Presentes nos Estudos
A identificação de técnicas de elicitação de requisitos é fundamental no processo de
desenvolvimento de software, pois contribui para garantir que as soluções construídas estejam
alinhadas com as reais necessidades dos usuários. Neste contexto, esta subseção concentrou-se
na análise das técnicas empregadas nos estudos, visando compreender até que ponto essas
abordagens são projetadas com foco nas necessidades dos usuários. Aprofundar-se nas técnicas
utilizadas permite não apenas obter requisitos precisos, mas também desenvolver soluções de
software que sejam funcionais e satisfatórias para os usuários finais.
A Figura 11 ilustra a classificação e a identificação das técnicas de elicitação de requisitos
conforme cada estudo analisado, indicando seis tipos principais de técnicas. Observou-se que,
dos vinte e sete artigos examinados, treze não especificaram a aplicação de nenhuma técnica
formal no processo de elicitação. Dentre as técnicas identificadas, destacam-se: grupos focais,
entrevistas semi-estruturadas, consulta com pacientes, card sort, personas e a Análise de Tarefas
Cognitivas Aplicadas.
49
Figura 11 – Técnicas de Elicitação de Requisitos Encontradas nos Estudos.
Fonte: Autoria própria, 2024.
3.4.4
Métodos de Avaliação dos Softwares Presentes nos Estudos
Para além das técnicas de elicitação de requisitos, esta subseção foca na apresentação
dos métodos de avaliação utilizados para validar os softwares. O objetivo é destacar os métodos
que foram empregados para avaliar as ferramentas. Identificou-se um total de dez métodos
distintos de avaliação, incluindo Avaliação Semiótica, Reflexão em Voz Alta, AttrakDiff, System
Usability Scale (SUS), Health-ITUEM, Health-ITUES, Heurísticas de Nielsen, Single Ease
50
Question (SEQ), Systems and Software Quality Requirements and Evaluation (SQUARE) e User
Experience Questionnaire (UEQ). Esses métodos são reconhecidos por sua capacidade de avaliar
a adequação e a eficiência de interfaces.
Figura 12 – Métodos de Avaliação Presente nos Estudos.
Fonte: Autoria própria, 2024.
A Figura 12 apresenta as técnicas identificadas conforme cada estudo, evidenciando
uma predominância no uso do método SUS, que foi empregado em nove trabalhos. Dos vinte
e sete estudos analisados, dezoito adotaram algum tipo de método de avaliação de software.
No entanto, a figura também revela que nove desses estudos optaram por não utilizar nenhuma
técnica específica para avaliação. Além disso, o método SUS se destaca por aparecer com
predominância, sendo adotadas em nove trabalhos como um método de avaliação, reforçando
sua relevância na identificação de melhorias para a experiência do usuário nas ferramentas
51
desenvolvidas para o setor de saúde.
3.5
DISCUSSÃO
A partir da análise que corroborou com a seleção de vinte e sete artigos alinhados ao tema
definido, foi possível identificar algumas lacunas e desafios na adoção de processos centrados
no usuário, considerando as questões abordadas nesta pesquisa. A Figura 13 evidencia essas
informações.
Figura 13 – Lacunas e Desafios Encontrados nos Estudos.
Fonte: Autoria própria, 2024.
A análise do estado da arte revela uma participação limitada dos usuários finais, especificamente profissionais de saúde, ao longo do ciclo de vida de desenvolvimento de software
voltado para o setor. As evidências mostram que, embora alguns estudos incluam esses profissionais na fase de avaliação, sua participação em outras fases, como levantamento de requisitos
e codificação, é insuficiente ou inexistente. Esse cenário aponta para uma lacuna importante
que é a falta de inclusão consistente dos usuários finais em todas as etapas do desenvolvimento,
corre-se o risco de criar soluções que não atendem adequadamente às necessidades e expectativas dos profissionais de saúde, comprometendo a eficácia dos sistemas desenvolvidos. A falta
de envolvimento desses profissionais nas etapas iniciais pode resultar em aplicações que não
refletem o conhecimento prático e as demandas do setor, limitando a qualidade e o impacto das
soluções tecnológicas na melhoria dos serviços de saúde.
Além disso, os desafios identificados no estado da arte estão fortemente relacionados ao
uso – ou ausência – de técnicas de elicitação de requisitos no desenvolvimento de aplicações de
52
saúde. A análise mostra que muitos estudos não especificam se as técnicas de elicitação e validação empregadas seguem diretrizes ou padrões de boas práticas, o que compromete a consistência
e a qualidade dos resultados. Apenas uma minoria dos estudos utiliza métodos baseados em
padrões técnicos, como heurísticas de Nielsen, método SUS ou diretrizes específicas para o setor
de saúde. Isso demonstra um desafio duplo: além de envolver os usuários finais de maneira mais
consistente, é necessário adotar técnicas que aproximem o usuário final do desenvolvimento da
aplicação. A ausência de práticas estruturadas para a elicitação e avaliação contribui para um
desenvolvimento que, muitas vezes, desconsidera as complexidades do ambiente clínico e as
necessidades reais dos profissionais de saúde, comprometendo, assim, o sucesso das aplicações.
3.6
CONSIDERAÇÕES FINAIS
Este capítulo investigou o papel do usuário final ao longo do ciclo de vida de desen-
volvimento de software no setor de saúde, buscando evidências que respondam às questões
de pesquisa propostas. Em relação à primeira questão, os estudos analisados reconhecem a
importância da participação do usuário final, mas apontam uma falta de evidências concretas
sobre o motivo da baixa inclusão desses usuários em fases importantes do ciclo de vida, como
o levantamento de requisitos. Essa ausência de envolvimento dos profissionais de saúde pode
resultar em desafios significativos, como insatisfação de uso, maior necessidade de manutenção e
descompasso entre as soluções desenvolvidas e as necessidades específicas do ambiente clínico.
Quanto à segunda questão, que explora a relação entre os desafios enfrentados e o uso de
técnicas de elicitação e validação, os resultados indicam que muitos dos problemas identificados
podem ser atribuídos à falta de metodologias robustas e específicas para o contexto da saúde.
Observou-se que a ausência de práticas estruturadas muitas vezes resulta em requisitos mal
definidos, aumentando a probabilidade de falhas no desenvolvimento de soluções tecnológicas
para o setor. A literatura enfatiza a importância de adotar padrões, técnicas e diretrizes que
favoreçam um desenvolvimento centrado no usuário, com foco em atender às necessidades reais
dos profissionais e pacientes. No entanto, poucos estudos demonstram uma aplicação consistente
dessas práticas no domínio da saúde, o que evidencia uma lacuna significativa.
As próximas etapas do estudo focarão no impacto do padrão openEHR na elicitação de
requisitos, avaliando se ele pode aprimorar a definição e validação desses requisitos, além de
melhorar o ciclo de vida de aplicações em saúde, alinhando-as às demandas dos usuários com
maior eficiência e qualidade.
53
4 INVESTIGANDO O USO DE ARQUÉTIPOS NA FASE DE ELICITAÇÃO DE REQUISITOS
Este capítulo está organizado da seguinte forma: a Seção 4.1 aborda os aspectos éticos da
pesquisa; a Seção 4.2 detalha o percurso metodológico; a Seção 4.3 apresenta a construção e o
mapeamento do perfil dos participantes; e a Seção 4.4 descreve o experimento realizado com
profissionais da saúde e engenheiros de requisitos.
4.1
ASPECTOS ÉTICOS DA PESQUISA
Esta pesquisa foi conduzida de acordo com os princípios éticos estabelecidos pela
resolução brasileira, que delineia quatro pilares fundamentais da bioética e dos direitos humanos:
autonomia, não maleficência, beneficência e justiça. Todos os participantes foram devidamente
informados sobre os objetivos e os métodos da pesquisa, sendo assegurados o anonimato, a
confidencialidade dos dados e a natureza voluntária da participação. O estudo foi aprovado pelo
Comitê de Ética em Pesquisa, sob o CAAE 78344424.7.0000.5013.
As interações com os participantes ocorreram somente após a assinatura do Termo de
Consentimento Livre e Esclarecido (TCLE), conforme Anexo B. Os métodos de processamento e
confidencialidade dos dados foram explicados, garantindo a proteção da identidade e de quaisquer
informações sensíveis que pudessem surgir durante as entrevistas ou questionários.
4.2
PERCURSO METODOLÓGICO
O percurso metodológico da parte prática deste estudo se dá em dois momentos distin-
tos. No primeiro momento, o processo inicia com o mapeamento e a construção do perfil dos
profissionais da saúde, utilizando um formulário online, o qual os participantes foram convocados por e-mail, conforme Apêndice A. Essa fase é fundamental para a coleta de dados que
serão posteriormente organizados e tratados. Após a coleta, os dados passam por uma etapa
de organização e tratamento, que envolve processos de limpeza e preparação, assegurando a
qualidade e a consistência das informações. Com os dados organizados e tratados, realiza-se
a análise temática dedutiva com o objetivo de identificar padrões e temas significativos. Os
resultados dessa análise são, então, documentados e utilizados para derivar boas práticas no
desenvolvimento de softwares voltados para a área da saúde.
No segundo momento, a partir das respostas dos 118 profissionais que responderam o
formulário inicial de construção de perfil, são realizadas entrevistas e experimentos práticos com
54
vinte profissionais da saúde. Além disso, foram realizadas entrevistas com onze engenheiros de
requisitos, o qual tinha como principal intuito a demonstração do arquétipo e a especificação
guiada com o arquétipo OpenEHR. A demonstração do arquétipo consiste na apresentação do
modelo aos participantes dos dois grupos, enquanto a especificação guiada utiliza o arquétipo
OpenEHR para orientar a definição de requisitos junto aos engenheiros e aos profissionais
da saúde. Ambas as atividades culminam na avaliação de experiência, onde os participantes
fornecem feedback sobre o processo e preenchem um formulário de experiência sobre as
especificações dos requisitos.
4.3
PRIMEIRO ESTÁGIO: MAPEAMENTO E CONSTRUÇÃO DE PERFIL
Ao aplicar o formulário com os profissionais da saúde, foram obtidas 126 respostas, dos
quais, após a filtragem dos dados, oito respostas foram excluídas da análise por não se adequarem
ao perfil da pesquisa, uma vez que os profissionais não pertenciam ao setor de saúde. Além
disso, o formulário foi composto por perguntas abertas e fechadas, o que permite fazer análises
quantitativas e qualitativas dos dados. Consequentemente, foram analisadas e mapeadas 118
respostas, com o intuito de delinear o perfil da população participante desta pesquisa. Dessa
forma, as subseções a seguir apresentam os resultados da análise quantitativa e qualitativa,
seguidos de uma discussão sobre os dados obtidos.
4.3.1
Análise Quantitativa dos Dados
Inicialmente, o foco do formulário esteve na investigação do perfil demográfico e profissi-
onal dos participantes. Dessa forma, os dados demográficos apresentados na Figura 15 mostram,
respectivamente, a distribuição de participantes por faixa etária, experiência profissional e localização geográfica. A maioria dos participantes (51,7%) está na faixa etária de 25 a 34 anos,
seguida pela faixa de 35 a 44 anos, que representa 22% do total. Participantes de 18 a 24 anos
constituem 14,4%, enquanto aqueles entre 45 e 54 anos e entre 55 e 64 anos representam 10,2%
e 1,7%, respectivamente.
Em relação à experiência profissional, observa-se que metade dos participantes (50%)
possui entre 1 e 5 anos de experiência. Além disso, 17,8% dos participantes têm entre 6 e 10
anos de experiência, enquanto 12,7% apresentam 16 anos ou mais de trajetória profissional. Por
outro lado, 9,3% dos respondentes possuem menos de um ano de experiência, e 7,6% têm entre
11 e 15 anos de experiência profissional. Apenas 2,6% optaram por não responder sobre sua
experiência. Além disso, geograficamente, a grande maioria dos participantes está localizada na
55
Figura 14 – Perfil Demográfico e Profissional dos Participantes da Pesquisa
Fonte: Autoria própria, 2024.
região Nordeste (80,5%), seguida pelas regiões Sudeste (9,3%), Norte (6,8%), e Centro-Oeste
(3,4%), com nenhum participante registrado na região Sul.
A análise das respostas dos 118 profissionais da saúde apresentou uma diversidade
tanto em escolaridade quanto em áreas de atuação, conforme destaca a Figura 15. Em relação
à escolaridade, 33,1% possuem graduação, enquanto 28% completaram uma especialização
ou MBA. Outros 22,9% têm formação em curso técnico, 9,3% estão com especialização ou
MBA incompletos, 4,3% têm mestrado incompleto, e 0,8% possuem mestrado ou doutorado
completos, com mais 0,8% no doutorado incompleto. Quanto à distribuição por área de atuação,
20,3% dos profissionais são técnicos em enfermagem, 19,5% são enfermeiros, 11,9% são
psicólogos, e 8,5% em odontologia. As áreas de farmácia e nutrição representam cada uma 7,6%,
seguidas por fisioterapia e medicina com 5,9% cada. Menores porcentagens são observadas em
fonoaudiologia (2,5%), serviço social (2,5%), técnico em radiologia (4,2%), e outras áreas como
educação física, biomedicina, gestão hospitalar e terapia ocupacional, cada uma representando
0,9% dos profissionais.
56
Figura 15 – Escolaridade e Área
Fonte: Autoria própria, 2024.
Além disso, os dados sobre o ambiente profissional dos participantes (Figura 16) revelam
uma variedade de contextos de atuação. A maioria trabalha em clínicas, representando 45
profissionais (39,8%), seguida por 29 que atuam em Unidades Básicas de Saúde (25,7%) e 19
em serviços de urgência e emergência (16,8%). O setor de assistência farmacêutica conta com
5 profissionais (4,4%), assim como as áreas de maternidade e centros de reabilitação (4,4%
cada). Hospitais gerais empregam 4 profissionais (3,5%), enquanto 3 trabalham em Unidades de
Terapia Intensiva (UTIs) (2,7%). Adicionalmente, 2 profissionais atuam em Centros de Atenção
Psicossocial (CAPS) (1,8%) e 1 em um hospital psiquiátrico (0,9%).
Figura 16 – Ambiente de Atuação Profissional
Fonte: Autoria própria, 2024.
Outro aspecto relevante investigado foi a finalidade das ferramentas digitais utilizadas
pelos profissionais da saúde em suas atividades diárias. Conforme ilustrado na Figura 18,
57
observa-se que a maioria dos profissionais (58,5%) emprega essas ferramentas para registro
de informações e evoluções de pacientes. Além disso, 10,2% utilizam as ferramentas para o
controle de medicamentos e prescrição, enquanto uma parcela menor, de 2,5%, as utiliza para
comunicação interna. Por outro lado, 28,8% dos profissionais relataram não utilizar ferramentas
digitais no dia a dia.
Figura 17 – Finalidade das Ferramentas Utilizadas
Fonte: Autoria própria, 2024.
4.3.2
Análise Temática
A análise qualitativa dos dados considerou as questões 9 e 10 do formulário, conforme
Tabela aplicado aos profissionais da saúde para fornecer uma visão ampla das percepções em
relação à sua participação no ciclo de vida do desenvolvimento de software e ao uso de aplicativos
de saúde em seus ambientes de trabalho. Esta análise avaliou diversos aspectos, incluindo
características técnicas e percepções dos usuários sobre funcionalidade, satisfação, segurança,
interoperabilidade e eficiência. Na análise temática, cada participante será identificado pela letra
"P"seguida de um número único, para garantir a confidencialidade e facilitar a organização das
respostas.
• Participação no Ciclo de Vida do Desenvolvimento de Software
Após a análise dos dados fornecidos pelos participantes, constatou-se que nenhum deles
havia participado do ciclo de vida de desenvolvimento de aplicativos de software. Este achado
está alinhado com os resultados do estado da arte, onde a literatura revela um padrão consistente
de envolvimento limitado dos profissionais de saúde nesses processos. A falta de participação
58
dos profissionais corrobora a análise mais ampla, destacando uma lacuna significativa entre o
desenvolvimento de tecnologias de saúde e o envolvimento dos usuários finais. Essa desconexão
levanta questões essenciais sobre a eficácia com que os aplicativos de software atendem às necessidades dos provedores de serviços de saúde e reforça a necessidade de estratégias que promovam
maior colaboração entre desenvolvedores e profissionais de saúde no design e implementação de
soluções tecnológicas.
• Funcionalidades
Os participantes relataram experiências variadas em relação às funcionalidades dos
sistemas. Muitos destacaram aspectos positivos, como a adequação para atender às necessidades
operacionais básicas, com P3 mencionando que o sistema é "suficiente"para as demandas exigidas,
proporcionando uma "visão multidisciplinar". P11 elogiou a capacidade do sistema de padronizar
relatórios e garantir que estes estejam acessíveis "pelos profissionais (médicos, fisioterapeutas e
enfermeiros) que estão cuidando do paciente". P36 apontou que o sistema de gerenciamento de
farmácias "integra as várias funcionalidades necessárias", centralizando funções e melhorando a
eficiência. A eficiência dos sistemas também foi elogiada, com P6 destacando a agilidade "entre
os sistemas governamentais e entre as equipes", e P51 afirmando que os sistemas "salvam nossas
vidas diariamente"e otimizam o tempo em processos urgentes. No entanto, algumas limitações
foram observadas, como P8 relatando que o sistema "simplesmente não tem a opção"de adicionar
algo quando necessário, e P65 criticando que, embora seja um sistema para todos os profissionais,
ele foi "projetado apenas para o trabalho médico".
• Satisfação dos Usuários
Em relação à satisfação dos usuários, alguns participantes avaliaram suas experiências
como satisfatórias, destacando a praticidade e a eficiência dos sistemas em melhorar a qualidade
do serviço e simplificar processos diários. P23, por exemplo, afirmou que o sistema tornou suas
tarefas “muito mais práticas”. P79 acrescentou que o sistema é “prático para avaliação e gestão
de pacientes”, indicando que a plataforma atende às suas necessidades e contribui para um
atendimento mais eficiente. P81 elogiou as plataformas por serem “muito completas e permitirem
um bom desenvolvimento das atividades realizadas nelas”, enfatizando que as funcionalidades
proporcionam uma experiência satisfatória.
No entanto, alguns participantes expressaram insatisfação devido à complexidade ou
limitações do software, o que impacta negativamente a experiência do usuário. P43 criticou o
59
sistema por ser “muito complexo” e “demorar muito”, sugerindo que a curva de aprendizado
e a navegabilidade são obstáculos significativos. P72 também mencionou que “geralmente os
sistemas são difíceis de entender no início, mas com o tempo se tornam rotina”, apontando
uma dificuldade inicial, e destacou que “a maioria dos serviços não tem sistemas completos”,
sugerindo a ausência de funcionalidades essenciais. P118 corroborou essa crítica, afirmando:
"ainda faltam algumas funções que sinto falta no sistema que utilizo". P108 também ressaltou a
falta de recursos essenciais, sugerindo que o sistema “poderia incluir mais informações pessoais
sobre os pacientes”, o que afeta a completude e a utilidade da ferramenta.
A insatisfação também foi refletida em outras partes dos sistemas. P87 relatou problemas
“principalmente na farmácia”. Ao mesmo tempo, P83 foi mais detalhado, explicando que
“existem várias funções que não estão incluídas no sistema utilizado”, como “lançamento
de materiais na conta do paciente”, o que demanda “muito tempo, reduzindo o tempo de
atendimento direto”. Além disso, P83 apontou que “anotações de enfermagem e evolução
médica” são problemáticas por serem difíceis de ler, comprometendo a precisão e a continuidade
do atendimento. No geral, esses comentários demonstram que, enquanto alguns usuários apreciam
os sistemas, outros enfrentam desafios significativos que afetam sua satisfação e eficácia no uso.
• Segurança
Em relação ao aspecto de segurança, não houve menções explícitas nas avaliações positivas, o que pode sugerir uma confiança implícita na segurança dos sistemas ou, possivelmente,
que as falhas de segurança não são tão aparentes a ponto de serem apontadas espontaneamente.
Essa ausência de menção pode indicar que, para muitos usuários, a segurança é aceitável e não representa uma preocupação central em suas interações diárias com os sistemas. No entanto, houve
uma preocupação por parte de um participante. P18 foi objetivo e expressou preocupação com a
confidencialidade e a privacidade dos dados, afirmando: "Não, por causa do sigilo profissional.”
Para esse usuário, a segurança dos sistemas pode não atender completamente aos requisitos de
confidencialidade necessários para suas atividades profissionais, levantando um ponto importante
sobre a adequação dos sistemas em ambientes que exigem altos níveis de proteção de dados.
• Interoperabilidade
A interoperabilidade é essencial para a eficiência dos sistemas de software em setores
que dependem da integração de dados e informações, como o ambiente de saúde. P6 destacou a
importância dessa integração ao mencionar que a interoperabilidade entre o sistema de saúde
60
brasileiro e o Programa Nacional de Imunizações (PNI), no qual trabalha, “agiliza entre os
sistemas governamentais e entre as equipes”, sugerindo que a implementação eficaz melhora a
comunicação e a eficiência operacional.
Além disso, outros participantes da pesquisa relataram desafios em relação à falta de
compatibilidade entre os sistemas. P69, por exemplo, relatou dificuldades no setor público,
afirmando que “existem alguns problemas no cadastramento e regularização dos pacientes”
devido à incompatibilidade entre as plataformas. Isso demonstra que a falta de interoperabilidade
pode criar obstáculos na coleta e gestão de dados, prejudicando a eficiência dos serviços. P96
corroborou essa visão ao mencionar que “de forma relevante, a falta de harmonia entre os
sistemas em termos de troca de dados dificulta a manipulação das informações”, deixando claro
que a desarmonia entre os sistemas compromete o fluxo de trabalho e a qualidade do atendimento.
Esses relatos destacam a necessidade de soluções mais robustas para garantir que os sistemas
de software sejam compatíveis e capazes de suportar as diferentes demandas do ambiente de
trabalho.
• Eficiência
Alguns participantes relataram que os sistemas de software ajudam a otimizar o tempo
e a eficiência em suas atividades profissionais. Por exemplo, P28 apontou que o sistema utilizado tem sido uma excelente ajuda para “anotações e progresso em relação ao cuidado com o
paciente/cliente”, comparando-o favoravelmente com métodos manuais: “Melhor do que registros manuais.” P51 enfatizou que os sistemas “otimizam o tempo”, especialmente ao facilitar
a agilidade no processo de permanência no cuidado. No entanto, a eficiência do aplicativo de
software foi questionada por alguns participantes, que apontaram falhas e limitações que afetam
negativamente seu desempenho. P40 relatou que “ainda há muitos erros” no sistema, especialmente “erros no estoque de medicamentos”. O mesmo participante observou que a ferramenta
online para gerenciamento de suprimentos em farmácias “não tem a sensibilidade necessária”
para acompanhar as demandas em mudança de acordo com o perfil dos pacientes internados.
Como resultado, isso obriga os profissionais a recorrerem a métodos manuais, comprometendo a
eficiência esperada do sistema.
Por fim, P104 classificou diretamente o sistema como “ruim” sem especificar detalhes,
indicando uma insatisfação geral com a capacidade do sistema de atender às suas expectativas.
Esse tipo de feedback, embora conciso, demonstra uma frustração significativa que pode estar
ligada a múltiplos aspectos do sistema, desde falhas técnicas até limitações na usabilidade ou
61
adequação às necessidades do usuário.
4.3.3
Discussão
Os dados coletados no formulário inicial demonstram um perfil diversificado entre os
participantes, com variações de idade, experiência profissional e localização geográfica. A
maioria dos respondentes está na faixa etária de 25 a 34 anos, com 1 a 5 anos de experiência
profissional, além de uma predominância de profissionais com graduação e especialização
ou MBA, embora também haja um número significativo de técnicos com formação prática.
Em termos de área de atuação, enfermeiros, técnicos em enfermagem, psicólogos e dentistas
representam a maior parte dos participantes, atuando principalmente em clínicas, Unidades
Básicas de Saúde e serviços de urgência. Apesar de muitos utilizarem ferramentas tecnológicas
para o registro de informações, uma parte dos profissionais ainda não as incorporou à rotina
diária, evidenciando um potencial para intervenção.
No que diz respeito à participação no desenvolvimento de software, a análise revelou que
nenhum dos profissionais de saúde foram consultados ou envolvidos nesse processo, reforçando a
desconexão entre desenvolvedores e usuários finais. Esse distanciamento resulta em soluções que,
embora funcionais para alguns, apresentam limitações significativas para outros, especialmente
pela falta de consideração das diferentes necessidades e perfis profissionais. Além disso, a
ausência de interoperabilidade eficiente entre os sistemas foi identificada como um obstáculo,
prejudicando a comunicação e a gestão de dados no ambiente de trabalho.
Por fim, a satisfação dos usuários com as ferramentas tecnológicas varia consideravelmente. Enquanto alguns participantes relataram uma clara melhoria em suas atividades diárias,
outros apontaram problemas que comprometem a eficiência e a eficácia dos sistemas. A segurança
dos sistemas também foi motivo de preocupação para alguns profissionais, que destacaram a
importância de proteger a confidencialidade dos dados. Diante dessas divergências, fica evidente
a necessidade de soluções mais robustas e adaptáveis, que considerem as demandas específicas
dos diferentes usuários e promovam maior colaboração entre desenvolvedores e profissionais
da saúde no processo de criação, garantindo, assim, maior aceitação e eficácia das ferramentas
tecnológicas no setor.
62
4.4
4.4.1
SEGUNDO ESTÁGIO: EXPERIMENTO UTILIZANDO ARQUÉTIPOS OPENEHR
Experimento com Profissionais de Saúde
Para complementar a coleta de dados por meio do questionário, foram entrevistados vinte
profissionais de saúde para discutir a importância da fase de elicitação e validação de requisitos
com especialistas no domínio. Profissionais de seis áreas diferentes participaram da pesquisa,
conforme destacado na Figura 18. Nesse contexto, buscou-se investigar se o uso de arquétipos
openEHR poderia servir como uma abordagem viável para o design de software. Para facilitar
essa exploração, criamos um cenário de avaliação centrado em um domínio de problema familiar
aos profissionais de saúde, no qual eles estão diretamente envolvidos em suas atividades diárias.
Em seguida, foram desenvolvidos arquétipos que puderam ser modelados pelos participantes
e representam esse domínio, detalhando claramente os elementos de dados, terminologias e
restrições.
Além disso, foram relatados como esses arquétipos podem permitir que os especialistas
no domínio participassem ativamente do processo de elicitação e validação de requisitos, especificando os arquétipos a serem utilizados no desenvolvimento de aplicações de software. Após
as entrevistas, foi solicitado que os participantes respondessem a um breve questionário e os
incentivamos a compartilhar abertamente suas experiências, fornecendo percepções sobre suas
perspectivas em relação a essa abordagem.
Figura 18 – Participação de Profissionais de Saúde por Especialidade.
Fonte: Autoria própria, 2024.
63
Os profissionais de saúde preencheram um questionário, e o modelo de suas respostas
é mostrado na Tabela 2 utilizando um formato de escala Likert. Essa abordagem estruturada
permitiu uma compreensão detalhada das percepções e experiências dos dois grupos participantes.
Em seguida, foram utilizados métodos estatísticos para analisar as respostas e verificar se havia
uma correlação significativa entre o uso de arquétipos e as avaliações dos participantes. Essa
análise tem como objetivo fornecer suporte empírico para os possíveis benefícios da integração
de arquétipos openEHR no processo de desenvolvimento de software.
Tabela 2 – Questões para Avaliar o Uso de Arquétipos na Elicitação e Validação de Requisitos.
Questões
Questão
1
2
3
4
5
6
Profissionais da Saúde
Considero que o método utilizado para identificar os requisitos foi claro e fácil de
seguir.
As informações postas na
representação são fáceis de
compreender.
A modelagem dos dados representados pelo arquétipo
facilita o entendimento do
fluxo de trabalho em que estou inserido.
A interface gráfica gerada
a partir do arquétipo me
permite compreender como
essa funcionalidade estará
disposta no sistema.
O método utilizado para identificar e validar os requisitos permitiu que eu colaborasse ativamente durante o
processo de elicitação de requisitos.
Estou satisfeito(a) com a
forma como a abordagem de
elicitação e validação de coleta de requisitos considerou
meu conhecimento sobre o
domínio de problema.
Engenheiros de Requisitos
Escala Likert
1 2 3 4 5
O arquétipo openEHR representa adequadamente o domí◦
nio de saúde no desenvolvimento de software.
O arquétipo é fácil de adaptar quando há necessidade de ◦
ajustes ou novas exigências.
◦ ◦ ◦ ◦
◦ ◦ ◦ ◦
O arquétipo openEHR facilita o reuso de componentes
◦
em diferentes cenários clínicos.
◦ ◦ ◦ ◦
O arquétipo ajuda a reduzir a
complexidade na implemen◦
tação de requisitos de sistemas de saúde.
◦ ◦ ◦ ◦
As terminologias usadas no
arquétipo são consistentes
◦
com as necessidades dos engenheiros de software.
◦ ◦ ◦ ◦
O uso do openEHR melhora
a eficiência no processo de
elicitação de requisitos.
◦ ◦ ◦ ◦ ◦
Escala Likert: 1 - Discordo totalmente; 2 - Discordo Parcialmente; 3 - Neutro; 4 - Concordo Parcialmente; 5 Concordo Totalmente.
64
Nesta análise estatística, foi utilizado o Alpha de Cronbach, Análise de Variância
(ANOVA) e Correlação de Spearman. Os resultados estatísticos calculados neste estudo são baseados nas respostas de uma escala Likert variando de 1 a 5, em que os participantes avaliaram seu
grau de concordância com diversas afirmações. A definição, o método de cálculo e os resultados
de cada método estatístico são descritos a seguir.
• Análise do Alpha de Cronbach
O Alpha de Cronbach é calculado avaliando a variância de cada item (questão) e
comparando-a com a variância total de todos os itens combinados. Ele mede a consistência interna ou o quão relacionados os itens estão em termos de mensurar o mesmo conceito subjacente,
conforme a Equação 1.
k
α=
k−1
P 2
σitems
1−
2
σtotal
(1)
Onde:
• k é o número de itens.
•
P
2
é a soma das variâncias dos itens individuais.
σitems
2
• σtotal
é a variância da soma total dos itens.
Algorithm 1 Script do Calculo do Alpha de Cronbach - Respostas dos Profissionais da Saúde
1: procedure A LPHA DE C RONBACH(df)
2:
k ← df.shape[1]
3:
variance_sum ← df.sum(axis=1).var(ddof=1)
4:
variances ← df.var(ddof=1).sum()
5:
alpha ← (k/(k − 1)) × (1 − (variances/variance_sum))
6:
return alpha
7: end procedure
8:
9: Data:
10: Método claro e fácil de seguir ← [5, 5, 5, 5, 5, 5, 5, 5, 4, 5, . . .]
11: Informações fáceis de compreender ← [5, 5, 5, 5, 5, 5, 5, 5, 5, 5, . . .]
12: Modelagem facilita entendimento ← [5, 5, 5, 4, 5, 5, 5, 4, 3, 5, . . .]
13: Interface gráfica permite compreensão ← [5, 4, 5, 4, 5, 5, 5, 4, 4, 5, . . .]
14: Colaboração ativa durante elicitação ← [5, 5, 5, 5, 5, 5, 5, 4, 3, 5, . . .]
15: Satisfação com a consideração do conhecimento ← [5, 5, 5, 5, 5, 5, 5, 4, 5, 5, . . .]
16:
17: df_new ← pd.DataFrame(data_new)
18: alpha_value_new ← Cronbach_Alpha(df_new)
19: Print Cronbach’s Alpha value: alpha_value_new
65
O cálculo do Alpha de Cronbach foi implementado em Python, conforme script presente
no Algoritmo 1, e o resultado encontrado foi 0,72. De acordo com os valores de referência para
este método, um resultado acima de 0,7 indica que as questões estão bem correlacionadas e
medem de forma consistente a percepção dos profissionais sobre o uso de arquétipos. Também
indica que os itens do questionário estão adequadamente relacionados em termos de clareza,
facilidade de adaptação, compreensão e colaboração, reforçando a coesão das perguntas em torno
de um tema central. Esse coeficiente também sugere que o questionário foi bem estruturado para
captar uma visão coerente sobre a eficácia e adequação dos arquétipos na fase de elicitação de
requisitos de software.
• Análise de ANOVA
A ANOVA é utilizada para comparar as médias das respostas entre diferentes grupos
(por exemplo, tipos de profissionais de saúde), determinando se há diferenças significativas nas
respostas da escala Likert. Ela calcula a variância dentro e entre os grupos para verificar se as
diferenças nas médias das respostas são estatisticamente significativas, conforme mostrado pela
Equação 2.
F =
SSB
k−1
SSW
N −k
(2)
Onde:
• F é a estatística F para ANOVA.
• SSB é a soma dos quadrados entre os grupos (variação devida à interação entre os grupos).
• SSW é a soma dos quadrados dentro dos grupos (variação dentro de cada grupo).
• k é o número de grupos.
• N é o número total de observações.
Seguindo a mesma abordagem do método anterior, foi implementada uma rotina em
Python para calcular o valor-p de cada pergunta respondida (conforme Algoritmo 2), e os resultados mostraram que não houve diferenças estatisticamente significativas entre os profissionais
de saúde em relação às questões avaliadas. Esse resultado indica que, apesar das diferentes
especialidades e funções dos profissionais de saúde, suas percepções sobre o uso de arquétipos
66
na fase de elicitação e validação de requisitos são homogêneas. A Tabela 3 apresenta os valores-p
para cada pergunta do formulário respondido pelos profissionais de saúde.
Algorithm 2 Script do Cálculo de ANOVA - Respostas dos Profissionais da Saúde
1: procedure A NÁLISE ANOVA
2:
df_new ← pd.DataFrame
3:
Define the dataset with columns:
4:
Profissional ← [”N utricao”, ”T ecnicodeEnf ermagem”, ”P sicologia” . . .]
5:
Método claro e fácil de seguir ← [5, 5, 5, 5, 5, 5, 5, 5, 4, 5, . . .]
6:
Informações fáceis de compreender ← [5, 5, 5, 5, 5, 5, 5, 5, 5, 5, . . .]
7:
Modelagem facilita entendimento ← [5, 5, 5, 4, 5, 5, 5, 4, 3, 5, . . .]
8:
Interface gráfica permite compreensão ← [5, 4, 5, 4, 5, 5, 5, 4, 4, 5, . . .]
9:
Colaboração ativa durante elicitação ← [5, 5, 5, 5, 5, 5, 5, 4, 3, 5, . . .]
10:
Satisfação com a consideração do conhecimento ← [5, 5, 5, 5, 5, 5, 5, 4, 5, 5, . . .]
11:
12:
13:
14:
15:
16:
17:
18:
Perform ANOVA for each question: for each question in df_new.columns[1:] do
end
groups ← [df _new[df _new[”P rof issional”] == prof ][question] for each prof]
anova_results_new[question] ← stats.f_oneway(*groups)
Print the ANOVA results: for each question, result in anova_results_new.items() do
end
Print F-statistic and p-value for the question.
19:
20: end procedure
Os p-valores obtidos para todas as questões estão acima de 0,05. Isso significa que não
há evidências suficientes para concluir que os profissionais de saúde de diferentes áreas avaliam
os arquétipos de maneira diferente. A uniformidade das respostas coletadas nos dados demonstra
que os arquétipos têm o potencial de padronizar o processo de desenvolvimento de software na
área da saúde, facilitando a colaboração entre profissionais e desenvolvedores de sistemas. Essa
consistência também pode ajudar a reduzir os custos e o tempo de desenvolvimento, já que os
arquétipos podem ser reutilizados em diferentes contextos clínicos.
• Análise da Correlação de Spearman
Por fim, a correlação de Spearman é calculada ao classificar as respostas da escala
Likert e medir a força e a direção da relação entre duas variáveis (questões). Ela demonstra o
quão fortemente as respostas de uma questão estão associadas às respostas de outra entre os
participantes, conforme demonstrado pela Equação 3.
67
Tabela 3 – Resultados da ANOVA para os Profissionais de Saúde
Questão
1
2
3
4
5
6
F-estatística
0.53
Não calculável
0.92
1.64
0.81
0.53
P-valores
0.75
Não calculável
0.50
0.21
0.56
0.75
P
6 d2i
ρ=1−
n(n2 − 1)
(3)
Onde:
• ρ é o coeficiente de correlação de postos de Spearman.
• di é a diferença entre os postos de cada par de variáveis correspondentes.
• n é o número de observações.
A correlação de Spearman possibilita identificar o grau e a direção da associação entre
duas variáveis, com o valor de correlação ρ podendo ser positivo ou negativo, variando de -1 a
+1. O Script em python foi feito e executado conforme ilustrado no Algoritmo 3.
Algorithm 3 Script do Cálculo de Correlação de Spearman - Respostas dos Profissionais da
Saúde
1: procedure C ORRELAÇÃO S PEARMAN
2:
df_new ← pd.DataFrame
3:
Create DataFrame with columns:
4:
5:
6:
7:
8:
9:
10:
Método claro e fácil de seguir ← [5, 5, 5, 5, 5, 5, 5, 5, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5]
Informações fáceis de compreender ← [5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5]
Modelagem facilita entendimento ← [5, 5, 5, 4, 5, 5, 5, 4, 3, 5, 4, 5, 5, 5, 5, 5, 4, 5, 5, 4]
Interface gráfica permite compreensão ← [5, 4, 5, 4, 5, 5, 5, 4, 4, 5, 3, 5, 5, 5, 5, 5, 5, 4, 5, 5]
Colaboração ativa durante elicitação ← [5, 5, 5, 5, 5, 5, 5, 4, 3, 5, 5, 5, 5, 5, 4, 5, 5, 5, 5, 5]
Satisfação com a consideração do conhecimento
←
[5, 5, 5, 5, 5, 5, 5, 4, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5]
11:
12:
correlation_matrix ← df_new.corr(method=’spearman’)
13:
Print the Spearman correlation matrix.
14: end procedure
A primeira associação identificada foi entre as questões 1 e 5. O coeficiente mostrou uma
correlação positiva moderada de 0,61. Esse resultado indica que, à medida que os profissionais
68
percebem o método de elicitação como mais transparente e acessível, eles tendem a sentir que
podem colaborar de forma mais ativa durante o processo de elicitação de requisitos. Em outras
palavras, a clareza do método utilizado não apenas facilita a compreensão dos requisitos, mas
também aumenta o envolvimento dos profissionais de saúde, permitindo que eles contribuam de
maneira mais significativa para o desenvolvimento do sistema. Isso pode indicar que a clareza na
elicitação é essencial para estabelecer uma participação profissional mais eficaz.
Outra correlação relevante foi encontrada entre as questões 3 e 4, com um coeficiente de
0,56, também uma correlação positiva moderada. Isso indica que os profissionais que acreditam
que a modelagem de dados facilita a compreensão do fluxo de trabalho também tendem a achar
que a interface gráfica gerada a partir do arquétipo oferece uma compreensão mais clara de
como a funcionalidade do sistema será organizada. Esse resultado destaca a importância de uma
modelagem bem estruturada para a compreensão visual do sistema. Em termos práticos, isso
sugere que uma boa representação dos dados no arquétipo pode ajudar a criar uma interface
gráfica mais intuitiva, melhorando a usabilidade do sistema final.
A correlação entre as questões 5 e 6 foi de 0,51, novamente uma correlação positiva
moderada. Isso mostra que, quando os profissionais de saúde se sentem mais envolvidos no
processo de elicitação de requisitos, eles tendem a estar mais satisfeitos com a forma como
seu conhecimento sobre o domínio do problema é considerado. Isso destaca a importância de
envolver os profissionais durante a elicitação de requisitos, pois quanto mais eles se sentem
parte do processo, mais satisfeitos ficam com o resultado. Assim, é possível deduzir que o uso
de arquétipos, ao incentivar a colaboração ativa, também contribui para a percepção de que o
conhecimento especializado dos profissionais está sendo devidamente valorizado.
Por fim, existe uma correlação positiva entre as questões 1 e 3, embora seja um pouco
menor (0,47), indicando que a clareza do método de elicitação tem um impacto mais significativo
nos aspectos de colaboração do que na percepção da modelagem.
4.4.1.1
Percepção dos Profissionais de Saúde
Nas entrevistas com os vinte profissionais de saúde, surgiram diversos pontos importantes
sobre o uso de ferramentas computacionais no processo de elicitação de requisitos. Os profissionais compartilharam abertamente suas percepções, destacando os benefícios e os desafios
enfrentados ao utilizar essas tecnologias em suas rotinas. Eles também expressaram suas opiniões
sobre a participação em um processo de desenvolvimento utilizando arquétipos.
Durante a apresentação dos arquétipos, uma observação comum foi o potencial dos
69
profissionais de saúde para contribuir no desenvolvimento de aplicações de software. A capacidade deles de propor requisitos e funcionalidades que poderiam melhorar seu fluxo de trabalho
foi vista como um aspecto positivo. A visualização em tempo real dos campos e funções que
estavam sendo criados foi especialmente destacada como uma ferramenta útil para entender a
funcionalidade do sistema, recebendo um feedback positivo dos profissionais.
No entanto, alguns desafios também foram observados. Um desses desafios é o tempo
necessário para coletar e ajustar os requisitos. Muitos profissionais mencionaram que o processo
de elicitação precisa passar por várias interações até que todas as necessidades sejam completamente atendidas. Eles acharam interessante o fato de, como profissionais de saúde, poderem
interagir com a ferramenta e especificar os requisitos, mas ressaltaram a importância de contar
com o apoio de um engenheiro de requisitos para auxiliar no processo.
Eles mencionaram que a interface gráfica das ferramentas poderia ser mais amigável
e visualmente mais atraente, facilitando a compreensão de como as funcionalidades estão
organizadas. Também levantaram a questão da adaptação das ferramentas a cenários de trabalho
específicos. Em áreas como a nutrição, os sistemas precisam ser mais flexíveis e ajustáveis para
acomodar as especialidades de cada profissional.
Durante as entrevistas, vários profissionais de saúde destacaram que os sistemas atualmente utilizados em seus ambientes de trabalho apresentam muitos erros e limitações, especialmente no que diz respeito à usabilidade e adaptação às suas rotinas. Eles também relataram que
essas falhas geram frustração e dificultam o uso das ferramentas, levando-os a preferir métodos
manuais, como registros em papel. Apontaram que, apesar das vantagens dos sistemas, o papel
ainda oferece mais flexibilidade e controle na coleta de informações, além de permitir uma
tomada de notas mais rápida.
Por outro lado, eles também destacaram a dificuldade de armazenar e gerenciar dados
utilizando registros em papel. Profissões como a psicologia, por exemplo, exigem que as informações dos pacientes sejam armazenadas por pelo menos cinco anos, o que gera um grande volume
de documentos físicos, tornando desafiador organizar e acessar rapidamente informações antigas.
Os entrevistados enfatizaram que, se os sistemas fossem adaptados às suas necessidades, isso
reduziria os erros e a frustração com o uso dos arquétipos, além de facilitar o armazenamento
eficiente dos dados.
70
4.4.2
Experimento com Engenheiros de Requisitos
Além de entrevistar os profissionais de saúde, foi identificada a necessidade de envolver
engenheiros de requisitos para entender suas perspectivas sobre o uso de arquétipos no ciclo de
desenvolvimento de software. O objetivo dessas conversas foi coletar evidências de profissionais
diretamente envolvidos em atividades práticas de elicitação de requisitos, fornecendo insights
sobre a eficácia e a aplicabilidade da abordagem proposta no contexto real de desenvolvimento
de software.
Onze engenheiros de requisitos foram entrevistados utilizando a mesma estrutura das
entrevistas realizadas com os profissionais de saúde. Foi apresentado um domínio de problema
na área de saúde, especificados arquétipos que representavam o cenário e explicado sobre como
esses arquétipos são utilizados. Ao final da sessão, foi pedido aos engenheiros de requisitos
que preenchessem o questionário presente na Tabela 2 e fornecessem feedback aberto sobre
sua experiência na elicitação de requisitos utilizando arquétipos. A análise aplicou os mesmos
métodos estatísticos, exceto a ANOVA, pois apenas um tipo de profissional, os engenheiros
de requisitos, estava envolvido. A ANOVA foi considerada desnecessária devido à ausência de
múltiplos grupos profissionais para comparação.
• Análise do Alpha de Cronbach
Para obter esse resultado, foi implementada uma rotina em Python, conforme Algoritmo
4 para calcular o Alpha de Cronbach com o objetivo de avaliar a consistência interna das
questões do formulário aplicado aos engenheiros de requisitos. O valor encontrado foi de 0,86,
indicando alta consistência interna entre as perguntas. Esse resultado indica que as questões
estão fortemente correlacionadas, o que significa que todas elas avaliam de forma coesa o
mesmo construto, neste caso, a adequação dos arquétipos openEHR no processo de elicitação de
requisitos.
A consistência interna demonstra que os diversos aspectos avaliados, como a forma
como o domínio da saúde é representado, a facilidade de adaptação dos arquétipos a novos
requisitos e a eficiência do processo de elicitação, estão todos interconectados na percepção
dos engenheiros. As respostas consistentes indicam que os engenheiros de requisitos veem o
processo de desenvolvimento com arquétipos de forma holística, onde esses diferentes fatores
trabalham juntos para otimizar a elicitação de requisitos.
71
Algorithm 4 Script do Cálculo do Alpha de Cronbach - Respostas dos Engenheiros de Requisitos
1: procedure A LPHA DE C RONBACH(df)
2:
k ← df.shape[1]
3:
variance_sum ← df.sum(axis=1).var(ddof=1)
4:
variances ← df.var(ddof=1).sum()
5:
alpha ← (k/(k − 1)) × (1 − (variances/variance_sum))
6:
return alpha
7: end procedure
8:
9: Dados:
10: Representa adequadamente o domínio de saúde ← [2, 2, 3, 4, 5, 5, 4, 4, 4, 4, 5]
11: Fácil de adaptar para ajustes ← [2, 2, 1, 2, 5, 5, 4, 5, 4, 4, 4]
12: Facilita o reuso de componentes ← [4, 4, 3, 5, 5, 5, 3, 5, 5, 5, 4]
13: Reduz complexidade na implementação ← [4, 4, 3, 2, 4, 5, 5, 4, 4, 5, 4]
14: Terminologias consistentes com engenheiros de software ← [2, 2, 2, 1, 5, 5, 5, 5, 4, 3, 5]
15: Melhora a eficiência no processo de elicitação ← [3, 4, 4, 4, 5, 5, 4, 4, 5, 4, 5]
16:
17: df_engenheiros ← pd.DataFrame(data_engenheiros)
18: alpha_value_engenheiros ← cronbach_alpha(df_engenheiros)
19: Print valor de Alpha de Cronbach: alpha_value_engenheiros
• Análise da Correlação de Spearman
A análise de correlação de Spearman foi implementada em Python, conforme ilustrado
no Algoritmo 5, para investigar a relação entre diferentes aspectos do uso de arquétipos no
processo de elicitação de requisitos. Entre eles, a correlação das questões 1 e 6 aponta para um
coeficiente de 0,82. Essa forte correlação mostra que os engenheiros que consideram o arquétipo
uma representação fiel do domínio de saúde também percebem uma melhoria significativa na
eficiência do processo de elicitação de requisitos.
Outra correlação importante foi entre as questões 1 e 2, indicando um coeficiente de
0,77. Nesse caso, quanto melhor o arquétipo captura o domínio de saúde, mais flexível ele se
torna para adaptações e ajustes futuros. Isso prova que uma boa modelagem de domínio facilita
a incorporação de mudanças no sistema ao longo do ciclo de desenvolvimento, o que é essencial
em ambientes dinâmicos, como o de saúde, onde os requisitos mudam frequentemente.
Além disso, as questões 2 e 5 apresentaram um valor de 0,87, uma das correlações
mais fortes encontradas, mostrando que a flexibilidade do arquétipo para se adaptar a novos
requisitos está diretamente ligada à clareza e à adequação das terminologias utilizadas. Quando
a terminologia usada no arquétipo é consistente e compreensível para os engenheiros, o processo
de ajuste e adaptação torna-se mais fluido e menos propenso a mal-entendidos. No entanto, a
questão 3 mostrou correlações mais moderadas, sugerindo que, na percepção dos engenheiros de
72
requisitos, o reúso de componentes é visto como um aspecto mais independente do processo de
elicitação.
Algorithm 5 Cálculo da Correlação de Spearman - Respostas dos Engenheiros de Requisitos
1: procedure M ATRIZ DE C ORRELAÇÃO DE S PEARMAN(df)
2:
correlation_matrix ← df.corr(method=’spearman’)
3:
return correlation_matrix
4: end procedure
5:
6: Dados:
7: Representa adequadamente o domínio de saúde ← [2, 2, 3, 4, 5, 5, 4, 4, 4, 4, 5]
8: Fácil de adaptar para ajustes ← [2, 2, 1, 2, 5, 5, 4, 5, 4, 4, 4]
9: Facilita o reuso de componentes ← [4, 4, 3, 5, 5, 5, 3, 5, 5, 5, 4]
10: Reduz complexidade na implementação ← [4, 4, 3, 2, 4, 5, 5, 4, 4, 5, 4]
11: Terminologias consistentes com engenheiros de software ← [2, 2, 2, 1, 5, 5, 5, 5, 4, 3, 5]
12: Melhora a eficiência no processo de elicitação ← [3, 4, 4, 4, 5, 5, 4, 4, 5, 4, 5]
13:
14: df_engenheiros ← pd.DataFrame(data_engenheiros)
15: correlation_matrix_engenheiros ← Matriz_de_Correlação_de_Spearman(df_engenheiros)
16: Print matriz de correlação de Spearman: correlation_matrix_engenheiros
De modo geral, os resultados mostram que os engenheiros de requisitos veem de forma
positiva os arquétipos openEHR no processo de elicitação de requisitos, especialmente no que
diz respeito à clareza, flexibilidade e eficiência. A representação adequada do domínio da saúde
é um fator importante, influenciando diretamente a adaptabilidade e melhorando a eficiência
no processo de definição de requisitos. Além disso, a consistência na terminologia é percebida
como um fator essencial que facilita a adoção e o uso eficaz dos arquétipos.
4.4.3
Percepção dos Engenheiros de Requisitos
Durante as entrevistas, os participantes levantaram espontaneamente vários pontos es-
senciais, proporcionando uma visão mais detalhada sobre o uso dos arquétipos OpenEHR no
processo de elicitação de requisitos. As opiniões dos entrevistados trouxeram à tona aspectos
práticos e percepções sobre a ferramenta, variando desde as vantagens observadas em seu uso
até os desafios e limitações enfrentados ao aplicá-la em cenários reais de desenvolvimento. Com
base nas contribuições dos participantes, alguns desses pontos serão discutidos a seguir.
Um dos aspectos positivos mencionados foi a flexibilidade da ferramenta, que permite
aos usuários visualizar e ajustar os campos e dados utilizados no sistema em tempo real. Isso
facilita a interação com o usuário final. Os participantes observaram que essa característica
contribui para uma maior fluidez no processo de elicitação de requisitos, permitindo ajustes
73
rápidos e oferecendo ao cliente uma visão clara do desenvolvimento. Isso também melhora a
comunicação entre o cliente e os engenheiros de requisitos, especialmente para profissionais com
menos conhecimento técnico. A capacidade de visualizar os dados em tempo real ajuda a alinhar
as expectativas do cliente com os entregáveis reais, antecipando assim possíveis problemas no
processo.
No entanto, os participantes também identificaram desafios e limitações no uso dos
arquétipos, especialmente em relação à interface gráfica. A interface foi descrita como "antiga"e
"pouco intuitiva", o que dificultaria o uso para pessoas menos familiarizadas com tecnologia.
Além disso, a falta de autonomia para personalizar a organização visual dos campos foi considerada uma fraqueza. Embora seja possível adicionar campos, o layout visual rígido pode resultar
em interfaces que comprometem o processo de elicitação de requisitos e a experiência do usuário.
Outro ponto destacado entre os desafios levantados foi a necessidade de profissionais especializados para conduzir a elicitação de requisitos utilizando arquétipos. Isso pode representar uma
barreira significativa em equipes menores ou em ambientes de desenvolvimento ágil, onde o
tempo e os recursos são mais limitados.
Por fim, os entrevistados discutiram os desafios de integrar os arquétipos em um ambiente
real de desenvolvimento. Embora os arquétipos sejam eficazes na captura e padronização de
dados, é necessário garantir que o cliente compreenda que a visualização oferecida é uma
simulação funcional, e não o design final do sistema. Esse ponto de comunicação foi destacado
como essencial para evitar mal-entendidos e frustrações, especialmente durante as validações do
processo.
4.4.4
Considerações Finais
Este capítulo explorou o potencial dos arquétipos openEHR como ferramenta para apro-
ximar as necessidades clínicas das especificações técnicas, resultando em soluções que atendam
melhor às demandas específicas do setor de saúde. Para isso, baseado na lacuna identificada
no estado da arte, delineou-se o perfil dos participantes e conduziu-se um experimento prático
envolvendo profissionais da saúde e engenheiros de requisitos, com o objetivo de compreender
como esses arquétipos podem facilitar a adequação entre o conhecimento clínico e os aspectos
técnicos de desenvolvimento.
As entrevistas com engenheiros de software reforçaram a importância de uma colaboração
mais próxima com os especialistas de domínio, reconhecendo que o envolvimento direto dos
profissionais da saúde contribui para uma visão mais completa e aplicada das necessidades
74
clínicas. Os profissionais de saúde, por sua vez, destacaram a necessidade de softwares que
compreendam as nuances de seu trabalho cotidiano e que respeitem as particularidades de suas
rotinas. Essa perspectiva dos usuários finais demonstrou o valor de uma abordagem inclusiva
no desenvolvimento, onde os requisitos são integrados desde as fases iniciais, de forma a criar
sistemas que facilitam as operações clínicas e potencializam a eficiência no atendimento ao
paciente.
Com isso, esse alinhamento entre engenheiros de software e especialistas de domínio,
indica que práticas colaborativas podem reduzir a lacuna entre o desenvolvimento técnico e a
aplicação prática no ambiente clínico. Dessa forma, este capítulo contribui para uma melhor
compreensão dos benefícios e desafios da integração de arquétipos no desenvolvimento de
software, apontando caminhos para futuras implementações mais alinhadas com as necessidades
reais dos usuários finais no setor de saúde.
75
5 BOAS PRÁTICAS PARA A ELICITAÇÃO DE REQUISITOS UTILIZANDO ARQUÉTIPOS OPENEHR
Para contribuir com a área de pesquisa explorada neste estudo, foram propostas boas
práticas focadas no uso de arquétipos openEHR durante as fases de elicitação e validação no
ciclo de vida de desenvolvimento de software para aplicações na área de saúde. Essas práticas
recomendadas são fundamentadas no ciclo de vida de elicitação de requisitos descrito no Guide to
the Software Engineering Body of Knowledge (SWEBOK) [Bourque e Fairley 2014], que oferece
uma estrutura sistemática para capturar requisitos com maior precisão. O SWEBOK ajuda a
melhorar o envolvimento dos especialistas de domínio, promovendo uma coleta de requisitos
mais rica e elevando a qualidade geral das especificações para garantir que as necessidades
clínicas sejam plenamente atendidas.
O uso do SWEBOK garante que nossas recomendações sejam baseadas em padrões
amplamente aceitos, aumentando sua credibilidade. Seu foco em processos sistemáticos facilita a
comunicação eficaz com as partes interessadas, levando a soluções de software melhores para os
profissionais de saúde. Essa aliança promove consistência na prática e ajuda a enfrentar desafios
únicos no domínio da saúde.
Esta proposta, como mostrado na Figura 19, delineia seis boas práticas que são identificadas como BP e o número correspondente a prática aplicada, sendo projetadas para aprimorar a
elicitação e validação de requisitos em aplicações de saúde através do uso eficaz de arquétipos
openEHR. Cada prática enfatiza a importância de envolver os profissionais de saúde como
participantes ativos no ciclo de vida de desenvolvimento de software. A figura ilustra o processo
degerenciamento de requisitos, composta pelas fases de elicitação, análise, especificação e validação. Além disso, cada uma dessas fases (enumeradas de 01 a 04), contam com a interação do
engenheiro com os usuários finais da aplicação.
• BP1: Envolver as Partes Interessadas Desde o Início e Continuamente
É essencial envolver as partes interessadas desde o início do ciclo de vida do desenvolvimento de software para captar suas percepções e atender às suas necessidades de forma eficaz. O
envolvimento precoce de profissionais de saúde garante que os requisitos sejam melhor definidos
e alinhados com a prática clínica. Facilitar discussões em torno dos arquétipos openEHR, que
são modelos estruturados representando conceitos clínicos, pode ajudar as partes interessadas
a visualizar como seus requisitos serão integrados ao sistema. Esse engajamento contínuo cria
um ambiente colaborativo, onde o feedback pode ser compartilhado livremente, aumentando a
76
Figura 19 – Aplicação de Arquétipos openEHR na Fase de Elicitação de Requisitos.
Fonte: Autoria própria, 2024.
relevância e a qualidade do produto final.
• BP2: Utilizar Técnicas Estruturadas de Elicitação
Empregar técnicas estruturadas de elicitação é importante para reunir requisitos bem
definidos e precisos. Desenvolvedores podem promover diálogos eficazes com profissionais de
saúde utilizando métodos como entrevistas semiestruturadas e grupos focais. Essas técnicas
estruturadas estabelecem uma estrutura que incentiva as partes interessadas a explorar elementos
de dados específicos, terminologias e restrições relevantes para seu trabalho. A incorporação
dos arquétipos openEHR nesse contexto facilita a representação clara dos conceitos clínicos,
capacitando os participantes a contribuir com percepções baseadas em suas experiências práticas
e em seus conhecimentos.
• BP3: Validar Requisitos com Especialistas no Domínio
77
A validação é uma fase fundamental nesse ciclo, pois é nela que os requisitos propostos
precisam ser revisados e confirmados por especialistas no domínio. Validar regularmente os
arquétipos openEHR com profissionais de saúde garante que os modelos reflitam com precisão
as realidades e necessidades clínicas. Essa prática melhora a qualidade dos requisitos e gera
confiança entre as partes interessadas, à medida que veem suas contribuições sendo integradas
ao processo de desenvolvimento. A colaboração com especialistas do domínio durante essa fase
ajuda os desenvolvedores a identificar potenciais problemas desde o início, garantindo que a
solução final de software atenda aos altos padrões exigidos na área de saúde.
• BP4: Iterar com Base no Feedback
O processo de desenvolvimento de software se beneficia de uma abordagem iterativa que
permite ajustes e refinamentos contínuos com base em feedback constante. Estabelecer ciclos
frequentes de feedback possibilita que desenvolvedores colaborem com as partes interessadas
para avaliar e melhorar os requisitos e os arquétipos. Essa abordagem iterativa promove flexibilidade e adaptabilidade às necessidades em constante mudança, o que é especialmente importante
no ambiente dinâmico da saúde. O uso de arquétipos openEHR facilita rápidas adaptações,
permitindo que os profissionais de saúde proponham modificações que aprimorem o alinhamento
do software com as práticas clínicas.
• BP5: Foco em Usabilidade e Experiência do Usuário
Priorizar a usabilidade é essencial para qualquer aplicação de software, especialmente no
setor de saúde, onde a experiência do usuário desempenha um papel crítico no cuidado com o
paciente. Enfatizar a usabilidade durante a fase de validação de requisitos garante que o software
seja amigável ao usuário e atenda de forma eficaz às necessidades práticas dos profissionais
de saúde. Por meio da integração de testes de usabilidade baseados nos arquétipos openEHR,
os desenvolvedores podem obter feedback sobre o design e a funcionalidade do software. Esse
método melhora a experiência do usuário e aumenta substancialmente a probabilidade de adoção
bem-sucedida pelos profissionais de saúde, resultando, em última análise, em melhores resultados
para os pacientes.
• BP6: Documentar o Processo de Elicitação
Uma documentação minuciosa dos processos de elicitação e validação de requisitos é
vital para garantir clareza e rastreabilidade. Manter registros detalhados de como os arquétipos
78
openEHR foram definidos, bem como dos processos de feedback e tomada de decisão das partes
interessadas, oferece informações necessárias para desenvolvimentos futuros. Essa documentação
serve como uma referência que apoia a melhoria contínua e garante que as lições aprendidas no
projeto atual possam orientar iniciativas subsequentes.
As boas práticas propostas para a utilização dos arquétipos openEHR não têm a intenção
de substituir as atividades e processos já estabelecidos na engenharia de software. Pelo contrário,
elas visam servir como uma estrutura alternativa que facilita o envolvimento ativo dos profissionais de saúde no ciclo de vida das aplicações de saúde. Ao integrar essas práticas, podemos criar
oportunidades para que especialistas no domínio contribuam significativamente na definição
de elementos de dados, terminologias e restrições dentro do processo de desenvolvimento de
software. Essa abordagem melhora a relevância e a precisão dos requisitos e garante que as
aplicações finais estejam melhor alinhadas com as realidades da prática clínica, resultando, em
última instância, em melhorias no cuidado ao paciente e na eficiência operacional.
79
6 CONCLUSÃO
Este capítulo apresenta as principais contribuições da pesquisa na Seção 6.1, onde são
discutidos os resultados alcançados e seu impacto no campo de estudo. A Seção 6.2 reconhece as
limitações do trabalho, incluindo a amostra restrita e os possíveis vieses dos dados autodeclarados,
além de destacar as ameaças à validade do estudo, como a falta de controle sobre variáveis
externas. Por fim, a Seção 6.3 propõe direções para trabalhos futuros, sugerindo a implementação
das práticas recomendadas em ambientes reais de desenvolvimento.
6.1
PRINCIPAIS CONTRIBUIÇÕES
Esta pesquisa apresenta uma análise do papel dos especialistas de domínio no desenvolvi-
mento de software voltado para a área da saúde, com foco nas fases de elicitação e validação de
requisitos. Ao longo da pesquisa, foi destacada a importância de envolver esses profissionais
no processo de desenvolvimento de software, dado o impacto direto que sua participação tem
na eficácia das soluções criadas para o ambiente clínico. Um dos aspectos centrais abordados
foi o potencial dos arquétipos openEHR, que podem atuar como uma ferramenta poderosa para
alinhar as necessidades clínicas com as especificações técnicas, promovendo maior aderência
entre as soluções desenvolvidas e as demandas do setor de saúde.
A partir da análise do estado da arte, foi identificado um déficit significativo na participação de profissionais de saúde no ciclo de vida do desenvolvimento de software. Essa lacuna pode
comprometer o desenvolvimento de soluções que realmente atendam às necessidades do ambiente clínico, resultando em aplicações que, embora tecnicamente robustas, falham em termos
de usabilidade prática no dia a dia dos profissionais de saúde. Tal cenário reforça a necessidade
de criar pontes mais sólidas entre os desenvolvedores e os usuários finais, representados pelos
especialistas de domínio, que possuem o conhecimento necessário para orientar a criação de
soluções mais eficazes.
A análise temática realizada trouxe à tona experiências valiosas dos profissionais de saúde
com as soluções de software atualmente disponíveis. Esses profissionais relataram uma série de
desafios, como a falta de adaptação às suas rotinas e a dificuldade em utilizar ferramentas que
não foram projetadas com base em suas necessidades. Ao mesmo tempo, surgiram oportunidades
claras de melhoria, que podem ser aproveitadas para transformar as soluções existentes e futuras.
Os resultados quantitativos corroboraram com esses achados, evidenciando que o envolvimento
limitado dos profissionais de saúde é uma realidade preocupante, especialmente em uma área
80
onde a eficácia e a precisão são importantes para o atendimento de qualidade.
Entrevistas realizadas com engenheiros de software também forneceram uma perspectiva
essencial sobre a integração dos arquétipos openEHR no desenvolvimento de aplicações. Esses
profissionais destacaram a importância de uma colaboração mais estreita com os especialistas
de domínio, ressaltando como essa interação pode contribuir para a criação de soluções mais
adequadas às exigências clínicas e mais eficazes no longo prazo. A partir dessa colaboração,
foi possível delinear um conjunto de boas práticas voltadas para a elicitação e validação de
requisitos. Essas práticas visam reduzir o distanciamento entre o desenvolvimento técnico e as
necessidades clínicas, promovendo um alinhamento mais preciso e centrado no usuário final.
O estudo conclui que a abordagem adotada responde de forma direta à questão de
pesquisa "O uso de arquétipos openEHR na fase de elicitação de requisitos facilita a identificação
e materialização do conhecimento do especialista de domínio no desenvolvimento de aplicações
em saúde?". A análise demonstrou que o uso de arquétipos com base no padrão OpenEHR
contribui com a especificação dos requisitos, promovendo aderência entre as especificações
técnicas e as necessidades reais do ambiente clínico.
Ainda assim, o processo de aproximação entre o ambiente de desenvolvimento e os
profissionais de saúde apresenta desafios. Trazer esses profissionais para o contexto de desenvolvimento não é uma tarefa simples, visto que envolve uma adaptação mútua e um esforço
maior em capturar as exigências clínicas para uma linguagem técnica. As recomendações para a
implementação dessa metodologia em contextos reais reforçam o impacto positivo na criação de
soluções mais alinhadas às rotinas clínicas, evidenciando que o uso dos arquétipos OpenEHR
pode facilitar a criação de softwares de saúde centrados no usuário final e ajustados às demandas
específicas do setor.
Por fim, este estudo representa um avanço no estado da arte e contribui para a disseminação científica, resultando em duas publicações derivadas desta pesquisa:
• Silva, J., Araújo, A., Coutinho, F., & Silva, A. (2024). Are End-Users Participating in the
Life Cycle of Healthcare Application Development? An Analysis of the Opportunities
and Challenges of the Use of HCI Techniques in the Healthcare Sector. BIOSTEC (2),
789-796.
• Silva, J., & Araújo, A. (2024). The Use of OpenEHR Archetypes in Requirements Elicitation: Best Practices for Engaging Domain Experts in Healthcare Software Development.
IEEE Access.
81
6.2
LIMITAÇÕES E AMEAÇAS À VALIDADE
As conclusões deste estudo apresentam importantes contribuições sobre o papel dos
especialistas de domínio no desenvolvimento de software para a área da saúde, especialmente ao
se considerar o uso de arquétipos openEHR. Contudo, é necessário observar que certos aspectos
podem influenciar a validade dos resultados, sendo relevante discutir as possíveis limitações e
ameaças à confiabilidade e aplicabilidade das descobertas. Com isso, os principais pontos foram
identificados e relatados abaixo:
• Validade de Construto: É uma das principais preocupações, uma vez que o estudo se
baseia em dados autodeclarados por profissionais de saúde. Esses dados podem estar
sujeitos a vieses pessoais, já que as percepções e experiências individuais podem diferir
significativamente entre os participantes. Quando se lida com a complexidade do sistema
de saúde e com a implementação de tecnologias como os arquétipos openEHR, captar de
forma precisa a eficácia desses conceitos exige uma abordagem cuidadosa. As respostas
dos profissionais podem não refletir todas as nuances e desafios enfrentados na prática
cotidiana, especialmente se houver limitações na forma como os conceitos foram definidos
e aplicados no estudo.
• Validade Interna: O fato de não ter havido um controle rigoroso sobre variáveis externas,
como a experiência variada dos participantes ou os diferentes contextos organizacionais,
pode ter introduzido inconsistências nos dados. A diversidade de conhecimentos e práticas
entre os profissionais de saúde que contribuíram para o estudo poderia ter gerado respostas
mais dispersas, afetando a confiabilidade dos resultados. Isso ressalta a importância de
considerar essas variáveis ao interpretar os dados coletados.
• Validade Externa: Embora o estudo forneça resultados valiosos, sua generalização pode
ser limitada devido à amostra restrita, que foi retirada de ambientes de saúde específicos.
Isso significa que os resultados podem não ser aplicáveis a outras realidades ou contextos
culturais distintos. As peculiaridades de cada sistema de saúde, suas normas operacionais
e os diferentes níveis de maturidade tecnológica podem influenciar como os resultados se
manifestam em diferentes ambientes.
Portanto, embora o estudo ofereça contribuições relevantes para a área de desenvolvimento de software para a saúde, é fundamental reconhecer essas limitações e interpretá-lo à luz
dessas considerações.
82
6.3
TRABALHOS FUTUROS
Para o futuro, propõe-se a implementação das boas práticas discutidas neste trabalho em
um ambiente de desenvolvimento de software dentro da indústria, com foco específico no setor
de saúde. Em um cenário real de desenvolvimento, é possível avaliar sua funcionalidade, o que
possibilita uma análise mais apofundada da interação entre usuários finais e desenvolvedores,
a identificação de desafios e a adaptação das práticas às demandas do setor da saúde. Além
disso, pesquisas futuras devem explorar como o uso de arquétipos em aplicações de saúde pode
contribuir para a sustentabilidade e a adaptabilidade do software a longo prazo, considerando
o cenário de saúde. Esse aspecto é importante para garantir que as soluções desenvolvidas
permaneçam eficazes e relevantes diante de mudanças nos requisitos e avanços tecnológicos.
Outra direção importante para futuras investigações está no desenvolvimento de métodos
para validar arquétipos, assegurando sua qualidade e adequação. Paralelamente, a ampliação da
amostragem para incluir diferentes contextos é essencial para compreender melhor a aplicabilidade dos arquétipos. Por fim, pode-se explorar o potencial de integração dos arquétipos com
tecnologias emergentes, como inteligência artificial e sistemas de suporte à decisão, fortalecendo
sua utilidade em soluções modernas. Essas iniciativas contribuirão significativamente para a
evolução do uso de arquétipos no desenvolvimento de software voltado à saúde.
83
REFERÊNCIAS
ABRAS, C.; MALONEY-KRICHMAR, D.; PREECE, J. et al. User-centered design. Bainbridge,
W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage Publications,
v. 37, n. 4, p. 445–456, 2004.
ALABDULHAFITH, M.; ALQARNI, A.; SAMPALLI, S. Customized communication between
healthcare members during the medication administration stage. In: Proceedings of the 20th International Conference on Human-Computer Interaction with Mobile Devices and Services.
[S.l.: s.n.], 2018. p. 1–8.
ARAUJO, A.; TIMES, V.; SILVA, M. A tool for generating health applications using archetypes.
IEEE Software, IEEE, v. 37, n. 1, p. 60–67, 2018.
ARAÚJO, A. M. C. de; TIMES, V. C.; SILVA, M. U. Towards a reusable framework for
generating health information systems. In: SPRINGER. 16th International Conference on
Information Technology-New Generations (ITNG 2019). [S.l.], 2019. p. 423–428.
ARAÚJO, A. M. C. de; TIMES, V. C.; SILVA, M. U. da. A cloud service for graphical user interfaces generation and electronic health record storage. In: SPRINGER. Information TechnologyNew Generations: 14th International Conference on Information Technology. [S.l.], 2018.
p. 257–263.
BACUNGAN, R. B. E.; CHOI, K. M. C.; CHUA, J. P. A.; DUPO, J. P.; ESTRELLA, N. E.
Sentinel: The development of a web and mobile application for the development and testing of an
e-service learning interprofessional telehealth community based rehabilitation program among
hypertensive clients. In: IEEE. 2021 International Conference on Software Engineering
& Computer Systems and 4th International Conference on Computational Science and
Information Management (ICSECS-ICOCSIM). [S.l.], 2021. p. 341–347.
BADR, N. G. Guidelines for health it addressing the quality of data in ehr information systems.
In: Healthinf. [S.l.: s.n.], 2019. p. 169–181.
BARBIERI, C.; NERI, L.; STUARD, S.; MARI, F.; MARTÍN-GUERRERO, J. D. From electronic health records to clinical management systems: how the digital transformation can support
healthcare services. Clinical Kidney Journal, Oxford University Press, v. 16, n. 11, p. 1878–
1884, 2023.
BARBOSA, S.; SILVA, B. Interação humano-computador. [S.l.]: Elsevier Brasil, 2010.
BELGAMO, A.; MARTINS, L. E. G. Estudo comparativo sobre as técnicas de elicitação de
requisitos do software. In: XX Congresso Brasileiro da Sociedade Brasileira de Computação
(SBC), Curitiba–Paraná. [S.l.: s.n.], 2000.
BICER, V.; KILIC, O.; DOGAC, A.; LALECI, G. B. Archetype-based semantic interoperability
of web service messages in the health care domain. International Journal on Semantic Web
and Information Systems (IJSWIS), IGI Global, v. 1, n. 4, p. 1–23, 2005.
BITKINA, O. V.; KIM, H. K.; PARK, J. Usability and user experience of medical devices: An
overview of the current state, analysis methodologies, and future challenges. International
Journal of Industrial Ergonomics, Elsevier, v. 76, p. 102932, 2020.
BOURQUE, P.; FAIRLEY, R. E. (Ed.). Guide to the Software Engineering Body of Knowledge
(SWEBOK), Version 3.0. Los Alamitos, CA, USA: IEEE Computer Society Press, 2014.
84
BRAUN, V.; CLARKE, V. Using thematic analysis in psychology qualitative research in psychology, 3 (2), 77-101. Online im Internet, p. 1–42, 2006.
CARROLL, J. M. HCI models, theories, and frameworks: Toward a multidisciplinary
science. [S.l.]: Elsevier, 2003.
CHATTERJEE, A.; PRINZ, A.; GERDES, M.; MARTINEZ, S.; PAHARI, N.; MEENA, Y. K.
Prohealth ecoach: user-centered design and development of an ecoach app to promote healthy
lifestyle with personalized activity recommendations. BMC Health Services Research, Springer,
v. 22, n. 1, p. 1120, 2022.
CHEN, R.; KLEIN, G. O.; SUNDVALL, E.; KARLSSON, D.; ÅHLFELDT, H. Archetype-based
conversion of ehr content models: pilot experience with a regional ehr system. BMC medical
informatics and decision making, Springer, v. 9, p. 1–13, 2009.
COMPANY, T. B. R. Software Products Global Market Report. 2023. Available in: <https:
//abrir.link/0sTyx>. Accessed: December 13, 2023.
COUTO, H.; LIMA, Í.; SOUZA, R.; ARAÚJO, A.; TIMES, V. A speech recognition mechanism
for enabling interactions between end-users and healthcare applications. In: SPRINGER. 17th
International Conference on Information Technology–New Generations (ITNG 2020). [S.l.],
2020. p. 429–435.
DAHELLA, S. S.; BRIGGS, J. S.; COOMBES, P.; FARAJIDAVAR, N.; MEREDITH, P.;
BONNICI, T.; DARBYSHIRE, J. L.; WATKINSON, P. J. Implementing a system for the realtime risk assessment of patients considered for intensive care. BMC Medical Informatics and
Decision Making, BioMed Central, v. 20, n. 1, p. 1–7, 2020.
DENECKE, K.; TIEBEL, J.; MEIER, J. How does shortage of health it professionals impact on
the digital health transformation? In: dHealth 2023. [S.l.]: IOS Press, 2023. p. 6–11.
DING, Y.; HU, Z.; WANG, Y.; XU, X.; NAN, S.; DUAN, H. Accelerate clinical decision
support system development by converting ontology to openehr archetypes. In: IEEE. 2023 9th
International Conference on Big Data and Information Analytics (BigDIA). [S.l.], 2023. p.
372–378.
FAIZZATI, M.; ARIFIANSYAH, F. Interaction design of fertility tracking application using usercentered design. In: IEEE. 2022 International Conference on Data and Software Engineering
(ICoDSE). [S.l.], 2022. p. 95–100.
FALCÃO, I.; SOUZA, D. d. S.; ARAUJO, F. P.; FERNANDES, J. G. d. S.; PIRES, Y. P.;
CARDOSO, D. L.; SERUFFO, M. C. Usability and cognitive benefits of a serious game to
combat aedes aegypti mosquito. In: IEEE. 2019 IEEE 32nd International Symposium on
Computer-Based Medical Systems (CBMS). [S.l.], 2019. p. 720–725.
FERREIRA, D. E.; SOUZA, J. M. de. Methodology for developing openehr archetypes: a
narrative literature review. Journal of Health Informatics, v. 15, n. 2, p. 53–59, 2023.
FERREIRA, J.; NOBLE, J.; BIDDLE, R. The semiotics of usage-centred design. Project Management and Risk Management in Complex Projects: Studies in Organizational Semiotics,
Springer, p. 211–229, 2007.
85
FICO, G.; HERNANZEZ, L.; CANCELA, J.; DAGLIATI, A.; SACCHI, L.; MARTINEZMILLANA, A.; POSADA, J.; MANERO, L.; VERDÚ, J.; FACCHINETTI, A. et al. What do
healthcare professionals need to turn risk models for type 2 diabetes into usable computerized
clinical decision support systems? lessons learned from the mosaic project. BMC medical
informatics and decision making, BioMed Central, v. 19, n. 1, p. 1–16, 2019.
FRANCESE, R.; RISI, M.; TORTORA, G.; SALLE, F. D. Thea: empowering the therapeutic
alliance of children with asd by multimedia interaction. Multimedia Tools and Applications,
Springer, v. 80, p. 34875–34907, 2021.
FREITAS, E. M. de; ZAMBON, M. S.; AUGUSTI, V. M. O uso de tecnologias aplicadas as
organizações de saúde como fator de seu desenvolvimento. Teoria & Prática: Revista de
Humanidades, Ciências Sociais e Cultura, v. 4, n. 2, p. 13–30, 2021.
GARCIA, D.; CINTHO, L. M. M.; MORO, C. M. C. Electronic health record to support chronic
kidney disease prevention—integrating guidelines and archetypes. In: IEEE. IEEE-EMBS
International Conference on Biomedical and Health Informatics (BHI). [S.l.], 2014. p.
193–196.
GHAZALI, M.; ARIFFIN, N. A. M.; OMAR, R. User centered design practices in healthcare: A
systematic review. In: 2014 3rd International Conference on User Science and Engineering
(i-USEr). [S.l.: s.n.], 2014. p. 91–96.
GIACHELLE, F.; IRRERA, O.; SILVELLO, G. Medtag: a portable and customizable annotation
tool for biomedical documents. BMC Medical Informatics and Decision Making, BioMed
Central, v. 21, n. 1, p. 1–19, 2021.
GOVELLA, A. Collaborative Product Design: Help Any Team Build a Better Experience.
[S.l.]: O’Reilly Media, 2019. ISBN 9781491974988.
HEFNY, W. E.; BOLOCK, A. E.; HERBERT, C.; ABDENNADHER, S. Chase away the virus: a
character-based chatbot for covid-19. In: IEEE. 2021 IEEE 9th International Conference on
Serious Games and Applications for Health (SeGAH). [S.l.], 2021. p. 1–8.
IGNÁCIO, R. C. et al. Guia facetado de técnicas de elicitaçao de requisitos. Florianópolis, SC,
2018.
ISHAK, M.; RAHMAN, R.; MAHMUD, T. Integrating cloud computing in e-healthcare: System
design, implementation and significance in context of developing countries. In: IEEE. 2021
5th International Conference on Electrical Engineering and Information Communication
Technology (ICEEICT). [S.l.], 2021. p. 1–6.
ISLAM, M. N.; RAIYAN, K. R.; MITRA, S.; MANNAN, M. R.; TASNIM, T.; PUTUL, A. O.;
MANDOL, A. B. Predictis: an iot and machine learning-based system to predict risk level of
cardio-vascular diseases. BMC Health Services Research, Springer, v. 23, n. 1, p. 171, 2023.
JACOBS, M.; JOHNSON, J.; MYNATT, E. D. Mypath: Investigating breast cancer patients’
use of personalized health information. Proceedings of the ACM on Human-Computer
Interaction, ACM New York, NY, USA, v. 2, n. CSCW, p. 1–21, 2018.
KITCHENHAM, B. A. Systematic review in software engineering: where we are and where we
should be going. In: Proceedings of the 2nd international workshop on Evidential assessment
of software technologies. [S.l.: s.n.], 2012. p. 1–2.
86
KOTONYA, G.; SOMMERVILLE, I. Requirements engineering: processes and techniques.
[S.l.]: Wiley Publishing, 1998.
KOUMPOUROS, Y. A highly user-centered design approach for developing a mobile health app
for pain management (painapp). In: The 14th PErvasive Technologies Related to Assistive
Environments Conference. [S.l.: s.n.], 2021. p. 320–329.
KOWATSCH, T.; NISSEN, M.; SHIH, C.-H. I.; RÜEGGER, D.; VOLLAND, D.; FILLER, A.;
KÜNZLER, F.; BARATA, F.; HUNG, S.; BÜCHTER, D. et al. Text-based healthcare chatbots
supporting patient and health professional teams: preliminary results of a randomized controlled
trial on childhood obesity. Persuasive Embodied Agents for Behavior Change (PEACH2017),
ETH Zurich, Department of Management, Technology and Economics, 2017.
KUMAR, M. A comparative study of universally accepted sdlc models for software development.
International Journal of Scientific Research in Science and Technology, v. 4, n. 5, p. 31,
2018.
LADWA, S.; GRØNLI, T.-M.; GHINEA, G. Towards encouraging a healthier lifestyle and
increased physical activity–an app incorporating persuasive design principles. In: SPRINGER.
Human-Computer Interaction. Interaction in Context: 20th International Conference, HCI
International 2018, Las Vegas, NV, USA, July 15–20, 2018, Proceedings, Part II 20. [S.l.],
2018. p. 158–172.
LEAU, Y. B.; LOO, W. K.; THAM, W. Y.; TAN, S. F. Software development life cycle agile vs traditional approaches. In: International Conference on Information and Network Technology.
[S.l.: s.n.], 2012. v. 37, n. 1, p. 162–167.
LEHMANN, N. J.; KARAGÜLLE, M.-U.; MEURER, P.; NIEDERMEYER, E.; VIDISHIQI, P.;
PYSZ, L.; KRESS, M.; MUTH, L. R.; FELDMEIER, H.; SAHONDRA, B. R. et al. Designing
aina-intercultural human-centered design of an ai-based application for supporting the diagnosis
of female genital schistosomiasis. In: IEEE. 2022 IEEE 10th International Conference on
Healthcare Informatics (ICHI). [S.l.], 2022. p. 431–441.
LEITE, J. Elicitação de requisitos. In: Anais do XXIII Congresso Nacional de Informática.
[S.l.: s.n.], 1994.
LESLIE, H. openehr archetype use and reuse within multilingual clinical data sets: case study.
Journal of medical Internet research, JMIR Publications Toronto, Canada, v. 22, n. 11, p.
e23361, 2020.
LI, M. Usability problems and obstacles to addressing them in health information software implementations. In: SPRINGER. Information and Communication Technologies for Development.
Strengthening Southern-Driven Cooperation as a Catalyst for ICT4D: 15th IFIP WG 9.4
International Conference on Social Implications of Computers in Developing Countries,
ICT4D 2019, Dar es Salaam, Tanzania, May 1–3, 2019, Proceedings, Part II 15. [S.l.], 2019.
p. 241–252.
MAEDA, H.; SAIKI, S.; NAKAMURA, M.; YASUDA, K. Memory aid service using mind
sensing and daily retrospective by virtual agent. In: SPRINGER. Digital Human Modeling and
Applications in Health, Safety, Ergonomics and Risk Management. Healthcare Applications:
10th International Conference, DHM 2019, Held as Part of the 21st HCI International
Conference, HCII 2019, Orlando, FL, USA, July 26–31, 2019, Proceedings, Part II 21. [S.l.],
2019. p. 353–364.
87
MARINHO, L. L.; NÓBREGA, I. C. P. da; PI, N. S.; COSTA, R. M. E. M. da; WERNECK, V.
M. B. Increasing availability control of human biological samples using a mobile management
system. In: SPRINGER. Digital Human Modeling and Applications in Health, Safety, Ergonomics and Risk Management. Healthcare Applications: 10th International Conference,
DHM 2019, Held as Part of the 21st HCI International Conference, HCII 2019, Orlando,
FL, USA, July 26–31, 2019, Proceedings, Part II 21. [S.l.], 2019. p. 63–74.
MARKETS; MARKET. Healthcare IT Market by Products Services (Healthcare Provider
Solutions, Healthcare Payer Solutions, HCIT Outsourcing Services), Components (Services,
Software, Hardware), End User (Hospitals, Pharmacies, Payers) Region - Global Forecast
to 2027. 2023. Available in: <https://abrir.link/vmpsG>.
MARTINI, N.; BROADBENT, E.; KOO, J.; LAM, L.; VERCHES, D.; ZENG, S.;
MONTGOMERY-WALSH, R.; SUTHERLAND, C. Investigating the usability, efficacy and
accuracy of a medication entering software system for a healthcare robot. Frontiers in Robotics
and AI, Frontiers Media SA, v. 9, p. 814268, 2022.
MEEHAN, R. A. The need to optimize the electronic health record: Usability issues in legacy
systems can compromise patient safety. In: HEALTHINF. [S.l.: s.n.], 2020. p. 609–613.
MELDER, A.; ROBINSON, T.; MCLOUGHLIN, I.; IEDEMA, R.; TEEDE, H. An overview of
healthcare improvement: unpacking the complexity for clinicians and managers in a learning
health system. Internal medicine journal, Wiley Online Library, v. 50, n. 10, p. 1174–1184,
2020.
MESQUITA, R.; SILVA, G.; CANEDO, E. On the experiences of practitioners with requirements
elicitation techniques. In: Proceedings of the XXXVII Brazilian Symposium on Software
Engineering. [S.l.: s.n.], 2023. p. 442–451.
MIN, L.; TIAN, Q.; LU, X.; AN, J.; DUAN, H. An openehr based approach to improve the
semantic interoperability of clinical data registry. BMC medical informatics and decision
making, Springer, v. 18, p. 49–56, 2018.
MOHER, D.; LIBERATI, A.; TETZLAFF, J.; ALTMAN, D. G.; GROUP*, P. Preferred reporting
items for systematic reviews and meta-analyses: the prisma statement. Annals of internal
medicine, American College of Physicians, v. 151, n. 4, p. 264–269, 2009.
MONER, D.; MALDONADO, J. A.; ROBLES, M. Archetype modeling methodology. Journal
of biomedical informatics, Elsevier, v. 79, p. 71–81, 2018.
NIMMOLRAT, A.; KHUWUTHYAKORN, P.; WIENTONG, P.; THINNUKOOL, O. Pharmaceutical mobile application for visually-impaired people in thailand: development and implementation. BMC medical informatics and decision making, BioMed Central, v. 21, n. 1, p. 1–19,
2021.
OLIVEIRA, D.; HAK, F.; GUERRA, H.; ABELHA, A. Electronic health records structuring
based on the openehr standard. In: Big Data Analytics and Artificial Intelligence in the
Healthcare Industry. [S.l.]: IGI Global, 2022. p. 192–212.
PALMER, R. C.; SIMMS-CENDAN, J. S. Implementing an electronic health record as an
objective measure of care provider accountability for a resource-poor rural area in the dominican
republic. IET, 2012.
88
PALOJOKI, S.; LEHTONEN, L.; VUOKKO, R. et al. Semantic interoperability of electronic
health records: Systematic review of alternative approaches for enhancing patient information
availability. JMIR medical informatics, JMIR Publications Inc., Toronto, Canada, v. 12, n. 1, p.
e53535, 2024.
PERES, F. M.; MORAIS, D. C. Desafios do design de interação para contextos contrahegemônicos: destacando e superando contradições para transformação social e responsividade. In: SBC. Anais do XX Simpósio Brasileiro sobre Fatores Humanos em Sistemas
Computacionais. [S.l.], 2021.
PETERSEN, K.; VAKKALANKA, S.; KUZNIARZ, L. Guidelines for conducting systematic
mapping studies in software engineering: An update. Information and software technology,
Elsevier, v. 64, p. 1–18, 2015.
PITKÄNEN, J.; PITKÄRANTA, M. Improving meaningful use and user experience of healthcare
information systems towards better clinical outcomes. Finnish Journal of eHealth and eWelfare,
v. 8, n. 2-3, p. 98–106, 2016.
PREECE, J.; ROGERS, Y.; SHARP, H.; BENYON, D.; HOLLAND, S.; CAREY, T. Humancomputer interaction. [S.l.]: Addison-Wesley Longman Ltd., 1994.
PUSPITASARI, I.; CAHYANI, D. I. et al. A user-centered design for redesigning e-government
website in public health sector. In: IEEE. 2018 International Seminar on Application for
Technology of Information and Communication. [S.l.], 2018. p. 219–224.
QUINDE, M.; KHAN, N.; AUGUSTO, J. C.; WYK, A. van. A human-in-the-loop contextaware system allowing the application of case-based reasoning for asthma management. In:
SPRINGER. Digital Human Modeling and Applications in Health, Safety, Ergonomics and
Risk Management. Healthcare Applications: 10th International Conference, DHM 2019,
Held as Part of the 21st HCI International Conference, HCII 2019, Orlando, FL, USA, July
26–31, 2019, Proceedings, Part II 21. [S.l.], 2019. p. 125–140.
RAHUTOMO, R.; PERBANGSA, A. S.; ASADI, F.; NIRWANTONO, R.; PARDAMEAN, B.
A design of childhood stunting assessment feature with agile ux approach. In: IEEE. 2022 8th
International HCI and UX Conference in Indonesia (CHIuXiD). [S.l.], 2022. v. 1, p. 1–6.
REPORTS, P. Software Market Analysis Research Report [2023-2030]. 2023. Available in:
<https://abrir.link/87Pfn>.
REZAEI-HACHESU, P.; SAMAD-SOLTANI, T.; YAGHOUBI, S.; GHAZISAEEDI, M.; MIRNIA, K.; MASOUMI-ASL, H.; SAFDARI, R. The design and evaluation of an antimicrobial
resistance surveillance system for neonatal intensive care units in iran. International Journal of
Medical Informatics, Elsevier, v. 115, p. 24–34, 2018.
ROGERS, Y.; SHARP, H.; PREECE, J. Design de interação. [S.l.]: Bookman Editora, 2013.
ROQUE, G.; CAVALCANTI, A.; NASCIMENTO, J.; SOUZA, R.; QUEIROZ, S. Botcovid:
Development and evaluation of a chatbot to combat misinformation about covid-19 in brazil.
In: IEEE. 2021 IEEE International Conference on Systems, Man, and Cybernetics (SMC).
[S.l.], 2021. p. 2506–2511.
SILVA, J.; ARAÚJO, A.; COUTINHO, F.; SILVA, A. Are end-users participating in the life
cycle of healthcare application development? an analysis of the opportunities and challenges of
the use of hci techniques in the healthcare sector. BIOSTEC (2), p. 789–796, 2024.
89
STAFFORD, P.; ERDIL, K.; FINN, E.; KEATING, K.; MEATTLE, J.; PARK, S.; YOON, D.
Software maintenance as part of the software life cycle. Medford, MA, US, Department of
Computer Science, Tufts University, Medford, MA, US, 2003.
TETTEH, S. G. Empirical study of agile software development methodologies: A comparative
analysis. Asian Journal of Research in Computer Science, v. 17, n. 5, p. 30–42, 2024.
VEALE, G.; DOGAN, H.; MURPHY, J. Development and usability evaluation of a nutrition and
lifestyle guidance application for people living with and beyond cancer. In: SPRINGER. Design,
User Experience, and Usability. Application Domains: 8th International Conference, DUXU
2019, Held as Part of the 21st HCI International Conference, HCII 2019, Orlando, FL,
USA, July 26–31, 2019, Proceedings, Part III 21. [S.l.], 2019. p. 337–347.
WANG, L.; MIN, L.; WANG, R.; LU, X.; DUAN, H. Archetype relational mapping-a practical
openehr persistence solution. BMC medical informatics and decision making, Springer, v. 15,
p. 1–18, 2015.
WU, Z.; TRIGO, V. Impact of information system integration on the healthcare management
and medical services. International Journal of Healthcare Management, Taylor & Francis,
v. 14, n. 4, p. 1348–1356, 2021.
ZOTOV, E.; HILLS, A. F.; MELLO, F. L. de; ARAM, P.; SAYERS, A.; BLOM, A. W.; MCCLOSKEY, E. V.; WILKINSON, J. M.; KADIRKAMANATHAN, V. Jointcalc: A web-based
personalised patient decision support tool for joint replacement. International journal of
medical informatics, Elsevier, v. 142, p. 104217, 2020.
90
APÊNDICE A – Modelo do E-mail
91
92
93
APÊNDICE B – Termo de Consentimento Livre e Esclarecido
94
95
APÊNDICE C – Comitê de Ética em Pesquisa
96
97
98
99
100
101
102