| 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 |
|
| 213 | \subsection{Requirementos não funcionais}
|
| 214 |
|
| 215 | De acordo com \cite[p.~89]{sommerville:2010}: "Requisitos não funcionais são
|
| 216 | restrições sobre os serviços ou funções oferecidas pelo sistema". Ou seja,
|
| 217 | definem os critérios de qualidade que o sistema deve seguir, abrangendo
|
| 218 | aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto,
|
| 219 | destacam-se especialmente a preservação da privacidade do usuário, a
|
| 220 | transparência proporcionada pelo código aberto e a possibilidade de utilização
|
| 221 | offline, o que garante acessibilidade mesmo em contextos de conectividade
|
| 222 | limitada.
|
| 223 |
|
| 224 | \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
|
| 225 | \caption{Requisitos não funcionais}
|
| 226 | \label{tab:requisitos_nao_funcionais}
|
| 227 | \hline
|
| 228 | N° &
|
| 229 | Requisito &
|
| 230 | Descrição \\
|
| 231 |
|
| 232 | \hline
|
| 233 |
|
| 234 | [RNF01] &
|
| 235 | Usabilidade &
|
| 236 |
|
| 237 | O sistema deve possuir uma interface intuitiva e acessível para
|
| 238 | usuários leigos em tecnologia, com navegação fluída e confirmações
|
| 239 | visuais após cada interação importante \\
|
| 240 |
|
| 241 | \hline
|
| 242 |
|
| 243 | [RNF02] &
|
| 244 | Desempenho &
|
| 245 |
|
| 246 | O tempo de resposta entre a entrada do usuário e a resposta do sistema
|
| 247 | deve ser inferior a 1 segundo; O carregamento do histórico semanal e
|
| 248 | visualizações de ciclos anteriores deve ocorrer em no máximo 2
|
| 249 | segundos. \\
|
| 250 |
|
| 251 | \hline
|
| 252 |
|
| 253 | [RNF03] &
|
| 254 | Segurança &
|
| 255 |
|
| 256 | Os dados do usuário devem ser armazenados de forma criptografada; O
|
| 257 | sistema deve exigir autenticação segura para acesso; A exportação de
|
| 258 | dados deve sempre exigir a confirmação do usuário \\
|
| 259 | \hline
|
| 260 |
|
| 261 | [RNF04] &
|
| 262 | Confiabilidade &
|
| 263 |
|
| 264 | O sistema deve garantir a persistência dos dados, mesmo em casos de
|
| 265 | falha de energia ou conexão; Os dados registrados devem ser armazenados
|
| 266 | automáticamente e sincronizados quando ouvir conexão \\
|
| 267 |
|
| 268 | \hline
|
| 269 |
|
| 270 | [RNF05] &
|
| 271 | Portabilidade &
|
| 272 |
|
| 273 | Todos os dados do usuário podem ser exportados a qualquer momento, em
|
| 274 | um formato de texto que permita que ele possa ler e interpretar,
|
| 275 | mediante compreensão mínima da linguagem/formato utilizado \\
|
| 276 |
|
| 277 | \hline
|
| 278 |
|
| 279 | [RNF06] &
|
| 280 | Privacidade &
|
| 281 |
|
| 282 | Nenhuma informação sensível do usuário deve ser compartilhada com
|
| 283 | terceiros e o sistema deve fornecer uma política de privacidade clara e
|
| 284 | acessível; Quaisquer alterações à mesma demanda que o usuário seja
|
| 285 | notificado \\
|
| 286 |
|
| 287 | \hline
|
| 288 | \end{longtable}
|
| 289 | \source{Elaborado pelo autor (2026)}
|
| 290 |
|
| 291 | Com essas definições em mãos, pode-se avançar para a etapa de modelagem do
|
| 292 | sistema, usando os requerimentos apresentados como fundação para o sistema.
|