2021-FelipeBritoAyres-tcc

Prévia do material em texto

Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Técnicas para Realizar a Validação de Requisitos no
Contexto de Internet das Coisas (IoT)
Felipe Brito Ayres
Monografia apresentada como requisito parcial
para conclusão do Curso de Engenharia da Computação
Orientadora
Prof.a Dr.a Edna Dias Canedo
Brasília
2021
Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Técnicas para Realizar a Validação de Requisitos no
Contexto de Internet das Coisas (IoT)
Felipe Brito Ayres
Monografia apresentada como requisito parcial
para conclusão do Curso de Engenharia da Computação
Prof.a Dr.a Edna Dias Canedo (Orientadora)
CIC/UnB
Prof.a Dr.a Roberta Barbosa Oliveira Prof.a Dr.a Letícia Lopes Leite
CIC/UnB CIC/UnB
Prof. Dr. João José Costa Gondim
Coordenador do Curso de Engenharia da Computação
Brasília, 21 de outubro de 2021
Dedicatória
Dedico este trabalho a minha família que sempre me apoiou, tanto na minha vida pessoal
quanto acadêmica. Foram 5 anos de muito esforço, dedicação e a presença deles tornou
esse tempo mais tranquilo para que pudesse me formar. Minha mãe por sempre estar
presente, receptível e paciente e a meu pai que, por ser da área de engenharia, foi um
norte e que pude me espelhar para seguir firme durante o curso.
iii
Agradecimentos
Aos meus pais Elana e Florêncio, que estiveram comigo durante toda minha jornada e
fizeram o possível para me incentivar e ajudar.
Á minha família, em especial, aos meus avós maternos, Deijayme e Maria José, e aos
meus falecidos avós paternos, Florêncio e Amanda, pela garra que tiveram durante a vida
e que possibilitaram o crescimento de uma família grande e próspera.
Agradeço ao Lucas, parceiro durante a pesquisa exploratória para este trabalho e que
facilitou muito o desenvolvimento das atividades.
Á minha orientadora, Edna Dias Canedo, que sanou minhas dúvidas durante o processo
do trabalho de graduação e esteve sempre disponível.
Por fim, agradeço aos meus amigos dos ensinos primário, médio e universitário, par-
ceiros de minha jornada estudantil, que somaram experiências e vivências durante este
período especial e de muitos aprendizados.
O presente trabalho foi realizado com apoio da Coordenação de Aperfeiçoamento de
Pessoal de Nível Superior - Brasil (CAPES), por meio do Acesso ao Portal de Periódicos.
iv
Resumo
A internet das coisas vem ocupando um espaço cada vez maior em equipes de desenvolvi-
mento de software e na sociedade. O nível de aplicação da IoT é abrangente. Tráfego
de pessoas, casas inteligentes, ambientes otimizados e gestão de água/energia são alguns
dos exemplos da sua aplicabilidade. Nesse universo de possibilidades, desenvolvedores e
empresas de tecnologia devem estar preparados para adaptar seus projetos e absorver essa
tecnologia em expansão. Como essa tecnologia é recente, falhas de projeto e retrabalho
acontecem com frequência e dificultam o desenvolvimento de produtos de alta qualidade
atualmente. O objetivo deste trabalho é identificar por meio de uma pesquisa explo-
ratória, processos e técnicas de validação, voltadas ao contexto da internet das coisas.
Além disso, investigamos a percepção dos desenvolvedores de software IoT sobre as suas
atividades relacionadas a Engenharia de Requisitos em seus projetos. A percepção dos
profissionais foi coletada através de entrevistas onde eles relataram as dificuldades e de-
safios que enfrentam durante suas atividades diárias. Foram encontrados 22 processos e
9 técnicas de validação para o contexto de IoT na literatura. A partir das entrevistas, foi
possível perceber que stakeholders de projetos IoT não utilizam um processo formal de
engenharia de requisitos. Normalmente, são utilizadas técnicas distintas como reuniões
e diagramas, sempre com base na demanda e na necessidade do projeto. Apesar dos
profissionais e stakeholders acharem importante a Engenharia de Requisitos, a adesão à
processos e técnicas voltadas a IoT não é unânime devido a curva de aprendizado para
adotar novos métodos e a falta de maleabilidade nos processos durante o desenvolvimento
de software.
Palavras-chave: Requisitos, IoT, internet das coisas, técnicas de validação, validação,
entrevistas, pesquisa exploratória.
v
Abstract
Internet of things occupies more and more space in development teams and in society in
general. The applicability that IoT covers is huge. Smart houses, water/energy consup-
tion, traffic management and smart buildings are some examples of what has been made
in this context. In this vast universe of possibilities, developers and tech companies need
to be prepared and adapt their projects to cover it.
With that in mind, failures/reworks in projects happens more easily and makes it more
difficult to produce high standards products. The objective of this paper is to identify,
based on a exploratory research, processes and validation techniques in IoT context.
Furthermore, this work investigates the professionals‘ perception in their activities with
requirenment engineering in IoT projects. Their reports were collected through interviews
so they could explain the difficulties and problems that arise in their daily work.
In total, 22 processes and 9 validation techniques has been found in literature. From
the interviews, it had been realized that stakeholders don´t use formal processes in their
IoT projects. Usually, single techniques are used, like reunions and diagramans, to handle
the requirements engineering.The stakeholders implement these methods based on the
demand and size of the project. Although stakeholders thinks that RE is a important
part inside a project, the use of processes and techniques for IoT development isn´t
unanimous due to the learning curve to adopt such methods and the lack of flexibility in
these processes during the development phase.
Keywords: requirements, IoT , internet of things, techniques of validation, interviews,
exploratory research
vi
Sumário
1 Introdução 1
1.1 Problema de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Metodologia de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Embasamento Teórico 5
2.1 Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Classificação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Processos em Engenharia de Software . . . . . . . . . . . . . . . . . . 7
2.1.3 Etapas do Processo em RE . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Técnicas para Realizar a Validação e Verificação de Requisitos . . . . 11
2.1.5 Aplicações da IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Processos de Engenharia de Requisitos no Contexto de IoT . . . . . . . . . . 15
2.2.1 A Requirements Engineering Process for IoT Systems . . . . . . . . . 16
2.2.2 A UML-based Proposal for IoT System Requirements Specification . . 18
2.2.3 TrUStAPIS: A Trust Requirements Elicitation Method for IoT . . . . 19
2.2.4 REM4DSPL: A Requirements Engineering Method for Dynamic Soft-
ware Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.5 Modeling IoT Aplications with SysML4IoT . . . . . . . . . . . . . . . 21
2.2.6 Specifying Functional Requirements and QoS Parameters for IoT Sys-
tems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.7 Design Science and ThinkLets as an Holistic Approach to Design
IoT/IoS Systems . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
vii
2.2.8 An Improved RE Framework for IoT-Oriented Smart Applications
using Integrated Approach . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.9 Detecting IoT Applications Opportunities and Requirements Elicita-
tion: A Design Thinking Based Approach . . . . . . . . . . . . . . . . 27
2.2.10 An Evidence-Based Framework for Supporting the Engineering of IoT
Software Systems Mid-stage Research . . . . . . . . . . . . . . . . . . 28
2.2.11 Non Functional Requirement Analysis in IoT based smart traffic ma-
nagement system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.12 Horizontal Requirement Engineering in Integration of Multiple IoT
Use Cases of City Platform as a Service . . . . . . . . . . . . . . . . . 31
2.2.13 Towards Modelling and Analysis of Spatial and Temporal Requirements 32
2.2.14 Uma Tecnologia para Apoiar a Engenharia de Requisitos de Sistemas
de Software IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.15 IoT Composer: Composition and Deployment of IoT Applications . . 34
2.2.16 Conversion Method for User Experience Design Information and Soft-
ware Requirement Specification . . . . . . . . . . . . . . . . . . . . . 35
2.2.17 Key Abstractions for IoT-Oriented Software Engineering . . . . . . . 35
2.2.18 Towards a catalog of conflicts for HCI quality characteristics in Ubi-
Comp and IoT applications: Process and first results . . . . . . . . . 37
2.2.19 Emotion-oriented requirements engineering: A case study in develo-
ping a smart home system for the elderly . . . . . . . . . . . . . . . . 38
2.2.20 IoT System Development Methods . . . . . . . . . . . . . . . . . . . . 42
2.2.21 Stakeholder Identification and Use Case Representation for Internet-
of-Things Applications in Healthcare . . . . . . . . . . . . . . . . . . 47
2.2.22 Intelligent Parking Management by Means of Capability Oriented Re-
quirements Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3 Síntese dos Processos de Engenharia de Requisitos no contexto da IoT . . . . 49
2.4 Técnicas de Validação de Requisitos no Contexto de IoT . . . . . . . . . . . 52
2.4.1 SCENARIoT: Support for scenario specification of internet of things-
based software systems . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.2 SCENARIoTCHECK: Uma Técnica de Leitura Baseada em Checklist
para Verificação de Cenários IoT . . . . . . . . . . . . . . . . . . . . . 55
2.4.3 Towards the Description and Representation of Smartness in IoT Sce-
narios Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.4 Requirement Engineering Technique for Smart Spaces . . . . . . . . . 59
2.4.5 Requirements for Testing and Validating the Industrial Internet of
Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
viii
2.4.6 IoT Roadmap: Support for Internet of Things Software Systems En-
gineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.5 Síntese das técnicas de validação em Engenharia de Requisitos no contexto
da IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.6 Síntese do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3 Entrevistas 64
3.1 Seleção dos participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2 Processo das entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3 Perfil dos entrevistados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 Resultados 68
4.1 Pesquisa exploratória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.1 Processos no contexto IoT . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.2 Técnicas de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2 Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.1 Ameaças a Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Conclusão e Trabalhos Futuros 76
Referências 78
ix
Lista de Figuras
1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Modelo linear [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Modelo linear Iterativo [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Modelo Iterativo não linear [1] . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Modelo em Espiral [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Modelo de processo em RE voltado a IoT [2]. . . . . . . . . . . . . . . . . . 16
2.6 Sub-processo 1: Definição de escopo [2]. . . . . . . . . . . . . . . . . . . . . 17
2.7 Sub-processo 2: Definição do sistema IoT [2]. . . . . . . . . . . . . . . . . . 18
2.8 Sub-processo 3: Definição dos requisitos para o sistema IoT [2]. . . . . . . 18
2.9 Visão geral sobre o funcionamento da ferramenta ThinkLets [3]. . . . . . . 25
2.10 Funcionamento da ferramenta IoT Composer [4]. . . . . . . . . . . . . . . . 34
2.11 Passos do processo proposto por Carvalho et al. no contexto da UbiComp
[5]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.12 Modelo de Objetivos do SofiHub . . . . . . . . . . . . . . . . . . . . . . . . 42
2.13 Processo de estruturação de uma IIA segundo Silva [6]. . . . . . . . . . . . 53
2.14 Processo da SCENARIoTCHECK com base na melhoria do processo SCE-
NARIoT proposto por Silva [6]. . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.1 Resultado dos métodos utilizados em processos . . . . . . . . . . . . . . . . 69
4.2 Relato dos entrevistados a respeito da importância da etapa de engenharia
de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3 Relato dos entrevistados sobre as dificuldades em desenvolvimento de pro-
jetos IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
x
Lista de Tabelas
2.1 Três fases do processo envolvendo a DSR [3]. . . . . . . . . . . . . . . . . . 24
2.2 Questões chave levantadas por Zambonelli para a elaboração de um sistema
utilizando IoT [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Visão geral dos Processos de Engenharia de Requisitos no contexto da IoT . 52
2.4 Checklist utilizada por Souza [8] para esclarecer possíveis inconsistências na
SCENARIoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5 Elaboração de um cenário baseado em smartness (inteligência), segundo
Souza [9]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.6 Análise do cenário produzido pela técnica [9]. . . . . . . . . . . . . . . . . . 59
2.7 Visão geral das técnicas de validação de requisitos existentes em Internet
das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1 Informações demográficas dos participantes da entrevista . . . . . . . . . . . 67
4.1 Fases abordadas em cada processo . . . . . . . . . . . . . . . . . . . . . . . 70
xi
Lista de Abreviaturas e Siglas
5W1H O que, Como, Quem, Quando e Por quê.
ADL Linguagem de Descrição de Arquitetura.
AIIs Arranjos de Interação IoT.
AIOTI Aliança para a Inovação em Internet das Coisas.
BPMN Notação para Modelagem de Processos de Negócio.
CADP Construção e Análises de Processos Distribuídos.
CORE Engenharia de Requisitos Orientada a Capacidade.
CPPS Sistemas Cibernéticos de Produção Física.
CSS Sistema de Software Contemporâneo.
DE Expositores de Dados.
DSPL Linha de Produto de Software Dinâmico.
DSR Design Science Research.
EoI Entidade de Interesse.
GIS Sistema de Informação Geográfica.
GORE Engenharia de Requisitos Orientada por Objetivos.
GSEM-IoT Metodologia Geral de Engenharia de Software para a Internet das Coisas.
HID Dispositivo de Interface Humana.
IIA Arranjos de Interação em IoT.
xii
IoT Internet das Coisas.
IoT-AD Desenvolvimento de Aplicativos IoT.
IoT-RML Linguagemde Modelagem de Requisitos em IoT.
KAOS Manter Todos os Objetivos Satisfeitos.
LNT Nova Tecnologia LOTOS.
M2M Máquina para Máquina.
MBD Design Baseado em Modelo.
RE Engenharia de Requisitos.
REM4DSPL Método para Engenharia de Requisitos para Linhas de Produtos de Soft-
ware Dinâmicos.
RR Revisão Rápida.
SAL Linguagem de Arquitetura Srijan.
SDL Linguagem de Implantação Srijan.
SDM Métodos de Desenvolvimento do Sistema.
SRS Especificação de Requisitos de Software.
SVL Linguagem de Vocabulário Srijan.
UbiComp Computação Ubíqua.
UFRJ Universidade do Rio de Janeiro.
UXD Design de Experiência do Usuário.
WoT Rede das Coisas.
xiii
Capítulo 1
Introdução
De acordo com Filho [10], a Engenharia de Requisitos (RE) possui como responsabilidade
principal a identificação e análise de requisitos, com o objetivo de minimizar erros e
economizar custos ao simplificar e corrigir eventuais falhas nos requisitos elicitados, antes
de ser repassado para as fases seguintes do processo de desenvolvimento de software,
incluindo a validação de requisitos. Para Schwab [11], um dos desafios da RE no contexto
da Internet das Coisas (IoT) é a necessidade de realizar uma constante validação de dados,
motivando a análise das técnicas existentes na RE para obter informações mais precisas.
A Internet das Coisas proporciona que objetos do dia-a-dia se comuniquem com a
Internet, desde que seus recursos eletrônicos permitam esta tarefa [12]. A comunicação
com a Internet é realizada através de um dispositivo eletrônico com módulo integrado de
conexão à rede. Desde sua criação, a Internet das Coisas propõe o compartilhamento de
informações em objetos, fornecendo dados e permitindo que os dispositivos controlem a
si mesmos e a outros [13].
A Internet das Coisas ganhou um destaque significativo nos últimos anos para pessoas
e empresas, cujos interesses se convergem em ter maior praticidade e economia em suas
atividades cotidianas [12], uma vez que equipamentos interligados podem proporcionar
redução no consumo elétrico e maior conforto para os usuários. No entanto, a RE enfrenta
um desafio com a IoT [11] uma vez que a definição e escolha das técnicas para validar
os requisitos dos dispositivos da IoT se mostra importante para que seu funcionamento
possa ser garantido, pois os dispositivos são meros coletores de dados, porém os mesmos
tendem a ter mais inteligência e necessidades [14].
Os sistemas no contexto da IoT são complexos e heterogêneos e as pesquisas na área de
Requisitos de Software para IoT são limitados e muitas vezes específicos a um determinado
tipo de projeto [15], [16].
1
1.1 Problema de pesquisa
A engenharia de requisitos no contexto de internet das coisas é marcada pela falta de
uma abordagem sistemática para o desenvolvimento de aplicações IoT [2], bem como não
possui técnicas específicas para validar os requisitos funcionais e não funcionais dessas
aplicações [2].
1.2 Justificativa
Com o crescimento da internet das coisas, diversas aplicações foram surgindo [2], fazendo
com que a engenharia de requisitos passasse a ter um papel fundamental nas fases iniciais
do projeto, garantindo uma melhor qualidade no desenvolvimento dos sistemas. Propor
processos e técnicas específicas para IoT permite um melhor produto e um menor re-
trabalho por parte das equipes de desenvolvimento de sistemas. Além disso, mapear as
dificuldades e as percepções dos desenvolvedores a respeito da área permite a criação de
processos que se adaptem melhor aos utilizadores.
1.3 Objetivos
Essa seção destina-se a descrever o objetivo central do trabalho e os objetivos secundários
a serem alcançados.
1.3.1 Objetivo Geral
Este trabalho tem como objetivo fazer a conexão entre a literatura da engenharia de
requisitos no contexto de IoT com o desenvolvimento em situações reais de produtos IoT
por empresas e desenvolvedores.
1.3.2 Objetivos Específicos
Para atingir o Objetivo Geral, os seguintes objetivos específicos foram definidos:
1. Realizar uma pesquisa exploratória para identificar na literatura os processos de RE
existentes no contexto IoT;
2. Realizar uma pesquisa exploratória para identificar na literatura técnicas de valida-
ção de requisitos no contexto IoT;
3. Avaliar como as empresas de IoT utilizam os processos da engenharia de requisitos
e as técnicas de validação de requisitos no desenvolvimento de seus projetos;
2
4. Levantar as dificuldades encontradas por desenvolvedores e equipes para desenvol-
verem projetos IoT;
5. Analisar as percepções dos stakeholders em IoT a respeito da engenharia de requi-
sitos;
1.4 Resultados Esperados
Espera-se com esse trabalho identificar as propostas de processos e técnicas de validação
da RE na literatura e que possam ser utilizadas pela IoT, obter das equipes de desenvol-
vimento de software a utilidade desses processos e técnicas para lidar com a validação dos
requisitos.
1.5 Metodologia de Pesquisa
A metodologia utilizada neste trabalho consiste das seguintes etapas:
1. Pesquisa Exploratória: Revisão da literatura para identificar as técnicas de vali-
dação de requisitos e os processos da engenharia de requisitos no contexto da IoT.
2. Entrevista semi-estruturada com profissionais de IoT: Etapa responsável
por obter a percepção dos profissionais da área de desenvolvimento de software IoT
sobre a aplicabilidade/dificuldade da implantação dos processos da RE além de uma
explanação sobre a realidade da área e suas dificuldades.
3. Análise e descrição dos resultados: A partir das entrevistas e da revisão de
literatura descreveremos os resultados obtidos.
Figura 1.1: Metodologia
3
1.6 Estrutura do Trabalho
O Capítulo 2 apresenta o referencial teórico com a finalidade de aprofundar os conhecimen-
tos gerais sobre Engenharia de Requisitos e Internet das Coisas e a pesquisa exploratória
para identificar os processos e técnicas de validação de requisitos no contexto da IoT.
O Capítulo 3 é destinado a parte metodológica das entrevistas realizadas. Nele des-
crevemos a estrutura utilizada para as conversas, além dos participantes envolvidos e
objetivos a serem alcançados pelas entrevistas.
O Capítulo 4 descreve os resultados obtidos a partir da pesquisa exploratória e a partir
das entrevistas e questões de pesquisa propostas no capítulo 3.
O Capítulo 5 conclui este trabalho e descreve os próximos passos ou melhorias que
poderão ser incorporadas a este trabalho.
4
Capítulo 2
Embasamento Teórico
Este Capítulo apresenta os conceitos necessários para o entendimento deste trabalho. Na
Seção 2.1 é apresentando os conceitos gerais relativos a Engenharia de Requisitos. A
Seção 2.2 apresenta os processos existentes para validação de requisitos em dispositivos
IoT. A Seção 2.3 realiza uma síntese dos processos existentes na validação de requisitos
IoT. Já na Seção 2.4 são apresentadas as técnicas propostas para a validação de requisitos
no contexto da IoT. Com base nisso, a Seção 2.5 destaca uma visão geral das técnicas de
validação de requisitos em IoT.
2.1 Engenharia de Requisitos
Engenharia de Requisitos (RE), uma subárea da Engenharia de Software, possui relevân-
cia para a elaboração de um software por possuir a responsabilidade de levantar todas
as solicitações requeridas pelo stakeholder, elaborar uma documentação e repassar to-
dos estes requisitos para todas as partes interessadas de maneira clara, concisa e sem
ambiguidades [10].
Outra principal responsabilidade desta área é a redução dos custos ao longo do pro-
cesso. Este processo, chamado de Validação de Software, possui como objetivo identificar
informações conflitantes (seja por ambiguidade ou conflitos com a legislação) e solucioná-
las antes de ser iniciada a construção do software. De acordo com Kalinowski e Spínola
[17], os custos para reparar um eventual erro cometido por falha na análise de requisitos
pode variar de acordo com o nível de evolução do desenvolvimento, sendo bastante caro
caso alguma inconsistência seja encontrada na fase final do produto de software.
Todas estas questõesocorrem através de um ponto de partida mutualmente relacio-
nado, os stakeholders. Bourque e Fairley [18] afirmam que, em todo projeto relacionado
a RE, é necessário definir os atores, escutar suas necessidades, para que posteriormente
5
possa ser feito a validação destes requisitos, seguida pela compilação e verificação com os
usuários. Os atores são:
• Usuário: pessoa que irá utilizar o produto final, sem nenhuma relação com o desen-
volvimento de um software;
• Clientes: parte principal do projeto de software, são as pessoas que encomendam o
software para proporcionar uma boa experiência de seus serviços para os clientes da
companhia;
• Analistas de mercado: ator que tem o papel de sondar novas tecnologias e tendências
no meio externo, podendo adicionar algumas ideias para o projeto;
• Reguladores: tipo de ator que deve possuir domínio na área de atuação para projetos
de software que envolvam portarias e outras normas, como bancos, mineração e
logística;
• Engenheiros de Software: primordial para todo o projeto de elaboração do software,
possui a responsabilidade de ouvir os clientes, validar seus requisitos (isto é, verifi-
car inconsistências), compilar e verificar o sistema junto com os clientes enquanto
aguarda um feedback. Todas estas funções devem ser executadas de modo a propor-
cionar uma redução nos custos do projeto, mesmo que possa ser difícil para softwares
cujo funcionamento dependa de autorizações alheias às partes interessadas.
Avila e Spínola [19] definem a Engenharia de Requisitos (RE) como um conjunto de
atividades que coordenam a produção e gerência de um projeto de software. As atividades
são:
• Produção de Requisitos: construção do projeto de software, em que os requisitos,
uma vez categorizados, são registrados através de uma documentação detalhada,
para que possam ser verificados (com a finalidade de eliminar possíveis inconsistên-
cias, como ambiguidades e outros tipos de problemas) e validados com os stakehol-
ders.
• Gerência de Requisitos: é a parte sensível da RE em decorrência de mudanças
alheias ao projeto - mudanças na legislação ou mercado - e por eventuais falhas
que passaram despercebidas pela fase de verificação de requisitos. Neste contexto,
possui a responsabilidade de coordenar mudanças, gerenciar configurações (permite
realizar as mudanças necessárias sem ferir a integridade do software), realizar a
rastreabilidade (isto é, criar e manter um escopo para as funções) e gerenciar a
qualidade dos requisitos, esta última, análoga à Produção de Requisitos.
6
2.1.1 Classificação de Requisitos
Vazques e Simões [20] definem requisitos como as informações dadas pelos stakeholders de
uma organização, informando suas particularidades, descrevendo permissões, restrições e
todas as condições necessárias para que um sistema satisfaça suas necessidades. Segundo
Bourque e Fairley [18], existem duas categorias de requisitos vigentes na RE:
• Requisitos funcionais: descreve as funções principais que um software deve executar
a cada comando de usuário, como o ato de informar credenciais;
• Requisitos não funcionais: ferramentas que envolvem o escopo dos requisitos funcio-
nais, com a finalidade de proporcionar maior controle sobre um sistema, concedendo
ou restringindo permissões para usuários.
Segundo Sommerville [21], os requisitos não funcionais, por realizar restrições, são
categorizados em três modos, de acordo com as políticas internas da companhia ou por
fatores externos:
• Requisitos de produto: concedem permissões ou negam acesso para alguns tipos de
usuário;
• Requisitos organizacionais: são regras impostas pelo cliente (de acordo com as po-
líticas internas da empresa) para acesso a certas funcionalidades do software;
• Requisitos externos: sistemas cujo funcionamento dependem de permissões con-
cedidas por fatores alheios aos stakeholders, como certificações de segurança para
bancos.
2.1.2 Processos em Engenharia de Software
Engenharia de requisitos é uma parte fundamental do desenvolvimento de um software
como um todo. O procedimento de coletar, analisar e documentar os requisitos é funda-
mental para o produto final ter a qualidade desejada [1]. Processos em RE podem ser
desenvolvidos de algumas maneiras distintas que, apesar de não haver o modelo de ideal
de fazer o processo, todos esses procedimentos podem resultar em um ótimo modelo de
engenharia de requisitos. São quatro modelos de processos de RE [22]:
1. Modelo de processo de RE linear
Um dos processos mais simples na literatura de engenharia de requisitos e é des-
tinado para projetos pequenos e com pouca escalabilidade. O desenvolvimento é
composto por cinco etapas, conforme apresentado na Figura 2.1.
7
Figura 2.1: Modelo linear [1]
2. Modelo de processo de RE linear iterativo
Este modelo é parecido em questão de etapas com o processo linear, porém, conforme
apresentado na Figura 2.2, determina uma maior precisão nas especificações e na
validação de requisitos, pelo fato de que essa etapa no processo é efetuada até os
stakeholders ficarem satisfeitos [1].
Figura 2.2: Modelo linear Iterativo [1]
3. Modelo de processo de RE iterativo
Este modelo é composto de três fases principais: elicitação, especificação e validação
dos requisitos. De acordo com o apresentado na Figura 2.3, segue um caminho não
linear e retira os requisitos se baseando nos stakeholders e problemas do domínio.
[1].
8
Figura 2.3: Modelo Iterativo não linear [1]
4. Modelo de processo de RE espiral
Modela o processo de RE em uma espiral, em que cada volta na espiral significa
passar por todos os processos envolvidos para os requisitos. A espiral é divida
em quatro quadrantes em que cada um possui uma tarefa na RE, como pode ser
observado na Figura 2.4 [1].
Figura 2.4: Modelo em Espiral [1]
2.1.3 Etapas do Processo em RE
Os modelos de processo em RE tem como principal diferença entre si a ordem e o meio de
execução das fases do processo. Contudo, apresentam etapas semelhantes durante todo
seu processo. No processo de desenvolvimento do sistema, a engenharia de requisitos deve
fazer a elicitação de requisitos com os interessados do projeto, documenta-los de forma
9
correta, validar e verificar se esses requisitos estão em conforme com o projeto como um
todo, além de geri-los por todo o ciclo de vida do sistema [23].
• Elicitação
A elicitação de requisitos é executada pelo conhecimento do contexto do sistema
a partir das diversas fontes de requisitos. Os requisitos podem vir a partir de
três fontes diferentes. Elas são divididas em stakeholders, documentos e algumas
vezes sistemas antigos em operação. Durante essa etapa, uma boa organização e
comunicação com os stakeholders são essenciais para que o processo seja feito de
uma maneira completa e bem feita [23].
• Documentação
Por muitas vezes, o projeto apresenta uma quantidade muito vasta de requisitos,
essa etapa se mantêm importante para que o pessoal envolvido e não envolvido com
o projeto consigam compreender todos os requisitos. Além disso, a localização e
modificação de requisitos conforme o andamento do projeto é muito facilitada [23].
• Validação e verificação
Os requisitos elicitados e documentados precisam sofrer uma validação para que se
garanta que as ideias dos stakeholders estejam sendo respeitadas e se os critérios
de qualidade previamente definidos estão sendo compridos. Com isso, o objetivo da
validação e verificação é descobrir erros nos requisitos documentados. Incompletude,
contradições e ambiguidade são problemas que podem ser encontrados e solucionados
nessa etapa do processo [23]. Apesar de serem similares, a etapa de verificação pode
ser diferenciada com a de validação por meio dessa análise [24]:
– Validação: "Estou fazendo o produto correto?"
– Verificação: "Estou fazendo corretamente o produto?"
• Gerência
Gerenciar os requisitos também é uma das principais etapas e garante a disponibi-
lidade dos requisitos por todo o ciclo de vida do sistema. Essa manutenção ocorre
tanto em requisitos individuais como em uma documentaçãode requisitos completa.
Versionamento, rastreabilidade e designar atributos aos requisitos são algumas das
técnicas utilizadas para gerir-los [23].
10
2.1.4 Técnicas para Realizar a Validação e Verificação de Re-
quisitos
O processo de validação e verificação de requisitos é composto de atividades menores como
revisar, analisar e testar para que se tenha certeza que o sistema desenhado é compatível
com seus requerimentos [24].
Para esses passos serem bem estruturados foram criadas e aprimoradas diversas técni-
cas na literatura que permitem um melhor uso de tempo e recursos pelas pessoas envolvi-
das no sistema. Técnicas de validação de manuais ou documentação de requisitos,também
conhecidas como revisões, são muito utilizadas nesse processo [23]. Elas podem ser clas-
sificadas principalmente por seis tipos de revisões:
1. Revisão de um especialista
Esta técnica se baseia em utilizar os conhecimentos de outra pessoa, um especialista,
para fazer um julgamento a respeito da qualidade dos requisitos. O especialista
revê todos os requisitos e busca por problemas como inconsistência ou ambiguidade.
Quando é encontrado algum problema, o revisor comenta na documentação os erros
e possíveis soluções para consertá-los.
2. Inspeção dos requisitos
Esse método normalmente é constituído de múltiplas fases e pessoas, portanto, é
um processo detalhado e minucioso para verificar presença de erros nos requisitos.
A equipe de uma inspeção é formada de seis funções distintas, sendo elas [23]:
• Organizador: Planeja e controla o processo de inspeção;
• Moderador: Lidera as sessões, mantendo sempre o seguimento da inspeção
conforme combinado nas etapas iniciais;
• Autor: Responsável para explicar os requisitos para os inspetores nas fases ini-
ciais do projeto. O autor é responsável também por corrigir os erros levantados
pelas últimas etapas do processo;
• Leitor: Membro da equipe que guiará os inspetores diante dos diversos re-
quisitos a serem inspecionados. A função dele é tirar a responsabilidade do
inspetor de interpretar o que o autor quis dizer, e eles poderem se concentrar
no requisito em si;
• Inspetores: Responsáveis por detectar as falhas e reporta-las para os outros
membros do projeto;
• Secretário: Responsável por pegar o resultado da sessão e compila-los, além
de preparar a ata para a sessão;
11
A inspeção dentro do contexto de validação de requisitos pode ser dividida nas
etapas de planejamento, visão geral, detecção de falhas e coleta de falhas [23]:
(a) Planejamento: É o começo de tudo, nesta etapa é traçado o objetivo da
inspeção, o desenvolver do processo e as funções de cada participante;
(b) Visão geral: Nesta fase o autor detalha todos os requisitos a sua equipe para
que todos estejam cientes do sistema em questão e possam esclarecer eventuais
dúvidas;
(c) Detecção de falhas: Os requisitos são efetivamente examinados pelos inspe-
tores nesta fase e documentadas para a próxima etapa. A busca de falhas pode
ser feita tanto em equipe quanto individualmente. A busca em grupo possui a
vantagem de comunicação e consequente sinergia entre os inspetores enquanto
a busca individual faz com que todos fiquem focados no trabalho;
(d) Coleta de falhas: A última fase dessa técnica é para a coleta e consolidação
de todas as falhas apresentadas pela etapa de detecção. Nesta etapa é feita
a checagem em todos os erros em busca de erros duplicados ou erros que na
verdade não são erros, mas foram detectados como tal por má interpretação
dos requisitos.
3. Walkthrough
O Walkthrough é uma técnica parecida com a inspeção, porém é uma versão mais
simples e menos rígida [23]. A divisão da equipe é mais simplificada, tendo várias
funções podendo ser desempenhadas pela mesma pessoa. Nessa técnica, são usadas
as funções de pelo menos um revisor, autor, secretário e moderador. Esse método é
feito para identificar falhas nos requisitos e compartilhar o entendimento do projeto
entre as pessoas envolvidas no projeto.
4. Verificação em diferentes perspectivas
Essa técnica faz a validação dos requisitos através uma interpretação do sistema
levando em conta diversas perspectivas distintas [23]. Com diversos pontos de vista
únicos, o foco e resultados obtidos na validação de requisitos tem uma melhora
significativa. As perspectivas normalmente variam de sistema para sistema, mas é
possível ao menos elicitar alguns tipos que ocorrem geralmente em todo projeto e
que podem ser adaptados:
Perspectivas dos stakeholders
12
• Perspectiva do cliente: O cliente ou usuário checa os requisitos a partir de
sua perspectiva e verifica se condiz com a realidade e qualidade esperadas;
• Perspectiva do desenvolvedor: O desenvolvedor verifica se os requisitos
contêm todas as informações e propriedades necessárias para que o projeto
consiga ser feito;
• Perspectiva de teste: O testador verifica se com os requisitos presentes é
possível fazer casos de teste que satisfazem todo o projeto.
Perspectivas de qualidade do sistema
• Perspectiva de documentação: Nessa perspectiva é assegurado que a do-
cumentação envolvendo os requisitos atenda todas os critérios anteriormente
discutidos;
• Perspectiva de conteúdo: Perspectiva que trata do conteúdo dos requisitos
em si, e foca na qualidade desse conteúdo;
• Perspectiva de acordo: Nesta perspectiva, o foco é assegurar que todos os
envolvidos no projeto estejam de acordo com os requisitos levantados e se não
há nenhum conflito a ser solucionado.
A técnica de validação usando diferentes perspectivas pode ser usada independente-
mente ou em conjunto com alguma outra técnica de revisão vista anteriormente. É
importante, nesta técnica, detalhar o que será abordado em cada perspectiva para
que todos estejam entendendo o que irá ser focado em cada uma visão, para que
não haja retrabalho posteriormente.
5. Validação por prototipagem
Protótipo é um modelo preliminar de um sistema completo. Com isso, o que essa
técnica faz é usar esse modelo a favor da validação de requisitos. A partir de um
protótipo do projeto, requisitos podem ser testados e validados de forma prática
pelos stakeholders e é verificado se atendem ao objetivo originalmente traçado. Os
protótipos podem ser divididos dependendo da destinação deles em protótipos des-
cartáveis ou protótipos evolutivos [23]. Os descartáveis servem somente para o teste
atual e não irá ser colocado em produção novamente, já o evolutivo é um protótipo
que fica em constante evolução conforme o projeto se desenvolve e, por isso, requer
um maior trabalho para ser feito. Para que um protótipo seja feito, é preciso fazer a
seleção dos requisitos que ele ira contemplar. Esse conjunto normalmente não cobre
todos os requisitos documentos já que traria custos e complexidades muito elevados.
13
Por isso, é preciso fazer um critério de seleção entre os requisitos e determinar quais
são os mais adequados a serem utilizados no protótipo.
Junto com o protótipo em si, são necessários mais três documentos para que seja
feita a validação dos requisitos [23], sendo:
• Um manual para os integrantes que vão utilizar o protótipo que conste todas
as informações de uso e aplicação;
• Um documento que conste vários cenários para a validação dos requisitos e uma
lista de verificações com todas os requisitos que estão querendo ser validados.
Cenários que não constam nos documentos podem e devem ser testados depois
de todo o processo para que se verifique o sistema em diversas situações e
circunstâncias que não foram planejadas de início.
Após a finalização da validação, os resultados são compilados e discutidos. Altera-
ção, remoção ou adição de requisitos são consequências durante essa etapa. Se as
alterações forem muito grandes ou impactantes, é aconselhável a remodelação do
protótipo para que abrange essas mudanças e seja possível de ser feito uma nova
validação [23].
6. Validação por checklist
A técnica de checklist é utilizada em projetos complexos e quando o sistema possui
diversas questões que precisam ser levados em conta. As checklists podem seruti-
lizadas em conjunto com diversas outras técnicas e ela é composta de perguntas ou
afirmações para identificar os erros contidos nos requisitos. A fonte para a monta-
gem da checklist pode vir tanto dos stakeholders quanto de critérios de qualidade
de requisitos que a literatura dispõe. A lista pode sempre estar sendo atualizada
conforme o projeto avança e novas funcionalidades e requisitos surgem, por isso,
remoção de perguntas ambíguas, edição e adição de informações são sempre bem
vindas conforme o projeto vai se desenvolvendo. O sucesso da técnica vai depender
da extensão e complexidade da checklist. Uma lista muito longa e cheia de detalhes
pode fazer o processo ficar mais lento e inviável para o auditor. A mesma coisa pode
acontecer se a lista for muito subjetiva, tornando o processo de validação lento e
suscetível a falhas.
2.1.5 Aplicações da IoT
De desktops a smartphones, todos os dispositivos eletrônicos com capacidade de enviar ou
receber dados através da Internet ou outros meios de conexão, proporciona a indústria e
ao consumidor uma melhor automação em processos, redução de custos e maior controle
14
sobre dispositivos, todos estes atrelados a IoT. Todos os recursos com uma variedade
de sensores embutidos permitem diversas aplicações em potencial [25]. Neste quesito,
Lacerda [26] destaca cinco utilidades para a IoT.
A Internet das Coisas evoluiu de maneira significativa neste aspecto graças a capa-
cidade dos dispositivos interligados em realizar um monitoramento efetivo de atividades
físicas e condições de saúde do usuário [25]. Dispositivos vestíveis como smartwatch (reló-
gio com funções e monitoramento integrado a um smartphone) são recomendados para o
monitoramento de atividades físicas, bem como pode ser utilizado para monitorar doenças
crônicas, como por exemplo o mal de Parkinson [27].
Para Souza [8], este monitoramento dos pacientes através da IoT torna mais rápido
o processo de diagnóstico, de identificação e da análise das condições de saúde do pa-
ciente. Além destes, dispositivos IoT ligados a área de saúde também podem coletar
dados e rastrear os locais onde a pessoa frequentou, embora este assunto afete questões
de privacidade previstas por legislações de cada país [25].
Santos et al. [12] definiu esta categoria da IoT como Smart Home (casas inteligentes)
devido ao fato dos dispositivos interligados poderem controlar, por si mesmos ou por ação
humana, todos os equipamentos elétricos e eletrônicos dentro da residência do usuário.
Em casas e apartamentos, a IoT se mostra bastante eficiente em vários aspectos. Para
Milenkovic [25], a Internet das Coisas dentro de um ambiente residencial pode propor-
cionar: 1. Conforto: controle de luz, de temperatura ou ligar/desligar dispositivos; 2.
Segurança: abrir/fechar portões a uma certa distância ou avisar sobre janelas e portas
abertas; 3. Redução de custos: desligamento automático de luzes e equipamentos que não
estão sendo utilizados por um tempo determinado.
Milenkovic [25] destacou que os recursos propostos na IoT no conceito das smartci-
ties (cidades inteligentes) necessita de uma ampla rede de conexão capaz de transmitir
dados para controle, gerar estatísticas e propor maior segurança a sua população, como
antecipação às previsões do clima em um determinado dia. Apesar deste crescimento ser
promissor, estas tecnologias ligadas a IoT ainda dividem espaço com dispositivos ana-
lógicos, que embora não seja recomendável, conseguem atender as necessidades de cada
usuário de um produto ou serviço [26].
2.2 Processos de Engenharia de Requisitos no Con-
texto de IoT
A evolução significativa da Internet das Coisas e sua complexidade se tornou um desafio
para a área de Engenharia de Requisitos, principalmente para a indústria 4.0 cujo en-
foque é o uso de biotecnologia, energias renováveis e nanotecnologia [11]. Para Lim et
15
al. [28], atualmente, existem estudos e aplicações voltadas ao uso da IoT como recurso
para validação de requisitos, possuindo como características individuais as vantagens e
desvantagens.
Os processos encontrados por meio da pesquisa exploratória foram evidenciados nas
subseções abaixo e intituladas com o nome do artigo publicado que contem o processo ou
o nome que os autores deram ao processo.
2.2.1 A Requirements Engineering Process for IoT Systems
Devido a falta de procedimentos sistemáticos a respeito de RE em IoT, Silva et al. [2]
descreveu um processo voltado para o desenvolvimento de sistemas em Internet das coisas
utilizando Notação para Modelagem de Processos de Negócio (BPMN). O processo é
composto por três sub-processos, em que cada um é feito de acordo com a ISO/IEC/IEEE
122071, ou seja, a norma que define processos em engenharia de software. Cada sub-
processo e o processo em si possui entradas e saídas:
Figura 2.5: Modelo de processo em RE voltado a IoT [2].
1. Definição do escopo do projeto:
Como primeiro sub-processo, descrito na Figura 2.6, a definição do escopo desem-
penha o papel importante de determinar o esquemático do projeto. O sub-processo
determina primeiramente qual é o problema e o que o sistema irá abranger. Em
seguida, determina quais são os stakeholders em potencial e, por consequência, quais
são suas vontades e desejos a respeito do projeto a ser feito. Com todas essas in-
formações agrupadas, é feita uma análise a respeito da viabilidade do sistema, se é
possível fazer o sistema e se ele está de acordo com o plano. No passo seguinte, as
necessidades dos stakeholders são transformadas em requisitos para o projeto. Esse
processo inclui todas a identificação,controle de qualidade e análise dos requisitos.
Por fim, o projeto precisa passar pela aprovação explícita de todos os envolvidos.
1https://www.iso.org/standard/63712.html
16
https://www.iso.org/standard/63712.html
Este sub-processo tem como objetivo final que as necessidades dos stakeholders se-
jam transformadas em requisitos e que todas as pessoas envolvidas estejam cientes
deles.
Figura 2.6: Sub-processo 1: Definição de escopo [2].
2. Definição do sistema IoT:
Na segunda parte do processo, o aspecto IoT do projeto é levado muito em consi-
deração em seu desenvolvimento. Seguindo o fluxograma proposto na Figura 2.7, o
propósito dessa etapa é definir os cenários IoT, identificar os componentes presentes
no sistema e identificar diversas soluções para que se possa escolher uma preferida.
Esse sub-processo determina começa propondo uma solução em IoT para o sistema,
se baseando nos requisitos dos stakeholders e do detalhamento do projeto,todos eles
feitos no sub-processo anterior. Logo , se constrói cenários IoT em alto nível, nor-
malmente em forma de narrativa ou esquemas, para o fácil entendimento de todas
as pessoas envolvidas no projeto.
Com o cenário definido, são feitas a identificação dos componentes do sistema IoT
e suas ações. Dispositivos, sensores e outros são identificados e descritos de acordo
com o cenário proposto e quais são suas ações dentro do sistema. Dessa etapa podem
surgir diversos arranjos diferentes de componentes e ações diferentes, por isso cabe
a equipe se reunir e decidir se as soluções encontradas atendem ao projeto e qual
delas escolher para serem as mais viáveis.
No final desse sub-processo os cenários IoT devem estar definidos e os componentes
e ações do sistema IoT identificados. É preciso apresentar diversas composições
para o sistema IoT além daqueles que são os mais propensos a se desenvolverem
para realmente serem implementados.
3. Definição de requisitos para o sistema IoT:
Última etapa do processo, e tem como objetivo a especificação dos componentes
IoT e verificar toda a especificação do projeto. No final desta etapa, os componen-
tes precisam estar especificados e verificados, casos de uso precisam estar criados
17
Figura 2.7: Sub-processo 2: Definição do sistema IoT [2].
e verificados. Além do vinculo dos requisitos dos stakeholders com o sistema IoT.
O sub-processo inicia uma especificação dos componentes a fim de criar uma do-
cumentaçãodetalhada sobre os dispositivos que compõem o sistema IoT. Logo em
seguida a validação dessa especificação para que não haja nenhuma inconformidade.
Com isso, é feito a especificação e a verificação dos componentes de software para
que seja possível o desenvolvimento do projeto de acordo com o planejado.
Tendo por concluído a especificação e a verificação, são feitos e verificados os casos de
uso se baseando em cada cenário criado em etapas anteriores. Estes casos abrangem
o uso dos componentes, as exceções que podem ocorrer no software. Os casos de
uso também devem abranger as regras de negócio que o sistema irá conter. Por fim,
é feito um acompanhamento para saber se todos os desejos dos stakeholders foram
atendidos nos requisitos e nas documentações. Além de verificar se os requisitos
do sistema IoT atendem aos requisitos dos stakeholders. No final do processo,
todos os componentes de software e de dispositivos devem estar especificados e
verificados,casos de uso devem ter sido feitos e o acompanhamento de requisitos IoT
e dos stakeholders deverão ter sido desempenhados.
Figura 2.8: Sub-processo 3: Definição dos requisitos para o sistema IoT [2].
2.2.2 A UML-based Proposal for IoT System Requirements Spe-
cification
Tendo como motivo a falta de processos da engenharia de requisitos voltada para IoT,
Reggio [15] apresentou o IoTReq, um processo para elicitação e especificação de requisitos
em sistemas IoT. O processo tem como diferencial sua construção em UML para toda a
construção do modelo. O IotReq primeiramente faz a modelagem em que o sistema
IoT será inserido, tendo o seu domínio extenso e possuindo várias entidades e interações
18
entre elas. Ele é feito seguindo um paradigma orientado a serviços, e usando diagramas
UML. Depois dessa fase inicial, o processo faz a descrição de diversos tipos de objetivos
que o sistema tera como projeto. Esses objetivos são propriedades ou requisitos que os
stakeholders anunciaram que o sistema deveria abranger, podendo ser divididos em:
1. Objetivos estratégicos: Primeiro requisito elicitado pelos stakeholders, normal-
mente são requisitos de alto nível e normalmente são as razões básicas que o projeto
está sendo feito. Por isso, muitas vezes são genéricos/subjetivos e deles são criados
outros requisitos;
2. Objetivos operacionais: Requisitos feitos a partir dos objetivos estratégicos, esses
objetivos são propriedades e funções que o sistema IoT apresentará. Eles represen-
tam os requisitos funcionais do projeto, são essenciais para uma boa elicitação dos
requisitos;
3. Objetivos tecnológicos: São os requisitos não funcionais do projeto, esses obje-
tivos entram no detalhe da implementação e citam quais e como certas tecnologias
serão usadas. São derivados dos objetivos operacionais e eles serão os requisitos de
mais baixo nível levantados.
Ao final, o IotReq é feito a partir de três passos, a construção de um modelo para o
domínio IoT, um esquemático para a visualização dos objetivos/relações do sistema e, por
último, a especificação desses objetivos a partir de um diagrama UML. Esse processo foi
colocado em prática com um caso de estudo realístico e conseguiu especificar os requisitos
de forma precisa e com até certa facilidade de leitura [15].
2.2.3 TrUStAPIS: A Trust Requirements Elicitation Method for
IoT
TruUStAPIS [29] é um método para elicitação de requisitos para um cenário IoT. Este
método é feito a partir da criação de domínios e dividi-los em sete tipos diferentes (usa-
bilidade, identidade, segurança, disponibilidade, privacidade, proteção e confiabilidade).
Considerando a necessidade de haver confiança entre as entidades que atuam com IoT, o
método proposto pelos autores é composto pelos seguintes elementos para a elicitação do
requisito:
1. Ator: Humano ou entidade IoT que realiza o objetivo descrito;
2. Ação: Atividade que o Ator desempenha no sistema;
3. Objetivo: Objetivo que o requisito quer alcançar no sistema;
19
4. Contexto: Faz parte do domínio do requisito, envolve as circunstancias do projeto
e os objetivos do requisito.
Para a documentação, os autores propuseram o uso de um JSON como template,
tanto por ser suportável em várias linguagens como por ser uma linguagem fácil de ser
entendida tanto por computadores como por humanos. Esse tipo de organização também
é defendida pelos autores por ter capacidade de alta rastreabilidade entre seus requisitos,
sendo possível ter um controle sobre as versões dos requisitos. Além disto, é adotado os
diagramas UML para auxiliar nas fases de elicitação e especificação de requisitos em IoT.
O TrUStAPIS é dividido em quatro etapas [29]. Na primeira etapa foi expandido o
sistema IoT para um esquemático envolvendo as entidades. Essa etapa torna mais simples
a elicitação dos requisitos por facilitar a interpretação do sistema e das necessidades do
stakeholders. A segunda parte já é a composição dos parâmetros nos JSONs baseando-
se no modelo construído na fase anterior. A terceira parte é destinada a documentação
escrita dos requisitos levantados pelo JSONs em tabelas, essa etapa tem como saída os
próprios requisitos elicitados. A quarta e última etapa é manter a rastreabilidade dos
requisitos, construindo-se novas tabelas para a associação de requisitos.
2.2.4 REM4DSPL: A Requirements Engineering Method for
Dynamic Software Product Lines
O Método para Engenharia de Requisitos para Linhas de Produtos de Software Dinâmicos
(REM4DSPL), criado por Sousa et al. [30], tem a finalidade de organizar um produto de
software com o intuito de ser adaptativos às necessidades existentes em uma companhia,
definido pelo Linha de Produto de Software Dinâmico (DSPL). O REM4DSPL é um
método para a engenharia de requisitos voltada a produtos Linha de Produto de Software
Dinâmico (DSPL). DSPL são linhas de produtos que possuem sensibilidade ao contexto
que estão inseridos e precisam estar sempre se adaptando em tempo de execução para que
suas finalidades possam ser feitas.
Sistemas IoT entram nessa categoria pois sempre são influenciadas pelo contexto pre-
sente no sistema, além da alta capacidade de adaptação necessária para poder executar
corretamente as constantes mudanças. Tendo isso em mente o Método para Engenharia
de Requisitos para Linhas de Produtos de Software Dinâmicos (REM4DSPL) pode ser um
método utilizado em IoT, onde seu processo utiliza BPMN [30]. Esse método é composto
de três fases no seu processo.
1. Elicitação dos requisitos: Colhe as características dos requisitos e identifica o
contexto e as características que o sistema e o contexto em que ele está inserido
20
deve conter. O método propõe utilizar cenários e técnicas narrativas envolvendo o
usuário e o sistema para detecta-los;
2. Especificação dos requisitos: Com base no que fora realizado na etapa anterior e
utilizando uma documentação dos cenários levantados, é realizada uma identificação
das regras de negócio e especificar as características de um Linha de Produto de
Software Dinâmico (DSPL). Sendo a etapa mais complexa deste processo, é dividido
em objetivos, sendo eles:
• Especificar os requisitos; Identificar o modelo de negócio do sistema;
• Especificar as funcionalidades do produto;
• Associar as funcionalidades com os requisitos;
• Identificar e especificar o contexto e suas características;
• Identificar as variações do contexto e modela-las.
3. Gerenciamento da mutabilidade do sistema: Como etapa final, esta fase tem
como objetivo de modelar todas as características da Linha de Produto de Software
Dinâmico (DSPL) que serão implementadas e fazer a gerencia da mutabilidade e
relação entre características e requisitos. Além disso, esta etapa faz uma verificação
nos modelos criados em busca de inconsistências presentes.
2.2.5 Modeling IoT Aplications with SysML4IoT
Costa et al. [31] propuseram uma metodologia para o desenvolvimento inicial das aplica-
ções IoT, desde a especificação dos requisitos a montagem de esquemáticos. Esse método
é baseado em diagramas UML e foca na resolução de três problemascruciais na fase de
design de um sistema IoT, como a diversidade de componentes de hardware e software
disponíveis para IoT, bem como a escassez de técnicas para a elicitação de requisitos
e seu posterior planejamento por cenários. Como resolução ao primeiro problema, o
SysML4IoT, usa um modelo que abstrai o sistema para especificar claramente os diversos
componentes e softwares que um sistema IoT apresenta, facilitando assim o entendimento
como um todo. Neste modelo o sistema é composto por dispositivos e serviços interagindo
com outros sistemas ou usuários.
Para esclarecer melhor as necessidades dos stakeholders, Costa et al. [31] usaram
tabelas para a separação dos stakeholders por habilidades e responsabilidades. Com
isso, foi criado um outro modelo contendo vários pontos de vista diferentes a respeito da
aplicação: visão funcional, de informação, operacional e outros, são citados como possíveis
entradas para essa modelagem. Por último, o método IoT DevProcess foi proposto para
21
resolver o caso do terceiro problema, a falta de métodos de design das aplicações. Esse
método utiliza da SO/IEC/IEEE 15288:2015 e da OOSEM (Object-Oriented SE Method)
para a criação de um método para aplicações IoT em desenvolvimento.
O IoT DevProcess inicia por meio da análise dos requisitos do sistema. Os requisitos
dos dispositivos são especificados, incluindo protocolos e formatos dos dados. Após essa
etapa, é feita a modelagem das entidades, são especificados os dispositivos, serviços e
recursos que o sistema terá quando estiver pronto. Nessa etapa também é criado um
modelo para o formato dos dados que os serviços dentro do sistema irá conter. O próximo
passo do método é decompor o sistema em diversos componentes que interagem entre
si baseados nos requisitos levantados, e com esses componentes criar modelos para a
visualização tanto em alto nível como com mais detalhes da composição.
2.2.6 Specifying Functional Requirements and QoS Parameters
for IoT Systems
Costa et al. [32] descreveram sobre a não trivialidade de fazer uma especificação de requi-
sitos em projetos IoT e propuseram um método para ajudar na especificação de requisitos
em sistemas IoT. O processo é chamado de Linguagem de Modelagem de Requisitos em
IoT (IoT-RML) e tem como objetivo especificar e modelar requisitos de diversos stakehol-
ders de maneira precisa e resolver os conflitos que diversos requisitos possam possuir. O
IoT-RML especifica tanto requisitos funcionais como não funcionais (Quality of Service) e
utiliza a linguagem SysML para representar os modelos utilizados no processo, com base
em diagramas UML.
O processo tem como base um modelo do domínio dos requisitos gerado quando re-
quisitos são elicitados pelos stakeholders e modelados conforme estrutura contida [32].
Nele são descritos os conflitos entre requisitos, a sua categoria e suas características. Re-
quisitos não funcionais são tratados como parâmetros QoS e considerados diferentemente
conforme a camada da arquitetura do sistema. Vale destacar que o artigo descreve os
conflitos de requisitos como de quatro tipos distintos, são eles:
1. Oposto: Conflito causado quando requisitos fazem ações opostas um do outro;
2. Numérico: Conflito em relação a unidade de medida entre um requisito e outro;
3. Duração: Aplicações requisitando o mesmo recurso mas com quantidade de tempo
de uso diferente;
4. Completude: Uma aplicação não conseguir efetuar algum requisito por causa do
uso do recurso por outra aplicação
22
Com os requisitos sendo abstraídos pelo modelo do domínio e baseado na SysML, é
criado o IoT-RML SysML Profile, que efetua todo o gerenciamento de múltiplos stakehol-
ders e conflitos entre requisitos. A partir dessas duas ferramentas, o processo entra na
etapa de resolver os conflitos e o desenvolvimento propriamente do sistema IoT proposto.
2.2.7 Design Science and ThinkLets as an Holistic Approach to
Design IoT/IoS Systems
O processo criado por Bernsteiner e Schlögl [33] utilizou dois parâmetros para a elabora-
ção de um design de sistema IoT: o Design Science e a ferramenta ThinkLets. O primeiro
parâmetro, o Design Science, é oriunda do termo Design Science Research (DSR), tendo
consigo um papel fundamental para a resolução de problemas, criando artefatos que pos-
sam atender as necessidades e aos problemas de uma companhia [34].
Apiola e Sutinen [35] destacaram a imponência do DSR em relação a outros projetos
de desenvolvimento de software, pela capacidade do DSR em utilizar um amplo e absoluto
repertório de metodologias de pesquisa ao longo das fases do processo. Ainda, para os
autores, estes processos são divididos em fases de explicação do problema, definição dos
requisitos (funcionalidades e permissões), design, desenvolvimento e validação.
Segundo Bernsteiner e Schlögl [33], é importante destacar alguns fatores que influen-
ciam o processo:
1. Construtores: Utilizados para definir um contexto geral sobre requisitos, proble-
mas de domínio e realização de artefatos;
2. Modelos: Cria uma relação entre os construtores a fim de compartilhar informações
em comum e, consequentemente, realizar configurações específicas para solução de
problemas;
3. Métodos: Ferramentas que podem ser utilizadas para verificar se os construtores
e modelos estão de acordo com o projeto de software, como exemplo, o uso de
diagramas UML.
Hevner [3] destacou as três fases que envolvem a DSR, descritas na Tabela 2.1. O
autor pondera a existência de pontes que interligam estas fases. Por exemplo, existe um
Ciclo de Relevância - que prevalece entre as fases de Meio ambiente e DSR - e possui
a responsabilidade de realizar testes de campo; o Ciclo de Design, que executa em loop
apenas dentro do contexto da DSR; por fim, o Rigor do Ciclo, atuando entre a Base de
conhecimento e o DSR na troca de informações.
ThinkLets, por outro lado, é definida como um padrão de construção genérica de
blocos capaz de atender as especificações do projeto. O seu desenvolvimento se baseia nos
23
Fases Propriedades
Ambiente do contexto
Aplicação de Domínio:
•Pessoas
•Sistemas de uma organização
•Sistemas técnicos
•Problemas e Oportunidades
Construção de um artefato de design e processosDSR Avaliação
Base de Conhecimento
Fundamentos:
•Teorias científicas
•Métodos científicos
•Experiência
•Produtos e processos do design
Tabela 2.1: Três fases do processo envolvendo a DSR [3].
processos colaborativos, designando padrões genéricos de colaboração, que deixa claro as
atividades para cada membro do projeto [33]. Consistindo de cinco fases, Kolfschoten e
de Vreede [36] descreveram a visão geral sobre o ThinkLets na Figura 2.9. Cada item
pode enviar e receber dados através das interações, as quais são:
• Diagnóstico da tarefa: através de uma conversa com os stakeholders, é discutido
questões relevantes em relação a requisitos. Para a equipe de RE, os requisitos
apresentados podem ser ajustados, negociados ou questionados;
• Decomposição da atividade: nesta fase, as atividades são divididas entre o grupo de
desenvolvimento através do ThinkLets, onde todos devem possuir uma visão ampla
do produto de software;
• Escolha da tarefa ThinkLets: após a conclusão da decomposição, o ThinkLets atua
como responsável por atribuir as atividades separadas na fase de decomposição, fase
esta que pode ser delicada;
• Construção de agenda: uma vez concluídas, as fases anteriores servem como parâ-
metro para esclarecer questionamentos, definições, objetivos, tempo que será gasto
e estimativas;
• Validação do design: na última fase do processo, todos os requisitos propostos nas
etapas anteriores são validados. Também é verificado questões acerca dos custos,
tempo gasto e outras informações complementares;
• Satisfeita as cinco etapas deste processo colaborativo, uma documentação é elabo-
rada.
24
Figura 2.9: Visão geral sobre o funcionamento da ferramenta ThinkLets [3].
Levando em consideração os dois conceitos sobre DSR e ThinkLets vistos nesta seção,
estas questões servem como base para a elaboração deuma ferramenta de design para
IoT. Utilizando a técnica de brainstorming - chamada por Bernsteiner e Schlögl [33] como
DirectedBrainstorming (Brainstorming Dirigido) - com o auxílio da ferramenta ThinkLets,
utiliza cinco parâmetros seguindo os padrões colaborativos, os quais são:
1. Distribuição de papéis: consiste nos participantes do projeto realizarem um caso
de uso em folha de papel, entregar a um moderador e, caso necessário, pode ser
elaborado mais cenários;
2. Análise dos papéis: nesta fase, através de uma discussão e da ferramenta FastFocus
(foco rápido) presente no ThinkLets, os participantes podem expressar uma visão
geral dos casos de uso feitos na fase anterior, definindo portanto um caso de uso que
não prejudique as fases seguintes;
3. Organização dos conceitos: por meio da ferramenta ThinkLet PopCornSort, tem
o intuito de estabelecer relações e dependências nos casos de uso, feito por fases
anteriores;
4. Descrição e desenvolvimento: ainda permanecendo nos termos de definição da fase
anterior, nesta etapa os casos de uso passam por uma descrição acerca dos termos
existentes na IoT - como sensoriamento, identificação e atuação - bem como meio
de comunicação, interface de usuário e outros;
25
5. Avaliação: nesta última fase, os casos de uso trabalhados ao longo do processo de
brainstorming passam por uma validação, que tem o objetivo de analisar as funções,
situações que podem ser relevantes e eventuais falhas que podem ocorrer. Esta etapa
conta com a ajuda da ferramenta BucketWalk.
Uma vez concluído as cinco etapas e atingido os objetivos em comum de cada fase
(isto é, a conclusão de um caso de uso), é utilizado ainda no processo de avaliação uma
ferramenta denominada StrawPoll, que permite a cada participante votar nos casos de
uso que forem mais relevantes ao processo. Finalizando esta questão, todo o processo é
dado como encerrado [33].
2.2.8 An Improved RE Framework for IoT-Oriented Smart Ap-
plications using Integrated Approach
Kaleem et al. [37] apresentaram um estudo para a criação de uma ferramenta de aborda-
gem integrada utilizando o conceito de smartness (inteligência) - voltada para a Internet
das Coisas - com base nos processos e técnicas de validação existentes na Engenharia de
Requisitos. Os autores destacam a utilização de frameworks para definir os processos
nesta proposta [37], adotando o uso de diagramas UML. Seu primeiro processo destaca o
ponto de partida para o estudo dos processos, seguindo uma metodologia similar à pro-
posta do processo linear elaborada por Rehman et al. [1], com foco em satisfazer as cinco
etapas:.
1. Identificação dos Stakeholders: nesta etapa, as partes interessadas entram em
uma conversa para debater o propósito do sistema, suas funcionalidades, permissões,
bem como a definição de responsabilidades acerca das áreas da Engenharia de Soft-
ware. Esta fase do processo é baseada no método Goal-Question-Metric, conceito
criado pela Universidade de Maryland para unir objetivos, questões operacionais e
métricas [38];
2. Elicitação de Requisitos: fase responsável por colher as necessidades dos sta-
keholders utilizando fatores socio-técnicos para mesclar fatores humanos, organiza-
cionais e aspectos técnicos do sistema [39];
3. Análise de Requisitos: ocorre a checagem de todas as necessidades descritas
pelos stakeholders com auxílio do Design Baseado em Modelo (MBD), ferramenta
primordial para a análise, também incluindo aspectos de verificação e validação dos
requisitos [40];
26
4. Especificação dos Requisitos: nesta fase, um workshop interativo se mostra pre-
sente dentro do framework da Engenharia de Requisitos para documentar, através
da Especificação de Requisitos de Software (SRS), todos os processos e requisitos
voltados a smartness envolvendo a IoT [37];
5. Métodos: ferramentas que podem ser utilizadas para verificar se os construtores
e modelos estão de acordo com o projeto de software, como exemplo, o uso de
diagramas UML. na última fase deste processo principal, é utilizado técnicas para
design de casos de teste - podendo ser um template ou um protótipo - para validação
e verificação do produto de software, envolvendo os stakeholders e a equipe de
desenvolvimento. Caso receba um feedback positivo, este processo é declarado como
encerrado.
2.2.9 Detecting IoT Applications Opportunities and Require-
ments Elicitation: A Design Thinking Based Approach
Dantas et al. [41] descreveram um processo de RE para IoT por meio da abordagem
Design Thinking. Este processo tenta entender os objetivos dos usuários e stakeholders
enquanto detecta os desafios e propõe soluções que não estavam sendo pensadas a primeira
vista. O processo de Design Thinking descrito pelos autores [41] é iterativo, não linear e
consta com cinco etapas principais, divididas em:
• Compreensão: Fase inicial e crucial para o sucesso no processo, nesta fase é feita a
compreensão do ponto de vista dos stakeholders. São citadas técnicas como bodys-
torming e entrevistas;
• Definição: Define qual será as características que o design do sistema terá como
foco. A Interaction Design Foundation é uma abordagem centralizada no ser hu-
mano, ampla para a criatividade e focada para que seja possível de ser concretizada;
• Idealização: Fase para se pensar em outras ideias além da qual já foi arquitetada.
Essa etapa visa ampliar a visão do time para soluções inovadoras;
• Prototipação: Criação de protótipos de alta e baixa fidelidade para que se possa
validar as ideias levantadas e adquirir mais feedbacks dos stakeholders;
• Testagem: Agrupamento dos feedbacks dos stakeholders e dos protótipos criados
ao longo do desenvolvimento do sistema. A equipe pode analisa-los e deles surgirem
uma nova ideia.
Dantas et al. [41] utilizaram três técnicas:
27
• How Might We Questions (HMW): Técnica de brainstorming que se baseia em
perguntas de "Como pode ser feito?". Os times do projeto se reúnem para analisar
os fatos e requisitos já conhecidos junto com as diversas perspectivas que cada time
deve ter a respeito do projeto. Rescrever todos essas informações em perguntas
HMW e verificar se com elas dá para se fazer outras soluções a partir de uma sessão
de brainstorming;
• Jornada do usuário: Técnica utilizada para documentar o comportamento do
usuário utilizando o produto. Cada passo que o usuário fizer no sistema é docu-
mentado, assim como o pensamento e sentimento do usuário a respeito do uso da
plataforma. Essa técnica constrói uma perspectiva do usuário e pode ser essencial
para a descoberta de algum problema ou inconsistência;
• Diagrama de afinidade: Agrupamento por setores de dados e resultados obti-
dos anteriormente a partir de um critério antes definido. Essa técnica facilita a
organização e a fluidez das ideias conforme o projeto é desenvolvido.
Dantas et al. [41] descreveram algumas ferramentas feitas para IoT que podem ser
utilizadas para o entendimento dos requisitos do sistema IoT e aplicação das técnicas
mencionadas, são elas:
• IoT Design Deck: Utilizado para fazer a integração de times para a produção de
um sistema IoT. Utiliza um deck de cartas para ajudar os times a utilizarem uma
linguagem em comum e focar na experiencia do usuário. Por meio de várias técnicas
e ferramentas, esse método garante a comunicação e entendimento do projeto IoT
que normalmente contém uma grande multidisciplinaridade;
• Tiles IoT ToolKit: Projeto em open source também baseado em cartas para
ajudar na elaboração de ideias, storyboards e explorar o cenário IoT por completo;
• IoT Service Kit: Ferramenta para IoT que baseia-se em cartões, onde existe
a interação com o design e tokens para esquematizar interações de entidades no
projeto.
2.2.10 An Evidence-Based Framework for Supporting the Engi-
neering of IoT Software Systems Mid-stage Research
Motta [42] propôs um framework composto por três etapas, a fim de evitar soluções
limitadas (considerando a coleta e processamento de dados), deixando lacunas em aberto
no quesito de validação dos requisitos em Internet das Coisas,bem como visa reforçar a
28
qualidade de desenvolvimento baseando-se nos estudos de viabilidade do projeto. Com
base na metodologia O que, Como, Quem, Quando e Por quê (5W1H), Motta apresentou
um framework composto por três fases, cada uma destas possuindo sub-rotinas.
1. Concepção: nesta etapa, é feita uma análise detalhada sobre os requisitos solici-
tados para um dispositivo IoT.
(a) Caracterização: primeira etapa do processo, é consultado na literatura as téc-
nicas existentes, com suas definições, aplicações e características, a fim de
encontrar possíveis inconsistências;
(b) Preocupações: nesta etapa, é vista as questões legais e sociais que podem
afetar um projeto em Internet das Coisas de forma negativa, como invasão
a privacidade ou coleta de dados sem a devida precaução na segurança dos
mesmos;
(c) Investigação de facetas: visa a revisão de questões que podem envolver a IoT,
como áreas de conhecimento e tópicos, etapa esta que pode ter um contexto
amplo;
(d) Proposta de um framework: com base nos dados colhidos nas etapas anterio-
res, é construído um Conjunto de Conhecimentos em IoT (BoK), baseando-se
em questões como coisas, inteligência, interatividade, meio ambiente, conecti-
vidade e comportamento, aliando um panorama dos stakeholders com desafios
e questionamentos.
2. Desenvolvimento: nesta etapa, é colocado em prática os conceitos vistos anteri-
ormente. Existem três etapas:
(a) Construção da base de conhecimento: fundamentado na criação da BoK na fase
de constituição do framework, uma segunda revisão literária se torna necessária
para analisar aspectos técnicos;
(b) Definição do projeto: nesta fase, é vista as caracterizações dos artefatos vistos
ao longo do projeto e do BoK;
(c) Definição de orientações de engenharia: nesta fase, os desenvolvedores podem
fazer algumas pontuações sobre o projeto, tais como definições, recursos e
outras questões.
3. Avaliação: na última fase do projeto, a autora destaca dois tópicos cujo estudo é
necessário para a aprovação final do projeto.
29
(a) Viabilidade: é feito um estudo para verificar se a estrutura realizada corres-
ponde aos anseios propostos na etapa de concepção do processo e se a cons-
trução do mesmo é realizável. Em consonância, pode ser agregado também a
opinião da equipe de desenvolvimento. Todas estas variáveis podem colaborar
para uma melhoria do framework.
(b) Observações: sendo a última etapa, é visto a possibilidade do projeto em si pos-
suir uma interpretação prática coerente com sua revisão teórica, questão esta
que depende da aplicação do recurso IoT (por exemplo, automação residencial
ou mobilidade urbana).
2.2.11 Non Functional Requirement Analysis in IoT based smart
traffic management system
Mahalank et al. [43] levantaram a importância do estudo e entendimento dos requisitos
não funcionais para o desenvolvimento de um sistema de software em IoT. Uma detecção
no início do processo de desenvolvimento desses requisitos levam o desenvolvimento do
sistema a ter um melhor gerenciamento de suas limitações já no começo do seu desenvol-
vimento, evitando assim um retrabalho no final do projeto. Os autores afirmaram que o
conceito de requisitos não funcionais não é muito bem definido entre os desenvolvedores
de software. Por isso, descreveram um método para analisar e especificar os requisitos não
funcionais para sistemas IoT. O método conta com três características em que os requisi-
tos não funcionais deverão ser analisados: performance, capacidade de armazenamento e
limitações para manutenção.
Mahalank et al. [43] utilizaram um sistema de tráfego inteligente como exemplo para
seu método, e para isso, cada elemento do sistema IoT a ser desenvolvido é analisado e
descrito a partir dessas características principais. Com essa análise, o nível de funciona-
mento do sistema IoT é identificado e descrito. O desenvolvimento dessas três caracte-
rísticas principais ainda pode se desdobrar em outras características menores conforme a
necessidade do projeto.
Por fim, o método proposto pelos autores [43] resumem a análise dos requisitos não
funcionais em três templates e uma checklist em que contém as informações necessárias
sobre o requisito especificado.
30
2.2.12 Horizontal Requirement Engineering in Integration of
Multiple IoT Use Cases of City Platform as a Service
Yamakami [44] descreveu a falta de metodologias para o design de sistemas IoT e propôs
um framework para ajudar a unir diferentes casos de uso dentro de sistemas IoT. Este
framework destaca os desafios que compõem a união de casos de uso e cria formas de
levá-los para os times envolvidos com o projeto, utilizando diagramas UML para fins de
ilustração. Além disso, faz uma análise sobre a associação da engenharia de requisitos
vertical com a horizontal, e o impacto de cada uma dentro da estrutura do IoT.
O framework é sucintamente composto de 3 etapas:
1. Identificação da interação entre casos de uso: Responsável por identificar a
relação que os casos de uso possuem antes de se fazer a união. Essa interação pode
ser de:
• Inclusão: Um caso de uso é incluso em outro caso de uso;
• Sobreposição: Há somente uma parte de um caso de uso que é compartilhada
com outro;
• Diferenciais ocultos: Existem aspectos ocultos no desenvolvimento,implantação
ou no operacional entre esses casos de uso;
• Requisitos conflitantes: Requisitos de diferentes casos de uso possuem con-
flitos entre si;
2. Identificação de coordenação: Essa fase, é responsável por fazer a coordenação
entre as diferentes fases de arquitetura do sistema a ser construído. Muitas vezes,
o projeto possui diversas equipes trabalhando de forma independente, por isso, é
importante garantir que que os times tenham em mente o que cada parte tem
como arquitetura planejada.Se o projeto estiver bem definido, essa fase irá somente
confirmar os requisitos da arquitetura projetada.
3. Identificação de impacto: Essa etapa lida com os impactos que a união de casos
de uso podem efetuar no sistema IoT. Os autores ainda quantificam a gravidade do
impacto, e se não houve nenhum impacto nessas uniões que levaram a revisões e
criação de novos requisitos e, com isso, impactando diversas partes [44].
Checklists e tabelas também são utilizadas para auxiliar as etapas do framework. Elas
tem objetivo de tornar mais claro o processo para o utilizador. O framework proposto por
Yamakami et al. [44] apesar de estar em estágios iniciais, tem como função guiar os times
de desenvolvedores que trabalham no mesmo projeto mas em áreas diferentes, a identificar
31
e verificar com mais facilidades os aspectos do projeto, minimizando retrabalhos e conflitos
de requisitos.
2.2.13 Towards Modelling and Analysis of Spatial and Temporal
Requirements
Touzani e Ponsand [45] descreveram um modelo para integração e análise de requisitos de
espaço-tempo no desenvolvimento de sistemas com contexto de IoT a partir da Engenharia
de Requisitos e do Sistema de Informação Geográfica (GIS). Características temporais são
estudadas e analisadas com muito mais ênfase do que características espaciais, estas só
vistas em sistemas mais específicos. Apesar disso, Touzani e Ponsand [45] destacaram
a importância que a união das características de tempo e espaço podem ter em revelar
problemas antes não vistos e tornar mais claro o sistema a ser construído.
A modelagem e integração desses requisitos é feita a partir de um método baseado
em Engenharia de Requisitos Orientada por Objetivos (GORE), o conceito de Manter
Todos os Objetivos Satisfeitos (KAOS) e a representação dos modelos por um diagrama
UML. Com isso, são feitas as integrações dos modelos de domínio e de objetivos com
características especiais e temporais. A integração de requisitos espaço temporais gera
um refinamento nos requisitos gerados baseando no fato das condições serem mais preci-
samente representadas. Outro ponto positivo é na checagem de requisitos, pois conforme
as restrições são colocadas, mais pontos de validação são criados.
A proposta realizada pelos autores