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