| 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, embora, ele também
|
| 8 | possa atuar isoladamente como um aplicativo de registro de humor, e portanto, o
|
| 9 | nome reflete essa escolha. A lógica é, de um aplicativo que consegue conectar
|
| 10 | diversos pontos, que em um primeiro momento parecem soltos: sono, rotina,
|
| 11 | práticas, humor, gatilhos.
|
| 12 |
|
| 13 | A partir das demandas identificadas na pesquisa e dos princípios estabelecidos
|
| 14 | para este projeto, delineia-se um sistema de monitoramento de humor centrado no
|
| 15 | usuário, com ênfase em personalização, privacidade e utilidade reflexiva. O
|
| 16 | funcionamento do sistema parte da premissa de que o humor não é uma variável
|
| 17 | universal, mas sim composto por elementos subjetivos que variam entre
|
| 18 | indivíduos. Assim, fundamentalmente para cada entrada no diário, o usuário pode
|
| 19 | indicar que componentes de humor ele percebe em vigência naquele momento, como
|
| 20 | “raiva”, “tristeza”, “felicidade”, etc., elementos que ele considera mais
|
| 21 | representativos de seu estado emocional, permitindo um mapeamento mais fiel da
|
| 22 | sua experiência.
|
| 23 |
|
| 24 | O monitoramento, pode ser gerado em diversos momentos do dia, o que torna o
|
| 25 | aplicativo mais flexível, ao invés de uma única entrada no dia. O usuário pode
|
| 26 | também anotar para cada momento, algo relevante, através de escrita livre, e
|
| 27 | usar uma escala que possa indicar o que ele percebe como indicadores dos níveis
|
| 28 | de energia, estresse e ansiedade. Associado a isso, o sistema permitirá a
|
| 29 | entrada de gatilhos e eventos significativos, sejam positivos ou negativos, que
|
| 30 | poderão ser posteriormente correlacionados com os estados de humor, permitindo
|
| 31 | identificar padrões ou ciclos. Esses dados podem ser correlacionados/vinculados
|
| 32 | com "práticas" ou "intervenções", como fármacos, psicoterapia, atividades
|
| 33 | físicas.
|
| 34 |
|
| 35 | Outro ponto essencial é a exportação de dados em formatos acessíveis,
|
| 36 | garantindo que o usuário tenha controle e mobilidade sobre suas informações,
|
| 37 | algo frequentemente negligenciado em sistemas fechados. Além disso, a
|
| 38 | ferramenta é por inteiro \textit{software} livre, garantindo transparência de
|
| 39 | funcionamento, possibilidade de auditoria e fomento a melhorias comunitárias,
|
| 40 | especialmente importantes no contexto de tecnologias sensíveis à saúde mental.
|
| 41 | Essas características formam a base de um sistema comprometido com o bem-estar,
|
| 42 | o respeito à individualidade e a soberania dos dados pessoais.
|
| 43 |
|
| 44 | Com base nas funcionalidades listadas, pode-se definir os requisitos funcionais
|
| 45 | e não funcionais no qual o sistema deve necessitar.
|
| 46 |
|
| 47 | \section{Classificação dos Requisitos}
|
| 48 |
|
| 49 | Como observado por \cite[p.~58]{sommerville:2010}, "Os requisitos de um sistema são
|
| 50 | as descrições dos serviços que o sistema deve prestar e as restrições à sua
|
| 51 | operação". Portanto, requisitos são declarações articuladas descrevendo de
|
| 52 | forma clara o que o sistema deve ser capaz de fazer para satisfazer as
|
| 53 | necessidades postas anteriormente. São definidas em duas categorias: requisitos
|
| 54 | funcionais que descrevem o comportamento e funções do sistema e requisitos não
|
| 55 | funcionais que descrevem os critérios específicos que podem ser usados para
|
| 56 | avaliar o bom funcionamento do sistema. A separação entre requisitos funcionais
|
| 57 | e não funcionais permite uma estrutura clara para priorização, testes e
|
| 58 | validação do projeto, respeitando tanto os objetivos técnicos quanto éticos da
|
| 59 | proposta. Logo a seguir, serão abordados com mais detalhes cada um deles.
|
| 60 |
|
| 61 | \subsection{Requisitos funcionais}
|
| 62 |
|
| 63 | Os requisitos funcionais dizem respeito às funcionalidades centrais do sistema,
|
| 64 | ou seja, declarações de tudo o que o sistema deve e está proposto a fazer e
|
| 65 | reagir. Sommerville reforça esse aspecto:
|
| 66 |
|
| 67 | \begin{quote}
|
| 68 |
|
| 69 | Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles
|
| 70 | dependem do tipo de software a ser desenvolvido, de quem são seus possíveis
|
| 71 | usuários e da abordagem geral adotada pela organização ao escrever os
|
| 72 | requisitos. Quando expressos como requisitos de usuário, os requisitos
|
| 73 | funcionais são normalmente descritos de forma abstrata, para serem
|
| 74 | compreendidos pelos usuários do sistema.
|
| 75 |
|
| 76 | \cite[p.~59]{sommerville:2010}
|
| 77 | \end{quote}
|
| 78 |
|
| 79 | Portanto, diante das funcionalidades previstas, que foram brevemente listadas,
|
| 80 | no Quadro 2 é apresentado os requisitos que o sistema deve fornecer:
|
| 81 |
|
| 82 | \newpage
|
| 83 |
|
| 84 | % TODO: Add this to the list of tables
|
| 85 | \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
|
| 86 | \caption{Requisitos funcionais}
|
| 87 | \label{tab:requisitos_funcionais} \\
|
| 88 | \hline
|
| 89 | N° & Requisito & Descrição \\
|
| 90 | \hline
|
| 91 | \endfirsthead
|
| 92 | \hline
|
| 93 | N° & Requisito & Descrição \\
|
| 94 | \hline
|
| 95 | \endhead
|
| 96 | \endfoot
|
| 97 |
|
| 98 | [RF01] &
|
| 99 | Login &
|
| 100 | O sistema deve ser capaz de realizar login com email e senha \\
|
| 101 |
|
| 102 | \hline
|
| 103 |
|
| 104 | [RF02] &
|
| 105 | Redefinir senha &
|
| 106 |
|
| 107 | O sistema permite que o usuário redefina a sua senha, mediante informar
|
| 108 | o email usado \\
|
| 109 |
|
| 110 | \hline
|
| 111 |
|
| 112 | [RF03] &
|
| 113 | Auto-cadastro &
|
| 114 | O sistema deve permitir que o usuário crie uma conta ao acessar pela
|
| 115 | primeira vez \\
|
| 116 |
|
| 117 | \hline
|
| 118 |
|
| 119 | [RF04] &
|
| 120 | Desconectar &
|
| 121 | O sistema permite que o usuário faça logout do sistema \\
|
| 122 |
|
| 123 | \hline
|
| 124 |
|
| 125 | [RF05] &
|
| 126 | Manter humor &
|
| 127 | O usuário deve poder registrar e atualizar seu estado emocional
|
| 128 | conforme a necessidade \\
|
| 129 |
|
| 130 | \hline
|
| 131 |
|
| 132 | [RF06] &
|
| 133 | Registrar gatilho &
|
| 134 | O sistema deve permitir associar sentimentos ou eventos específicos que
|
| 135 | influenciam o humor \\
|
| 136 |
|
| 137 | \hline
|
| 138 |
|
| 139 | [RF07] &
|
| 140 | Visualizar histórico &
|
| 141 | O usuário deve ter acesso aos registros anteriores de humor e demais
|
| 142 | entradas \\
|
| 143 |
|
| 144 | \hline
|
| 145 |
|
| 146 | [RF08] &
|
| 147 | Visualizar detalhes do dia &
|
| 148 | O sistema deve permitir expandir e consultar dados específicos de um
|
| 149 | determinado dia \\
|
| 150 |
|
| 151 | \hline
|
| 152 |
|
| 153 | [RF09] &
|
| 154 | Visualizar diário semanal &
|
| 155 | O usuário deve poder consultar uma visão consolidada da semana \\
|
| 156 |
|
| 157 | \hline
|
| 158 |
|
| 159 | [RF10] &
|
| 160 | Manter registro de sono &
|
| 161 | O sistema deve permitir que o usuário possa cadastrar registros de sono \\
|
| 162 |
|
| 163 | \hline
|
| 164 |
|
| 165 | [RF11] &
|
| 166 | Manter ações de cuidado &
|
| 167 | O usuário deve poder cadastrar ações de cuidado (atividade, medicamentos, consultas) \\
|
| 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 | Associar humor à um gatilho &
|
| 187 | O sistema deve permitir que o usuário vincule um humor específico com um gatilho \\
|
| 188 |
|
| 189 | \hline
|
| 190 |
|
| 191 | [RF15] &
|
| 192 | Associar intervenção a gatilho &
|
| 193 | O sistema deve permitir vincular uma intervenção específica a um
|
| 194 | gatilho registrado \\
|
| 195 |
|
| 196 | \hline
|
| 197 |
|
| 198 | [RF16] &
|
| 199 | Avaliar eficácia de uma intervenção &
|
| 200 |
|
| 201 | O usuário deve poder avaliar se a intervenção aplicada foi eficaz ou
|
| 202 | não para fins de controle \\
|
| 203 |
|
| 204 | \hline
|
| 205 | \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\
|
| 206 | \end{longtable}
|
| 207 |
|
| 208 | \subsection{Requirementos não funcionais}
|
| 209 |
|
| 210 | De acordo com \cite[p.~89]{sommerville:2010}: "Requisitos não funcionais são
|
| 211 | restrições sobre os serviços ou funções oferecidas pelo sistema". Ou seja,
|
| 212 | definem os critérios de qualidade que o sistema deve seguir, abrangendo
|
| 213 | aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto,
|
| 214 | destacam-se especialmente a preservação da privacidade do usuário, a
|
| 215 | transparência proporcionada pelo código aberto e a possibilidade de utilização
|
| 216 | offline, o que garante acessibilidade mesmo em contextos de conectividade
|
| 217 | limitada.
|
| 218 |
|
| 219 | \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
|
| 220 | \caption{Requisitos não funcionais}
|
| 221 | \label{tab:requisitos_nao_funcionais} \\
|
| 222 | \hline
|
| 223 | N° & Requisito & Descrição \\
|
| 224 | \hline
|
| 225 | \endfirsthead
|
| 226 | \hline
|
| 227 | N° & Requisito & Descrição \\
|
| 228 | \hline
|
| 229 | \endhead
|
| 230 | \endfoot
|
| 231 |
|
| 232 | [RNF01] &
|
| 233 | Usabilidade &
|
| 234 |
|
| 235 | O sistema deve possuir uma interface intuitiva e acessível para
|
| 236 | usuários leigos em tecnologia, com navegação fluída e confirmações
|
| 237 | visuais após cada interação importante \\
|
| 238 |
|
| 239 | \hline
|
| 240 |
|
| 241 | [RNF02] &
|
| 242 | Desempenho &
|
| 243 |
|
| 244 | O tempo de resposta entre a entrada do usuário e a resposta do sistema
|
| 245 | deve ser inferior a 1 segundo; O carregamento do histórico semanal e
|
| 246 | visualizações de ciclos anteriores deve ocorrer em no máximo 2
|
| 247 | segundos. \\
|
| 248 |
|
| 249 | \hline
|
| 250 |
|
| 251 | [RNF03] &
|
| 252 | Segurança &
|
| 253 |
|
| 254 | Os dados do usuário devem ser armazenados de forma criptografada; O
|
| 255 | sistema deve exigir autenticação segura para acesso; A exportação de
|
| 256 | dados deve sempre exigir a confirmação do usuário \\
|
| 257 | \hline
|
| 258 |
|
| 259 | [RNF04] &
|
| 260 | Confiabilidade &
|
| 261 |
|
| 262 | O sistema deve garantir a persistência dos dados, mesmo em casos de
|
| 263 | falha de energia ou conexão; Os dados registrados devem ser armazenados
|
| 264 | automáticamente e sincronizados quando ouvir conexão \\
|
| 265 |
|
| 266 | \hline
|
| 267 |
|
| 268 | [RNF05] &
|
| 269 | Portabilidade &
|
| 270 |
|
| 271 | Todos os dados do usuário podem ser exportados a qualquer momento, em
|
| 272 | um formato de texto que permita que ele possa ler e interpretar,
|
| 273 | mediante compreensão mínima da linguagem/formato utilizado \\
|
| 274 |
|
| 275 | \hline
|
| 276 |
|
| 277 | [RNF06] &
|
| 278 | Privacidade &
|
| 279 |
|
| 280 | Nenhuma informação sensível do usuário deve ser compartilhada com
|
| 281 | terceiros e o sistema deve fornecer uma política de privacidade clara e
|
| 282 | acessível; Quaisquer alterações à mesma demanda que o usuário seja
|
| 283 | notificado \\
|
| 284 |
|
| 285 | \hline
|
| 286 | \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\
|
| 287 | \end{longtable}
|
| 288 |
|
| 289 | Com essas definições em mãos, pode-se avançar para a etapa de modelagem do
|
| 290 | sistema, usando os requerimentos apresentados como fundação para o sistema.
|