Os Cinco Níveis de Maturidade na Gestão de Requisitos

Ter maturidade significa ser capaz de ver o contexto e efectuar boas escolhas. No âmbito de uma empresa, significa basear as decisões numa compreensão clara dos custos e dos benefícios inerentes à decisão de fazer uma coisa em detrimento de outra. Este artigo fala das decisões tomadas nas organizações e daquilo que fazem à medida que sobem na escala de maturidade da gestão de requisitos (RMM - Requirements Management Maturity).

Tal como a subida de uma montanha tem um custo (em energia e tempo), o mesmo se aplica à subida na escala RMM. Consequentemente, quando olharmos mais adiante para as vantagens de alcançar níveis de maturidade mais elevados, não ignoraremos o investimento que é necessário em termos de tempo, esforço e dinheiro. Além disso, analisaremos a forma como as ferramentas de automatização da gestão de requisitos (RM - Requirements Management) poderão ajudar as organizações a alcançar níveis de maturidade mais elevados em termos de RM.

Os leitores familiarizados com o CMM (Capability Maturity Model) do Software Engineering Institute (SEI) irão notar algumas semelhanças com o nosso modelo paralelo, apesar deste último não ter qualquer relação directa com o CMM, excepto uma: o alcance do Nível Cinco do RMM ajudará garantidamente as organizações a alcançar, pelo menos, o Nível Três do CMM. Evidentemente, é importante ter consciência de que é mais fácil atingir um nível mais elevado de maturidade numa única área - como a gestão de requisitos - do que fazer subir toda a organização no processo de maturidade.

Os cinco níveis de maturidade do nosso RMM são:

1. Escrito
2. Organizado
3. Estruturado
4. Acompanhado
5. Integrado

Iremos utilizar estas categorias para segmentar as práticas de gestão de requisitos, começando pelo nível mais baixo (Um) e subindo até ao Nível Cinco.

Caos: não há requisitos

Na realidade, além dos cinco níveis da escala de maturidade da gestão de requisitos referidos atrás, existe mais um: o Nível Zero. Neste nível, as organizações têm uma ideia geral daquilo que fazem e acham que o tempo que poupam por não inventariarem devidamente os requisitos não se voltará mais tarde contra elas por disponibilizarem demasiado ou muito pouco aos seus clientes.

Por vezes, este jogo resulta bem, mas o mais frequente é ter consequências nefastas: são disponibilizados produtos com lacunas em termos de funcionalidades, com funções que não são necessárias, ou com baixa qualidade. Estes problemas têm vários graus de impacto, dependendo dos clientes ou do tipo de software (se é mais ou menos crítico). Se as consequências forem suficientemente graves, poderão "obrigar" as organizações a preocuparem-se com a questão dos requisitos e a criarem um processo de RM.

Nível um: requisitos escritos

O primeiro passo para ficar acima do caos da inexistência de requisitos resume-se simplesmente à redacção dos requisitos. As anotações não contam. Também não consideramos como escrita de requisitos a utilização de meios de anotação que não possam ser objecto de back-up e não apresentem a possibilidade de restauração da informação, uma vez que o risco envolvido é elevado.

Quando se começam a escrever os requisitos, tornam-se óbvias várias vantagens. Em primeiro lugar, temos uma base real para o contrato com os clientes. Se escrevermos bem os requisitos, estes podem moldar claramente a compreensão daquilo que os clientes querem que seja construído. Além disso, os clientes podem ler esses requisitos e concordar (ou não) com eles.

Em segundo lugar, toda a gente da nossa equipa de desenvolvimento tem uma base para realizar o seu trabalho. Estão aqui incluídos, obviamente, os arquitectos e os modeladores, que poderão começar a pensar na forma como arquitectar o sistema de forma a responder às expectativas dos clientes. Os especialistas de teste também podem começar a escrever casos de teste atempadamente, onde irão basear mais tarde os procedimentos e scripts de teste.

Em terceiro lugar, à medida que a equipa vai avançando com o projecto, terá uma fonte de referência para determinar aquilo que a aplicação ou o sistema devem fazer. Isto também é válido para os novos membros que possam entrar numa determinada fase do projecto. Como os requisitos estão escritos, podem ser guardados e restaurados sempre que necessário. Desta forma, deu-se um grande passo para reduzir os riscos.

E a questão dos custos? Alguém - ou mesmo uma equipa - terá que gastar tempo a efectuar o trabalho de escrita dos requisitos. Se não for a equipa sozinha a estabelecer os requisitos, será necessário falar com os clientes para identificar aquilo que querem. A manutenção também envolve custos e tempo. Se não forem actualizados, os requisitos acabarão por se tornar inúteis. Por outro lado, quem quer que seja responsável pela manutenção, tem que aprender e implementar alguma "ferramenta" para levar a cabo a escrita, mesmo que seja simplesmente o Word ou o Notepad.

Valerá a pena o tempo e o esforço? Para responder a esta questão temos que considerar o custo das potenciais consequências em que se incorre quando não se escrevem os requisitos. O que acontecerá se não construírmos e não disponibilizarmos aquilo que os clientes pretendem? O que acontecerá se disponibilizarmos mais do que o pretendido pelos clientes? Se a resposta disser que não acontecerá grande coisa, então não haverá grandes problemas em descorar a questão dos requisitos. No entanto, se a disponibilização de um sistema inadequado provocar grandes quebras no preço das acções da empresa, ou provocar a insatisfação dos clientes, talvez já valha a pena realizar o investimento.

Nível dois: organizado

Neste nível, as organizações lidam com coisas como a qualidade dos requisitos, o seu formato, segurança, onde são armazenados e como efectuar o acompanhamento das diferentes versões. O objectivo de um requisito é comunicar de forma clara o comportamento proposto do software a um conjunto diverso de intervenientes: utilizadores, clientes e outros stakeholders, bem como à equipa de desenvolvimento.

Não se pense que o alcance deste objectivo é fácil. Na realidade, é difícil de atingir. Um bom conjunto de requisitos conseguirá atingir o objectivo referido no parágrafo anterior. Um mau conjunto de requisitos não. Os bons requisitos são compreensíveis para os stakeholders que os especificam, além de serem utilizáveis pelos arquitectos, especialistas em desenvolvimento e especialistas de teste. No entanto, para conseguirem isto terão que ser legíveis, não poderão ser ambíguos e terão que ser testáveis.

Formatação

Os requisitos também têm que ser formatados de forma adequada. A utilização consistente de esquemas de numeração, de títulos e de fontes, assim como um bom índice, farão com que os documentos sejam mais fáceis de ler, compreender e utilizar. Mesmo um requisito bem escrito, pode tornar-se inútil se estiver mal formatado. A formatação é uma tarefa simples, mas é frequentemente esquecida devido à pressa em ter os requisitos "prontos". Os modelos de documentos (templates) podem ajudar no trabalho de formatação, o mesmo acontecendo com o recurso a padrões simples de formatação para os documentos de requisitos.

Acessibilidade, segurança e controlo visual

Já alguma vez ficou frustrado(a) por não encontrar um documento de requisitos? No Nível Dois precisamos de um local central e bem conhecido para os requisitos. Um local que seja acessível a todos os utilizadores. Também é necessário pensar nas questões de segurança. Independentemente de utilizarmos a simples segurança do sistema de ficheiros, ou técnicas mais sofisticadas, a limitação da possibilidade de pessoas não autorizadas modificarem os requisitos ajudará a garantir a integridade dos mesmos.

A instituição do controlo de versões para os requisitos é outra medida que poderá traduzir-se em poupanças de tempo e menos frustrações, uma vez que garantirá que as pessoas saberão sempre se estão a trabalhar ou não com base na versão mais recente das especificações. Além disso, saberão sempre quem efectuou cada alteração e porquê.

Mas estes não são os únicos benefícios de se estar no Nível Dois. Também temos que lhe adicionar automaticamente as vantagens do Nível Um. Quando os requisitos são mais fáceis de ler e de compreender (e mais fiáveis), tem-se uma melhor base para o contrato com o cliente, Além de que a equipa de desenvolvimento achará os requisitos mais fáceis de utilizar e os eventuais novos elementos da equipa (entrados numa determinada fase do ciclo de vida do projecto) atingirão mais rapidamente níveis elevados de produtividade.

Os custos associados ao alcance do Nível Dois têm a ver sobretudo com a formação e a análise. A escrita de requisitos de qualidade não é uma tarefa simples. A não ser que uma organização tenha a sorte de já ter analistas experientes nos seus quadros, será necessário ministrar formação à equipa. Para atingirem e se manterem num dado nível de maturidade, as empresas também precisarão de uma análise consistente dos documentos de requisitos e de algum nível de "melhoria de processos".

Evidentemente, estes custos são contrabalançados pelas vantagens óbvias inerentes à garantia de que os requisitos são adequados: menos trabalho repetido e melhor aceitação por parte do cliente, para referir apenas duas. Se tivermos que fazer as coisas certas à primeira, provavelmente valerá a pena incorrer nestes custos.

Nível três: estruturado

Para se chegar ao nível três é necessário começar a ser mais específico quanto aos "tipos" de requisitos identificados. São funcionais ou não funcionais? De negócio ou de sistema? São características ou requisitos de software? São requisitos de cliente, de marketing ou de utilizador? O estabelecimento destas diferenças ajuda-nos a obter uma melhor compreensão dos requisitos e a geri-los melhor.

O nível três também implica a adição de informação sobre os requisitos, para além do texto base. Podemos fornecer esta informação adicional sob a forma de "atributos", o que nos ajudará a dar um grande passo em frente a nível da gestão e reporting dos requisitos.

Tipos de requisitos adequados

Quando pensamos em muitos tipos possíveis de requisitos, devemos considerar duas questões importantes. A primeira tem a ver com o facto de não distinguirmos os diferentes tipos de requisitos. Se a nossa especificação de requisitos tiver apenas uma lista de requisitos, sem qualquer indicação do seu tipo, o mais provável é que contenha diferentes tipos. Por exemplo, um requisito pode ser o seguinte: "o help desk do fornecedor deve responder a 90 por cento de todos os recibos de problemas no prazo de quatro horas". Outro pode dizer que "o sistema deve suportar a verificação automática dos pré-requisitos".

Apesar de ambos serem requisitos válidos, estão direccionados claramente para áreas de preocupação diferentes. O primeiro é um requisito para o sector de suporte da empresa que fornece o software, enquanto que o segundo é uma especificação para aquilo que o software tem de fazer. Sem a indicação do tipo, uma longa lista de requisitos poderá provocar confusão e desperdícios de tempo para quem a lê. As pessoas que procuram requisitos de software serão distraídos pelos requisitos de suporte e vice-versa. Também será difícil efectuar um relatório para mostrar, por exemplo, todos os requisitos de software.

A segunda questão tem a ver com a existência de tipos de requisitos, mas sem qualquer acordo sobre aquilo que significam. Um exercício interessante nestes casos consiste em perguntar aos membros da equipa quem tem de utilizar os requisitos para escrever definições para os vários tipos de requisitos. Normalmente ficamos surpreendidos com a variedade de interpretações. Existirá claramente um problema se uma pessoa definir um "requisito de utilizador" como "uma necessidade de negócio que o utilizador final acha que o futuro sistema tem de cumprir para poder realizar o seu trabalho" e outra pessoa o definir como "um requisito para a experiência de utilizador".

Atributos

Consideremos agora o conceito de atributos de requisitos - outra capacidade do Nível Três. Nem todos os requisitos são iguais. Alguns são mais importantes do que outros. Alguns são mais estáveis do que outros. Alguns poderão destinar-se a uma versão e outros a outra. Estes são aspectos importantes que é necessário acompanhar. A adição de atributos aos requisitos pode ajudar nesse acompanhamento. Os atributos incluem informação que complementa o texto dos requisitos e nos ajuda a compreender e a gerir melhor os requisitos.

Mas como é que sabemos qual a informação de atributos que é necessária? Depende das necessidades daqueles que irão utilizar a informação dos requisitos. Um erro comum consiste em utilizar às cegas um conjunto predefinido de atributos de outro projecto ou ferramenta de requisitos (como aquele que vem com o Rational RequisitePro, por exemplo). As templates de projecto são óptimas como ponto de partida, mas o mais provável é que tenhamos de modificar a template para responder às nossas necessidades. Caso contrário, podemos acabar sobrecarregados com atributos que não precisamos e omitir muitos daqueles que seriam necessários.

No caso de grandes projectos, que dispersem os requisitos por vários analistas, será muito útil um atributo "proprietário" (ou dono). No entanto, um atributo deste tipo poderá já não fazer sentido em projectos pequenos, onde apenas uma pessoa é "proprietária" de todos os requisitos. Precisamos de compreender como é que os requisitos irão ser utilizados para podermos identificar os atributos necessários. Que relatórios e consultas (queries) precisamos de suportar? Que métricas precisamos de manter? A resposta a estas questões irá ajudar-nos a começar com o pé direito.

As vantagens de estar no Nível Três têm a ver com uma melhor compreensão e com uma gestão mais fácil. Os requisitos bem estruturados identificam claramente diferentes tipos de requisitos. Por sua vez, os atributos fornecem a possibilidade de consultar e filtrar grupos de requisitos. Isto significa que os membros da equipa têm que realizar muito menos trabalho de "detective" e de "adivinhação" para identificarem as suas responsabilidades e tarefas. Uma melhor distribuição dos requisitos por tipos também proporcionará maiores garantias de que a equipa identificou todos os requisitos importantes.

O principal custo para chegar ao Nível Três reside no planeamento e na manutenção. A determinação dos tipos de requisitos e dos atributos apropriados não é uma tarefa trivial. Mesmo um mini-projecto, envolve o diálogo com os utilizadores dos requisitos para determinar aquilo que eles precisam. Normalmente, esta informação é recolhida num Requirements Management Plan (RMP).

Por outro lado, os atributos de requisitos serão de pouco uso se não forem mantidos actualizados. Desta forma, existe um trabalho de manutenção que vai mais longe do que o realizado para o Nível Dois. O custo também será superior, uma vez que demora algum tempo a determinar o valor correcto do atributo. Frequentemente, quando as organizações chegam ao Nível Três, instituem a utilização de uma ferramenta de gestão de requisitos. Estas ferramentas têm grandes vantagens e justificam frequentemente o custo da sua aquisição, actualização e administração do software.

Nível quatro: acompanhado

A implementação dos três níveis anteriores conduz-nos a uma situação em que podemos determinar e acompanhar as relações entre requisitos. A maior parte dos sistemas com alguma complexidade significativa contam com uma hierarquia de requisitos. Num ambiente de engenharia de sistemas, essa hierarquia começa com os requisitos de sistema e vai descendo para os requisitos de subsistema, requisitos de programa e requisitos de elemento.

No Rational Unified Process (RUP), a hierarquia começa com as necessidades de utilizador, continua com as características e segue depois para os casos de utilização. A capacidade de acompanhar estas relações é normalmente designada por traceability e envolve a identificação e a documentação do caminho de derivação (ascendente), bem como do caminho de alocação (descendente) dos requisitos na hierarquia. Esta capacidade de acompanhamento permite compreender como é que as alterações de um requisito podem afectar os restantes (análise de impacto) e poderá ajudar-nos a determinar se os nossos requisitos estão completos (análise de cobertura).

Normalmente, uma organização que esteja no Nível Quatro desenvolve uma estratégia explícita de acompanhamento antes de iniciar um projecto e documenta-a depois no plano de gestão de requisitos. Essa estratégia define os níveis de requisitos e como é que se encaixam na hierarquia. Adicionalmente, estabelece algumas "regras" para as relações entre requisitos. Por exemplo, uma regra pode dizer que para todas as "necessidades de utilizadores" deverá haver pelo menos uma "característica" e para cada característica deverá haver pelo menos um caso de utilização. A implementação de um processo de gestão de requisitos como este permite relatórios sofisticados.

Os relatórios de análise de cobertura mostram se cada requisito de alto nível tem um requisito de mais baixo nível associado a ele. Isto ajuda-nos a determinar se temos algumas brechas por cobrir. Por exemplo, se tivermos uma característica que não tem um caso de utilização associado, o software resultante poderá apresentar alguma falha em termos de funcionalidade. Ou então, se tivermos um caso de utilização sem característica associada, talvez estejamos a implementar funcionalidades sem qualquer valor de negócio.

Os relatórios de análise de impacto destinam-se principalmente à gestão das alterações. Mostram claramente como é que uma alteração a um requisito irá repercutir-se nos outros, o que faz com que seja muito mais fácil justificar ou resistir às alterações. Por exemplo, se alguém quiser alterar uma característica e um relatório de impacto mostrar que isso irá provocar alterações em vários casos de utilização (e provocar atrasos face à calendarização estabelecida do projecto), será mais fácil pesar os custos e as vantagens de tal alteração.

As vantagens do acompanhamento dos requisitos são significativas mas, mais uma vez, têm custos associados. O trabalho envolvido na introdução e manutenção das relações não é propriamente trivial. A definição, organização e análise dos relatórios de cobertura e de impacto exigem tempo e esforço. Nos projectos de pequena dimensão, o acompanhamento dos requisitos pode ser efectuado manualmente, através de simples tabelas Word ou Excel. No entanto, nos projectos mais complexos é frequentemente necessário recorrer a ferramentas de gestão de requisitos. As vantagens inerentes à utilização deste tipo de ferramentas são significativas mas, como sublinhámos atrás, existem custos associados à sua compra e manutenção, bem como à formação necessária para trabalhar com elas.

Nível cinco: integrado

Acontece frequentemente utilizarem-se os requisitos para obter o acordo por parte dos clientes sobre aquilo que o software deverá fazer. No entanto, depois disso, esses requisitos não são ligados realmente à forma como o software é desenvolvido. Isto resulta em requisitos desactualizados e em software que não cumpre os seus objectivos. Atingir o Nível Cinco significa integrar o processo de gestão de requisitos com o resto do ambiente de desenvolvimento de software. Isto quer dizer que se utilizam os requisitos directamente no desenho do software, na gestão das alterações, nos testes e na gestão do projecto.

O software que faz aquilo que os clientes esperam é construído em conformidade com os requisitos - ou seja, a equipa do processo de desenvolvimento de software utiliza os requisitos como input chave. Os arquitectos e os modeladores de sistema seguem um processo destinado a assegurar que todos os requisitos são implementados no desenho - o RUP faz isto através do tratamento dos casos de utilização como artefacto de input para a disciplina de análise e desenho.

A integração dos requisitos no processo de gestão das alterações ajuda a garantir que não são efectuadas alterações aos requisitos sem a devida análise e aprovação. Ao relacionarmos cada pedido de alteração a um requisito existente ou novo, estamos a contribuir para limitar os problemas relacionados com as características. Os testes baseados nos requisitos também são uma parte importante para garantir que o software cumpre os seus objectivos. Tal como os modeladores têm de utilizar os requisitos para desenhar o sistema, os especialistas de teste têm de os utilizar para criar casos de teste e outros artefactos de teste.

Uma vez que os requisitos são a base para todo o processo de desenvolvimento, os gestores de projecto deverão ter acesso directo a um estado do projecto relativamente aos requisitos. Isto inclui métricas sobre novos requisitos, requisitos implementados, requisitos testados e pedidos de alteração de requisitos.

Um processo de desenvolvimento de software completo e baseado nos requisitos - como o descrito neste artigo - exige um trabalho significativo em termos de planeamento, formação e melhoria de processo.

As ferramentas de desenvolvimento de software também são uma parte importante da implementação de tal processo. As ferramentas de modelação visual (como o Rational Rose, ou o Rational XDE), as ferramentas de gestão das alterações (como o Rational ClearQuest), as ferramentas de gestão de requisitos (como o Rational RequisitePro) e as ferramentas de estado de projecto (como o Rational ProjectConsole) podem contribuir significativamente para melhorar a capacidade de uma organização no sentido de atingirem o nível mais elevado de maturidade em termos de gestão de requisitos. Mas apesar destas ferramentas terem vantagens claras, também têm custos associados (aquisição, manutenção e formação).

Suporte das ferramentas de gestão de requisitos

Até ao Nível Cinco, é teoricamente possível fazer manualmente tudo aquilo de que falámos neste artigo, ou através do recurso a ferramentas genéricas, como um processador de texto ou uma folha de cálculo. No entanto, a partir do Nível Dois, a utilização de uma ferramenta de gestão de requisitos poderá ajudar-nos a ser bastante mais eficientes e consistentes. O Quadro 1 mostra como é que as principais funcionalidades do Rational RequisitePro suportam as características chave dos cinco níveis de maturidade da gestão de requisitos.

Suporte RUP

Os cinco níveis de que falámos ao longo deste artigo abarcam o processo de gestão de requisitos. Um processo determina e documenta quem faz o quê, quando o faz e o que produz. É necessário tempo e esforço para decidir aquilo que o processo deve ser e depois documentá-lo. As organizações poderão poupar recursos optando por não reinventar a roda e proceder alternativamente à adaptação de um processo standard para responder às suas necessidades.

O Rational Unified Process, por exemplo, está dividido em disciplinas, sendo uma delas a Requirements Management Discipline (ou disciplina de gestão de requisitos). Se olharmos para a disciplina, veremos que contém um fluxo de trabalho a detalhar muitos dos conceitos de que falámos atrás. As organizações que começarem com o RUP poderão assim obter uma vantagem inicial para o aumento da sua maturidade em termos de gestão de requisitos.

Avaliar e subir na escala

O objectivo deste artigo é descrever as melhores práticas que as organizações adoptam à medida que os seus esforços em termos de gestão de requisitos vão atingindo uma maior maturidade e avançam para novos níveis de sofisticação. Os cinco níveis que descrevemos devem fornecer uma framework para que possamos avaliar a nossa própria organização e compreender onde estamos e o que precisa de ser melhorado. Também deverão constituir uma forma de compreendermos as vantagens e os custos relacionados com a evolução na escala de maturidade em termos de gestão de requisitos.

Baseado no artigo "The Five Levels of Requirements Management Maturity", de Jim Heumann, Requirements Evangelist, Rational Software.

Produzido em 2005