XXIII Encontro Nac. de Eng.

de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003

ENEGEP 2003 ABEPRO 1

Sistematizao do levantamento de requisitos em processos de
desenvolvimento de software a partir de uma arquitetura de
modelagem de negcios

Delmir Peixoto de Azevedo Jnior (UENF/DATAPREV-RJ) delmir.junior@rj.previdenciasocial.gov.br
Renato de Campos (UENF) rdcampos@uenf.br


Resumo
Os sistemas de informaes so os habilitadores do negcio e precisam estar alinhados com
os reais objetivos do negcio. Existe uma carncia de mtodos que alinhem de forma
sistemtica o levantamento de requisitos de software s reais necessidades de um negcio.
Este trabalho busca inserir no UP atividades para o levantamento de requisitos baseado em
uma arquitetura de modelagem de negcios. Desta forma estas atividades podero ser
aplicadas em qualquer metodologia de desenvolvimento de sistemas que se fundamente nos
mesmos princpios estabelecidos no UP.
Palavras-chave: Modelagem de Negcios, Levantamento de Requisitos, Processo Unificado.


1. Introduo
As organizaes empresariais modernas precisam estar em constante evoluo para se
manterem competitivas. So necessrias freqentes reformulaes e inovaes nos processos
de negcio e conseqentemente nos sistemas de informao que os do suporte. A integrao
entre os objetivos do negcio, os processos de negcio, e sistemas de informao um fator
determinante da dinmica necessria organizao e tambm um desafio aos gerentes.
Existem vrios mtodos, tcnicas e ferramentas de modelagem para facilitar o entendimento e
anlise da complexidade das organizaes modernas. Essas facilidades so utilizadas na
tentativa de tornar a realidade organizacional complexa mais compreensvel. Tambm existem
vrias metodologias para o desenvolvimento de sistemas de informao. O que se observa no
entanto uma falta de integrao entre a anlise nos dois domnios, o do negcio e o dos
sistemas que os do suporte.
Dentre as metodologias de desenvolvimento de sistemas de software o Processo Unificado
(UP) uma das que vm obtendo destaque entre as demais. Entretanto mesmo no UP a
atividade de levantamento de requisitos ainda um processo emprico, no considerando de
forma sistemtica a importncia do foco nos objetivos do negcio.
Neste contexto, evidencia-se a necessidade de uma maior aproximao entre o levantamento
de requisitos de sistemas de softwares, nos processos de desenvolvimento de software, s
reais necessidades do negcio. No paradigma da orientao a objeto a anlise de requisitos
tem sido feita com base num elemento de modelagem da UML chamado de Caso de Uso.
Embora existam algumas heursticas propostas para identificao de casos de uso, como as
apresentadas em Schneider (1998), Jacobson (1999), e em Lilly (1999), no existem mtodos
estabelecidos que tornem esta atividade mais sistemtica.

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 2

O alinhamento entre requisitos de software e as reais necessidades de informatizao da
empresa pode ser otimizado atravs de tcnicas de modelagem de negcios. Assim, neste
artigo so apresentadas algumas definies relativas a Engenharia de Requisitos, o Processo
Unificado (UP), e so apresentados alguns conceitos relacionados com a modelagem de
processos de negcios com a UML e questes relacionadas com a identificao de casos de
uso de negcio. Ento, so descritas as atividades propostas a serem inseridas em
metodologias baseadas no UP, e finalmente so realizadas as consideraes finais.
2. Engenharia de Requisitos e o Processo Unificado
A engenharia de software se d atravs de um conjunto de fases. Cada uma das fases pode
envolver mtodos, ferramentas e procedimentos. A forma de estruturao destas so citadas
como modelo de engenharia de software (PRESSMAN, 1995). Pressman tambm analisa que
independentemente do modelo de desenvolvimento de software, o processo de
desenvolvimento de software contm trs fases genricas: definio, desenvolvimento e
manuteno.
Quatro modelos de engenharia de software tm sido amplamente discutidos: o ciclo de vida
clssico (ou cascata), a prototipao, o modelo espiral, e as tcnicas de Quarta gerao
(PRESSMAN, 1995). Atualmente um novo modelo tem sido amplamente usado, o modelo
iterativo e incremental. Este modelo apresentado por Jacobson (1999) e por Paula (2001).
A anlise de requisitos uma etapa sempre presente na fase de definio do software,
independentemente do modelo de engenharia de software adotado. Ela efetua a ligao entre a
necessidade de informatizao de processos ao projeto do software que atender tais
necessidades. Uma srie de mtodos de anlise e especificao de requisitos foi desenvolvida,
entretanto, poucas so as propostas que visam uma sistematizao da identificao de
requisitos de forma a tornar esta atividade menos subjetiva.
O Processo Unificado (UP) um processo estabelecido para o desenvolvimento de software
que resultou de trs dcadas de desenvolvimento e uso prtico. Jacobson (1999) apresenta as
origens do UP desde o processo Objectory (com primeira verso em 1987) passando pelas
contribuies do Processo Rational Objectory (em 1997) at o Processo Unificado da Rational
- RUP. O propsito do UP , como qualquer outro processo de desenvolvimento, determinar
um conjunto de atividades necessrias para transformar requisitos em sistemas de software.
Ele utiliza a UML como linguagem para a modelagem dos artefatos de software produzidos
ao longo do processo de desenvolvimento. A UML foi adotada pela OMG (Object
Management Group) em 1997 como linguagem padro para a modelagem de sistemas
orientados a objeto. Ela uma linguagem para especificao, visualizao, construo, e
documentao de artefatos de sistemas de software, como tambm para a modelagem de
negcios e outros sistemas que no de software. Ela representa uma coleo das melhores
prticas de engenharia que provaram sucesso na modelagem de sistemas grandes e complexos
(OMG, 1997).
3. Modelagem de Processos de Negcios com a UML
Segundo Johansson (1995) um processo de negcio um conjunto de atividades ligadas que
tomam um insumo de entrada e o transformam para criar um resultado de sada.
Teoricamente, a transformao que nele ocorre deve adicionar valor e criar um resultado que
seja mais til e eficaz ao recebedor acima ou abaixo da cadeia.
Vrias so as tcnicas, metodologias e notaes existentes para a modelagem de empresa
(VERNADAT, 1996). Para que uma empresa possa ser adaptvel s mudanas, ela precisa ter
uma descrio simples e unificada de suas entidades. Embora este seja o objetivo de muitos

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 3

esforos para modelagem, o que se tem hoje ainda uma descrio tipicamente extensa,
inflexvel, e frgil (MARSHALL, 1999).
Recentemente a UML (Unified Modeling Language), que j se encontra consagrada para a
modelagem de sistemas de software, tem sido proposta para a modelagem de empresas
atravs de seus mecanismos de extenso. Segundo a OMG (1997) a UML possui mecanismos
de extenso que permitem adequ-la a novidades e domnios especficos.
As extenses definidas pelos usurios na UML se do atravs de esteritipos, valores
associados e restries que coletivamente estendem e adaptam a UML a um domnio
especfico. Na subseo seguinte ser apresentada uma propostas de extenses para a
modelagem de negcios com a UML.
3.1 Proposta de Eriksson e Penker
As propostas de Eriksson e Penker (2000) formam uma Arquitetura baseada na linguagem
UML para a modelagem de negcios com a qual um arquiteto de negcios pode adicionar
stereotypes, tagged values e constraints convenientes para sua linha de negcios. Seu trabalho
baseia-se basicamente em extenses da UML para representar: processos, recursos, regras e
objetivos. Sua proposta baseia-se na hiptese de que um negcio pode ser modelado atravs
de objetos e relacionamentos entre estes. Uma arquitetura de modelagem fornece vistas para a
modelagem com foco em aspectos significativos. Cada vista pode ser modelada por um ou
mais tipos de diagramas. A Arquitetura proposta oferece as seguintes vistas :
Viso do Negcio (Business Vision) : Modela conceitos e objetivos a serem seguidos de
acordo com a estratgia do negcio;
Processo do Negcio (Business Process): Modela os processos de negcio, e seus
relacionamentos com os recursos, a serem seguidos para atingir os objetivos;
Estrutura do Negcio (Business Structure): Modela a estrutura dos recursos (fsicos,
informacionais, humanos);
Comportamento do Negcio (Business Behavior): Modela o comportamento e interao
entre recursos e entre processos.
Dentro desta vista de Processo do Negcio destaca-se aqui o Diagrama de Processos de
Negcio e o Diagrama de Linha de Montagem. O Diagrama de Processos de Negcio
descreve os processos de negcio atravs de suas relaes com Objetos (Objetivos, Entradas,
Sadas, Fornecedores e Controles). No topo do diagrama de Linha de Montagem est um
Diagrama de Processos de Negcios. Abaixo deste esto um nmero de pacotes horizontais
que so chamados pacotes de linha de montagem, cada um representando um grupo de
objetos. Os objetos de um pacote podem ser de uma classe especfica ou de diferentes classes.
Um pacote de linha de montagem um item pacote da UML estereotipado para <<linha de
montagem>> e desenhado como um longo retngulo horizontal. A Figura 1 mostra o exemplo
de um processo (Tratar Entrega de Volumes), ilustrando a identificao de casos de uso
relativos ao processo de negcio.
O propsito deste diagrama demonstrar como o processo na parte superior do diagrama
utiliza e gera objetos na linha de montagem. A referncia de um objeto a uma linha de
montagem indicada por um fluxo de objeto (representado por uma linha tracejada na UML)
entre o processo e o objeto dentro do pacote na linha de montagem. O diagrama de linha de
montagem pode ser usado como tcnica para levantamento de casos de uso do sistema ou
sistemas que daro suporte aos processos de negcio.

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 4

A identificao dos casos de uso atravs desta tcnica faz com que os objetivos dos atores, e
conseqentemente os requisitos do sistema em forma de casos de uso, estejam alinhados aos
objetivos globais do negcio uma vez que so analisados com base nos processos de negcio
e estes por sua vez foram definidos em funo dos objetivos do negcio.

Figura 1 Diagrama de Linha de Montagem e Identificao de Casos de Uso.

4. Proposta de Atividades para a Sistematizao do Levantamento de Requisitos no UP
Este trabalho prope um wokflow a ser inserido no UP para a modelagem de negcio com
base na tcnica de modelagem proposta por Eriksson e Penker (2000). Tambm so propostas
atualizaes em algumas atividades pr-estabelecidas no UP. As atividades so propostas de
forma a poderem ser aplicadas a qualquer metodologia que se baseie no UP.
A tcnica de construo de arquiteturas de negcio proposta por Eriksson e Penker , dentre
as propostas de modelagem de negcio com UML pesquisadas, a nica que aborda de forma
sistemtica a passagem da arquitetura de negcio para uma arquitetura de software que d
suporte primeira. Porm, Eriksson e Penker no exploram a sistematizao desta passagem
no contexto de um processo ou metodologia de desenvolvimento de sistemas.
No UP as atividades do workflow de levantamento de requisitos existem em todas as fases do
desenvolvimento com maior nfase nas fases de Concepo e Elaborao. Na fase de
Concepo existe uma maior nfase na identificao dos requisitos mas no na especificao
detalhada dos mesmos, esta deve ser feita na Elaborao.
Um mtodo de levantamento de requisitos que derive os casos de uso de uma arquitetura de
software no UP deve definir atividades e seus fluxos, bem como o estado esperado dos
artefatos gerados por estas atividades, em cada fase do processo (Concepo, Elaborao,
Construo, e Transio), considerando tal estrutura iterativa e incremental.

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 5

A aplicao da tcnica de Eriksson e Penker ao UP se realiza portanto atravs da definio de
um workflow para a modelagem de negcio e atualizaes nas atividades j estabelecidas para
os outros workflows de forma a integr-los. Algumas atividades so adicionadas e outras
apenas atualizadas com a insero de sub-atividades. Tambm definida a abordagem que
cada atividade proposta deve ter nas fases de Concepo e Elaborao, que como visto
anteriormente so as fases onde devem existir as atividades de anlise de requisitos.
4.1 Workflow para Modelagem de Negcio
O workflow definido para a modelagem de negcio apresentado na Figura 2 e a seguir so
apresentadas as descries de cada atividade e a abordagem que devem ter em cada fase do
processo de desenvolvimento.

Figura 2 - Workflow para a Modelagem de Negcio.
- Modelar os Objetivos do Negcio: A modelagem dos objetivos deve identificar os
principais objetivos e sub-objetivos do negcio numa estrutura hierrquica que permita a
visualizao de dependncia entre tais objetivos. Este modelo servir de base para a definio
dos processos de negcio. A modelagem dos objetivos do negcio deve ser feita com base em
entrevistas realizadas com os conhecedores do negcio. Produto resultante: Diagrama de
Modelo de Objetivos.
Na Concepo o Modelo de Objetivos deve abordar todos os objetivos relevantes ao projeto
em questo, desde os de nvel mais estratgico at os que estejam ao nvel de objetivos de
processos de negcio.
Na Elaborao Deve-se atualizar o modelo de objetivos em funo de possveis
esclarecimentos posteriores.
- Modelar os Processos de Negcio: Os processos de negcio devem ser definidos buscando
a realizao dos objetivos identificados no Modelo de Objetivos do Negcio. Porm, no
necessrio haver uma relao 1 para 1 entre processos de negcios e objetivos do negcio pois
muitos processos auxiliares no estaro necessariamente relacionados a um objetivo do
Modelo de Objetivos do Negcio. Entrevistas com os envolvidos no negcio tambm devem
ser realizadas para fornecer subsdios definio dos processos de negcio. Produto
resultante: Diagrama de Processos de Negcio.
Na Concepo Deve-se identificar os principais processos de negcio, suas relaes com os
recursos (entradas, sadas, fornecedores, controles e objetivo), e a seqncia de execuo dos
mesmos. Porm, no necessria a descrio detalhada do fluxo de eventos ocorrido
internamente no processo.
Na Elaborao Detalhar o fluxo de eventos dos processos que sero abordados na iterao.
- Modelar os Recursos Envolvidos: Os recursos, informaes e unidades organizacionais
devem ser modelados atravs dos diagramas da Vista de Estrutura do Negcio. A modelagem

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 6

destes elementos deve ser feita paralelamente s atividades de Modelagem de Processos de
Negcio a fim de se ter um melhor entendimento dos termos relacionados ao negcio e
conseqentemente uma maior consistncia na modelagem do mesmo. Produtos resultantes:
Diagramas de Modelos de Recursos, Informaes e Organizao.
Na Concepo Devem ser modelados todos os recursos significativos identificados no
Modelo de Processo de Negcio definido na fase Concepo, de forma a analisar a
dependncia entre tais recursos e suas propriedades.
Na Elaborao Modelar todos os recursos significativos identificados durante o
detalhamento dos fluxos de eventos de cada processo de negcio.
- Modelar Comportamento dos Recursos: Um Diagrama de Estados de Recurso pode ser
criado para facilitar a determinao dos processos de negcio quando este se caracteriza por
refinamentos de um mesmo objeto ao longo da cadeia de valor. Por exemplo, considerando
um negcio de vendas, o pedido pode ser abordado como um objeto cujo estado vai sendo
alterado (refinado) ao longo de toda a cadeia de valor, desde a abertura do pedido at a
confirmao do pedido entregue ao cliente. Num caso como este a identificao dos estados
possveis de tal objeto (como pedido solicitado, pedido em verificao de estoque, pedido em
produo, pedido em expedio e pedido entregue) pode facilitar a identificao dos
processos de negcio necessrios ao cumprimento das mudanas de estado do produto.
Produto resultante: Diagrama de Estado de Recurso e Diagramas de Interao de Recursos e
de Estados.
Na Concepo Modelar o comportamento de recursos nos caso em que estes sofram vrias
alteraes ao longo dos processos de negcio e esta dinmica de alteraes precisa ser melhor
entendida.
Na Elaborao Detalhar os Diagramas de Estado de Recursos, caso tenham sido criados na
fase Concepo, com base no detalhamento dos fluxos de evento dos processos.
- Definir Papis e Responsabilidades: Cada processo de negcio deve possuir um
responsvel uma vez que ele geralmente no estar ligado a uma nica unidade
organizacional, mas sim passando por mais de uma delas. Cada processo por sua vez define
um fluxo de eventos que pode envolver um ou mais atores. necessrio definir que atores
agem em cada um dos processos. Isto pode ser feito atravs de uma anlise do fluxo de
eventos e associao destes aos atores envolvidos no processo. Produto Resultante: Tabela de
Papis e Responsabilidades.
Na Concepo Definir apenas os responsveis por cada processo de negcio, sejam eles
unidades organizacionais ou funes.
Na Elaborao Definir os papis (atores) associados aos eventos que ocorrem no fluxo de
evento de cada processo de negcio.
4.2 Workflow de Levantamento de Requisitos
A atividade seguinte foi adicionada ao Workflow de Levantamento de Requisitos:
- Identificar Necessidades de Informatizao: Nesta atividade deve-se associar os processos
de negcio aos sistemas de informao que lhes do suporte e assim identificar a possvel
necessidade de novos sistemas de informao atravs da identificao de carncias de suporte
automatizado de informao e operaes aos processos. Sugere-se a utilizao do Diagrama
de Linha de Montagem como base para a realizao desta atividade. Produto resultante:
Diagrama de Linha de Montagem com os pacotes de linha de montagem identificados.

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 7

Na Concepo Identificar sistemas de software que do suporte aos processos de negcio
bem como identificar a necessidade de novos sistemas e subsistemas. Utilizar o Diagrama de
Linha de Montagem como recurso de apoio ao desenvolvimento desta atividade. Deve-se
comear com os pacotes em um alto nvel de abstrao, representando os sistemas j
existentes e a natureza das informaes das referncias que estes fazem a cada processo de
negcio analisado. Deve-se ento fazer uma primeira avaliao quanto natureza das
informaes e as operaes necessrias ao processo e o atendimento destas pelos sistemas
existentes, de forma a buscar identificar tipos de informaes e operaes que no esto sendo
mantidas pelos sistemas de software disponveis. Tais necessidades de informao e de
operaes devem ser referenciadas a um outro pacote representativo do sistema (ou sistemas)
a ser construdo para atender tais requisitos.
Na Elaborao Deve-se atualizar e aprofundar a anlise iniciada na Concepo com base na
descrio do fluxo de evento dos processos. Deve-se avaliar cada fluxo de evento e identificar
eventos que podem ser auxiliados por sistemas de informao mas que ainda no so. Tais
auxlios devem ser representados como referncias do processo aos sistemas que os realizam.
Considerando o escopo de um sistema identificado na concepo deve-se representar cada
linha de montagem como uma classe do sistema e distribuir a responsabilidade entre as
classes atravs das referncias feitas a cada uma delas pelos processos. Cada evento a ser
informatizado deve resultar em uma referncia classe que o realizar e quando esta no
existir dever ser criada como uma nova linha de montagem. Este processo deve ser feito
respeitando-se o conceito de encapsulamento.
- Derivar Casos de Uso dos Processos de Negcio: Os casos de uso devem ser identificados
com base nos processos de negcio. Esta atividade deve resultar em uma Relao de Casos de
Uso na qual deve-se associar cada caso de uso identificado ao processo de negcio a que este
atende. Sugere-se a utilizao do Diagrama de Linha de Montagem como base para a
realizao desta atividade. A identificao dos casos de uso no Diagrama de Linha de
Montagem se d atravs do agrupamento de referncias (entre o processo e os sistemas) de
mesma natureza. Produto resultante: Diagrama de Linha de Montagem e casos de uso.
Na Concepo A atividade deve visar a identificao dos casos de uso arquiteturalmente
significativos. Estes casos de uso representam funcionalidades num alto nvel de abstrao.
Estes casos de uso servem como base para a definio da vista lgica da arquitetura de
software que os realizar.
Na Elaborao A atividade visa identificar todos os casos de uso do sistema com base na
anlise das referncias entre os processos detalhados e os sistemas de software que os apoiar.
4.3 Workflow para Anlise
A atividade Realizao de Casos de Uso, existente no UP, foi atualizada com a sub-atividade:
- Identificar Classes a partir da Arquitetura de Negcio: Esta atividade consiste a
identificao de Classes a partir de modelos da Vista de Estrutura do Negcio e da Vista de
Processos de Negcio. Produto resultante: Diagrama de Classes.
Na Concepo: Busca-se a identificao das principais Classes do sistema com base na
anlise dos Modelos de Recursos e de Informaes.
Na Elaborao: Deve ser feita uma reavaliao das Classes identificadas com base nas
referncias do Diagrama de Linha de Montagem desenvolvido nesta fase. Atravs da anlise
das referncias deve-se identificar que classes sero responsveis pela realizao dos casos de
uso identificados no Diagrama de Linha de Montagem.

XXIII Encontro Nac. de Eng. de Produo - Ouro Preto, MG, Brasil, 21 a 24 de out de 2003
ENEGEP 2003 ABEPRO 8

5. Consideraes Finais
O UP no define adequadamente atividades para a Modelagem de Negcio. Nele, as
atividades comeam a partir do levantamento de requisitos e a modelagem de negcio
apenas citada como um possvel facilitador para a identificao de possveis atores do
sistema. O RUP apresenta uma proposta de modelagem de negcio atravs de casos de uso de
negcio. Esta proposta, no entanto, apresenta limitaes quanto a modelagem de fluxos entre
os processos de negcio e quanto ao alinhamento dos casos de uso identificados aos reais
objetivos do negcio. No domnio da modelagem de negcio a tcnica de construo de
arquiteturas de negcio proposta por Eriksson e Penker (2000) , dentre as propostas de
modelagem de negcio com UML pesquisadas, a nica que aborda de forma sistemtica a
passagem da arquitetura de negcio para uma arquitetura de software que d suporte
primeira. Eriksson e Penker porm no exploram a sistematizao desta passagem no contexto
de um processo ou metodologia de desenvolvimento de sistemas.
Neste artigo foram propostas atividades para a modelagem de negcio, com base na tcnica
proposta por Eriksson e Penker, a serem inseridas no UP ou em qualquer metodologia que se
baseia nos mesmos princpios deste, com o objetivo de sistematizar a identificao de
requisitos de softwares alinhados aos objetivos do negcio. As atividades definidas no mtodo
mostraram-se consistentes com o modelo iterativo e incremental, e com interfaces bem
estabelecidas com as atividades pr-estabelecidas no UP, apresentando duas vantagens:
- A identificao sistemtica de necessidade de informatizao a partir do fluxo de evento dos
processos estabelecida na atividade
- A identificao sistemtica dos casos de uso numa abordagem iterativa estabelecida na
atividade Derivar Casos de Uso dos Processos de Negcio.
A identificao dos casos de uso a partir do diagrama de linha de montagem mostrou-se um
procedimento eficiente, facilitando a identificao das reais necessidades de informatizao
nos processos de negcio. Como proposta para trabalhos futuros sugere-se a comparao
desta tcnica com demais tcnicas de identificao de requisitos, e a construo de uma
ferramenta CASE que permita uma maior automao das atividades definidas neste trabalho.
Referncias
ERIKSSON, HANS-ERIK e PENKER, MAGNUS. Business Modeling with UML. Estados Unidos: Wiley &
Sons, 2000. 459p.
JACOBSON, I., BOOCH, G., RUMBAUGH, J.. The Unified Software Development Process. Addison Wesley,
1999.
JOHANSSON, HENRY J., MCHUGH, P., PEDLEBURY, J., WHELLER III, W. Processos de Negcio. Rio de
Janeiro: Pioneira, 1995.
LILLY, S. Use Case Pitfalls: top 10 problems from Real projects using Use Cases, In: Proceedings, technology
of object oriented languages and systems, 1999.
MARSHALL, C. Enterprise Modeling with UML. USA: Addison-Wesley, 1999.
OMG - Object Management Group. UML Especifications.1997. Disponvel na Internet em
http://www.rational.com/uml.
PAULA, W. P. F., Engenharia de Software Fundamentos, mtodos e padres. Rio de Janeiro: LTC, 2001.
PRESSMAN, R. S., Engenharia de Software. So Paulo: Makron Books, 1995.
SCHNEIDER, G., WINTERS, J. P., Applying Use Cases: a pratical guide, Addison Wesley, 1998.
VERNADAT, F. B., Enterprise Modeling and Integration: Principles and Application. Londres: Chapman &
Hall, 1996. 509p.