O que é Requisito Inverso

requisito-inverso-engenharia-de-software-engenharia-de-requisitos

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 de Requisitos- 50% de Desconto

Grande abraço!

Engenharia de Software

 

  • Edson Brasil

    Olá Plinio, bom dia!

    Aqui na empresa, tentamos empregar esta técnica no passado, porém nossa experiência não foi muito boa, talvez por discurso e gostaria de saber o que teve de experiencia neste sentido.

    Sempre que descrevemos o que não fazer no escopo do projeto fui surpreendido pelo cliente, aonde após a entrega o mesmo solicitou alguma ação que não estava descrita nem no escopo nem no fora do escopo, o que gerava grandes discussões entre nós e nossos clientes.

    Já passou por esta situação?

    • Plínio Ventura

      Olá Edson, como vai?

      Já passei por isso, muitas dezenas de vezes, infelizmente… :(

      Vou delongar um pouco, mas entendo ser necessário. Fique à vontade para avançarmos o debate aqui, ok?

      É importante entendermos que antes de falarmos da demanda de “produzir software”, estamos falando de relações comerciais entre pessoas (seja pessoa jurídica, que por trás desta, trata-se de pessoas físicas, ou pessoa física diretamente). Vendo desta forma, é sempre necessário analisar as questões culturais, morais etc. de ambos os lados, pois estes traços ditarão muito da qualidade da relação comercial estabelecida.

      Avançando, ainda antes de falarmos da demanda de “produzir software”, temos um contrato – trabalhar sem contrato neste contexto significa: ou levar grandes prejuízos, ou ter que partir para a imoralidade para sobreviver. Eu não recomendo nem aplicaria nenhuma das duas possibilidades.

      Avançando um pouco mais: considerando o perfil das pessoas envolvidas, o contrato estabelecido, temos ainda o escopo, que como costumo dizer, é o que acaba valendo como “contrato” em projetos de software de escopo fechado. Tomar todos os cuidados nesta parte é fundamental, mas, nem sempre dá certo (não por questões técnicas, ou é problema em contrato mal feito, ou cultura/moral questionáveis de algum dos lados).

      Considerando as observações acima, abaixo seguem alguns comentários meus para reflexão. De repente lhe ajuda a pensar em algo.

      -> Sempre é importante deixar o mais claro possível no contrato como as restrições de escopo serão formalizadas, e como será o tratamento para itens não presentes no escopo, caso o cliente solicite que sejam incluídos. Neste caso, a boa especificação de requisitos é recurso que, ao menos do ponto de vista legal, dará segurança ao fornecedor. Aberturas no contrato para revisão de escopo, e quais regras serão aplicadas para tratar isso, também são obrigatórias em contratos com este perfil.

      -> Conforme o perfil do cliente, risco do contrato, complexidade do software etc. é sempre bom ter margem de segurança. Esta margem deve ser calculada com base no histórico da empresa em relação à desvios de escopo que impactaram as estimativas (prazo/esforço/custo). Ou seja, se a cada projeto o problema de “querer o que não está escrito” gerou um impacto médio de 10% para baixo, então nos novos contratos/estimativas, é pertinente acrescer 10% de margem para mais.

      -> Ceder ou não ceder? Isso é uma avaliação que deve ser feita considerando o perfil do cliente. O bom senso muitas das vezes pode ser aplicado, mas nenhum lado pode sair no prejuízo. Na minha visão, apenas uma relação de ganha-ganha é válida, pois o conceito de vantagem/desvantagem não é algo moral, pois anula a ideia do “justo”. Mas, quando o fornecedor cede muito, o cliente fica mal acostumado, e o contrário também se aplica.

      -> Fazer ou não fazer? Também algo que deve ser considerado. Estratégias de CRM (mais focado no marketing One to One) nos dá condições de saber qual cliente merece mais “concessões”, por gerar mais valor para o fornecedor. Saber dizer não em alguns casos, até mesmo, dependendo do caso, abortar o projeto, pode ser necessário para a saúde financeira do negócio do fornecedor.

      -> Continuar ou não o projeto? Idem ao caso acima. Uma vez um conhecido meu, proprietário de uma empresa de engenharia falida me disse assim: “se nos projetos A, B e C eu tivesse tido coragem, deixado claro para o meu cliente que o projeto estava me gerando prejuízo devido a solicitações feitas por ele e que não estavam no escopo das obras, e feito recisão unilateral, eu não teria quebrado…”.

      Nenhuma teoria resiste fielmente à aplicação prática, entretanto, abandonar a teoria como direcionamento é abrir as portas para o caos.

      Grande abraço!

      • Edson Brasil

        Olá Plínio, bom dia!

        Primeiramente, muito obrigado pelo retorno.

        Quanto ao conteúdo da resposta, acredito que esteja bem aderente as ações que tivemos no passado quando encontramos este tipo de situação.

        Abraço

        • Plínio Ventura

          Bacana, Edson! Abraço!