Desenvolvimento de Software: O Conceito de Requisitos Inversos

AGRADEÇA AO AUTOR COMPARTILHE!

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?

conceito-requisitos-desenvolvimento-software

Imagem via Shutterstock

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 RNRegra 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

AGRADEÇA AO AUTOR COMPARTILHE!

André Luis Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Analista Implementador Delphi em Florianópolis.


2 Comentários

Wilkner
1

Eu considero o conceito de ‘requisitos inversos’ como algo analisado, mas que não estará no escopo de desenvolvimento da funcionalidade. Ou seja, sabe-se que existe determinado comportamento para uma situação, porém, estará evidenciado que não será desenvolvida para o ponto em questão.

Trato a informação do que não estará incluso no escopo de desenvolvimento na parte inicial do documento para facilitar a leitura e não obrigar o leitor a ter interrupções de entendimento no decorrer do texto. Tem funcionado, pelo menos no meu cenário profissional atual.

Artigo muito bem redigido e de fácil entendimento, parabéns por compartilhar seus conhecimentos, André!

Abs,
Wilkner

André Luis Celestino Autor do Post
2

Olá, Wilkner. Obrigado pelo feedback e por deixar o comentário!

O seu ponto de vista sobre requisitos inversos é digno de um profissional na área. A técnica de tratar informações fora do escopo de desenvolvimento realmente é bastante adequada para evitar falhas nas funcionalidades do software, além de trazer objetividade na documentação.

Grande abraço!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">