O ato de contar histórias é quase tão antigo quanto andar para frente. Contando histórias nós informamos, ensinamos ou divertimos. Há uma estrutura clássica para histórias que pretendem informar. Elas devem responder a uma sequência pré-determinada de questões: o quê? quem? quando? onde? como? por quê? Este padrão, parte do que é conhecido como pirâmide invertida, foi lançado pelo jornal New York Times em 1861. É utilizado por jornalistas desde então. Variações da sequência surgiram como ferramentas no mundo dos negócios na segunda metade do século passado. Elas ficaram conhecidas por siglas como 5W2H e 6W, por exemplo. Mais recentemente, em The Back of the Napkin (Portfolio, 2008), Dan Roam utilizou a neurociência para justificar sua versão das questões. Em relação à pirâmide invertida original ele apenas trocou a posição das perguntas quando e onde. Se há uma estrutura relativamente bem consolidada para a narração de histórias, por que precisaríamos de algo diferente para o registro de requisitos – das necessidades, desejos e restrições de clientes e usuários?

Diz a lenda¹ que no final dos anos 1960 Ivar Jacobson, trabalhando em uma empresa de telecomunicações sueca, deu à luz uma ferramenta que apoia os trabalhos de descoberta e descrição dos requisitos funcionais de um sistema. A ferramenta se chama Especificação de Casos de Uso – Casos de Uso para os íntimos. Causo para todos que já frequentaram uma turma do FAN. O termo, bem caipira, serve para a rápida vinculação com histórias curtas narradas em linguagem coloquial. Um caso de uso típico apresenta a seguinte estrutura:

• Nome do Caso de Uso (O quê?)
• Objetivo (Por quê?)
• Ator(es) (Quem?)
• Fluxos Principal e Alternativos (Como?)

Comparado à pirâmide invertida, o caso de uso carece de duas informações que ajudariam a entender melhor o contexto: quando e onde. Apesar deste e de alguns outros pesares, esta é a melhor ferramenta para os trabalhos de descoberta e descrição de funções. É uma pena que nosso incurável gosto por coisas “sofisticadas” a tenha complicado demais. Inventamos n nomes para os fluxos (os comos), casos de uso de negócio (uma aberração²) e outras tantas coisas que só bagunçaram o coreto. Não por acaso, são muitos os profissionais que nutrem verdadeiro ódio pela ferramenta. Devo fazer um mea culpa: o modelo que utilizo poderia ser um pouco menos rebuscado. Mas, como explico em sua apresentação, a principal finalidade é didática. E ele tem funcionado bem assim.

Com a intenção de contrapor as intermináveis “especificações funcionais” inventamos as Histórias de Usuários (User Stories). Sua mensagem é clara: trocamos trocentas páginas de documentos por maior proximidade e mais conversas com clientes e usuários. As histórias são formadas por três componentes: um cartão (onde a história é descrita); as conversas (motivadas pela história); e a confirmação (testes que devem verificar a realização da história). Uma história padrão é contada da seguinte maneira:

• Como um (Quem?)
• Eu preciso/quero  (O quê?)
• De forma a realizar (Por quê?)

Além das mesmas omissões que vemos em casos de uso, as histórias também abrem mão do como. Talvez seja importante dizer que isso não é uma falha e sim uma característica intencional. O desenvolvedor que deve realizar uma história tem total liberdade para experimentar. Para funcionar bem as histórias de usuários apresentam um pré-requisito fundamental: a proximidade e intensa participação de clientes e usuários. Quando isso não é possível, o número de idas e vindas (ou seja, de experimentações) pode ser muito maior do que o desejável.

O bode que as histórias de usuários tiraram da sala, a sua maior diferença em relação aos casos de uso, é a descrição do como: como um ator (perfil/usuário) utilizará determinada função. Esta é de fato a parte mais complexa de qualquer história. É também a porção dos casos de uso que mais sofreu nas mãos de “inventores”. Cabe um pequeno exemplo. Por diversas vezes questionaram o pequeno espaço que dedico para o “caminho feliz” (o fluxo principal de um caso de uso). Citando Coplien e Cockburn³, insisto que o fluxo principal não deveria ter mais que sete ou nove passos. Algumas pessoas acham isso arbitrário demais e seguem questionando. O que me obriga a apelar: se não estamos desenvolvendo um videogame (único caso em que faz sentido dificultar a vida do usuário em seu caminho para realizar determinado objetivo), devemos sempre buscar o caminho mais curto possível. Já pensou se você tivesse que dar doze cliques para comprar um livro na Amazon? Até quem construiu os quase sempre disfuncionais caixas automáticos e bancos eletrônicos não ousou ultrapassar o limite de nove passos para a realização de uma transação. Por que você o faria?

Epílogo

Organizações são únicas, assim como projetos e histórias. Acreditar em um padrão universal para o registro destas é como crer em Papai Noel. Me contradigo? Afinal, escrevi ali em cima que “a especificação de casos de uso é a melhor ferramenta para a descoberta e descrição dos requisitos funcionais de um sistema”. Sustento minha colocação em duas características dos casos de uso: 1) Não somos obrigados a escrever muito nem muito pouco. Distância e constância da participação de clientes e usuários são os únicos fatores que determinam quanto devemos escrever; 2) Podemos criar um modelo que atenda necessidades específicas de uma organização, equipe ou projeto.

E o que dizer da deficiência apontada acima, da falta de um lugar para registrar onde e quando? Oras, nada o impede de criar este espaço e chamá-lo de Contexto. Tanto melhor se você referenciar o processo de negócio suportado no causo. Melhor ainda se você combinar presente (as-is – processo de negócio) e futuro (to-be – requisitos) em uma visualização única (PUCS – Process-Use Case Support). Há muito tempo aprendemos que uma história que pretende informar obrigatoriamente responde a seis perguntas básicas. Por mais que gostemos de reinventar a roda, devemos respeitar o óbvio: a roda é redonda; Uma história tem seis respostas.

Notas

1. A lenda fala em final dos anos 1960. Na história devidamente documentada, a especificação de casos de uso foi formalmente apresentada por Ivar Jacobson em 1986.
2. Casos de uso de negócio são uma aberração. Porque a ferramenta caso de uso trata o sistema (negócio) em discussão como uma caixa preta – não queremos nem precisamos ver seu interior, não precisamos entender como o sistema (negócio) realizará determinada função. Nos interessam apenas as interações entre usuário e sistema (negócio). Quando estudamos um negócio, queremos e precisamos entender como ele funciona. Por isso não faz o menor sentido tratá-lo como uma caixa preta.
3. Em Lean Architecture (Wiley, 2010) e Escrevendo Casos de Uso Eficazes (Bookman, 2006), respectivamente.

?

Apesar de toda a má fama que a acompanha, a ferramenta Caso de Uso continua sendo apresentada por muitos, inclusive este que vos escreve, como a mais eficaz no apoio às atividades de “descoberta e descrição dos requisitos funcionais de um sistema”. Os mal ditos sobre os casos de uso têm origem bem identificada. Em dado momento, entre o final dos anos 1990 e início do novo século, tentaram sofisticar demais a ferramenta. Modelos rebuscados e divisões artificiais e redundantes (fluxo disso, fluxo daquilo…) deram enorme contribuição. A gota d’água veio daquela parte da população que tem preguiça de pensar e adora templates repletos de badulaques. Pronto, estava criada a fama – justíssima, dados os casos criados – de que casos de uso eram muito complicados, de difícil elaboração pelos analistas, incompreensíveis para os usuários, detestados e consequentemente ignorados pelos desenvolvedores e distantes demais dos testers (provavelmente os únicos que, se tivessem a chance, talvez gostassem daquilo. Porque era melhor que nada!)

O advento do Manifesto Ágil quase nos fez crer que Caso de Uso era coisa do século passado. Mas o que seria do mundo se não fossem os teimosos? Alistair Cockburn nunca abandonou os casos. Nem Ivar Jacobson, o pai da criança que agora nos apresenta essa releitura (escrita a seis mãos com Ian Spence e Kurt Bittner, autores de “Use Case Modeling” – Addison-Wesley, 2002).
O que ela traz de novo a ponto de merecer o “2.0”? Antes disso, qual a motivação para uma nova versão?

Os autores defendem que o Caso de Uso 2.0 é: Leve, Escalável, Versátil e Fácil de usar. Fica implícita a intenção de oferecer a versão remoçada da ferramenta como alternativa para as User Stories. Apesar de ilustrarem sua utilização até em um processo baseado no modelo waterfall. A falta de um comparativo entre User Stories e Casos de Uso, a exemplo do que fizeram James Coplien e Gertrud Bjørnvig em “Lean Architecture“ (Wiley, 2010), reduz o impacto da proposta. Mas, afinal, qual é a proposta?

Jacobson reforça uma mensagem que já apresentava em seus tempos de Rational¹: “casos de uso são a cola de todo o ciclo de vida do processo “. Ou seja, eles “suportam a análise, projeto, planejamento, estimativas, acompanhamento e testes de sistemas”, além da captura de requisitos, é claro.

Um mapa conceitual nos ajuda a entender todos os elementos da proposta e as relações entre eles. Peço desculpas pela redundância mas vou reescrever as partes que representam as maiores alterações (e, tentarei mostrar, os problemas da proposta).

Os interessados (stakeholders): i) são as fontes dos Requisitos; ii) estão envolvidos e priorizam Casos de Uso; e iii) se comunicam contando Histórias.

Até aqui tudo bem, até porque o mapa informa que: iv) Requisitos são capturados na forma de Casos de Uso.  Agora, como falamos aqui no interior, a porca torce o rabo (e a proposta se enrola). Porque é colocado que: v) Casos de Uso são explorados através da narração de Histórias; e vi) seu escopo é gerenciado e endereçado como um conjunto de Fatias de Caso de Uso (Use-Case Slice); que, por sua vez, vii) são identificadas (ou têm sua identificação facilitada) pelas Histórias.

Essas histórias, a princípio, não têm nada a ver com as conhecidas User Stories (não citadas no e-book). Mas é impossível não perceber a intenção de fazer com que elas sejam elaboradas e tratadas da mesmíssima maneira proposta por Kent Beck (em “Extreme Programming Explained” – Addison-Wesley, 1999) e amadurecida por Mike Cohn (“User Stories Applied” – Addison-Wesley, 2004). Uma História, segundo os autores, pode ser qualquer coisa: requisito funcional ou não funcional, um trecho ou fluxo(s) do Caso de Uso, um requisito especial (?) ou ainda um caso de teste. E elas, genéricas (e versáteis assim), ajudariam na identificação de Fatias de Casos de Uso.

Essas Fatias, apresentadas como “o elemento mais importante do Caso de Uso 2.0”, justificariam-se porque, segundo os autores, “precisamos de uma maneira de dividir casos de uso em conjuntos menores”. Li e reli o documento e continuo não acreditando que o próprio cara que inventou a ferramenta e seus naturais mecanismos de quebra (extensão) e organização esteja propondo tamanha confusão. Talvez meus neurônios não tenham percebido o fim das férias, sei lá. O fato é que a proposta, particularmente suas Histórias e Fatias, não parece fazer muito sentido.

Um Caso de Uso é uma maneira mais (ou menos) ESTRUTURADA² de se contar e registrar uma história, um causo. Ele sempre possui um Fluxo Principal (ou Básico), uma sequência natural de interação entre um Ator e um Sistema onde todos os passos são bem sucedidos. Todas as variações ou desvios desta sequência principal são capturados e registrados na forma de Fluxos Alternativos (ou Secundários). Está aqui o primeiro mecanismo natural de ‘quebra’ de um caso de uso. Considero-o natural porque ele reflete a forma do usuário pensar. Uma vez registrado o comportamento mais esperado, como Fluxo Principal, a história se desenrola, por exemplo, em uma sequência de “e se”: “e se o cliente não tiver crédito”, “e se não houver estoque disponível” etc³. Casos de uso são tremendamente eficazes na “descoberta e descrição de requisitos funcionais de um sistema” exatamente porque permitem que uma história seja narrada e estruturada da forma mais natural (e próxima do usuário) possível.

Por que, então, precisaríamos de outros mecanismos de quebra e organização? Para termos elementos ainda menores, que caibam em uma iteração de duas semanas ou em um post-it? Coplien e Bjørnvig, no capítulo 7 do livro citado acima, já haviam dado a receitinha: “qual é a diferença entre a lista de desvios (Fluxos Alternativos) e uma lista de requisitos, features ou User Stories? Quase nenhuma quando olhamos de perto. Podemos formular cada item da lista na forma de User Stories se isso faz com que a gente se sinta mais Agile“. Bem antes deles, no já distante ano 2000, Alistair Cockburn (em “Writing Effective Use Cases” – Addison-Wesley, 2000) já havia sugerido a derivação de uma Lista de Trabalho a partir de um Caso de Uso e seus diversos fluxos (Work List, págs. 172 – 174). Com itens que cabem perfeitamente em um post-it ou, falando mais sério, “cabem” em iterações (sprints) e facilitam o acompanhamento e gerenciamento de um product backlog ou algo parecido. Enfim, Casos de Uso nunca foram monolitos nem nunca levaram a uma situação “tudo ou nada”. Repito: nunca!

Casos de Uso também podem ser vistos ou utilizados como uma “cola que une todas as etapas de um processo de desenvolvimento” desde a criação da UML (1995-1997) e dos derivados do Processo Unificado (1998~). Não creio que serão as sugeridas Fatias que farão, agora, a mágica de viabilizar tal visão. Porque a verdade é que nós nunca (ou, para pegar um pouco mais leve) raramente utilizamos Casos de Uso em toda a sua plenitude. O faremos agora que ele ficou um pouquinho mais complicado?

?

Observações:

1. Lê-se a primeira frase destacada na apresentação “Common Chalenges in Use Case Modeling”, de autoria de Ivar Jacobson e com logo da Rational Software (sem data de publicação).
2. E é esta propriedade fundamental, o fato do Caso de Uso ser uma história ESTRUTURADA, sua principal diferença em relação a outras propostas, particularmente as User Stories. Um Caso de Uso, por natureza, é um conjunto de requisitos que faz todo o sentido para um usuário ou cliente. Um conjunto estruturado. Um conjunto que “entende” sua relação com os demais componentes da solução. Naturalmente.
3. Destaquei o primeiro (Fluxos Alternativos) mas não cito acima os demais “mecanismos naturais de quebras” dos Casos de Uso. Porque aqui a porca torce o rabo de vez e, preciso admitir, alguns mecanismos não são tão naturais assim (Extends e Includes devem ter passado pela sua cabeça). Para não deixar o tema no limbo preciso dizer que Cenários (combinações de passos dos fluxos principal e alternativos) e Casos de Testes são derivados ou componentes de um Caso de Uso e representam outras formas de “quebra”. Serão mais ou menos naturais dependendo da forma como são elaborados.
4. Slice of a Pumpkin Pie, foto que ilustra este artigo, é de autoria de TheCulinaryGeek.

?

Antes de mais nada, os créditos. A principal provocação para o novo modelo veio de “Lean Architecture” (Wiley, 2010), de James Coplien e Gertrud Bjørnvig. O casal, por sua vez, cita os trabalhos de Rebecca Wirfs-Brock (“Designing Scenarios” – Smalltalk Report, nov-dez/1993) e Constantine e Lockwood (“Software for Use: A Practical Guide to Models and Methods of Usage-centered Design” – Addison-Wesley, 1999). Me convenceram da utilidade e necessidade do uso de duas colunas nos fluxos. E provam, em seu livro, como as especificações podem ser ágeis e enxutas. Na semana passada o “pai” dos casos de uso, Ivar Jacobson, publicou um artigo sobre Casos de Uso 2.0. Dele ganhei a confirmação de que casos de uso: i) são tão ágeis quanto você; ii) escalam o quanto você precisar; iii) não tratam apenas de requisitos funcionais; iv) não se limitam a projetos de sistemas; e v) nem aos requisitos – valem em todo o ciclo de vida de um projeto. Usei todas as novas sugestões como complementos ao modelo que utilizava anteriormente e que era fortemente baseado no trabalho de Alistair Cockburn, “Escrevendo Casos de Uso Eficazes” (Bookman, 2008).

Aos iniciados, letrados e usuários super-avançados de casos de uso e afins, um aviso: o modelo aqui sugerido segue tendo como principal motivação o uso didático. Por isso, talvez o modelo não tenha nenhuma utilidade para vocês. Pensei nos iniciantes e em todos que precisam rever seus (pré)conceitos sobre a ferramenta. Me preocupei, principalmente, com todos que precisam de um tipo de guia (e de limites) enquanto aperfeiçoam sua técnica. Vamos ao que interessa.

O modelo anterior era muito pequeno (formato A5), o que impedia seu uso em casos ‘de verdade’. O novo modelo foi diagramado em formato A4 paisagem. Frente (acima) e verso (logo mais) podem ser impressos em uma única folha ou em separado, como explicarei mais tarde. A frente condensa todas as informações fundamentais sobre um caso de uso. Vou apresentá-la por partes.

Cabeçalho

Segue a preocupação com a identificação da fonte e respectivo ponto de vista (estratégico, tático, operacional ou técnico). Incorporei um sofisticado “controle de versões”. Ele me ajuda a reforçar um grito: “joga o caso no lixo! (tão logo dele tenha brotado algum derivado)”.

Finalmente me lembrei dos ícones que determinam o nível de detalhamento do caso. Não, prezadas fábricas de software (sic), não contemplei o tal nível “pré-sal” que vocês insistem em pedir. Mas a nova versão da ostra, quero crer, não gerará mais dúvidas nem piadinhas.

O campo “processo / atividade” serve para referência cruzada com algum diagrama do negócio, de preferência com o PUCS (Process-Use Case Support) ou um diagrama de atividades.

“Valor”, que talvez ainda seja rebatizado “Benefício”, indica como o cliente ou usuário valoriza o caso em questão. “Custo” é a estimativa de esforço do time de desenvolvimento (expressa em unidades relativas, pontos de casos de uso ou qualquer outra unidade de medida). A possível avaliação benefício/custo pode determinar a “Ordem”, a posição do caso no cronograma (ou, de preferência, no backlog do produto). Daí o espaço “Iteração”, onde deve ser registrado a iteração projetada para o trabalho neste caso. Quem não “itera” pode ignorá-lo, sem problemas.

Contexto, Pré e Pós-Condições

Não se trata de um filler, vulgo “encheção de linguiça”. O Contexto nos ajuda a posicionar o caso de uso no projeto, indicando suas relações com outros elementos. É aberto para possibilitar até mesmo o desenho de um pequeno diagrama de casos de uso. Mesmo que fujas dos temidos (e mal compreendidos) extends e includes da vida, você deve achar alguma utilidade para o espaço. Pré e pós-condições não pedem por maiores explicações. Ah, só preciso dizer que elas são um tipo muito especial de Regras de Negócio. Regra do negócio, e não aquele papo de “o usuário tem que estar logado no sistema (sic)”. Pronto, disse.

Fluxo Principal

A conversa devidamente explicitada. Eu evitava o modelo com duas colunas por morrer de medo daqueles que acham que, para cada intenção do ator o sistema deve, obrigatoriamente, dar uma resposta. Desperdício imperdoável de tempo que culminava em obviedades assim: Ator: Indentificar Cliente / Sistema: Exibir nome do cliente. Terrível! Mas Coplien e Bjørnvig me convenceram de que, apesar dos mestres do óbvio, este modelo é realmente mais eficaz.

Ainda assim, o espaço disponível para descrição dos passos do ‘caminho feliz’ segue exíguo para todos aqueles que não acreditam nos limites sugeridos por Coplien (máximo de 7 passos) ou Cockburn (máximo de 9 passos). Só evitei numerá-lo, como no modelo antigo, para deixar o formulário um pouco menos poluído.

Fluxos Alternativos / Instruções para Testes

Está aqui o trecho que mais me custou mais tempo. O número de fluxos alternativos pode ser muito grande, dependendo do caso de uso. Mas a questão não era só essa. Queria contemplar também um espaço para um tipo de Caso de Testes. Acho que consegui matar os dois coelhos. O trecho acima aparece na parte da frente do modelo e em metade do verso. Por isso eu disse que o verso pode ser impresso de forma independente. Ele também contempla outras regras de negócios e outros tipos de requisitos. Quando o espaço não for suficiente, basta imprimir ou utilizar mais páginas apenas com o verso do modelo. Aos campos.

Indicamos o número do passo afetado e o tipo de registro (fluxo Alternativo o Teste). Na sequência, o motivo para o desvio ou então alguma instrução para a execução de testes. Há ainda uma coluna para comentários e outra para a indicação da iteração que deve contemplar a realização deste fluxo alternativo. Esta ideia combina bem com os slices propostos por Ivar Jacobson no referido artigo. Combina ainda mais com as sugestões apresentadas em “Lean Architecture” (em resumo: em um projeto tocado por um método iterativo, os incrementos são fluxos dos casos de uso. Ex: em uma iteração você entrega o fluxo principal, na seguinte dois fluxos alternativos e assim por diante).

Se a ferramenta é escalável, como confirma Jacobson, o modelinho também deve ser. Daí a diagramação do verso, exibida abaixo.

?

Utilizarei este modelo nas próximas edições de meus treinamentos. Acho que só depois de duas ou três experiências terei noção das alterações necessárias. Ou seja, novidades sobre o tema só no final de novembro. Enquanto isso, se você quiser brincar um pouco com o modelo, faça o download aqui: bit.ly/UCfinito. Claro que estou contando com seu retorno, experiências, críticas e sugestões. Desde já agradeço. Abraços!

Obs.:

1. Nunca antes na história deste blog o nome de uma imagem combinou tanto com o conteúdo. “Extracting Knowledge” é de autoria do HikingArtist e foi legalmente surrupiada no Flickr.
2. Depois de meus canhotos rabiscos, todo o trampo artístico e de diagramação foi do mano Gus Vasconcellos, da Opção Artes Gráficas. Não sei o que seriam de meus rabiscos sem a colaboração dele.

Arquitetura¹: concebida com o propósito primordial de organizar espaço para determinada finalidade e visando a determinada intenção.

Este artigo é uma modesta provocação. E uma tentativa de transcrever a palestra “Arquitetura do Negócio: Enxuta & Ágil” que apresentei no último Agile Vale. É que alguns assuntos pedem para ser espalhados. Se você se interessa por arquitetura corporativa, arquitetura de negócios, arquitetura de software, DDD, DSL, métodos ágeis e pensamento enxuto (lean), talvez encontre algo de útil no meio deste longo texto.

?

Peço sua atenção para a definição de arquitetura acima. Particularmente para os termos espaço, finalidade e intenção. Quando arquitetamos algo, nós “organizamos um espaço para determinada finalidade visando a determinada intenção”. Preciso voltar também para um conceito que já apresentei aqui no {finito}, a Tríade Vitruviana. Ela fixa três critérios fundamentais para avaliação de uma arquitetura:

• Firmitas: a construção é estável, robusta e sustentável;
• Utilitas: a arquitetura é funcional; e
• Venustas: é bela.

A área de TI gosta de adotar termos de outras áreas de conhecimento. Seria legal se, além dos nomes, adotássemos também os conceitos básicos. Já tem um tempinho que acolhemos o termo “arquitetura”. Recentemente, passamos a falar bastante sobre Arquitetura Corporativa. Acho que indicamos que através dela “organizamos espaço para determinada finalidade e visando a determinada intenção”. Qual espaço?

TI organiza dois espaços, a saber: i) Arquitetura Tecnológica – hardware, infraestrutura de rede e software básico. Significa o que a organização possui; ii) Arquitetura de Informações – bases de dados e repositórios de informações não estruturadas. Indica o que a organização sabe. Esses espaços são organizados “para determinada finalidade”. Qual finalidade?

TI atende a ou oferece um sem número de finalidades, de funcionalidades. O faz através de sua Arquitetura de Sistemas, que representa todas as aplicações, ou seja, o que a organização faz. E faz esse tanto de coisa porque está “visando a determinada intenção”. Que intenção?

Chegamos naquela parte da tal Arquitetura Corporativa que justifica tudo, inclusive a própria existência de TI. É a Arquitetura do Negócio, aquela que explica a intenção – para quem e porque a organização faz (oferece sistemas), sabe (informações) e possui (aquele tanto de ferro e software básico). No longínquo mundo ideal, não deveria haver um único centavo gasto em qualquer das três camadas inferiores que não fosse rastreável até a arquitetura do negócio, comprovando um benefício real e mensurável. Sendo assim, é factível supor que tudo começa (e deveria terminar) aqui, na Arquitetura do Negócio. Do que ela consiste?

Todo e qualquer negócio, independente do porte ou ramo de atividade, é formado por quatro elementos básicos: Objetivos, Recursos, Processos e Regras. Mas estamos falando de Arquitetura do Negócio, o que nos leva novamente para a preocupação de “organizar espaço para determinada finalidade visando a determinada intenção”. O espaço que organizamos é a estrutura da empresa – as pessoas, instalações, móveis, veículos, enfim, todos os seus recursos². A finalidade é representada por todo o seu conjunto de processos, por toda a sua parte dinâmica. Finalmente, a intenção é o grupo de objetivos da organização. Colocando de outra maneira: organizamos os recursos (espaço) de uma empresa de forma que os permita executar ou viabilizar a execução de processos (finalidade) visando a alcançar determinados objetivos (intenção).

Ao representar a arquitetura de um negócio, mesmo sem querer, sempre utilizamos três visões ou combinações entre elas. A visão do negócio trata dos objetivos, da intenção. A visão da estrutura nos mostra os recursos, o espaço. E a visão dos processos nos dá a finalidade. As representações podem ser ultrasofisticadas ou de uma simplicidade risível. Não é minha intenção debatê-las aqui, agora. Mas, para fins ilustrativos, entenda que um organograma é parte da visão da estrutura, enquanto um fluxograma pode compor a visão dos processos. Balanced Scorecards ou simples listas de objetivos representam a visão do negócio. O que nos interessa neste ponto é a “organização do espaço para determinada finalidade visando a determinada intenção”. Hora de agitar o coreto.

Muito falamos sobre a dinâmica, a velocidade das mudanças, e a complexidade do atual mundo dos negócios. O que muda tanto? E o que é complexo? Será que tudo?

Jurgen Appelo, no livro “Management 3.0” e falando sobre a teoria da complexidade, sugere um modelo para estudos: o modelo da Estrutura-Comportamento³. Ele escreveu que nos equivocamos quando intercambiamos os termos “complexo” e “complicado”. E afirma que o que é complexo não é passível de simplificação. Me esforçarei para deixar o papo menos maluco (e menos abstrato).

Quando tratamos de uma estrutura, o que está em jogo é nossa habilidade para entendê-la. Portanto, uma estrutura pode ser simples ou complicada. Neste sentido um casamento, por exemplo, é uma estrutura simples. Ele envolve, na teoria e em seu início, apenas dois elementos. Por outro lado, uma empresa ou uma cidade possuem uma estrutura complicada – difícil de entender.

Em outra dimensão está o comportamento e o que é exigida é nossa capacidade de prevê-lo. Um relógio, por complicado que seja (em sua estrutura), tem comportamento bastante previsível. Dizemos que seu comportamento é ordenado. Diferente do casamento, que apesar da estrutura simples, pode resultar em comportamentos bastante complexos. Nesta dimensão temos ainda uma terceira “ordem de grandeza”, o caos. O trânsito de nossas grandes cidades, por exemplo, tem comportamento caótico – ele é praticamente imprevisível. E, só para fechar o exemplo, a estrutura destinada para esse mesmo trânsito não tem nada de simples. Ela é complicada. Uma estrutura é passível de simplificação. Já o comportamento, com certa dose de boa-fé, poderia ser linearizado (o que é complexo ou caótico poderia ser ordenado).

Coreto devidamente agitado? E o que esse papo sobre complexidade tem a ver com arquitetura? Tudo!

A “estrutura” do papo acima é o espaço que organizamos. Voltando para a arquitetura do negócio, trata-se exatamente da visão da estrutura, de todos os recursos utilizados por uma organização. E a dimensão do comportamento representa a finalidade da arquitetura, as ações que ali devem ocorrer. No domínio (!) do negócio, refere-se à visão dos processos.

Um negócio, qualquer negócio, é um Sistema Adaptativo Complexo. O modelo proposto por Appelo nos ajuda a estudá-lo. Sistemas de informação são igualmente adaptativos e complexos. O modelo “Estrutura – Comportamento” nos ajudaria a arquitetá-los? No mínimo, como tentarei mostrar abaixo, justificaria uma “nova” maneira de pensar.

Quando falamos, geralmente reclamando, sobre a dinâmica dos negócios, devemos entender que o grande volume de mudanças ocorre na dimensão comportamental, ou seja, nos processos. Posso apelar para Pareto? Então vamos fixar que 80% das “mudanças organizacionais” (sic) referem-se às alterações na forma de trabalhar, nos processos de negócios. O restante significa, de fato, alteração na estrutura (demissões, remanejamentos, fusões & aquisições etc).

Acima eu escrevi que também vivemos reclamando da complexidade dos negócios. Novamente o modelo proposto pelo Appelo nos ajuda a separar o joio (estrutura, no máximo complicada) do trigo (processos, de fato complexos ou até mesmo caóticos). Fiquei com vontade de usar outra metáfora.

Ao desenhar sua casa, você separou generoso espaço (!) para montar seu sonhado home office (finalidade!). Mobiliou-o com tudo de bom e do melhor e ficou realmente mais produtivo (intenção!) naquela zona (no bom sentido) de conforto (no melhor sentido possível). Mas eis que vem a notícia de um filhinho não planejado e lá se vai o querido escritório de volta para a garagem. Aquele generoso espaço ganhará nova finalidade. Ele mudou? A menos que você tenha derrubado paredes e redimensionado outros cômodos, você não mexeu no espaço – na estrutura da casa. Foi só a finalidade daquele espaço que mudou.

Uma estrutura, mesmo quando mal e porcamente concebida, é mais estável que o comportamento. Ou, colocando de outra forma, a estrutura é menos instável que os processos. Então, por que será que nossos sistemas de informação raramente refletem essa separação? Até que ponto nossa indisciplinada mistura de forma (espaço) e funcionalidade (finalidade) é responsável pelos altíssimos custos de manutenção e pela dificuldade de adaptação dos sistemas ditos “legados”? Prometo parar por aqui com as questões retóricas. O que vem a seguir é uma proposta para pensar arquitetura de sistemas de uma maneira diferente.

Arquitetura Enxuta & Ágil

Se não ficou claro, apesar (ou exatamente por causa) de minha verborragia, nosso objetivo é fazer com que um sistema reflita e respeite a separação entre estrutura e comportamento. Vamos diferenciar o que o sistema é do que o sistema faz.

Já tem um tempinho que utilizamos classes para representar coisas do mundo real. Apesar de chamarmos isso de “Orientação a Objetos”, o fato é que nossa programação é mesmo orientada a classes. Não importa. Aprendemos nas escolas da vida que um objeto deveria encapsular sua estrutura (atributos) e comportamento (métodos). Temos outro probleminha aqui. Se desejamos representar elementos da estrutura do negócio, então deveríamos esquecer todo esse papo de encapsular comportamento. Essas classes e respectivos objetos que definem o que o sistema é devem ser ignorantes em relação a tudo o que se refira a ação. Quando muito, sabem um CRUDzinho básico. O cliente Mané, por exemplo, não sabe o que é comprar livro ou colocar livro no carrinho de compras. O Mané não sabe nada! Mas pode aprender!!

Todas as ações, serviços ou funcionalidades, compõem o que o sistema faz. No diagrama ao lado, todas essas interAÇÕES são representadas por papéis (roles). Existem dois tipos: aqueles que sabem o que fazer (methodful roles) e aqueles que só fingem que sabem (methodless roles). A distinção entre os papéis que sabem (methodful) daqueles que fingem saber (methodless) é muito importante. Os últimos funcionam apenas como interfaces. E nós esperamos que as interfaces sofram bem menos alterações do que os métodos propriamente ditos. Novamente a intenção é separar nitidamente aquilo que muda com mais frequência daquilo que pouco se altera no decorrer do tempo. Mas, afinal de contas, do que tratam esses papéis? Simples, são eles que sabem comprar livro ou colocar livro no carrinho de compras, por exemplo.

Pronto! Agora temos atores (classes e objetos dispostos no lado esquerdo do diagrama) e papéis. Falta dar-lhes um roteiro.

Peraí Paulo: ou seu exemplo não é lá essas coisas ou então o papo é bem furado mesmo. Afinal, comprar livro ou colocar livro no carrinho de compras não são ações extremamente simples?

Ações ordenadas ou bastante previsíveis, você quis dizer, certo? Vamos lá: imagine que nosso querido Mané, apresentado ali em cima, seja um cliente preferencial. Como tal, ele tem direito a descontos em todas as compras. Quando ele vê um livro, já sabe seu preço normal e o desconto que merecerá. Ao mesmo tempo, a loja já sabe que o Mané prefere pagar com cartão de crédito. O que significa, além de outras coisas, um prazo menor de entrega. Já o cliente (objeto) José é bem diferente: mal se identificou (a loja ainda não sabe nada sobre suas preferências) e está prestes a fazer sua primeira compra. Os ROTEIROS que Mané e José seguirão são consideravelmente diferentes. Apesar de ambos apenas desejarem comprar o último best-seller da Bruna Surfistinha.

Ok, o exemplo continua meia-boca. Mas espero que você tenha entendido o fundamental: interAÇÕES bem distintas acontecerão em ambos os casos. Os atores José e Mané desempenharão papéis diferentes.

Primeiro ponto, aquele que ficou aberto seis parágrafos acima: como Mané e José “aprenderão” a comprar livro ou colocar livro no carrinho de compras? Primeira “mágica”: aquele conhecimento (comprar ou colocar) será INJETADO nos dois clientes (objetos). O termo injetado é muito bom. Lembra-se como Neo, no filme Matrix, aprendeu a lutar kung-fu? Pois é, o conhecimento foi injetado na nuca! É mais ou menos o que estamos fazendo aqui, ensinando (em tempo de execução!) um elemento da estrutura a executar determinada ação.

Não disponho de tempo, espaço e nem competência para entrar em detalhes técnicos desta sugestão. Só me cabe dizer, por enquanto, que tal “mágica” é possível tanto em linguagens OO mais antigas (como C++) quanto em modernosos dialetos mais dinâmicos (como Ruby). Já já te falo onde encontrar exemplos de código, se isso te interessa.

De interesse mais geral deve ser nosso segundo ponto, gritado quatro parágrafos acima: o ROTEIRO. Agora ele merecerá outro nome, um pouquinho mais técnico: Caso de Uso. Estranho como algumas pessoas perdem o sentido da palavra “caso”. Gosto de provocá-las usando um termo caipirão, “causo”. Um “causo” é uma história curta, enxuta. Para nós, é uma história de interAÇÕES, sobre o USO de alguma coisa, sobre FUNÇÕES executadas. Portanto, nosso roteiro (ou script) é redigido na forma de uma especificação de caso de uso. E, em tempo de execução, este mesmo roteiro se transforma em um objeto. Objeto que tem um nome bem especial: CONTEXTO. Mané e José, nossos honoráveis clientes (objetos), desempenharão alguns papéis diferentes e outros semelhantes dependendo do Contexto.

Tempo para uma breve releitura. Você ainda está aqui? Puxa, muito obrigado. Vamos lá:

Mané e José mudarão muito pouco no decorrer do tempo. Alguns de seus atributos, como endereço ou telefone, podem ser alterados. Sua idade, com certeza, mudará a cada ano. Mas isso não significará nenhum tipo de mudança em sua forma. Já os papéis, as interações ou processos de negócios, podem sofrer mudanças com grande frequência. A porção mais volúvel de um negócio, suas regras, estariam praticamente todas concentradas nos papéis com real conhecimento (methodful roles). Assim, ao contrário do que vemos em grande parte dos sistemas de hoje (ou seria de ontem?), as mudanças ficam concentradas em um só lugar. Elas não gerarão impactos em um sem número de classes e outros elementos. Neste desenho, podemos agregar novas funcionalidades sem gerar praticamente nenhum impacto nos elementos já constituídos. Um novo cenário em um caso de uso é só isso, um novo roteiro – que costura e direciona como os atores desempenharão seus papéis em um novo contexto.

Hora de dar nome e crédito à proposta apresentada acima. DCI, de Data, Context and Interaction, é o nome da criança. Criança mesmo, que mal tem cinco anos de vida. A primeira parte, Data (Dados), representa a estrutura (o espaço). Já as Interações representam as finalidades, a arquitetura funcional. E o Contexto, por fim, junta tudo. Este paradigma foi sugerido por Trygve Reenskaug, sujeito que tem em seu currículo outro padrão arquitetônico, amplamente conhecido e aceito: o MVC (Model-View-Controller). Já havia apresentado o tema aqui, quando comentei o livro “Lean Architecture“, de James Coplien e Gertrud Bjørnvig. Para você que quer ver e experimentar um pouco de código, creio que este livro seja o melhor ponto de partida.

UMA Arquitetura

Muito provavelmente é pura burrice de minha parte, mas quando vejo (de soslaio) altos papos sobre DDD (Domain-Driven Design), DSL’s (Domain-Specific Language) e afins, enxergo pouco ou nenhum NEGÓCIO. Eu sei, os conceitos são amplos demais e não pretendem apenas tratar de sistemas para negócios. Mas eu desconfio que um pouquinho de proximidade não faria mal nenhum, muito pelo contrário. Por isso o DCI, particularmente da forma como foi trabalhado por Coplien e Bjørnvig, me chamou tanto a atenção. Percebi ali uma nítida preocupação com o domínio, a complexidade e a dinâmica dos negócios. Mais que isso, vi naquela proposta uma extensão lógica e natural – o que tentei demonstrar aqui. Arquitetura do negócio e de sistemas podem ser vistas como UMA única arquitetura. É certo que estou sendo tendencioso e otimista demais. Se DCI demorar tanto quanto o MVC para “pegar”, com certeza não estarei por aqui para ver o resultado. O MVC é de 1978!

Mas eu sou um incurável otimista. Ao testemunhar como ideias “agile” e “lean” se espalham, fico na esperança de ver mais conversas práticas e pragmáticas ganharem espaço nas agendas de todos os envolvidos com sistemas de informação. Preciso achar espaço para registrar uma preocupação. Será aqui mesmo: não basta ser “ágil” pra caramba e entregar na metade do tempo aquele maravilhoso produto, realizando um pseudo e imediatista valor. Teu ROI (sic), prezada(o) leitora, derretará mais rápido que bolsa de valores em tempos de crise se:

1. Teu rebento, aquele produto, exigir mudanças estruturais toda vez que o negócio evoluir;
2. O tempo tornar seu produto ilegível e incompreensível para os olhos de outrem;
3. Seu produto pedir por duas ou três iterações toda vez que um novo cenário ou papel for necessário.

É curioso e divertido acompanhar como a combinação dos termos “agile” e “lean” tem evoluído. Enquanto algumas dicotomias caem por terra, surgem novos confrontos e contradições. Coplien e Bjørnvig não hesitaram ao colocar várias lenhas nesta estimulante fogueira. Por exemplo:

• Pensar antes não significa FAZER antes. E se você é realmente “lean”, você PENSA antes de fazer;
• Pensar arquitetura != BDUF (Big Design Up Front).
• Esse papo de postergar uma decisão para o último momento (responsável) é perigoso. Porque é difícil descobrir que momento é esse. Mais lógico é decidir na hora em que a decisão é realmente necessária e pronto.
• Lean é baseado em “uma cultura de parar ou desacelerar de forma a obter qualidade no primeiro momento e maior produtividade no longo prazo.” (Jeffrey Liker, em “The Toyota Way” – McGraw-Hill, 2004);
• Pensar “lean” é ver o todo – daí minha preocupação que acabou tornando este artigo um recorde pessoal (2.730 palavras até aqui!). Tentei mostrar como Arquitetura do Negócio e Arquitetura de Sistemas compartilham fundamentos (Espaço, Finalidade) e, principalmente, Intenção;
• Pensar “lean” é ser sustentável – é ter sincera preocupação com o amanhã, com a evolução de um sistema que responde sem ressalvas nem soluços à dinâmica do negócio;
  
• E ser “ágil”, nos ensina o Manifesto, é “responder a mudanças” (além de outras coisas, claro);
  
• “TDD (Test-Driven Development) pode deteriorar a arquitetura”; e
• Como sou um chato incorrigível, vou citar até uma lenha aparentemente menor: o que é mais fácil administrar e entregar, 300 e tantas histórias (User Stories) ou 20 e tantos casos de uso?

?

Céus, quase três mil palavras e você ainda está aqui? Espero que de fato aproveite alguma coisa no meio de tanta prosa. Sabe o que é pior? A sensação de mal ter explorado todas as possibilidades do tema. Pior ainda? Aceitar o fato de que minha contribuição não irá muito além disso aqui. Não vou codificar exemplos e é pouco provável que eu participe, mesmo que como observador, do desenho de uma arquitetura conforme sugerida por Reenskaug, Coplien e Bjørnvig. Resta te pedir que me avise sempre que perceber qualquer coisa parecida passando por perto, ok? Tks!

Observações:

1. Trecho da definição de arquitetura proposta por Lúcio Costa e surrupiada da Wikipédia.
2. Não é lá muito “ágil” esse negócio de chamar pessoas de recursos. É feio, eu admito. Mas, por favor, entenda que no frio da teoria uma pessoa pode ser sim um RECURSO utilizado por uma empresa para determinada finalidade e visando a determinada intenção. O que deveria de fato importar é que a empresa não trate uma pessoa da mesma maneira como trata uma mesa ou um carro enguiçado. Mas tem gente que gosta de briga e não será um recurso nunca! Nem no melhor sentido da palavra.
3. Por uma questão de brevidade (haha!) me limitei a citar o modelo Estrutura-Comportamento proposto por Jurgen Appelo. Saiba que ele compara sua sugestão com dois modelos um pouco mais conhecidos, o Cynefin proposto por David Snowden e o modelo da Concordância & Certeza (Agreement & Certainty) proposto por Ralph Stacey. Jurgen insiste para que recebamos todas essas propostas sempre com um pé atrás: “todas estão erradas… mas algumas são úteis”.
4. “Spil-skitse-tegning” é o cartoon que aparece lá no longínquo topo do artigo. Pra variar, é do HikingArtist.
5. Ah sim, caso interesse, está aqui a apresentação utilizada no Agile Vale 2011. Como alertei a amiga Simone, ela deve ser ininteligível se não acompanhada da prosocopeia acima.

Tentarei ilustrar a situação com uma breve história.

.:.

Era uma vez uma empresa de médio para grande porte repleta de sistemas. Como é tradicional, a parte “feijão com arroz” do negócio (processos de apoio – financeiro, contábil, RH…) foi informatizada com um pacote ERP; A parte “filé com fritas” (processos primários – vendas, atendimento…) é um combinado de módulos desenvolvidos internamente com algumas soluções de terceiros. Antenada por necessidade, a empresa em questão, que chamaremos de ACME, já usa mas pouco abusa de conceitos modernos como SOA, BPM e BI.

Assim como acontece em praticamente todas as organizações ao redor do globo, a “Arquitetura Corporativa” da ACME assemelha-se ao retrato do inferno devidamente registrado por uma câmera de 12 megapixels. Consequência natural de anos e anos de projetos “para ontem”, adoção de caixinhas mágicas, fornecedores famintos e voluntariosos e algumas pitadas de modismos. A receita pode variar um pouquinho de empresa para empresa, mas o prato parece ser sempre o mesmo. E é indigesto.

A demanda por manutenção (80%) e novas aplicações (20%) é sempre maior que a capacidade instalada. Fornecedores devidamente homologados adoram essa parte. Afinal, “fábricas de software” (sic) foram inventadas para isso mesmo, certo?

Software é um elemento vital para a ACME. Aliás, deve ser para 80% das empresas. Mas ele ainda não é visto como ativo, como conhecimento. Software é contabilizado como despesa. E é tratado como tal: um mal necessário. Então a ACME brinca de fazer de conta que mantém o cérebro e terceiriza membros, mais precisamente os braços. Traduzindo: uma equipe interna definiria o que precisa ser feito; o “como” e respectiva construção seriam executados por “parceiros”. (Há palavra mais maldita que essa em nosso mundo?)

Acontece que o cérebro é pequeno e fica cada vez menor. Para cada neurônio disponível para “coletar requisitos” (sic), existem dezenas ou centenas de usuários putos da vida, atrasados, indecisos e com hora marcada no psicólogo. Quando muito, uma reunião(zinha) de 1 hora é tudo o que o neurônio tem para entender o que o usuário quer. Desse entendimento nasce um briefing. E dele extrai-se um “cheiro” que, como num passe de mágica, vira compromisso de prazo e custo. Tudo acontece tão rápido que o neurônio nem tem tempo de suspirar.

Com um olho na fila de usuários que aguardam sua vez de choramingar requisitos, o neurônio repassa para o parceiro selecionado por um critério qualquer aquele conjunto de parágrafos desconexos apresentados anteriormente como briefing. Sim, a escassez de neurônios é tamanha que cabe ao parceiro “fechar o escopo” (sic). Com um pouco de insistência e um tanto de sorte o parceiro consegue um ou dois encontros com usuários para desenvolver “casos de uso”. O papo é menos belicoso que aquele entre usuários e neurônios porque o parceiro é “de fora”. Mas, talvez para mitigar riscos de rusgas, o parceiro sempre manda um analista diferente. O rodízio deve seguir a lógica do namoro de jogador de futebol. Mas os usuários já se cansaram de dizer que “eu já expliquei isso antes…”

Tão logo o parceiro se manifeste satisfeito com as informações coletadas (implicitamente ele tá de saco cheio daquelas idas e vindas), tem início um hiato de duração indeterminada (apesar do cronograma assinado).

É marcado para um belo dia (e precisa ser belo mesmo – porque, se ameaçar chover, o parceiro nem tira o carro da garagem) a apresentação do projeto. Dependendo da cara (e do bolso) do sponsor, o evento tem lá suas regalias. Na maior parte das vezes, é só um encontro do parceiro com alguns usuários e um cafezinho. O neurônio autor do briefing é convidado a participar. Claro, se ele ainda estiver na folha de pagamentos da ACME.

O encontro é tenso. Já começa nervoso. E os usuários não colaboram com o clima: “Nossa, atrasou tanto desta vez, né?”

Num caso específico a apresentação começou por uma parte bem complicada do projeto: uma tela de cadastro de clientes. O usuário do departamento de marketing mal esperou a tela acabar de ser “renderizada” (sic) e já reclamou: “Nossa logomarca sofreu pequenas alterações há 6 meses. Adequação para a nova realidade Web 2.0 e patati patatá…”. Foi interrompido. O parceiro falou que ninguém avisou. “Mas é uma pequena alteração besta…”, disse, tentando encerrar o assunto. Afinal, o importante era o conteúdo! O cara do marketing não concordou, mas silenciou.

Para testar o conceito de usabilidade o parceiro pediu que um outro usuário, sem nenhum treinamento, fizesse o cadastro de um cliente. Claro, ele escolheu a menininha mais bonitinha que estava na sala. E quase pegou em sua mão para guiar o mouse na direção do botão “Incluir”. “Por que esse botão tem a cor diferente dos outros?”, questionou a bela. Não mereceu resposta, mas seguiu em sua nobre tarefa.

Até que, após digitar nome, CPF e logradouro do namorado (para infelicidade do parceiro), se deparou com uma combo box onde ela deveria selecionar a Unidade da Federação. Clicou na setinha e viu uma lista mais ou menos assim: SP, BA, MG, RJ, DF, RS, SC, AC, RR, PA, MS, AM…

Não se sabe quem disparou primeiro, se o neurônio, a bela ou o cara de marketing. Talvez tenha sido um coro: “Caramba, por que a lista não está ordenada?”

O parceiro engoliu seco e sacou da mochila importada um calhamaço manchado e cheio de dobras que apresentava na capa a logomarca da ACME (desatualizada) e o nome do projeto. Passou pelas (33) páginas do caso de uso em questão – de trás para frente e de frente para trás – e cravou: “Não tá escrito aqui que a lista deveria ser ordenada. Isso é mudança de escopo!”

.:.

A história acima é uma ficção baseada em fatos reais. Só as trechos mais exagerados são verdadeiros.

A foto utilizada, “Lift Shaft Within the Old Town Hall Tower”, foi devidamente surrupiada de lostajy. Ela foi liberada com licença Creative Commons.

Antes, os créditos: foi o André Wolff quem deu a sugestão de usar um desenho parecido com aqueles mapas que apareciam nos livros da Wrox. E algumas caixinhas acima só apareceram por causa de depoimentos (e desejos) dos colegas Leandro e Ronan.

Talvez o meu rabisco não dê esta impressão, mas ainda há muito espaço a ser preenchido ali. Tentei destacar o fundamental, inclusive no tópico ‘Formação Complementar’. E, claro, não contemplo nenhum treinamento de ‘Habilidades Sociais’ (Soft Skills). O desenho trata exclusivamente de ‘Habilidades Técnicas’ (Hard Skills). Cabe uma breve descrição de cada caixinha:

FAN – Entendendo o Negócio é o programa que ‘roda mundo’ há pouco mais de um ano. Sua versão ‘oficina’ (workshop – 7 horas) dá uma visão geral de tudo que está inserido no tema “Modelagem de Negócio”. O curso (35 horas) permite o detalhamento e prática de alguns temas, particularmente a modelagem de negócios com UML e sua extensão EPBE (Eriksson-Penker Business Extensions).

A relativa complexidade da EPBE e, principalmente, da Modelagem de Negócios, justifica a existência de um módulo avançado, o FAN – Modelando Negócios com UML/EPBE. Imagino um curso 100% prático, com a modelagem de um negócio “inteiro”. Teria algo entre 32 e 40 horas. Imagino… teria… Sim, por enquanto este módulo é só uma idéia.

FAN – Business Patterns  segue no mesmo caminho. Só o livro de Eriksson e Penker apresenta algumas dezenas de patterns. Debatê-las e praticá-las em um treinamento faz todo o sentido. O problema aqui é nosso nível de maturidade quando o assunto é modelagem de negócios. Ou seja, é idéia para a próxima Copa do Mundo. E olhe lá!

Apesar de meu “apego” à EPBE, não posso ignorar a crescente demanda por profissionais que dominem a Modelagem de Processos de Negócios com BPMN. Não tenho condições de oferecer tal treinamento. Por isso este módulo não tem a marca “FAN”. É o mesmo caso do Modelagem com Aris/EPC.

Destaquei dois módulos em Formação Complementar que estão diretamente relacionados com a Modelagem de Negócios: i) Balanced Scorecards & Mapas Estratégicos, ferramentas que enriquecem consideravelmente um modelo de negócios – facilitando o entendimento de objetivos, metas, oportunidades e problemas; e ii) BPM (Business Process Management), um universo em si. Tanto que, neste ponto, imagino apenas um treinamento de introdução ao BPM. Reparem, BPMN está em outro canto.

Segurei a tentação de colocar caixinhas SOA e Arquitetura Corporativa aqui por dois motivos: estamos tratando da Formação de Analistas de Negócios. Lotar o módulo Formação Complementar pode gerar muita dispersão de atenção. Mantive o básico. Pelo menos, enquanto as duas áreas de cima não estiverem melhor resolvidas. Vamos então ao amplo e “polêmico” módulo Engenharia de Requisitos:

FAN – Entendendo o Usuário também faz parte do programa que tenho apresentado. A oficina (7 horas) trata do básico, com ênfase no Desenvolvimento de Requisitos. O treinamento de 35 horas permite uma maior exploração de algumas técnicas, particularmente a especificação de casos de uso e a realização e facilitação de entrevistas, sessões JAD etc.

Como temos visto no fórum, o tema ‘Casos de Uso’ é mais cabeludo e incompreendido do que imaginamos. Por isso ele merece um módulo adicional, Escrevendo Casos de Uso, que desenvolvo há 2 meses. Deve se transformar em um curso prático, de 40 horas. Isso tudo? Sim, pelo que descobri, o tema merece. Mas deve existir uma versão oficina (7 horas) também.

E faz todo o sentido que o roadmap contemple também o módulo Escrevendo Users Stories. É uma alternativa aos casos de uso. Tenho lá minhas restrições, mas não posso ignorar sua adoção e eficácia em alguns projetos. Só não me habilito a formatar e oferecer tal treinamento.

Assim como, por enquanto, me manterei relativamente distante do Gerenciamento de Requisitos. É importante destacar que quando falo Gerenciamento de Requisitos estou falando também de Gerenciamento de Mudanças.Coloquei aqui apenas dois módulos: No OpenUP e No Scrum. (Obs: “No” não está em inglês, ok?).

Derivam deste último módulo duas sugestões para a formação complementar: Gerenciamento de Projetos e Scrum. Não é para o AN se bandear para o gerenciamento de projetos, please! Acontece que suas atividades se entrelaçam demais com aquelas de um gerente de projetos. É legal que ele conheça a disciplina de uma forma mais ampla.

Por fim, abri um módulo que é meu “xodó” mais recente: uma oficina que exercite exclusivamente as diversas técnicas de descoberta, aprendizado e descrição de requisitos: Entrevistas, JAD, 6 Hats…  Xodó meu, não sei se há demanda. Quero crer que sim. É outro item de meu backlog que anda clamando por atenção. Sua aparição aqui pode dar o empurrão necessário.

Aliás, a grande motivação para este post é exatamente essa: empurrões! Algumas definições & idéias! E, claro, uma deixa-provocação: será que alguém (alguma instituição) consegue oferecer todo esse roadmap como um programa único? Alguém aí quer tentar preencher as caixinhas não assinadas? E colocar novas caixinhas? É isso. Inté!

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).

Minha palestra foi a segunda, logo depois do Adail. Baita responsabilidade mas, por outro lado, peguei a platéia devidamente aquecida por TOC, Corrente Crítica e as boas sugestões do Adail. Aliás, antes que eu mergulhe nos meus assuntos, vale dizer que o evento é muito rico exatamente pela diversidade de temas e visões. O Papo apresentou o OpenUP e o Juan (como um maestro na foto ao lado), falou sobre Scrum.

Eu não hesitei nada quando, há mais de um mês, decidi que meu tema seria “Engenharia de Requisitos”. Só coloquei uma tagline na apresentação da palestra: “Uma Visão Prática”. Depois de algumas oficinas, eu sabia que deveria colocar o assunto para um público um pouco diferente: os Coordenadores e Gerentes de Projetos. Tinha umas 3 “provocações” para apresentar… e, como esperado, criei caso.

Antes preciso falar que a execução consecutiva de oficinas (com 7 horas de duração) está me deixando “destreinado” em palestras. O ritmo é totalmente diferente. As interações, na palestra, só ocorrem no finalzinho, no tradicional momento “Q & A”. Mas errei feio: minha palestra deveria terminar às 12h20. Levei um susto quando olhei o relógio e vi que ainda restavam uns 30′ e eu só tinha mais uns 4 slides… de um total de 64! Falei mais rápido do que o normal. Isso sem contar que alguns slides-piadinhas-de-gosto-duvidoso não ficam 10″ no telão (e que telão tem o auditório da FIAP, imenso!). Mas, para minha satisfação, o momento “Q & A” durou quase meia hora. Satisfação dupla: preenchi o “buraco” de tempo e, claro, confirmei que as provocações surtiram efeito.

Provocações: i) Caso de Uso não é documentação; ii) Matriz de rastreabilidade não é solução; e iii) Engenharia de Requisitos não significa burocracia e falta de agilidade. Foram as 3 explícitas. A que mais gerou debate, claro, foi a primeira. Principalmente quando eu disse que não consigo entender quando alguém me explica que “levanta os requisitos e depois escreve os casos de uso”. Melhor, o bicho pegou mesmo quando eu falei que jogo os casos de uso no lixo tão logo eles tenham cumprido sua nobre utilidade: ajudar equipe e usuários e clientes a *aprender* os requisitos. Até de “agilista” eu fui chamado, vejam só! hehe.. “Você está dizendo que só o código basta como documentação de um sistema?” Claro que não foi o que eu disse.

Caso de Uso é uma ferramenta fantástica. Sem enrolação, e quando bem desenvolvida, ensina o QUE precisa ser feito; tendo o usuário como ponto de partida. Permite que a gente extraia e estude uma parte específica (tarefa ou atividade) de um processo de negócio sem desmontá-lo e sem a necessidade de novos termos ou metáforas. Repito: Caso de Uso é uma ferramenta fantástica. Mas… como documentação de um sistema? Totalmente dispensável. Não sei se convenci alguém, mas o Sr. Xavier disse ter gostado da “forma como defendo meus argumentos”, ou algo parecido. Um problema-polêmica bem maior viria na sequência, numa provocação até então implícita. Uma questão que me me incomodou em todas as oficinas sobre o tema: Os passos de um Caso de Uso são Requisitos Funcionais!

Incomoda porque é sempre uma surpresa para muita gente. Incomoda mais porque, como escrevi acima, não está escrito em “lugar nenhum”. Será uma bela “varada n’água”, um terrível engano deste que aqui rascunha? Tentarei responder no próximo post. Inté!

Está aqui a versão completa da apresentação (PPT – 3mb). Completa: Inclui as fotos de Varginha!!

Quais são os pontos de vista relevantes? Depende do projeto. Trata-se de um empreendimento que exige interfaces complexas com usuários? A equipe deveria contar com um especialista em usabilidade. O projeto requer um sofisticado desenho de bases de dados? A presença de um especialista em bases transacionais, analíticas e em gerenciamento de conteúdo não estruturado é recomendada. O projeto requer um preciso dimensionamento de servidores e da rede? Convoque o especialista em infraestrutura. Claro, o AN é presença obrigatória. É sua responsabilidade *ensinar* o problema para a equipe e auxiliar no desenho da solução. Essa reunião de especialistas é o que chamo de “Parlamento“.

Parlamento, s.m. (do inglês parliament)
assembléia ou câmara legislativa;
ato de falar.

Cabe aqui um lembrete: tomando o RUP ou o OpenUP como referência, ainda nos encontramos na fase conhecida como Incepção. Não iniciamos ainda a etapa de elaboração que, segundo aquelas propostas, resulta no “Lifecycle Architecture Milestone” (veja figura abaixo ). O parlamento foi convocado para desenhar uma ou mais soluções para o problema colocado, e apoiar o AN na elaboração de uma proposta (ou documento de visão, ou project charter, ou…).

Ao aprender e debater cada caso de uso, começando sempre por aqueles mais críticos para o negócio, os participantes do parlamento “rabiscam” as primeiras idéias de solução. São essas idéias que, em determinado momento, são agrupadas. Como vimos no artigo anterior, podemos ter até três alternativas de solução – três agrupamentos de idéias.

Cada idéia deve ser avaliada por todos os participantes. Antes dos chutes (ou estimativas), espera-se uma classificação bem simples: a implementação daquela idéia é Simples, de Média Complexidade ou Complexa? Ainda estamos preocupados em descobrir qual é a melhor solução para aquele problema. Lembrando: “melhor” não significa a mais sofisticada ou a mais econômica. A melhor solução será aquela que estiver mais alinhada com os objetivos e restrições do negócio.

Neste momento eu gosto muito de utilizar uma ferramenta que, aparentemente, é meio bobinha. Estou falando da Matriz SMBP (confesso, acabo de inventar um nome para o brinquedinho). Veja o rabisco abaixo:

Todo caso de uso e requisito aprendido e desenvolvido pelo AN mereceu uma classificação simples: Fundamental, Importante ou Opcional. Vamos assumir que esta classificação equivale a 3, 2 e 1 ponto, respectivamente. Somamos a pontuação de todos os requisitos registrados em um caso de uso e dividimos pelo número de requisitos. Ou seja, calculamos a pontuação média de cada caso de uso.

Todas as idéias de solução propostas pelo parlamento também foram classificadas, como Simples, de Média Complexidade e Complexas. Assumiremos aqui os valores 1, 2 e 3 pontos, respectivamente. Como a complexidade foi avaliada por vários especialistas, também calculamos a pontuação média. Pronto, agora temos as coordenadas que permitirão o posicionamento de cada idéia na matriz SMBP.

Todas as idéias que aparecerem no quadrante de “Sonho” devem ser consideradas. Todas são de fácil implementação e satisfazem requisitos que foram considerados fundamentais para o negócio. Podemos dizer que um projeto que só tem itens neste quadrante também é um projeto “dos Sonhos”. Pena que eles são raros. Existem também aquelas idéias cuja implementação é mais difícil. Como elas também representam alto valor para o negócio, as chamamos de “Mal Necessário”. Muito necessárias. Não podemos ignorá-las.

Já os dois quadrantes da parte inferior da matriz representam itens que devem ser muito questionados. As “bobeirinhas” um pouco menos, já que sua implementação é relativamente simples. Mas das idéias “Pesadelo” devemos fugir. Além de representar pouco ou nenhum valor para o negócio, são todas de implementação difícil. Como justificá-las?

Como eu disse, a ferramenta parece uma besteirinha. Mas é muito útil na tomada rápida de decisões. Permite que toda a equipe se concentre em itens que realmente fazem a diferença em um projeto. Didática, a própria matriz pode ser utilizada para justificar o escopo do projeto para um cliente. Permite também que se decida a meta de cada iteração ou o escopo de versões posteriores do produto em questão.

O parlamento, uma reunião que deve durar algo entre 1 e 4 horas, fornece bases para que o AN desenvolva a melhor proposta ou estudo possível. Respeita as inevitáveis restrições de custos e tempo – “é pra ontem!” – ao mesmo tempo em que elimina riscos e armadilhas. Não todos, é claro, mas é óbvio que a proposta ou estudo gerado é mais forte, melhor fundamentado.

É cara? Se comparada às propostas “bumba-meu-boi” e “balança-mágica” que algumas empresas elaboram, sim. Mas é um custo facilmente recuperado em um projeto que já começa em trilhos certos, sem desvios ou surpresas. E, claro, se estivermos falando de propostas comerciais, o método aqui sugerido aumenta consideravelmente as chances de vitória.

.:.

Notas:

1. Sim, *Especialistas*. Não coringas-especialistas-generalistas que chutam com as duas. Isso não tem nada a ver com Taylor e afins. O papo é cansativo, mas insistirei: é papo de Drucker, que diz que “conhecimento, por definição, é especializado“. Todo trabalhador do conhecimento (knowledge worker) busca (ou deveria buscar) a especialização. Como sou especialista em chatice, explorarei mais o tema em futuros artigos. A citação de Drucker eu tirei de “O Advento da Nova Organização”, artigo publicado na Harvard Business Review em 1988 (edição jan-fev).
2. Figura (indevidamente?) surrupiada do OpenUP (que não deveria ter Copyright).
3. Adoro nossa criatividade quando o assunto é a geração de propostas. O método “bumba-meu-boi” parece ser o default: um cara de vendas (ou pré-vendas) vai lá no cliente, se esforça para entender suas “dores”, volta correndo pra casa e se desdobra para traduzir aquilo tudo em cifras. Sim, porque a primeira coisa que seu chefe quer saber é o valor do projeto. “Bumba meu boi bumbá – é melhor alocar e cobrar por mês!!”, hehe.
   A “balança mágica”, como o nome confessa, é bem mais sofisticada. Ouvi dizer que uma grande empresa a utiliza. Na verdade, uma versão adaptada d’uma balança que um dia foi usada para pesar outro tipo de coisa ilícita. É de altíssima precisão. Joga lá a RFP e vê quanto deu: 127,34 gramas? Então o preço é R$ 400k, arredondado, e o projeto demorará 6 meses!! hehehe… Imprime até etiquetinha!

A mais importante ferramenta do físico é sua cesta de lixo.
– Albert Einstein

As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção.
– Frank Lloyd Wright

Costumo dizer que, na iteração 0 (nos momentos iniciais do projeto, que antecedem o estudo de viabilidade e a elaboração de uma proposta), o principal trabalho do analista de negócios (AN) é ter uma visão do todo: “2 quilômetros de extensão e 2 centímetros de profundidade“. Para obter esse “instantâneo”, o AN lança mão de suas duas principais armas-disciplinas: A Análise e Modelagem do Negócio e a Engenharia de Requisitos .

Ao interpretar as dores e os objetivos do cliente, o AN começa a dar um certo “relevo” àquele “instantâneo”. Ele destaca os requisitos de usuários mais críticos – fundamentais para o negócio. Como mostrei na pequena série “Estruturando Requisitos” (link p/ parte 2), cada requisito devidamente *aprendido* pelo AN é – obrigatoriamente – acompanhado do atributo “Grau de Importância”: aquele requisito é Fundamental, Importante ou Opcional?

Com base nesta classificação o AN tem condições de selecionar os pontos que merecerão sua maior atenção. Sua atuação, agora, depende do tempo que ele tem para a elaboração da Proposta (ou Estudo de Viabilidade, ou Documento de Visão, ou Project Charter…). Seguindo a sugestão apresentada no artigo citado no parágrafo anterior, cada Requisito de Usuário selecionado é transformado em um Caso de Uso. O requisito “Emitir Nota Fiscal”, por exemplo, vira o caso de uso cujo título é “Emitir Nota Fiscal”.

Ao desenvolver o caso de uso em questão, o AN está “fazendo um zoom” naquele “instantâneo”. Por ser crítico para a solução do problema de negócio, aquele requisito (de usuário) será desdobrado em n requisitos funcionais. Mais que isso: no mesmo momento o AN também pode estar descobrindo ou aprendendo regras de negócio, definições de dados e também alguns requisitos não-funcionais. Informações que podem ser facilmente registradas em um bom modelo para especificações de casos de uso. Para cada requisito *aprendido* segue valendo a mesma questão: ele é Fundamental, Importante ou Opcional?

Vamos supor que estamos tratando de um projeto com 10 casos de uso. O AN teve tempo suficiente para detalhar um pouco mais 4 deles. Claro, para o detalhamento ele lançou mão de entrevistas, observações, sessões JAD (ou workshops) – as técnicas mais indicadas para aquele projeto e/ou cliente. Respeitando o prazo (que quase sempre é imposto), ele desenhou o melhor retrato possível do problema do cliente. Este retrato é composto por um grande diagrama conceitual (ou mapa de processos), diagramas de processos ou de linhas de montagem (caso os processos de negócio em questão sejam complexos o suficiente para justificar a elaboração destes), a classificação de 10 casos de uso e a especificação (um pouco mais detalhada) de 4 deles. Esta “radiografia” é tudo que a equipe possui para definir qual a melhor solução.

Equipe? Sim, o desenho da solução deve ser um trabalho em equipe. Em um futuro artigo apresentarei o que chamo de “parlamento” – o formato desta equipe. Vale ressaltar que cada ponto de vista relevante deve estar representado neste momento. Desenvolvedores, especialistas em usabilidade, os “inimigos” da infra, os “chatos” dos DBA’s e, claro, o coordenador do projeto. O AN, óbvio, representa o cliente. Mas não como um “advogado do diabo”. Não agora, em que sua principal responsabilidade é *ensinar* para a equipe o problema que deve ser solucionado. O AN apresenta um conjunto de “Fatos”, o problema definido.

Começamos aqui a expandir aquilo que Scott Berkun chama de “Espaço do Problema” :

O início dos debates é marcado por um volume relativamente grande e heterogêneo de idéias. O “espaço do problema” aumenta, como ilustra a figura acima (surrupiada do Berkun). Em determinado momento (que variará bastante dependendo do tipo e complexidade do projeto), o time pára de gerar idéias e começa a agrupá-las. É sugerido que se chegue em 3 alternativas de solução: a mais cara, a mais barata e a coluna do meio, por exemplo. Sugestão: as idéias também são agrupadas em casos de uso.

Os debates, que a partir deste momento podem incluir o próprio cliente (formalmente, via proposta que contemple as 3 alternativas, ou informalmente, na mesa de discussões) visam a redução do número de opções. Gradativamente, por exclusão, ou com o cliente fazendo a escolha de uma das três alternativas apresentadas.

O problema com este enfoque é que, se por um lado está bem claro o que é fundamental ou importante para o negócio, por outro temos pouca visibilidade da complexidade e custo daquelas alternativas de solução. O “parlamento” foi reunido exatamente para suprir tal necessidade. Mas como isso é feito? O próximo artigo apresentará uma sugestão. Inté!

Notas:

1. Mais do que os objetivos ou os atores (e seus objetivos), acredito que o melhor “guia” para o desenvolvimento de requisitos são os próprios processos de negócio. Um dia, num clássico trabalho (The Object Advantage – Addison Wesley (1995)), Ivar Jacobson disse que o “caso de uso é o nosso constructo para um processo de negócio”. Entendo que a análise e modelagem do negócio é indissociável da engenharia de requisitos. Para minha sorte, não estou só.
2. “A Arte do Gerenciamento de Projetos“, de Scott Berkun – Artmed Editora (2008). Pois é, finalmente o grande livro do Berkun é lançado em pt-br. Para nosso azar o livro foi reeditado lá fora, com novo título (“Making Things Happen“) e conteúdo revisto. Quem mandou demorar?