Mudanças entre as edições de "Arquitetura do Sistema - Requisitos Não Funcionais"

De Redome
Ir para: navegação, pesquisa
(Criou página com 'Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profu...')
 
 
Linha 1: Linha 1:
 +
[[Arquitetura|'''Voltar''']]
 +
<br/><br/>
 
Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profundo efeito na forma como o sistema é aceito pelos usuários e pessoas que dão suporte ao sistema.
 
Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profundo efeito na forma como o sistema é aceito pelos usuários e pessoas que dão suporte ao sistema.
  

Edição atual tal como às 16h48min de 4 de maio de 2021

Voltar

Os Requerimentos não funcionais remetem a aspectos que, embora não afetem diretamente as funcionalidades do sistema sob a ótica de negócio dos usuários, pode ter um profundo efeito na forma como o sistema é aceito pelos usuários e pessoas que dão suporte ao sistema.

Em outras palavras, os requisitos não funcionais são aqueles que declaram restrições e se relacionam aos padrões de qualidade e definem se o sistema será eficiente e adequado para a tarefa que se propõe a fazer. Ao contrário dos requisitos funcionais, não determinam as funções a serem realizadas pelos sistemas de software, mas os comportamentos e restrições que ele deve satisfazer.

A seguir apresentamos os requisitos não funcionais definidos para o sistema em questão, bem como, as diretrizes para satisfazer esses requisitos.

Requisito Não-Funcional Diretrizes
RNF001 O acesso à informação dos doadores e pacientes no sistema, bem como a transmissão destas informações para outros sistemas deve ser permitido somente a usuários autorizados. Tais informações devem ser protegidas contra modificação ou destruição acidental.
  • O controle de acesso ao sistema será baseado em papéis que determinará os privilégios de cada usuário.
  • As ações sobre as informações de paciente e doadores tomadas pelo usuário para modificá-las serão registradas em um log de auditoria.
RNF002 Todo o processo de envio, reenvio e recebimento de arquivos no sistema deverá ser logado.
  • Os logs serão gravados em arquivo texto, no sistema de arquivos onde o sistema está hospedada.
RNF003 A interface gráfica do usuário do sistema deverá ser apresentada nos idiomas Português Brasileiro, Inglês e Espanhol.
  • Será utilizado um mecanismo de internacionalização (i18N) e Localização (l10N) que possibilite o compartilhamento destes conteúdos entre essas camadas do sistema.
  • Para camada de apresentação: atributos i18n e TranslationProvider.
  • Para camada de aplicação e acesso a dados: MessageSources do Spring MVC.