Relacionando requisitos de software e competências de

recursos humanos através de modelos organizacionais

Henrique Prado Sousa1, Eduardo Kinder Almentero1,

Julio Cesar Sampaio do Prado Leite2

1Departamento de Computação

Universidade Federal Rural do Rio de Janeiro (UFRRJ)

Seropédica, RJ, Brasil

Departamento de Informática

Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)

Rio de Janeiro, RJ, Brasil

hps.infotec@gmail.com, almentero@ufrrj.br, www.inf.puc-rio.br/~julio

Abstract. Business process models can be used as input for eliciting software

requirements. One of the motivations for using these models is the search for

alignment between IT and the organization, considering that they more faithfully

represent the flow of tasks and information in an organization. However, business

process models are insufficient in representing the complex organizational envi-

ronment. Organizational modeling can integrate elements from different areas in

order to enable deeper analysis of the interaction of modeled concepts aiming,

for example, to favor organizational alignment. The GPI (Goal, Process, Indica-

tors) language has been developed in this sense, adding specific Human Re-

sources domain concepts to allow modeling and evaluation of its alignment. The

objective of this paper is to analyze the potential of this information present in

organizational models as an input for requirements elicitation. To do this we map

human competency information with potential software requirements extracted

from organizational models. The relationships between human competencies and

software requirements prove to be relevant and useful to assist in organizational

decision making involving software projects.

Keywords: Software Requirements, Competencies, Human Resources, Organi-

zational Modeling, Business Processes.

1 Introdução

As competências presentes em uma organização representam o seu potencial de reali-

zação, o qual pode possibilitar o alcance de seus objetivos. A gestão de competências

normalmente é um papel da área de Recursos Humanos (RH), que busca administrá-las

2

de forma alinhada aos objetivos estratégicos, ampliando a capacidade de sucesso e so-

brevivência, especialmente em ambientes competitivos [13].

É compreensível que, fundamentalmente, a área de RH vislumbre o conceito de com-

petências partindo dos indivíduos que compõem o capital humano organizacional. De

fato, as pessoas desempenham papéis fundamentais na organização, especialmente, pa-

péis decisórios e tarefas sensíveis, as quais demandam competências específicas que

auxiliam a obtenção de resultados satisfatórios.

No entanto, os processos organizacionais vêm sido enriquecidos com tecnologia há

décadas, impelindo a reengenharias de processos com mudanças profundas, em espe-

cial, com a absorção de responsabilidades por parte de softwares, o que altera a estrutura

de competências da organização [11].

Além de transformar a forma de trabalho de áreas consolidadas como a de RH, a

área de TI obtém seu papel estratégico na organização, sendo corresponsável pela ad-

ministração de competências organizacionais que são entregues a partir da estrutura

tecnológica, em especial os softwares [5], [18].

Com o avanço tecnológico nos processos organizacionais, algumas competências

tendem a ser compartilhadas e/ou absorvidas por softwares, entretanto, a inserção de

elementos tecnológicos pode desdobrar em novas demandas de competências para os

recursos humanos, os quais atuarão em conjunto com a tecnologia.

Em meio às transformações constantes, estão os riscos inerentes, os quais podem ser

reduzidos a partir de mecanismos teóricos que auxiliem a projetar mudanças com me-

nor risco possível. Um dos maiores desafios das organizações é manter o alinhamento

de sua estrutura em determinado grau de sinergia para obter o máximo desempenho. O

maior desafio consiste em manter diferentes áreas atuando em conjunto de forma har-

mônica, o que sobressalta a importância do contexto social, da comunicação e da atua-

ção de papéis estratégicos ao alinhamento.

Há de se observar tanto o alinhamento de cada parte, como o alinhamento do con-

junto, especialmente em favor dos objetivos organizacionais. Neste interim, delinear as

competências necessárias para satisfazer as demandas organizacionais é uma tarefa im-

portante. Para auxiliar o profissional no estudo e avaliação do complexo domínio orga-

nizacional, a modelagem é de suma importância, pois auxilia não somente no registro

e organização de informações, mas servem de instrumento de entendimento do domí-

nio, na análise de cenários, definição de estratégias, e auxílio em decisões. Portanto,

podem ser utilizados como insumo em projetos com diferentes finalidades, incluindo

projetos de software.

Diversas propostas de linguagens para modelagem organizacional foram desenvol-

vidas (ex. [1], [2], [9], [12], [15], [20]), entretanto, não exploram conceitos específicos

provenientes dos diferentes domínios organizacionais, como os utilizados neste traba-

lho, provenientes do domínio de RH. Comumente, a modelagem organizacional repre-

senta os recursos humanos como “atores” os quais são responsáveis por tarefas e obje-

tivos. No entanto, o contexto de RH é mais complexo, pois envolve atributos do indi-

víduo que são capazes de afetar os resultados de um processo, o que as torna, por con-

sequência, informações relevantes no contexto estratégico.

A não inclusão de informações deste domínio implica na ausência de notação para a

sua modelagem, o que consequentemente gera a impossibilidade de relacionamento

3

com os outros elementos do modelo. Isso impede a correlação destas informações com

outras que são relevantes na elicitação de requisitos de software.

O objetivo deste artigo é realizar uma análise do potencial de uso das informações

sobre competências de recursos humanos presentes em modelos organizacionais como

insumo para a engenharia de requisitos. Para isso, utilizaremos um exemplo para evi-

denciar as interseções de competências humanas e requisitos de software. Posterior-

mente avaliamos os benefícios dessas informações visando a automatização de tarefas

e apoio computacional.

O presente artigo está dividido nas seguintes seções: a seção 2 descreve resumi-

damente a teoria de competências e apresenta como a linguagem GPI-RH permite a

modelagem de competências através de um padrão de modelagem; a seção 3, apresenta

os modelos utilizados neste trabalho como insumo para a definição de requisitos e pos-

terior cruzamento com as informações de competências. As informações são apresen-

tadas em tabelas que auxiliam a visualização da correlação dos dados, seguida de uma

discussão dos resultados; na seção 4 são apresentadas as conclusões e trabalhos futuros.

2 A modelagem de competências em modelos organizacionais

Os recursos humanos estão presentes em todos os níveis da hierarquia organizacional e

ocupam cargos comumente determinados por um perfil profissional o qual se julga ca-

pacitado a cumprir com as responsabilidades que lhe serão atribuídas. Esses perfis co-

mumente estão relacionados a determinados papéis pré-estabelecidos e são definidos

por um conjunto de quesitos, os quais se espera que o recurso humano possua, de tal

forma que esteja apto a desempenhar o papel organizacional.

As competências são resultados alcançados através da execução de tarefas sob de-

terminado desempenho [8]. Essas tarefas demandam um conjunto de Conhecimentos,

Habilidades e Aptidões (conhecido como CHA ou KSA, em inglês) para que possam

ser realizadas a contento. Na literatura especializada, as competências são diretamente

definidas em termos de CHA [19], embora existam outras abordagens (ex. [3], [7]).

As competências organizacionais ficam delimitadas pela capacidade de seus recur-

sos, porém, observa-se que a união de diferentes competências é capaz de gerar outras

competências. Através dos resultados do trabalho de múltiplas equipes em múltiplos

processos, a organização pode alcançar competências altamente agregadas [8] que for-

mam seu portfolio [14], habilitando-a a atuar em determinado nicho do mercado. Por-

tanto, existem competências em diferentes níveis de abstração.

Nos modelos organizacionais, os recursos humanos podem ser definidos em termos

dos elementos CHA que possuem, enquanto as tarefas organizacionais são definidas

em termos de CHA que requerem. Desta forma, pode ser modelado um perfil de deter-

minado recurso humano (definido como Perfil Real) e um perfil de requisitos para as

tarefas organizacionais (definido como Perfil Requerido). Por consequência, é possível

construir Perfis Requeridos de determinados papéis, bem como de processos, processos

abstratos, competências e até objetivos organizacionais. Este desdobramento dos mapas

de CHA permite avaliar o potencial alinhamento de recursos humanos através do cru-

zamento dos Perfis Reais e dos Perfis Requeridos [16].

4

Para representar esses elementos, utilizamos a linguagem GPI-RH1 [16] que introduz

no âmbito da modelagem organizacional, conceitos específicos do domínio de RH. A

linguagem utiliza-se de padrões do domínio, os quais são relacionados especialmente

ao alinhamento organizacional. Neste trabalho utilizamos o Padrão de Competências

[17] para modelar a relação de competência e os respectivos mapas de CHA. A Tabela

1 apresenta a notação do padrão, ilustrado na Fig. 1.

Tabela 1. – Notação para o Padrão de Competência

Conceito/Representação Definição

Representa uma qualidade que pode ser satisfeita em diferentes

níveis, dependendo da visão do avaliador.

Representa determinado conhecimento necessário para a orga-

nização ou um atributo de um recurso humano.

Representa determinada habilidade necessária para a organiza-

ção ou um atributo de um recurso humano.

Representa determinada aptidão necessária para a organização

ou um atributo de um recurso humano.

Representa uma contribuição positiva.

Representa uma relação “E”, denotando uma decomposição.

Os perfis são conceitos qualitativos que podem pertencer a determinado recurso hu-

mano ou é demandado para determinado ator, tarefa, processo ou competência, po-

dendo tomar diferentes graus baseado em suas operacionalizações. Essas operacionali-

zações são os conhecimentos, habilidades e aptidões, que mapeiam os respectivos per-

fis, sendo específicos ao determinado elemento para o qual o padrão de competência é

instanciado.

Cada operacionalização CHA pode ser definida como mandatórias ou desejáveis. As

operacionalizações mandatórias são necessárias para fazer (make) minimamente a com-

petência existir, portanto, estão ligados pelo relacionamento AND. As operacionaliza-

ções desejáveis são opcionais e contribuem positivamente para o perfil, se presente em

algum nível. Portanto, eles estão ligados por um relacionamento HELP (+). Não são

esperados relacionamentos do tipo HURT (-) em um perfil que normalmente é de ava-

liação positiva, entretanto, não há impedimentos de uso.

Ainda existem as operacionalizações que são obrigatórias ou desejadas, e que são

mensuráveis. Elas são marcadas com três barras pequenas, na parte inferior do elemento

do gráfico, e devem obrigatoriamente estar relacionadas a indicadores. As operaciona-

lizações do CHA são expressas em uma notação diferente das descritas no NFR Fra-

mework [4], para se adequar melhor ao formato utilizado na linguagem GPI-RH.

1 A ferramenta GPI pode ser acessada em http://ger.inf.puc-rio.br:8080/oryx/GPI_editor.xhtml

5

Fig. 1. – Padrão de Perfil de Competências

3 Mapeando requisitos de software e competências de recursos

humanos

Os requisitos de um software descrevem o seu comportamento, isto é, o que ele deve

fazer e como isto deve ser feito para satisfazer as necessidades dos interessados. Du-

rante a apreciação de modelos organizacionais com viés de elicitação de requisitos é

comum o enfoque nas tarefas descritas, pois estas descrevem um comportamento ope-

racional. Entretanto, as competências registradas em alguns destes modelos (no uso da

linguagem GPI-RH) também são uma importante fonte de informação, pois detalham

as características necessárias e/ou recomendadas aos atores para que os resultados se-

jam entregues de forma satisfatória. Uma vez que a automatização do processo implica

em transferir para o software a responsabilidade pela execução de parte ou de todas as

tarefas do processo, é importante garantir a implementação adequada das competências

necessárias para entrega satisfatória dos resultados. Caso contrário, é possível que o

software não apresente o comportamento necessário para atender às necessidades que

motivaram seu desenvolvimento.

Desta forma, também é possível contribuir para o alinhamento do domínio organi-

zacional de TI com o domínio de Recursos Humanos. Muitas propostas de alinhamento

da TI com a organização possuem uma visão vertical, orientada aos objetivos da orga-

nização, ou ainda, à governança interna. O alinhamento horizontal é mais complexo,

6

pois demanda esforço conjunto de diferentes perspectivas organizacionais (ex. Finan-

ças, Marketing, RH, TI) para alcançar uma sinergia organizacional.

Ademais, acreditamos que a consideração das competências no processo de Enge-

nharia de Requisitos possibilita um entendimento maior das necessidades relacionadas

às tarefas do processo organizacional analisado. Ao elucubrar as competências no con-

texto de requisitos estamos ampliando os pontos de vista da análise que é feita tradici-

onalmente. Ao invés de considerar apenas o que e como deve ser feito, estamos consi-

derando também às características necessárias aos atores do processo, para que a chance

da entrega corresponder ao esperado seja maior. Desta forma, ao automatizar o processo

através de software, considerando as competências, estamos tornando o novo ator do

processo, o software, mais apto a entregar aquilo que se espera dele.

A fim de preencher a lacuna explicitada, propomos neste trabalho uma abordagem

baseada no mapeamento de competências em requisitos, criando um rastro que deve ser

mantido ao longo do processo de Engenharia de Requisitos. Este rastro possibilita iden-

tificar se há impacto da competência nos requisitos, além de determinar este impacto.

Considerando um processo tradicional de Engenharia de Requisitos [10], posiciona-

mos a abordagem aqui proposta na etapa de elicitação requisitos (Fig. 2), assumindo

que serão utilizados como fonte de informações modelos organizacionais que permitam

a representação de competências, como o GPI-RH. Os eventuais impactos identificados

devem ser considerados para as etapas posteriores, de modelagem e análise. É impor-

tante que ressaltar que este posicionamento é apenas uma sugestão. É perfeitamente

razoável, caso a especificação de requisitos já esteja concluída, por exemplo, realizar o

mapeamento utilizando modelos de requisito.

Fig. 2. Abordagem inserida no processo de Engenharia de Requisitos (ER)

O processo de mapeamento adotado neste trabalho utiliza como insumo um modelo

organizacional contendo um processo relacionado às competências humanas (Fig. 3),

as quais são mapeadas através de um modelo padrão de perfil de competências (Fig. 4

e Fig. 5). Posteriormente identificamos requisitos através da interpretação do processo

organizacional (Tabela 2). A lista de requisitos está relacionada às tarefas de processo,

as quais demandam do recurso humano determinada configuração de CHA para serem

7

realizadas. As tarefas de um processo fomentam a relação indireta entre os requisitos

de software e o perfil de competências (Tabela 3).

O processo utilizado no exemplo é o “Requisição de Análise de Crédito”, que foi

obtido através de uma simplificação do processo descrito em [6]. O processo é ilustrado

na Fig. 3 (os conceitos representados na figura se encontram descritos em vermelho);

O modelo também possui outros conceitos mapeados, como as competências, objetivos

organizacionais, e o recurso de “agrupamento” o qual delineia o conjunto de tarefas

necessárias para implementar uma competência. A “entrega” da competência satis-

faz/contribui os objetivos relacionados.

Fig. 3. Processo de Avaliação de Proposta de Crédito

8

Neste processo, todas as tarefas são realizadas manualmente, e considera-se a possi-

bilidade de automatizá-las.

Este processo descreve um curso de tarefas usual do domínio financeiro para con-

cessão de empréstimo. O processo inicia quando uma proposta de crédito é recebida

pelo Analista de crédito. Ele verifica a existência de cadastro do cliente. Caso o cadastro

não exista, o Analista realiza o cadastro. Caso o cadastro exista e esteja desatualizado,

o Analista atualiza o cadastro. Se o cadastro existir e estiver atualizado, o Analista ve-

rifica se o cliente possui crédito suficiente para cobrir a sua solicitação. Se não houver

crédito suficiente, a proposta de crédito é cancelada, senão, o valor da proposta é aba-

tido do valor do crédito. Posteriormente o Analista calcula as taxas de contrato e juros

de acordo com o perfil do cliente, e então redige a proposta de contrato. O Gerente de

empréstimo analisa proposta de contrato visando identificar características que apon-

tem um contrato de risco em potencial. Caso o contrato seja de risco, ele é cancelado,

porém, se for possível alterá-lo de forma a torná-lo aceitável, o Gerente realiza os ajus-

tes. Se não houver riscos substanciais ele é aprovado. Ao final, o Gerente de contrato

comunica o resultado da proposta de crédito.

Através de um exercício simples de análise das tarefas do modelo, extraímos uma

lista de potenciais requisitos do software (Tabela 2). O mapeamento pode ser realizado

com requisitos em outros níveis de detalhamento. Neste exemplo, a fim de facilitar o

entendimento, utilizamos requisitos em um nível alto de abstração.

Tabela 2. – Lista de requisitos

Nº Nome Descrição

1 Calcular as taxas as-

sociadas ao contrato

O sistema deve calcular as alíquotas de impostos que incidam

sobre o contrato de crédito de acordo com a legislação vigente.

2 Calcular juros refe-

rentes ao contrato

O sistema deve calcular os juros que serão cobrados do cliente

utilizando as tabelas de juros definidas pela instituição.

3 Avaliar proposta de

contrato

O sistema deve aplicar os critérios estabelecidos pela instituição

para determinar se o contrato será aprovado ou reprovado.

4 Sugerir ajuste de

contrato

Caso o contrato seja reprovado, o sistema deve sugerir as corre-

ções necessárias.

Analisando o processo é possível identificar, por exemplo, que para executar as ta-

refas “Analisar proposta de contrato”, “Ajustar proposta de contrato” e “Cancelar con-

trato de risco” o ator “Gerente de Empréstimo” deve possuir a competência descrita

pelo perfil de competência (Fig. 4 e Fig. 5) “Avaliação de contrato de risco”. Este perfil

detalha a competência necessária decompondo-a em perfil de conhecimento, perfil de

habilidade, e perfil de aptidão. Assim, verificamos que as operacionalizações “Flexibi-

lidade”, “Perspectiva (pontos de vista)” e “Criteriosidade”, são, por exemplo, algumas

das operacionalizações obrigatórias para este perfil de competência.

9

A partir dos modelos de perfil de competência (Fig. 4 e Fig. 5) e da lista de requisitos

é possível realizar o primeiro passo do mapeamento entre competências, CHA e requi-

sitos do software. Para realizar este passo é importante observar a relação entre os re-

quisitos, as tarefas e as competências presentes no modelo organizacional. No exemplo

utilizado verificamos que o requisito “Calcular as taxas associadas ao contrato” está

relacionado a competência “Calcular as taxas associadas ao contrato” e, portanto, este

mapeamento foi realizado na Tabela 3. O mesmo raciocínio foi aplicado no requisito

“Sugerir ajuste de contrato”, o qual foi relacionado a competência “Avaliação de con-

trato de risco”.

Fig. 4. Modelo de Perfil de Competência “Definição de propostas de contrato”

O segundo passo do mapeamento consiste na avaliação das CHA afim de verificar

aquelas que estão relacionadas aos requisitos mapeados às competências. No caso do

requisito “Calcular as taxas associadas ao contrato” a operacionalização de Perfil de

Conhecimento “Legislação tributária” foi considerada desnecessária e, por isso, foi

10

removida. Por outro lado, as operacionalizações de Perfil de Conhecimento “Fórmulas

contábeis” e “Regras institucionais para definição de taxas e juros” foram consideradas

necessárias e, por isso, permaneceram no mapeamento.

Esta mesma lógica foi aplicada às operacionalizações do Perfil de Habilidade, em

que a operacionalização “Aplicação de regras de juros” foi removida, enquanto as ope-

racionalizações “Uso de fórmulas contábeis” e “Aplicação de legislação tributária” fo-

ram mantidas. Já no caso das do Perfil de aptidões, foi removida a operacionalização

“Meticulosidade”. O mesmo raciocínio foi utilizado para os demais requisitos da lista

e com isso completamos a Tabela 3.

Fig. 5. Modelo de Perfil de Competência “Avaliação de contrato de risco”

Uma vez mapeadas as relações entre os requisitos extraídos do processo e as com-

petências é possível avaliar o impacto das operacionalizações de Perfil de

11

Conhecimento, Habilidade e Aptidão. Durante a análise destes impactos, identificamos

casos similares recorrentes, que levaram a identificação de três padrões:

• Não há impacto;

• O impacto incorre na modificação de um requisito funcional ou não funcional ou

adição de um novo;

• O impacto incorre na modificação do próprio processo que está sendo automatizado.

As operacionalizações “Foco”, “Atenção”, “Honestidade” e “Raciocínio lógico” do

Perfil de Aptidão, por exemplo, que estão relacionadas com o requisito “Calcular taxas

associadas ao contrato” são absorvidas uma vez que o processo for automatizado, pois

as características intrínsecas a um sistema computacional dispensam a necessidade de

operacionalizar essas características humanas.

A operacionalização de Perfil de Aptidão “Facilidade de aprendizado”, por exemplo,

relacionada ao requisito “Calcular juros referentes ao contrato” é necessária devido a

volatidade das regras de juros da instituição financeira, a qual deve adequar-se cons-

tantemente a realidade do mercado. Uma alteração nestas regras requer um novo enten-

dimento, para que o resultado seja entregue de maneira satisfatória. Neste caso, a ope-

racionalização de Perfil de Aptidão terá impacto nos requisitos do software, uma vez

que este deve ser flexível (RNF) para acomodar eventuais mudanças nas regras de cál-

culo de juros.

Por fim temos o caso em que a relação entre Perfil de Competência e requisito tem

impacto no próprio processo que está sendo automatizado. A operacionalização de Per-

fil de aptidão “Responsabilidade”, que está relacionada ao requisito “Avaliação de con-

trato de risco”, está ligada a identificação da autoria da tomada de decisão. Neste caso,

uma vez que a tomada de decisão seja delegada ao software, o próprio processo preci-

sará ser adaptado para que a autoria possa ser atribuída a um agente humano responsá-

vel. Isto pode ser feito, por exemplo, através da inclusão de uma nova tarefa em que a

alternativa escolhida pelo software durante a tomada de decisão seja aprovada ou não

por um responsável (humano).

Tabela 3. Mapeamento entre requisitos e CHA

Competên-

cia

Requisito(s) Conhecimentos Habilidades Aptidões

Definição de

propostas de

contrato

Calcular as taxas

associadas ao con-

trato

- Fórmulas contábeis

- Regras institucionais

para definição de taxas

e juros.

- Aplicação de

regras de juros

- Uso de fórmu-

las contábeis.

- Foco

- Atenção

- Facilidade de

aprendizado

- Honestidade

- Raciocínio ló-

gico.

Definição de

propostas de

contrato

Calcular juros re-

ferentes ao con-

trato

- Legislação tributária

- Fórmulas contábeis

- Uso de fórmu-

las contábeis.

- Foco

- Atenção

- Facilidade de

aprendizado

12

- Aplicação de

legislação tribu-

tária

-Meticulosidade

- Honestidade

- Raciocínio ló-

gico.

Avaliação de

contrato de

risco

Avaliar proposta

de contrato

- Histórico de fatos

- Fatos Correlaciona-

dos

- Fatos relevantes

- Perfis de risco de

crédito

- Heurísticas de risco

de crédito

- Regras institucionais

de avaliação de risco

de crédito

- Correlação

- Análise de Al-

ternativas

- Determinação

de cenários

- Interpretação

de grafos

- Flexibilidade

- Perspectiva

(pontos de vista)

- Criteriosidade

- Responsabili-

dade

- Análise crítica

Avaliação de

contrato de

risco

Sugerir ajuste de

contrato

- Histórico de fatos

- Fatos Correlaciona-

dos

- Heurísticas de risco

de crédito

- Regras institucionais

de avaliação de risco

de crédito

- Correlação

- Perspectiva

(pontos de vista)

- Criteriosidade

- Responsabili-

dade

4 Conclusão

Neste trabalho defendemos a ideia de que relacionar as competências dos recursos hu-

manos aos requisitos extraídos de modelos organizacionais, em tempo de desenho, pos-

sibilita uma análise mais profunda e detalhada das necessidades que o software deve

atender.

Demonstramos através de um exemplo modelado na linguagem GPI a interação en-

tre informações de diferentes domínios (TI e RH), que se afetam mutuamente na inser-

ção de softwares em processos organizacionais.

Destacamos que esse estudo é importante, uma vez que a engenharia de requisitos

não se atém somente ao software, mas perpassa por todo conhecimento domínio, o qual,

no âmbito organizacional, possui vasto campo multidisciplinar. Há a necessidade de se

identificar as interfaces entre as diversas perspectivas organizacionais para que possi-

bilite a definição recursos que auxiliem sua correlação e posterior análise.

Outros trabalhos já abordaram o conceito de competências organizacionais [18] e de

características humanas [20], em modelos organizacionais, entretanto, não correlacio-

naram conceitos específicos do domínio, visando ampliar o conhecimento para contri-

buir na construção de softwares mais alinhados sob a perspectiva de RH.

O cruzamento de informações pode auxiliar em projetos de software, por exemplo,

a partir da priorização de requisitos a partir de demandas identificadas pela área de RH.

13

Essas demandas poderiam ser identificadas durante a gestão de competências, com evi-

dências de dificuldades em satisfazer determinadas tarefas de rotina, o que poderia jus-

tificar o investimento em apoio ou automatização computacional, em contrapartida a

novas contratações ou consultorias.

Este trabalho se encontra delimitado a um estudo preliminar, baseado em exemplos

simples. Entretanto, a investigação se justifica para evidenciar a relação dos conceitos

abordados a partir da modelagem organizacional e do uso dos modelos como fonte de

informação para elicitação de requisitos. Em trabalhos futuros, aprofundaremos o es-

tudo a partir de modelos organizacionais mais detalhados para melhor delimitar as re-

lações e identificar potenciais padrões. A partir disso, será possível identificar melhor

como apoiar a questão do alinhamento vertical entre a TI e o RH.

Referências

1. Amyot, D., Mussbacher, G.: URN: Towards a New Standard for the Visual Description

of Requirements. In: Proceedings of International Workshop on System Analysis and

Modeling, SAM’2002. pp.21-37, (2002).

2. Braubach, L., Pokahr, A., Jander, K., Lamersdorf, W., Burmeister, B.: Go4Flex: Goal-

oriented Process Modelling, Proc. 4th International Symposium on Intelligent Distributed

Computing, (2010).

3. Carbone, P., Brandão, H.P., Leite, J.B.D., Vilhena, R.M.P.: Gestão por competências e

gestão do conhecimento, Rio de Janeiro: Ed. Fundação Getúlio Vargas, (2005).

4. Chung, L., Nixon, B., Yu, E., Mylopoulos, J., “Non-Functional Requirements in Software

Engineering”; Kluwer Academic Publishers – Massachusetts, USA, (2000).

5. Coltman, T., Tallon, P., Sharma, R., Queiroz, M.: Strategic IT alignment: twenty-five

years, Journal of Information Technology, https://doi.org/10.1057/jit.2014.35, (2015).

6. Diirr, T., Souza, A, Azevedo, L. G., Santoro, F.: Analyze Credit Request Model, Tech-

nical Report of Applied Informatics Department – Federal University of State of Rio de

Janeiro (UNIRIO), (2010).

7. Draganidis, F.; Mentzas, G.: Competency based management: a review of systems and

approaches, Information management & computer security, 14(1), 51-64, (2006).

8. Fleury, M. T. L., Fleury, A. C. C.: Alinhando estratégia e competências, RAE-Revista de

Administração de Empresas, vol. 44, n. 1, (2004).

9. Jander, K., Braubach, L., Pokahr, A., Lamersdorf, W.: Goal-oriented Processes with

GPMN, International Journal of Artificial Intelligence Tools 20(6):1021-1041, (2011).

10. Leite, J.C.S.P., Livro Vivo: Engenharia de Requisitos. (1993).

11. Mascarenhas, A.O., Vasconcelos, F.C., Vasconcelos, I.F.G.: Impactos da tecnologia na

gestão de pessoas: um estudo de caso, Revista de Administração contemporânea 9.1,

pp.125-147, (2005).

12. OMG.: Business Process Model and Notation (BPMN), Version 2.0, (2011).

13. Penrose, E.T.: The Theory of Growth of the Firm, 1st edn, London: Basil Blackwell,

(1959).

14. Prahalad, C.K., Hamel, G.: The core competence of the corporation, Strategische un-

ternehmungsplanung—strategische unternehmungsführung. Springer, Berlin, Heidel-

berg, pp. 275-292, (2006).

14

15. Scheer, A.W., ARIS – Business Process Modeling, Berlin; Heidelberg; New York; Bar-

celona; Hong Kong; London; Milan; Paris; Singapore; Tokyo: Springer, 2000, 218 p. 3.

ed., Bibliografia: ISBN, 3-540-65835-1, (2000).

16. Sousa, H.P.S., Leite, J.C.S.P.: Toward an organizational alignment modeling language:

the Human Resource competency perspective, In: 2017 IEEE 19th Conference on Busi-

ness Informatics (CBI). Vol. 1. IEEE, (2017).

17. Sousa, H.P.S., Leite, J.C.S.P.: Requirement Patterns for Organizational Modeling, In:

2017 IEEE 25th International Requirements Engineering Conference Workshops (REW).

IEEE, (2017).

18. Stirna, J., Grabis, J., Henkel, M., Zdravkovic, J.: Capability Driven Development – An

Approach to Support Evolving Organizations, In: Sandkuhl K., Seigerroth U., Stirna J.

(eds) The Practice of Enterprise Modeling. PoEM 2012. Springer, Berlin, Heidelberg,

(2012).

19. Tripathi, K., Agrawal, M.: Competency Based Management, In Organizational. Global

Journal of Finance and Management, 6(4), 349-356, (2014).

20. Yu, E.: Modelling Strategic Relationships for Process Reengineering, Phd Thesis, Grad-

uate Department of Computer Science, University of Toronto, Toronto, Canada, (1995).