Requisitos Não Funcionais

Requisitos Não Funcionais

1. Segurança

• RNF-SEC-01: O sistema deve utilizar o Keycloak como provedor de identidade, centralizando autenticação, controle de sessão, gerenciamento de credenciais, papéis e permissões funcionais dos usuários.
• RNF-SEC-02: O sistema deve utilizar o Keycloak Authorization Services para controlar permissões funcionais sobre os recursos do sistema, como usuários, consultas, agendas, médicos, anexos e relatórios.
• RNF-SEC-03: O backend deve validar o token de acesso dos usuários e consultar as permissões funcionais antes de executar operações protegidas.
• RNF-SEC-04: O sistema deve validar, além da autorização funcional, regras contextuais no backend, como vínculo com a organização, status ativo, propriedade dos dados, relação entre médico e consulta e vínculo entre usuário comum e suas próprias consultas.
• RNF-SEC-05: O sistema não deve armazenar senhas dos usuários em sua base de dados, mantendo apenas o identificador do usuário proveniente do Keycloak.
• RNF-SEC-06: O sistema deve garantir a confidencialidade dos dados sensíveis dos usuários e das informações clínicas, utilizando comunicação segura por HTTPS em ambientes de implantação.
• RNF-SEC-07: O sistema deve restringir o acesso a consultas, registros de atendimento e anexos conforme as permissões funcionais do Keycloak e as regras contextuais validadas pelo backend.
• RNF-SEC-08: O sistema deve manter histórico de alterações das entidades auditáveis por meio do Hibernate Envers.
• RNF-SEC-09: O sistema deve registrar informações de criação e alteração das entidades, incluindo usuário responsável, data de criação, data da última alteração e versão do registro.
• RNF-SEC-10: O sistema deve considerar princípios da LGPD no tratamento de dados pessoais e clínicos, limitando o acesso às informações conforme necessidade, finalidade de uso e vínculo com a organização.
• RNF-SEC-11: O sistema deve impedir auto-registro público de usuários, exigindo que acessos sejam criados ou liberados por perfis autorizados da organização.
• RNF-SEC-12: O sistema deve utilizar mecanismos de proteção contra tentativas repetidas de login, como bloqueio temporário por força bruta configurado no Keycloak.

2. Desempenho

• RNF-DES-01: O sistema deve responder às principais operações do usuário em até 2 segundos em condições normais de uso.
• RNF-DES-02: O sistema deve permitir a consulta eficiente de agendas por data, médico, unidade, consultório e status da consulta.
• RNF-DES-03: O sistema deve evitar carregamento desnecessário de arquivos binários armazenados no banco de dados, retornando o conteúdo dos anexos apenas quando solicitado pelo usuário autorizado.
• RNF-DES-04: O sistema deve utilizar paginação ou filtros em listagens com potencial de crescimento, como consultas, usuários, médicos, agendas e registros de atendimento.
• RNF-DES-05: O sistema deve impedir conflitos de agenda de forma eficiente, considerando consultas existentes, bloqueios, alocações médicas e disponibilidade do consultório.
• RNF-DES-06: O sistema deve evitar consultas excessivas ao Keycloak, utilizando validações de autorização de forma controlada e compatível com o padrão de introspecção adotado.
• RNF-DES-07: O sistema deve realizar operações críticas de agendamento e alteração de status de forma transacional, evitando inconsistências causadas por concorrência.

3. Escalabilidade

• RNF-ESC-01: O sistema deve ser estruturado de forma modular, permitindo evolução futura de módulos como financeiro, convênios, notificações, prescrição digital e integrações laboratoriais.
• RNF-ESC-02: O backend deve ser projetado de forma stateless sempre que possível, delegando autenticação, sessão, papéis e permissões funcionais ao Keycloak.
• RNF-ESC-03: O sistema deve permitir crescimento gradual no volume de organizações, unidades, médicos, usuários comuns, consultas e registros de atendimento sem exigir alteração estrutural significativa no modelo de dados.
• RNF-ESC-04: O armazenamento de anexos no banco de dados deve ser tratado de forma controlada, considerando limites de tamanho, impacto no desempenho e estratégia futura de migração para serviço externo de arquivos.
• RNF-ESC-05: O modelo de autorização deve permitir expansão futura de novos recursos e permissões no Keycloak sem necessidade de reestruturação completa da aplicação.

4. Disponibilidade

• RNF-DISP-01: O sistema deve estar disponível durante o horário operacional da organização que o utiliza.
• RNF-DISP-02: O sistema deve tratar falhas de forma adequada, exibindo mensagens compreensíveis ao usuário quando uma operação não puder ser concluída.
• RNF-DISP-03: O sistema deve preservar a integridade das informações já registradas em caso de falhas durante operações críticas, como agendamento, cancelamento, reagendamento, check-in e registro de atendimento.
• RNF-DISP-04: O sistema deve depender da disponibilidade do Keycloak para autenticação e autorização funcional dos usuários, devendo informar adequadamente quando o serviço de identidade estiver indisponível.
• RNF-DISP-05: O sistema deve evitar perda de dados em operações parcialmente concluídas, utilizando transações e tratamento adequado de exceções.

5. Backup e Recuperação

• RNF-BKP-01: O sistema deve permitir a realização de backups periódicos da base de dados.
• RNF-BKP-02: Os backups devem incluir os dados de domínio da aplicação, registros clínicos, consultas, anexos armazenados no banco e tabelas de auditoria geradas pelo Hibernate Envers.
• RNF-BKP-03: O sistema deve permitir a restauração dos dados a partir de backups, preservando a integridade das relações entre usuários, médicos, consultas, registros de atendimento, anexos e organizações.
• RNF-BKP-04: O processo de recuperação deve manter a consistência dos dados auditáveis e das versões registradas.
• RNF-BKP-05: A configuração do Keycloak, incluindo realm, clients, roles, grupos, user profile, resources, scopes, policies e permissions, deve poder ser exportada e versionada para facilitar restauração do ambiente.

6. Usabilidade

• RNF-USA-01: O sistema deve possuir interface simples e intuitiva, adequada aos perfis de administrador, recepcionista, médico e usuário comum.
• RNF-USA-02: O sistema deve minimizar o número de ações necessárias para tarefas frequentes, como agendamento de consulta, check-in, alteração de status e registro de atendimento.
• RNF-USA-03: O sistema deve apresentar feedback visual claro para ações realizadas, como sucesso, erro, carregamento, validação e indisponibilidade de horário.
• RNF-USA-04: A interface do médico deve priorizar a visualização da agenda, fila de atendimento e registro clínico simplificado.
• RNF-USA-05: A interface da recepcionista deve priorizar o controle da agenda diária, check-in, cadastro de usuários comuns e acompanhamento da fila.
• RNF-USA-06: A interface do usuário comum deve priorizar a consulta de horários, agendamento, histórico e acompanhamento do status das consultas.
• RNF-USA-07: O sistema deve apresentar mensagens claras quando uma ação for negada por falta de permissão funcional ou por regra contextual da aplicação.

7. Compatibilidade

• RNF-COMP-01: O sistema deve ser acessível por navegadores modernos, como Google Chrome, Mozilla Firefox e Microsoft Edge.
• RNF-COMP-02: O sistema deve possuir interface responsiva, permitindo utilização em desktop, tablet e dispositivos móveis.
• RNF-COMP-03: O sistema deve utilizar APIs REST e formato JSON para comunicação entre frontend e backend.
• RNF-COMP-04: O sistema deve ser compatível com ambiente backend baseado em Spring Boot, JPA/Hibernate, Hibernate Envers e integração com Keycloak.
• RNF-COMP-05: A API do sistema deve utilizar o prefixo /api para separar endpoints do backend das rotas da interface web.
• RNF-COMP-06: O sistema deve permitir execução local com frontend e backend em portas separadas, bem como implantação monolítica em produção, com frontend e API publicados sob o mesmo contexto externo.

8. Manutenibilidade

• RNF-MAN-01: O sistema deve ser desenvolvido com código modular e organizado, separando responsabilidades de domínio, aplicação, infraestrutura, segurança e interface.
• RNF-MAN-02: O sistema deve possuir documentação técnica adequada, incluindo requisitos, diagramas, modelo de dados, configuração do Keycloak e descrição dos principais fluxos.
• RNF-MAN-03: O sistema deve utilizar entidades padronizadas com campos comuns de identificação, auditoria e versionamento.
• RNF-MAN-04: O sistema deve facilitar a evolução futura sem necessidade de grandes alterações no núcleo principal de organização, agenda, consulta e atendimento.
• RNF-MAN-05: O sistema deve evitar acoplamento indevido entre regras de negócio da aplicação e dados de autenticação gerenciados pelo Keycloak.
• RNF-MAN-06: O sistema deve manter separação clara entre permissões funcionais, controladas pelo Keycloak, e regras contextuais de domínio, controladas pelo backend e pelo banco do Medflow.
• RNF-MAN-07: O sistema deve permitir atualização do software sem perda dos dados já persistidos.
• RNF-MAN-08: O sistema deve permitir versionamento da configuração de segurança e autorização do Keycloak por meio de exportação do realm.

9. Integração

• RNF-INT-01: O sistema deve integrar-se ao Keycloak para autenticação, controle de sessão, obtenção da identidade dos usuários e autorização funcional.
• RNF-INT-02: O sistema deve manter em sua base apenas a referência ao usuário autenticado, por meio do identificador fornecido pelo Keycloak.
• RNF-INT-03: O sistema deve disponibilizar APIs REST para comunicação com o frontend.
• RNF-INT-04: O sistema deve utilizar JSON como formato padrão de troca de dados entre cliente e servidor.
• RNF-INT-05: O sistema deve permitir que o backend utilize integração administrativa com o Keycloak para criação, ativação, desativação e alteração de papéis de usuários, conforme permissões da organização.
• RNF-INT-06: O sistema deve permitir evolução futura para integração com serviços externos, como notificações, armazenamento de arquivos, convênios ou sistemas laboratoriais, sem que esses recursos façam parte do escopo inicial.
• RNF-INT-07: O sistema deve utilizar o identificador sub do Keycloak como referência principal para vincular a identidade externa ao usuário interno da aplicação.

10. Confiabilidade

• RNF-CONF-01: O sistema deve garantir consistência dos dados em operações críticas, como criação de consulta, cancelamento, reagendamento, check-in e registro de atendimento.
• RNF-CONF-02: O sistema deve utilizar transações nas operações que envolvem múltiplas entidades relacionadas.
• RNF-CONF-03: O sistema deve impedir agendamentos duplicados ou conflitantes para o mesmo médico, consultório e horário.
• RNF-CONF-04: O sistema deve preservar o histórico das alterações relevantes por meio dos recursos de auditoria e versionamento.
• RNF-CONF-05: O sistema deve validar dados obrigatórios antes da persistência, reduzindo inconsistências em cadastros, agendas, consultas e registros de atendimento.
• RNF-CONF-06: O sistema deve diferenciar exclusão física, desativação lógica e alteração de status de fluxo, preservando histórico e integridade referencial das entidades principais.
• RNF-CONF-07: O sistema deve garantir que consultas não sejam removidas fisicamente, utilizando status de fluxo para representar estados como cancelada, finalizada ou não compareceu.