Requisitos inversos: o oposto dos funcionais

Alô, leitores! Há algum tempo, publiquei um artigo sobre a importância dos requisitos não-funcionais no desenvolvimento de 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. Isso mesmo! 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 chamados de “fronteira”.

Nesse 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, suponha 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 dizer 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.

Exemplos de requisitos inversos

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:

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:

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 de especificação. É preciso ficar atento à essas similaridades para não causar equívocos ou criar documentos muito extensos.

Fico por aqui, leitores!
Um abraço e até a próxima semana!