No capítulo anterior vimos conceitos básicos sobre dois elementos fundamentais para o trabalho com requisitos: Informação e Comunicação. O tema de hoje é Conhecimento – o que devemos aprender e desenvolver sobre cada requisito de um projeto. O papo será mais prático, podes crer.
Como a conversa no artigo anterior ficou bem “matemática”, segue mais uma fórmula:
Requisito = (Informação * Confirmação) – Ruído
Vimos na introdução desta série que a informação representada por um requisito é uma “condição necessária para alcançar certo fim”. Depois, vimos que este “certo fim”, em nosso contexto, é um conjunto de objetivos do negócio. Objetivos que podem ser detalhados e organizados na forma de requisitos do negócio. É suficiente, para o desenvolvimento e condução de um projeto, que se conheça apenas essas informações (condições e fins) devidamente confirmadas e livres de ruídos? Sim, desde que interpretemos a variável “informação” da fórmula acima de uma maneira bem ampla.
Se você não aprender corretamente os requisitos, não fará a menor diferença o quão bem trabalhe no restante do projeto. -Karl Wiegers
Assim como será praticamente impossível encontrar um cliente ou usuário que, durante a exposição de seus objetivos e condições, aja mais ou menos assim: “Vou relacionar os requisitos funcionais, anota aí. Prepare-se para os não funcionais. Agora, às restrições. Por fim, falemos sobre regras de negócio”. Este usuário não existe. E não precisa existir!
Cabe ao analista os processos de estruturação e enriquecimento dos requisitos. Aliás, se ele fizer só isso por um projeto já terá justificado seu salário. Se você acha que isso é muito pouco, por favor, continue lendo.
Estruturar significa organizar – separar os mais diversos tipos de requisitos e demais informações. Porque cada um deles merecerá um destino diferente. Porque cada um pede tratamento e ferramental específicos. Veremos isso nos capítulos sobre Funções, Atributos, Preferências e Restrições.
Enriquecer significa obter mais informações e confirmações (feedback) sobre cada requisito. O diagrama ao lado ilustra sete atributos que todo e qualquer requisito (de todo e qualquer projeto) deveria merecer.
Tipo
Aqui simplesmente colocamos cada requisito em sua devida caixinha. Na classificação mais básica possível teríamos: Requisitos do Negócio, Funções, Atributos e Restrições. Quem quiser ser mais específico pode diferenciar requisitos de usabilidade, de dados, telas, relatórios, integração, transição, segurança etc. No modelo proposto por Suzanne e James Robertson¹ existem apenas: Restrições, Requisitos Funcionais, Não Funcionais e de Tecnologia. Com certeza há uma separação e nomenclatura mais adequadas para sua organização ou projeto. Esta série utilizará a primeira lista acima em todos os exemplos.
Fonte
O nome de quem manifestou aquele requisito pela primeira vez. A tabelinha² Fonte pode, obviamente, ser completada por outras informações como cargo, departamento etc. Em alguns casos não é possível identificar uma pessoa. Quando tudo o que um analista tem em mãos é um edital, por exemplo. Nessas situações (terríveis) registramos apenas o documento e, eventualmente, capítulos e páginas.
Só não recomendo que se registrem aqui informações sobre o impacto que o projeto terá sobre a pessoa e sua influência. Porque são informações do tipo caixa preta que deveriam ser persistidas em um local menos público.
Perspectiva
É o ponto de vista defendido pela fonte. Sugiro uma distinção bem simples:
- Estratégica: a pessoa está no topo da pirâmide organizacional, é proprietária ou da alta direção.
- Tática: gerentes, coordenadores ou supervisores. A pessoa está no escalão intermediário.
- Operacional: na base da pirâmide, onde ficam todos que de fato colocam a mão na massa (ou no martelo).
Além dessas, podemos ter perspectivas que não participam diretamente do negócio. Legal, por exemplo, para representar o corpo jurídico da empresa; Técnico para diferenciar todos os requisitos que vieram de TI e assim por diante. Em cada organização ou projeto podem existir pontos de vista diferentes que merecem destaque.
Repare no diagrama acima que, apesar de qualificar a Fonte, a Perspectiva é um atributo do Requisito. É o primeiro mecanismo do modelo que visa a resguardar a história do projeto. Quando uma pessoa for promovida, mudando assim sua perspectiva, não levará consigo seus antigos requisitos. Fica registrado que, quando aquela pessoa manifestou determinado requisito ainda defendia o ponto de vista “operacional”, por exemplo.
Valor
Todo requisito tem um valor (benefício) e um custo. Representamos aqui qual é a contribuição de determinado requisito para a realização dos objetivos do negócio. Podemos utilizar uma escala bem simples, como:
- Fundamental: a não realização deste requisito resultará em fracasso do projeto. Sua satisfação é incondicional.
- Importante: este requisito não dá uma contribuição direta para a realização dos objetivos do negócio. É uma função ou característica que pode ser entregue em outro momento. Ainda assim, por algum motivo, ela é importante para o cliente ou usuário.
- Opcional: requisito que não representa nenhuma contribuição direta ou indireta para a realização dos objetivos do negócio. Deve ser percebido apenas como algo que agradaria o cliente ou usuário caso haja tempo e dinheiro para sua realização.
Quem precisar de uma escala maior pode utilizar, por exemplo, a sequência de Fibonacci. Costumo recomendar um pequeno subconjunto: 1, 2, 3, 5, 8, 13. Em situações que envolvam quatro ou mais interessados (proponentes de requisitos), sugiro também o uso do Planning Poker para a valorização das necessidades e restrições apresentadas. Geralmente esta ferramenta é utilizada apenas para estimativas de esforço, o que é um desperdício. Quando utilizamos unidades relativas, é importante que valor (benefício) e estimativas (custo) sejam medidos com a mesma régua. Tanto melhor se utilizarmos o mesmo método. No capítulo sobre estimativas e planejamento isso será melhor explicado.
Este assunto merece livros inteiros. Porque está aqui boa parte dos problemas que presenciamos em projetos. Quanta grana se desperdiça com funções que raramente ou nunca são utilizadas; Quanto tempo é perdido em requisitos que representam nada ou muito pouco para a solução do verdadeiro problema; Enfim, como faz falta uma visão compartilhada sobre aquilo que realmente interessa em um projeto.
Em praticamente tudo o que compramos ou construímos há prioridades e alternativas. Na lista do supermercado, no carro ou na casa nova pensamos em itens fundamentais, importantes e supérfluos ou opcionais. É curioso como no mercado de software sobrevive, por muito tempo, um jogo de tudo ou nada. Curioso porque software é infinitamente mais maleável que casas, carros e listas de supermercado.
O que deve ficar, neste ponto, é a consciência de que esta pergunta – “Ilmo. Sr. Usuário, quanto vale esta solicitação?” – deve ser feita. Imediatamente após a apresentação do requisito. O cliente ou usuário pode se enganar ou, em raros casos, tentar ludibriar o analista. Momento este que aciona o lado crítico do analista: “Me explique, caríssimo Usuário, como a função X (ou o atributo Y) ajudará a ACME a aumentar em 30% o faturamento”. Sim, os objetivos e requisitos do negócio devem balizar todos os demais requisitos. Não há outra maneira de analisar e de fato criticar e priorizar requisitos. Não há!
Relações com os Outros Requisitos
Se através do Valor rastreamos cada requisito na vertical (entendendo sua contribuição para a realização dos objetivos do negócio), está naquele pequeno círculo incompleto a rastreabilidade horizontal. Ou seja, o tipo de relacionamento que determinado requisito tem com todos os demais. Quando existe, a relação pode ser de:
- Dependência: a realização do requisito B depende da realização do requisito A. É através deste mecanismo que agrupamos requisitos, formando um módulo ou uma funcionalidade completa, por exemplo.
- Complementaridade: a realização do requisito A facilita a realização do requisito B ou simplesmente o completa. Aqui também sinalizamos um agrupamento, desta vez com elementos levemente acoplados.
- Redundância: requisitos A e B, apesar de uma possível redação diferente, representam a mesma condição – necessidade ou restrição. Portanto, um deles deve ser excluído* do escopo do projeto.
- Conflito: o requisito A impede a realização do requisito B. Este conflito normalmente se dá entre funções e atributos ou, principalmente, entre funções e restrições. E, infelizmente, boa parte deles só pode ser identificada na bancada de testes. Ainda assim, é recomendável que o analista fique atento aos conflitos em potencial. E registre-os.
- Substituição: o requisito B substitui o requisito A. Está aqui o mais importante mecanismo de proteção da história do projeto de todo o modelo proposto. Uma vez registrado, nunca mais o requisito deveria ser editado ou apagado. Se determinado requisito precisa ser alterado por algum motivo qualquer, deveríamos registrar um novo requisito e indicar que ele substitui um ou mais existentes. Anotando cuidadosamente o motivo da alteração. No meio de tanto bafafá sobre gerenciamento de mudanças, normalmente perdemos o essencial: uma mudança é, antes de tudo, um requisito. Por isso, deveria ser tratada da mesmíssima maneira (no mínimo).
* Portanto, o excluído daquela frase deve ser interpretado como uma desativação do requisito mas não sua exclusão física. Porque pode ser bom lembrar e medir, por exemplo, quanta redundância se originou do trabalho de diversos analistas entrevistando diversas pessoas.
Há outro tipo de rastreabilidade, igualmente necessária mas não contemplada nesta sugestão. Ela trata do relacionamento entre requisitos e elementos da solução. Quem sabe usar (direitinho) a UML não precisa se preocupar com isso. Os demais ficarão com uma bela pulga atrás da orelha.
É bastante provável que neste momento lhe tenha caído uma ficha: “Caramba! Quanto trabalho!” Entendeu agora porque um analista de negócios ganha tão bem? Brincadeirinha… A mensagem é outra.
O diabo está nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo se lambuza.
Outra mensagem: se o analista envolvido com requisitos não faz este trabalho ele não está fazendo seu trabalho. Ponto!
Não há análise, seja de requisitos ou de negócios, feita no atacado, por cima, nas coxas…
Testes
E por falar nas coxas… Hora de conversar um pouco sobre testes. Lembra-se da fórmula que abriu este capítulo?
Requisito = (Informação * Confirmação) – Ruído
Os testes são os grandes responsáveis por gerar confirmação e também por subtrair ruídos dos requisitos. Não por acaso, é o único atributo do modelo sugerido que mantém relação de muitos para muitos com os requisitos. Este tema também merecerá um capítulo só seu. Por enquanto, é importante o entendimento de que os testes ocorrem em diversos momentos e com propósitos distintos. No início, durante uma entrevista, por exemplo, testamos um requisito no sentido de confirmar i) Nosso entendimento; e ii) Sua (do requisito) real necessidade. Nos momentos seguintes, de forma isolada ou em conjunto, os requisitos são submetidos a baterias de testes que visam a i) Confirmar nosso entendimento; e ii) Confirmar a sua (do requisito) realização.
Teste é sinônimo de confirmação, feedback, refinamento e aprendizado. Não deveria estar relacionado com coxas.
Estado
Enfim, o último atributo básico que todo requisito deveria merecer. Aqui simplesmente posicionamos o requisito em um momento de seu ciclo de vida. Podemos utilizar a mesma nomenclatura das divisões de um quadro kanban, por exemplo: Em Espera; Em Execução; Em Testes; Entregue. Claro, sua organização ou projeto pode requerer uma visão diferente, mais detalhada. O importante é que se saiba, a qualquer momento, qual o estado de cada requisito.
A Tabela Central
A tabela² Requisitos possui, além das diversas chaves estrangeiras (ligações com outras tabelas), alguns campos próprios. Mantendo o padrão, relaciono abaixo o que considero o mínimo necessário:
- Número: sequencial, por ordem de entrada. Serve apenas para identificação e não tem relação nenhuma com a Ordem (posição do requisito no escopo do projeto ou backlog do produto).
- Descrição: breve texto que exprime aquela necessidade ou restrição. Existem regrinhas de padronização para cada tipo de requisito. Veremos isso no momento oportuno.
- Justificativa: explicação (opcional) para o requisito. É um campo texto, livre.
- Material Complementar: Lista (opcional) de links e referências para fontes que completem o entendimento do requisito.
- Versão: Número da versão do requisito. Cada substituição inserida (veja Relações entre Requisitos acima) se reflete aqui.
- Analista: Nome (ou código) do analista que efetuou o registro do requisito.
- Timestamp: (Agora exagerei. Perdão).
Revendo Tudo
- Informação é diferença que faz a diferença. (Gregory Bateson)
- Informação é dado investido de relevância e propósito. (Peter Drucker)
- A conversão de dados em informação requer conhecimento. (idem)
- Informação é a principal matéria prima de projetos.
- Comunicação = Informação * Relacionamentos * Confirmação (Jurgen Appelo)
- Comunicação (em Projetos) = Requisitos * Relacionamentos
- Requisito é informação devidamente confirmada e livre de ruídos.
Requisito = (Informação * Confirmação) – Ruído - Requisito, enquanto informação estruturada e enriquecida, é conhecimento produzido por conhecimento.
- Conhecimento é a capacidade de agir. (Karl-Erik Sveiby)
Depois deste tour de force, quem sabe o que virá a seguir?
Notas
- Em Requirements-Led Project Management (Addison-Wesley, 2005). É do casal Suzanne e James Robertson o modelo Volere, um “modelo de conhecimentos de requisitos” mais completo (e mais complicado) do que o que é sugerido nesta série. Não gosto da forma como o modelo do negócio é (mal) tratado no Volere.
- A sugestão aqui apresentada foi concebida, há mais de dez anos, como um modelo E-R (entidade-relacionamento). Quando ela deixou o laboratório e ganhou as ruas, através do treinamento {FAN}, manteve o desenho original. Para surpresa deste que aqui rabisca, o formato se provou bastante didático. No entanto, peço desculpas se a terminologia técnica ou as bobas explicações sobre ela causaram chateação, desconforto ou dúvidas. Neste caso, sou todo ouvidos.
- O termo elicitação não existe em língua portuguesa. E sua criação, convenhamos, é totalmente desnecessária. Não porque utilizamos coleta em seu lugar. Mil vezes não! Coletamos lixo ou material para exames clínicos. Não coletamos requisitos.
Essa terminologia, particularmente a separação entre elicitação e análise de requisitos, é herança maldita das cascatas e cascateiros. No longínquo 1989, Donald Gause e Gerald Weinberg já nos mostravam a correção do termo Explorar requisitos (Exploring Requirements – Quality Before Design. Dorset House). São equivalentes os termos aprender e desenvolver, os meus preferidos.
Não tem muito tempo que deixamos de chamar requisitos de requerimentos. Passa da hora de abandonarmos palavras que, além de feias, não refletem o real significado do trabalho com requisitos.
