| 1 | \chapter{Nexo}
|
| 2 |
|
| 3 | O aplicativo proposto por esse trabalho, denominado “Orbit”, se propõe a ser
|
| 4 | uma 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, e portanto, o nome
|
| 8 | reflete essa escolha, visto que, um determinado objeto celeste em órbita de
|
| 9 | outro possuí duas fases: apogeu e perigeu. Define-se apogeu como “o ponto mais
|
| 10 | alto, supremo ou máximo de algo” (APOGEU, 2025). É um ponto de destaque,
|
| 11 | marcado pelo auge, prosperidade, influência ou excelência em uma determinada
|
| 12 | área ou contexto. Enquanto o segundo termo, define-se como “distância real ou
|
| 13 | aparente, de um astro, quando mais se aproxima da Terra”. O mesmo poderia ser
|
| 14 | utilizado de forma metafórica para descrever as duas fases da bipolaridade, a
|
| 15 | mania e a hipomania.
|
| 16 |
|
| 17 | A partir das demandas identificadas na pesquisa e dos princípios estabelecidos
|
| 18 | para este projeto, delineia-se um sistema de monitoramento de humor centrado no
|
| 19 | usuário, com ênfase em personalização, privacidade e utilidade reflexiva. O
|
| 20 | funcionamento do sistema parte da premissa de que o humor não é uma variável
|
| 21 | universal, mas sim composto por elementos subjetivos que variam entre
|
| 22 | indivíduos. Assim, fundamentalmente para cada entrada no diário, o usuário pode
|
| 23 | indicar que componentes de humor ele percebe em vigência naquele momento, como
|
| 24 | “raiva”, “tristeza”, “felicidade”, etc., elementos que ele considera mais
|
| 25 | representativos de seu estado emocional, permitindo um mapeamento mais fiel da
|
| 26 | sua experiência.
|
| 27 |
|
| 28 | O monitoramento, pode ser gerado em diversos momentos do dia e flexível: o
|
| 29 | usuário poderá escolher entre registrar suas emoções por meio de escrita livre,
|
| 30 | e usar uma escala que possa indicar o que ele percebe como indicadores dos
|
| 31 | níveis de estresse e ansiedade. Associado a isso, o sistema permitirá a entrada
|
| 32 | de gatilhos e eventos significativos, sejam positivos ou negativos, que poderão
|
| 33 | ser posteriormente correlacionados com os estados de humor, permitindo
|
| 34 | identificar padrões ou ciclos. A esses dados podem ser associadas intervenções
|
| 35 | leves, como sugestões de autorreflexão, lembretes de autocuidado, ou apenas
|
| 36 | mensagens-resumo, todas ajustáveis conforme a preferência de tom do usuário.
|
| 37 |
|
| 38 | Outro ponto essencial é a exportação de dados em formatos acessíveis,
|
| 39 | garantindo que o usuário tenha controle e mobilidade sobre suas informações,
|
| 40 | algo frequentemente negligenciado em sistemas fechados. Além disso, a
|
| 41 | ferramenta será open-source, garantindo transparência de funcionamento,
|
| 42 | possibilidade de auditoria e fomento a melhorias comunitárias, especialmente
|
| 43 | importantes no contexto de tecnologias sensíveis à saúde mental. Essas
|
| 44 | características formam a base de um sistema comprometido com o bem-estar, o
|
| 45 | respeito à individualidade e a soberania dos 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 Sommerville (2011, p. 85), “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 | [...] Requisitos funcionais do sistema variam de requisitos gerais, que
|
| 72 | abrangem o que o sistema deve fazer, até requisitos muito específicos, que
|
| 73 | refletem os sistemas e as formas de trabalho em uma organização.
|
| 74 | \cite[p.~59]{sommerville:2010}
|
| 75 | \end{quote}
|
| 76 |
|
| 77 | Portanto, diante das funcionalidades previstas, que foram anteriormente
|
| 78 | listadas, no Quadro 2 é apresentado os requisitos que o sistema deve fornecer:
|
| 79 |
|