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
Boa noite, Grosso modo, olhando a figura acima, está me parecendo uma análise "Top-down", que eu particularmente tenho como abordagem inicial quando entre em alguma discussão, de qualquer que seja o tema a ser estudado. Porém com o andar e caminhar do assunto que está sendo estudado, deve-se em algum momento passar a mesclar esta abordagem com a "bottom-Up". Geralmente isto é indicado quando já temos um bom entendimento "estratégico" do assunto, e precisamos descer para um nível mais denso" de material, muito provavelmente com a mudança de algumas pessoas, ou a entrada de novas pessoas, com um perfil mais operacional, o convívio de pessoas operacionais com um grupo muito maior de estrategistas, tende a ter muitos conflitos, devido a visão do tema, que passa a estar mais ligada ao dia-a-dia do assunto em tela. Achei muito interessante o assunto e gostaria de participara das discussões. Um forte abraço. Edson ( Santos - SP ).
ResponderExcluirEdson, obrigado pelo comentário.
ResponderExcluirRespondendo à sua questão, posso dizer que existem diferentes sentidos para os termos "top-down" e "botton-up". Um deles, e creio que é o sentido a que você se refere, é no sentido de indicar um movimento do mais geral para o mais específico/detalhado (top-down) ou o inverso (botton-up). No caso apresentado não é este exatamente o sentido que gostaria de dar.
O que a Engenharia de Requisitos propõe é a idéia que uma solução para um problema passa a ser, em si, um novo problema, que demandará outras soluções, que por sua vez serão outros problemas a serem tratados, e assim sucessivamente, em uma cadeia que deve ser administrada de forma ordenada, sob risco de se tornar incontrolável. Vejamos um exemplo que mostra como isto não significa um detalhamento (top-down), mas uma sequência causal no mesmo nível de detalhamento.
Digamos que uma empresa detecte um problema no seu serviço de atendimento a clientes. A análise das possíveis soluções pode determinar que a solução para o problema está no treinamento dos atendentes. Agora, nós temos um outro problema: desenvolver um programa de treinamento para o pessoal de atendimento. A solução para este problema pode ser, por exemplo, criar um programa de auto-estudo para reciclagem dos operadores antigos e auxiliar o treinamento dos novos atendentes. Agora, o problema passa a ser estabelecer qual é o conteúdo deste treinamento, e qual a plataforma de auto-estudo que será utilizada. E assim continuamos, até exaurirmos a cadeia problemas-soluções-problemas.
Note que não houve, neste exemplo, um detalhamento da solução inicial, mas a descoberta de outros problemas correlatos que demandam soluções que geram novos problemas, e que toda a cadeia deve ser analisada e resolvida antes que o problema original seja realmente solucionado. Este é, então, um dos papéis que a Arquitetura Empresarial enxerga na Engenharia de Requisitos: o de tornar claras estas relações causais e permitir que elas sejam tratadas de forma adequada, para que a solução do problema original seja realmente alcançada.
Não concordo com esta figura! Pois repete os problemas de negócios ou criando mais problemas de negócio.
ResponderExcluirElias, respeito sua discordância, mas a figura não repete os mesmos problemas ou cria outros problemas. A realidade é que uma solução para um problema pode, sim, criar outros problemas, que também exigirão uma solução. Esta cadeia deve ser conhecida e tratada pelo Engenheiro de Requisitos antes que a solução inicial seja (eventualmente) adotada.
ResponderExcluirJá participei de muitos projetos em que a solução inicial "perfeita" se revelou um grande fracasso porque os problemas decorrentes causados por ela foram maiores que o benefício de sua adoção. A Engenharia de Requisitos procura conhecer estas relações de causa e efeito para que a opção por uma das possíveis soluções de um problema seja feita da forma mais consciente possível.
Obrigado pela oportunidade para esclarecer este conceito.