| 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, como o
|
| 36 | formato CSV \cite{Shafranovich_2005}, garantindo que o usuário tenha controle e
|
| 37 | mobilidade sobre suas informações, algo frequentemente negligenciado em
|
| 38 | sistemas fechados. Além disso, a ferramenta é por inteiro \textit{software}
|
| 39 | livre, garantindo transparência de funcionamento, possibilidade de auditoria e
|
| 40 | fomento a melhorias comunitárias, especialmente importantes no contexto de
|
| 41 | tecnologias sensíveis à saúde mental. Essas características formam a base de um
|
| 42 | sistema comprometido com o bem-estar, o respeito à individualidade e a
|
| 43 | soberania dos dados pessoais.
|
| 44 |
|
| 45 | Com base nas funcionalidades listadas, pode-se definir os requisitos funcionais
|
| 46 | e não funcionais no qual o sistema deve necessitar.
|
| 47 |
|
| 48 | \section{Classificação dos Requisitos}
|
| 49 |
|
| 50 | Como observado por \cite[p.~58]{sommerville:2010}, ``Os requisitos de um sistema são
|
| 51 | as descrições dos serviços que o sistema deve prestar e as restrições à sua
|
| 52 | operação''. Portanto, requisitos são declarações articuladas descrevendo de
|
| 53 | forma clara o que o sistema deve ser capaz de fazer para satisfazer as
|
| 54 | necessidades postas anteriormente. São definidas em duas categorias: requisitos
|
| 55 | funcionais que descrevem o comportamento e funções do sistema e requisitos não
|
| 56 | funcionais que descrevem os critérios específicos que podem ser usados para
|
| 57 | avaliar o bom funcionamento do sistema. A separação entre requisitos funcionais
|
| 58 | e não funcionais permite uma estrutura clara para priorização, testes e
|
| 59 | validação do projeto, respeitando tanto os objetivos técnicos quanto éticos da
|
| 60 | proposta. Logo a seguir, serão abordados com mais detalhes cada um deles.
|
| 61 |
|
| 62 | \subsection{Requisitos funcionais}
|
| 63 |
|
| 64 | Os requisitos funcionais dizem respeito às funcionalidades centrais do sistema,
|
| 65 | ou seja, declarações de tudo o que o sistema deve e está proposto a fazer e
|
| 66 | reagir. Sommerville reforça esse aspecto:
|
| 67 |
|
| 68 | \begin{quote}
|
| 69 |
|
| 70 | Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles
|
| 71 | dependem do tipo de software a ser desenvolvido, de quem são seus possíveis
|
| 72 | usuários e da abordagem geral adotada pela organização ao escrever os
|
| 73 | requisitos. Quando expressos como requisitos de usuário, os requisitos
|
| 74 | funcionais são normalmente descritos de forma abstrata, para serem
|
| 75 | compreendidos pelos usuários do sistema.
|
| 76 |
|
| 77 | \cite[p.~59]{sommerville:2010}
|
| 78 | \end{quote}
|
| 79 |
|
| 80 | Portanto, diante das funcionalidades previstas, que foram brevemente listadas,
|
| 81 | no Quadro 2 é apresentado os requisitos que o sistema deve fornecer:
|
| 82 |
|
| 83 | \newpage
|
| 84 |
|
| 85 | % TODO: Add this to the list of tables
|
| 86 | \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
|
| 87 | \caption{Requisitos funcionais}
|
| 88 | \label{tab:requisitos_funcionais} \\
|
| 89 | \hline
|
| 90 | N° & Requisito & Descrição \\
|
| 91 | \hline
|
| 92 | \endfirsthead
|
| 93 | \hline
|
| 94 | N° & Requisito & Descrição \\
|
| 95 | \hline
|
| 96 | \endhead
|
| 97 | \endfoot
|
| 98 |
|
| 99 | [RF01] &
|
| 100 | Login &
|
| 101 | O sistema deve ser capaz de realizar login com email e senha \\
|
| 102 |
|
| 103 | \hline
|
| 104 |
|
| 105 | [RF02] &
|
| 106 | Redefinir senha &
|
| 107 |
|
| 108 | O sistema permite que o usuário redefina a sua senha, mediante informar
|
| 109 | o email usado \\
|
| 110 |
|
| 111 | \hline
|
| 112 |
|
| 113 | [RF03] &
|
| 114 | Cadastro &
|
| 115 | O sistema deve permitir que o usuário crie uma conta \\
|
| 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 | tipos de dados como Gatilho, Sono, etc. \\
|
| 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 registros de humor recente &
|
| 155 | O usuário deve poder visualizar os ultimos registros de humor como
|
| 156 | forma de ler \\
|
| 157 |
|
| 158 | \hline
|
| 159 |
|
| 160 | [RF10] &
|
| 161 | Manter registro de sono &
|
| 162 | O sistema deve permitir que o usuário possa cadastrar registros de sono \\
|
| 163 |
|
| 164 | \hline
|
| 165 |
|
| 166 | [RF11] &
|
| 167 | Manter ações de cuidado &
|
| 168 | O usuário deve poder cadastrar ações de cuidado (atividade, medicamentos, consultas) \\
|
| 169 |
|
| 170 | \hline
|
| 171 |
|
| 172 | [RF12] &
|
| 173 | Exportar dados &
|
| 174 | O sistema deve oferecer uma funcionalidade para exportar os dados
|
| 175 | registrados \\
|
| 176 |
|
| 177 | \hline
|
| 178 |
|
| 179 | [RF13] &
|
| 180 | Registrar que um medicamento foi tomado &
|
| 181 | O usuário pode marcar que um determinado medicamento foi tomado
|
| 182 | mediante que foi cadastrado \\
|
| 183 |
|
| 184 | \hline
|
| 185 |
|
| 186 | [RF14] &
|
| 187 | Associar humor à um gatilho &
|
| 188 | O sistema deve permitir que o usuário vincule um humor específico com
|
| 189 | um gatilho \\
|
| 190 |
|
| 191 | \hline
|
| 192 |
|
| 193 | [RF15] &
|
| 194 | Associar consulta com um humor ou gatilho &
|
| 195 | O sistema deve permitir vincular uma consulta específica a um
|
| 196 | gatilho ou humor registrado \\
|
| 197 |
|
| 198 | \hline
|
| 199 |
|
| 200 | [RF16] &
|
| 201 | Gerar um relatório com os últimos dados &
|
| 202 | O usuário deve selecionar um período e gerar/exportar um relatório com
|
| 203 | os últimos dados \\
|
| 204 |
|
| 205 | \hline
|
| 206 | \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\
|
| 207 | \end{longtable}
|
| 208 |
|
| 209 | \subsection{Requirementos não funcionais}
|
| 210 |
|
| 211 | De acordo com \cite[p.~89]{sommerville:2010}: ``Requisitos não funcionais são
|
| 212 | restrições sobre os serviços ou funções oferecidas pelo sistema''. Ou seja,
|
| 213 | definem os critérios de qualidade que o sistema deve seguir, abrangendo
|
| 214 | aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto,
|
| 215 | destacam-se especialmente a preservação da privacidade do usuário, a
|
| 216 | transparência proporcionada pelo código aberto e a possibilidade de utilização
|
| 217 | offline, o que garante acessibilidade mesmo em contextos de conectividade
|
| 218 | limitada.
|
| 219 |
|
| 220 | \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |}
|
| 221 | \caption{Requisitos não funcionais}
|
| 222 | \label{tab:requisitos_nao_funcionais} \\
|
| 223 | \hline
|
| 224 | N° & Requisito & Descrição \\
|
| 225 | \hline
|
| 226 | \endfirsthead
|
| 227 | \hline
|
| 228 | N° & Requisito & Descrição \\
|
| 229 | \hline
|
| 230 | \endhead
|
| 231 | \endfoot
|
| 232 |
|
| 233 | [RNF01] &
|
| 234 | Usabilidade &
|
| 235 |
|
| 236 | O sistema deve possuir uma interface intuitiva e acessível para
|
| 237 | usuários leigos em tecnologia, com navegação fluída e confirmações
|
| 238 | visuais após cada interação importante \\
|
| 239 |
|
| 240 | \hline
|
| 241 |
|
| 242 | [RNF02] &
|
| 243 | Desempenho &
|
| 244 |
|
| 245 | O tempo de resposta entre a entrada do usuário e a resposta do sistema
|
| 246 | deve ser inferior a 1 segundo; O carregamento do histórico semanal e
|
| 247 | visualizações de ciclos anteriores deve ocorrer em no máximo 2
|
| 248 | segundos. \\
|
| 249 |
|
| 250 | \hline
|
| 251 |
|
| 252 | [RNF03] &
|
| 253 | Segurança &
|
| 254 |
|
| 255 | Os dados do usuário devem ser armazenados de forma criptografada; O
|
| 256 | sistema deve exigir autenticação segura para acesso; A exportação de
|
| 257 | dados deve sempre exigir a confirmação do usuário \\
|
| 258 | \hline
|
| 259 |
|
| 260 | [RNF04] &
|
| 261 | Confiabilidade &
|
| 262 |
|
| 263 | O sistema deve garantir a persistência dos dados, mesmo em casos de
|
| 264 | falha de energia ou conexão; Os dados registrados devem ser armazenados
|
| 265 | automáticamente e sincronizados quando ouvir conexão \\
|
| 266 |
|
| 267 | \hline
|
| 268 |
|
| 269 | [RNF05] &
|
| 270 | Portabilidade &
|
| 271 |
|
| 272 | Todos os dados do usuário podem ser exportados a qualquer momento, em
|
| 273 | um formato de texto que permita que ele possa ler e interpretar,
|
| 274 | mediante compreensão mínima da linguagem/formato utilizado \\
|
| 275 |
|
| 276 | \hline
|
| 277 |
|
| 278 | [RNF06] &
|
| 279 | Privacidade &
|
| 280 |
|
| 281 | Nenhuma informação sensível do usuário deve ser compartilhada com
|
| 282 | terceiros e o sistema deve fornecer uma política de privacidade clara e
|
| 283 | acessível; Quaisquer alterações à mesma demanda que o usuário seja
|
| 284 | notificado \\
|
| 285 |
|
| 286 | \hline
|
| 287 | \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\
|
| 288 | \end{longtable}
|
| 289 |
|
| 290 | Com essas definições em mãos, pode-se avançar para a etapa de modelagem do
|
| 291 | sistema, usando os requerimentos apresentados como fundação para o sistema.
|