Exemplos de Requisitos Não Funcionais

A média diária de faturas a serem processadas é 80.000. Cada lote contem 500 faturas, totalizando 160 lotes. A janela de produção disponível para o processamento de todos os lotes é de 4h.

Considerando as medidas acima, o sistema deve processar todos os 160 lotes em, no máximo, 4h. Para atender isso, o sistema deverá rodar os lotes na quantidade máxima permitida de trheads, considerando a seguinte especificação do servidor de aplicativos:

– 16 processadores com quatro núcleos cada.
– 64 GB de memória RAM.
– 1 TB de espaço em disco.

Obs.: deve haver no sistema alguma funcionalidade ou arquivo de configuração, onde seja possível o próprio analista da TI parametrizar a quantidade de threads que o sistema deverá rodar. Esta informação não pode ser fixada em código e nem ser de domínio apenas do fornecedor que implementará a solução.

Todos os registros de clientes cadastrados no sistema poderão ser mantidos (alterados/consultados/excluídos) com o sistema off-line e novos registros de clientes (inclusão) poderão ser incluídos também com o sistema off-line. Todos os relatórios do módulo de informações cadastrais também precisarão rodar off-line.

Cada usuário do módulo deverá ter em sua estação de trabalho uma cópia do banco de dados do módulo citado, sempre com a mesma versão do modelo de dados utilizado. Deverá haver uma rotina no banco de dados do sistema (banco hospedado no servidor da aplicação), que a cada operação de inclusão/alteração/exclusão de registros nas tabelas do módulo de informações cadastrais sincronize estas atualizações com as bases de dados locais de cada usuário, para manter a massa de dados na mesma posição.

Sempre que o usuário abrir o sistema uma função deverá verificar se há conectividade com o servidor de banco de dados. Se houver, deverá conectar neste ambiente (servidor), senão, deverá conectar na versão do banco de dados local da aplicação.

O sistema deverá ainda ser preparado para fazer sincronização dos dados incluídos/alterados/excluídos quando no uso do banco de dados local (sistema off-line), e na sincronização de “volta” (banco local para banco no servidor), verificar se mais de um usuário manteve um mesmo registro, e realizar merge para que não haja defasagem/perda de dados.

Para autenticação no nível de servidor, o IP de cada consumidor dos webservices deverá ser cadastrado no servidor web onde o sistema estará hospedado, com acesso para execução de scripts. Há uma política de segurança que revisa a validade destes acessos a cada mês, isso deve ser considerado no tratamento de exceções no contexto deste requisito.

Para autenticação no nível da aplicação, cada consumidor dos webservices deverá possuir um usuário ativo no sistema. A senha do usuário deverá ser gravada/trafegada utilizando-se o algoritmo SHA-3 para criptografia.

O sistema não poderá permitir cache de senha, salvamento de senha ou qualquer outro recurso do tipo. A cada novo acesso, a autenticação deverá se realizada novamente, de maneira integral.

Deverá haver uma política de segurança que assegure que, a cada mês, a senha de cada um dos usuários citados expire e precise ser renovada, e que tenha critérios de complexidade alta de senhas (vide o documento da área de infraestrutura da empresa que tenha detalhes sobre os níveis de complexidade exigidos para cadastro de senhas); tudo isso deve ser considerado no tratamento de exceções no contexto deste requisito.

A integração se dará por envio de arquivo texto, a ser confeccionado conforme layout específico para o arquivo CI03. Os dados do layout para o arquivo citado devem ser obtidos em https://www.bcb.gov.br/?INFOL,

página do site do BACEN que mantém atualizadas as informações sobre o layout do arquivo CI03. O protocolo a ser utilizado para transmissão é o FTP, mas por razões de segurança do BACEN, a porta utilizada nunca é a 21. A conexão é autenticada, com usuário e senha que o BACEN fornece ao banco. Para o sistema transmissor, o usuário e senha não precisam ser criptografados no ato da abertura da conexão FTP com o BACEN.

Deverá haver um recurso no sistema que permita avisar ao administrador do sistema, por e-mail e SMS (sempre ambos), quando a transmissão não for bem sucedida, detalhando qual a causa do insucesso. Este mesmo recurso deve permitir que, após intervenção humana (seja nos dados que populam o arquivo ou nas configurações do sistema), possa ser realizada a retransmissão dos arquivos.

Todo o processo de envio/reenvio do arquivo deverá ser logado. Os logs devem ser gravados em arquivo texto quando o envio for bem sucedido, e quando não for, em arquivo texto e no Event Viewer do servidor de aplicações onde o sistema estará hospedado.

A interface do sistema deverá se comporta adequadamente independente do front-end que será utilizado para acesso – Browser, Smartphone ou Tablet.

Obs.: durante o processo de homologação do sistema serão realizados testes de usabilidade validando este requisito. O não atendimento a este requisito gerará o não pagamento relativo à fração pertinente à funcionalidade que não for homologada, segundo os critérios aqui apresentados.

Para ambos os sistemas são aplicadas rigorosamente as atualizações dos fabricantes, sempre que são liberadas.

O sistema, por se tratar de um aplicativo desktop em arquitetura cliente/servidor, deverá rodar nos sistemas operacionais elencados neste requisito considerando as demais informações aqui descritas. O comportamento deve ser o mesmo, tanto no que se refere às funcionalidades quanto à instalação.

Obs.: para este requisito haverá garantia do fornecedor do sistema para que as releases do aplicativo mantenham retrocompatibilidade com os sistemas operacionais citados. Este garantia vigorará enquanto o contrato de manutenção estiver vigente.

Todo o projeto deverá ser feito utilizando uma arquitetura separada em camadas, onde cada camada conterá apenas os algoritmos relacionados à sua responsabilidade. Abaixo as camadas que deverão ser utilizadas, e suas responsabilidades:

Interface: abrigar lógicas de tela, validação de campos, acionamento de comandos, códigos para design de interface etc. Obs.: Para esta camada deverá ser utilizado o “code behind” de cada tela, não podendo ser criada uma camada “adicional”.

Negócio: abrigar lógicas de negócio, onde será codificado o escopo das regras de negócio associadas aos requisitos funcionais pertinentes à funcionalidade.

Dados: abrigar lógicas de acesso a dados, comandos SQL ou comandos para utilização de mecanismos de persistência utilizado, para o caso de uso de ORM.

Segurança: abrigar lógicas de autenticação, auditoria, manutenção de usuários.

Infraestrutura: abrigar lógicas não relacionadas a interfaces gráficas, regras de negócio, dados ou segurança, mas que poderão ser utilizadas em todas estas camadas. Conterá recursos para gravação de logs, transferência de arquivos, mensagens, envio/recepção de e-mails etc.

Obs.: em nenhuma das camadas serão permitidos métodos com mais de 40 linhas de código.

Para atender este requisito, cada tabela do módulo de prontuário deverá conter as colunas abaixo, com as respectivas especificações:

Deverá ser criado um relatório no módulo correspondente do sistema, onde conterá a informação deste requisito. Este relatório será utilizado numa eventual visita dos fiscais da ANS, ou caso a ANS solicite envio de comprovação do atendimento à norma 554.