Profissionais TI - Pra quem respira informação

Olá, pessoal!

Há algum tempo, publiquei no Profissionais TI um artigo sobre a importância dos requisitos não-funcionais em um software e também comentei brevemente sobre os requisitos funcionais. Além destas duas categorias de requisitos, existe também uma vertente conhecida como requisitos inversos.

Já ouviram falar?

Requisitos inversos? O que são?

Já sabemos que, grosso modo, os requisitos funcionais se referem aos requisitos levantados junto ao cliente, e os requisitos não funcionais envolvem as características técnicas do software, certo?

Pois bem, os requisitos inversos, por sua vez, são simplesmente relacionados com as condições que não devem ocorrer no software. Na prática, os requisitos inversos são o oposto dos requisitos funcionais. Além dessa definição, os requisitos inversos também dizem respeito ao que o software não deve realizar fora de seus limites de escopo, tecnicamente conhecidos como “fronteira”.

Fronteira?

Sim. Neste contexto, fronteira é o termo utilizado para designar a dimensão do software e a abrangência de operações que ele pode realizar. Por exemplo, considere que a sua empresa esteja desenvolvendo um software para gestão de vendas, e que os dados dessas vendas também devem estar armazenados na nuvem para que os vendedores da empresa possam acessá-los em seus tablets. Porém, o sistema utilizado nos tablets já está desenvolvido e, portanto, podemos afirmar que ele não faz parte da fronteira do seu sistema. A forma como os vendedores acessam os dados das vendas, emitem relatórios e geram novos pedidos não contempla o escopo da aplicação que você está desenvolvendo.

Você poderia citar alguns exemplos de requisitos inversos?

Claro! Mas antes dos exemplos, é interessante comentar sobre as nomenclaturas normalmente utilizadas em documentações de software para indicar o tipo de requisito:

• RF – Requisito Funcional (ou RN – Regra de Negócio)
• RNF – Requisito Não-Funcional
• RI – Requisito Inverso

Geralmente, essas nomenclaturas são acompanhadas de um número sequencial para identificar cada requisito do software. Lógico, nada impede que cada empresa defina seus próprios padrões de nomenclatura para melhor compreensão, portanto, as nomenclaturas acima não são uma regra.
Partindo dessas definições, poderíamos declarar os seguintes requisitos inversos:

• [RI-10] O sistema não deve ser acessado pela internet
• [RI-16] O backup não pode ser executado durante a sincronização de dados
• [RI-25] O sistema não deve permitir vendas com datas retroativas
• [RI-32] Exceções do WebService não devem ser gravadas no log de erros principal
• [RI-39] O sistema não deve processar escrita fiscal, apenas a exportação

Observe que todas as frases acima contém a palavra “não”. Essa é uma caraterística comum dos requisitos inversos, uma vez que tratam de situações que devem ser evitadas pelo software.

Embora alguns requisitos inversos sejam relativamente óbvios (como o RI-16, sobre o backup), é importante documentá-los para evitar a falta de cobertura nas especificações ou servir como base de conhecimento para analistas, desenvolvedores e projetistas da empresa.

Vale lembrar que não é recomendado abusar na especificação de requisitos inversos. A maioria dos requisitos devidamente atribuídos como funcionais já vão de encontro com as condições que não devem ocorrer no software. Portanto, especificar os requisitos inversos, neste caso, causaria uma redundância de informações.
Para exemplificar a afirmação acima, observe os requisitos funcional e inverso abaixo:

• [RF-48] O CNPJ é campo obrigatório e deve ser validado
• [RI-36] O CNPJ não pode ser nulo

O requisito funcional, por informar que o campo CNPJ é obrigatório, logicamente já induz o ideia de que o campo não pode ser nulo. Além disso, corre-se o risco do requisito funcional não condizer com o requisito inverso, resultando em um conflito na especificação. É preciso ficar atento à essas similaridades para não causar equívocos ou criar documentos muito extensos.

Obrigado pela atenção, leitores.
Um grande abraço!

Publicado originalmente no blog SubRotina