Exemplos de Requisitos Não Funcionais

Após a publicação do post O que é um Requisito Não Funcional vários leitores solicitaram exemplos de Requisitos Não Funcionais especificados. Sem dúvida que ver a especificação produzida ajuda muito a entender o que deve ser feito.

Neste post temos um exemplos de Requisitos Não Funcionais para cada uma das categorias existentes para este tipo de requisito. Observem o nível de detalhe de cada requisito especificado, isso é um dos fatores mais importante neste trabalho.

Desempenho

Identificador RNF001 Categoria Desempenho
Nome Tempo limite para processamento de todos os lotes de fatura na rotina diária
Data de criação 18/01/2016 Autor Alexandre de Afrodísias
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição No módulo de faturamento, o processamento de faturas em lote é um processo oneroso em termos de memória e CPU, devido ao alto volume de dados. Em função desta realidade, o sistema deverá prover recursos para processamento paralelo (multithreading) que possibilite processar lotes de faturas de forma paralela, compactando o tempo de execução da rotina diária.

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.

Disponibilidade

Identificador RNF002 Categoria Disponibilidade
Nome Utilização do módulo de Informações Cadastrais em modo off-line
Data de criação 25/01/2015 Autor Aristarco de Samos
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Importante
Descrição O módulo de informações cadastrais é um módulo do CRM que precisa funcionar 24 x 7 (vinte e quatro horas por dia, sete dias por semana) na operação do Call Center da empresa. Por isso é necessário que o sistema possua recursos para sua utilização em modo “off-line”, pois em nossa infraestrutura não é possível ter garantia de 100% de disponibilidade do servidor de banco de dados. Para informação, a garantia atual é de 89% de disponibilidade do ambiente.

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.

Exemplos de Requisitos Não Funcionais - eBook sobre Requisitos de Software

Segurança

Identificador RNF003 Categoria Segurança
Nome Autenticação de usuário para consumo de webservices do sistema por sistemas externos
Data de criação 30/01/2016 Autor André Comte Sponville
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição Todas as APIs do sistema expostas como webservices poderão ser acessadas por sistemas externos de clientes, fornecedores e parceiros. Este acesso precisa ser seguro, com autenticação em nível do servidor e em nível da aplicação.

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.

Interoperabilidade

Identificador RNF004 Categoria Interoperabilidade
Nome Integração com sistema do Banco Central para envio de informações de transferência internacional de valores
Data de criação 30/01/2016 Autor René Descartes
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição Diariamente, em janela de produção específica, o sistema deverá enviar para o BACEN (Banco Central) as informações do processamento diário (sempre com um dia de atraso, ou D-1) de transferências internacionais de valores realizadas pelo banco.

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.

/* para requisitos não funcionais de integração (categoria Integração) que envolvam layouts de arquivos, estrutura de arquivos xml ou algo do tipo é recomendado que se detalhe a estrutura do arquivo (layout) no requisito, ou que se faça referência a algum documento que contenha os detalhes de tal estrutura. Quando não há esta especificação é muito comum faltar campo, ter campos com tipos errados, validações não passarem etc. e isso sempre gera muitos problemas */

Usabilidade

Identificador RNF005 Categoria Usabilidade
Nome Uso de Design responsivo nas interfaces gráficas
Data de criação 30/01/2016 Autor Diógenes de Apolônia
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Importante
Descrição O sistema de Atendimento a Clientes será construído para rodar em ambiente web. Deverá possui um design responsivo (https://en.wikipedia.org/wiki/Responsive_web_design).

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.

Compatibilidade

Identificador RNF006 Categoria Compatibilidade
Nome Compatibilidade com sistemas operacionais Windows e Linux
Data de criação 30/01/2016 Autor Friedrich Engels
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição O parque da empresa é composto, nas estações de trabalho, por sistemas operacionais Linux e Windows. Para Linux a variante utilizada é o Ubuntu a partir da versão 15.10, para Windows utiliza-se versões a partir do XP (XP, Vista 7 e 8), considerando sempre o service pack mais recente.

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.

Padrão

Identificador RNF007 Categoria Padrão
Nome Divisão arquitetural do sistema em camadas para desacoplamento
Data de criação 30/01/2016 Autor Empédocles
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição O projeto do software deverá ser fortemente orientado a baixo acoplamento e alta coesão, primando pela melhor separação de responsabilidades.

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.

Legal

Identificador RNF008 Categoria Legal
Nome Atendimento à instrução normativa 554 da ANS (Agência Nacional de Saúde)
Data de criação 30/01/2016 Autor Hipócrates
Data da última alteração N/A Autor N/A
Versão 1 Prioridade Essencial
Descrição Para atendimento à instrução normativa 554 da ANS, o módulo de prontuário deverá gravar em todas as suas tabelas as informações de data/hora do atendimento realizado e dados do médico que realizou o atendimento (CRM e nome completo). Estas informações poderão ser solicitadas pela ANS há qualquer momento, sem aviso prévio.

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

Campo Descrição Tipo Obrigatório
DTHRATEND Data e hora em que o médico atualizou o prontuário. Datetime Sim
NMMEDICO Nome do médico que atualizou o prontuário. Varchar(100) Sim
CRMMEDICO CRM do médico que atualizou o prontuário. Varchar(10) Sim

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.

Obrigado pela leitura, espero que tenha sido útil.

Se você quiser tornar-se um Expert em Engenharia de Requisitos e sair na frente no mercado, conheça nosso curso on-line super diferenciado!

Exemplo de Requisitos Não Funcionais - Curso de Engenharia de Requisitos

Abraço!

Requisitos Não Funcionais

  • Pingback: O que é um Requisito Não-Funcional | Até o Momento – Muito conteúdo de qualidade sobre Engenharia de Software()

  • Joines

    Muito bom! Muito bom mesmo! Estão de Parabéns com essa iniciativa!

    • Plínio Ventura

      Oi Joines! Que bom que gostou, muito obrigado pela sua participação!

  • Vitor

    Perfeito! Estava precisando desses exemplos, muito bem feito! Parabéns!!

    • Plínio Ventura

      Oi Vitor! Bacana, obrigado. Espero poder ter lhe ajudado. Abraço!

  • Fernando Alves Miranda

    Muito esclarecedor. Exemplos são necessários para clarear o etendimento. Obrigado!

    • Plínio Ventura

      Oi Fernando! Que bom que lhe ajudou, eu quem agradeço a visita. Abraço!

  • Filipe

    Conheci a pouco o blog e estou gostando muito do conteúdo, as explicações são claras, diretas e muito práticas! Parabéns pela iniciativa de compartilhar e ajudar a todos.

    Uma dúvida sobre o post: No último RNF esta parte:

    “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.”
    Este relatório que esta citado seria um outro Requisito Funcional?
    Muito Obrigado!

    • Plínio Ventura

      Oi Filipe, tudo bem?

      Obrigado, espero que o conteúdo lhe auxilie. Sobre seu comentário, é exatamente isso. Como foi um exemplo, não evidenciei o RF (Requisito Funcional) pertinente ao relatório, que deverá ser realizado por alguma funcionalidade no sistema.

      Mas na “vida real”, havendo um RF associado – por exemplo, RF0098, eu colocaria na descrição deste Requisito Não Funcional algo como: “vide RF0098 onde se define a função de emissão do relatório pertinente”.

      Qualquer dúvida adicional estou à disposição.

      Abraço!

      • Filipe

        Obrigado Plínio!
        Abraço!