eletrotupi / tcc/ monografia/chapters/app.tex900f2bcfdf5d6b2d5891439eb07570fba92a49bc
7.5 KB | 212 lines Raw
1
\chapter{Nexo}
2

3
O aplicativo proposto por esse trabalho, denominado "Nexo", se propõe a ser uma
4
aplicação para dispositivos móveis, de forma a preencher essas lacunas
5
demonstradas tanto pelo questionário, quanto também tentando preencher as
6
questões analisadas em outros sistemas similares. Como mencionado
7
anteriormente, o sistema é direcionado para pessoas com TAB, e portanto, o nome
8
reflete essa escolha. A lógica é, de um aplicativo que consegue conectar
9
diversos pontos, que em um primeiro momento parecem soltos: sono, rotina,
10
práticas, humor, gatilhos.
11

12
A partir das demandas identificadas na pesquisa e dos princípios estabelecidos
13
para este projeto, delineia-se um sistema de monitoramento de humor centrado no
14
usuário, com ênfase em personalização, privacidade e utilidade reflexiva. O
15
funcionamento do sistema parte da premissa de que o humor não é uma variável
16
universal, mas sim composto por elementos subjetivos que variam entre
17
indivíduos. Assim, fundamentalmente para cada entrada no diário, o usuário pode
18
indicar que componentes de humor ele percebe em vigência naquele momento, como
19
“raiva”, “tristeza”, “felicidade”, etc., elementos que ele considera mais
20
representativos de seu estado emocional, permitindo um mapeamento mais fiel da
21
sua experiência.
22

23
O monitoramento, pode ser gerado em diversos momentos do dia, o que torna o
24
aplicativo mais flexível, ao invés de uma única entrada no dia. O usuário pode
25
também anotar para cada momento, algo relevante, através de escrita livre, e
26
usar uma escala que possa indicar o que ele percebe como indicadores dos níveis
27
de energia, estresse e ansiedade. Associado a isso, o sistema permitirá a
28
entrada de gatilhos e eventos significativos, sejam positivos ou negativos, que
29
poderão ser posteriormente correlacionados com os estados de humor, permitindo
30
identificar padrões ou ciclos. Esses dados podem ser correlacionados/vinculados
31
com "práticas" ou "intervenções", como fármacos, psicoterapia, atividades
32
físicas.
33

34
Outro ponto essencial é a exportação de dados em formatos acessíveis,
35
garantindo que o usuário tenha controle e mobilidade sobre suas informações,
36
algo frequentemente negligenciado em sistemas fechados. Além disso, a
37
ferramenta é por inteiro \textit{software} livre, garantindo transparência de
38
funcionamento, possibilidade de auditoria e fomento a melhorias comunitárias,
39
especialmente importantes no contexto de tecnologias sensíveis à saúde mental.
40
Essas características formam a base de um sistema comprometido com o bem-estar,
41
o respeito à individualidade e a soberania dos dados pessoais.
42

43
Com base nas funcionalidades listadas, pode-se definir os requisitos funcionais
44
e não funcionais no qual o sistema deve necessitar.
45

46
\section{Classificação dos Requisitos}
47

48
Como observado por \cite[p.~58]{sommerville:2010}, "Os requisitos de um sistema são
49
as descrições dos serviços que o sistema deve prestar e as restrições à sua
50
operação". Portanto, requisitos são declarações articuladas descrevendo de
51
forma clara o que o sistema deve ser capaz de fazer para satisfazer as
52
necessidades postas anteriormente. São definidas em duas categorias: requisitos
53
funcionais que descrevem o comportamento e funções do sistema e requisitos não
54
funcionais que descrevem os critérios específicos que podem ser usados para
55
avaliar o bom funcionamento do sistema. A separação entre requisitos funcionais
56
e não funcionais permite uma estrutura clara para priorização, testes e
57
validação do projeto, respeitando tanto os objetivos técnicos quanto éticos da
58
proposta. Logo a seguir, serão abordados com mais detalhes cada um deles.
59

60
\subsection{Requisitos funcionais}
61

62
Os requisitos funcionais dizem respeito às funcionalidades centrais do sistema,
63
ou seja, declarações de tudo o que o sistema deve e está proposto a fazer e
64
reagir. Sommerville reforça esse aspecto:
65

66
\begin{quote}
67

68
  Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles
69
  dependem do tipo de software a ser desenvolvido, de quem são seus possíveis
70
  usuários e da abordagem geral adotada pela organização ao escrever os
71
  requisitos. Quando expressos como requisitos de usuário, os requisitos
72
  funcionais são normalmente descritos de forma abstrata, para serem
73
  compreendidos pelos usuários do sistema.
74

75
  \cite[p.~59]{sommerville:2010}
76
\end{quote}
77

78
Portanto, diante das funcionalidades previstas, que foram brevemente listadas,
79
no Quadro 2 é apresentado os requisitos que o sistema deve fornecer:
80

81
\newpage
82

83
% TODO: Add this to the list of tables
84
\begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
85
    \caption{Requisitos funcionais}
86
    \label{tab:requisitos_funcionais}
87
        \hline
88
        N° &
89
        Requisito &
90
        Descrição \\
91

92
        \hline
93

94
        [RF01] &
95
        Login &
96
        O sistema deve ser capaz de realizar login com email e senha \\
97

98
        \hline
99

100
        [RF02] &
101
        Redefinir senha &
102

103
        O sistema permite que o usuário redefina a sua senha, mediante informar
104
        o email usado \\
105

106
        \hline
107

108
        [RF03] &
109
        Auto-cadastro &
110
        O sistema deve permitir que o usuário crie uma conta ao acessar pela
111
        primeira vez \\
112

113
        \hline
114

115
        [RF04] &
116
        Desconectar &
117
        O sistema permite que o usuário faça logout do sistema \\
118

119
        \hline
120

121
        [RF05] &
122
        Manter humor &
123
        O usuário deve poder registrar e atualizar seu estado emocional
124
        conforme a necessidade \\
125

126
        \hline
127

128
        [RF06] &
129
        Registrar gatilho &
130
        O sistema deve permitir associar sentimentos ou eventos específicos que
131
        influenciam o humor \\
132

133
        \hline
134

135
        [RF07] &
136
        Visualizar histórico &
137
        O usuário deve ter acesso aos registros anteriores de humor e demais
138
        entradas \\
139

140
        \hline
141

142
        [RF08] &
143
        Visualizar detalhes do dia &
144
        O sistema deve permitir expandir e consultar dados específicos de um
145
        determinado dia \\
146

147
        \hline
148

149
        [RF09] &
150
        Visualizar diário semanal &
151
        O usuário deve poder consultar uma visão consolidada da semana \\
152

153
        \hline
154

155
        [RF10] &
156
        Ver ciclo atual &
157
        O sistema deve apresentar um resumo do ciclo emocional em andamento \\
158

159
        \hline
160

161
        [RF11] &
162
        Comparar ciclos passados &
163
        O usuário deve poder visualizar diferenças entre ciclos emocionais
164
        anteriores \\
165

166
        \hline
167

168
        [RF12] &
169
        Exportar dados &
170
        O sistema deve oferecer uma funcionalidade para exportar os dados
171
        registrados \\
172

173
        \hline
174

175
        [RF13] &
176
        Configurar lembretes &
177
        O usuário pode configurar lembretes para registros de humor ou outras
178
        atividades \\
179

180
        \hline
181

182
        [RF14] &
183
        Manter registro de sono &
184
        O sistema deve permitir que o usuário registre informações relacionadas
185
        ao sono de forma simples \\
186

187
        \hline
188

189
        [RF15] &
190
        Registrar intervenção &
191
        O sistema deve permitir registrar intervenções realizadas para lidar
192
        com um gatilho ou de forma habitual \\
193

194
        \hline
195

196
        [RF16] &
197
        Associar intervenção a gatilho &
198
        O sistema deve permitir vincular uma intervenção específica a um
199
        gatilho registrado \\
200

201
        \hline
202

203
        [RF17] &
204
        Avaliar eficácia de uma intervenção &
205

206
        O usuário deve poder avaliar se a intervenção aplicada foi eficaz ou
207
        não para fins de controle \\
208

209
        \hline
210
\end{longtable}
211
\source{Elaborado pelo autor (2026)}
212