A gestão de requisitos é descrita como chave para diversas disciplinas: Engenharia de Software, Arquitetura Corporativa, Maturidade de Processos e Análise de Negócios. Todos tentam implementa-la, mas raros são os casos de êxito.

Muitas organizações por onde passei como consultor ou instrutor sonham com uma gestão de requisitos eficiente e bem estruturada. Vi diversas iniciativas sendo executadas para elaborar templates de artefatos detalhados que fossem capazes de armazenar todas as informações relevantes a uma empreitada e com isso diminuir conflitos entre clientes e fornecedores e evitar o retrabalho.

As principais expectativas das organizações que investem em gerenciamento de requisitos é o alcance desses 4 objetivos:

1.       Garantia de retorno sobre investimentos através de um processo de validação prévia das iniciativas a serem realizadas com objetivos mensuráveis e bem definidos que possam ser perseguidos durante e aferidos ao final dos projetos.

2.       Retenção do conhecimento do negócio em uma base de conhecimento que permita que a equipe cliente não fique dependente dos fornecedores que construíram a solução, nem precise fazer engenharia reversa de código fonte para poder entender quais são as regras de negócio vigentes ou como o fluxo de atividades acontece de fato no processo.

3.       Definição clara do escopo dos projetos gerando acordos inequívocos entre clientes e fornecedores para reduzir o desgaste nas etapas avançadas dos projetos, garantir o cumprimento de prazo e permitir o controle de qualidade.

4.       Análise do impacto de cada mudança sobre os ativos de processos organizacionais atuais, identificando inclusive quais novos ativos precisarão ser criados, quais podem ser reaproveitados e quais precisam ser modificados. Esta análise permite acelerar bastante os projetos de manutenção eliminando o trabalho de reespecificar algo que já existe, apenas sendo necessário descrever as mudanças necessárias em uma nova versão.

Gerenciamento de Requisitos no Guia BABOK

Para alcançar estas expectativas, um conjunto de 5 tarefas é descrito no Guia BABOK® v3 na área de conhecimento “Gerenciamento do Ciclo de Vida dos Requisitos”:

A realização dessas tarefas sobre um repositório centralizado de requisitos, com acesso a todos os envolvidos deveria ser capaz de cumprir as promessas do gerenciamento de requisitos e atender às expectativas descritas anteriormente.

Todavia, a maior parte das organizações que enveredam nesta empreitada tem resultados bem aquém do esperado.

Erros mais comuns

Existe uma tendência a focar todos os esforços da gestão de requisitos na especificação e manutenção de requisitos funcionais e não funcionais em projetos de desenvolvimento ou manutenção de sistemas de TI. Este foco auxilia no alcance de sucesso no objetivo 3 (Definição clara do escopo), mas em geral falha nos outros 3. O motivo está em um entendimento equivocado sobre o que são requisitos e na forma de organizar seus repositórios para a gestão.

Há diferentes formatos de requisitos e estes devem ser mapeados e armazenados de forma diferente. O foco excessivo nos requisitos funcionais e não funcionais, com uma perspectiva exclusiva de TI, deixa indefinido o modelo de negócio, seus processos, definições e regras, que normalmente só existem na cabeça de alguns poucos privilegiados, e muitas vezes há uma inconsistência tremenda sobre o entendimento de cada um.

O modelo padrão para a especificação dos requisitos, normalmente definido em um template, abrange apenas um subconjunto dos tipos e formas de mapeamento de requisitos. Processos de garantia da qualidade obrigam os analistas a documentarem sempre da mesma forma, mesmo que a documentação não agregue nenhum valor. Formas alternativas de documentação são raramente avaliadas.

A forma de trabalho mais comum é pensar na gestão de requisitos apenas considerando o ciclo de vida dos projetos. Mesmo que exista um repositório representando o produto (Em vez de “produto” sua empresa pode usar outro termo como solução de negócio, processo, serviço, capacidade ou sistema. Por favor, generalize.), a cada projeto de evolução neste produto uma nova especificação é gerada contendo apenas as mudanças envolvidas no projeto. Esta especificação é adicionada ao repositório do produto a fim de “reter o conhecimento” agregado. Contudo o resultado deste esforço não é uma documentação completa e atualizada do produto, mas sim uma infinidade de documentações de projetos inútil para o entendimento do todo.

Algumas empresas se propõem a manter uma documentação atualizada dos produtos, mas esta atualização só é realizada nos projetos grandes. Pequenos ajustes ou manutenções evolutivas ficam de fora desta obrigação. Mesmo as mudanças negociadas durante o desenrolar de um projeto não são atualizadas na documentação. Com isso, a documentação fica sempre desatualizada e cai no descrédito.

Dimensões do gerenciamento de requisitos

Para conquistar os diferentes objetivos do gerenciamento de requisitos é essencial classificar os requisitos sobre duas diferentes dimensões:

Dimensão 1: Projeto x Produto

Projetos e Produtos possuem Ciclos de Vida diferentes. Projeto, como você já sabe, é um empreendimento temporário que mobiliza recursos para criar um resultado exclusivo. Este resultado pode ser a criação de um novo produto ou a modificação em um produto já existente. Veja que, um produto sofre evolução a partir de diversos projetos durante o seu ciclo de vida.

Quando um requisito é especificado, ele pode ser feito no contexto de um projeto, ou no contexto de um produto. Veja os exemplos:

No primeiro caso, o verbo incluir indica uma ação que deverá ser realizada uma única vez pela equipe do projeto, durante o tempo de vida do projeto, provavelmente uma melhoria em um produto atual que é algo que faz parte do escopo desta iniciativa.

No segundo caso, o verbo cadastrar refere-se a uma função presente no produto, que é executada por um usuário ou sistema automatizado e que será realizada várias vezes enquanto este produto existir.

O exemplo que usei aqui é bastante simples pois o objetivo disso é ser didático. Poderia dar outros exemplos em outros níveis de requisitos ou utilizando técnicas mais elaboradas de modelagem, mas o importante é que você entenda que há duas formas de se escrever requisitos e as duas são importantes. Uma delas orienta a equipe do projeto a saber o que precisa ser feito. A outra orienta a equipe de operação e retém o conhecimento sobre o produto.

Dimensão 2: Necessidade x Solução

Projetos e Produtos são criados e mantidos para atender necessidades de negócio. Entenda necessidade como um problema a ser resolvido ou uma oportunidade a ser explorada. Uma solução é uma maneira específica de atender a uma ou mais necessidades dentro de um contexto.

Idealmente iniciamos um projeto pelo entendimento das necessidades e, a partir delas, identificamos diferentes alternativas de solução. Em seguida detalhamos aquela solução que melhor atende às necessidades considerando todas as restrições do contexto atual. Eu disse “idealmente” porque (quem tem um pouco de experiência sabe disso) grande parte dos projetos são criados para desenvolver uma solução já pré-definida em algum processo difuso de análise de negócios não documentado e que supostamente já ocorreu “em algum lugar do passado”.

Projetos criados desta forma não descrevem objetivos com ênfase no atendimento de necessidades, mas sim no desenvolvimento de soluções.

Exemplo de objetivo com ênfase na solução: “Criar sistema XPTO”.

Quais foram as necessidades que demandaram este sistema? Ninguém sabe. Ou sabe, mas não está escrito em lugar nenhum. O fato desta informação não estar disponível impede aos envolvidos no projeto de fazer as seguintes perguntas:

–  “Este sistema que estamos desenvolvendo atende às necessidades que o criaram?”

–  “Esta é a melhor forma de atender a estas necessidades?”

No contexto do Gerenciamento de Requisitos, considere que requisitos englobam tanto a representação de necessidades quanto de soluções (design). Ambas podem ser identificadas e mantidas pois ambas podem agregar valor.

A representação das necessidades dá o entendimento do que de fato representa valor aos clientes. Permite avaliar diferentes formas de solução alternativas e identificar oportunidades de melhoria.

A representação da solução permite analisar mais claramente a forma como trabalhamos e entender os detalhes de como serão (ou foram) implementados processos, regras ou sistemas de TI.

Objetivos x Dimensões

Cada requisito pode ser classificado simultaneamente de acordo com as 2 dimensões apresentadas anteriormente. Como cada dimensão possui 2 diferentes visões, um requisito pode ser classificado em um dos 4 quadrantes a seguir:

Quadrantes dos requisitos sob as dimensões

Enquanto os quadrantes I e III descrevem requisitos de forma temporária, para serem consumidos pelo projeto, os quadrantes II e IV descrevem requisitos que serão mantidos e versionados a cada projeto que trata de evoluções do produto.

Enquanto os requisitos dos quadrantes I e II utilizam termos específicos das comunidades de negócio (ou usuários), os dos quadrantes III e IV tendem a utilizar uma linguagem mais voltada a comunidade técnica (ou TI).

Se sua organização está investindo em uma iniciativa para gerenciar requisitos, é importante primeiro definir de quais requisitos estamos falando. Cada quadrante exige formato de especificação e processo de gerenciamento diferenciados. Os requisitos de um quadrante serão lidos e validados por um grupo de stakeholders diferentes dos requisitos de outro quadrante. A rastreabilidade é o recurso que manterá a consistência entre eles. Não existe um formato único que descreva requisitos num único repositório e preencha todas essas dimensões.

E por fim, você se lembra daqueles 4 objetivos que descrevemos no início deste artigo como sendo a grande expectativa com a gestão de requisitos? Pois bem, agora vem a parte bacana: cada quadrante foca em apenas um deles. Veja no quadro a seguir e reflita sobre ele alguns segundos que você irá perceber a relação.

Quadrantes dos objetivos atendidos em cada quadrante

Para alcançar apenas um destes objetivos, não é necessário manter requisitos no formato de outro quadrante que não ao associado ao objetivo desejado.

Conclusão

Requisitos podem ser descritos e geridos de 4 diferentes formas baseadas em 2 diferentes dimensões (Projeto x Produto e Necessidade x Solução). Cada uma dessas formas de especificação e gestão permite o alcance de diferentes objetivos.

Se sua organização tem prioridade em algum destes objetivos em detrimento dos demais, não tenha pudor em focar seus esforços apenas nele e deixar de lado as outras formas de documentação e gestão de requisitos que não irão lhe agregar valor.

Se todos estes objetivos lhe são importantes, você precisará gerenciar requisitos em todos os quadrantes. Mas defina seus processos e estruturas de maneira clara para cobrir todo este escopo e evite misturar requisitos de quadrantes diferentes num mesmo artefato ou repositório.

BA Day 2016

Venha ouvir mais detalhes sobre este e outro assuntos no dia 05/12/2016 no evento organizado pelo IIBA SP onde estarei presente ministrando a palestra “Por que a gestão de requisitos não funcionou?”. (http://iibasp2016.yubi.me/)

por Fabrício Laguna em 16/11/2016