O que é Requisito Inverso

Compartilhe!

Talvez tão importante quanto formalizar-se “o que deve ser feito”, é formalizar-se “o que não deve ser feito”.  E quando estamos lidando com escopo de um software, isso é crítico.

Teoricamente (e na prática também, em vários casos), formalizar apenas o que deve ser feito é algo que resolve o problema, pois entende-se, naturalmente, que somente aquilo que está escrito deve ser feito.

O que não está escrito, obviamente, não se aplica, é escopo negativo, ou item que está fora do escopo, não devendo ser feito.

Existem várias formas de lidar com isso, e aqui, apresentamos uma delas, que é a aplicação do conceito de Requisito Inverso.

Requisitos de Software

Na produção de um software, seja em contexto de projetos ou de manutenção, a parte mais sensível deste processo é:

  • Entender realmente o que o cliente quer que seja feito.
  • Transcrever isso de alguma forma inteligível para o cliente e para a equipe técnica.
  • Certificar-se que isso foi bem transcrito.
  • E então materializar o software através de projeto e construção, por exemplo.

Uma forma adotada para lidar com esta situação é através do uso de Engenharia de Requisitos, onde, dentre outras coisas, são produzidos os requisitos de software.

/* Se você quiser entender bem o que são Requisitos de Software, quais os tipos, exemplos etc. você pode baixar nosso eBook abaixo: */

Diagrama de Atividades - eBook sobre Requisitos de Software

O produto da fase de Engenharia de Requisitos é o escopo do software, do ponto de vista funcional (foco nas funcionalidades, sob o ponto de vista do negócio, do usuário/cliente).

Escopo x Escopo Negativo

Em linhas gerais, devemos entender escopo como “aquilo que deve ser feito”.

Sempre costumo dizer que em projetos de software com escopo fechado, talvez o maior contrato “de fato” do projeto seja o escopo definido e especificado.

A boa qualidade da especificação do escopo aumentará muito as chances do projeto ser bem sucedido.

/* Se você refletir verá que a maioria dos problemas encontrados em projetos de software não é de definição técnica, bugs de código, ou defeitos arquiteturais. Na maioria dos casos o problema está em definições incorretas, rasas, ambíguas etc. de “pedaços” do escopo. E como tudo começa no escopo, o que começa errado costuma terminar errado… */

E o que não deve ser feito?

A isso podemos dar vários nomes, mas eu prefiro chamar de Escopo Negativo, que é uma “caixa” onde os itens que não deve ser feitos ficam.

O cliente deve conhecer bem o conteúdo desta caixa, homologá-la e estar ciente que o que está lá dentro, não faz parte do combinado.

Requisito Inverso

Os requisitos de software precisam ser classificados, para que se compreenda melhor o que cada tipo de requisito se propõe a fazer e a partir disso, realizar o processo de especificação.

Por exemplo: restrição de negócio = regra de negócio, restrição técnica de sistema = requisito não funcional, e por aí vai.

Algumas literaturas pregam o conceito de Requisito Inverso para aquilo que será item do Escopo Negativo, ou seja, que não será feito. É uma alternativa de classificação.

/* Eu particularmente não acho interessante usar explicitamente esta classificação, pois o processo de Engenharia de Requisitos já é complexo por si só, e quanto mais “tipos”, maior a confusão que se gera em torno do processo. */

Isso pode ser feito de inúmeras formas.

Pode-se definir no projeto um requisito funcional, regra de negócio ou requisito não funcional como Requisito Inverso, ou simplesmente, manter seu “tipo original” e incluí-los em Escopo Negativo, para assim, documentar-se que os itens nesta “caixa” não serão feitos.

Exemplificando

Vejamos na imagem abaixo um exemplo de como definir requisitos inversos conforme citei anteriormente.

requisito-inverso-escopo-negativo-engenharia-requisitos

Na imagem não temos uma classificação diferente para os requisitos de software fora de escopo. Possuem a mesma classificação, o mesmo tipo original, mas foram incluídos no projeto em pacote apropriado (Escopo Negativo), deixando claro que estes itens não serão feitos.

Outra forma é classificar os requisitos como Inverso e deixar mais claro no nome do requisito a “negação”, como podemos ver na imagem abaixo:

requisito-inverso-negacao-engenharia-requisitos

Neste exemplo, perceba que alteramos a estrutura do pacote “Requisitos de Software”, e também alteramos o prefixo aplicado na nomenclatura do Requisito (ao invés de RF [Requisito Funcional] usamos RI [Requisito Inverso]).

Qual padrão utilizar?

O melhor padrão sempre será aquele que a cultura da empresa adota e consegue a melhor eficiência e a melhor eficácia na utilização. Ou seja, depende! 🙂

Se houver um processo estabelecido de Engenharia de Requisitos na empresa, as duas opções devem ser avaliadas.

Sugiro que neste tipo de avaliação, a diminuição da complexidade no processo de produção de software sempre seja considerada, pois neste contexto, quanto menos, melhor.

Se quiser tornar-se um especialista em requisitos, nosso curso é uma excelente oportunidade para você!

curso-engenharia-requisitos-desconto-200-reais-vagas

 

Grande abraço!

Engenharia de Software