11th.

Workshop on Requirements Engineering

Uma Proposta para Avaliao de Equipes de Requisitos

Milene Serrano
PUC-Rio (Brasil)
milene@les.inf.puc-rio.br

Maurcio Serrano
PUC-Rio (Brasil)
mauserr@les.inf.puc-rio.br

Eduardo Kinder
PUC-Rio (Brasil)
ekalmentero@gmail.com

Mark Douglas
PUC-Rio (Brasil)
mark.rlk@terra.com.br

Bruno Rezende
PUC-Rio (Brasil)
brezende@inf.puc-rio.br

Abstract
Software Engineering has, as one of its main goals,
the duty of helping software managers perform their
jobs as better as possible. As such, technical
management, which embodies software engineering
expertise, is the central aspect in software
management. Managing human resources is difficult
for any production scheme, but is particular
challenging for software, a knowledge intensive
production process. This paper tackles the issue of
evaluating requirements teams. An evaluation method
is proposed to help managers better control their
teams productivity. The proposed method stands on
the shoulders of previous literature and on early
feedback from its use in two laboratory projects
conducted at PUC-Rio.

1. Introduo
A rea de gerncia de software amplamente
discutida em livros gerais [1] [2] [3] como em livros
especficos [4] [5] [6]. A maioria desses livros aborda
o tema, ressaltando as particularidades tcnicas de
gerncia no contexto de Engenharia de Software:
chamamos a isso de gerncia tcnica em contraponto a
conceitos gerais de gerncia. No escopo da gerncia
tcnica, nosso objetivo atacar uma lacuna da
literatura. Esta lacuna refere-se aos processos de
avaliao de equipes de requisitos.

Fillipe Napolitano
PUC-Rio (Brasil)
fnapolitano@inf.puc-rio.br
Danielle Loyola
PUC-Rio (Brasil)
danielle_loyola@yahoo.com.br

Julio Cesar Sampaio do Prado Leite

PUC-Rio (Brasil)
www.inf.puc-rio.br/~julio

Propomos um mtodo que possibilita a avaliao de

equipes de requisitos no contexto da gerncia de
requisitos. Entendemos a gerncia de requisitos como
aquela que responsvel pela elaborao dos requisitos
do software, diferentemente da gerncia por requisitos
que tem por objetivo gerenciar a produo de software
com base nos requisitos [7].
A literatura tem reportado estudos sobre equipes de
software [1] [8] [9] [10] [11]. Esses estudos defendem,
primeiramente, uma anlise criteriosa das escolhas
tcnicas e organizacionais comumente utilizadas pelas
equipes novatas ou experientes na soluo de
problemas. Posteriormente, com base nesse
levantamento, mtodos so propostos visando a
avaliao de diferentes equipes, e uma anlise
comparativa em relao ao desempenho de cada equipe
obtido. Contudo, esses mtodos so burocrticos e
necessitam de conhecimentos avanados por parte dos
avaliadores.
No intuito de prover uma avaliao focada em
requisitos e torn-la mais simples, propomos um
mtodo composto de trs tipos de avaliao: avaliao
tcnica, avaliao gerencial e avaliao do
comportamento de risco. Esses tipos de avaliao
ocorrem em um processo composto por cinco estgios.
O mtodo foi construdo com base na literatura [9] [10]
[11] [12] [13] [14] e refinado atravs de sua aplicao

34

11th. Workshop on Requirements Engineering

em dois projetos de laboratrio (Projeto SimulES e

Projeto Loja Carioca) conduzidos na PUC-Rio [15].
No Projeto SimulES, a equipe de requisitos elaborou
requisitos de um jogo online. No Projeto da Loja
Carioca, a equipe de requisitos lidou com um catlogo
comercial.
As Sees seguintes esto assim organizadas: Seo
2 resume a literatura na qual baseamos nosso trabalho,
a Seo 3 faz uma descrio geral do processo de
avaliao, a Seo 4 detalha os estgios base do
mtodo e a Seo 5 relata nossas concluses.

2. Reviso da Literatura
Muitas pesquisas tm proposto solues visando a
avaliao ou gerenciamento de equipes em vrios subprocessos do processo de construo de software,
como por exemplo, na especificao, na inspeo, na
implantao e em testes. Algumas dessas pesquisas so
apresentadas a seguir.
Historicamente, podemos destacar os trabalhos
apresentados em [4] [5] [6]. Em [4] feita uma anlise
da estrutura organizacional de processamento de dados
comparando-a com outras organizaes. Withington
[4] descreve essa estrutura como fortemente
dependente das metas estabelecidas aos seus membros,
dos controles, dos padres de desempenho e dos
regulamentos. Alm disso, o autor [4] destaca a
importncia das questes tcnicas (ex. capacidade
individual dos membros em operar um determinado
equipamento) e gerenciais (ex. gerentes gerais, sem
treinamento especfico, ou extremamente qualificados)
na estrutura organizacional de processamento de dados.
Em [5] apresentado um processo para gerenciamento
de planejamento, desenho, avaliao, documentao,
distribuio
e
manuteno
de
softwares.
Particularmente, interessante a descrio feita por
Gunther [5] quanto s relaes organizacionais
encontradas nas corporaes. Em [6] so apresentados
vrios conceitos comumente usados para organizar e
qualificar as equipes de desenvolvimento, tais como:
papis, responsabilidades, e conduta de cada membro
na alocao de recursos e na transferncia de
tecnologia. Alm disso, Booch [6] destaca a
importncia das pessoas e no do processo, e ainda
sugere que o bom gerenciamento dessas pessoas
determinante para o sucesso do processo.

Em [8] apresentada a utilizao do TSP (Team

Software Process) como proposta para gerenciar
equipes do nvel 2 do CMMI (Capability Maturity
Model Integration), no intuito de evitar os principais
problemas que afetam as organizaes que
desenvolvem software, tais como: defeitos, prazos e
oramentos no cumpridos e a insatisfao constante
dos clientes.
Os pesquisadores Schenk, Vitalari e Shannon Davis
[9] apresentam algumas diferenas entre Analistas de
Sistemas Novatos e Experientes baseadas em estudos
empricos realizados pelos autores. Segundo o artigo,
essas diferenas so evidentes em domnios de
conhecimento especficos, na estruturao de
problemas, no gerenciamento do processo, no uso de
estratgias e na definio das metas a serem atingidas.
Normalmente, os analistas novatos verbalizam menos
em termos de metas, hipteses e estruturao. O
contrrio ocorre com os analistas mais experientes.
Entretanto, essas diferenas no implicam em
resultados menos satisfatrios para os novatos. Muitas
vezes, como apresentado pelos autores em [9], bons
resultados so oriundos de estratgias inovadoras,
idealizadas e aplicadas por analistas novatos.
O trabalho apresentado em [10] prope o
conhecimento como base para especialistas na anlise
de sistemas. O estudo emprico realizado por Vitalari
[10] fez uso de anlise de protocolo visando definir os
tipos de conhecimentos utilizados por um conjunto de
analistas de sistemas experientes (total de 18 analistas)
para soluo de problemas. Vitalari conclui
apresentando os resultados obtidos (ex. uma lista de
conhecimento, organizada em categorias, que mapeia
as diferentes solues propostas pelos analistas diante
do problema apresentado).
A pesquisa apresentada em [11] analisa os
comportamentos de dois grupos de analistas de
sistemas na soluo de problemas, e conclui sobre o
relacionamento entre esses comportamentos para um
desempenho de sucesso em relao ao trabalho
realizado. Os resultados do estudo sugerem que: (i)
diferenas qualitativas existem entre as solues; e (ii)
as habilidades associadas s solues de problemas
bem avaliadas por especialistas podem levar a um
melhor rendimento no trabalho. Alm disso, essas
habilidades podem ser transferidas para outros
praticantes.

35

11th. Workshop on Requirements Engineering

Outras pesquisas corroboraram com conceitos e

questes que foram explorados no desenvolvimento do
mtodo que propomos. Algumas delas sero descritas a
seguir:
O foco da pesquisa apresentada em [16] est na
participao dos integrantes envolvidos no processo
(ex. satisfao e produtividade) e no no processo
propriamente dito. Entretanto, Langan-Fox et al.
tambm discutem os resultados obtidos com base na
anlise das equipes participantes (ex. clientes e
desenvolvedores) em termos de suas implicaes para
o sucesso do processo como um todo. Alguns
resultados obtidos na pesquisa [16] consistem no
levantamento das diferenas individuais entre os
participantes, na modelagem da participao e na
identificao dos fatores determinantes para o bom
rendimento de uma equipe. Esses resultados foram
usados no desenvolvimento do nosso mtodo,
principalmente, na anlise da satisfao do cliente ao
longo do processo de levantamento de requisitos
realizado pela equipe de requisitos.
Os autores do artigo [17] descrevem o
desenvolvimento de um mtodo de avaliao da
eficcia dos membros de uma equipe. Para isso, eles
fazem um levantamento, baseado na literatura, de
vrios itens importantes (ex. capacidade de interao e
facilidade de comunicao) para serem avaliados nesse
contexto. Os testes so realizados usando grupos de
estudantes. A abordagem completa compreende 87
itens capazes de medir 29 tipos de contribuies dos
membros das equipes. Cada tipo composto de pelo
menos trs itens. Essas contribuies so ento
categorizadas usando uma taxonomia apropriada e
definida pelos autores. Cada categoria auxilia na
avaliao dos membros da equipe quanto a sua
eficcia. Entretanto, a abordagem dos autores visa
apenas avaliao especfica do critrio eficcia.
Outros critrios no so contemplados nesse mtodo. A
proposta do nosso mtodo mais ampla e mais restrita
ao mesmo tempo. mais ampla porque consiste em um
mtodo de avaliao que leva em conta diferentes
critrios (ex. satisfao dos clientes e comportamento
de risco dos membros da equipe de requisitos). mais
restrita porque est contextualizada para a avaliao de
equipes de requisitos.
O trabalho apresentado em [18] tem um diferencial
interessante. Os autores Rousseau et al. fazem um

levantamento de vrios comportamentos de equipes de

trabalho, relatados em pesquisas encontradas na
literatura, e propem a integrao desses modelos em
uma nica abordagem. O intuito de Rousseau et al
facilitar, atravs do uso do modelo integrado, a
realizao de tarefas coletivas junto aos membros das
equipes de diferentes organizaes. Mesmo Rousseau
et al no tendo a preocupao direta com a avaliao
das equipes envolvidas, o levantamento dos
comportamentos comumente encontrados nessas
equipes foi usado no desenvolvimento do nosso
mtodo. Esses comportamentos ajudaram a estabelecer
os principais critrios a serem considerados,
principalmente, nas avaliaes tcnica e gerencial do
nosso mtodo.
O trabalho apresentado em [19] descreve os efeitos
de diferentes personalidades no rendimento de uma
equipe. Alguns resultados apontados pelos autores
Mohammed e Angell so: (i) diferentes personalidades
(ex. habilidades tcnicas e de comunicao diferentes)
resultam em apresentaes orais mais expressivas; e (ii)
equipes com alto grau de habilidade cognitiva rendem
melhor em relatrios escritos. Essas questes foram
consideradas ao longo do desenvolvimento do nosso
mtodo, mostrando a necessidade de se desenvolver
uma etapa especfica (avaliao de comportamento de
risco), usando o foco no detalhe (zooming) para
avaliar, individualmente, o comportamento de
diferentes membros da equipe.
A pesquisa apresentada em [20] descreve como
equipes de gerenciamento podem gerenciar conflitos no
intuito de melhorar e promover inovaes
organizacionais. O artigo descreve vrios exemplos
reais que confirmam que o gerenciamento de conflitos
pode contribuir para melhorar a eficcia das equipes
em uma organizao. A anlise dos autores Chen et al.
levanta questes em relao ao comportamento da
equipe seja de cooperao, competio ou intimidao.
Alm disso, o artigo [20] destaca a importncia do lder
da equipe para o controle da situao. Particularmente,
o nosso mtodo sugere uma anlise especfica em
relao ao lder da equipe (sua postura, conhecimento e
habilidade de comunicao) e uma anlise dos conflitos
entre os membros da equipe.
No artigo [21], os autores Faraj e Sproull
argumentam que a mera existncia de experincia em
uma equipe no garante alta-qualidade de trabalho.

36

11th. Workshop on Requirements Engineering

Essa experincia precisa ser gerenciada e coordenada.

O estudo dos autores Faraj e Sproull avaliado em 69
equipes de desenvolvimento de software. Com base
nessa avaliao, esses autores revelam que a correta
coordenao da experincia mostra forte associao
com um maior rendimento da equipe. Entretanto, Faraj
e Sproull no analisam equipes novatas ou pouco
experientes. No nosso caso, a proposta contribuir
para avaliao de equipes experientes, nas quais
analisamos tambm a conduo (gerenciamento e
administrao) da experincia por parte do lder da
equipe; e de equipes novatas, nas quais a falta de
experincia no vista pelo nosso mtodo como
determinante para o insucesso do processo de
elicitao de requisitos.
No artigo [22], seus autores apresentam o conceito
de colaborao em equipes visando a avaliao da
qualidade das equipes. Os critrios usados na avaliao
so: comunicao, coordenao, balano das
contribuies por membro da equipe, auxlio mtuo
entre membros, esforos e coeso. Hoegl e Gemuenden
declaram que esses critrios, de acordo com os testes
realizados, so significativamente determinantes para
avaliao do rendimento das equipes. Vrios desses
critrios so direta ou indiretamente avaliados nas fases
bases (Avaliao Tcnica, Avaliao Gerencial e
Avaliao de Comportamento de Risco) do nosso
mtodo.

disso, Mohammed e Dumville propem um framework

que delineia os relacionamentos na construo do
conhecimento da equipe. O estudo emprico realizado
em [24] auxiliou o nosso mtodo, cujo
desenvolvimento foi conduzido considerando alguns
dos modelos mentais estabelecidos em [24],
principalmente na identificao dos comportamentos
de risco.
Nosso artigo detalha uma proposta de mtodo de
avaliao de equipes de requisitos. A construo foi
baseada na observao e anlise dos comportamentos
de quatro equipes (duas equipes cliente e duas equipes
de requisitos) em um Laboratrio de Requisitos
experimental [15] e na literatura que resumimos acima.
Nossa principal contribuio a apresentao de um
mtodo intuitivo, fundamentado em observao,
anotaes e uso de recursos visuais para analisar
equipes com diferentes perfis. Em seguida
apresentaremos o mtodo e suas principais etapas.

3. Viso Geral do Mtodo

O mtodo compreende as seguintes etapas: Etapa de
Avaliao Inicial, Etapa de Avaliao Tcnica, Etapa
de Avaliao Gerencial, Etapa de Avaliao de
Comportamento de Risco e Etapa de Avaliao dos
Resultados. A Figura 1 ilustra as etapas do mtodo,
bem como a ordem de execuo das mesmas.

Os autores em [23] descrevem o uso de ambientes

virtuais para a interao cooperativa entre mltiplos
participantes, enquanto especialistas observam
possveis focos de problemas, seja atravs dos conflitos
entre os participantes, seja pelo baixo rendimento da
equipe, seja por outros fatores. O trabalho apresentado
em [23] particularmente motivou o uso de um
laboratrio de requisitos no desenvolvimento do nosso
mtodo de avaliao, proposto nesse artigo. O
laboratrio experimental realizado na PUC-Rio
permitiu a observao, a anlise e o levantamento de
critrios importantes de acordo com o comportamento
das equipes dos projetos SimulES e Loja Carioca.
Os autores em [24] apresentam o desenvolvimento
de um estudo emprico que relaciona modelos mentais
de grupos com o rendimento desses grupos. Nesse
contexto, so levantados modelos mentais incluindo,
por exemplo, compartilhamento de informao,
aprendizado em grupo e consenso cognitivo. Alm

Figura 1: Etapas do Mtodo Proposto

O mtodo proposto est centrado na existncia de
pontos de controle durante o processo de construo
dos requisitos. O ponto de controle proposto pelo
mtodo o da realizao de reunies. De acordo com

37

11th. Workshop on Requirements Engineering

Camacho em [25], o uso de reunies como ponto de

controle permite que os avaliadores possam participar,
in loco, das atividades da equipe, quando a reunio for
realizada com a participao dos clientes. No entanto,
o mtodo pode vir a ser empregado utilizando outro
tipo de ponto de controle.
A Etapa de Avaliao Inicial compreende o
levantamento das principais caractersticas da equipe
de requisitos e do contexto onde ir atuar. Levam-se
em considerao aspectos tais como: a identificao do
nvel de conhecimento da equipe em relao
elicitao de requisitos; determinao de quantos
membros compem a equipe; familiaridade da equipe
de requisitos com o contexto; e perfil do lder da
equipe. Trata-se de uma etapa para construo do perfil
da equipe que ir trabalhar em um dado projeto
(contexto).
A Etapa de Avaliao Tcnica compreende a
avaliao de quais tcnicas foram escolhidas pela
equipe de requisitos. Utilizamos a caracterizao de
Leite [12] e dividimos a avaliao tcnica em trs
grandes partes: a) elicitao, b) modelagem e c)
anlise. A elicitao cuida da delimitao do Universo
de Informaes e da subseqente aquisio das
informaes sobre o software a ser construdo ou
evoludo. Exemplos de estratgias de elicitao so:
entrevista, leitura de documento, reunio, introspeco,
questionrio, dentre outras [12] [26] [27].
A
modelagem cuida da seleo de linguagens de
modelagem e a translao das informaes adquiridas
pela elicitao para essas linguagens. So vrias as
propostas de linguagens de modelagem, tais como:
lxico [28] [29], cenrios [28] [30] [31] [32], casos de
uso [33] [34] [35] [36], workflow [37], dentre outras.
A anlise procura garantir a qualidade dos modelos
gerados e pode utilizar tanto verificao como
validao. As tarefas de verificao so conduzidas
sem a necessidade da participao dos clientes e as
tarefas de validao, geralmente, envolvem uma
execuo, qui por simulao, do comportamento
modelado. Diferentes estratgias so disponveis na
literatura [12] tais como: inspeo, animao de
cenrios, pontos de vista, verificao formal e
prottipos.
A Etapa de Avaliao Gerencial compreende
avaliar vrios critrios de acordo com as caractersticas
das equipes em avaliao (ex. novata, experiente ou

pouco interativa). O mtodo sugere alguns critrios,

normalmente pertinentes para avaliao de qualquer
tipo
de
equipe: apresentao, pontualidade,
organizao da informao, postura, satisfao do
cliente, comunicao com o cliente e grau de
participao da equipe. A avaliao desses critrios
implica em conhecer melhor a equipe de requisitos,
mapeando suas qualidades e suas falhas. O objetivo
central a identificao dos aspectos gerenciais e a
precoce correo do processo de gerenciamento dos
requisitos, evitando falhas no desenvolvimento e na
manuteno do software.
A Etapa de Avaliao de Comportamento de
Risco compreende uma anlise mais profunda, na qual
a equipe em avaliao questionada acerca de
condutas no desejadas por parte dos seus membros
(ex. falta de tica, constantes atrasos, rendimento
baixo, insatisfao do cliente, entre outros). Para
auxiliar na identificao de comportamentos de risco, o
mtodo sugere a construo de grficos, considerando,
por exemplo, cada membro da equipe de requisitos em
separado. Focar no indivduo permite uma anlise
minuciosa do comportamento de risco, identificando se
o mesmo retrata um problema geral da equipe ou
apenas uma dificuldade de alguns membros da equipe
para com o projeto.
A Etapa de Avaliao dos Resultados compreende
a anlise dos resultados obtidos ao longo do processo
de construo dos requisitos. Alguns resultados
avaliados nessa etapa so: o prprio documento de
requisitos, a modelagem e demais solicitaes dos
clientes (ex. apresentaes, modelos, oramento, dentre
outras). O mtodo sugere a participao do cliente
nessa etapa, pois a sua satisfao serve de parmetro na
avaliao dos resultados. Sua satisfao pode ser
interpretada como sucesso; sua neutralidade como algo
que deve ser melhorado; e sua insatisfao implica que
o processo de elicitao seja refeito. Essa etapa
inspirou-se no uso de estratgias de anlise (vide em
Etapa de Avaliao Tcnica), em particular em
inspees [38].
As etapas do mtodo proposto no so executadas
seqencialmente. Elas podem ser aplicadas de acordo
com a ilustrao apresentada na Figura 1. Caso seja
necessrio, o avaliador (ou avaliadores) pode(m)
retornar a uma determinada etapa e especificar algum
detalhe observado em uma etapa posterior. Portanto, o

38

11th. Workshop on Requirements Engineering

mtodo pode ser seguido usando paralelismo entre as

diferentes etapas de avaliao. O importante que, ao
final do processo de construo dos requisitos, a
avaliao tenha passado por todas as etapas propostas
pelo mtodo, explorando os vrios recursos sugeridos
pelo mesmo (ex. grficos, tabelas comparativas e
sugestes de anlise).
Obviamente que pequenas adaptaes podem ser
necessrias para adequar o mtodo no caso de se tratar
de uma avaliao diferenciada (ex. individualista); ou
referente a uma equipe que diverge dos padres
tradicionais (ex. pouco interativa).
O mtodo incorpora ainda a escrita de textos, em
linguagem natural, solicitados aos clientes, que podem
expor suas opinies sobre a equipe de requisitos, bem
como relatar as necessidades observadas por eles
diante dos problemas e solues levantados pela equipe
de requisitos. Esses textos podem ser redigidos aps
uma atividade de interao entre desenvolvedores e
clientes, que na instncia atual do mtodo proposto
uma reunio. Porm, dependendo da disponibilidade
do cliente, essa prtica pode ser invivel. Por isso, o
mtodo pode ser flexibilizado, de acordo com a
possibilidade de colaborao do cliente, a ponto de
solicitar apenas um nico relatrio ao final do processo
de elicitao, diante dos resultados obtidos e
documentos entregues.
importante ressaltar que o mtodo proposto pode
ser utilizado tanto por gerentes das equipes de
requisitos como por auditores externos equipe.
Portanto, a palavra avaliador pode ser instanciada de
diferentes maneiras.

4. Detalhamento das Etapas do Mtodo

O mtodo utilizado para avaliao das equipes de
requisitos baseado em diferentes perspectivas [39]
[40]. De acordo com Leite [39], perspectivas referemse a Um conjunto de fatos observados e modelados de
acordo com uma estratgia de modelagem e um ponto
de vista1. O uso de diferentes perspectivas torna mais
equnime um processo de avaliao, na medida em que
possibilita uma viso mais geral. O fato de dividirmos
o mtodo em cinco (5) etapas reflexo da preocupao
1

http://requirementsviewpoints.blogspot.com/2007/07/perspectivesx-viewpoints-x-views.html

com as diferentes perspectivas que sobressaem em cada

etapa.
A possibilidade de lidar com essas diferentes
perspectivas permite avaliar casos, nos quais algumas
equipes mostram-se capazes de resolver problemas
usando tcnicas rebuscadas e cuidadosamente
aplicadas, enquanto outras usam criatividade e solues
mais simples. Segundo [9], equipes novatas costumam
ser mais criativas que as equipes experientes. Muitas
vezes, mesmo sem uma organizao e um
conhecimento vasto sobre aspectos gerenciais, o
relacionamento entre cliente e equipe pode ser bastante
promissor.
A
primeira
etapa,
avaliao
inicial,

fundamentalmente: um levantamento do contexto, onde

a avaliao ser aplicada, e um detalhamento do perfil
da equipe. Com isso o avaliador, ou avaliadores,
foca(m) no alvo de sua avaliao num contexto bem
definido. A ltima etapa envolve uma avaliao geral
tanto da equipe como dos documentos produzidos.
Nessa avaliao a participao dos clientes
fundamental.
Nas Sub-Sees seguintes nos deteremos na parte
central do mtodo, isto , nas avaliaes tcnica,
gerencial e de risco.

4.1. Etapa de Avaliao Tcnica

Esta etapa enumera as tcnicas utilizadas pelas
equipes levando em considerao a elicitao,
modelagem e anlise dos requisitos. Um quadro geral
construdo indicando as estratgias utilizadas, bem
como eventuais comentrios sobre o uso. A matriz
mostrada no quadro (Figura 2) reflete o fato de que o
ponto de controle utilizado pelo avaliador so reunies
em que os engenheiros de requisitos tiveram contato
com os clientes. No caso do Projeto SimulES [15], por
exemplo, a clula (Elicitao, Reunio 1) preenchida
com as tcnicas: brainstorming, observao e anotao.
O preenchimento do Quadro para Acompanhamento
das Escolhas Tcnicas da Equipe de Requisitos
realizado com base em comentrios qualitativos e
tcnicos dos membros da equipe avaliadora.
Normalmente, as equipes de requisitos, em um
primeiro contato, procuram conhecer o problema e os
clientes. Portanto, as tcnicas mais utilizadas na fase de
elicitao so reunies, questionrios e entrevistas e,

39

11th. Workshop on Requirements Engineering

dificilmente, a equipe optar, por exemplo, por uma

introspeco [26] em um primeiro momento.
Obviamente, quanto maior o contato com o cliente,
melhor para a relao equipe-cliente. Logo, costumam
ser mais proveitosas as reunies e entrevistas, buscando
sempre a interao e a participao dos interessados.

referente a essa tcnica. Vale lembrar que a estratgia

utilizada pode ter sido usada antes do ponto de controle
e rastreadas usando como base relatos dos clientes ou
comentrios entre os membros da equipe.

4.2. Etapa de Avaliao Gerencial

A Etapa de Avaliao Gerencial compreende a
avaliao de vrios critrios, dentre eles: Apresentao,
Pontualidade, Organizao da Informao, Postura,
Satisfao do Cliente, Comunicao com o Cliente e
Grau de Participao da Equipe. Esses critrios
utilizam
conceitos
gerais
de
administrao,
principalmente no que concerne a gerncia de recursos
humanos.

Figura 2: Quadro para Acompanhamento das

Escolhas Tcnicas da Equipe de Requisitos
Em relao modelagem, a avaliao deve valorizar
as tcnicas que utilizem uma linguagem mais prxima
do cliente, de fcil entendimento e utilizando recursos
visuais e um vocabulrio simples, de preferncia em
linguagem natural [41]. Uma opo nesse contexto
seria o uso de cenrios [31]. Nesse espao da matriz,
tambm, registram-se estratgias referentes evoluo2
dos documentos sendo produzidos. Em particular
importante ressaltar a estratgia de gerncia de
configurao [42] e se os documentos sendo
produzidos esto registrando os rastros necessrios [7]
[43]. Outras estratgias de controle tambm podem ser
adotadas [44] [45].
No que diz respeito anlise, a avaliao deve
considerar quais foram as formas utilizadas pelas
equipes de requisitos para verificar e validar os
requisitos elicitados. A verificao ou validao deve
ser realizada ao longo de toda a fase de Requisitos
[12].
Como dito anteriormente, cada clula da matriz
conter a estratgia utilizada, como algum comentrio
2

Aqui, pensou-se em colocar mais uma linha na matriz, mas

preferimos manter apenas as trs partes fundamentais. No fundo,
essa observao mostra uma caracterstica aspectual da prpria
gerncia, ou seja aplica-se a cada uma das trs partes. Decidimos
manter o aspecto de controle (configurao e rastros) na parte onde
as informaes so registradas (modelagem).

O critrio Apresentao visa avaliar o

comportamento da equipe de requisitos junto aos
clientes. Espera-se que a equipe de requisitos se
comporte adequadamente: (i) identificando cada
membro da equipe e apresentando-o ao cliente; (ii)
comparecendo com os principais membros da equipe
nas reunies com os clientes; (iii) apresentando
trabalhos de sucesso realizados anteriormente que
comprovem a experincia da equipe; e (iv)
demonstrando interesse em satisfazer o cliente.
O critrio Pontualidade avalia se a equipe est
comprometida com o projeto evitando, principalmente,
atrasos. Se por ventura ocorrerem, os atrasos devem ser
justificados aos clientes no primeiro momento do
encontro marcado.
O critrio Organizao da Informao avalia
como a equipe utiliza documentos na interao com os
clientes. Nesse aspecto importante que a equipe use
recursos de apresentao para facilitar o dilogo,
evitando prender-se to somente aos modelos
utilizados (vide modelagem na etapa anterior).
Particularmente interessante disponibilizar um
cronograma para oferecer aos clientes uma viso do
andamento do processo. Alia-se a isso o uso de
organograma, deixando mais transparente as
atribuies da equipe.
O critrio Postura avalia o quanto a equipe
experiente, segura, responsvel e estvel. Esse critrio
pode ser analisado observando o desempenho da
equipe em relao aos demais critrios e estabelecendo
uma nota geral. O cliente, normalmente, espera de uma
equipe de requisitos uma postura digna de quem

40

11th. Workshop on Requirements Engineering

resolver o problema de forma eficiente. Assim, a

avaliao desse critrio depende muito do critrio
Satisfao do Cliente. Questes de liderana tambm
so consideradas na avaliao da Postura. Quem
lidera o processo de levantamento de requisitos,
normalmente denominado gerente da equipe, deve:
(i) liderar a equipe; (ii) intervir em situaes de
conflito; (iii) dirigir e mediar as reunies; (iv)
apresentar a equipe aos clientes; e (v) ocupar uma
posio de destaque na equipe em termos de
conhecimento (tcnico e gerencial).

evitando falhas no desenvolvimento e na manuteno

do software. A Figura 3 apresenta um quadro
especificando cada um dos critrios, para facilitar a
avaliao das equipes na etapa gerencial. No caso do
Projeto SimulES [15], por exemplo, a clula
(Pontualidade, Reunio 2) preenchida com a seguinte
anotao: Pontualidade de alguns membros (4
membros), mas atrasos (1 membro) e at ausncia (1
membro) de parte da equipe.

O critrio Satisfao do Cliente avalia o

comportamento da equipe de requisitos pela
perspectiva do cliente. Comportamentos de risco (ex.
descontentamento por parte da equipe de requisitos;
conflitos freqentes entre as equipes ou entre membros
da mesma equipe) podem ser identificados atravs das
flutuaes constantes dos traos dos grficos. Como
uma das bases do mtodo proposto a satisfao do
cliente, cresce a necessidade de avaliar a relao
cliente-equipe cuidadosamente. Alm disso, o cliente
pode oferecer um feedback valioso e real sobre o
desempenho geral da equipe, apontar as principais
falhas e identificar as qualidades da equipe. A
satisfao do cliente pode revelar uma equipe de
requisitos
apresentvel,
pontual,
responsvel,
organizada e comunicativa, contribuindo dessa forma
para a avaliao de outros critrios.
O critrio Comunicao com o Cliente avalia,
principalmente, se a equipe prope alguma forma de
comunicao (alm dos pontos de controle) com o
cliente. Por exemplo, se existe uma forma de
comunicao a qualquer hora e em qualquer momento
(ex. blog, telefone, frum, correspondncia e e-mail)
com a qual o cliente possa interagir com a equipe para
esclarecer suas dvidas e expor novas necessidades.
Uma prtica interessante e aconselhada que a cada
ponto de controle, o cliente receba um documento
escrito em linguagem natural.
O critrio Grau de Participao da Equipe avalia
se a equipe de requisitos participou ativamente na
soluo dos problemas apresentados pelos clientes.
A avaliao desses critrios implica em conhecer
melhor a equipe de requisitos, mapeando suas
qualidades e suas falhas. O objetivo central a
identificao dos aspectos gerenciais e a precoce
correo do processo de gerenciamento dos requisitos,

Figura 3: Quadro para Acompanhamento do

Rendimento Gerencial da Equipe de
Requisitos
Cabe ressaltar que alguns critrios podem ser
incorporados ou removidos de forma que o mtodo
fique mais adequado s necessidades de cada projeto.
Assim como no caso da etapa de avaliao tcnica,
o preenchimento do Quadro para Acompanhamento do
Rendimento Gerencial da Equipe de Requisitos
realizado com base em comentrios qualitativos dos
membros da equipe avaliadora em relao ao
comportamento da equipe de requisitos. Os
comentrios so em relao aos diferentes critrios
utilizados, as linhas. As anotaes referem-se aos
pontos de controle ou s observaes anteriores ao
ponto de controle.

41

11th. Workshop on Requirements Engineering

4.3. Etapa de Avaliao de Comportamento de

Risco
Nesta etapa realiza-se uma anlise mais criteriosa,
utilizando-se de grficos para auxiliar a identificao
dos comportamentos de riscos. Um exemplo desse tipo
de comportamento, ocorrido na avaliao de uma das
equipes de requisitos presentes no laboratrio de
projetos, pode ser observado na Figura 4. Essa equipe
de requisitos participou ativamente nas primeiras
reunies e esse grau de participao foi se reduzindo
significativamente at a reunio de nmero 4.

Figura 4: Grfico Representando um

Comportamento de Risco
Neste caso, foi utilizada uma anlise investigativa
questionando esse comportamento junto equipe
cliente, alm da construo do grfico considerando

cada membro da equipe de requisitos individualmente,

como mostra a Figura 5.
O detalhamento a nvel individual permite uma
anlise minuciosa do comportamento de risco,
identificando se o mesmo retrata um problema geral da
equipe ou apenas um descaso de alguns membros da
equipe para com o projeto. O foco no detalhe
(zooming) pode ser aplicado sempre que for
observada uma situao de risco que pode
comprometer o processo de elicitao de requisitos.
Avaliaes so obtidas argindo cada membro da
equipe avaliadora, utilizando-se assim a estratgia de
mltiplos pontos de vista [39] em relao aos
diferentes quesitos das avaliaes tcnica e gerencial, e
com isso, obtendo avaliaes qualitativas de acordo
com os seguintes conceitos: (i) Muito Bom; (ii) Bom;
(iii) Regular; (iv) Insuficiente; (v) Ruim; e (vi) No
Avaliado. A avaliao no precisa ser de todos os
quesitos, mas sim, daqueles que merecem uma anlise
mais aprofundada, dada sua condio de risco.
Os membros fornecem seus conceitos de forma
independente e reservada, evitando-se assim que um
determinado membro seja influenciado pela opinio
dos demais. Uma vez obtidas as avaliaes de todos os
membros da equipe, essas avaliaes so divulgadas a
todos. Dessa forma, um conceito final estabelecido
por consenso entre os avaliadores. Os grficos so
obtidos sumarizando-se os conceitos por cada ponto de
controle, permitindo a visualizao do quesito em
questo ao longo de todo o processo de avaliao.

42

11th. Workshop on Requirements Engineering

5. Concluses

6. Referncias

Diante do exposto neste trabalho, ficam claras as

caractersticas de complexidade e incerteza conferidas
s tarefas de avaliar uma equipe e de sua correta
formao, atravs da anlise de variveis nem sempre
bem determinadas, com conceitos vagos e subjetivos e,
ainda, sem poder contar com histricos documentados
da atuao de seus membros. Alm disso, os mtodos
propostos na maioria das pesquisas e estudos empricos
encontrados na literatura implicam em disciplina e
conhecimento avanados do avaliador para serem
devidamente aplicados. Portanto, a pesquisa
apresentada prope um mtodo simples e intuitivo para
avaliao de equipes de requisitos que pode, por
exemplo, ser utilizado por empresas que desejam
melhorar o processo de elicitao de requisitos e
garantir a satisfao dos clientes.

[1]Sommerville, I. Software Engineering, 7th Edition,

Addison Wesley, 784 pages, ISBN-10: 0321210263, May
2004.
[2]Pressman, R. S., Engenharia de Software, 6 edio, Ed.
McGraw - Hill, 2006.
[3]Davis. Software Requirements Engineering. 2nd
Edition, Wiley- IEEE Computer Society Press, 549 pages,
ISBN-10: 0818677384, February 1997.
[4]Withington, F. G. A Organizao da Funo de
Processamento de Dados. Livros Tcnicos e Cientficos
Editora S.A., 122 pginas, Rio de Janeiro, RJ, 1976.
[5]Gunther, R. C. Management Methodology for Software
Product Engineering. Wiley-Interscience Publication, John
Wiley & Sons, 379 pages, 1978.
[6]Booch, G. Object Solutions: Managing the ObjectOriented Project. Addison-Wesley Publishing Company,
323 pages, 1996.
[7]Sayo, M.; Leite, J. C. S. P. Rastreabilidade de
Requisitos. Revista de Informtica Terica e Aplicada RITA, Volume XII, Nmero 1, 2005.
[8]Agnol, S. D.; Herbert, J. S. Utilizao do TSP para a
Gerncia de Equipes Nvel 2 do CMMI, VI Simpsio
Internacional de Melhoria de Processos de Software
Simpros, pp. 107-118, November 2004.
[9]Schenk, K. D.; Vitalari, N. P.; Davis, S. K. Differences
Between Novice and Expert Systems Analysts: What Do We
Know and What Do We Do?. Journal of Management
Information Systems, Summer, Vol. 15, Number 1, pp. 9-50,
1998.
[10]Vitalari, N. P. Knowledge as a Basis for Expertise in
Systems Analysis: An Empirical Study. Management
Information Systems Research Center Quarterly, University
of Minnesota, Vol. 9, Number 3, pp. 221-241, September
1985.
[11]Vitalari, N. P., Dickson, G. W. Problem Solving for
Effective Systems Analyis: An Experimental Exploration.
Communications of ACM, Vol. 26, Number 11, pp. 948-956,
November 1983.
[12]Leite, J.C.S.P. Livro Vivo : Engenharia de Requisitos,
http://livrodeengenhariaderequisitos.blogspot.com/ (2008).
[13]Batista, E. A.; Carvalho, A. M. B. R. Uma Taxonomia
Facetada para Tcnicas de Levantamento de Requisitos.
Anais do WER03 Workshop em Engenharia de Requisitos,
20 pginas, Piracicaba, SP, 2003.
[14]Rezende, A.; Valds, H. Mtodos de estudo das
habilidades tticas: abordagem comparativa entre jogadores
habilidosos e iniciantes - expert & novice. Revista Digital,
Buenos Aires, Ao 9 - N 65, Buenos Aires, Octubre 2003.
[15]Serrano, M.; Serrano, M.; Napolitano, F.; Kinder, E.;
Douglas, M.; Loyola, D.; Rezende, B.; Leite, J. C. S. P.
Avaliao Experimental de um Mtodo para Avaliao de
Equipes de Requisitos. Aceito no Simpsio Brasileiro de
Engenharia de Software (SBES), 2008.
[16]Langan-Fox, J.; Code, S.; Gray, R.; Langfield-Smith, K.
Supporting Employee Participation: Attitudes and
Perceptions in Trainees, Employees and Teams. Group

O mtodo compreende, dentre outras tcnicas: a

observao, a organizao da avaliao de acordo com
diferentes critrios, o uso de recursos visuais como
quadros comparativos e grficos e consultas aos
clientes sobre o desempenho da equipe de requisitos.
A observao faz-se necessria para investigar as
principais tcnicas utilizadas pela equipe, bem como
para avaliar o comportamento e o desempenho dos
membros da mesma. A organizao das avaliaes
geradas com a observao da equipe de requisitos
permite obter uma avaliao geral (mdia entre as
avaliaes). Essa viso geral importante para orientar
o avaliador sobre as principais qualidades e
fragilidades da equipe de requisitos.
O uso de quadros e grficos permite a visualizao
do desempenho da equipe em relao a critrios de
importncia. Vale ressaltar tambm que o uso de
diferentes perspectivas e de pontos de vista contribuem
para uma maior completude da avaliao. Conforme
apontado na Introduo, o mtodo j reflete a retroalimentao produzida por sua utilizao em dois
estudos de caso, num contexto de laboratrio
envolvendo um total de cerca de 20 pessoas [15].
Trabalhos futuros devero ser orientados para outras
aplicaes em laboratrio, o que permitir um melhor
conhecimento sobre o mtodo. Pretende-se aplicar o
mtodo com a participao de outras equipes
avaliadoras.

43

11th. Workshop on Requirements Engineering

Processes & Intergroup Relations, Vol 5(1), pp. 5382,

London, Thousand Oaks, CA, 2002.
[17]Loughry, M. L.; Ohland, M. W.; Moore, D. D.
Development of a Theory-Based Assessment of Team
Member Effectiveness. Educational and Psychological
Measurement, Vol. 67, Number 3, pp. 505-524, June 2007.
[18]Rousseau, V.; Aub, C.; Savoie, A. Teamwork
Behaviors: A Review and an Integration of Frameworks.
Small Group Research, Vol. 37, Number 5, October 2006.
[19]Mohammed, S.; Angell, L. C. Personality Heterogeneity
in Teams: Which Differences Make a Difference for Team
Performance? Small Group Research, Vol. 34, Number 6,
pp. 651-677, December 2003.
[20]Chen, G.; Liu, C.; Tjosvold, D. Conflict Management
for Effective Top Management Teams and Innovation in
China. Journal of Management Studies, March 2005.
[21]Faraj, S.; Sproull, L. Coordinating Expertise in
Software Development Teams. Management Science, Vol.
46, Number 12, pp. 1554-1568, December 2000.
[22]Hoegl, M.; Gemuenden, H. G. Teamwork Quality and
the Success of Innovative Projects: A Theoretical Concept
and Empirical Evidence. Organization Science, Vol. 12,
Number 4, pp. 435-449, August 2001.
[23]Mastaglio, T.W. Callahan, R. Large-scale complex
virtual environment for team training. IEEE, Vol. 28, Issue:
7, pp. 49-56, July 1995.
[24]Mohammed, S.; Dumville, B. C. Team mental models
in a team knowledge framework: expanding theory and
measurement across disciplinary boundaries. Journal of
Organizational Behavior, Vol. 22, Issue: 2, pp. 89-106,
March 2001.
[25]Camacho, C. Gerenciando Conflitos em Reunies: Uma
estratgia para a Elicitao de Requisitos de Software.
Dissertao de Mestrado - Departamento de Informtica,
Pontifcia Universidade Catlica do Rio de Janeiro, PUCRio, 168 pginas, Maro 2005.
[26]Goguen, J. A.; Linde, C. Techniques for Requirements
Elicitation. In: International Symposium on Requirements
Engineering, Proceedings IEEE Computer Society Press,
Edited by Stephen Fickas and Anthony Finkelstein, Vol.1,
pp. 152-164, San Diego, 1993.
[27]Toro, A. D.; Jimnez, B. B. Metodologa para la
Elicitacin de Requisitos de Sistemas Software. Versin
2.3, Informe Tcnico LSI200010 (revisado), Dpto. de
Lenguajes y Sistemas Informticos, 76p., Sevilla, Abril 2002.
[28]Silva, L. F.; Leite, J. C. S. P.; Breitman, K. K. C&L:
Uma Ferramenta de Apoio Engenharia de Requisitos.
Revista de Informtica Terica e Aplicada - RITA, 23
pginas, 2005.
[29]Nitsche, R.; Bortoli, L. A. E-LAL: Um Editor Para o
Lxico Ampliado da Linguagem, 9 pginas, Abril 2006.
[30]Breitman, K.; Leite, J.C.S.P. Scenario Evolution:
observations from a case study. Proceedings of the
International Conference on Requirements Engineering,
IEEE Computer Society Press, pp. 214-221, 1998.
[31]Benneer, K. M. et al. Utilizing Scenarios in the
Software Development Process. Information Systems
Development Process, North-Holland: Elsevier Science
Publisher, pp. 117-134, 1993.

[32]Junior, J. C.; Masiero, P. C. ERACE-TOOL Uma

Ferramenta baseada em Cenrios para a Engenharia de
Requisitos. Workshop de Engenharia de Requisitos, pp. 7078, Maring, Paran, Brasil, Outubro 1998.
[33]Jacobson, I.; Christerson, M.; Jonsson, P.;vergaard, G.
Object-Oriented Software Engineering - A Use Case Driven
Approach. Addison Wesley, 350 pages, ISBN 0201544350,
June 1992.
[34]Lopes, P. S. N. D.; Barreto, M. R. P. Requirements
Modeling with UML Discussed. Boletim Tcnico, Escola
Politcnica da USP, 2002.
[35]Regnell B.; Andersson M.; Bergstrand J. A Hierarquical
Use Case Model with Graphical Representation.
Proceedings IEEE International Symposium and Workshop
on Engineering of Computer-Based Systems, 1996.
[36]Leffingwell, Dean; Widrig, Don. Managing Software
Requirements - A Use Case Approach. 2nd Edition,
Addison-Wesley, 544 pages, ISBN-10: 032112247X, May
2003.
[37]Bortoli, L.A., Price, A.M.A. O Uso de Workflow para
Apoiar a Elicitao de Requisitos. Workshop de Engenharia
de Requisitos, pp. 22-37, Rio de Janeiro, 2000.
[38]Freitas, M. E.; Pagliuso, P B. B.; Boas, V. B.;
Tambascia, C. A.; Maldonado, J. C.; Hhn, E. N.; Fabbri, S.
C. P. F. Inspeo de Documentos de Requisitos Baseado em
Tcnica de Leitura PBR: Experincia Prtica no CPqD.
Simpsio Brasileiro de Qualidade de Software - SBQS,
Artigo Nmero 14, 8 pginas, Braslia, DF, Brasil, 2004.
[39]Leite, J.C.S.P., Freeman, P.A, Requirements Validation
Through Viewpoint Resolution. In IEEE Transactions on
Software Engineering, Vol. 17, Number 12, pp. 1253-1269,
1991.
[40]Nuseibeh, B.; Kramer, J., Finkelstein, A. A Framework
for Expressing the Relationships Between Multiple Views in
Requirements Specifications. IEEE Transactions on
Software Engineering, Vol. 20, Number 10, pp. 760-773,
October 1994.
[41]Silva, L. F. S.; Chapetta, W. A. Processamento de
Linguagem Natural Aplicada Inspeo de Documentos de
Especificao de Requisitos de Software. Universidade
Federal do Rio de Janeiro, COPPE / Engenharia de Sistemas
de Computao, 27 pginas, Junho 2003.
[42]Oliveira, S. B. C.; Tanaka, A. K.; Vianna, D, S.
Avaliao de Ferramentas para Controle Automatizado de
Verses de Artefatos de Requisitos de Software. Workshop
de Engenharia de Requisitos, pp. 124-130, Rio de Janeiro,
RJ, Julho 2006.
[43]Ramesh, B.; Powers, T.; Stubbs, C. Implementing
Requirements Traceability: A Case Study. 2nd. IEEE
Symposium on Requirements Engineering, pp. 89-95,
England, March 1995.
[44]Grande, J. I. de ; Martins, L. E. G. SIGERAR: Uma
Ferramenta para Gerenciamento de Requisitos. Workshop
de Engenharia de Requisitos, pp. 75-83, Rio de Janeiro, RJ,
Brasil, Julho 2006.
[45]Hazan, C.; Leite, J. C. S. P. Indicadores para a Gerncia
de Requisitos. Anais do WER03 - Workshop em
Engenharia de Requisitos, pp. 285-301, Piracicaba, SP,
Novembro 2003.

44