Modelagem Organizacional: captura dos requisitos organizacionais no desenvolvimento de sistemas de informação

Organizational Modeling: identifying organizational requirements for the development of information systems

Modelagem Organizacional: captura dos requisitos organizacionais no desenvolvimento de sistemas de informação

Organizational Modeling: identifying organizational requirements for the development of information systems

Sílvia Inês Dallavalle de Pádua^I; Edson Walmir Cazarini^II; Ricardo Yassushi Inamasu^III

^IUniversidade de São Paulo, Escola de Engenharia de São Carlos, Departamento de Engenharia Mecânica, Laboratório de Simulação, Avenida Trabalhador São-carlense, 400, São Carlos, SP, CEP 13566-590, e-mail: [e-mail]

^IIUniversidade de São Paulo, Escola de Engenharia de São Carlos, Departamento de Engenharia de Produção, Avenida Trabalhador São-carlense, 400, São Carlos, SP, CEP 13566-590, e-mail: [e-mail]

^IIIEMBRAPA, Centro Nacional de Pesquisa e Desenvolvimento de Instrumentação Agropecuária, Rua XV de Novembro, 1452, São Carlos, SP, CEP 13560-970, e-mail: [e-mail]

RESUMO

Existem muitos sistemas que, embora tecnicamente corretos, não satisfazem as reais necessidades do negócio. Isso ocorre porque a tecnologia da informação é, muitas vezes, utilizada apenas para automação dos processos de negócio existentes e não para a reformulação desses processos, visando a encontrar todas as necessidades do usuário. Nesse sentido, este trabalho tem o objetivo de apresentar algumas técnicas de Modelagem Organizacional, um breve estudo comparativo entre essas técnicas e detalhar o Enterprise Knowledge Development (EKD), que é um método de Modelagem Organizacional, que facilita a aquisição do conhecimento da estrutura organizacional e estratégica; auxilia na captura dos requisitos organizacionais, na tentativa de melhorar a compreensão do domínio e na interação com usuários, para que eles entendam o que o sistema de informação pode fazer para melhorar o negócio.

Palavras-chave: Modelagem Organizacional, regras de negócio, EKD, modelagem do conhecimento organizacional, engenharia de requisitos.

ABSTRACT

Though technically correct, many information systems fail to meet the real needs of users in a business setting because information technology is often used only to automate the existing business processes and not to reformulate those processes with a view to meeting all the user's needs. In this context, this paper discusses various organizational modeling techniques, briefly compares these techniques, and gives a detailed description of the EKD – an organizational modeling method designed to facilitate the acquisition of knowledge about organizational and strategic structures. The method helps to grasp organizational requirements, enhancing comprehension of the domain and interaction with the user and enables to understand what the information system can do to improve the business.

Keywords: Organizational Modeling, Business Rules, EKD, Modeling of Organizational Knowledge, Requisite Engineering.

1. Introdução

Muitas técnicas tradicionalmente aplicadas no desenvolvimento de software tratam de aspectos relacionados à funcionalidade do sistema, à descrição de atividades e entidades, às entradas que deverão ser transformadas e às saídas que deverão ser produzidas, porém sem considerar aspectos mais amplos como: os objetivos da organização, as regras do negócio, as restrições, os aspectos não funcionais relacionados à qualidade, à confiabilidade e à usabilidade. De acordo com Alencar (1999), essas técnicas não ajudam, portanto, a buscar soluções alternativas para problemas da organização, não adicionam valor ao negócio e, na maioria das vezes, os processos manuais são automatizados sem nenhuma modificação. Os requisitos organizacionais não devem ser considerados como uma simples descrição da funcionalidade do sistema, pois tratam do domínio no qual o sistema está inserido e das restrições que podem existir no ambiente, no sistema e no desenvolvimento, diminuindo ambigüidades e incertezas. Nesse contexto, a Modelagem Organizacional facilita a compreensão do ambiente empresarial e é reconhecida como uma atividade valiosa pela engenharia de requisitos. O modelo organizacional é uma representação da estrutura, das atividades, dos processos, das informações, dos recursos, do pessoal, do comportamento, dos objetivos e das restrições das empresas comerciais, governamentais ou de outra natureza. Esse modelo ajuda a compreender as complexas interações entre as organizações e as pessoas.

Bubenko (1993) faz importante observação com relação ao grande número de ferramentas de métodos Computer-Aided Software Engineering (CASE). Para o autor, esses produtos são direcionados para a metade ou para o final do processo de desenvolvimento de software. Praticamente nenhum deles é direcionado de forma estruturada para o início do processo, os objetivos do negócio, os estágios de geração de requisitos, e não resolvem o problema de mover do domínio informal para o formal. Os métodos existentes não são designados para captura explícita e representação de forma estruturada do "conhecimento organizacional e do negócio" para ser, subseqüentemente, usado na fase de projeto do sistema de informação. Não são mantidas ligações entre modelo organizacional e especificação do sistema. Assim, não pode ser explicitamente feito o gerenciamento de mudança e de evolução da organização, e nem o mapeamento de mudanças nos requisitos e nos componentes do sistema de informação.

De acordo com Stergiou e Johnson (1998), a transformação organizacional tem sido amplamente discutida e praticada. Os autores falam em um "vazio" entre negócios e tecnologia da informação, como o grande problema das organizações e sistemas.

Para diminuir esse "vazio" entre negócios e tecnologia da informação, será apresentado, no presente trabalho, um estudo comparativo entre algumas técnicas de Modelagem Organizacional e será mais detalhado o EKD que é um método de Modelagem Organizacional, que facilita a aquisição do conhecimento da estrutura organizacional e estratégica; auxilia na captura dos requisitos organizacionais, na tentativa de melhorar a compreensão do domínio e na interação com usuários, para que eles entendam o que o sistema de informação pode fazer para melhorar o negócio.

2. Abordagens de Modelagem Organizacional

Cada organização tem missão, objetivos e processos próprios e é importante dar atenção à modelagem desses itens. Alencar (1999) destaca os seguintes objetivos da Modelagem Organizacional:

1) Fornecer um objeto, que seja uma representação compartilhável e reusável da cadeia de fornecimento de informação e conhecimento;

2) Suportar tarefas da cadeia de fornecimento, pela habilitação de respostas a questionamentos, que não estão explicitamente representados no modelo;

3) Definir os objetos de maneira precisa, de forma que sejam consistentemente aplicados, por meio dos domínios e interpretados pelos usuários; e

4) Suportar visualização do modelo, de forma intuitiva, simples e consistente.

Muitas técnicas de Modelagem Organizacional são propostas, algumas com o foco principal nos aspectos sociais como em Dobson (1994) que descreve os objetivos, política e estrutura da organização. Na linha de Bubenko (1994), Yu (1993) e Rolland et al. (2000), é realizada a Modelagem Organizacional com múltiplas visões com análise de metas e objetivos da organização. A organização, segundo esses autores, é representada por meio de modelos, que facilitam a realização de especificações de requisitos mais próximas à realidade da organização.

Os modelos de requisitos existentes descrevem o ambiente organizacional em termos de entidades e atividades, sem se importarem com situações em que os usuários poderão tomar diferentes decisões. Esses modelos têm como objetivo a descrição de sistemas técnicos, em vez de fornecer descrições mais ricas sobre as organizações sócio-humanas. As informações capturadas nos modelos existentes, como Diagrama de Fluxo de Dados (DFD) e Diagrama Entidade e Relacionamento (DER), não são suficientes, uma vez que esses modelos descrevem apenas entidades, funções, fluxo de dados e estados do sistema, não expressando as razões envolvidas no processo, ou seja, o porquê de fazer uma determinada ação ou o porquê de tomar uma decisão (alternativas para o "como fazer"). Assim, faz-se necessário uma ontologia mais rica, que facilite os esforços da Engenharia de Requisitos, para obter uma melhor compreensão sobre os relacionamentos da organização entre os vários atores do sistema, e entender as razões envolvidas nos processos de decisões. Algumas técnicas de Modelagem Organizacional são:

1. A técnica ORDIT (Organizational Requirements Definition of Information Technology Systems), de acordo com Dobson apud Alencar (1999), serve para ajudar os participantes das organizações a definir técnicas alternativas e o futuro organizacional e, conseqüentemente, o papel da tecnologia da informação, fornecendo um processo sistemático e aproveitável, que seja capaz de suportar gerações de requisitos organizacionais, e fornecer métodos e ferramentas associadas que suportem o processo.

2. A técnica de modelagem de Furlan (1997) tem como princípio conhecer a missão da organização. A missão é o motivo pelo qual a empresa foi criada, ou seja, a identidade da organização, sendo um texto curto e objetivo. O próximo passo é definir os objetivos executivos ou objetivos da organização, que são os alicerces para a missão, e que devem, portanto, ser totalmente compatíveis com o que estabelece a missão. Os objetivos estarão melhor definidos conforme o desenvolvimento da empresa. Depois, serão definidos os objetivos estratégicos que estão relacionados com as áreas funcionais, com a finalidade de alcançar os objetivos executivos e os fatores chaves de sucesso. Para alcançar os fatores chaves de sucesso são desenvolvidas estratégias, que serão o diferencial da empresa no mercado. Os planos de ação representam a concretização das estratégias.

3. A técnica F3 de Bubenko (1993) destaca áreas de conhecimento da organização. É constituída por cinco modelos elaborados a partir de objetivos (Modelo de Objetivos - MO), atores (Modelo de Atores - MA), atividades e uso (Modelo de Atividades e Uso - MAU), conceitos (Modelo de Conceitos - MC) e requisitos (Modelo de Requisitos do Sistema de Informação - MRSI).

4. A técnica i* de Yu apud Alencar (1999) é composta por dois modelos: o Modelo de Dependências Estratégicas (SD) e o Modelo de Razões Estratégicas (SR). O Modelo de Dependências Estratégicas (SD) descreve as relações de dependências externas entre os atores da organização, e o Modelo de Razões Estratégicas (SR) descreve interesses e conceitos dos participantes e as direções que podem seguir. As semânticas dos relacionamentos, no Modelo de Dependências Estratégicas (SD), são caracterizadas em termos de algumas supostas características internas intencionais do agente, algumas das quais são, explicitamente, modeladas no segundo tipo de modelo previsto na técnica i*, Modelo de Razões Estratégicas (SR). Na estrutura interna intencional de um agente, na qual todas as variáveis livres nas fórmulas são entendidas como universalmente quantificadas, inclui-se, pelo menos, os três componentes seguintes: (a) Ux – um conjunto de rotinas; (b) Hx – um conjunto de regras meio-fim; e (c) Ex – um conjunto de elementos primitivamente manipuláveis; e

5. A metodologia EKD (Enterprise Knowledge Development), segundo Rolland et al. (2000) e Nurcan (1999), fornece uma forma sistemática de documentar e analisar organização e seus componentes, usando a Modelagem Organizacional. De acordo com Kirikova (2000), a família de modelo do EKD é destinada para responder as questões: o que, como, onde, quem, quando e por que. Essa estrutura serve como um esquema de classificação conveniente ou "tabela periódica" para entidades de informação. Como elementos químicos, essas entidades podem ser combinadas de infinitas formas, para produzir o sistema de informação de interesse da organização. Em outro ponto de vista, é possível ver essa estrutura como uma família de muitos modelos inter-relacionados, em que relacionamentos entre elementos arbitrários pertencentes a sub-modelos são permitidos. O EKD fornece base para o entendimento e apoio às mudanças organizacionais e ajuda o desenvolvimento de sistemas de informação que apoiará a organização. Para Kirikova (2000), essa talvez seja a teoria mais rica em uso. A proposta de usar o EKD é prover uma descrição clara e não ambígua de:

• Como a organização funciona atualmente;

• Quais são os requisitos e as razões para a mudança;

• Quais alternativas deveriam ser criadas para encontrar esses requisitos; e

• Quais são os critérios e argumentos para avaliação dessas alternativas.

2.1 Considerações sobre as técnicas

A técnica de Furlan (1997) e a técnica ORDIT não desenvolvem modelos com múltiplas visões, não consideram as regras do negócio, não apresentam modelos de processos, o que dificulta o trabalho de captura dos requisitos organizacionais. A técnica de Furlan (1997) se concentra na definição da missão, objetivos, estratégias e plano de ação. Não considera especificação dos requisitos organizacionais, e os atores envolvidos. A técnica ORDIT trata a responsabilidade das pessoas envolvidas no trabalho. As práticas de trabalho são descritas como responsabilidades e relacionamentos em vez de atividades ou processos. Não trata objetivos organizacionais.

O principal enfoque da técnica i* são os atores, concentrando-se na análise das implicações sob o ponto de vista dos relacionamentos de dependência entre os atores de uma organização. A técnica F3 tem como enfoque principal os objetivos, dos quais derivam-se as atividades e os atores. O objetivo, na técnica i*, está vinculado a uma dependência entre dois atores, ou seja, o que um espera obter do outro. Em F3, o objetivo está vinculado à organização e não a um ator em específico ou a um relacionamento entre dois atores. Na técnica i*, por meio dos atores, decidem-se os domínios dos objetivos; em F3 partindo-se dos objetivos surgem os domínios.

Um fator muito importante para a Engenharia de Requisitos é a compreensão por todos (desenvolvedores, clientes e usuários). Uma vez que o problema esteja claro, é possível validar requisitos. Alencar et al. (1999) explicam que o entendimento dos modelos recai na questão de pontos de vista. Por parte dos profissionais técnicos, aptos a lidarem com modelos gráficos do tipo DFD ou DER, o entendimento dos modelos propostos pelas duas técnicas não se diferenciariam quanto à dificuldade ou facilidade de compreensão. A técnica i* trabalha com um pouco de rigor matemático, o que não é muito atraente para alguns desenvolvedores de software. Com pouco esforço, esses profissionais compreenderiam o significado dos modelos em ambas as técnicas. Contudo, por parte de outros profissionais não especificamente ligados à área de desenvolvimento de software, os modelos da técnica i* seriam de difícil compreensão, ao passo que os modelos F3, seriam mais fáceis de serem entendidos e analisados. De acordo com Bubenko e Wangler (1993), para uma pessoa do negócio ser capaz de ler e validar os modelos, é necessário que a linguagem seja fácil de entender.

Em F3, o ponto principal está no conhecimento ou identificação dos objetivos da organização, retratados em seu modelo de Objetivos (MO), do qual resultam os modelos de Atividades e Uso (MAU) e o de Atores (MA). A técnica i* estabelece de imediato a noção dos atores e seus relacionamentos, partindo do modelo de Relacionamentos Estratégicos (SD) e derivando o modelo de razões estratégicas (SR).

As Regras do Negócio propostas em Bubenko (1993) no Modelo de Objetivos (MO), em princípio não são tratadas especificamente na técnica i* (Alencar, 1999). De acordo com Berztiss e Bubenko (1995), a experiência tem mostrado que o uso de uma abordagem dirigida a modelo de objetivos proporciona um melhor entendimento do domínio para os tomadores de decisões, definidores de requisitos, desenvolvedores de software e usuários finais, além do valor econômico de melhorar a comunicação e entendimento, minimizando retrabalho nos estágios finais do processo de desenvolvimento do sistema de informação. Um bom sistema de informação pode ser uma vantagem competitiva do negócio, mas se o sistema não atende às necessidades do negócio, este pode ter seu desempenho prejudicado. Esse é o motivo do início de uma troca de paradigma da Engenharia de Sistemas, orientada à tecnologia para estruturas, que valorizam a modelagem de "regras do negócio" (Bubenko e Wangler, 1993). A importância de regras de negócio, na Modelagem Organizacional e na especificação de requisitos tem sido discutida por diversos autores (Bubenko (1993) Bubenko e Wangler (1993), Stergiou e Johnson (1998), Rosca et al. (1997), Gottesdiener (1999), Herbst (1996), Kilov e Simmonds (1997), Dallavalle e Cazarini (2000), Pádua (2001) e Leite e Leonardi (1998)).

O método EKD é uma evolução da técnica F3. O método é orientado a objetivos e trata também os atores envolvidos nos processos, nas regras e nos objetivos da organização. O EKD é composto de seis modelos: Modelo de Objetivos (MO), Modelo de Regras do Negócio (MRN), Modelo de Conceitos (MC), Modelo de Processos de Negócio (MPN), Modelo de Atores e Recursos (MAR) e Modelo de Requisitos e componentes técnicos (MRCT). O desenvolvimento do modelo organizacional utilizando o método EKD proporciona o gerenciamento de mudanças, captura das melhores práticas do negócio, gerenciamento das regras do negócio, gerenciamento do conhecimento organizacional. O método apresenta: um conjunto de diretrizes, que orienta todo o processo de modelagem; um conjunto de questões, que apóia o desenvolvimento de todos os modelos; e um outro conjunto de questões para apoio na verificação das ligações entre componentes de todos os modelos, depois de desenvolvidos. O método é utilizado para a especificação de requisitos.

As Tabelas 1 e 2 apresentam um estudo comparativo entre as técnicas apresentadas. É possível observar que o método EKD oferece uma forma sistemática e controlada de analisar, entender, desenvolver e documentar uma organização e seus componentes. Essa abordagem representa passos importantes para um novo paradigma de desenvolvimento de software, que nos primeiros estágios de desenvolvimento concentra-se na organização e em questões do negócio, em vez de em mecanismos de implementação de sistemas de informação. Neste sentido, a abordagem que será apresentada em mais detalhes neste trabalho é o EKD – Enterprise Knowledge Development.

3. EKD

O trabalho que originou esse método iniciou-se nos anos 1980 pelo projeto Plandata, e foi refinado pelo SISU (Swedish Institute for Systems Development – Instituto Sueco para o Desenvolvimento de Software), no final dos anos 1980. Ele foi fundado em 1984 e realizou mais de 100 projetos de análise de sistemas e negócio, no quais a metodologia de Modelagem Organizacional foi usada. A grande contribuição foi considerar componentes organizacionais de uma especificação, por exemplo, os objetivos (intenções) de um negócio, além dos tipos de componentes do modelo tradicional, como entidade, relacionamentos e processos. O uso dessa abordagem em muitas aplicações diferentes, durante os últimos dez anos, mostrou que a razão do sucesso não era apenas o Modelo Organizacional, mas também o gerenciamento apropriado do processo do negócio e engenharia de requisitos. A idéia inicial do Modelo do Negócio do SISU foi estendida para o Modelo Organizacional e, mais tarde, desenvolvida no projeto ESPRIT F3 (From Fuzzy to Formal). A Modelagem Organizacional F3 foi então elaborada pelo projeto ESPRIT ELKD e está agora sendo aplicada no projeto ESPRIT ELEKTRA (Electrical Enterprise Knowledge for Transforming Applications) (Bubenko et al., 1998). O projeto ELEKTRA concentra-se, principalmente, na aplicação do método EKD para problemas de gerenciamento de mudanças, dentro de organizações da Grécia e Suécia, gerando um conjunto de práticas genéricas de forma a aplicá-las em outras companhias. Segundo Rolland et al. (2000), a pesquisa do projeto ELEKTRA objetiva a criação de uma base de conhecimento para o gerenciamento de mudança. Um dos objetivos do projeto era: capturar as melhores práticas do negócio, para reusá-las em situações similares em outras companhias de eletricidade.

A necessidade de reengenharia e de gerenciamento de mudanças está crescendo rapidamente, tornando-se fatores chaves de sobrevivência e competitividade das companhias. Nesse caso a organização precisa desenvolver uma disciplina que organize todo o conhecimento requerido, para identificar a necessidade de mudança na organização, e para cumprir essas mudanças de maneira conveniente e profissional (Bernus e Nemes, 1997). Segundo Kirikova (2000), o EKD pode ser usado em situações diferentes e com propósitos diferentes, como nas seguintes situações:

• Na engenharia de requisitos para definição e especificação de requisitos;

• Na análise do negócio para detecção do problema;

• Na reengenharia de processos do negócio para definição de novos sistemas de negócio; e

• No gerenciamento de conhecimento organizacional ou aprendizagem organizacional, para formar a base de propagação e ampliação de conhecimento.

Para tanto, são necessárias descrições que representem e comuniquem percepções e idéias. Essas descrições são apresentadas por meio do modelo organizacional. O conhecimento da organização é estruturado por esse modelo que, sendo suficientemente detalhado e não ambíguo, torna-se uma poderosa ferramenta para o entendimento ou desenvolvimento da organização, permitindo discussão entre objetos visuais e tangíveis, que são o centro da atenção coletiva de um grupo de pessoas (Bubenko et al., 1998). Para Bubenko et al., 1998, o modelo EKD não mostrará uma exata reflexão do mundo real. Ele é apenas uma coleção de percepções do mundo real, refletindo as estruturas de referências e experiências dos colaboradores. Um modelo de boa qualidade é baseado na discussão explícita dos participantes e nos relacionamentos entre elementos de diferentes sub-modelos. Para tanto, as discussões deveriam concentrar-se na organização por diferentes pontos de vistas, envolvendo participantes com conhecimentos diferentes. O modelo fornece, de forma natural, uma possibilidade para os participantes entrarem em questões e fenômenos relacionados à sua parte do negócio, e ver o impacto de suas decisões ou requisitos em todos os processos da organização. De acordo com Pádua (2001), os modelos proporcionam benefícios para a cultura e o aprendizado organizacional. Os participantes devem explicitamente contribuir com seus conhecimentos do domínio, suas habilidades e experiências. Eles devem ser abertos, construtivos, ativamente participativos. É muito importante que eles saibam ouvir, respeitar e responder aos outros, e que tentem encontrar e esclarecer relacionamentos e aspectos escondidos. Apenas dessa forma, os efeitos de sinergia do grupo poderiam ser alcançados. O desenvolvimento do conhecimento organizacional é extremamente dependente dos participantes e não dos facilitadores. Facilitador é a pessoa que lidera e adverte, durante as sessões de modelagem, e apóia cada um na aquisição de conhecimento e de idéias do grupo de aplicação.

De acordo com Bubenko et al. (1998), o conteúdo básico da estrutura EKD inclui: um conjunto de técnicas de descrição, a participação de stakeholders e um conjunto de diretrizes para o trabalho. O termo stakeholder foi introduzido para nomear a todos os envolvidos no projeto, diretamente ou indiretamente, ou que tenha interesse no resultado do projeto. O conjunto de técnicas de descrições fornece um conjunto de modelos, que é usado para descrever o sistema a ser analisado ou construído e a organização na qual ele será operado. Esse conjunto de técnicas é usado pelos desenvolvedores do sistema. As técnicas de descrições envolvem atuais clientes, usuários finais, gerentes, proprietários, entre outros interessados. A abordagem EKD envolve tipicamente estrategistas, gerentes táticos e funcionários do nível operacional, que juntamente com o facilitador e técnicos, familiarizados com EKD iniciam o processo de:

1. Diagnóstico. Modelar a situação corrente e os requisitos de mudanças;

2. Entendimento. Interpretar, entender, raciocinar, deliberar e discutir o estado corrente e futuro da empresa; e

3. Projeto. Discutir e modelar as situações alternativas futuras e os cenários.

O modelo resultante estará disponível para os tomadores de decisões atuarem sobre as estratégias futuras, as táticas e os objetivos da empresa. O Modelo Organizacional contém vários sub-modelos inter-relacionados. Cada um representa algum aspecto da organização. De acordo com Bubenko et al. (1998), os tipos de sub-modelos (Figura 1) e as questões que eles abordam são:

1. Modelo de Objetivos (MO). Concentrado na descrição de idéias da organização. Descreve o que a organização e os empregados querem alcançar ou evitar, e quando. Usualmente esclarece questões como:

• Para onde deveria ser movida a organização;

• Quais os objetivos mais importantes e as prioridades desses objetivos; e

• Como cada objetivo é relacionado aos outros e quais problemas dificultam a realização das metas.

2. Modelo de Regras do Negócio (MRN). Usado para definir e manter explicitamente regras do negócio formuladas e consistentes com o Modelo de Objetivos. Regras do Negócio podem ser vistas como operacionalização ou como limites dos objetivos. O Modelo de Regras do Negócio geralmente esclarece questões como:

• Quais regras afetam os objetivos da organização;

• Quais são as políticas declaradas;

• Como cada regra do negócio é relacionada com os objetivos; e

• Como os objetivos serão apoiados pelas regras.

3. Modelo de Conceitos (MC). Usado estritamente para definir "coisas" e "fenômenos" relacionados a outros modelos. Representa entidades organizacionais, atributos e relacionamentos. Entidades são usadas para definir mais estritamente expressões do Modelo de Objetivos, tanto quanto o conteúdo do conjunto de informação do Modelo de Processos do Negócio. O Modelo de Conceitos usualmente esclarece questões como:

• Quais entidades ou conceitos são reconhecidos na organização (incluindo seus relacionamentos com objetivos, atividades e processos, e atores);

• Como as entidades são definidas; e

• Quais regras do negócio e restrições monitoram esses objetos e conceitos.

4. Modelo de Processos do Negócio (MPN). Usado para definir processos organizacionais, e a forma pela qual eles interagem e manuseiam a informação e os materiais. Um processo de negócio deve consumir as entradas (informação e/ou material) e produzir uma saída (informação e/ou material). Em geral o MPN é similar aos tradicionais modelos de diagramas de fluxo de dados (DFD). O Modelo de Processos do Negócio esclarece questões como:

• Quais atividades e processos do negócio são reconhecidos na organização (ou deveriam ser), para gerenciar a organização em concordância com as metas; e

• Como os processos de negócio e tarefas deveriam ser realizados (workflows, transição de estado, ou modelo de processos), e quais as informações necessárias.

5. Modelo de Atores e Recursos (MAR). Usado para descrever como diferentes atores e recursos se relacionam, e como eles são relacionados a componentes do Modelo de Objetivos e a componentes do Modelo do Processo do Negócio. Por exemplo: um ator pode ser responsável por um particular processo no MPN ou um ator pode buscar um particular objetivo no MO. O Modelo de Atores e Recursos normalmente esclarece questões como:

• Quem está ou deveria estar realizando quais processos e tarefas; e

• Como estão as estruturas de informação e de responsabilidade entre os atores definidos.

6. Modelo de Requisitos e Componentes Técnicos (MRCT). Usado quando a proposta do EKD é ajudar a definir os requisitos para o desenvolvimento de um sistema de informação. Esse modelo direciona para o sistema técnico que é necessário para apoiar os objetivos, processos e atores da organização. Inicialmente, é necessário desenvolver um conjunto de requisitos de alto nível ou objetivos para o sistema de informação como um todo. Baseado nesses requisitos, o sistema de informação é estruturado em um número de subsistemas, ou componentes técnicos. O MCRT é uma tentativa inicial de se definir toda a estrutura e propriedades do sistema de informação, para apoiar as atividades do negócio, como definido no MPN. O Modelo de Requisitos Componentes Técnicos usualmente esclarece questões como:

• Quais requisitos são gerados pelos processos do negócio; e

• Qual o potencial da tecnologia da informação para melhoria do processo.

De acordo com Pádua (2001), cada um desses sub-modelos, inclui um número de componentes que descrevem diferentes aspectos da organização. Por exemplo, o Modelo de Objetivos contém objetivos do negócio, problemas do negócio que são divididos em tratamento, fraquezas, causas, oportunidades do negócio e restrições. Os componentes dos sub-modelos são relacionados entre si (relacionamento intra-modelo), e, também, com componentes de outros sub-modelos (relacionamento inter-modelos).

A habilidade de traçar decisões, componentes e outros aspectos em todas as partes da organização é dependente do uso e do entendimento desses relacionamentos. Quando se desenvolve um modelo organizacional completo, esses relacionamentos entre componentes de diferentes sub-modelos executam tarefa essencial. Por exemplo, declarações do modelo de objetivos permitem que diferentes conceitos sejam definidos no Modelo de Conceitos. Da mesma forma, objetivos do Modelo de Objetivos motivam processos particulares no Modelo de Processos do Negócio. Os processos são necessários para atingir os objetivos declarados. Uma ligação (link) é definida entre um objetivo e um processo. Ligações entre modelos tornam o modelo transparente, mostrando por que certos processos e requisitos do sistema de informação têm sido introduzidos.

De acordo com Bubenko et al. (1998), existem limitações na forma em que os sub-modelos e seus relacionamentos podem ser povoados. Esses são controlados por um número de regras de consistência estáticas e dinâmicas que, por sua vez, controlam seus estados de transição permissíveis. Os relacionamentos entre modelos são importantes por possibilitarem a análise e comparação dos elementos organizacionais.

Os componentes do modelo organizacional têm representações gráficas, como, por exemplo, caixas retangulares, elipses, e outras formas. O relacionamento entre esses componentes é representado com ligações (links). Existem dois textos associados a cada componente: short name e long name. O short name é usado para numerar e identificar os componentes do modelo, deve ser único, para servir de referência. O long name é usado para expressar e armazenar a descrição do componente.

Na abordagem EKD, existe o cuidado de relacionar os componentes do Modelo de Objetivos por meio de ligações semânticas monodirecionais, das quais os principais tipos são:

• Apoio: usado para refinar ou decompor objetivos e outros componentes;

• Impedimento: usado para mostrar influências negativas entre componentes do Modelo de Objetivos; e

• Conflito: usado para definir situações em que, ao atingir um objetivo, poderá haver um conflito com outro objetivo.

4. Refinamento e operacionalização dos objetivos

A proposta de operacionalização de objetivos é detalhar como o alto nível de objetivos pode ser satisfeito. A operacionalização do Modelo de Objetivos encoraja o desenvolvimento da rede de objetivos. As principais atividades da operacionalização são o refinamento dos objetivos e o gerenciamento de conflitos. Durante o refinamento dos objetivos, novos objetivos são gerados por meio do detalhamento de alto nível. Nesse sentido, um objetivo de alto nível é refinado em um ou mais sub-objetivos, que podem tornar a ser refinados em novos sub-objetivos. O resultado desses refinamentos sucessivos é uma estrutura hierárquica multi-nível, iniciando-se de um objetivo de alto-nível vago, até objetivos operacionais específicos. É possível usar relacionamento AND/OR nas estruturas para refinar objetivos em muitas combinações alternativas de sub-objetivos, ou um sub-objetivo que pode ser realizado por muitas alternativas de modelo de projeto. O gerenciamento de conflitos consiste de um número de atividades:

• Detecção de conflitos: concentra-se na identificação de conflitos entre objetivos. Pode ser difícil relacionar novos objetivos com os objetivos existentes, e determinar o efeito daqueles para estes. Para conseguir encontrar conflitos, deve-se procurar exaustivamente no modelo de objetivo, e comparar o novo objetivo para cada objetivo existente. Uma forma razoável de procurar por potenciais conflitos é usar os conflitos dos objetivos de alto nível, que já foram identificados durante o estágio de aquisição; e

• Classificação de conflitos: concentra-se na identificação do tipo de conflito detectado. Conflito final ocorre quando dois objetivos contraditórios são desejados. Conflito de recursos (means) ocorre quando os atores, relacionados a objetivos idênticos, querem usar o mesmo recurso. A classificação de conflitos pode ser usada por métodos de gerenciamento de conflitos para reagir de modo devido.

Muito freqüentemente, os objetivos de alto nível, os problemas, regras do negócio, entre outros, adquiridos no estágio de aquisição, contêm um número de requisitos informais e imprecisos; é recomendado que o Modelo de Objetivos seja estruturado no estágio inicial. Essa tarefa envolve:

1. Classificação de Objetivos: classificá-los em uma tabela matriz é aconselhável para melhorar a compreensão e entendimento de inúmeros objetivos, na qual eles possam ser categorizados de acordo com origem, stakeholder, função, domínio, etc. Isso permitirá a comparação, análise e, talvez, a descoberta da necessidade de mais discussões baseadas na análise dos padrões dos objetivos;

2. Priorização de Objetivos: possibilita a resolução dos conflitos entre objetivos. Um alto nível de objetivos age como uma restrição em um objetivo de baixo nível; e

3. Correlação de Objetivos: é compreendida como interação positiva e negativa entre objetivos. Em geral, colaboração de objetivos é desejável, desde que a colaboração entre dois objetivos signifique que a satisfação de um apoiará a satisfação de outro; mostrando também um consenso entre objetivos e stakeholders. A existência de objetivos antagônicos poderia impedir a satisfação dos objetivos. Além disso, falhas para reconhecer objetivos antagônicos poderiam causar confusão no processo de projeto. Uma abordagem sistemática tem a função de revelar correlações de objetivos, usando matrizes para assegurar que todas as interações possíveis sejam descobertas e que os diagramas tornem claro o padrão dos relacionamentos.

5. Relacionamento entre os modelos

Bubenko et al. (1998), explicam que no desenvolvimento de um modelo organizacional completo, as ligações entre os componentes de diferentes sub-modelos executam tarefa essencial. Por exemplo, declarações no Modelo de Objetivos possibilitam que conceitos diferentes sejam definidos mais claramente no Modelo de Conceitos, no qual uma ligação é especificada entre o componente correspondente no Modelo de Objetivos e o conceito no Modelo de Conceitos. Da mesma forma, objetivos no Modelo de Objetivos motivam processos particulares no Modelo de Processos do Negócio. Os processos são necessários para alcançar os objetivos declarados. Assim, a ligação é definida entre o objetivo e o processo que deverá ser realizado para cumpri-lo. Ligações entre modelos tornam o conhecimento mais disponível, sendo possível ver por que certos processos e requisitos do sistema de informação têm que ser introduzidos. As ligações entre os sub-modelos do Modelo Organizacional são explicadas a seguir (Figura 1):

• Ligações entre o Modelo de Objetivos e o Modelo de Atores e Recursos podem motivar ou requerer a introdução de novos atores particulares, como Agentes de Relações de Clientes (motivado pelo objetivo de melhorar relacionamentos com clientes). Podem, também, descrever quais componentes do Modelo de Atores e Recursos são responsáveis por alcançar um particular objetivo ou defini-lo;

• Ligações entre o Modelo de Atores e Recursos e o Modelo de Regras do Negócio descrevem como componentes diferentes do Modelo de Atores e Recursos são relacionados a Regras do Negócio do Modelo de Processos de Negócio. Exemplos de nomes de ligações: define, é responsável por;

• Ligações entre o Modelo de Objetivos e o Modelo de Conceitos são usadas para descrever componentes do Modelo de Objetivos, que referenciam entidades do Modelo de Conceitos. Por exemplo, o objetivo: "Melhorar a satisfação do cliente" deveria referenciar o conceito "Cliente" no Modelo de Conceitos;

• Ligações entre o Modelo de Objetivos e o Modelo de Processos de Negócio, tipicamente, relacionam objetivos do Modelo de Objetivos a processos do Modelo de Processos de Negócios com o relacionamento "motiva". Exemplo: "Melhorar a satisfação do cliente" poderia, inicialmente, motivar um particular processo de alto nível da organização como "Monitoramento das Relações com Cliente";

• Ligações entre o Modelo de Objetivos e o Modelo de Regras do Negócio descrevem como componentes diferentes do Modelo de Objetivos são implementados, em termos de regras do negócio no Modelo de Regras do Negócio. Por exemplo, o objetivo "Registrar Maus Clientes" declarado no Modelo de Objetivos requer uma regra do negócio no Modelo de Regras do Negócio, que declara como, exatamente, isso deve ser distinguido, como "Cliente é considerado mau cliente se demorar mais do que quatro semanas para efetuar pagamento";

• Ligações entre o Modelo de Regras do Negócio e o Modelo de Processos de Negócio descrevem como processos do Modelo de Processos de Negócio são disparados pelas regras do negócio do Modelo de Regras do Negócio. Por exemplo, se existe uma regra que declara "Clientes são registrados como maus clientes se demorarem mais do que quatro semanas para efetuar pagamento", então essa regra dispara o processo que realiza o registro de maus clientes;

• Ligações entre o Modelo de Processos de Negócio e o Modelo de Conceito estão entre o conjunto de informação do Modelo de Processos do Negócio e os componentes do Modelo de Conceitos. Por exemplo, o Conjunto de Informação "vôo esperado" deve referir-se a entidades incluindo atributos e relacionamentos como Vôo, Linha Área, Piloto e dados temporais sobre chegadas; e

• Ligações entre o Modelo de Requisitos e Componentes Técnicos e outros componentes do modelo podem ser mais complexas do que os relacionamentos binários normais. O Modelo de Processos do Negócio motiva os objetivos do sistema de informação e os requisitos do sistema de informação. Declarações binárias podem ser simples, como "O Sistema de Catálogo da Biblioteca deve ser capaz de manusear X pedidos simultaneamente", mas podem também ser mais complexas, como "O tempo de resposta para o usuário do tipo X, quando estiver realizando o processo P, na data definida como C, deve ser menor do que Z segundos".

Os componentes do Modelo podem ser ligados de muitas formas. As ligações que devem ser estabelecidas dependem do propósito de cada projeto EKD em particular. Cada Modelo Organizacional tem um propósito e um foco que as ligações de cada modelo devem refletir. Toda ligação representa uma declaração feita sobre a organização e, possivelmente, seus requisitos do sistema de informação. A semântica de todas ligações deve ser analisada cuidadosamente. Existe um conjunto mínimo de ligações, que deveria ser definido pela representação para ser considerado completo.

6. Aplicações

Segundo Bubenko et al. (1998), a abordagem EKD está longe de ser constituída apenas do produto o Modelo Organizacional e seus sub-modelos. O sucesso da aplicação do EKD depende inteiramente da forma pela qual é introduzido na organização e na forma pela qual o processo de desenvolvimento é conduzido. No trabalho de Bubenko et al. (1998), são apresentadas algumas diretrizes para introduzir e usar a abordagem EKD. Mesmo essa abordagem e seus predecessores tendo sido aplicados por muitos anos, muito conhecimento novo é ainda observado e desenvolvido, a partir da aplicação do EKD. Essas diretrizes devem ser consideradas como conhecimento em constante evolução e extensão. Um grande número de experiências em Modelagem Organizacional (ou Modelagem de Negócio) tem sido feito na Suécia com os seguintes resultados:

• Descrições claras e com rigor adicional;

• Evolução na aprendizagem organizacional; e

• Aceitabilidade na realização de mudanças e no processo de reengenharia na organização.

Bubenko et al. (1998) apresentaram um conjunto de pré-condições para organizar a aplicação de um projeto EKD:

1. Passar uma missão clara para todo o grupo de modelagem;

2. Alocar tempo e recursos suficientes para a atividade;

3. A composição do grupo de modelagem deve ser baseada na idéia de que o grupo, coletivamente, tenha conhecimento em todos os campos necessários tais como: estratégias de negócio, objetivos, computação, software, sistema de informação, gerenciamento, questões operacionais, entre outras;

4. O grupo de modelagem deve ter autoridade para re-projetar a organização;

5. Designar responsabilidades considerando a documentação, uso e manutenção do Modelo Organizacional a ser desenvolvido; e

6. Planejar atividade de modelagem considerando:

• as questões a serem discutidas;

• os participantes envolvidos;

• a alocação de tarefa;

• os participantes sendo alocados em tempo;

• as expectativas para serem completadas;

• o treinamento oferecido aos participantes no uso da Modelagem Organizacional, antes do início da sessão de modelagem; e

• a participação de um facilitador experiente.

O gerente e os participantes do processo de modelagem devem entender completamente e concordar com todos os aspectos do projeto. O propósito, objetivos e escopo do projeto devem ser documentados. A alocação de recursos (pessoal, responsabilidade, tempo, dinheiro, recursos computacionais) deve ser determinada. A garantia de qualidade em termos de resultados e validação deve ser mantida e registrada.

Foi observado por Bubenko et al. (1998), que a abordagem é difícil de explicar, e que existe um risco de levar a crenças em mudanças mágicas na organização, ou seja, acreditar que a abordagem, automaticamente, ajudará a resolver todos os problemas da organização. Existe a necessidade de muita disciplina, para mover-se da fase inicial até versões de modelos melhorados, usando ferramentas computacionais.

Em Nurcan (1999), são relatados os benefícios da aplicação do EKD na ECOM – European Electricity Company – a qual deveria se organizar de acordo com as regras da União Européia (UE) que liberou concorrências entre as empresas. Assim não existiria o monopólio e a ECOM deveria se adequar para entrar no mercado competidor. Os benefícios para companhia ECOM por ter usado a abordagem EKD foram os seguintes:

• A aplicação da abordagem é uma procura sistemática e conduzida de maneiras alternativas para atingir o objetivo de mudança, tanto no caso de melhoramento ou extensão do objetivo existente quanto na introdução de um novo objetivo, ajudando também os stakeholders a apresentarem soluções inovadoras;

• Por causa de a abordagem de desenvolvimento de objetivos usar como entrada o modelo de objetivo, os stakeholders foram capazes de apontar os impactos da mudança que eles estavam propondo nos processos existentes; e

• Os stakeholders foram capazes de realizar uma avaliação do cenário de alternativas de mudanças, para selecionar a mais apropriada.

As versões mais antigas do EKD já foram aplicadas em algumas organizações como British Aerospace (Reino Unido), TELIA (Suécia), ERICSSON (Suécia), CESELSA (Espanha), Sweden Post (Suécia). Nessas organizações, o método aplicado incluía: melhoramento de processos de negócio, planejamento de estratégia de negócio, definição de requisitos do sistema. Em ELEKTRA (2000), estão disponíveis grandes projetos que, sistematicamente, utilizaram a metodologia EKD, e comprovaram grandes mudanças nas estruturas organizacionais e melhorias nos processos de negócio. Os resultados desses projetos são extensivamente apresentados em ELEKTRA (2000).

O projeto ELEKTRA produziu uma base de conhecimento que contém modelos (padrões) de gerenciamento de mudança para o setor de eletricidade. O objetivo desses modelos é fornecer soluções nas áreas de Distribuição de Eletricidade e Gerenciamento de Recursos Humanos. Esse modelo consiste de uma linguagem para descrever o conhecimento embutido nos modelos, um método para descobrir as práticas e soluções potenciais e sua generalização de forma que eles possam ser aplicados em mais de uma organização. Em Rolland et al. (2000), avaliou-se esse modelo, criado pelos mesmos autores para capturar as melhores práticas do gerenciamento de mudança da abordagem EKD, e as mais importantes conclusões foram:

• Alto nível de abstração deve ser evitado, enquanto é descrita a solução para o problema organizacional. Os avaliadores, freqüentemente, expressaram que o nível de abstração era inapropriado para o tipo de problema a ser resolvido e, na maioria das vezes, o nível de abstração era muito alto;

• Os modelos em grupo são mais fáceis de entender do que os isolados porque apresentam soluções mais completas. Assim, os usuários podem entender mais rapidamente a idéia global de como as soluções propostas podem ser aplicadas naquelas situações;

• Os modelos devem descrever soluções concretas em vez de diretrizes e sugestões de como "agarrar" o problema em geral. As soluções propostas devem ser ilustradas pelas melhores práticas e ter referência para casos similares na vida real; e

• Os modelos devem descrever soluções alternativas com diretrizes para escolha de uma solução apropriada, dependendo de uma situação particular da organização. Os avaliadores confirmaram que a base de conhecimento de uma determinada área é um parâmetro importante para resolver problemas no mesmo contexto.

De acordo com Bubenko et al. (1998), a modelagem realizada em grupo tem vantagens e desvantagens. As vantagens são as idéias criativas ressaltadas pelo número de pessoas que aumentam o conhecimento e as competências do grupo. As soluções são caracterizadas pelo consenso e são mais próximas à realidade quando "pessoas-chave" participam. Existe um bom balanço entre criatividade e crítica. As desvantagens são tensões sociais que impedem a cooperação: as pessoas presentes, que têm prestígio político dentro da organização, podem intimidar ou influenciar a participação de outras pessoas, desencorajando o pensamento inovador. Isso também ocorre se houver diferenças substanciais na posição e temperamento dos membros. O trabalho pode ser descoordenado, se finalizado por vários indivíduos ou se algumas pessoas abdicarem de suas tarefas e responsabilidades.

7. Conclusões

A Modelagem Organizacional foi apresentada neste trabalho como uma forma de capturar requisitos organizacionais para melhorar a compreensão do domínio, interagir com usuários, para que eles entendam o que o sistema pode fazer para melhorar o negócio, e adquirir conhecimento da estrutura organizacional e estratégica.

A abordagem EKD propõe modelar o conhecimento organizacional para entender, analisar, melhorar e ajustar sistemas. Os componentes são modelos que examinam a organização de um número de perspectivas inter-relacionadas. Esses modelos irão coletivamente constituir o Modelo Organizacional. Dessa forma, contribui para um desenvolvimento do sistema de informação da mesma forma inter-relacionadas.

O EKD direciona para a construção de modelos diferentes, representando o estado inicial da organização e o estado futuro, além da expressão das estratégias alternativas para mudanças, a avaliação dessas estratégias possibilitando um sistema de informação passível de manutenção e melhorias acompanhando as mudanças da organização.

A metodologia prevê o gerenciamento de conflito por meio de duas questões chaves: conhecimento da trajetória do conflito e gravação das informações sobre esses conflitos, tal como as circunstâncias que levam a esses conflitos. Muito freqüentemente, os objetivos de alto nível, os problemas, as regras do negócio, entre outros, adquiridos no estágio de aquisição, contêm um número de requisitos informais e imprecisos. É recomendado que o Modelo de Objetivos seja estruturado no estágio inicial. Para tanto, neste trabalho, foi apresentado que é necessário realizar a classificação, priorização e correlação de objetivos. Na classificação dos objetivos é desenvolvida uma tabela matriz, na qual eles possam ser categorizados de acordo com origem, stakeholder, função, domínio, etc. Isso permitirá a comparação, a análise e, talvez, a descoberta da necessidade de mais discussões baseadas na análise dos padrões dos objetivos. A correlação de objetivos é compreendida como interação positiva e negativa entre objetivos, sendo também desenvolvida uma tabela matriz, assegurando que todas as interações possíveis seriam descobertas antes da implementação do sistema de informação.

A aplicação do EKD, de acordo com o estudo apresentado, proporciona uma oportunidade para os participantes entrarem em questões e fenômenos, que são relacionados com sua parte do negócio, podendo então ver o impacto de suas decisões ou os requisitos de todos os processos da organização. O EKD auxilia os desenvolvedores de sistemas de informação e stakeholders na determinação dos requisitos e objetivos do sistema.

Os modelos proporcionam benefícios para a cultura e o aprendizado organizacional. Os participantes devem, explicitamente, contribuir com seus conhecimentos do domínio, suas habilidades e experiências. Eles devem ser abertos, construtivos e ativamente participativos. O desenvolvimento do conhecimento organizacional é extremamente dependente dos participantes. Dessa forma auxilia na internalização de um novo sistema de informação.

Existe um relacionamento natural e lógico entre o negócio e os requisitos do sistema, sendo assim, o modelo organizacional é parte importante do desenvolvimento de software para captura e especificação dos requisitos, nos quais a determinação explícita dos objetivos, problemas, conceitos, atividades, processos e atores direciona para um sistema que atende às reais necessidades do cliente, além de diminuir custos de manutenção.

8. Agradecimentos

Os autores desse trabalho agradecem especialmente à CAPES.

Recebido em 30/10/2003

Aceito em 12/5/2004

• ALENCAR, F. M. R. Mapeando a Modelagem Organizacional em especificações precisas 1999. p. 304 Tese (Doutorado) - Centro de Informática, Universidade Federal de Pernambuco, Recife, 1999.
• BERNUS, P.; NEMES, L. Requirements of the generic enterprise reference architecture and methodology. Annual Reviews in Control, v. 21, p. 125-136, 1997.
• BERZTISS, A.T.; BUBENKO JR., J.A. A Software process model for business reengineering. In: INFORMATIONS SYSTEMS DEVELOPMENT FOR DECENTRALIZED ORGANIZATIONS/IFIP WORKING CONFERENCE, 1995, Trondheim. Proceedings... Norway: Chapman & Hall, 1995.
• BUBENKO JR., J.A.; WANGLER, B. Objectives driven capture of business rules and information systems requirements. In: INTERNATIONAL CONFERENCE ON SYSTEMS, MAN AND CYBERNETICS, Le Touquet. Proceedings... [S.l.:s.n.], 1993. p. 670-677.
• BUBENKO JR., J.A. Extending the scope of infomation modelling. In: INTERNATIONAL WORKSHOP ON THE DEDUCTIVE APPROACH TO INFORMATION SYSTEMS AND DATABASE, 4., Lloret-Costa Brava. Proceedings... Barcelona: Departament de Llenguatges i Sistemes Informatics of the Universitat Politecnica de Catalunya, 1993. p. 73-98.
• BUBENKO JR., J.A.; KIRIKOVA, M. Enterprise modelling: improving the quality of requirements specification. In: IRIS-17 INFORMATION SYSTEMS RESEARCH SEMINAR IN SCANDINAVA, Oulu. Proceedings... [S.l.:s.n.], 1994.
• BUBENKO JR.; J.A.; STIRNA, J.; BRASH, D. EKD user guide, Dpt of computer and systems sciences Stockholm: Royal Institute of Technology, 1999.
• DALLAVALLE, S.I.; CAZARINI E.W. Regras do negócio: fator chave de sucesso no processo de desenvolvimento de sistemas de informação. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO, 20., 2000, São Paulo. Anais... São Paulo: [s.n.], 2000. 1 CD-ROM.
• DOBSON, J.E.; STREMS, R. Organizational requirements definition for information technology. In: IEEE INTERNATIONAL CONFERENCE ON REQUERIMENTS ENGINEERING, Los Alamitos. Proceedings... Los Alamitos: IEEE Computer Society, 1994. p. 158-165.
• ELECTRICAL ENTERPRISE KNOWLEDGE FOR TRANSFORMING APPLICATIONS. The ELEKTRA project programme Disponível em: <http://www.singular.gr/elektra.ekd.htm>. Acesso em: 27 Nov. 2000.
• FURLAN, J.D. Modelagem de negócio - uma abordagem integrada de modelagem estratégica funcional, de dados e a orientação a objetos São Paulo: Makron Books, 1997.
• GOTTESDIENER, E. Capturing business rules. Software Developement, v. 7, n. 12, p. 72-76, Dec. 1999.
• HERBST, H. Business rules in system analysis: a meta-model and repository system. Information Systems, v. 21, n. 2, p. 147-166, 1996.
• KILOV, H.; SIMMONDS, I. Business rules: from business specification to design. In: BOSCH, J.; MITCHELL, S. Object oriented technology Berlin: Springer, 1997. (Lectures Notes in Computer Sciences, 1357).
• KIRIKOVA, M. Explanatory capability of enterprise models. Data & Knowledge Engineering, v. n.33, p. 119-136, 2000.
• LEITE, J. C. S. P.; LEONARDI, M. C. Business rules as organizational policies. In: INTERNATIONAL WORKSHOP ON SOFTWARE SPECIFICATION & DESIGN, 9., Japan. Proceedings... Los Almitos, IEEE CSP, 1998. p. 68-76.
• NURCAN, S. Analysis and design of co-operative work process a framework. Information and Software Technology, v. 40, n. 3, p. 143-156, Jun. 1998.
• PÁDUA, S.I.D. Investigação do processo de desenvolvimento de software a partir da Modelagem Organizacional, enfatizando regras do negócio 2001. p. 145 Dissertação (Mestrado) Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos.
• ROLLAND, C.; NURCAN, S.; GROSZ, G. A Decision making pattern for guiding the enterprise knowledge development process. Journal of Information and Software Technology, v. 42, p. 313-331, 2000.
• ROSCA, D. et al. A Decision making methodology in support of business rules lifecycle. In: IEEE INTERNATIONAL SYMPOSIUM ON REQUERIMENTS ENGINEERING, Annapolis. Proceedings... Los Alamitos: IEEE Computer Society, 1997. p. 236 -246.
• STERGIOU, M.; JOHNSON, L. The Importance of business rules in the organizational transformation process. In: INTERNATIONAL CONFERENCE ON INFORMATION SYSTEMS, ANALYSIS AND SYNTHESIS, 4., 1998, Orlando. Proceedings.. Orlando: International Institute of Informatics and Systemics, 1998.
• YU, E. Modelling organizations for informations systems requirements engineering. In: IEEE INTERNATIONAL SYMPOSIUM ON REQUERIMENTS ENGINEERING, 1993, San Diego. Proceedings.. Los Alamitos: IEEE Computer Society, 1993. p. 34-41.

Datas de Publicação

• Publicação nesta coleção
  08 Nov 2004
• Data do Fascículo
  Ago 2004

Histórico

• Aceito
  12 Maio 2004
• Recebido
  30 Out 2003