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: */
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.
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:
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 quanto menos, melhor.
Grande abraço!