| 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, e portanto, o nome
|
| 8 | reflete essa escolha. A lógica é, de um aplicativo que consegue conectar
|
| 9 | diversos pontos, que em um primeiro momento parecem soltos: sono, rotina,
|
| 10 | práticas, humor, gatilhos.
|
| 11 |
|
| 12 | A partir das demandas identificadas na pesquisa e dos princípios estabelecidos
|
| 13 | para este projeto, delineia-se um sistema de monitoramento de humor centrado no
|
| 14 | usuário, com ênfase em personalização, privacidade e utilidade reflexiva. O
|
| 15 | funcionamento do sistema parte da premissa de que o humor não é uma variável
|
| 16 | universal, mas sim composto por elementos subjetivos que variam entre
|
| 17 | indivíduos. Assim, fundamentalmente para cada entrada no diário, o usuário pode
|
| 18 | indicar que componentes de humor ele percebe em vigência naquele momento, como
|
| 19 | “raiva”, “tristeza”, “felicidade”, etc., elementos que ele considera mais
|
| 20 | representativos de seu estado emocional, permitindo um mapeamento mais fiel da
|
| 21 | sua experiência.
|
| 22 |
|
| 23 | O monitoramento, pode ser gerado em diversos momentos do dia, o que torna o
|
| 24 | aplicativo mais flexível, ao invés de uma única entrada no dia. O usuário pode
|
| 25 | também anotar para cada momento, algo relevante, através de escrita livre, e
|
| 26 | usar uma escala que possa indicar o que ele percebe como indicadores dos níveis
|
| 27 | de energia, estresse e ansiedade. Associado a isso, o sistema permitirá a
|
| 28 | entrada de gatilhos e eventos significativos, sejam positivos ou negativos, que
|
| 29 | poderão ser posteriormente correlacionados com os estados de humor, permitindo
|
| 30 | identificar padrões ou ciclos. Esses dados podem ser correlacionados/vinculados
|
| 31 | com "práticas" ou "intervenções", como fármacos, psicoterapia, atividades
|
| 32 | físicas.
|
| 33 |
|
| 34 | Outro ponto essencial é a exportação de dados em formatos acessíveis,
|
| 35 | garantindo que o usuário tenha controle e mobilidade sobre suas informações,
|
| 36 | algo frequentemente negligenciado em sistemas fechados. Além disso, a
|
| 37 | ferramenta é por inteiro \textit{software} livre, garantindo transparência de
|
| 38 | funcionamento, possibilidade de auditoria e fomento a melhorias comunitárias,
|
| 39 | especialmente importantes no contexto de tecnologias sensíveis à saúde mental.
|
| 40 | Essas características formam a base de um sistema comprometido com o bem-estar,
|
| 41 | o respeito à individualidade e a soberania dos dados pessoais.
|
| 42 |
|
| 43 | Com base nas funcionalidades listadas, pode-se definir os requisitos funcionais
|
| 44 | e não funcionais no qual o sistema deve necessitar.
|
| 45 |
|
| 46 | \section{Classificação dos Requisitos}
|
| 47 |
|
| 48 | Como observado por \cite[p.~58]{sommerville:2010}, "Os requisitos de um sistema são
|
| 49 | as descrições dos serviços que o sistema deve prestar e as restrições à sua
|
| 50 | operação". Portanto, requisitos são declarações articuladas descrevendo de
|
| 51 | forma clara o que o sistema deve ser capaz de fazer para satisfazer as
|
| 52 | necessidades postas anteriormente. São definidas em duas categorias: requisitos
|
| 53 | funcionais que descrevem o comportamento e funções do sistema e requisitos não
|
| 54 | funcionais que descrevem os critérios específicos que podem ser usados para
|
| 55 | avaliar o bom funcionamento do sistema. A separação entre requisitos funcionais
|
| 56 | e não funcionais permite uma estrutura clara para priorização, testes e
|
| 57 | validação do projeto, respeitando tanto os objetivos técnicos quanto éticos da
|
| 58 | proposta. Logo a seguir, serão abordados com mais detalhes cada um deles.
|
| 59 |
|
| 60 | \subsection{Requisitos funcionais}
|
| 61 |
|
| 62 | Os requisitos funcionais dizem respeito às funcionalidades centrais do sistema,
|
| 63 | ou seja, declarações de tudo o que o sistema deve e está proposto a fazer e
|
| 64 | reagir. Sommerville reforça esse aspecto:
|
| 65 |
|
| 66 | \begin{quote}
|
| 67 |
|
| 68 | Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles
|
| 69 | dependem do tipo de software a ser desenvolvido, de quem são seus possíveis
|
| 70 | usuários e da abordagem geral adotada pela organização ao escrever os
|
| 71 | requisitos. Quando expressos como requisitos de usuário, os requisitos
|
| 72 | funcionais são normalmente descritos de forma abstrata, para serem
|
| 73 | compreendidos pelos usuários do sistema.
|
| 74 |
|
| 75 | \cite[p.~59]{sommerville:2010}
|
| 76 | \end{quote}
|
| 77 |
|
| 78 | Portanto, diante das funcionalidades previstas, que foram brevemente listadas,
|
| 79 | no Quadro 2 é apresentado os requisitos que o sistema deve fornecer:
|