Afinal, onde estão as regras de negócio??

Volta e meia eu recebo e-mails de pessoas interessadas em análise de negócios. Eu gosto de responder às dúvidas, principalmente quando a pessoa já pesquisou o material disponível e está com uma dúvida bem tangível. Foi esse o caso.

Aqui vai a dúvida:

Olá Claudio!!!

Já li muitos posts em seu blog e sempre achei muito interessante, logo gostaria de desejar parabéns.

Gostaria de tirar uma dúvida com você quanto a regras de negócio, tenho uma extrema dificuldade em identifica-las embora o meu forte nunca tenha sido focar em negócios, porém eu estudo livros,estudo artigos e parece que não consigo aplicar em casos diferentes.

Resumindo, já li inclusive um post seu em relação aos 7 equivocos de caso de uso e ainda assim não consigo extrair o que são regras de negócio

O que você recomendaria?

 

blabla

Aqui a resposta:

Todo mundo fala, fala, fala e fala sobre regras de negócios, aí quando vamos procurar por exemplos reais não encontramos, ou pior, encontramos enunciados fraquinhos.

Vou te dizer onde estão 85% das regras de negócios:

  • Diagrama de classes
  • Diagrama de máquina de estados

Peraí, classes? Isso é coisa de desenho de sistema. Sim e não. Cada classe no diagrama possui vínculos com outras classes, atributos e operações (métodos). Se tirarmos os métodos, todo o resto é 100% negócio.

  • Uma nota fiscal possui N itens? Regra de negócio.
  • Um professor pode lecionar para N turmas? Regra de negócio.
  • Uma pessoa pode ser professor em uma turma e aluno em outra? Regra de negócio.

Os atributos de uma entidade de negócio (a classe) também são Regra de Negócio. É o negócio que dita se cliente tem um ou mais telefones, isso depende do uso que o negócio vai dar à informação.

A questão é: para quê descrever isso em linhas e linhas de texto se consigo demonstrar tudo em um diagrama conciso? Não vale, a não ser que o AN esteja querendo encher linguiça.

Máquina de estados

Quase todos os sistemas (ou processos) possuem uma ou mais entidades principais e essas entidades possuem vários estados possíveis. O que determina como é a transição entre esses estados são as regras de negócios.

Um exemplo para máquina de estados é um pedido de uma loja virtual: o pedido começa com o estado “Pagamento pendente”, passa para “Pagamento confirmado”, “Aguardando envio”, “Enviado” e por fim, digamos “Entregue”.

Como você explica o quê acontece se o cliente quiser cancelar o pedido em cada uma dessas situações? Máquina de estados :)

Ela mostra os estados, as transições e as condições para que essas transições ocorram.

Ok, fiz os dois diagramas, aliás, fiz diagrama de classes e algumas máquinas de estados. Sobra alguma coisa?

Sim, mas é muito pouco. Um dos poucos exemplos de regra de negócios que fica boa em texto é: “O limite de bagagem gratuita por passageiro é de 23 Kg”. Aliás, se bobear dá para colocar essa regra em um diagrama também.

Ok, mas é só entregar os diagramas para desenvolvedores e esperar a mágica acontecer? Não, eles são ótimos para comunicar as regras de negócio, contudo, o que guia o desenvolvimento são as funcionalidades. O segredo está em vincular as regras às funcionalidades.

Em uma funcionalidade, pense em quais entidades são afetadas por ela. Cole na funcionalidade a parte do diagrama de classes que ela afeta. Isso vai ajudar o desenvolvedor a compreender quais são as regras que se aplicam. Vai entender que a relação é de um professor por turma, e que o professor substituto se liga à turma através de outro vínculo.

A mesma coisa com máquina de estados. Vincule às funcionalidades afetadas. Aliás, a máquina de estados permite que você informe nas transições qual funcionalidade está envolvida.

Bom, “em poucas palavras”, é por aí.

 

 

 

15 ideias sobre “Afinal, onde estão as regras de negócio??

  1. …”para quê descrever isso em linhas e linhas de texto… (?)”… quando sabem descrever! Infelizmente o mercado está saturado de profissionais de TI que não sabem escrever, quanto mais desenhar algum conceito de processamento de dados. Estes dias, daqui de Métricas, analisando um Documento de Visão, quis entender o contexto do sistema, o que ele recebia de quem, para processar o quê e para quem… questionei a falta de um “diagrama de contexto”, sabem o que eu ouvi? Que “desenho” não é importante. Um texto enorme, tipo linguiça, em frustada tentativa de descrever um sistema… “autista”! (Zero PF pra ele!) *** Em situações (sim, “ões”, no plural) eu fico pensando cá com os meus botões; como dorme um “analista” desse? Acorda galera de TI do Brasil! Leiam Claudio Br com as suas, como sempre, sensacionais :))

    • Pois é Aline. Texto é perigoso mesmo. Veja que a Simone ficou mais preocupada com o “r” que faltou no seu comentário do que com o que você estava dizendo :)

      Talvez você goste de diagramas porque não sabe escrever. Uau, esse seria um estereótipo e tanto hein? Ihh, estereótipos também são modelos!

      A Simone disse ” Infelizmente, eu não seria capaz de exemplificar as regras de negócio com as quais eu trabalhei no passado de maneira simples, sem explicar os complexos contextos de negócio dos quais essas regras eram extraídas”.

      Isso me parece dificuldade de abstração. Costuma ocorrer quando ficamos presos ao uso exclusivo do texto.

  2. Eu não sei com que tipos de sistemas vc já trabalhou, mas achei de um simplismo sem tamanho vc concluir que 85% das regras de negócio podem ser demonstradas (?) através de diagramas. Infelizmente, eu não seria capaz de exemplificar as regras de negócio com as quais eu trabalhei no passado de maneira simples, sem explicar os complexos contextos de negócio dos quais essas regras eram extraídas, mas, acredite: existe muito mais do que 15% para ser descrito como texto.

    Uma pequena observação à colega que falou que o mercado está saturado de profissionais de TI que não sabem escrever: o correto é FRUSTRADA.

    • Oi Simone! Acho que temos duas questões distintas no seu comentário e ambas, claro, muito válidas.

      A primeira é uma discussão objetiva sobre a minha afirmação de que 85% das regras de negócio podem ser expressadas na forma de diagrama de classes/endidades e de máquina de estados. Bem, uma ressalva que devo fazer é a de que estou me referindo ao conjunto total de regras de negócio que serão representadas no sistema a ser desenvolvido. Isso deixa de fora uma série de regras que não estão no escopo do sistema, coisas que são, por exemplo, muito caras para parametrizar.

      Como vamos verificar de forma objetiva que 85% das regras de negócio estão nesses diagramas? Eu sugiro o seguinte: pegamos um sistema qualquer, desenhamos seu diagrama de classes e diagramas de máquinas de estados e redigimos as regras de negócio que não podem ser expressas através desses diagramas, seriam textos declarativos, tabelas e equações.

      Ótimo, agora, vamos transformar a informação que está nos diagramas em texto descritivo, por exemplo: “Um aluno só pode fazer parte de uma turma por semestre”. Após transcrever isso tudo, mandamos contar as palavras e o resultado será que a transcrição dos diagramas possui seis vezes mais palavras que as regras que não podem ser expressadas através de diagramas.

      Ok, é, mais uma vez uma simplificação, talvez simplista, mas o que são modelos senão simplificações da realidade? É a arte da abstração.

      Acredito que damos pouco valor para a quantidade de regras de negócio que estão nos diagramas talvez justamente por elas serem as que menos incomodam por estarem bem descritas através deles.

      A segunda questão é a saturação do mercado de TI por pessoas que não sabem escrever. De fato isso frustra, até porque não saber escrever costuma ser filho do não querer/poder/saber ler.

      Eu fico frustrado com isso também, contudo, eu uso o texto corrido onde ele realmente traz mais valor, onde ele não abre tantas portas para a ambiguidade. Meus requisitos sempre contam com textos de contextualização. Aliás, existe algo que gosto muito de fazer no começo de um produto que é criar um texto no qual explico a razão de ser das entidades mais importantes do negócio em coisa de um ou dois parágrafos. É bem legal.

      Escrever é uma ferramenta útil, contudo, devemos buscar eliminar a ambiguidade e nossa linguagem é mais apropriada para a poesia do que para a lógica ao ponto que é bem provável que eu tenha interpretado mal algo que você escreveu e que o mesmo ocorra agora enquanto você lê a minha resposta.

    • Não foi de pOpósito, Simone! Me descuRpa E sendo eu partidária do simplismo; quem dera se o problema das descrições de sistemas fosse a grafia!

  3. A discussão sobre esse assunto está muito boa lá no An-br (an-br@googlegroups.com). O Fabrício Laguna apresentou exemplos de importantes regras de negócios que não cabem em diagramas e o Rafa Jaguá alertou para o risco de acabar fazendo um BDUF ao usar esses diagramas e disse que faz uso dos diagramas do Visio para desenhar as regras junto com os clientes/usuários.

  4. Não foi de pOpósito, Simone! Me descuRpa :) E sendo eu partidária do simplismo; quem dera se o problema das descrições de sistemas fosse a grafia!

  5. Muito bom o artigo, antes de ler o mesmo, eu tinha uma ideia parecida com a da Simone. Após a leitura do artigo e dos comentários, acredito que o mais importante, é se fazer entender, seja por meio da escrita ou da criação de diagramas.

    Enfim, o que é válido, é se fazer entender da maneira mais fácil possível.

  6. Achei a discussão interessante mas gostaria de colocar alguns pontos:

    1 – Quando foi falado sobre 85% de RN estarem nas classes… Beleza! Isto pode ser um fato para quando se está analisando um sistema ‘pronto’. Tenho uma segunda óptica que:
    1.1 – Como trabalho na área de inovação, dificilmente tenho classes para analisar, ou seja, no momento em que estou captando regras de negócio para o produto, ninguém desenhou as classes ainda. Então, a dica é desenhar e fazer pequenas anotações. (nada de novo, certo?)
    1.2 – Tenho visto inúmeras pessoas falando sobre AN como se fosse um simples cursinho a solução. Sério, conheço uma baciada de ‘analistas de negócio’ que JAMAIS conseguiriam ler um diagrama de classes :) então estudo é o melhor remédio.

    2 – Percebi que a discussão está muito sobre a questão sistêmica (o que na verdade é 80% da realidade). Mas alerto para os futuros ANs que a análise de negócio não está ligada estritamente a TI. Veja que por exemplo o BABOK que caminha o tempo todo no âmbito do Negócio. Então cuidado com as definições sob a óptica de TI. Trabalhei por anos em uma empresa cujas regras de negócios não se aplicavam a sistemas^informatizados, mas a processos de conferência e separação, ou análise de qualidade de materiais plásticos. …por exemplo. mas enfim é pra outro tópico.

    Abraços e parabéns pelo trabalho! ;)

  7. Gostaria de fazer somente um comentário em relação à esta afirmação:
    “A questão é: para quê descrever isso em linhas e linhas de texto se consigo demonstrar tudo em um diagrama conciso? Não vale, a não ser que o AN esteja querendo encher linguiça.”

    A resposta é simples: porque as regras são DO NEGÓCIO, e o pessoal DO NEGÓCIO não sabe ler diagramas de classes nem máquinas de estado (aliás, eles terão uma síncope se você sequer mencionar estes diagramas). Regras de negócio TEM que ser descritas em um formato que o pessoal de negócio possa compreender, avaliar, aprovar e manter ao longo de toda a vida DA ORGANIZAÇÃO, independente delas serem ou não implementadas em algum sistema. Na realidade, as regras embutidas no sistema são, apenas, expressões em código das regras de negócio da organização. Elas não são as regras de negócio da organização! (coisa que a maioria dos agilistas finge ignorar)

    Portanto, quando alguém disser que “as regras de negócio não precisam ser documentadas, porque estão no código”, recuse esta posição simplista e exija que elas sejam documentadas através de um metodo (textual ou gráfico) que possa ser gerenciado pelo pessoal de negócios.

    • Antonio, até hoje não encontrei uma pessoa do negócio que não fosse capaz de compreender e passar a usar os diagramas da UML após 20 minutos de explicação. Talvez você não esteja dando a essas pessoas o crédito que elas merecem. Repito o que sempre falo: “as maior prova de que as pessoas do negócio são mais sabidas que a gente é o fato delas não terem optado por trabalhar com TI”.

      Por favor, fique livre para armazenar as regras de negócio da forma que achar melhor, contudo, na hora de discutir como essas regras de negócio afetam um sistema a ser desenvolvido não existe notação melhor do que esses diagramas (por enquanto, mas vou usar o que achar melhor assim que encontrar). Cada diagrama é uma imagem que substitui milhares de palavras. Por acaso você ganha pela lauda?

      Se você se considera um profissional indispensável, o único que é capaz de fazer a ponte entre negócio e TI eu sugiro que assista a minha palestra mais recente: http://blog.claudiobr.com/slides-com-audio-analise-de-negocios-agil-e-jogar-a-vida-no-hard-dia-25-de-abril-no-agile-trends-sao-paulo/ .

      Seu comentário trouxe muitas crenças, contudo eu gostaria que você apresentasse algum argumento mais elaborado, de preferência sustentados com fatos.

      Você deu uma beliscada nos agilistas, então sugiro que leia o recém lançado draft do BABOK 3.0 (http://www.iiba.org/babok-guide-v3-public-review/index.html). O recado é que o século XXI já chegou há 14 anos amigo, está na hora de largar o osso do waterfall.

      Aliás, reproduzo abaixo os pilares do manifesto ágil, gostaria que você respondesse dizendo de quais deles você discorda e como você faz no seu trabalho:

      Manifesto para Desenvolvimento Ágil de Software

      Estamos descobrindo maneiras melhores de desenvolver
      software, fazendo-o nós mesmos e ajudando outros a
      fazerem o mesmo. Através deste trabalho, passamos a valorizar:

      Indivíduos e interações mais que processos e ferramentas
      Software em funcionamento mais que documentação abrangente
      Colaboração com o cliente mais que negociação de contratos
      Responder a mudanças mais que seguir um plano

      Ou seja, mesmo havendo valor nos itens à direita,
      valorizamos mais os itens à esquerda.

    • Caramba Antonio, gastei um tempo escrevendo uma bela resposta, aí vi que você tinha informado um link e fui ver. O que eu encontro na área principal do seu site? Dois DIAGRAMAS!

      http://www.centus.com.br/

      Seu engraçadinho. A gente tinha que estar se abraçando e não discutindo. Precisando de software chama a Lambda3, a galera de processos e regras de negócios adora quando estamos no projeto.

      Ahh, ainda quero aquela resposta sobre o manifesto ágil, ok?

      • Claudio,

        Eu não disse que não era a favor de diagramas: eu SOU a fovor de diagramas! Eu também não sou contra os métodos ágeis: eu USO uma metodologia ágil no meu trabalho de modelagem de decisões. E sou membro do IIBA, e o IIBA abraça as metodologias ágeis como uma das possíveis formas de organização de uma iniciativa de análise de negócios.

        Isto posto, minha única restrição à aplicação prática dos métodos ágeis é a afirmação “se está no código, qualquer outra forma de documentação é desnecessária ou prejudicial ao andamento do projeto”. Em relação a isso, sou terminantemente contrário. Eu acredito que o código pode perfeitamente documentar COMO o sistema foi construído, mas é falho em mostrar PORQUE ele foi construído desta forma. Em outras palavras, eu trabalho com uma perspectiva de negócio, e não de sistemas. A documentação de processos, decisões e de informações deve presceder, e prescindir, o desenvolvimento dos sistemas que irão implementá-los. Desta forma, teremos uma separação, salutar, entre o que o negócio precisa que seja feito (documentação do negócio) e o como foi, eventualmente) implementado em um sistema. A primeira parte, onde o AN trabalha, depende de uma formalização(escrita ou em modelos) que o pessoal de negócios possa entender e validar, e a segunda parte, onde trabalham os desenvolvedores ágeis ou não, de uma documentação (no código ou em modelos) que permita sua manutenção e atualização posterior.

        Portanto, em relação ao Manifesto Ágil:
        - Indivíduos e interações mais que processos e ferramentas
        > sem dúvida, desde que as interações não sejam desgastadas por falhas de entendimento que poderiam ser minimizadas pelo uso correto de processos e ferramentas
        - Software em funcionamento mais que documentação abrangente
        > com certeza, desde que a documentação “menos abrangente” permita que o software entregue o valor demandado pelas partes interessadas
        - Colaboração com o cliente mais que negociação de contratos
        > perfeito, desde que esta colaboração se dê em cima de bases concretas, e não em torno de conceitos abstratos e sem conteúdo claro
        - Responder a mudanças mais que seguir um plano
        > fundamental, pois a única coisa constante na vida é a mudança;

        Como você vê, temos mais pontos em comum do que divergências… vamos tomar um café qualquer dia destes e conversar sober as diferenças entre a visão do negócio (que eu defendo) e a visão dos sistemas.

        Abraços,

Deixe uma resposta para Emerson Soares Cancelar resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *