Você tem razão, existem situações e projetos que exigirão uma orientação diferente para a engenharia de requisitos. Mas, no meu caso, o foco é o trabalho do Analista de Negócios. Daí minha observação: o desenvolvimento de requisitos será sempre orientado aos processos de negócio. Minha falta de experiência com sistemas embarcados e afins também me impede de aprofundar neste caso.

Os autores da EPBE, Eriksson e Penker, não sugerem um método em seu trabalho. Tratam exclusivamente da notação. E a esticam um pouquinho, apresentando uma série de “Business Patterns”. Portanto, seu trabalho, assim como o que desenvolvo aqui, são relativamente “inéditos”.

Quem te falou que BPMN é complexa? Não acho. E, lembre-se: ela só substitui o diagrama de atividades da UML. Ainda assim, apenas em alguns casos. O diagrama de atividades é mais flexível e abrangente.

Abraços,

Paulo

Só pegando um gancho nessa sua obervação:

“”Por isso, o “desenvolvimento de requisitos orientado por processos de negócio” parece um tipo de pleonasmo. Mas, dada nossa inocência quando o tema é o desenvolvimento de requisitos, quem sabe a redundância não seja útil?””

De fato, após escrever o post eu fiquei com a mesma sensação.

A minha idéia parte do seguinte: existem sistemas cuja Eliciação/Gestão de Requisitos não é derivada de “processos” – pensando aqui na acepção de processos no contexto de processos organizacionais. Ex.: software embarcado para aplicações militares. Neste casos, os requisitos de software derivam da Engenharia de Sistemas. Até onde eu sei, existe já um arcabouço de notação e atividades (método) mais bem estruturado, consistente e bastante utilizado.

Quando se trata de desenvolvimento (ou modificação ou implantação) de software para processos organizacionais, embora naturalmente a Eliciação de Requisitos origina-se da modelagem de processo, não conheço (e pode ser pura ignorância deste escriba) nenhum método consistente e estruturado que permita “fluir” do desenho de processo para a Eliciação/Gestão de Requisitos de Software. Se quisermos ainda fazer a rastreabilidade de Caso de Uso (ou Funcionalidade) para Requisito de Processo, acho que o problema se agrava.

Em parte, o que me despertou o interesse pelo EPBE foi, com base em seus artigos, a impressão de que esta pode ser esse “elo perdido”. VOu averiguar.

Assim, pode ser que, se eu enveredar por essa linha, a dissertação poderia ser algo como um Método (aqui entendido como Notação+Atividades), com base nas extensões à UML propostas pelos autores, para preencher o “elo perdido” (aqui não sei se cabe, pois não sei se os autores propõem um método).

OUtra linha, que na verdade eu vinha pensando era justamente a de linkar BPMN com UML – mas tenho tido muitos feedbacks que BPMN é complexo. Porém, como trabalho acadêmico…talvez.

Meu caro, de certa forma é isso que sugiro em meu trabalho. A Análise e Modelagem de Negócios ocorre simultaneamente com o Desenvolvimento de Requisitos. Na verdade, não faz o menor sentido que seja feito de outra forma. Por isso, o “desenvolvimento de requisitos orientado por processos de negócio” parece um tipo de pleonasmo. Mas, dada nossa inocência quando o tema é o desenvolvimento de requisitos, quem sabe a redundância não seja útil?

Sim, você tem razão. A pouca popularidade da EPBE é consequência da baixa adoção de uma abordagem mais consistente da Análise e Modelagem de Negócios.

Como eu disse anteriormente, vou relembrar o ZF, de acordo com sua sugestão. Mas acho pouco provável que, nesta versão do meu trabalho, eu faça alguma alteração mais profunda. E, como eu disse em outro lugar, meu próximo tema “de cabeceira” será Arquitetura Corporativa. Aí, com certeza, vou “sugar” muito do ZF.

Obrigado pelo comentário. Abraços,

Paulo

Estava pensando em algo como “Eliciação (ou Gestão) de Requisitos orientada por Processos”.

Quanto à pouca utilização da EPBE como mencionado, será que ainda não tem a ver com o fato (ou minha impressão) de que a Modelagem de Negócio, de uma forma mais estruturada e sistematizada, ainda estar “em formação”? – Quero dizer, ela já vem sendo feita na prática, mas sem um arcabouço consistente de notação, processo… enfim, metodologia.

Como mencionei no outro post, há algum tempo tomei contato com o Zachman Framework, algo criado há muito tempo, que faz muito sentido na minha opinião, mas também pouco utilizado. E vejo o ZF como podendo ser um elemento agregador/orientador/direcionador da AN.

hehe, já cometi tal “heresia” no Rose, StarUML e Umbrello. Só no segundo eu tinha a extensão. Nas outras duas, só criei os estereótipos. E, pimba! Tava lá.

Só não trato aquelas elipses como casos de uso de negócio. Naquele diagrama são casos do sistema mesmo. Mas, se vc quiser relacionar BUC’s e casos do sistema, também não vejo nada que impeça.

Meu caro, EPBE realmente não tem popularidade nenhuma. Talvez eu coloque alguma coisa na Wikipédia, em pt. Mas quando sobrar um tempinho…

A EPBE está completando seu 8º ano de vida. Era para ser mais conhecida. Não importa: como eu disse em outro lugar, o problema está com o entendimento e adoção da disciplina Modelagem de Negócios. Quando ela for mais praticada, com certeza EPBE crescerá com ela.

Abraços,

Para mim é uma ótima representação gráfica para a interação entre casos de uso de negócios e casos de uso de sistema e como as entidades são afetadas por esses casos de uso de sistema.

Outra coisa, assim que comecei a ler sobre EPBE e falei sobre isso com o pessoal, surgiu a questão da BPMN. Na boa, para mim ela poderia ser uma biblioteca de ícones para UML, mas tudo bem. O que me assustou foi que coloquei EPBE e BPMN na Wikipedia (inglês) e não encontrei nada sobre EPBE. Isso é um pouco assustador.

Sobre o livro, pois é, como estou estudando ITIL e pontos de função e peguei férias, ele acabou ficando para janeiro. Acho que os obstáculos para a adoção de uma extensão da UML não mandatária vem de todos os lados 🙂