Quem explora e desenvolve requisitos deve se preocupar com sete questões fundamentais. São testes executados várias vezes e em diversos momentos de um projeto. Segue a lista¹:

É Necessário?

O requisito realmente dá alguma contribuição, ainda que pequena, para a realização dos objetivos do negócio? Apesar de nossa insistência em perguntar a clientes e usuários pelo valor de cada requisito, a revalidação se paga. Porque podem aparecer funções, atributos ou restrições que, depois de certo tempo, perdem o sentido.

Também não pode existir, em nenhum tipo de projeto, um requisito que não se relacione com nenhum outro. Tratamos aqui de relações de dependência ou complementaridade, como visto anteriormente. Não há uma conta “diversos” em  projetos minimamente sérios.

É Compreensível?

No frigir dos ovos, um requisito é só “uma condição necessária para alcançar certo fim” (Houaiss). Nada justifica que seu entendimento seja difícil. Requisito é informação. E informação é “dado investido de relevância e propósito” (Peter Drucker). Informação é “a diferença que faz diferença” (Gregory Bateson). Por isso enriquecemos cada requisito com um conjunto de características que o explica e justifica: fonte, perspectiva, valor, relações e estado, pelo menos. Cada característica aumenta nossa compreensão sobre o requisito. Claro que, antes de qualquer coisa, a redação do requisito deve ser clara e objetiva. A estruturação não nos isenta da boa escrita.

Está Completo?

Um requisito que apresente pendências não deveria avançar em seu ciclo de vida. O solicitante aguarda alguma informação ou ainda precisa confirmar algo com alguém? Devemos oferecer nosso apoio, resolver as pendências e só então incorporar o requisito.

A recomendação é outra quando a pendência é fruto da insegurança de quem manifestou o requisito. Se é algo de muito valor, então acelere ou antecipe a realização daquele requisito. Coloque-o no topo da fila e faça com que entregas preliminares tranquilizem o cliente ou usuário. Mais sobre isso no último item da lista.

É Verificável?

Se não há a menor ideia sobre como a realização do requisito será testada, é provável que não seja um requisito. Atributos pra lá de ambíguos (tela bonita, processo rápido, operação fácil etc) também comprometem a testabilidade de uma solução. Eles devem ser evitados a todo custo. Todo bom requisito sugere, de maneira clara, pelo menos um teste que comprova sua realização.

É Viável?

O valor atribuído a cada requisito ou grupo de requisitos possibilita seu posicionamento vertical (eixo benefício) na matriz ao lado. Estimativas de custo de cada alternativa de solução² indicam a posição horizontal. Temos assim uma ferramenta que apoia a análise benefício/custo³ de todo o escopo de um projeto.

Pesadelos são descartados sem dramas. Dado o baixo valor agregado de determinado requisito, sua realização só faz sentido quando for uma bobeirinha – algo fácil e barato de construir. É a metade superior da matriz que merece nossa atenção. Se todas as alternativas fossem sonhos, com certeza você não estaria aqui. Projetos dignos de nota sempre oferecem algum tipo de desafio – módulos de muito valor cuja realização envolve alguma complexidade técnica e, consequentemente, alto custo.

Utilizamos valores relativos, tanto para benefícios quanto para custos, quando os números reais ainda estão distantes. Podemos utilizar escalas simples (Fundamental=3, Importante=2, Opcional=1) ou um pouco mais sofisticadas (a sequência de Fibonacci, por exemplo). Esta validação nos ajuda a definir o escopo ideal de uma solução. De quebra, ela sugere prioridades.

Está Priorizado?

A melhor imagem do escopo de qualquer projeto é uma fila indiana. Cada requisito incorporado merece uma posição única. No topo, temos tudo o que é fundamental para a realização dos objetivos do negócio. No fim, tudo o que pode ser cortado sem choro nem vela.

Quando é possível colocar em produção as entregas parciais, então os sonhos serão prioritários. Desta forma antecipamos a realização de valor. Caso contrário – quando tudo deve ser entregue em conjunto – começamos pelos desafios. Depois de entregar o que realmente importa, em havendo tempo e dinheiro, desenvolvemos algumas bobeirinhas.

Está Correto?

Enfim, resta saber se o requisito está correto. E o que garante sua correção? A assinatura do cliente ou usuário no documento de requisitos? Um contrato redigido pelo mais competente escritório de advocacia? Nada disso pode garantir que um requisito esteja correto. Só conseguimos 100% de certeza quando o requisito não é mais “uma condição para alcançar determinado fim”. Só temos total certeza de sua correção quando o fim é alcançado. Isso só é possível com a solução entregue e em funcionamento. O que pode demorar dias, semanas ou até meses para se confirmar.

Tamanha distância não nos livra da busca pela correção dos requisitos. Qualquer coisa – modelos, protótipos, versões alpha e beta e paliativos afins – que minimize o frio na barriga das partes interessadas pode e deve ser utilizada. Desde que haja consciência de que apenas o produto final, devidamente entregue e em funcionamento, terá as respostas definitivas.

Notas

1. A lista acima não tem nada a ver com os famigerados checklists que divertem ou enganam leitores de algumas revistas populares. Porque não é simples como: sim, não, sim, sim, não, não, sim = 17 pontos: tô gordo! Não é possível aplicá-la em um ponto específico do projeto. São validações e testes que analistas e demais envolvidos executam diariamente. Obsessivamente.
2. É de quem vai construir a solução a responsabilidade por apresentar alternativas e respectivas estimativas. Para que esta ferramenta funcione direitinho, a turma de negócio fala sobre benefícios e o time técnico sobre custos. O embate, a tensão criativa, tende a fazer emergir a melhor solução possível.
3. Não estou inventando moda. Foram Tom DeMarco e Timothy Lister, em Peopleware (Dorset House, 1999), que sugeriram a análise benefício / custo. A grafia “análise custo X benefício” carrega dois equívocos: i) a suposta operação ( multiplicação ou subtração) não faz nenhum sentido matemático; ii) a colocação do custo antes do benefício é coisa de gente mesquinha.
4. Este artigo é uma releitura das sugestões apresentadas por Karl Wiegers em Software Requirements (Microsoft Press, 1999).

A literatura técnica tradicional costuma tratar atributos como requisitos não funcionais. O termo é ruim e causa certa confusão. Funcional é um adjetivo. Em nosso curioso domínio, não funcional não é sinônimo de disfuncional. Não pode ser. Ninguém pede por algo que não funcione. Recentemente outros nomes foram propostos, como Requisitos Transversais. Esta série adota a nomenclatura sugerida por Gerald Weinberg e Donald Gause em Exploring Requirements¹ (Dorset House, 1989). É deles uma diferenciação bem clara entre funções e atributos: “Um Porshe 911 Carrera tem mais ou menos as mesmas funções de um Fiat 147, mas muitos, muitos atributos diferentes.”

Atributos são características ou qualidades. São expressos na forma de adjetivos ou advérbios. Dada uma função, é imenso o número de possibilidades de realizá-la. Os atributos reduzem as alternativas e apontam o caminho desejado.

Dependendo do produto/projeto, a diversidade de atributos pode ser considerável. Pense em um carro, por exemplo: econômico, versátil, seguro, potente, bonito, moderno e ecologicamente correto são alguns requisitos comuns. Cada um deles demanda explicações e estudos bastante específicos. Para sistemas de informação, a lista de tipos de atributos é igualmente extensa: usabilidade, performance, disponibilidade, segurança, confiabilidade, portabilidade, eficiência, manutenabilidade, reusabilidade e flexibilidade são alguns deles.

Quatro perguntas nos ajudam a começar e direcionar a prosa:

• Quais características farão desta uma excelente solução?
• Você já usou algo parecido antes? Se sim:
  • O que mais lhe agradou?
  • O que mais lhe irritou?

São várias as formas de registro deste tipo de requisito. É difícil indicar a melhor. Mas é muito fácil identificar uma ruim: é aquela onde tudo (funções, atributos, restrições e regras de negócio) está misturado e descrito na forma de texto corrido. Se os requisitos são tratados assim, não surpreende que os sistemas sejam macarrônicos, porcamente acoplados e de cara manutenção.

Cada tipo de atributo merece tratamento específico. Requisitos de usabilidade, por exemplo, são mais bem expressos na forma de protótipos e storyboards. E por que não registrar requisitos de dados em dicionários de dados e modelos E-R? O fato é que, na maioria das vezes, as transcrições textuais representam puro desperdício.

Balanço

Bom, bonito e barato: escolha qualquer par. Este dito ilustra bem outro desafio no trabalho com atributos. O cliente ou usuário não pode ter tudo. É dever de quem desenvolve os requisitos informar sobre as inevitáveis permutas – explicar que a ênfase em determinada característica pode significar perdas em outros pontos.

Karl Wiegers, em Software Requirements (Microsoft Press, 1999), desenvolveu uma matriz que ilustra impactos positivos e negativos entre os principais atributos de qualidade. A ênfase em reusabilidade, por exemplo, gera reflexos positivos em diversos outros atributos, como flexibilidade, interoperabilidade, portabilidade e manutenabilidade. Por outro lado, resulta em impacto negativo no custo de desenvolvimento. O balanço ideal não ocorre por acaso. Experiências e testes dos pontos mais críticos e de possíveis conflitos é nada menos que uma obrigação de quem desenvolve a solução.

Restrições

Vimos anteriormente que todo e qualquer requisito merece ser enriquecido com um pequeno conjunto de informações. Uma delas é o Valor do requisito, que pode ser representado por uma escala simples como Fundamental, Importante e Opcional².

Todo atributo valorizado como fundamental torna-se uma restrição. Como nos ensina o dicionário, uma restrição é uma imposição de limite. Ou seja, é algo que deve ser respeitado na íntegra pela solução. Demais atributos, de menor valor, podem e devem ser negociados.

Devemos separar as restrições em dois grandes grupos:

• Do Sistema: delimitam as fronteiras da solução;
• Do Projeto: determinam limites do projeto como prazo e custo, por exemplo.

Cada grupo tem um público específico: o primeiro interessa aos arquitetos e desenvolvedores; o segundo é de quem vai gerenciar o projeto. É curioso como muitos não percebem este segundo grupo como sendo requisitos. Sempre foram. Sempre serão. E geralmente eles são explorados logo no início de um projeto.

Igualmente curiosa é a confusão entre restrições do sistema e regras de negócio. Quando alguém classifica “o usuário deve estar logado no sistema” como uma regra de negócio a coisa está feia, muito feia. Porque é muito fácil evitar a confusão: desligue o sistema; aquela restrição segue valendo? Então ela é uma regra do negócio. Simples assim.

Preferências

A diferença entre o desapontamento e o deslumbramento não é uma questão de entrega, mas de quão bem o produto entregue satisfaz expectativas. Weinberg & GauseO papo sobre restrições, sejam do projeto ou do sistema, costuma incomodar. É uma conversa fria, racional. Mas necessária. Afinal, não existem projetos sem restrições. Para que um evento (entrevista, reunião) de desenvolvimento de requisitos não termine de forma chata, deixamos para o final um assunto mais quente: as preferências de clientes e usuários. Fazemos duas perguntinhas básicas:

• Qual é a sua maior expectativa em relação a esta solução?
• Que parte da nova solução será mais valiosa para você?

As respostas devem permitir o destaque das funções e atributos que merecerão maior atenção. O trabalho de gerenciamento de requisitos não pode ser visto como uma coisa mecânica – tá pronto / não tá pronto. Gerenciar requisitos significa, em grande medida, gerenciar expectativas.

Notas

1. Este livro foi publicado no Brasil em 1991 pela McGraw-Hill com o título Explorando Requerimentos de Sistemas. Está esgotado, mas pode ser encontrado nos sebos da vida. A edição eletrônica foi dividida em duas partes. Trata-se do mesmo texto original.
2. Existem n variações de escalas para avaliação e priorização de requisitos. Como sugerido anteriormente, podemos utilizar a escala de Fibonacci. O método MoSCoW também é bastante conhecido.
3. A série aproxima-se do fim. Enfim! Além dos famigerados exemplos, o que mais você gostaria de ver por aqui? Qual tema merece mais alguns dedos de conversa?

Falhamos muitas vezes não porque não conseguimos resolver os problemas que encaramos mas porque encaramos o problema errado. –Russel AckoffRequisitos do negócio são requisitos de alto nível que explicam necessidades do negócio e justificam a execução de um ou mais projetos. Requisitos do negócio representam objetivos do negócio. Muito dificilmente esta representação se dará em uma relação de um para um. E raramente este trabalho – a verdadeira definição de um problema – chegará pronto para a equipe que deve encontrar e desenvolver a solução.

Não se trata de má vontade ou trabalho mal feito, pelo menos não na maioria das vezes. Não há um protocolo universal para comunicação de problemas e requisitos. Assim como não há nem nunca haverá um processo único, uma receitinha de bolo que nos ajude a entender e comunicar requisitos do negócio. Porque, como escreveram Donald Gause e Gerald Weinberg¹, “é impossível definirem-se os problemas naturais do dia-a-dia de uma forma simples, única e totalmente não ambígua”.

O Início, O Fim e o Meio

O mapa que orienta esta série indica que a definição dos requisitos do negócio antecede o(s) projeto(s) que deve(m) satisfazê-los. Não estou sugerindo que este seja o processo e sim afirmando que é assim que as coisas acontecem, mesmo na mais bagunçada das empresas. Uma organização, ao reconhecer um problema ou identificar uma oportunidade², decide efetuar uma ou mais mudanças. Mudanças que podem ser planejadas e executadas através de projetos.

Portanto, o início de um projeto marca o fim do reconhecimento e aceitação de um problema. Colocando de outra forma: o início de um projeto indicaria o término da fase de descoberta e entendimento dos requisitos do negócio. Este é o momento em que a porca torce o rabo e nossos primeiros desafios dão as caras. Veja no pequeno inventário abaixo quais situações lhe são familiares:

• Você não precisa saber disso, diz o cara de negócios, sonegando informações que lhe permitiriam i) Priorizar requisitos; ii) Criticar requisitos; iii) Saber se está no caminho certo; iv) Ter um propósito na vida que não seja apenas deixar-se levar; dentre outras coisas.
• Você não é orientado a falar sobre isso pela fantástica metodologia adotada, afinal o importante é entregar dentro do prazo e do orçamento o escopo acordado, seja lá o que isso signifique.
• Você e seus colegas estão perdidinhos da silva, sem saber o que perguntar e para quem. Mas todo início de projeto é assim mesmo, diz a voz da “experiência”.

Repare no diagrama acima que TODOS os requisitos de um projeto derivam dos requisitos do negócio. É fácil concluir que a ausência ou o desconhecimento destes torna um projeto um bate papo entre malucos, uma viagem sem destino nem mapas. Assim como deve ser fácil entender que suposições e decisões acerca dos requisitos do negócio viverão até o término do projeto e além.

Antes que muitos saibam alguma coisa, um deve sabê-lo. – Henrik IbsenÉ de fato natural que o início de um projeto seja marcado por muitas incertezas. Mas é inaceitável que a equipe não saiba o que perguntar e para quem. A primeira grande pergunta é: por que este projeto é necessário? Claro, ela pode ser formulada de outras maneiras. E seguida por outras questões abertas que ajudarão a formar uma primeira visão do projeto. Seguem algumas sugestões³:

• Qual ou quais problemas de negócio você precisa resolver?
• Qual é a motivação para que se resolva este problema?
• O que pode acontecer se ele não for resolvido?
• Que tipo de solução está fora de cogitação? Por quê?
• Você entenderá que este projeto foi um sucesso se…
• Quanto vale esta solução?
• Quais pessoas ou áreas serão afetadas pela implantação desta solução?
• Quem poderá influenciar a construção desta solução?

As duas últimas questões nos ajudam a iniciar o mapeamento de todas as partes interessadas, interesseiras, indiferentes e até as encrenqueiras. Todas as pessoas que surgirem como resposta para a última questão devem ser submetidas ao mesmo questionário acima. No bololô das redundâncias (desejadas), buscaremos por contradições, mal entendidos, suposições tácitas (escondidas) e dúvidas.

Aliás, criar e semear dúvidas é uma forma de elaborar, amadurecer e testar os requisitos do negócio. Gause e Weinberg sugerem a regra das três interpretações¹: “Se você não puder achar pelo menos três coisas que possam estar erradas com sua compreensão do problema é porque não entendeu o problema”. Depois, ao apresentar essas interpretações aos envolvidos, caminhamos no sentido de eliminar ambiguidades e mal entendidos.

Este trabalho de reflexão e questionamento não combina com a pressa. Por isso será sempre recomendável que ele ocorra antes que um projeto seja disparado. Desta forma, ele não sofrerá a pressão de um cronograma. Por favor, não me interprete mal. Não estou sugerindo que esta etapa seja longa e demorada. Mas também não vou vender a ilusão do “separe 10% do cronograma para esta fase” ou o engano das iterações 0, -1 etc. Todo projeto é único. Alguns pedirão por algumas semanas de reflexão. Outros serão definidos (ou abortados) em poucas horas. C’est la vie…

Todos os trabalhos sobre requisitos que mostram alguma preocupação com este momento inicial concordam em algumas recomendações: vá devagar; seja redundante; tenha mente de iniciante; procure por todos os pontos de vista relevantes; ouça e pense, ouça e pense… (repita n vezes antes de abrir a boca). Sugestões que parecem contradizer alguns mantras do mundo moderno. Estariam ultrapassadas? Veremos no próximo capítulo, através da apresentação de um exemplo prático. Inté!

Notas

1. Seus Olhos estão Abertos? – Donald C. Gause e Gerald M. Weinberg (Makron Books, 1992).
2. Não passarei a série toda falando sobre “problemas e/ou oportunidades”. Porque o aproveitamento de uma oportunidade é, até a sua realização, um problema. Portanto, toda vez que você se deparar com a palavra “problema” acate esta interpretação, por favor.
3. Lista surrupiada e adaptada de More About Software Requirements – Karl E. Wiegers (Microsoft Press, 2006). Que por sua vez surrupiou e adaptou de Exploring Requirements – Quality Before Design, de Donald C. Gause e Gerald M. Weinberg (Dorset House, 1989). Autores como Wiegers e Scott Berkun consideram este o melhor livro sobre requisitos já escrito. Ele mereceu uma edição em pt-br, publicado em 1991 pela Makron Books com o infeliz título Explorando Requerimentos de Sistemas. Está esgotado, mas você pode ter a sorte de encontrá-lo nos sebos da vida.

Variações do diagrama acima aparecem nas oficinas do programa para Formação de Analistas de Negócios (FAN) e pintou também no seminário do último sábado. Todo mundo parece entender o diagrama sem problemas, mas só repara que a frase que negritei no primeiro parágrafo está implícita no desenho quando executamos os primeiros exercícios. Reparem: um Caso de Uso é um conjunto de Requisitos Funcionais. O nome do caso de uso é um Requisito do Usuário – um requisito funcional que carece de detalhamento. Eu realmente não entendia direito a razão de tanta estranheza, os motivos pelos quais tanta gente acha que passos em um caso de uso e requisitos funcionais são coisas totalmente diferentes. Desconfio que o problema esteja em nossas fontes, praticamente em todas elas.

Alistair Cockburn, em “Writing Effective Use Cases” , diz que podemos utilizar casos de uso em diferentes situações: Descrever um processo de negócio; Documentar o projeto (design) de um sistema; Discutir requisitos (sem descrevê-los); e Representar os Requisitos Funcionais de um sistema. Sobre esta última possibilidade, que é a que nos interessa aqui, Cockburn pede que a gente não se esqueça de duas coisinhas: i) Os Casos de Uso “são realmente os requisitos”; e ii) Mas não representam todos os requisitos.

A mensagem de Cockburn não ganha muito eco em outros trabalhos muito conhecidos. Karl Wiegers, por exemplo, chega a dizer que “na teoria, um conjunto de casos de uso compreende toda a funcionalidade requerida em um sistema” . O problema é que no mesmo livro, “Software Requirements” , Wiegers sugere que “o analista pega as descrições de casos de uso e começa a derivar os requisitos funcionais”. Wiegers defende enfaticamente a existência de um grande documento, uma SRS (Software Requirements Specification) que deve listar todos os requisitos (funcionais e não-funcionais), regras de negócio e outras informações desenvolvidas pelo analista.

Em outro trabalho, “More About Software Requirements” , Wiegers ‘desce do muro’, insistindo que “casos de uso não substituem os requisitos funcionais”. Ele rebate a visão apresentada por Kurt Bittner e Ian Spence em “Use Case Modeling” . Os dois autores afirmam que “no final das contas, todos os requisitos funcionais podem ser capturados como casos de uso, e muitos dos requisitos não-funcionais podem ser associados aos casos de uso”. Desnecessário dizer, mas defendo a visão de Cockburn, Bittner e Spence: Casos de Uso são os Requisitos Funcionais.

As variações em torno desta visão são curiosas. Tyner Blain, por exemplo, parte de uma uma sugestão de Karl Wiegers para gerar a visão representada pelo diagrama acima. Mas, caramba, não vejo ninguém afirmar com todas as letras que “passos em um caso de uso são requisitos funcionais”. Ou melhor, quase ninguém. Depois de uma rápida vasculhada (googlada?) descobri que Kevin Brennan, VP do IIBA, afirmou que “a maioria dos passos em um caso de uso são, de fato, requisitos funcionais”. Quase… Maioria? Prefiro ser mais direto: todos os passos são requisitos funcionais. Eliminando ambiguidades facilitamos o aprendizado e aumentamos a praticidade de uma ferramenta, no caso, dos casos de uso.

No seminário da semana passada minha sugestão foi confrontada por alguns participantes, principalmente por uma senhora que ilustrou seu questionamento com um belo e simples exemplo: uma máquina de café. Segundo ela, “tomar um café” é um requisito. . Na sequência ela citou os passos (que seriam executados por quem quer “tomar um café”):

1. Coloca uma moeda
2. Seleciona o tipo de bebida
3. Retira o copo

O que são os 3 passos acima? Não são funções requeridas pelo usuário para satisfazer sua necessidade ou objetivo maior (tomar um café)? Funções requeridas = Requisitos Funcionais, não? Por que, como sugere Karl Wiegers , eu precisaria extrair requisitos dos passos acima? Para redigi-los de uma forma diferente? Algo como “o usuário precisa de um lugar para colocar a moeda”? Oras… pra quê?

Mas eu temo que a confusão esconda outro probleminha, ainda mais sério. Considere que o passo 2 tenha gerado algo mais ou menos assim: “o usuário pressiona o botão referente ao tipo de bebida que quer”. Talvez o exemplo não esteja muito legal, mas quem disse que precisa ser um botão? E se a interface for outra? O que eu tento ilustrar aqui é que um caso de uso deve se limitar a explicar o QUE o usuário precisa, não COMO sua necessidade será satisfeita. Colocarei minha preocupação de outra forma: quando um caso de uso entra no domínio da solução, explicando ou apontando como determinado requisito será satisfeito, ele perde sua utilidade. Outras ferramentas, como protótipos, storyboards, modelos e código, são mais adequadas para a demonstração do COMO. Casos de uso existem exclusivamente para explicar o QUE o usuário precisa. Portanto, deveria ser utilizado apenas para o aprendizado e domínio do problema.

Mas, como tudo em nossa área, há controvérsias. E diversas outras sugestões, mais ou menos lógicas (e / ou viáveis). Quando insisto em minha proposta tenho dois objetivos: criar uma fronteira mais nítida entre problema e solução (SoC? sorry periferia purista); e simplificar – fornecer uma visão mais coesa de todas as informações necessárias para o desenho de uma solução.

Para encerrar, uma feliz coincidência: há exatamente 1 ano e 1 dia Hugh MacLeod publicava um cartoon que tem tudo a ver com a mensagem aqui: “It’s not what the software does. It’s what the user does.” Deveria virar um poster-lembrete na sala-mesa de todo AN.

Atualização:

Logo depois da publicação deste post troquei um breve papo com o mestre José Paulo Papo. Além de confirmar que concorda com minha sugestão, ele enviou uma preciosa dica ignorada na bibliografia abaixo: “Use Cases: Requirements in Context”, de Daryl Kulak e Eamonn Guiney (Pearson Education, 2003). Tks Papo!

Bibliografia:

1. Writing Effective Use Cases
   Alistair Cockburn. Addison-Wesley (2001).
2. Software Requirements
   Karl E. Wiegers. Microsoft Press (1999).
3. More About Software Requirements
   Karl E. Wiegers. Microsoft Press (2006).
4. Use Case Modeling
   Kurt Bittner e Ian Spence. Addison-Wesley (2003).

Para começar, a forma muito legal que o Ambler apresenta o AN:

Na teoria, a idéia de ter AN’s tradicionais envolvidos em um projeto deve funcionar muito bem, e na prática isso frequentemente acontece. Os melhores analistas são organizados e grandes comunicadores, têm a habilidade de destacar as informações críticas fornecidas pelos stakeholders do meio de toda aquela “poluição informativa” – lançando mão de várias técnicas de modelagem. Para muitas organizações a adição de AN’s claramente aumentou a qualidade dos requisitos e modelos. E também abriu um canal de comunicação entre os “tech weenies” de TI e os “business morons” para os quais o sistema é construído.

Jóia né? Mas aí apareceram os “poréns”. Comento abaixo cada um deles, na seqüência original:

1. AN’s não apresentam as habilidades corretas
   pv: Natural, afinal ainda não temos um mínimo ‘corpo de conhecimentos’ consolidado. Como já escrevi antes, considero o BABoK incompleto. Se não há consenso acerca da formação e habilidades requeridas em um AN, como exigir que eles as apresentem?
   AN’s são uma derivação não programada dos Analistas de Sistemas, que por sua vez substituíram (sem querer) os Analistas de Organizações e Métodos (O&M). No entanto, os AN’s não vieram para substituir os Analistas de Sistemas. São um tipo de contraponto aos “analistas-programadores”. Voltam seus olhos para o domínio do problema, enquanto aqueles tratam do domínio da solução.
2. AN’s podem ter uma influência muito negativa no projeto
   pv: Todo mundo pode, né? Mas, falando sério: insisto que um bom AN tem uma postura pró-ativa. Então, ele deve criticar requisitos. Porém, não deve nunca recusá-los sem consultar os stakeholders. Outra preocupação do Ambler me pareceu descabida: a influência do AN na arquitetura? Oras, ele não desenha a solução. Acho o risco mínimo, se é que ele existe. Já a última parte do alerta é sério: AN’s que não funcionam como canais, mas sim como uma “parede” entre os usuários e os desenvolvedores. O AN facilita o processo de comunicação, mas nunca impede o contato direto. Por exemplo, quando ele organiza e facilita um workshop, desenvolvedores e usuários estão em contato direto.
3. AN’s podem ficar desatualizados
   pv: Sim, todo mundo fica. Mas o foco do Ambler nesta questão é um tanto estranha: parece que ele considera que todo AN foi um dia um desenvolvedor. Nada mais errado. Um AN pode ter uma formação 90% em negócios, ser formado em administração ou economia, por exemplo. Naquele grande banco que citei em um post anterior, tem gente de Letras! Por outro lado, não vejo problemas em um desenvolvedor se tornar um AN. É tudo uma questão de gosto. E jeito… muito jeito.
4. AN’s podem ser uma barreira para a comunicação
   pv: Sim, como colocado no tópico 2 acima. Típica situação perde-perde-perde em um projeto. Perdem os usuários, desenvolvedores e os próprios analistas. Infelizmente é mais comum do que a gente imagina. E, tão nociva quanto a barreira, é a “tradução livre”. Explico: o AN começa a contar apenas “boas notícias” para ambos os lados. Por isso a comunicação aberta e o contato frequente entre todos os stakeholders é fundamental para o sucesso dos projetos.
5. AN’s podem reduzir a influência dos stakeholders
   pv: Sim, mas nem sempre isso é uma coisa negativa. Se ele filtrar as influências negativas, permitindo que a equipe performe, ele estará realizando seu trabalho. Mas é o tipo de ação que deve estar sincronizada com o coordenador do projeto e com a equipe. Se bem combinado, o AN se torna uma espécie de “firewall” para a equipe.
6. AN’s analisam MUITO
   pv: Até que essa apareceu tarde na lista. É o tal do BDUF (big design up-front). Ou o temor da “analysis-paralysis“. Simplificando: se o AN for jogado em um processo baseado no ciclo “cascata” (waterfall), o risco é real e imediato. Se o processo for iterativo e incremental (de verdade), o risco não existe.
   Aqui cabe um detalhe interessante (e uma brincadeirinha): o AN é o cara que mais trabalha no projeto. Veja o gráfico abaixo . Se ele resolver executar seu trampo “numa tacada só”, só ele vai trabalhar e o projeto se encerrará com uma série de documentos, descrições de casos de uso e protótipos. Ao distribuir suas atividades* entre as diversas etapas e iterações de um projeto, o AN faz bem seu trampo e permite que todos trabalhem.
   * São atividades de um AN: B (Business Modeling), R (Requirements), uma bela fatia do T (Tests) e uma fatiazinha do C (Change Management).

   

7. AN’s reduzem o feedback
   pv: Pouco provável, se o AN acompanhar todo o ciclo de desenvolvimento, guiando particularmente os testes e as entregas intermediárias. Ambler insiste nos problemas de comunicação, de certa forma factíveis. Afinal, o AN é outro nó na rede de comunicações. Ou, como diz Karl Wiegers , um cara entre a voz do usuário e os ouvidos do desenvolvedor. Se, ao invés de facilitar as comunicações, o AN emperrá-las, não estará fazendo seu trabalho.
8. AN’s reduzem as oportunidades para os desenvolvedores melhorarem suas habilidades de comunicação
   pv: Uau.. eu nunca tinha pensado nisso. O Ambler realmente não consegue “tirar o pé da jaca”. Ou, colocando d’uma forma menos agressiva: “não tira o boné de jeito nenhum”. Como eu disse acima, o AN não impede o contato direto dos desenvolvedores com usuários e demais stakeholders. Reduz o número de contatos, é certo. Mas é para o bem do projeto. Prefiro ver de outra forma: os desenvolvedores podem exercitar bem suas habilidades de comunicação (e pugilismo) com os AN’s. E aprender muito com os bons AN’s.

Notas:

1. Agility and Discipline made Easy: Practices from OpenUP and RUP
   Per Kroll e Bruce MacIsaac. Addison-Wesley (2006).
2. More About Software Requirements
   Karl Wiegers. Microsoft Press (2006).

Neste artigo vou tratar especificamente das formas como coletamos, descobrimos, inventamos e entendemos requisitos. Karl Wiegers, em “More About Software Requirements” , faz um importante alerta sobre a forma como chamamos esta atividade em um projeto de software. O termo coletar, segundo Wiegers, é enganoso. Nos leva a entender que os requisitos estão lá, estáticos, esperando a hora da colheita. Por isso falei que “coletamos, descobrimos, inventamos e entendemos”. Espero ter passado a correta amplitude do trabalho.

No post de ontem falei que temos dois grandes grupos de técnicas de aprendizado: a Socialização (interação pessoal) e a Internalização (interação com documentos dos mais diversos tipos). Vamos estruturar as técnicas de levantamento (e descoberta, invenção…) de requisitos nestes dois grupos. Veja o gráfico abaixo :

As técnicas de socialização, ou seja, aquelas que empregamos para a absorção e troca de conhecimento tácito, são as seguintes: Workshops / JAD, Entrevistas, Observações e Brainstorming. Coloquei o “Fone” ali só para fins ilustrativos (e para possibilitar outro nível de comparação). Cabe uma breve descrição sobre cada técnica:

• Workshops / JAD: reunião com um número relativamente grande de participantes. É um evento estruturado, possui agenda, duração e temas pré-definidos.
  Um Analista de Negócios (AN) pode ser alocado para planejar e organizar o evento, além de funcionar como um facilitador durante a sua execução. Neste caso é importante que exista outra pessoa (outro AN), registrando as discussões e decisões.
• Entrevistas: igualmente estruturado (ou seja, com agenda e pauta pré-determinados), é executado com um número menor de pessoas. Sua vantagem em relação aos workshops é uma certa facilidade em se manter o foco das discussões. Mas a falta de pontos de vista divergentes pode ser um fator negativo.
  Novamente o cenário ideal exige a presença de dois AN’s, um conduzindo a reunião e outro registrando os achados.
• Observações: técnica particularmente importante quando executamos a análise e modelagem do negócio e seus processos. Existem duas variações principais: i) Ativa, quando o AN executa as tarefas de um usuário; e ii) Passiva, quando o AN se limita a observar o trabalho do(s) usuário(s).
• Brainstorming: polêmica técnica que pode ser útil quando o projeto exigir criatividade, inovação. É complicada sua condução porque não há uma pauta pré-definida. O AN deve cuidar para que as idéias fluam sem nenhum tipo de interferência ou crítica. Sua eficácia depende muito do perfil e do humor dos participantes.

Todas as técnicas de socialização aparecem no quadrante de alta eficácia e riqueza. Os “agilistas” não erram quando dizem que nada substitui o “tête-à tête”. Um bom AN não se limita, em todos esses eventos, a registrar as conversas. Sinais, gestos e expressões podem ser muito relevantes também. O “mapeamento psicológico e sociológico” dos stakeholders também pode ser executado, de forma implícita e nada intrusiva. Para a execução e condução de todas as técnicas acima exige-se do AN grandes habilidades “sociais” (soft skills): comunicação, negociação, intermediação, e por aí vai.

Ao contrário das técnicas de internalização, que exigem habilidades bastante distintas. São elas: Código Fonte, Código Executável, Pesquisa e Documentação. O “Email” aparece no gráfico acima apenas para fins de ilustração. Vamos entender um pouco mais sobre cada uma delas:

• Engenharia Reversa: aparece na figura acima em três formatos, já que cada um deles possui uma classificação diferente.
  Código Fonte: sua análise é a mais rica de todas, já que permite um diagnóstico completo de um dado sistema. Também conhecida como “análise Caixa-Branca”. Dependendo da formação do AN, ele não terá condições de executar este tipo de análise. Dependerá de desenvolvedores.
  Código Executável: ou “análise Caixa-Preta”, mais factível de execução por um AN. Ele usa a aplicação e extrai idéias (casos de uso e requisitos).
  Documentação: deveria figurar em um lugar mais nobre no gráfico. Mas todos sabemos que muito raramente encontramos uma documentação boa (quando encontramos alguma documentação! Atualizada então…)
• Pesquisas: podem envolver algum tipo de socialização mas, neste caso, entrariam como uma variação dos “workshops” (acima). Estamos tratando aqui de pesquisas onde não há um contato pessoal. As pesquisas são muito úteis quando o usuário não é conhecido ou o número de usuários é grande demais. Existem dois grandes modelos:
  Questionários: pesquisas normais, onde uma população amostral é previamente selecionada. Os questionários podem ser abertos ou fechados (múltipla escolha). Podem nortear o desenvolvimento de um novo produto ou serviço.
  Versões de Testes: ou o “processo Google” de validação, com suas quase eternas versões “beta”. Um produto ou serviço, em versão de testes (ou protótipo), é disponibilizado para um grupo de pessoas pré-selecionado. Suas observações (na maioria voluntárias) são requisitos que devem ser coletados e analisados pela equipe.

Quero crer que assim ficou clara a diferença entre conhecimento tácito e explícito, e como ambos podem ser importantes em um projeto de software (ou de qualquer natureza). Como eu disse anteriormente, a ênfase no conhecimento tácito (conforme interpretada e proposta por alguns “agilistas”) gera um certo tipo de miopia no projeto.

Um AN “completo” desenvolve habilidades para selecionar e aplicar as melhores técnicas para cada tipo de projeto. Primeira habilidade obrigatória: humildade para reconhecer determinada limitação e pedir ajuda.

Notas:

1. More About Software Requirements
   Karl E. Wiegers. Microsoft Press (2006).
2. Gráfico foi inspirado neste, extraído de
   The Enterprise Unified Process: Extending the Rational Unified Process
   Scott Ambler, John Nalbone e Michael J. Vizdos. Prentice-Hall (2005).