\chapter{Nexo} O aplicativo proposto por esse trabalho, denominado "Nexo", se propõe a ser uma aplicação para dispositivos móveis, de forma a preencher essas lacunas demonstradas tanto pelo questionário, quanto também tentando preencher as questões analisadas em outros sistemas similares. Como mencionado anteriormente, o sistema é direcionado para pessoas com TAB, embora, ele também possa atuar isoladamente como um aplicativo de registro de humor, e portanto, o nome reflete essa escolha. A lógica é, de um aplicativo que consegue conectar diversos pontos, que em um primeiro momento parecem soltos: sono, rotina, práticas, humor, gatilhos. A partir das demandas identificadas na pesquisa e dos princípios estabelecidos para este projeto, delineia-se um sistema de monitoramento de humor centrado no usuário, com ênfase em personalização, privacidade e utilidade reflexiva. O funcionamento do sistema parte da premissa de que o humor não é uma variável universal, mas sim composto por elementos subjetivos que variam entre indivíduos. Assim, fundamentalmente para cada entrada no diário, o usuário pode indicar que componentes de humor ele percebe em vigência naquele momento, como ``raiva'', ``tristeza'', ``felicidade'', etc., elementos que ele considera mais representativos de seu estado emocional, permitindo um mapeamento mais fiel da sua experiência. O monitoramento, pode ser gerado em diversos momentos do dia, o que torna o aplicativo mais flexível, ao invés de uma única entrada no dia. O usuário pode também anotar para cada momento, algo relevante, através de escrita livre, e usar uma escala que possa indicar o que ele percebe como indicadores dos níveis de energia, estresse e ansiedade. Associado a isso, o sistema permitirá a entrada de gatilhos e eventos significativos, sejam positivos ou negativos, que poderão ser posteriormente correlacionados com os estados de humor, permitindo identificar padrões ou ciclos. Esses dados podem ser correlacionados/vinculados com ``práticas'' ou ``intervenções'', como fármacos, psicoterapia, atividades físicas. Outro ponto essencial é a exportação de dados em formatos acessíveis, como o formato CSV \cite{Shafranovich_2005} \footnote{Formato de arquivo onde cada coluna é separado por um delimitador, por exemplo: vírgulas, ponto-e-vírgula, apresentado no RFC 4180}, garantindo que o usuário tenha controle e mobilidade sobre suas informações, algo frequentemente negligenciado em sistemas fechados. Além disso, a ferramenta é por inteiro \textit{software} livre, garantindo transparência de funcionamento, possibilidade de auditoria e fomento a melhorias comunitárias, especialmente importantes no contexto de tecnologias sensíveis à saúde mental. Essas características formam a base de um sistema comprometido com o bem-estar, o respeito à individualidade e a soberania dos dados pessoais. Com base nas funcionalidades listadas, pode-se definir os requisitos funcionais e não funcionais no qual o sistema deve necessitar. \section{Classificação dos Requisitos} Como observado por \cite[p.~58]{sommerville:2010}, ``Os requisitos de um sistema são as descrições dos serviços que o sistema deve prestar e as restrições à sua operação''. Portanto, requisitos são declarações articuladas descrevendo de forma clara o que o sistema deve ser capaz de fazer para satisfazer as necessidades postas anteriormente. São definidas em duas categorias: requisitos funcionais que descrevem o comportamento e funções do sistema e requisitos não funcionais que descrevem os critérios específicos que podem ser usados para avaliar o bom funcionamento do sistema. A separação entre requisitos funcionais e não funcionais permite uma estrutura clara para priorização, testes e validação do projeto, respeitando tanto os objetivos técnicos quanto éticos da proposta. Logo a seguir, serão abordados com mais detalhes cada um deles. \subsection{Requisitos funcionais} Os requisitos funcionais dizem respeito às funcionalidades centrais do sistema, ou seja, declarações de tudo o que o sistema deve e está proposto a fazer e reagir. Sommerville reforça esse aspecto: \begin{quote} Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles dependem do tipo de software a ser desenvolvido, de quem são seus possíveis usuários e da abordagem geral adotada pela organização ao escrever os requisitos. Quando expressos como requisitos de usuário, os requisitos funcionais são normalmente descritos de forma abstrata, para serem compreendidos pelos usuários do sistema. \cite[p.~59]{sommerville:2010} \end{quote} Portanto, diante das funcionalidades previstas, que foram brevemente listadas, no Quadro 2 é apresentado os requisitos que o sistema deve fornecer: \newpage % TODO: Add this to the list of tables \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |} \caption{Requisitos funcionais} \label{tab:requisitos_funcionais} \\ \hline N° & Requisito & Descrição \\ \hline \endfirsthead \hline N° & Requisito & Descrição \\ \hline \endhead \endfoot [RF01] & Login & O sistema deve ser capaz de realizar login com email e senha \\ \hline [RF02] & Redefinir senha & O sistema permite que o usuário redefina a sua senha, mediante informar o email usado \\ \hline [RF03] & Cadastro & O sistema deve permitir que o usuário crie uma conta \\ \hline [RF04] & Desconectar & O sistema permite que o usuário faça logout do sistema \\ \hline [RF05] & Manter humor & O usuário deve poder registrar e atualizar seu estado emocional conforme a necessidade \\ \hline [RF06] & Registrar gatilho & O sistema deve permitir associar sentimentos ou eventos específicos que influenciam o humor \\ \hline [RF07] & Visualizar histórico & O usuário deve ter acesso aos registros anteriores de humor e demais tipos de dados como Gatilho, Sono, etc. \\ \hline [RF08] & Visualizar detalhes do dia & O sistema deve permitir expandir e consultar dados específicos de um determinado dia \\ \hline [RF09] & Visualizar registros de humor recente & O usuário deve poder visualizar os ultimos registros de humor como forma de ler \\ \hline [RF10] & Manter registro de sono & O sistema deve permitir que o usuário possa cadastrar registros de sono \\ \hline [RF11] & Manter ações de cuidado & O usuário deve poder cadastrar ações de cuidado (atividade, medicamentos, consultas) \\ \hline [RF12] & Exportar dados & O sistema deve oferecer uma funcionalidade para exportar os dados registrados \\ \hline [RF13] & Registrar que um medicamento foi tomado & O usuário pode marcar que um determinado medicamento foi tomado mediante que foi cadastrado \\ \hline [RF14] & Associar humor à um gatilho & O sistema deve permitir que o usuário vincule um humor específico com um gatilho \\ \hline [RF15] & Associar consulta com um humor ou gatilho & O sistema deve permitir vincular uma consulta específica a um gatilho ou humor registrado \\ \hline [RF16] & Gerar um relatório com os últimos dados & O usuário deve selecionar um período e gerar/exportar um relatório com os últimos dados \\ \hline \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\ \end{longtable} \subsection{Requirementos não funcionais} De acordo com \cite[p.~89]{sommerville:2010}: ``Requisitos não funcionais são restrições sobre os serviços ou funções oferecidas pelo sistema''. Ou seja, definem os critérios de qualidade que o sistema deve seguir, abrangendo aspectos como segurança, usabilidade, desempenho e manutenção. Neste projeto, destacam-se especialmente a preservação da privacidade do usuário, a transparência proporcionada pelo código aberto e a possibilidade de utilização offline, o que garante acessibilidade mesmo em contextos de conectividade limitada. \begin{longtable}{| p{.20\textwidth} | p{.30\textwidth} | p{.40\textwidth} |} \caption{Requisitos não funcionais} \label{tab:requisitos_nao_funcionais} \\ \hline N° & Requisito & Descrição \\ \hline \endfirsthead \hline N° & Requisito & Descrição \\ \hline \endhead \endfoot [RNF01] & Usabilidade & O sistema deve possuir uma interface intuitiva e acessível para usuários leigos em tecnologia, com navegação fluída e confirmações visuais após cada interação importante \\ \hline [RNF02] & Desempenho & O tempo de resposta entre a entrada do usuário e a resposta do sistema deve ser inferior a 1 segundo; O carregamento do histórico semanal e visualizações de ciclos anteriores deve ocorrer em no máximo 2 segundos. \\ \hline [RNF03] & Segurança & Os dados do usuário devem ser armazenados de forma criptografada; O sistema deve exigir autenticação segura para acesso; A exportação de dados deve sempre exigir a confirmação do usuário \\ \hline [RNF04] & Confiabilidade & O sistema deve garantir a persistência dos dados, mesmo em casos de falha de energia ou conexão; Os dados registrados devem ser armazenados automáticamente e sincronizados quando ouvir conexão \\ \hline [RNF05] & Portabilidade & Todos os dados do usuário podem ser exportados a qualquer momento, em um formato de texto que permita que ele possa ler e interpretar, mediante compreensão mínima da linguagem/formato utilizado \\ \hline [RNF06] & Privacidade & Nenhuma informação sensível do usuário deve ser compartilhada com terceiros e o sistema deve fornecer uma política de privacidade clara e acessível; Quaisquer alterações à mesma demanda que o usuário seja notificado \\ \hline \multicolumn{3}{c}{\small Fonte: Elaborado pelo autor (2026)} \\ \end{longtable} Com essas definições em mãos, pode-se avançar para a etapa de modelagem do sistema, usando os requerimentos apresentados como fundação para o sistema.