\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, 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,
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] &
Auto-cadastro &
O sistema deve permitir que o usuário crie uma conta ao acessar pela
primeira vez \\
\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
entradas \\
\hline
[RF08] &
Visualizar detalhes do dia &
O sistema deve permitir expandir e consultar dados específicos de um
determinado dia \\
\hline
[RF09] &
Visualizar diário semanal &
O usuário deve poder consultar uma visão consolidada da semana \\
\hline
[RF10] &
Ver ciclo atual &
O sistema deve apresentar um resumo do ciclo emocional em andamento \\
\hline
[RF11] &
Comparar ciclos passados &
O usuário deve poder visualizar diferenças entre ciclos emocionais
anteriores \\
\hline
[RF12] &
Exportar dados &
O sistema deve oferecer uma funcionalidade para exportar os dados
registrados \\
\hline
[RF13] &
Configurar lembretes &
O usuário pode configurar lembretes para registros de humor ou outras
atividades \\
\hline
[RF14] &
Manter registro de sono &
O sistema deve permitir que o usuário registre informações relacionadas
ao sono de forma simples \\
\hline
[RF15] &
Registrar intervenção &
O sistema deve permitir registrar intervenções realizadas para lidar
com um gatilho ou de forma habitual \\
\hline
[RF16] &
Associar intervenção a gatilho &
O sistema deve permitir vincular uma intervenção específica a um
gatilho registrado \\
\hline
[RF17] &
Avaliar eficácia de uma intervenção &
O usuário deve poder avaliar se a intervenção aplicada foi eficaz ou
não para fins de controle \\
\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.