Engenharia de Requisitos - Uma introdução

A Engenharia de Requisitos se ocupa, principalmente, das atividades de Engenharia de Sistemas relacionadas a descobrir, organizar e documentar requisitos de sistemas. Ela busca encontrar soluções para um ou mais problemas que afetam uma organização. Neste processo, duas abordagens são usadas: visão orientada para o problema, que foca no entendimento dos problemas reais, e visão orientada para a solução, que foca no desenho e seleção de alternativas de solução.

Engenharia de Requisitos Orientada para o Problema

A engenharia de requisitos orientada para o problema se origina na engenharia de sistemas e envolve investigar e documentar um domínio do problema. Dentro desta visão o engenheiro de requisitos descreve as situações problemáticas que estão sendo experimentadas, as relações entre estas situações, porque elas são vistas como problemáticas e quem é afetado por ou vive estes problemas.

Uma técnica comum dentro desta visão é a Engenharia de Requisitos Orientada para Objetivos (GORE-Goal-Oriented Requirements Engineering). Esta técnica elicita os objetivos das partes interessadas relevantes para endereçar seus problemas e preocupações. Estes objetivos definem o que uma parte interessada deseja atingir, ao mesmo tempo em que se abstrai do como isto pode ser feito, e por quem.

Os objetivos capturados capturam a razão de ser para a solução que deverá ser desenhada para atingir os objetivos e, assim, resolver os problemas identificados. Como preparação para o desenho da solução, os objetivos podem ser decompostos em objetivos menores e mais concretos, que possam ser realizados de forma mais fácil e direta. Isto resulta nas chamadas árvores de objetivos.

A engenharia de requisitos orientada para objetivos permite uma série de análises. Primeiro, ela facilita estabelecer a motivação e a justificativa para os objetivos e suas soluções. Através de técnicas de modelagem podemos analisar e demostrar que objetivos motivam outros objetivos e que elementos de uma arquitetura empresarial realizam estes objetivos. Segundo, a engenharia de requisitos orientada para objetivos suporta a modelagem e análise do quanto um objetivo contribui positiva ou negativamente para - ou mesmo conflita com - a realização de outros objetivos.

Engenharia de Requisitos Orientada para a Solução

A engenharia de requisitos orientada para solução representa uma abordagem mais tradicional da visão da engenharia de software em relação aos requisitos. Nesta visão a engenharia de requisitos é vista como uma especificação de uma solução. O engenheiro de requisitos especifica o contexto no qual o sistema irá operar, produz uma lista de funções do sistema requeridas ou desejadas, define a semântica destas funcionalidades (requisitos funcionais) e produz uma lista de atributos de qualidade para estas funcionalidades (requisitos não-funcionais).

Soluções alternativas podem ser propostas pelo engenheiro de requisitos. Por exemplo, configurações diferentes do sistema podem ser propostas para suportar diferentes atributos de qualidade da solução. Estas alternativas são analisadas com base em diversos critérios para selecionar aquela que oferece a melhor solução.

Técnicas comumente usadas nesta visão são baseadas na Análise Estruturada e na Análise Orientada para Objetos. A análise estruturada foca no fluxo dos dados através do sistema sendo construído, normalmente através do uso de Diagramas de Fluxo de Dados (DFD). A análise orientada para objetos aplica técnicas de modelagem de objetos para analisar os requisitos funcionais do sistema em construção. Uma técnica importante na análise orientada para objetos é a elicitação e especificação de Casos de Uso. Casos de uso capturam o comportamento da solução em termos de cenários das interações entre o sistema e os seus usuários.

Cadeia de Problemas

As duas visões da Engenharia de Requisitos, orientada para problemas e orientada para soluções, podem ser consideradas como duas fases consecutivas e complementares. Iterações destas fases podem ser aplicadas para endereçar um problema de forma progressiva, isto é, em múltiplas iterações. A partir desta perspectiva nós identificamos o que chamamos cadeia de problemas, onde cada elo conecta um problema com a sua solução, que por sua vez é considerada novamente um problema para o próximo elo. Por exemplo, um analista de negócios pode investigar um problema de negócio e especificar uma solução de negócio para este problema. Esta nova solução pode requerer o suporte da TI, na forma de um sistema novo ou modificado. Este sistema se torna, então, um problema para o Analista de TI. Ao mesmo tempo, a solução de negócio original pode dar origem a outros problemas de negócio, e assim sucessivamente.

Em um próximo artigo vamos explorar como estes conceitos são tratados pela Arquitetura Empresarial.

Fonte: Business Requirement Management Copyright 2010 BiZZdesign Academy

Quando é importante automatizar uma decisão?

A maioria das pessoas é capaz de identificar uma decisão quando vê uma. Ela tem um problema pela frente, determina que fatores devem ser levados em consideração para resolver o problema, levanta os dados que irão suportar sua decisão, e finalmente faz uma escolha entre as diversas alternativas que estão sendo consideradas. 

"Uma decisão é tomada com base em valores de fatos de condições que levam à escolha do valor do fato de conclusão, tomado entre os valores alternativos disponíveis."

Nós tomamos centenas de decisões, todos os dias: que roupa vestir, o que comer, que caminho seguir para o trabalho, que coisas comprar, e assim por diante. As organizações tomam milhares de decisões todos os dias, em todos os níveis hierárquicos: qual o preço da oferta de um produto, que empregados selecionar para uma tarefa, quanto pagar por um insumo, que fornecedores selecionar para fornecer um material ou serviço, que transportadoras utilizar para um dado pedido de venda, que impostos incidem sobre uma venda, e qual o seu valor, e assim em diante.  

Mas não basta saber que as decisões existem e que elas acontecem espalhadas por toda a organização. É necessário estabelecer orientações para quem irá tomá-las, entender quais as condições que devem se avaliadas e quais as opções de conclusão que podem ser escolhidas. Em muitos casos as decisões são total ou parcialmente automatizadas e, neste caso, é necessário estabelecer os critérios para decidir que decisões valem o esforço despendido para a sua automatização.      

Antes de mais nada, é importante entender que as decisões existem na organização independente de sua automatização ou não. Decisões manuais são feitas por pessoas, com ou sem o auxílio de sistemas informatizados. Uma organização que possua um sistema de aprovação de pedidos que mostra em uma tela as informações relativas à situação de crédito do cliente (limite de crédito, saldo em aberto e em atraso, avaliação externa de crédito, etc.) e registra a decisão de um analista de crédito (aprovado, não aprovado) não está, efetivamente, automatizando esta decisão. Ela continua sendo uma decisão manual!

Traduzindo este conceito de uma forma bem direta: Decisões automatizadas são tomadas pelos sistemas SEM a interferência direta de qualquer pessoa ou processo manual.

Decisões automatizadas são particularmente críticas quando é difícil, ou não-econômico, para que pessoas possam se manter atualizadas em relação às condições e valores de condição e de conclusão que uma decisão exige, ou processar este volume de informação em tempo hábil para manter o processo onde esta decisão se insere ágil e eficiente. Tipicamente, decisões com as características abaixo são candidatas naturais à automatização:

• Existe um grande número de regras de negócio (condições) que devem ser avaliadas em curto espaço de tempo
• As regras de negócio mudam com frequência em função de:
• mudanças nas políticas ou na legislação
• as regras são dependentes do momento da aplicação (descontos sazonais, por exemplo) ou da localização geográfica (impostos e taxas locais, por exemplo)
• As regras mudam com frequência em função de variáveis do mercado ou da estratégia da empresa (preços diários - ou horários - em supermercados, por exemplo), tipo de cliente, custos de frete, etc.
• As regras devem ser disseminadas e entendidas por um grande número de pessoas, possivelmente em localizações geográficas diferentes e com níveis de treinamento e entendimento variado

Como decidir que decisões devem ser automatizadas?

Nem todas as decisões são necessariamente adequadas para automatização. As decisões que melhor se prestam à automatização possuem as seguintes características:

• A decisão é repetível
  • Existe um padrão que deve ser seguido para a tomada da decisão e que pode ser automatizado
• A decisão é não-trivial
  • É importante que os benefícios de tornar a tomada da decisão mais acurada, rápida ou confiável sejam maiores que o custo de sua automatização
• O processo ou evento de negócio que contém ou dispara a decisão está claramente identificado
• Sabemos quando, onde e porque a decisão é tomada
• A informação necessária para a tomada da decisão é conhecida
• Podemos identificar todos os dados necessários para a tomada da decisão
• O conhecimento necessário para a tomada de decisão é claro
• Conhecemos toda a legislação, normas, padrões, melhores práticas, objetivos e estratégias do negócio necessários para uma tomada de decisão consciente
• É necessário conhecimento e governança da lógica do negócio
• Precisamos ter a certeza que a decisão está sendo tomada de acordo com as regras estabelecidas
• É necessário garantir que as regras de negócio e os valores dos fatos de condição estão atualizados e de acordo com a estratégia e os objetivos da organização

Identificadas as decisões que devem ser automatizadas, resta escolher a melhor maneira de explorar, analisar, avaliar e definir as alternativas de conclusão e as condições a serem consideradas. Este é o objetivo da modelagem de decisão, e em outros artigos detalharemos como isto é feito através do Modelo de Decisão (TDM).

Fique conosco, compartilhe sua opinião e suas experiências, discuta como as decisões são tratadas na sua organização.

Por que modelar decisões, e por que isto é importante para as Organizações? (Parte 2)

No artigo anterior falamos sobre a evolução ocorrida nas organizações ao longo do tempo e a importância da padronização e melhoria dos seus processos para o seu sucesso. Neste artigo, vamos definir exatamente o que a Lógica de Negócios e o que é uma Decisão de Negócio.

"Lógica de negócios é simplesmente um conjunto de regras de negócio representadas como elementos atômicos de condições que levam à conclusões. Como tal, a lógica de negócios representa o pensamento do negócio a respeito da forma como importantes decisões de negócio são tomadas." (von Halle e Goldberg, 2009).

De acordo com a definição acima, vemos que a lógica do negócio é uma representação da forma como as decisões do negócio são tomadas. Decisões de negócio estão em toda parte, e acontecem milhares de vezes, todos os dias, através de toda a organização. Alguns exemplos de decisões de negócio são:

• Determinar a elegibilidade de uma reivindicação de cobertura de seguro
• Determinar a aprovação de um pedido de compra
• Calcular o valor da taxa de juros de um empréstimo
• Calcular o valor a ser cobrado em um plano de telefonia celular
• Determinar que produtos associados devem ser sugeridos por um site de compras
• Determinar o valor do imposto a ser recolhido em uma operação de venda

Todas estas decisões de negócio possuem algumas características em comum:

• são baseadas em condições que avaliam fatos, e que levam a conclusões que interessam à organização gerenciar
• são repetíveis, ou seja, acontecem diversas vezes e, em todas elas devem seguir as mesmas regras estabelecidas pelo negócio
• são importantes para a sobrevivência e o crescimento do negócio
• são conectadas com os objetivos do negócio e afetam os resultados do negócio, mas são tomadas de forma pulverizada por toda a organização, a ponto de passarem desapercebidas
• possuem existência própria, independente da forma como são tomadas, se são automatizadas ou não
• podem ter valor unitário pequeno, mas quando tomadas milhares de vezes, todos os dias, assumem um valor de grande impacto estratégico e financeiro para a organização

Quando tomamos consciência da existência das decisões de negócio, e as nomeamos, devemos na sequência fazer algumas perguntas:

• nós sabemos realmente como cada decisão de negócio é tomada através de toda a organização?
• nós temos uma associação clara entre cada decisão de negócio e os efeitos que ela tem sobre resultados da organização?
• nós podemos mudar rapidamente a lógica que governa cada decisão quando as condições em que a organização opera mudam?
• a gestão da lógica do negócio é digna de atenção sustentada por parte do negócio - o conceito de regra de negócio está no nível correto de interesses do negócio; ela é algo com o que a direção realmente se preocupe, e pode usar em benefício do negócio, criar estratégias a respeito, e que continua tangível e ágil desde a concepção até a implantação?

Se a resposta para qualquer destas perguntas é NÃO, então a organização precisa reavaliar sua gestão da lógica e das decisões de negócios, sob o risco de perda do controle e da governança do negócio, e da redução da agilidade nos negócios e do aumento dos custos e perda das receitas associados a decisões mal tomadas.

No próximo post vamos analisar algumas estratégias usadas pelas organizações na tentativa de gerenciar sua lógica de negócios.