Sumário

3. Requisitos

Funcionais

1. Acesso de Usuários (visitante): O usuário que não estiver logado será considerado um usuário visitante, que poderá visualizar as diretrizes cadastradas, porém não poderá criar uma solicitação de diretriz ou gerenciar um projeto. Para tal, será necessário criar uma conta no sistema ou, se já possuir uma conta, realizar login. A tela de criação de conta conterá campos de (NOME DE USUÁRIO, EMAIL/CELULAR, SENHA E CONFIRMAÇÃO DE SENHA) e ela poderá ser acessada a partir da tela de login, na qual também conterá uma opção para redefinição de conta, caso por algum motivo o usuário esqueceu sua senha ou não possui mais acesso ao e-mail/celular.
2. Acesso de Usuários (comum): O usuário comum precisará estar logado no sistema para gerenciar seus projetos e suas solicitações.
3. Acesso de Usuários (admin): O usuário administrador possuirá uma tela de login diferente do usuário comum, ela poderá ser acessada por meio de um endpoint diferente no sistema. Para o usuário administrador não terão as opções de criação e recuperação de conta, visto que essa inclusão/modificação pode ser feita diretamente pela API ou pelo banco de dados.
4. Gerenciamento de Diretrizes: O usuário comum ao acessar a tela inicial do sistema terá acesso a todas as diretrizes disponíveis cadastradas ou aceitas por um usuário administrador, organizadas por paginação. Ele poderá realizar a filtragem por (TEXTO ou DEFICIÊNCIA). Para cada diretriz terá um ícone de carrinho para que assim ele possa montar seu projeto. O usuário administrador terá acesso às funcionalidades de incluir, editar ou excluir uma diretriz, também poderá utilizar os mesmos filtros. Além disso, o usuário comum poderá solicitar a criação de diretrizes, onde no menu ele também poderá acessar suas solicitações e filtrar por (TEXTO, DEFICIÊNCIA ou SITUAÇÃO). Para cada diretriz solicitada será mostrada a situação atual da solicitação. Ao acessar a solicitação, se houver, ele poderá também visualizar uma mensagem explicando o motivo da situação. O usuário administrador terá acesso a uma tela de solicitações, em que poderá verificar a solicitação, mudar a situação (APROVAR ou REJEITAR), que por padrão será em análise, e informar o motivo dela. Na tela de solicitações, o usuário administrador poderá filtrar por (SITUAÇÃO, DATA E HORA DA SOLICITAÇÃO ou DEFICIÊNCIA).
5. Gerenciamento de Projetos: O usuário comum poderá gerenciar seus projetos. Ao acessar o sistema, no menu ele terá a possibilidade de ir para a tela de projetos. Essa tela mostrará uma lista de projetos cadastrados pelo usuário, paginados. Ele poderá filtrar por (TEXTO ou DATA DE CRIAÇÃO). Nessa mesma tela haverá um botão para incluir um novo projeto e para cada projeto na lista haverá botões de edição e exclusão. Quando escolhida a opção de inclusão, a **interface aberta será a do carrinho, que mostra as diretrizes selecionadas e possibilita a criação de um nome e descrição para o projeto.
6. Preferências: Todos os usuários (visitante, comum e administrador) poderão visualizar e editar suas preferências do sistema, que incluirão (TEMA, BRILHO, FONTE, TAMANHO DA FONTE, CONTRASTE, ESPAÇAMENTO ENTRE LINHAS, ESPAÇAMENTO ENTRE LETRAS, TAMANHO DO CURSOR e COR DO CURSOR).

Não funcionais

1. Viabilizar Portabilidade: Por ser uma aplicação web funciona em qualquer sistema operacional, seja ele Linux, Windows, MacOS etc.
2. Ser acessível. Ser acessível. Com base na WCAG e no artigo AcessibiWeb, foram levantadas possíveis diretrizes a serem implementadas para que o sistema possua recursos de acessibilidade:
   1. Texto descritivo como alternativa para elementos não-textuais;
   2. Não dependência de orientação de tela para qualquer funcionalidade;
   3. Inputs de formulários com propósitos claros;
   4. Uso de contraste;
   5. Uso de texto, cores e elementos;
   6. Utilização de comandos por teclado;
   7. Responsividade;
   8. Título em todas as páginas (html head tag);
   9. Acesso de conteúdo por mais de um meio (menu, search…);
   10. Lógica sequencial e navegação intuitiva
   11. Labels e headings com propósitos claros;
   12. Mostrar ao usuário visualmente o ponto focal de onde ele está;
   13. Botões com descrições bem-definidas;
   14. Breadcrumb;
   15. Uso de WAI-ARIA;
   16. Tooltips;
   17. Definir o idioma da página;
   18. Cada item em uma lista precisa ter um valor único;
   19. Possibilidade de mais de um estilo de fonte, reajuste do tamanho do texto, brilho e contraste;
   20. Escrita por comando de voz;
   21. Leitor de tela;
   22. Teclado virtual

4. Design

• Arquitetura

  • O backend será uma API RESTful utilizando Nest.js e PostgreSQL, seguindo o padrão de separação em camadas (Controllers, Services, Repositories)
  • O frontend será uma aplicação Next.js seguindo padrão de componentes reutilizáveis e separação de responsabilidades
  • Comunicação por meio de JWT token e autorização por roles

• Backend Design

  • Padrão de módulos do Nest.js para organização de funcionalidades
  • Injeção de dependências para acoplamento fraco entre componentes
  • Guards para autenticação e permissões
  • Interceptors e filters para tratamentos de exceções
  • DTOs para validação de dados de entrada
  • Entidades mapeadas usando TypeORM

• Banco de Dados Design

  • Schema relacional com PostgreSQL
  • Constraints para garantir integridade dos dados

• Frontend Design

  • Arquitetura de componentes React (stateful/stateless)
  • Estratégia de gerenciamento de estado (Context API)
  • Padrão de rotas e navegação
  • Estratégia de fetching de dados (React Query)
  • Abordagem para UI/UX (design system, componentes reutilizáveis)

• Princípios REST

  • Separação entre frontend e backend
  • Não deve armazenar estado da sessão do cliente
  • Uso correto dos métodos HTTP, identificação por meio de URI

  ✅ 
  POST /users              # Criação de novo usuário
  PUT /users/123           # Atualização do usuário 123
  DELETE /users/123        # Exclusão do usuário 123
  
  ❌ Ruim
  GET /getUserById?id=123
  GET /createUser
  POST /deleteUser
  

  • O cliente não precisa saber se está interagindo diretamente com o servidor final ou com um intermediário