Requisitos e suas constantes mudanças

Um dos grandes desafios dos projetos de TI é gerenciar as mudanças. Aqui, segue uma idéia do que poderia ser um passo inicial para colocar a casa em ordem: Entender e gerenciar requisitos de maneira inteligente, evitando que análises de impacto e mudanças, sejam um martírio para os envolvidos em projetos de TI.

por Roberto Capra Neto

Quando tratamos definições de escopo e requisitos (em outras palavras, o que o cliente quer do projeto), a impressão que temos é de estar adentrando um verdadeiro "campo minado" em que, qualquer passo em falso pode nos levar a atrasos por conta de mudanças constantes. Frases como: "Por que você não pensou nisso antes?" são familiares para vocês?

Vamos começar falando um pouco sobre requisitos. Há diversos autores que ilustram os conceitos com bastante clareza e, mesmo havendo pequenas variações na classificação de tipos de requisitos, é possível encontrar um padrão bastante comum.

Mas afinal o que são requisitos?

Requisitos* são necessidades básicas do cliente, geralmente explicitadas como condição de negócio no contrato com o fornecedor. São características, tais como especificações técnicas, prazo de entrega, garantia, que o cliente "requer" do produto. Uma condição ou capacidade necessitada por um usuário, para resolver um problema ou alcançar um objetivo.

* fonte: Instituto de Desenvolvimento Gerencial

Não é o objetivo deste artigo explanar sobre os tipos de requisitos, (de negócio, funcionais, não funcionais, etc.) pois há um material bastante extenso na Web sobre o assunto. O fato é que muitos entendem (e defendem com razão) que uma definição correta de requisitos pode auxiliar questões relacionadas a melhoria da comunicação entre o cliente e fornecedor. Requisitos bem especificados, facilitam a comunicação entre as partes, criando um padrão que aumenta a eficiência. Em resumo, todos falam a mesma língua (em se tratando do negócio).

Os requisitos quando bem definidos esclarecem de fato, o que deve ser produzido, minimizando erros de especificação, que podem ser detectados antes do produto final acabado. Há diversos estudos que comprovando que o custo da correção de erros após a base do produto ter sido construída é muito maior.

Mas então, basta entender o que o cliente quer e traduzir a necessidade em requisitos bem definidos?

Não é só isso. Além de defini-los, ainda é preciso gerenciá-los. E a palavra-chave que define a razão de ser da atividade de gerenciamento de requisitos é uma só: mudança. Requisitos bem definidos e gerenciados ajudam a controlar mudanças que podem (sempre?) ocorrer ao longo do projeto.

Ao analisar os requisitos (gerenciados), encontramos uma das principais fontes para avaliações de custo e analises de impacto de mudanças de escopo. Por isso o gerenciamento de requisitos tem se tornado uma atividade fundamental ajudando a garantir que, mapear mudanças constantes, não seja um martírio para os envolvidos em projetos de TI.

Através do Gerenciamento dos Requisitos é possível localizar corretamente as mudanças que afetam os requisitos e analisar seu impacto através da relação entre eles, e entre outros elementos da solução. Em outras palavras, a rastreabilidade torna-se possível. Difícil de implementar? Nem tanto quanto parece.

E então, do que precisamos quando fazemos isso na prática?

1. Primeiramente, cada necessidade específica (traduzida em requisitos) deve ter uma identificação única (Familiar, não?)

2. Deve ser possível rastrear os requisitos e sua implementação, para ser possível saber quais os produtos de trabalho fazem referência (afetam) cada requisito.

3. Relacionar os requisitos entre si, para prever possíveis impactos entre eles (essa é uma excelente prática)

4. É muito comum a utilização de matrizes, que ajudam a documentar a rastreabilidade entre os requisitos.

Já adianto aos leitores que isso não é tudo, mas é um bom começo.

Você talvez esteja se perguntando: "Para que tudo isso?".

Particularmente, não gosto de responder uma pergunta com outra, mas neste caso, abrirei uma exceção: Você nunca quis saber verdadeiramente "o que afeta quem", ou "quem afeta o que" quando seu cliente solicita uma mudança? Hoje, na área de TI de sua empresa, será que você sabe?

Gerenciar os requisitos pode ser uma resposta inicial para que você comece a descobrir.

Em conjunto com os conceitos aplicados nos processos, sempre temos as ferramentas. É sempre bom lembrar que elas nos ajudam, desde que se tenha em mente o que realmente se pretende com sua adoção. Em minha trajetória profissional já observei diversos casos de empresas que adotaram ferramentas sem disseminar conceitos ou ainda, sem processos bem definidos, e fatalmente não conseguiram atingir o objetivo esperado. Ao adotar a estratégia de utilizar uma ferramenta de requisitos, a coisa não é diferente.

E mais uma vez, uma área de processo do modelo CMMI (Capability Maturity Model Integration) do SEI (Software Engineering Institute), nos auxilia a entender como compor um bom processo de gerenciamento de requisitos. Ao estudarmos REQM (Requirements Management ou simplesmente Gerenciamento de Requisitos), temos um conjunto detalhado das melhores práticas para implementar tais procedimentos em um processo. Novamente ressalto que ao ler o modelo, não nos é dito como fazer, mas sim diretrizes para seguir as melhores práticas de quem já aplicou com sucesso esse tipo de controle.

Aqui, alguns links que podem ajudar quem quiser saber mais sobre o assunto:

Sobre Requisitos

http://www.borland.com/us/solutions/requirements-definition-management/index.html

Ferramentas

http://www.borland.com/us/products/caliber/rm.html

http://www-111.ibm.com/ecatalog/Detail.wss?locale=pt_BR&synkey=U107428M40511T21

Grande abraço a todos.

Roberto Capra Neto