| 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° & Requisito & Descrição \\
|
| 89 | \hline
|
| 90 | \endfirsthead
|
| 91 | \hline
|
| 92 | N° & Requisito & Descrição \\
|
| 93 | \hline
|
| 94 | \endhead
|
| 95 | \endfoot
|
| 96 |
|
| 97 | [RF01] &
|
| 98 | Login &
|
| 99 | O sistema deve ser capaz de realizar login com email e senha \\
|
| 100 |
|
| 101 | \hline
|
| 102 |
|
| 103 | [RF02] &
|
| 104 | Redefinir senha &
|
| 105 |
|
| 106 | O sistema permite que o usuário redefina a sua senha, mediante informar
|
| 107 | o email usado \\
|
| 108 |
|
| 109 | \hline
|
| 110 |
|
| 111 | [RF03] &
|
| 112 | Auto-cadastro &
|
| 113 | O sistema deve permitir que o usuário crie uma conta ao acessar pela
|
| 114 | primeira vez \\
|
| 115 |
|
| 116 | \hline
|
| 117 |
|
| 118 | [RF04] &
|
| 119 | Desconectar &
|
| 120 | O sistema permite que o usuário faça logout do sistema \\
|
| 121 |
|
| 122 | \hline
|
| 123 |
|
| 124 | [RF05] &
|
| 125 | Manter humor &
|
| 126 | O usuário deve poder registrar e atualizar seu estado emocional
|
| 127 | conforme a necessidade \\
|
| 128 |
|
| 129 | \hline
|
| 130 |
|
| 131 | [RF06] &
|
| 132 | Registrar gatilho &
|
| 133 | O sistema deve permitir associar sentimentos ou eventos específicos que
|
| 134 | influenciam o humor \\
|
| 135 |
|
| 136 | \hline
|
| 137 |
|
| 138 | [RF07] &
|
| 139 | Visualizar histórico &
|
| 140 | O usuário deve ter acesso aos registros anteriores de humor e demais
|
| 141 | entradas \\
|
| 142 |
|
| 143 | \hline
|
| 144 |
|
| 145 | [RF08] &
|
| 146 | Visualizar detalhes do dia &
|
| 147 | O sistema deve permitir expandir e consultar dados específicos de um
|
| 148 | determinado dia \\
|
| 149 |
|
| 150 | \hline
|
| 151 |
|
| 152 | [RF09] &
|
| 153 | Visualizar diário semanal &
|
| 154 | O usuário deve poder consultar uma visão consolidada da semana \\
|
| 155 |
|
| 156 | \hline
|
| 157 |
|
| 158 | [RF10] &
|
| 159 | Ver ciclo atual &
|
| 160 | O sistema deve apresentar um resumo do ciclo emocional em andamento \\
|
| 161 |
|
| 162 | \hline
|
| 163 |
|
| 164 | [RF11] &
|
| 165 | Comparar ciclos passados &
|
| 166 | O usuário deve poder visualizar diferenças entre ciclos emocionais
|
| 167 | anteriores \\
|
| 168 |
|
| 169 | \hline
|
| 170 |
|
| 171 | [RF12] &
|
| 172 | Exportar dados &
|
| 173 | O sistema deve oferecer uma funcionalidade para exportar os dados
|
| 174 | registrados \\
|
| 175 |
|
| 176 | \hline
|
| 177 |
|
| 178 | [RF13] &
|
| 179 | Configurar lembretes &
|
| 180 | O usuário pode configurar lembretes para registros de humor ou outras
|
| 181 | atividades \\
|
| 182 |
|
| 183 | \hline
|
| 184 |
|
| 185 | [RF14] &
|
| 186 | Manter registro de sono &
|
| 187 | O sistema deve permitir que o usuário registre informações relacionadas
|
| 188 | ao sono de forma simples \\
|
| 189 |
|
| 190 | \hline
|
| 191 |
|
| 192 | [RF15] &
|
| 193 | Registrar intervenção &
|
| 194 | O sistema deve permitir registrar intervenções realizadas para lidar
|
| 195 | com um gatilho ou de forma habitual \\
|
| 196 |
|
| 197 | \hline
|
| 198 |
|
| 199 | [RF16] &
|
| 200 | Associar intervenção a gatilho &
|
| 201 | O sistema deve permitir vincular uma intervenção específica a um
|
| 202 | gatilho registrado \\
|
| 203 |
|
| 204 | \hline
|
| 205 |
|
| 206 | [RF17] &
|
| 207 | Avaliar eficácia de uma intervenção &
|
| 208 |
|
| 209 | O usuário deve poder avaliar se a intervenção aplicada foi eficaz ou
|
| 210 | não para fins de controle \\
|
| 211 |
|
| 212 | \hline
|
| 213 | \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\
|
| 214 | \end{longtable}
|
| 215 |
|
| 216 | \subsection{Requirementos não funcionais}
|
| 217 |
|
| 218 | De acordo com \cite[p.~89]{sommerville:2010}: "Requisitos não funcionais são
|
| 219 | restrições sobre os serviços ou funções oferecidas pelo sistema". Ou seja,
|
| 220 | definem os critérios de qualidade que o sistema deve seguir, abrangendo
|
| 221 | aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto,
|
| 222 | destacam-se especialmente a preservação da privacidade do usuário, a
|
| 223 | transparência proporcionada pelo código aberto e a possibilidade de utilização
|
| 224 | offline, o que garante acessibilidade mesmo em contextos de conectividade
|
| 225 | limitada.
|
| 226 |
|
| 227 | \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
|
| 228 | \caption{Requisitos não funcionais}
|
| 229 | \label{tab:requisitos_nao_funcionais} \\
|
| 230 | \hline
|
| 231 | N° & Requisito & Descrição \\
|
| 232 | \hline
|
| 233 | \endfirsthead
|
| 234 | \hline
|
| 235 | N° & Requisito & Descrição \\
|
| 236 | \hline
|
| 237 | \endhead
|
| 238 | \endfoot
|
| 239 |
|
| 240 | [RNF01] &
|
| 241 | Usabilidade &
|
| 242 |
|
| 243 | O sistema deve possuir uma interface intuitiva e acessível para
|
| 244 | usuários leigos em tecnologia, com navegação fluída e confirmações
|
| 245 | visuais após cada interação importante \\
|
| 246 |
|
| 247 | \hline
|
| 248 |
|
| 249 | [RNF02] &
|
| 250 | Desempenho &
|
| 251 |
|
| 252 | O tempo de resposta entre a entrada do usuário e a resposta do sistema
|
| 253 | deve ser inferior a 1 segundo; O carregamento do histórico semanal e
|
| 254 | visualizações de ciclos anteriores deve ocorrer em no máximo 2
|
| 255 | segundos. \\
|
| 256 |
|
| 257 | \hline
|
| 258 |
|
| 259 | [RNF03] &
|
| 260 | Segurança &
|
| 261 |
|
| 262 | Os dados do usuário devem ser armazenados de forma criptografada; O
|
| 263 | sistema deve exigir autenticação segura para acesso; A exportação de
|
| 264 | dados deve sempre exigir a confirmação do usuário \\
|
| 265 | \hline
|
| 266 |
|
| 267 | [RNF04] &
|
| 268 | Confiabilidade &
|
| 269 |
|
| 270 | O sistema deve garantir a persistência dos dados, mesmo em casos de
|
| 271 | falha de energia ou conexão; Os dados registrados devem ser armazenados
|
| 272 | automáticamente e sincronizados quando ouvir conexão \\
|
| 273 |
|
| 274 | \hline
|
| 275 |
|
| 276 | [RNF05] &
|
| 277 | Portabilidade &
|
| 278 |
|
| 279 | Todos os dados do usuário podem ser exportados a qualquer momento, em
|
| 280 | um formato de texto que permita que ele possa ler e interpretar,
|
| 281 | mediante compreensão mínima da linguagem/formato utilizado \\
|
| 282 |
|
| 283 | \hline
|
| 284 |
|
| 285 | [RNF06] &
|
| 286 | Privacidade &
|
| 287 |
|
| 288 | Nenhuma informação sensível do usuário deve ser compartilhada com
|
| 289 | terceiros e o sistema deve fornecer uma política de privacidade clara e
|
| 290 | acessível; Quaisquer alterações à mesma demanda que o usuário seja
|
| 291 | notificado \\
|
| 292 |
|
| 293 | \hline
|
| 294 | \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\
|
| 295 | \end{longtable}
|
| 296 |
|
| 297 | Com essas definições em mãos, pode-se avançar para a etapa de modelagem do
|
| 298 | sistema, usando os requerimentos apresentados como fundação para o sistema.
|