Cecilia Camacho
Gerenciando Conflitos em Reuniões: Uma Estratégia para a Elicitação de Requisitos de Software
Dissertação de Mestrado
Dissertação apresentada ao Programa de Pós-gra-
duação em Informática da PUC-Rio como requisito
parcial para obtenção do título de Mestre em
Informática. Aprovada pela comissão examinadora
abaixo assinada.
Orientador: Julio Cesar Sampaio do Prado Leite
Rio de Janeiro
Março de 2005
Todos os direitos reservados. É proibida a reprodução total ou
parcial do trabalho sem autorização do autor, do orientador e
da universidade.
Cecilia Camacho Graduada em Bacharel em Informática em 2002 pela
PUC-Rio. Sua área de interesse acadêmico é Engenharia de
Software, mais especificamente a sub-área de Engenharia de
Requisitos.
Ficha catalográfica
CDD: 004
Camacho, Cecilia Gerenciando conflitos em reuniões: uma estratégia
para a elicitação de requisitos de software / Cecilia Camacho ; orientador: Julio Cesar Sampaio do Prado Leite. – Rio de Janeiro : PUC-Rio, Departamento de Informática, 2005.
167 f. : il. ; 30 cm Dissertação (mestrado) – Pontifícia Universidade
Católica do Rio de Janeiro, Departamento de Informática. Inclui referências bibliográficas 1. Informática – Teses. 2. Elicitação de requisitos. 3.
Reuniões. 4. Gerência de conflitos. 5. Conflitos funcionais. 6. Conflitos não funcionais. 7. Retroalimentação. I. Leite, Julio Cesar Sampaio do Prado. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título.
Em memória do meu avô
Agradecimentos
A Deus por me iluminar sempre.
Aos meus pais e a minha avó pela força e incentivo, principalmente nos
momentos mais difíceis.
Ao meu namorado Brunno Lima pelo companheirismo.
Aos meus amigos Christian Dechery, Bruno Freitas e Jefferson Santos pela
paciência, apoio e atenção. E também aos amigos Antonio de Pádua, Roberta de
Souza, Ângela Albarello, Fábio Marques, Ana Luiza, Miriam Sayão, Gustavo
Robichez, Uirá Kuleska, Daniela Brauner, Akeo Tanabe, Lyrene Fernandes,
Cláudio Santanna e Anarosa Alves Brandrão pela participação nos estudos de caso
realizados.
A PUC-Rio e a CAPES, pelos auxílios concedidos, sem os quais esse
trabalho não poderia ser realizado.
Ao meu orientador Julio Cesar Sampaio do Prado Leite, pela sabedoria
compartilhada.
RESUMO
Camacho, Cecilia. Gerenciando Conflitos em Reuniões: Uma estratégia para a Elicitação de Requisitos de Software. PUC-Rio, 2005. 168p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
Esta dissertação estuda um meio de apoiar a elicitação de requisitos,
utilizando reuniões. Para isso utilizamos a gerência de conflitos, que através do
estímulo aos conflitos funcionais e do controle e tratamento dos conflitos não
funcionais, visa à criação de idéias e o dinamismo da reunião, aumentando o
volume de conhecimento elicitado. Tudo isso é realizado através de um trabalho
cooperativo entre os interessados no sistema a ser desenvolvido.
O método proposto é uma evolução de um trabalho anterior e baseia-se na
gerência de conflitos em um ciclo de reuniões. Essa gerência é levada adiante por
meio de um processo de retroalimentação de responsabilidade dos participantes
das reuniões, que utilizam um questionário para fornecimento destas informações.
Uma ferramenta Web foi construída para a coleta das respostas ao questionário,
bem como para apoiar à análise dos conflitos.
Palavras-Chave
Elicitação de requisitos; reuniões; gerência de conflitos; conflitos
funcionais; conflitos não funcionais; retroalimentação.
ABSTRACT
Camacho, Cecilia; Leite, Julio Cesar Sampaio do Prado; Conflict
Management in Meetings: An Strategy for Software Requirements
Elicitation. Rio de Janeiro, 2005. 168p. Master degree thesis – Computer
Science Department, Pontifícia Universidade Católica do Rio de Janeiro.
This work reports research on the automation support for requirements
elicitation performed by means of meetings. In order to provide this support, we
ground our work on conflict management, stimulating functional conflicts and
controlling non-functional conflicts in order to increase the volume of elicited
knowledge. This is based on cooperative work among the stakeholders of the
demanded system or demanded changes on an existing system.
The method is an evolution of a previous work on the topic and is based on
conflict management over a cycle of meetings. This management is performed by
a feedback process enacted by the meeting participants by means of a
questionnaire for the provision of information. A Web tool to support the method
was built to collect the information and analyze the conflicts.
Keywords
Requirements elicitation; meetings; conflict management; functional
conflicts; non-functional conflicts; feedback loop
Sumário
1 - Introdução 9
1.1. Descrição sumária do problema 10
1.2. Motivação do trabalho 11
1.3. Estrutura do trabalho 12
2 - Engenharia de requisitos 14
2.1. Importância 14
2.2. Conceitos gerais 15
2.3. Elicitação de requisitos 17
2.4. Análise de requisitos 24
2.5. Principais problemas na elicitação de requisitos 26
2.6. A reunião segundo o método de [Mathias 94] 28
3 – O método 36
3.1. O planejamento da reunião 37
3.2. Gerenciando os conflitos 38
3.3. A tomada de decisões 39
3.4. O questionário 40
3.5. Identificando conflitos 102
4 – Ferramenta de apoio ao método 108
4.1. Novas características da ferramenta 108
4.2. Interface da ferramenta 109
4.3. Grafo de relacionamento das tabelas implementadas 122
4.4. Sistema especialista para detecção dos conflitos 123
5 - Análise de caso prático 147
5.1. Preparação 147
5.2. Estudo de Caso 1 - Com o uso da ferramenta de apoio a reuniões 148
5.3. Estudo de Caso 2 - Sem o uso da ferramenta de apoio a reuniões 154
5.4. Conclusão do Experimento 156
6 – Conclusões e trabalhos futuros 158
7 – Bibliografia 161
Lista de figuras
Figura 1 – Árvore abstrata de usuários [Leite 94]. 21
Figura 2 – O espiral da elicitação, análise e negociação 26
Figura 3 – O fluxograma do método 36
Figura 4 – Arquitetura do sistema 109
Figura 5 – Tela de acesso ao sistema 110
Figura 6 – Tela de acesso aos módulos do líder e do participante comum 111
Figura 7 – Módulo planejador 111
Figura 8 – Módulo do planejador (Cadastro das reuniões) 113
Figura 9 – Módulo do planejador (Listagem dos conflitos) 114
Figura 10 – Módulo do líder 115
Figura 11 – Módulo do participante comum 122
Figura 12 – Grafo de relacionamento das tabelas implementadas 123
Figura 13 – O processo 141
Figura 14 – Fluxograma do estudo de caso 1 148
Figura 15 – Fluxograma do estudo de caso 2 154
1 - Introdução
Esta dissertação estuda um meio de apoiar a elicitação de requisitos,
tentando minimizar os principais problemas relacionados a esta tarefa. Para isso
utilizamos a gerência de conflitos, que através do estímulo aos conflitos
funcionais e controle e tratamento dos não funcionais, visa a criação de idéias e o
dinamismo da reunião, ao mesmo tempo em que trata problemas que não
objetivam trazer benefícios para a organização. Tudo isso é realizado através de
um trabalho cooperativo entre os interessados no sistema a ser desenvolvido.
Com este objetivo estudamos o uso de reuniões como meio para a elicitação
de requisitos, através da proposta de utilizar um ciclo de reuniões que se baseia na
retroalimentação dos participantes. Propomos uma estratégia que é uma evolução
de uma proposta anterior [Mathias 94]. O método baseia-se na realização de um
ciclo de reuniões que devem ser cuidadosamente planejadas e realizadas visando
produzir uma lista de requisitos a partir dos objetivos do sistema.
Neste trabalho, citamos os principais problemas relacionados a elicitação de
requisitos, junto com suas causas e técnicas de resolução destes problemas. A
partir daí, identificamos os principais pontos para se observar e seguir em reuniões
de aquisição de conhecimento, permitindo a elaboração de um questionário para
ser respondido pelos participantes da reunião ao seu final. Nele tentamos detectar
se ocorreu algum conflito durante a reunião, com base na análise da existência ou
não desses pontos primordiais.
As respostas fornecidas pelos participantes, para cada pergunta do
questionário, são analisadas medindo o nível de conflito em cada uma das
questões e comparando os níveis obtidos com os padrões estabelecidos para
controle. Os que ultrapassarem o limite irão compor a lista de conflitos que
ocorreram durante a reunião, junto com suas possíveis causas e técnicas de
gerenciamento sugeridas.
Dessa maneira, antes ou durante a próxima reunião, devem ser feitas
correções nos comportamentos negativos que foram observados, no enfoque e no
direcionamento que a reunião passada tomou, sempre visando uma melhoria na
10
qualidade dos requisitos obtidos. O ciclo de reuniões será encerrado quando se
julgar que não é mais necessário levantar novas funcionalidades e não forem mais
detectados problemas que possam prejudicar as demais etapas do processo de
desenvolvimento do sistema. Estes problemas podem ser identificados pela
ausência de conflitos funcionais ou ocorrência de conflitos não funcionais.
Como parte da nossa contribuição para a evolução do método de
gerenciamento de conflitos em reuniões, fizemos:
a) regras de produção em um sistema especialista para identificar a
ocorrência ou ausência de conflitos nas reuniões,
b) reformulação das perguntas do questionário e do encadeamento
dessas perguntas,
c) uma nova ferramenta com acesso distribuído aos participantes e,
d) criamos novas regras para identificação dos conflitos.
Realizamos um estudo de caso prático para verificarmos a aplicabilidade do
método. Os resultados deste estudo serão apresentados, mostrando as melhorias
obtidas tanto na dinâmica do grupo quanto na qualidade dos requisitos, a partir da
realização de um ciclo de reuniões baseado no método.
1.1. Descrição sumária do problema
Atualmente, um dos grandes problemas que as empresas enfrentam na
automação dos seus processos organizacionais é o estabelecimento dos requisitos
que devem ser atendidos pelos sistemas de informação. Apesar dos grandes
investimentos recentes em métodos e ferramentas de registro e de documentação
de requisitos, ainda há uma grande carência nas etapas de elicitação e análise dos
requisitos.
A dificuldade surge na comunicação entre a equipe de desenvolvimento e os
clientes envolvidos. As freqüentes falhas de comunicação e de entendimento, que
ocorrem durante esta interação, resultam em erros de especificação cuja posterior
correção, nos sistemas já construídos, comprometem os prazos e os custos
previstos.
A elicitação envolve todo um conjunto de ações, que ocorrem no universo
de informações, visando capturar as informações que subsidiarão o entendimento
do problema e, conseqüentemente, a modelagem dos requisitos. A captura é um
11
processo de descoberta no qual procuramos obter o máximo de informações para
o conhecimento do objeto em questão. Requer uma habilidade em trabalhar com
especialistas humanos e com o conhecimento tácito, que é trivial para quem
conhece a informação, mas não é trivial para quem procura obtê-la, de forma que
dificilmente é lembrado e, portanto, não é transmitido [Goguen 94].
Não é uma tarefa fácil obter as informações para desenvolvimento de um
sistema, pois os envolvidos têm experiências, conhecimentos, preconceitos e
terminologias diferentes. Algumas técnicas das ciências sociais, como psicologia e
sociologia, têm sido estudadas e utilizadas nesta atividade, que envolve fatores
comportamentais e de relacionamento humano [Bertolin 98] [Bortoli 99].
Entre as técnicas mais utilizadas para a aquisição do conhecimento
destacam-se as reuniões. Reunião é uma técnica que prevê a participação coletiva
dos envolvidos para discutir questões do problema. Esta prática permite uma
interação mais natural entre os participantes e leva em consideração múltiplas
visões sobre a questão abordada.
Participatory Design (PD) e Joint Application Design (JAD) são métodos
de reuniões que enfatizam a participação coletiva na especificação do software
[Carmel 93]. São práticas bem conhecidas que promovem a cooperação,
entendimento e formação de equipes de trabalho entre os envolvidos no universo
de informações, porém não estão focadas na elicitação de requisitos.
Diferentemente dos dois métodos de reuniões citados, JAD e o PD, o
método que apresentamos baseia-se em elicitar os requisitos do software, ao invés
de focar na modelagem. Além disso, é fundamentado em ciclos de reuniões
estruturadas com base na retroalimentação dos participantes. Essa
retroalimentação é baseada na gerência dos conflitos.
1.2. Motivação do trabalho
Buscamos evoluir o método de apoio a reuniões proposto por [Mathias 94]
com o objetivo de melhorar a sua aplicabilidade. Para esta evolução,
identificamos a necessidade de uma reformulação das perguntas do questionário,
para torná-lo menos cansativo, mais objetivo e capaz de apoiar também reuniões
realizadas de maneira não presencial.
12
Como uma das principais melhorias, citamos o desenvolvimento de um
sistema especialista para identificar os conflitos ocorridos e ausentes nas reuniões,
com base nas respostas do questionário pelos participantes. Com o uso de regras
de produção modularizamos a tarefa de análise das respostas e a tornamos mais
flexível e de fácil compreensão.
Esta evolução também permite uma maior interação dos usuários com o
sistema, pois a nova ferramenta foi desenvolvida em três camadas, com um
servidor web que permite o acesso distribuído, facilitando a interação dos usuários
e também possibilitando o apoio as reuniões realizadas de forma não presencial,
muito comuns no Desenvolvimento Distribuído de Software (DDS).
O DDS apresenta algumas características que o tornam fundamentalmente
diferente do desenvolvimento de software co-localizado [Zowghi 02]. A
comunicação e coordenação tornam-se mais problemáticas face aos fatores
característicos de DDS, principalmente no que range a localização geográfica e
temporal dos envolvidos.
1.3. Estrutura do trabalho
O capítulo 2 aborda brevemente as principais atividades da Engenharia de
Requisitos, apresenta os conceitos gerais e descreve as atividades de definição e
análise de requisitos e seus principais problemas. Trata também, em especial, do
tema conflito e suas características mais importantes, com a finalidade de fazer
compreender o que é o conflito e quais são os seus tipos. As principais técnicas de
resolução e de estímulo ao conflito também são apresentadas. Elas serão utilizadas
pelo método para o gerenciamento dos conflitos surgidos nas reuniões.
O capítulo 3 inicialmente descreve o método proposto por [Mathias 94] e
apresenta brevemente todas as contribuições desta dissertação no que se refere ao
método original. Em seguida, apresenta o novo questionário com a descrição
completa de cada pergunta, em seu respectivo grupo de classificação. Após isso
detalha todo o processo de reformulação do questionário, descrevendo os motivos
de cada alteração. E ao final mostra como os conflitos ocorridos são detectados a
partir das respostas dos participantes ao questionário. Apresenta o modelo que é
utilizado para detectar a presença do conflito e como são identificadas as causas
mais prováveis de cada um.
13
O capítulo 4 descreve as principais características técnicas da nova
ferramenta de apoio ao método, desenvolvida para fornecer uma maior
interatividade aos usuários e agilidade na detecção dos conflitos. Destacando o
sistema especialista e suas vantagens.
O capítulo 5 descreve os resultados obtidos. Os principais benefícios são
comentados com base em um caso prático..
Finalmente, o capítulo 6 contém as conclusões de todo o trabalho
apresentado, mostrando os principais benefícios das evoluções realizadas no
método. Apresenta também sugestões para o aprimoramento e trabalhos futuros.
Vale observar que convencionamos utilizar nas partes do texto que mostram
as regras para identificação dos conflitos e exemplos de código fonte a fonte de
texto Courier New 11.
2- Engenharia de requisitos
Este capítulo contém os principais conceitos sobre engenharia de requisitos.
Apresentamos as principais atividades do processo de definição de requisitos e
ressaltamos o uso da técnica de reuniões como uma estratégia para elicitação de
requisitos.
2.1. Importância
A visão do software como um produto [Gunther 78] permite organizar o seu
processo de criação de forma mais estruturada. Segundo [Leite 94], esta visão
facilita também a melhor identificação dos aspectos que são software e dos
aspectos que pertencem ao universo no qual o software será inserido.
Podemos notar que cada dia é mais freqüente encontrarmos o produto
software inserido em uma série de outros produtos, desde carros, telefones até
sistemas de informação organizacionais. Como de um produto exige-se preço e
qualidade, o software tem que ter o nível de qualidade exigido e tentar ser
desenvolvido com o menor custo possível. De acordo com [Leite 94], “esta é
exatamente a função da engenharia, procurar sistemas de melhor qualidade dentro
de um custo compatível com essa qualidade, otimizando a redução de custos”.
Porém, garantir a qualidade nos produtos e processos de engenharia de
software não é uma atividade fácil. Existem inúmeros fatores que atrapalham no
alcance dos objetivos de qualidade. No entanto, é necessário que estes objetivos
sejam atendidos, já que não podemos negar o quanto é decepcionante entregar um
software que não corresponda às necessidades dos clientes. Como um dos
causadores desses problemas podemos citar a falta de atenção dedicada à tarefa de
definir e acompanhar a evolução dos requisitos durante o processo de construção
do software [Leite 01].
É fundamental que o software seja confiável. Isso significa ser eficaz e
cumprir com os padrões exigidos pelo universo que será inserido. Freeman
[Freeman 87] subdivide a qualidade em duas vertentes: básica e extra. Ele
15
identifica qualidade básica como: funcionalidade, confiabilidade, facilidade de
uso, economia e segurança de uso. E qualidade extra como: flexibilidade,
facilidade de reparo, adaptabilidade, facilidade de entendimento, boa
documentação e facilidade de adicionar melhorias. O setor de software vem sendo
muito pressionado pela sociedade para que se invista alto no quesito qualidade.
Normas internacionais como a ISO e iniciativas como a da SEI (Software
Engineering Institute) [Fiorini 98] são exemplo disso.
“A engenharia de requisitos é a disciplina que procura sistematizar o
processo de definição de requisitos” [Leite 94]. Segundo o autor, [Leite 94] esta
atividade é de extrema importância já que a complexidade dos sistemas exige uma
maior atenção ao correto entendimento do problema antes do acordo de uma
solução final. Esta é uma atividade que trata de conhecimentos não apenas
técnicos, mas também gerenciais, organizacionais, econômicos e sociais [Castro
95], e estar intimamente associada a qualidade do software [Lee 98].
“A engenharia de requisitos estabelece o processo de definição de
requisitos como um processo no qual o que deve ser feito é elicitado, modelado e
analisado. Este processo deve lidar com diferentes pontos de vista, e usar uma
combinação de métodos, ferramentas e pessoal. (...) Este processo acontece num
contexto previamente definido a que chamamos de Universo de Informações” -
segundo [Leite 94].
A engenharia de requisitos propõe um conjunto de métodos, técnicas e
ferramentas para dar apoio ao processo de definição de requisitos. Neste capítulo
descreveremos as principais atividades da engenharia de requisitos, explicando
sua importância dentro do ciclo de desenvolvimento de um sistema.
2.2. Conceitos gerais
Iniciaremos discursando um pouco sobre alguns conceitos básicos da área
de engenharia de requisitos.
2.2.1. Especificações
Segundo Alan Davis [Davis 90], em seu livro Software Requirements, uma
especificação é simplesmente:
16
“A document; for example, a requirements specification is a document
containing requirements; a design specification is a document containing the
design; a test specification is a document containing the testing process”.
Já o autor Carlo Ghezzi [Ghezzi 91], em Fundamentals of Software
Engineering, é mais exato:
“In general, we can view a specification as the statement of an agreement
between a producer of a service and a consumer of the service, or an implementer
and a user”.
Especificações podem ser entendidas, em uma idéia formal, como ambos
requisitos e programa. É um requisito porque trata do contexto, e é um programa
porque também trata de características da máquina. Isto ocorre porque
especificações formam uma ponte entre requisitos e programas [Jackson 95].
De acordo com [Lawsweerde 02], de maneira geral uma especificação
formal é a expressão, em alguma linguagem formal e de alto nível de abstração,
de uma coleção de propriedades que determinado sistema deve satisfazer. Este
sistema pode ser um modelo descritivo de um domínio de interesse, um
determinado modelo de software e seu ambiente, a arquitetura do software ou um
modelo de algum processo a ser seguido. As propriedades consideradas acima
podem referenciar objetivos de alto nível, requisitos funcionais, requisitos não
funcionais, hipóteses do ambiente, entre outros.
2.2.2. Requisitos
The IEEE Standard Glossary of Software Engineering Terminology [IEEE
97] define requisito como uma condição ou capacidade necessária para um
usuário resolver um problema ou alcançar um objetivo.
Já Goguen [Goguen 94] define requisito como propriedades que um
sistema de software deve ter em busca do seu êxito no ambiente onde será
utilizado.
Conforme alguns autores [Macedo 99] [Gilb 97], os requisitos de software
podem ser tanto as necessidades funcionais, identificadas como o comportamento
e as propriedades do sistema, quanto as necessidades não funcionais,
caracterizadas pelos quesitos de qualidade e restrições operacionais ou do
desenvolvimento do software.
17
Apesar dos requisitos serem sobre o domínio da aplicação, não sobre a
máquina, a máquina pode garantir que estes requisitos sejam satisfeitos, pois a
máquina e os requisitos compartilham parte do domínio da aplicação, como
alguns eventos e estados. Quando um evento compartilhado acontece, ele
acontece em ambos, quando um estado compartilhado muda de valor, ele muda
em ambos [Jackson 95].
2.2.3. Domínio
Um domínio é um conjunto de funcionalidades comuns entre múltiplos
sistemas [Simos 96]. 1
A engenharia de domínio tem como finalidade a criação de artefatos de
software para um conjunto de aplicações de um domínio. Ela trabalha na criação
de soluções genéricas que possam ser reutilizadas por todas as aplicações deste
domínio.
O foco da análise de domínio é o suporte para o reuso sistemático e em larga
escala, através da captura das características comuns e das variabilidades entre os
sistemas do domínio.
A análise de domínio também pode ser definida como uma forma de criar
uma boa infra-estrutura de reuso que permita a especificação e a implementação
de aplicações dentro de um escopo definido (o domínio) [Arango 94].
2.3. Elicitação de requisitos
Dentro da engenharia de requisitos cabe à elicitação a tarefa de identificar os
fatos que compõem os requisitos do sistema, de forma a prover o mais correto e
mais completo entendimento do que é demandado daquele software. A captura de
informações é um processo de descoberta que objetiva aumentar o conhecimento
do objeto em questão, buscando o máximo de informações possível. Para isso é
necessária uma habilidade para trabalhar com especialistas humanos e com o
conhecimento tácito, que é trivial para quem tem o conhecimento, mas não é para
1 Podemos notar que a definição de domínio de Jackson é diferente, pois ele define
domínio como o contexto em que a aplicação se encontra.
18
quem o procura, sendo dificilmente lembrado e, portanto, não transmitido
[Goguen 94].
Segundo [Leite 94] a seguinte citação é atribuída a Von Neumann. Na
citação ele deixa de forma clara a importância da tarefa de elicitar na definição de
requisitos:
“There is no sense in being precise about something when you do not even
know what you are talking about.”
Leite [Leite 94] chama de elicitação de requisitos às atividades que
envolvem a descoberta de requisitos de um sistema, como a identificação das
fontes de informação, coleta de fatos e comunicação.
Engenheiros e desenvolvedores de software trabalham diretamente com
clientes e usuários finais na tentativa de achar problemas a serem resolvidos,
serviços que o sistema deve prestar, requisitos de performance, restrições de
hardware e outros. Para isso não é necessário apenas perguntar para as pessoas o
que elas querem, requer uma análise muito mais cuidadosa da organização, do
domínio da aplicação e dos processos de negócios onde o sistema será usado.
O processo de engenharia de requisitos como um todo é muito mais
complexo do que apenas uma atividade de transferência de conhecimento entre
clientes e engenheiros de requisitos. Primeiro porque os clientes dificilmente têm
uma idéia clara do que realmente querem, e segundo porque diferentes pessoas
dentro da organização normalmente possuem requisitos conflitantes, além de
existir na maioria dos casos limitações tecnológicas influenciando os requisitos,
entre outros.
A principal atividade no processo de engenharia de requisitos é definir o que
os usuários realmente necessitam. Pesquisas mostram que grandes projetos falham
por causa de requisitos errados [Boehm 81], além disso, esse problema é
freqüentemente causado por fatores social, político e cultural.
Existem quatro dimensões na elicitação de requisitos [Sommerville 98]:
1. Entendimento do domínio da aplicação
Entender o domínio da aplicação é ter o conhecimento geral da área onde
o sistema é aplicado.
2. Entendimento do problema
É necessário entender os detalhes do problema específico do cliente onde
o sistema será aplicado.
19
3. Entendimento do negócio
Geralmente sistemas pretendem contribuir de alguma maneira para o
desenvolvimento de alguma organização ou negócio. É importante saber como o
sistema afeta e interage com as diferentes partes do negócio e como ele pode
contribuir para melhorar as expectativas do negócio.
4. Entendimento das necessidades e restrições dos interessados no sistema.
Os interessados no sistema são pessoas que de alguma maneira são
afetadas pelo sistema. Elas podem ser usuários finais, gerentes, entre outros. O
engenheiro de requisitos deve entender, em detalhes, as necessidades específicas
deste grupo, principalmente os processos de trabalho que o sistema pretende
suportar.
Uma vez a necessidade expressada e um plano inicial desenvolvido, a
equipe de requisitos tenta identificar quais propriedades o sistema deveria ter para
satisfazer tal necessidade.
Propriedades relevantes podem incluir não apenas requisitos de alto nível,
mas também tempo de resposta, segurança, portabilidade, confiança e
manutenibilidade.
Como já foi dito, a tarefa de elicitação de requisitos está longe de ser uma
tarefa fácil. Clientes podem mudar de idéia uma vez que vêem as possibilidades
mais claramente, e descobertas feitas em fases muito tardias tendem a encadear
uma volta para o aperfeiçoamento dos requisitos.
No contexto evolutivo é importante saber da impossibilidade da completeza
de um conjunto de requisitos. Este conceito foi definido em [Leite 01] da seguinte
forma:
“O processo de definir requisitos é inerentemente incompleto, tendo em
vista a grande complexidade do mundo real. É obvio, no entanto, que sempre
estaremos procurando ter requisitos os mais completos possíveis. A
impossibilidade da completeza está relacionada a afirmação de Brooks [Brooks
87] sobre a bala de prata e a característica de homeostasia dos sistemas, ou seja, a
característica evolutiva do software, que procura se adaptar ao seu macrosistema”.
É compreensível o motivo pelo qual os clientes freqüentemente não sabem
exatamente o que necessitam. Isso pode ocorrer entre outros motivos, por uma
necessidade de ver modelos, explorar alternativas e prever novas possibilidades,
20
atividades realizadas junto aos engenheiros de requisito. Freqüentemente estas
possibilidades são mescladas com fatores sociais, políticos, legais, financeiros, e
psicológicos [Goguem 93].
Infelizmente um projeto pode vir a falhar porque nenhum sistema pode ser
construído que satisfaça os requisitos solicitados, ou porque os requisitos
acordados não refletem as necessidades reais [Goguem 93]. A Engenharia de
requisitos tem como principal meta evitar tais problemas, o que freqüentemente
envolve significantes esforços na tarefa de elicitação de requisitos.
A seguir descreveremos como chegar às fontes de informação, apontaremos
uma série de técnicas utilizadas para coletar os fatos do universo de informação
(UdI), que são a base para descrever os requisitos do software, e também
descrevemos técnicas que devem ser utilizadas na comunicação com os atores do
UdI.
2.3.1. Identificação das fontes de informação
Segundo Leite [Leite 94], o primeiro passo para identificação das fontes de
informação é descobrir qual é o nosso Universo de Informações, que é o contexto
no qual o software deverá ser desenvolvido e operado. Dele extrairemos as
informações necessárias na tarefa de elicitação. A perfeita delineação desse
universo é função do macrosistema ao qual o software vai servir. O UdI contem
todas as fontes de informação e todas as pessoas relacionadas com o software,
também conhecidas como atores deste universo.
Em [Leite 94] é citado o trabalho de Burstin como uma técnica para
identificar fontes de informação. Ele criou uma serie de heurísticas para
identificar atores e compor árvores desses atores. Basicamente, com o seu método,
ele consegue mapear os atores de uma forma abstrata segundo uma hierarquia, na
qual os atores que têm necessidades mais concretas aparecem nas folhas da
árvore. Podemos visualizar melhor esta técnica através da Figura 1 tirada de [Leite
94].
21
Figura 1 – Árvore abstrata de usuários [Leite 94].
Além de atores, outras importantes fontes de informação podem ser:
documentos do UdI, livros sobre temas relacionados, outros sistemas já existentes
na empresa e outros sistemas já existentes no mercado.
2.3.2. Coleta de fatos
Requisitos de software são sentenças que expressam as necessidades dos
clientes e que determinam a qualidade do software. Eles podem ser classificados
como: requisitos funcionais, que estão diretamente ligados a funcionalidade do
software; e não funcionais, que expressam restrições que o software deve atender
ou qualidade específicas que o software deve ter [Leite 01].
Desta forma, os critérios de qualidade que o software deverá ter é definido
através dos requisitos não funcionais. É freqüente o problema do não tratamento
dos aspectos relacionados a qualidade do produto no inicio do processo de
produção do software [Cysneiros 99] [Chung 00]. A estratégia de tratar a
qualidade no próprio processo de definição do software integra de maneira
coerente aspectos funcionais e não funcionais, podendo em um nível mais alto
22
trabalhar opções de solução que ficavam escondidas em muitos casos até a etapa
de programação [Leite 01].
Para realizar a tarefa de elicitação dos requisitos, o engenheiro de requisitos
pode necessitar usar diferentes técnicas para descobrir as informações necessárias
para o entendimento do domínio da aplicação e do problema. A maior parte do
conhecimento na elicitação dos requisitos vem da leitura de documentos sobre o
sistema e de conversas (entrevistas) com pessoas que estão envolvidas com o
sistema como usuários, gerentes, e outros. Isto resulta em um grande volume de
informação que deve ser organizada para torná-lo compreensível.
Existem várias técnicas de coleta de fatos como leitura de documentos,
observação, entrevistas, questionários, análise de protocolo, participação ativa dos
atores do UdI, enfoque antropológico, reuniões, reutilização, recuperação do
desenho de software, entre outras. Neste trabalho discutiremos mais
detalhadamente de duas delas: questionários e reuniões.
2.3.2.1. Reuniões
Realizar uma reunião é uma técnica que prevê a participação coletiva dos
envolvidos, sendo uma maneira mais efetiva de negociar requisitos e resolver seus
problemas. Elas têm a vantagem de permitir uma interação mais natural entre
pessoas, do que as entrevistas estruturadas e até mesmo as não estruturadas e
dispor de múltiplas visões sobre a questão abordada. Seu produto final é um
documento que contem definições do software.
Reuniões são práticas bem conhecidas de negociação de requisitos, que
promovem a cooperação, entendimento e formação de equipes de trabalho entre
os envolvidos no universo de informação. Os participantes da reunião devem ser
o engenheiro de requisitos que identificou algum problema nos requisitos e os
interessados no sistema que podem ajudar a resolver os problemas identificados. É
importante chamar pessoas de diferentes culturas e perspectivas para trazerem
diferentes habilidades, conhecimentos de domínio e experiência para a reunião.
Como resultado, os desenvolvedores aumentam seus conhecimentos sobre o
domínio da aplicação e os usuários tornam-se mais envolvidos no processo de
desenvolvimento.
23
A reunião como outras técnicas de elicitação tem que lidar com o problema
do conhecimento tácito. Durante a reunião o engenheiro de requisitos deve
explicitar cada problema encontrado nos requisitos e todos os interessados devem
ter a oportunidade de comentar. Porém certamente os participantes serão
incapazes de lidar com o conhecimento tácito. Mesmo com a ajuda de
facilitadores não existe garantia que os participantes irão compartilhar
conhecimentos com os outros. Além disso, podem existir na reunião participantes
com hierarquias diferentes dentro da empresa, correndo o risco de alguns não se
sentirem com liberdade pra dizer o que realmente pensam [Goguem 93].
Em uma reunião é também uma boa oportunidade para dar prioridades aos
requisitos e decidir qual requisito pode ser eliminado e quais devem ser incluídos
na especificação final do sistema.
Podemos classificar reuniões com base na maneira como elas são
organizadas, podendo ser apenas uma extensão do conceito de entrevista ou como
uma maneira de se ter a participação ativa dos atores do UdI. Técnicas de
brainstorm podem ser utilizadas para a fase de exploração dos requisitos. Já
métodos como JAD (Joint Application Design) [Andrews 91] são utilizados mais
na fase de especificação de requisitos, por ser um método que estrutura a reunião
com o objetivo de conseguir um clima de cooperação, utilizando representações
de Engenharia de Software.
Segundo Leite [Leite 94], as principais vantagens da utilização de reuniões
são a possibilidade de se dispor de múltiplas opiniões e da criação coletiva. Porém
existem algumas desvantagens que são a possibilidade de dispersão e o custo.
Vamos voltar a tratar com mais detalhes sobre reuniões na seção 2.6.
2.3.2.2. Questionários
Os questionários são mais utilizados quando é preciso ter acesso a um
grande número de pessoas. São importantes na tentativa de compreender melhor
como as pessoas percebem certos aspectos do universo de informação do
software.
Segundo Leite [Leite 94], as principais vantagens da utilização de
questionário são a padronização das perguntas e a possibilidade de tratamento
24
estatístico das respostas. A limitação do universo de respostas e a pouca interação,
visto a impessoalidade da técnica, ficam entre as principais desvantagens.
2.3.3. Comunicação
A comunicação eficiente entre clientes e engenheiros de requisitos é de
extrema importância para o sucesso da atividade de elicitação. A existência de
culturas diferentes entre clientes e engenheiros de software gerando diferentes
conhecimentos por parte de cada um é um problema de difícil resolução [Leite
94].
Problemas na elicitação de requisitos são naturais e inevitáveis, pois eles
refletem o fato que diferentes envolvidos no sistema tem diferentes necessidades e
prioridades. Se não forem realizadas negociações abertas e explícitas, alguns
interessados podem ficar decepcionados e hostis com o sistema.
O uso de técnicas de comunicação aumenta a possibilidade de uma
comunicação mais clara e efetiva entre as partes. Apesar da ênfase dada a
linguagem verbal é também importante nos preocuparmos com o uso da
linguagem escrita, principalmente quando usamos a linguagem natural.
2.4. Análise de requisitos
Nós discutimos a análise como se fosse uma atividade separada que segue a
elicitação. Porém, na realidade, eles são processos interligados. Durante o
processo de elicitação os problemas podem ser imediatamente reconhecidos,
discutidos e resolvidos.
A análise e a negociação de requisitos têm o objetivo de estabelecer um
acordo para a conclusão de um conjunto de requisitos o mais completo e
consistente possível. Durante o processo de análise são identificados requisitos
esquecidos, ambíguos, sobrepostos, conflitantes e não realistas. Se existe algum
desses problemas com os requisitos, os interessados no sistema devem negociar e
acordar modificações e /ou simplificações para eles.
As negociações dificilmente utilizam apenas argumentos lógicos e técnicos,
pois também são influenciadas por considerações organizacionais e políticas e
pela personalidade das pessoas envolvidas. Por exemplo, uma forte personalidade
25
pode forçar que suas prioridades prevaleçam em cima das dos demais, requisitos
podem ser aceitos ou rejeitados por fortalecerem as influências políticas de alguns
dentro da organização, usuários finais podem estar resistentes a mudanças e por
isso bloquear requisitos, etc.
A tarefa de análise de requisitos pode ser divida em: identificação de
partes, verificação e validação [Leite 94]. Porém, existe um grande problema
nesta divisão, que é como separar exatamente o que vem a ser verificação e o que
vem a ser validação.
As atividades de validação e verificação têm muito em comum. Na primeira
julgamos se os requisitos estão com as descrições feitas apropriadamente às
necessidades dos interessados e a outra verifica problemas nos requisitos. Porém
existem importantes diferenças para considerarmos elas separadamente.
O foco durante a verificação dos requisitos deve ser mais relacionado com a
maneira que os requisitos são descritos. O objetivo é verificar a consistência,
completeza e precisão no documento de requisitos.
Enquanto que o processo de validação deve garantir que os requisitos
reflitam as necessidades dos interessados ao invés dos detalhes da sua descrição.
A atividade de validação, no contexto da engenharia de requisitos, consiste
na execução de ações com o objetivo de confirmar o conhecimento adquirido.
Procura-se analisar se o que foi especificado realmente representa as necessidades
do cliente.
Se não ocorre o processo de validação e o desenvolvimento começa muito
cedo, alguns reparos podem ser inevitáveis. Como conseqüência de erros nos
requisitos, os erros identificados na fase de programação podem custar 100 vezes
mais para reparar [Sommerville 98]. Ocorre uma redução importante do re-
trabalho, se estes erros e problemas são descobertos durante a validação dos
requisitos [Sommerville 98].
Uma maneira de imaginar os processos de elicitação, análise e negociação
de requisitos são como segmentos em uma espiral, como mostra a figura 2 retirada
de [Sommerville 98], que foi inspirada no trabalho de [Boehm 88] sobre
desenvolvimento de software.
Primeiro o engenheiro de requisitos descobre alguma informação sobre os
requisitos. É feita uma análise, posteriormente uma negociação e então outro giro
da espiral começa.
26
Figura 2 – O espiral da elicitação, análise e negociação
2.5. Principais problemas na elicitação de requisitos
Segundo [Curtis et al 88] os principais problemas na elicitação de requisitos
são o conhecimento parcial ou incompleto do domínio da aplicação, requisitos
oscilantes e conflitantes e falhas na coordenação e comunicação de atividades.
A seguir vamos explicar um pouco mais sobre cada um destes problemas.
2.5.1. Conhecimento parcial ou incompleto do domínio da aplicação
Mesmo que cada membro da equipe de elicitação de requisitos compreenda
individualmente o domínio de uma aplicação, deve haver uma integração dos
pontos de vista e uma difusão do conhecimento pelos demais participantes do
projeto, porém isso normalmente não ocorre.
Não importa quanto um engenheiro de software sabe sobre técnicas de
análise e programação, ele é um principiante no domínio da aplicação do negócio
em questão.
Para construir um modelo do domínio que reflita um consenso entre os
participantes devemos integrar os seus pontos de vista, que podem diferir no
comportamento externo do sistema, no contexto onde o domínio está inserido ou
27
na representação mais apropriada do sistema. Um modelo integrado normalmente
é uma solução mais completa e criativa do que cada solução individual.
Outro problema que causa uma informação parcial do domínio da aplicação
e também é bastante freqüente, é a resistência apresentada por muitos usuários em
compartilhar a informação necessária com o engenheiro de requisitos. Existe uma
associação de poder e informação que geram nas pessoas um receio em
compartilhar a informação para não perder poder [Mathias 94], seja para não
perder o emprego ou mesmo para obter vantagens na organização.
2.5.2. Requisitos oscilantes e conflitantes
Requisitos oscilantes são os que variam com o tempo devido às alterações
externas à empresa (como mudanças na política econômica do país) ou devido a
modificações estruturais internas (reestruturação da empresa ou corte de despesas)
[Mathias 94].
Requisitos conflitantes são os que possuem inconsistência entre si e que
precisam da utilização de técnicas de resolução de conflitos para integrá-los
[Mathias 94].
Estes problemas são causados porque diferentes atores possuem diferentes
pontos de vista e como normalmente requisitos são definidos com entrevistas
individuais com os usuários, estes problemas se agravam. Dessa forma os
requisitos levantados por um usuário que foi entrevistado mais tarde podem
conflitar com os elicitados por outros anteriormente, necessitando assim de
métodos integrativos para produzir uma solução global para todos.
Diversas podem ser as causas dos requisitos oscilantes, por exemplo, o
usuário durante o processo de elicitação pode acabar aprendendo ou recordando
detalhes do universo de informação, apresentando e alterando idéias já levantadas.
Outro motivo pode ser a ausência de objetivos bem definidos para o sistema.
2.5.3. Falhas na comunicação e coordenação das atividades
Muitos engenheiros de software durante a elicitação de requisitos não
utilizam documentação formal, confiando na memória e em algumas anotações
em rascunho, gerando uma documentação deficiente do sistema [Rosson et al 88].
28
Outro problema de comunicação é a falta de divulgação de algumas
informações por desejo de obtenção de vantagens políticas, por necessidades de
manter sigilo sobre partes do projeto, ou até mesmo por acharem elas
desnecessárias. Isso influencia muito nos requisitos do sistema já que os
engenheiros de requisitos ficam sem acesso ou tem o acesso tardio a algumas
informações.
Muitos engenheiros de requisitos preferem trabalhar sozinhos e
desenvolverem sistemas através de suas próprias idéias em vez de trabalhar em
conjunto com o usuário. O que acarreta em um sistema que irá satisfazer as
vontades do engenheiro, não do usuário. Portanto, o ideal é que o contato entre
eles seja constante e direto.
O modelo de precisão, proposto por [McMaster, Grinder 80], utiliza
técnicas de comunicação para facilitar a tarefa de elicitação de requisitos. As
reuniões entre engenheiros de software e clientes são os principais focos desse
modelo, que tenta compreender os processos de comunicação e de aquisição do
conhecimento.
2.6. A reunião segundo o método de [Mathias 94]
Como já foi dito, o método que estudamos nesta dissertação se baseia em
um ciclo de reuniões de elicitação de requisitos apoiada pelo gerenciamento de
conflitos, que tenta atuar nos problemas que listamos acima.
Falaremos nesta seção sobre conflitos, causas e métodos de resolução para
facilitar o gerenciamento de conflitos, pois, muitas vezes, eles permanecem sem
solução por desconhecimento das causas e técnicas adequadas.
Primeiro descreveremos o conceito de conflito, depois citaremos suas
principais causas e logo a seguir as melhores técnicas para solucionar cada tipo de
conflito existente. No final mostraremos um pouco de como o conflito tem sido
tratado na atividade de elicitação de requisitos.
Um dos principais objetivos desta seção é mostrar que existe um tipo de
conflito que deve ser estimulado e trabalhado como um importante trunfo para a
aquisição do conhecimento.
29
2.6.1. O que é Conflito
Pode se chamar de conflito qualquer tipo de oposição ou interação
antagônica originada por diversos motivos, tais como estruturas de valores
diferentes, recursos ou posição social e disputa de poder [Robbins 74].
Na literatura sobre conflitos um dos pontos mais importantes é a distinção
feita entre conflito funcional e conflito não funcional. Segundo [Robbins 74], o
conflito funcional é aquele que o confronto beneficia ou auxilia nos objetivos da
organização. Qualquer outro tipo de conflito que não se encaixe nesta definição
não é um conflito desejável, deve ser tratado e eliminado, já que não objetiva
trazer benefício para a organização, no máximo, para interesses individuais.
O conflito funcional estimula o interesse e a curiosidade, impede a
estagnação, ajudando a realizar boas mudanças sociais e pessoais. Realizando a
direta expressão de idéias opostas, os sistemas sociais reajustam suas estruturas,
eliminando as fontes de insatisfação [Mathias 94].
É muito comum ocorrer a intolerância ao conflito na sociedade atual, pois a
educação que nossos pais nos ensinam é que devemos nos relacionar bem uns com
os outros, evitando qualquer tipo de confronto. Como por exemplo, discussões
com colegas da escola ou com os próprios irmãos. Também podemos citar como
exemplo algumas escolas da sociologia, onde o conflito é enxergado como o
desequilíbrio de forças do sistema social que deveria estar em repouso, isto é,
equilibrado quanto às forças que o compõem [Wikipedia 05]. Desta forma,
encaramos o conflito como algo sempre negativo que deve ser eliminado,
esquecendo e reprimindo os conflitos positivos, ou seja, os funcionais. Porém
devemos compreender que através da aceitação da existência do “bom conflito”
(conflito funcional) e do estudo deste, podemos evitar problemas destrutivos,
oferecer um grande número de idéias a partir do dinamismo gerado em busca de
soluções e estimular a percepção.
Segundo uma filosofia que reflete atitudes perante o conflito, chamada de
interacionista [Robbins 74], o benefício do conflito deve ser reconhecido e
encorajado. Ela define o gerenciamento de conflitos como uma técnica que
combina as técnicas de estímulo e resolução dos mesmos. Pela visão interacionista
existe uma quantidade ideal de conflito, necessitando de métodos de resolução
30
quando está alto demais ou de estímulo por técnicas adequadas quando está muito
baixo.
A filosofia interacionista acredita que as organizações devem estimular o
conflito para não sofrerem por causa de pensamentos estagnados, decisões
inadequadas e desmotivação, pois as boas mudanças acontecem a partir da
insatisfação, da vontade de progredir e do desenvolvimento de alternativas
criativas.
2.6.2. Causas do Conflito
Segundo [Robbins 74], o conflito pode ser causado por três motivos: fatores
de comunicação, estruturais e de comportamento pessoal.
2.6.2.1. Fatores de comunicação
A retroalimentação, que é a etapa em que o receptor se torna emissor e
transmite o que compreendeu da mensagem, é uma atividade importante para
verificar se o receptor entendeu o que foi passado. Porém ela não é garantia de
sucesso na comunicação, pois como o receptor se torna um emissor, ele fica
sujeito aos mesmos problemas do emissor original.
Problemas na comunicação podem ser causados porque a mensagem teve
que passar por vários intermediários até alcançar o receptor final ou por ruídos no
canal de comunicação. Alguns comportamentos do receptor como a desatenção,
avaliação prematura da mensagem, a interrupção do interlocutor ou a existência
de um antagonismo entre eles, também podem causar problemas na comunicação.
2.6.2.2. Fatores estruturais
Estes conflitos são aqueles causados por questões relacionadas à própria
estrutura da organização.
Segundo [Mathias 94], Katz distingue três tipos de conflitos com causas
estruturais:
• Conflito causado pela existência de vários subsistemas dentro da
organização.
31
Tipos distintos de orientação, para fora ou para dentro da organização,
são fonte potencial de conflito, pois normalmente suas normas e padrões
de referência entram em choque.
• Disputas internas entre unidades dentro de uma organização.
Organizações grandes normalmente contêm duas ou mais unidades com
funções parecidas, o que pode, em muitos casos, causar conflitos não
funcionais em busca de um maior destaque na organização.
• Conflito hierárquico por recompensas organizacionais.
Em uma organização comum é inevitável que indivíduos em cargos
diferentes recebam diferentes salários. Esta distinção de remuneração
pode gerar conflitos com o objetivo de obter mais poder, prestígio e
vantagens e também dificultar eventuais alterações na estrutura
organizacional, por parte de alguns resistentes a mudanças.
2.6.2.3. Fatores pessoais
Podemos citar valores e pensamentos diferentes entre duas ou mais pessoas,
fatores pessoais causadores de conflito, pois cada um tem o interesse que o seu
valor ou pensamento seja o dominante.
Por exemplo, pessoas de personalidade agressiva ou dominadora podem
causar conflitos não funcionais ao tentar dominar outros participantes. Já pessoas
extremamente tímidas ou resistentes a mudanças podem dificultar o trabalho
cooperativo, reduzindo a qualidade dos resultados de um trabalho em equipe.
Os membros de uma equipe podem ter personalidades diferentes, porém eles
têm que saber trabalhar em grupo, ouvir com atenção, ser firme sem magoar,
evitando assim reações emocionais prejudiciais. Desta forma conflitos
interpessoais não funcionais certamente serão menos freqüentes.
32
2.6.3. Técnicas de resolução de conflitos
Nesta seção abordaremos as principais técnicas de resolução de conflitos e
suas características. Ao apresentar cada técnica, iremos comentar qual forma de
conflito melhor seria resolvido com ela.
2.6.3.1. Negociação
A negociação tenta solucionar o conflito através da análise de todas as
possibilidades existentes, na tentativa de descobrir uma solução que satisfaça a
todos a medida do possível.
Esta técnica é indicada quando existe um relacionamento satisfatório entre
os participantes, permitindo uma comunicação aberta. É uma técnica das mais
democráticas, mas pode demorar muito para atingir solução, pelos inúmeros
impasses que podem ocorrer durante a negociação.
2.6.3.2. Técnicas com um participante externo
Quando os participantes não conseguem sozinhos resolverem o conflito é
necessário então o auxílio de uma fonte externa, que agirá com coerção sobre os
participantes com o objetivo de chegar a uma solução.
O profissional ou pessoa atribuída para ser o participante externo deve ter
algumas qualidades como elevada competência profissional em relação a
processos sociais, bom conhecimento dos indivíduos envolvidos no conflito e
saber manter a neutralidade para facilitar o desenvolvimento da confiança pelos
participantes [Mathias 94].
Esta técnica é bastante indicada, desde que o mediador atenda aos requisitos
citados anteriormente, pois como ele é imparcial tem mais facilidade para
enxergar soluções mais eficientes, já que analisa objetivamente o problema.
2.6.3.3. Esclarecimento do problema
Os participantes, de forma cooperada, buscam toda a gama de alternativas e
similaridades nos seus pontos de vista. Para desta forma, tentar entender o motivo
33
das dúvidas e mal entendidos que estão sendo gerados, tornando possível a
resolução através do melhor conhecimento do contexto onde o conflito se
encontra [Robbins 74].
Por se tratar de uma técnica que prioriza a comunicação, ela é altamente
recomendável mesmo se as relações entre os envolvidos não for muito boa. Pois é
possível durante o processo, que surja compreensão entre os participantes ou até
que seja percebido que o conflito não passou de um mal entendido.
2.6.3.4. Expansão e substituição de recursos
Quando o problema for falta de algum recurso, ele é resolvido simplesmente
aumentando o seu número. Porém dependendo do recurso escasso esta solução
pode se tornar bastante cara ou, dependendo do caso, inviável.
Se a expansão for impossível pode ser tentada a substituição do recurso
escasso por outro com características similares, mas corre-se o risco do recurso
similar não ser aceito pelo grupo.
Esta técnica pode ser empregada também para o caso de um conflito gerado
pela baixa qualidade de um recurso. Neste caso a chance de sucesso é muito
maior, considerando que o novo recurso satisfaça os quesitos de qualidade
desejados pelos envolvidos.
2.6.3.5. Votação
Esta é uma técnica bem simples onde cada pessoa envolvida deve
manifestar de forma aberta ou secreta sua opção. Após todos os votos apurados a
opção da maioria é adotada.
Esta técnica tem um ponto negativo, pois raramente satisfaz a todos. Ela só
deve ser aplicada após o insucesso na tentativa de outros métodos, como a
negociação, por exemplo.
2.6.3.6. Alteração da variável humana
Apesar de ser uma técnica lenta e cara, é recompensada pelos seus
resultados significativos, pois atua na causa do problema [Robbins 74]. Ela visa
34
alterar o comportamento de uma ou mais pessoas envolvidas no conflito. Por isso
ela é mais eficiente quando aplicada em conflitos devido a fatores pessoais.
2.6.3.7. Alteração de variáveis estruturais
Através de alguma alteração na estrutura da organização esta técnica tenta
tratar principalmente os conflitos relacionados com causas estruturais, como
alteração de normas vigentes, transferência de membros para outros
departamentos, etc. Para maior eficiência, esta técnica deve ser realizada por uma
pessoa com bom conhecimento da organização.
2.6.4. O conflito na elicitação de requisitos
O conflito está presente em todas as áreas que o homem atua. Aqui,
destacaremos a sua importância na área de Informática, mais especificamente, na
área de Elicitação de Requisitos.
No desenvolvimento de um sistema, surgem boas idéias por parte de cada
participante no processo de aquisição de conhecimento. Porém estas idéias na
maioria das vezes não se encaixam perfeitamente, deixam lacunas ou se
sobrepõem em algumas partes, o que é normal.
Existem alguns conceitos que justamente visam ajudar neste processo de
aquisição de conhecimento. Um deles é o conceito de pontos de vista, que trata
das características particulares de cada pessoa. Segundo [Mathias 94], Nygaard
diz que elas influenciam os aspectos que parecem relevantes a cada um, o que
resulta em distintas conclusões sobre o mesmo tema. Desta forma, na tentativa de
adquirir um conhecimento mais profundo podemos elaborar, comparar e combinar
visões da mesma área de interesse a partir de diferentes ângulos [Leite 88].
Acredita-se [Mathias 94] que é importante dar mais atenção às relações
contraditórias em uma organização com o objetivo de serem usadas como
importante fonte de aquisição de conhecimento. Ao contrário das metodologias
tradicionais, que sempre pregaram os conflitos como problemáticos, eles devem
ser inseridos como parte integrante do desenvolvimento de sistemas. Sendo
utilizado como uma alternativa para surgimento de novas idéias, ajudando a obter
requisitos de melhor qualidade e mais adequados à organização. Um ótimo
35
exemplo é a técnica de reuniões conhecida como brainstorming, essa técnica é
usada basicamente para maximizar a geração de idéias provenientes de um grupo
de pessoas, sem nenhuma preocupação crítica, até que se esgotem as
possibilidades.
3 – O método
Através da gerência de conflitos, que estimula os conflitos funcionais e
controla e trata os não funcionais, buscamos a geração de novas idéias e o
dinamismo de reuniões, ao mesmo tempo em que tratamos problemas que não
objetivam trazer benefícios para a organização.
Este método, proposto por [Mathias 94] em sua dissertação de mestrado,
baseia-se na realização de reuniões cuidadosamente planejadas, visando produzir
uma lista de requisitos com base nos objetivos do sistema. O resultado da reunião
é analisado através de um questionário respondido por todos os participantes.
Com base nas respostas do questionário, é gerada uma lista de observações que
ajudam o gerenciamento de conflitos numa reunião subsequente.
O principal objetivo da utilização do questionário é adquirir informações
dos participantes após a reunião, visando detectar e posteriormente gerenciar
conflitos. É de fundamental importância que todos os participantes respondam o
questionário, pois a base do método está na consideração dos pontos de vista de
todos os indivíduos que estavam presentes na reunião.
Figura 3 – O fluxograma do método2
2 As atividades sinalizadas com dois retângulos são as automatizadas pela ferramenta de
apoio ao método.
37
A seguir faremos um resumo das etapas que fazem parte do processo de
aplicação do método. Ao final de cada etapa apresentamos todas as evoluções
realizadas no método proposto [Mathias 94] e sugerimos algumas idéias para
serem inseridas no seu processo.
3.1. O planejamento da reunião
Segundo [Mathias 94], a fase de planejamento é a mais crítica, já que falhas
ocorridas nesta etapa são as causas de muitos problemas surgidos na fase de
execução.
A reunião deve ter um planejador, que deve ser um dos interessados no
sistema. O planejador escolhido para a reunião deve ficar atento aos seguintes
fatores [Mathias 94]:
1. Definir bem os objetivos da reunião;
2. Escolher os participantes, com interesse na reunião, levando em
conta fatores pessoais importantes, como facilidade de
relacionamento interpessoal, espírito cooperativo, boa capacidade de
expressão, entre outros.
3. Escolher o líder da reunião baseado nas características descritas em
2.6.3.2, onde aborda a intervenção de um conflito por um
participante externo;
4. Selecionar o local da reunião, lembrando que na evolução do método
proposto nesta dissertação permitimos a realização de reuniões de
maneira não presencial;
5. Disponibilizar todo o material necessário para a reunião;
6. Marcar uma data que todos os participantes estejam de acordo, para
evitar pressa e conseqüentemente decisões precipitadas.
Nós avaliamos ser importante também preparar para entregar aos
participantes da próxima reunião, uma ata com as principais decisões tomadas na
reunião anterior e principalmente uma lista com os requisitos do sistema já
elicitados até o momento.
38
Outra idéia que acreditamos ser de fundamental importância é a realização
de um “workshop” para os interessados no sistema a ser desenvolvido, explicando
os objetivos do método e as principais funcionalidades da ferramenta de apoio que
será usada pelos planejadores, líderes e participantes das reuniões. Esta pequena
apresentação deverá ser realizada principalmente quando for a primeira vez que
estiver sendo utilizado o método, juntamente com a ferramenta de apoio, pela
organização.
3.2. Gerenciando os conflitos
A ocorrência de conflitos em uma reunião é detectada pelo método
estabelecendo a intensidade mínima e máxima desejada de cada um, na análise do
questionário. Para o caso de conflitos funcionais existe uma intensidade mínima
desejada. Caso seu valor se encontre abaixo, indica a necessidade do uso de
técnicas adequadas de estímulo ao conflito. Já quando o nível de conflito não
funcional estiver acima do estabelecido, devem ser tomadas atitudes para que o
nível baixe ao ponto aceitável para a obtenção de requisitos de qualidade.
Para dar suporte a este controle, um questionário foi elaborado por [Mathias
94] com o objetivo de identificar os conflitos ocorridos durante a reunião e sugerir
as principais técnicas de estímulo e de resolução de acordo com cada tipo de
conflito identificado.
Neste trabalho, revimos cada pergunta presente no questionário original,
avaliando todos os componentes de cada questão, além de sua objetividade e
clareza. Na seção 3.4, relataremos todos os detalhes do processo de evolução do
questionário.
Criamos ainda uma ferramenta para apoiar o método de gerenciamento dos
conflitos, analisando as respostas de cada participante, para identificar os conflitos
e apontar as melhores técnicas para o seu tratamento de acordo com suas causas.
Com a disponibilidade e facilidade das tecnologias Web, o método de apoio
a reuniões passa a ser mais interativo. Desenvolvemos a nova ferramenta de apoio
em PHP, HTML e Javascript. Utilizamos o MySQL como gerenciador da base de
dados e o Apache como servidor Web, caracterizando a nova ferramenta como
uma aplicação de 3 camadas.
39
Desta forma, pretendemos além de torná-la uma ferramenta acessível em
qualquer parte do mundo, inseri-la também na comunidade de informática como
software livre.
Além disso, a tarefa de identificação dos conflitos agora é realizada por um
sistema especialista integrado à ferramenta de apoio, desenvolvido através do
software CLIPS que, entre outras vantagens trazidas, permitiu modularizar a
descrição das regras de detecção de conflitos. No capítulo 4 falaremos mais
detalhadamente sobre a nova ferramenta de apoio e a criação do sistema
especialista.
3.3. A tomada de decisões
O método, a partir das técnicas de gerenciamento de conflito, sugere
algumas decisões para serem tomadas de acordo com o conflito detectado. Certas
decisões devem ser tomadas pelo planejador, principalmente as que dizem
respeito ao líder da reunião. No entanto, a maior parte das decisões devem ser
tomada pelo líder.
O objetivo de tomar estas decisões é de estimular determinados conflitos
funcionais que não ocorreram na reunião anterior ou pela necessidade de resolver
conflitos não funcionais identificados pela ferramenta de apoio [Mathias 94].
Com a experiência adquirida estudando e desenvolvendo trabalhos práticos
com o método, percebemos que o uso de um quadro para apoiar o andamento da
reunião motiva mais a participação dos presentes. Principalmente quando o líder
está tentando resolver conflitos surgidos nos requisitos, mostrando ser uma boa
idéia ir escrevendo no quadro o requisito a ser trabalhado e o conflito identificado
nele.
O ciclo de reuniões deve ser encerrado quando não se julgar mais necessário
levantar novas funcionalidade e não forem mais detectados conflitos que possam
prejudicar as demais etapas do processo de desenvolvimento do sistema, ou seja,
quando não houver mais conflitos nas “questões vitais” [Mathias 94].
Na próxima seção, apresentaremos a evolução do questionário do método.
40
3.4. O questionário
Nesta seção explicamos melhor a importância da utilização do questionário
para o método, apresentamos o novo questionário e logo após explicamos
detalhadamente todas as mudanças realizadas no questionário original [Mathias
94].
3.4.1. Motivação
O principal objetivo da utilização do questionário é adquirir informações
dos participantes após a reunião, visando obter uma forma de detectar e
posteriormente gerenciar os conflitos funcionais e não funcionais que podem
surgir durante uma reunião. É muito importante que todos os membros da reunião,
inclusive o líder, respondam ao questionário, pois a base do método está na
consideração de todos os pontos de vista presentes na reunião.
A partir de um estudo feito em cima das questões do questionário proposto
[Mathias 94] e de bibliografias relacionadas com a elicitação de requisitos, foi
identificada a necessidade de haver uma reformulação no conjunto de questões
que compunham o questionário. Como acreditamos ser esta atividade uma das
mais importantes do processo de evolução do método, iremos detalhá-la a seguir:
A primeira constatação foi relacionada ao grande número de perguntas, e
como essa quantidade de perguntas seria aceita pelos usuários do sistema. O
primeiro e principal objetivo da revisão do questionário, foi então tentar diminuir
ao máximo o número de perguntas sem, é claro, prejudicar a observação de algum
aspecto importante das reuniões. No decorrer desta tarefa, começamos a detectar
questões bastante semelhantes, onde seus objetivos eram bem parecidos, muitas
vezes podíamos dizer que até idênticos. Ou seja, o conflito que se queria observar
era o mesmo entre as questões, o que nos mostrou uma nova necessidade, que
complementava a anterior. Encontrar questões com objetivos e gerenciamento
semelhantes, onde fosse possível uma reformulação das questões transformando-
as em uma, ou a escolha de uma entre as semelhantes, permitiria a conseqüente
diminuição destas. Neste mesmo aspecto, ocorria também o caso do objetivo de
uma questão já ter sido conquistado, com a combinação de duas ou mais outras,
sendo aquela descartada.
41
Apesar dos descartes e combinações de perguntas com objetivos
semelhantes, mantivemos perguntas de controle.
Um fator importante que levamos em consideração no estudo das questões
do questionário foi que este agora deverá ser usado também para dar apoio aos
problemas da elicitação de requisitos no ambiente de desenvolvimento distribuído
de software, preocupação que não existia na primeira versão do formulário. Neste
existiam perguntas específicas sobre o ambiente em que a reunião está sendo
realizada, como, perguntas analisando a acústica, temperatura, iluminação,
características impossíveis de se analisar em reuniões realizadas de forma não
presencial. Dessa forma, estas perguntas foram substituídas por uma que analisa
em um contexto genérico a maneira que a reunião foi realizada.
Durante este estudo foram encontradas necessidades de mudança em
questões que estavam com sua descrição ambígua e questões em que faltava a
análise de outras hipóteses da ocorrência de conflito. Além disso o novo
questionário, por motivo das alterações realizadas, apresenta uma nova numeração
e uma nova divisão das perguntas em grupos, que serão apresentados na seção
3.4.2.
No questionário original as perguntas tinham a finalidade de identificar a
ocorrência de conflitos não funcionais e funcionais, para evitar os não funcionais e
continuar estimulando os funcionais detectados. Porém, durante o estudo achamos
mais conveniente, ao invés disso, que as perguntas identificassem a ocorrência de
conflitos não funcionais e a ausência de funcionais. A ausência de um conflito
funcional pode ser identificada através da falta de discussão de determinado
assunto durante reunião, como podemos observar nas perguntas 11, 21 e 26 que
tentam detectar estes problemas. Desta maneira, podemos tratar os conflitos não
funcionais e estimular os conflitos funcionais que não estão ocorrendo. Ou seja,
achamos mais interessante identificar a ausência de conflitos funcionais para
então estimulá-los, do que apenas tomar consciência dos funcionais que estão
ocorrendo e realizar um trabalho de manutenção.
Desta forma, o novo questionário contém 38 perguntas obtidas a partir do
questionário proposto [Mathias 94], onde uma grande parte destas sofreu
modificações e uma pergunta nova foi criada. Somando um total de 39 perguntas,
25 a menos do que o número original.
42
Um melhor detalhamento da explicação da retirada ou reformulação das
questões será apresentado na Seção 3.4.3.
As perguntas do questionário devem ser respondidas apenas colocando o
grau de intensidade que o fato analisado pela pergunta ocorreu, este grau varia
entre 1 e 5 e devem ser dados por cada participante ao final de cada pergunta. A
intensidade dos graus é descrita da seguinte forma:
1- extremamente baixa;
2- um pouco baixa;
3- neutra;
4- um pouco alta
5- extremamente alta
As perguntas podem ser de dois tipos:
- absolutas: são perguntas que, se identificarem conflito, possuem causas
pré-determinadas, sem haver necessidade de fazer correlação com respostas de
outras perguntas para descobrir as causas do conflito.
- relativas: são perguntas que, caso ela identifique conflito, suas causas são
determinadas dependendo do relacionamento de causa e efeito com outras
perguntas. Normalmente existem várias causas associadas a essas questões. Elas
também se caracterizam por serem perguntas que, na maioria dos casos,
apresentam mais de uma hipótese para justificar a ocorrência do conflito
identificado pela pergunta.
As perguntas foram divididas em grupos:
A) Grupo de perguntas referentes a cada requisito obtido durante a reunião.
Este grupo contém perguntas que analisam cada requisito individualmente,
tentando identificar se algum requisito obtido na reunião está vago ou ambíguo.
Se for encontrado algum requisito nestas condições, tomar o respectivo
gerenciamento na tentativa de torná-lo estável e bem definido.
B) Grupo de perguntas referentes aos requisitos como um todo.
Este grupo visa detectar os conflitos que podem ocorrer com os requisitos
como um todo, tais como problemas com a compatibilidade entre os requisitos e
os objetivos ou com a qualidade da documentação utilizada para representar os
requisitos.
43
C) Grupo de perguntas referentes a cada objetivo da reunião.
Já este grupo visa analisar cada objetivo da reunião separadamente, para
verificar se cada um foi bem discutido.
D) Grupo de perguntas referentes aos objetivos da reunião como um todo.
Como o grupo B, o D analisa os objetivos da reunião como um todo, como,
por exemplo, analisar se eles são compatíveis entre si.
E) Grupo de perguntas referentes a cada participante da reunião.
Estas perguntas visam observar o comportamento individual de cada
participante para saber até que ponto deficiências individuais podem ter
prejudicado a obtenção de melhores requisitos. Os participantes respondem a este
grupo de perguntas analisando cada um dos outros participantes e nunca si
próprio. Isto porque separamos as perguntas de auto-avaliação em outro grupo. Já
que para estas são necessários maiores cuidados na elaboração da pergunta, pois o
indivíduo tende a julgar seu comportamento como superior ao dos demais, ou
seja, é tolerante com seus erros e crítico com as falhas alheias.
F) Grupo de perguntas referentes ao participante que está respondendo o
questionário
Como foi dito anteriormente, este grupo são de perguntas de auto-avaliação,
para analisar casos em que só o próprio indivíduo vai saber responder, tentando
detectar possíveis desvios do participante em relação ao comportamento ideal
durante a reunião.
G) Grupo de perguntas referentes à organização da reunião.
Este grupo contém perguntas que vão analisar como o líder desempenhou
seu papel durante a reunião, pois cabe a ele efetuar o controle e a coordenação das
atividades de forma adequada, evitando que a reunião se desvie dos seus
objetivos. Desta forma, todos os participantes devem responder a este grupo de
questões menos, é claro, o líder.
Dentro deste grupo também aparecem perguntas relacionadas ao modo
como a reunião foi realizada, independente se esta foi presencial ou não. Com o
objetivo de observar algum problema nas condições da sua realização, pois o bom
andamento da reunião tem influência direta sobre o bem estar dos participantes e
conseqüentemente sobre os resultados da mesma.
H) Grupo de perguntas referentes ao planejamento para as demais fases do
projeto.
44
Como todas as fases de um projeto devem estar perfeitamente
harmonizadas, não basta obter perfeitamente os requisitos do sistema. Pois tão
importante quanto isto é a preocupação em se estabelecer um planejamento
adequado para garantir que estes requisitos sejam cumpridos nas próximas fases
do projeto.
Além das perguntas do grupo G, o líder não deve responder outras perguntas
que não estão de acordo com o seu papel, como, por exemplo, o grau de interesse
ou benefício em determinado requisito, já que ele deve ser neutro em relação aos
resultados da reunião.
Com o término do estudo feito no questionário original, criamos um novo
conjunto de perguntas de apoio ao método.
A apresentação detalhada das perguntas do novo questionário será realizada
a seguir.
3.4.2. Descrição das questões do novo questionário
As questões serão apresentadas de forma que possam ser compreendidos
todos os aspectos relacionados com cada questão. Este formato será usado tanto
para perguntas relativas quanto absolutas.
O formato será o seguinte:
- a descrição da pergunta.
- o objetivo da pergunta: é necessário descrever o que se pretende observar
com a formulação de uma determinada questão, demonstrando, desta forma, a
relevância da pergunta para o método.
- o tipo da pergunta: absoluta ou relativa
- o conflito possível de ser detectado com a pergunta, incluindo:
- qual o grau em que o conflito ocorre, se para um grau alto ou baixo
das respostas.
- o tipo de conflito: não funcional ou se foi identificada a ausência de
um conflito funcional.
- a descrição do conflito.
- a(s) técnica(s) de gerenciamento que deve(m) ser empregada(s) no caso de
haver conflito.
45
- as causas do conflito: Existe uma distinção na apresentação das causas nas
questões absolutas e relativas.
- para perguntas absolutas: as causas são pré-determinadas. Desta
forma, não há necessidade de correlação com outras questões para a
identificação desta. A descrição da causa é apresentada diretamente.
- para perguntas relativas: é apresentado o número da questão que
pode ser uma causa provável juntamente com o grau em que esta deve
ocorrer para que caracterize o conflito. As questões da causa são
apresentadas de forma afirmativa para deixar mais clara a relação de causa e
efeito. Também são indicados os conectivos lógicos que relacionam as
diversas causas possíveis, podendo haver uma combinação do conectivo e
com o conectivo ou de diversas formas para a construção das possíveis
causas para o conflito.
- bibliografia: é apresentada ao final de cada questão, para informar quais
referencias bibliográficas forneceram os subsídios necessários para a sua
elaboração. Foi através do banco de conhecimento construído a partir do estudo
dessas bibliografias feito por Mathias [Mathias 94], que tivemos base para a
criação das perguntas e seus diagnósticos.
Em algumas questões relativas, podem surgir diversos tipos de conflito
dependendo do grau das respostas e suas causas. Deste modo, cada conflito
possível de ocorrer será representado por uma hipótese da questão. Havendo
diversas hipóteses possíveis dentro de uma mesma questão relativa, será
apresentada a descrição de cada hipótese juntamente com o grau das respostas que
a torna verdadeira, as causas mais prováveis para a ocorrência do conflito e as
técnicas de gerenciamento.
Antes de descrevermos detalhadamente todas as características das
perguntas do questionário, iremos apresentar uma tabela que irá ajudar no
entendimento da relação das causas das perguntas relativas com as demais
perguntas do questionário. Segue um quadro explicativo para o correto
entendimento da tabela de relacionamento entre as perguntas:
46
A coluna da esquerda da tabela apresenta o número da pergunta, sua descrição e
a intensidade do grau de resposta (grau do conflito) que sinaliza a identificação do conflito
pela pergunta, que pode ser grau alto ou baixo. Conseqüentemente a coluna da direita
lista as possíveis causas responsáveis pelo conflito identificado pela pergunta
apresentada.
As causas das perguntas relativas serão apresentadas pelos números das
perguntas, que identificam os problemas causadores do seu conflito, combinadas entre si
pelos operadores “e” e “ou” representados respectivamente pelos símbolos ∧ e ∨. Quando
a pergunta relativa tiver mais de uma hipótese, as suas causas serão apresentadas
separadas por hipótese e no caso de uma pergunta absoluta sua causa será descrita
diretamente.
Vale lembrar que a expressão “identificar conflito” corresponde a identificação da
ocorrência de conflitos não funcionais e a identificação da ausência de conflitos funcionais.
Também é importante ressaltar que a análise dos conflitos e o relacionamento de causa e
efeito entre as perguntas que identificaram conflitos são realizados somente após os
participantes da reunião terem respondido todas as perguntas do questionário.
Se a pergunta identificar conflito → Suas possíveis causas são:
Nº + Descrição + Grau do Conflito Causas:
1) Classifique o grau de ambigüidade
ou falta de clareza e precisão de cada
requisito.
Grau do conflito: Alto
2 ∨ 3 ∨ 4 ∨ 5 ∨ 7 ∨ 14 ∨ 15 ∨ 18 ∨ 21 ∨
26 ∨ 29
2) Qual o grau de necessidade de
especialistas adicionais que possam
sanar dúvidas ou esclarecer melhor
certos pontos que foram discutidos
referentes ao requisito?
Grau do conflito: Alto
Falha no planejamento, pois não foram
convocados especialistas para cobrir
todas as áreas de interesse da reunião.
47
3) Qual o grau de consenso surgido
entre os participantes no final da
reunião em relação a cada requisito
obtido?
Grau do conflito: Baixo
2 ∨ 15 ∨ 16 ∨ 19 ∨ 22 ∨ 24 ∨ 25 ∨ 26 ∨
27 ∨ 28 ∨ 30 ∨ 35 ∨ 36
4) Para cada requisito obtido, indique o
grau em que influências externas à
organização podem afetá-los.
Grau do conflito: Alto
Alterações no ambiente externo à
empresa constituem a causa deste
conflito.
5) Para cada requisito, classifique o seu
grau de conhecimento do mesmo após a
reunião.
Grau do Conflito: Baixo
2 ∨ 6 ∨ 15 ∨ 17 ∨ 18 ∨ 21 ∨ 26 ∨ 29 ∨
32 ∨ 33 ∨ 35
6) Qual o benefício que cada requisito
obtido, quando implementado, trará
para a execução de suas tarefas?
Grau do Conflito: Baixo
1º Hipótese: 14
2º Hipótese: 10 ∨ 20
3º Hipótese: 32
4º Hipótese: 32 ∧ (1 ∨ 2 ∨ 3 ∨ 5 ∨ 8 ∨ 9
∨ 15 ∨ 17 ∨ 18 ∨ 19 ∨ 21 ∨ 22 ∨ 25 ∨
26 ∨ 27 ∨ 29 ∨ 30 ∨ 31 ∨ 33 ∨ 34 ∨ 35
∨ 36)
7) Indique o grau em que influências
internas à própria organização podem
afetar cada requisito do sistema.
Grau do Conflito: Alto
Alterações na forma de desempenhar as
tarefas nos setores da organização
devido a melhorias ou reestruturação
das rotinas internas acabam por causar
mudanças nos requisitos que possuem
relação com as mudanças efetuadas,
pois o sistema deve refletir o
funcionamento da organização.
8) Qual o grau de compatibilidade entre
os requisitos do sistema obtidos na
reunião?
Grau do Conflito: Baixo
1º Hipótese: 13 ∨ 14
2º Hipótese: 13 ∧ 14 ∧ (2 ∨ 3 ∨ 9 ∨ 15
∨ 16 ∨ 18 ∨ 21 ∨ 22 ∨ 25 ∨ 26 ∨ 28 ∨
29 ∨ 30 ∨ 35 ∨ 36)
48
9) Qual a qualidade da documentação
que foi elaborada para representar os
requisitos.
Grau do Conflito: Baixo
15 ∨ 35 ∨ 37
10) Qual o grau de coerência entre os
requisitos obtidos e os objetivos da
reunião?
Grau do Conflito: Baixo
11 ∨ 13 ∨ 14 ∨ 15 ∨ 20 ∨ 31 ∨ 35
11) Para cada objetivo da reunião,
apresente o grau de discussão que foi
gerada em torno de seus tópicos
principais.
Grau do Conflito: Baixo
12 ∨ 13 ∨ 14 ∨ 15 ∨ 17 ∨ 20 ∨ 21 ∨ 22
∨ 29 ∨ 30 ∨ 31 ∨ 32 ∨ 33 ∨ 35
12) Qual o grau de viabilidade de cada
objetivo da reunião?
Grau do Conflito: Baixo
14
13) Qual o grau de compatibilidade
entre os objetivos da reunião?
Grau do Conflito: Baixo
14
14) Em que grau os objetivos da
reunião foram bem definidos antes do
seu inicio?
Grau do Conflito: Baixo
Falha dos planejadores que não se
preocuparam em definir claramente os
objetivos da reunião, trazendo prejuízos
à reunião pela falta de uma definição
clara do que deveria ser discutido.
15) Qual a sua opinião em relação ao
tempo de duração da reunião em função
dos objetivos da reunião?
Grau do Conflito-1º Hipótese: Baixo
Grau do Conflito-2º e 3º Hipótese: Alto
1º Hipótese: 2 ∨ 6 ∨ 11 ∨ 12 ∨ 13 ∨ 14
∨ 17 ∨ 31 ∨ 32 ∨ 35 ∨ 37
2º Hipótese: 3 ∨ 19 ∨ 22 ∨ 24 ∨ 25 ∨ 26
∨ 30 ∨ 34 ∨ 35
3º Hipótese: 10 ∨ 14 ∨ 20 ∨ 31 ∨ 35
49
16) Qual o grau em que cada membro
usou de coerção (ameaças) para fazer
prevalecer seus pontos de vista durante
a reunião?
Grau do Conflito: Alto
O participante que usou de coerção
possui alguma vantagem em relação aos
demais, seja por possuir um status
maior ou por ocupar um cargo melhor
na organização ou por possuir trunfos
que o permite persuadir os demais
membros da reunião. Desta forma, o
indivíduo utiliza a coerção como forma
de fazer valer suas idéias, prejudicando
os resultados da reunião.
17) Qual o grau de participação de cada
indivíduo durante a reunião?
Grau do Conflito: Baixo
1º Hipótese : 32
2º Hipótese: 10 ∨ 14 ∨ 20 ∨ 31 ∨ 35
3º Hipótese: 23 ∨ 24 ∨ 30
4º Hipótese: 27
18) Para cada participante, indique o
grau que a utilização excessiva de
vocabulário difícil e/ ou termos técnicos
prejudicou a compreensão dos
requisitos.
Grau do Conflito: Alto
Falta de conhecimento dos outros
membros da reunião, dos principais
termos do projeto ∨ 21 .
19) Para cada participante, qual o grau
de resistência demonstrado as novas
idéias que surgiram?
Grau do Conflito: Alto
Os indivíduos com resistência a novas
idéias podem não estar querendo alterar
suas formas de trabalho atuais, seja por
não aceitarem críticas construtivas ou
por medo de perda de poder ou de
demissão.
20) Informe o grau em que cada
participante se desviou dos objetivos
traçados pelos planejadores.
Grau do Conflito: Alto
12 ∨ 13 ∨ 14 ∨ 31 ∨ 32 ∨ 35
50
21) Indique o grau de conhecimento
que cada participante transmitiu sobre
os assuntos de sua alçada durante a
reunião.
Grau do Conflito: Baixo
1º Hipótese: 17 ∨ 22 ∨ 29 ∨ 30 ∨ 32 ∨
33 ∨ 35 ∨ 37
2º Hipótese: 5
22) Qual o grau de cooperação
demonstrado por cada participante da
reunião?
Grau do Conflito: Baixo
1º Hipótese: 6 ∨ 32 ∨ 33
2º Hipótese: 17 ∨ 30 ∨ 35
3º Hipótese: 27
23) Para cada participante da reunião,
informe o grau em que você conhece
seu trabalho (ou o grau que passou a
conhecer após a reunião).
Grau do Conflito: Baixo
A reunião foi efetuada com algum sub-
grupo que não trabalha junto,
ocasionando o desconhecimento do
trabalho do(s) outro(s) participante(s).
24) Para cada participante, qual o grau
de importância para você, que ele
execute suas tarefas diárias com rapidez
e com a qualidade desejada?
Grau do Conflito: Baixo
A estrutura da organização, onde
departamentos e indivíduos muitas
vezes não estão ligados, sendo
independentes. Possibilitando que em
certos casos, o sucesso de um indivíduo
não esteja condicionado a um bom
trabalho de outras pessoas.
25) Para cada participante, informe o
grau com que ele embasou suas
posições, expondo argumentos para a
sua linha de pensamento ao invés de
simplesmente colocar suas idéias sem
maiores explicações.
Grau do Conflito: Baixo
6 ∨ 11 ∨ 17 ∨ 21 ∨ 22 ∨ 29 ∨ 30 ∨ 32 ∨
33 ∨ 35
26) Qual o grau em que cada indivíduo
forneceu soluções para os problemas
que surgiram durante a reunião.
Grau do Conflito: Baixo
1º Hipótese: 6 ∨ 17 ∨ 21 ∨ 22 ∨ 27 ∨ 30
∨ 32 ∨ 33 ∨ 35
2º Hipótese: 6 ∨ (17 ∧ 22) ∨ 21 ∨ 27 ∨
30 ∨ 32 ∨ 33 ∨ 35
51
27) Qual o grau de antagonismo que
você possui em relação a cada
participante da reunião?
Grau do Conflito: Alto
Desavenças entre os membros devido a
acontecimentos passados ou discussões
durante a reunião podem ter causado o
surgimento de antagonismos entre
alguns indivíduos.
28) Qual o grau de monopolização da
discussão por parte de cada indivíduo?
Grau do Conflito: Alto
O indivíduo monopolizador fala em
excesso, esquecendo-se de que há outras
pessoas na reunião que também tem o
mesmo direito do uso da palavra.
29) Em que grau você deixou de emitir
suas opiniões ou de apresentar suas
experiências por achar que todos já
possuíam o conhecimento do que você
poderia expressar?
Grau do Conflito: Alto
O indivíduo que deixou de emitir suas
opiniões imaginou que os demais
membros já conheciam suas idéias ou já
haviam passado por experiências
semelhantes. Freqüentemente isto
ocorre porque o indivíduo já possui um
conhecimento sobre um determinado
assunto tão impregnado em sua mente
que sem perceber parte do pressuposto
de que as outras pessoas possuem uma
base de conhecimento semelhante a sua,
chamamos isso de conhecimento tácito.
30) Em que grau você se identificou
com o grupo?
Grau do Conflito: Baixo
A baixa identificação do participante
com o grupo vem a partir da falta de
visualização de objetivos,
comportamentos e necessidades
semelhantes as dos demais indivíduos.
31) Em que grau você sabia dos papéis
que deveria desempenhar durante a
reunião?
Grau do Conflito: Baixo
Falhas no planejamento causaram este
conflito, pois os planejadores deveriam
expor aos indivíduos convidados a
agenda da reunião e a participação que
seria esperada deles durante os debates.
52
32) Qual o grau de relacionamento do
sistema a ser desenvolvido com as
tarefas que você desempenha em seu
trabalho?
Grau do Conflito: Baixo
Falhas no planejamento fizeram com
que indivíduos sem relação com o
sistema tivessem sido convocados para
a reunião.
33) Com qual grau de importância você
classifica a fase de levantamento de
requisitos, isto é, a fase onde
procuramos entender as necessidades
do projeto e descrevê-las de forma mais
clara possível?
Grau do Conflito: Baixo
Falta de entendimento do participante
da importância do processo de
levantamento de requisitos para um
bom desenvolvimento de software.
34) Em que grau as discussões que
surgiram conduziram a um aumento na
tensão do grupo?
Grau do Conflito: Alto
Hostilidades anteriores a reunião entre
alguns participantes ou características
de personalidade de alguns membros
(agressivos, dominadores, sem
habilidades no trato social, resistentes a
mudanças) são causas prováveis para
este conflito.
35) Qual a qualidade do controle e da
cooperação de atividades efetuados
pelo líder durante a reunião?
Grau do Conflito: Baixo
1º Hipótese: 36
2º Hipótese: 36
36) Qual o seu grau de antagonismo em
relação ao líder da reunião?
Grau do Conflito: Alto
Problemas pessoais já existentes no
passado entre os participantes e o líder
ou então discussões surgidas durante a
reunião podem ter causado o
antagonismo entre os participantes e o
líder.
53
37) Qual o seu grau de satisfação em
relação à maneira a qual a reunião foi
realizada.
Grau do Conflito: Baixo
Um planejamento mal feito da reunião
realizado pelo planejador.
38) Qual o grau em que as diretrizes
estabelecidas pelos participantes serão
suficientes para garantir o cumprimento
dos requisitos durante o
desenvolvimento do sistema?
Grau do Conflito: Baixo
15 ∨ 35 ∨ Falhas na continuidade do
planejamento pelo líder e pelos
membros, pois estes não se
preocuparam em definir diretrizes que
assegurassem o cumprimento dos
requisitos obtidos.
39) Qual o grau em que os
compromissos firmados entre os
participantes serão suficientes para
garantir que os requisitos sejam
mantidos e atendidos pelo sistema?
Grau do Conflito: Baixo
15 ∨ 32 ∨ 35 ∨ 38 ∨ Falhas na
continuidade do planejamento pelo líder
e pelos membros, pois estes não se
preocuparam em estabelecer
compromissos que garantissem que as
diretrizes traçadas e os requisitos
obtidos fossem cumpridos.
Feitas estas colocações, segue a descrição detalhada das 39 perguntas que
compõem o novo questionário do método.
A) Grupo de perguntas referente a cada requisito obtido durante a
reunião.
Para cada requisito obtido durante a reunião, responda:
1) Classifique o grau de ambigüidade ou falta de clareza e precisão de cada
requisito.
Objetivo: Saber se os requisitos estão definidos de forma clara ou se foram
detectadas ambigüidades ou falta de clareza em sua forma de apresentação, o que
se refletirá em ambigüidades e dúvidas nas fases posteriores de desenvolvimento
do sistema.
54
Tipo da questão: relativa.
Conflito (com alto grau das respostas) : Não funcional entre a necessidade
de se ter requisitos claros e bem definidos e o grau de ambigüidade ou de falta de
clareza e precisão detectado.
Gerenciamento: Na próxima reunião, o líder deve propor um esclarecimento
do(s) requisitos ambíguo(s) e impreciso(s), onde os participantes devem colocar
os pontos onde o(s) requisito(s) estão mal definidos visando uma melhora do seu
entendimento.
Causas: 2 - Alta necessidade de especialistas que possam sanar dúvidas em
relação ao requisito ou 3 – Baixo grau de consenso entre os participantes em
relação ao requisito ou 4 – Alto grau em que influências externas à organização
podem afetar o requisito ou 5 - Baixo grau de conhecimento do requisito pelos os
participantes após a reunião ou 7 – Alto grau em que influências internas à
organização podem afetar o requisito ou 14 – Baixo grau de definição dos
objetivos da reunião antes da reunião ou 15 – Primeira Hipótese: Baixo tempo de
duração da reunião em função dos objetivos do sistema ou 18 - Alto grau de
utilização de vocabulário difícil e/ ou termos técnicos pelos participantes
prejudicando a compreensão do requisito ou 21 – Baixo grau de conhecimento
transmitido pelos participantes ou 26- Baixo grau com que os participantes
forneceram soluções para os problemas que surgiram durante a reunião ou 29 -
Alto grau com que os participantes deixaram de emitir suas opiniões por achar
que todos já possuíam o conhecimento daquilo que eles poderiam expressar.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram [Garg-
Janardan, Salvendy 87], [Kim, Courtney 88], [Reubenstein 91] e [Simões 70].
2) Qual o grau de necessidade de especialistas adicionais que possam sanar
dúvidas ou esclarecer melhor certos pontos que foram discutidos referentes ao
requisito?
Objetivo: Saber se há necessidade de inserir entre os participantes da
reunião pessoas com um conhecimento maior em determinadas áreas em que
surgiram muitas dúvidas.
Tipo da questão: absoluta
55
Conflito (com grau alto das respostas): Não funcional entre a necessidade de
estarem presentes especialistas relativos às áreas de discussão e a ausência destes
especialistas em determinadas áreas.
Gerenciamento: Resolução do problema através da inserção de especialistas
nas áreas onde foram detectadas a carência de pessoas com um maior
conhecimento.
Causa: Falha no planejamento, pois não foram convocados especialistas
para cobrir todas as áreas de interesse da reunião.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram
[Hampton 83], [Lima 69], [Macaulay 92], [McMaster, Grinder 80], [Reubenstein
91] e [Telem 88].
3) Qual o grau de consenso surgido entre os participantes no final da reunião
em relação a cada requisito obtido?
Objetivo: Verificar se houve consenso entre os participantes quanto a cada
requisito obtido.
Tipo da questão: relativa.
Conflito (com grau baixo das questões): Não funcional entre a necessidade
de se otimizar a satisfação dos participantes e o baixo grau de consenso obtido.
Gerenciamento: Usar técnicas de negociação entre os participantes para
tentar resolver as divergências. No caso de já terem sido usadas estas técnicas, o
líder deve servir como mediador no sentido de ajudar a resolver os impasses.
Causas: 2 – Alto grau de necessidade de especialistas adicionais que possam
sanar dúvidas em relação ao requisito ou 15 – Primeira Hipótese: Baixo tempo de
duração da reunião em função dos objetivos do sistema ou 16 – Alto grau de
coerção usada pelos participantes ou 19 – Alta resistência demonstrada pelo grupo
em relação as novas idéias ou 22 – Baixa cooperação mostrada pelo grupo ou 23 –
Baixo grau em que o trabalho dos participantes é conhecido pelos demais
membros da reunião ou 24 – Baixa importância dos participantes para que os
demais membros executem suas tarefas diárias com qualidade ou 25 – Baixo grau
com que os participantes embasaram suas posições ou 26 - Baixo grau com que os
participantes forneceram soluções para os problemas que surgiram durante a
reunião ou 27 – Alto grau de antagonismo entre os participantes da reunião ou 28
– Alto grau de monopolização da reunião pelos indivíduos ou 30 – Baixa
56
identificação dos participantes com o grupo ou 35 – Baixa qualidade do controle
e da coordenação de atividades efetuadas pelo líder ou 36- Alto grau de
antagonismo do grupo em relação ao líder.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram
[Brabander, Thiers 84], [Cook et.al 87], [McMaster, Grinder 80] e [Macaulay 92].
4) Para cada requisito obtido, indique o grau em que influências externas à
organização podem afetá-los.
Objetivo: Saber quais os requisitos que estão mais sujeitos a variações
devido a alterações nas condições externas à organização e que não podem ser
controladas pela mesma.
Tipo de questão: absoluta.
Conflito (com alto grau das respostas): Não funcional entre o ideal de ter
requisitos estáveis e a sua provável oscilação com o tempo devido a mudanças em
condições externas à organização.
Gerenciamento: Documentar detalhadamente quais as condições ambientais
que podem afetar determinados requisitos e mostrar aos planejadores da reunião
para que estes tomem consciência e tentem adotar as medidas necessárias à
minimização destes problemas. Isto é importante para justificar as manutenções
que serão necessárias durante e após o projeto devido a alterações nas condições
ambientais.
Causa: Alterações no ambiente externo à empresa constituem a causa deste
conflito.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram [Cronan,
Means 84] e [Curtis et. al 88].
5) Para cada requisito, classifique o seu grau de conhecimento do mesmo
após a reunião.
Obs: O líder não responde esta questão.
Objetivo: Verificar se a reunião cumpriu um dos seus objetivos, o de
aumentar o conhecimento dos participantes sobre os requisitos do sistema. Mesmo
que tenha havido um baixo conhecimento antes da reunião, com a cooperação é
esperado um aumento no conhecimento de cada requisito.
Tipo da questão: relativa.
57
Conflito (com grau baixo das respostas): Não funcional entre um dos
objetivos da reunião, de maximizar o conhecimento dos participantes sobre os
requisitos que foram obtidos e o baixo conhecimento observado após a reunião.
Causas: 2 – Alto grau de necessidade de especialistas que possam sanar
dúvidas em relação ao requisito ou 6 – Baixo benefício que o requisito trará para
os participantes ou 15 – Primeira hipótese: Baixo tempo de duração da reunião em
função dos objetivos do sistema ou 17 – Baixa participação dos indivíduos
durante a reunião ou 18 - Alto grau de utilização de vocabulário difícil e/ ou
termos técnicos pelos participantes prejudicando a compreensão do requisito ou
21 – Baixo grau de conhecimento transmitido pelos participantes ou 26 - Baixo
grau com que os participantes forneceram soluções para os problemas que
surgiram durante a reunião ou 29 – Alto grau em que os participantes deixaram de
emitir suas opiniões por achar que todos já possuíam o conhecimento daquilo que
poderiam expressar ou 32 – Baixo relacionamento do sistema com as tarefas
desempenhadas pelos participantes em seu trabalho ou 33 - Baixo grau de
importância que os participantes classificam a fase de levantamento de requisitos
ou 35 – Baixa qualidade do controle e da coordenação de atividades efetuadas
pelo líder.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram [Curtis
et. Al 88] e [Simões 70].
6) Qual o benefício que cada requisito obtido, quando implementado, trará
para a execução de suas tarefas?
Obs: O líder não responde esta questão.
Objetivo: Saber se os requisitos que foram obtidos irão contribuir para a
melhoria na qualidade do serviço do participante, permitindo estabelecer uma
relação custo x benefício de cada requisito, a partir do número de benefícios que
forem obtidos nas respostas de todos os participantes.
Tipo da questão: relativa.
Primeira hipótese (com grau baixo das respostas): Os objetivos da reunião
não foram definidos de forma a trazer algum benefício para a organização.
Conflito: Não funcional entre os objetivos mal definidos e a necessidade de
haver uma boa definição dos mesmos para a obtenção de requisitos de qualidade.
58
Gerenciamento: Os objetivos da reunião devem ser revistos e redefinidos,
visando a trazer um maior número de benefícios para os interessados no sistema.
Causa: 14 – Baixo grau de definição dos objetivos da reunião antes do seu
inicio.
Segunda hipótese (com grau baixo das respostas): Ocorreu um
deslocamento dos objetivos durante a reunião, o que pode ter ocasionado a
obtenção de requisitos que trarão poucos benefícios para os participantes.
Conflito: Não funcional entre os objetivos definidos e os assuntos tratados
durante a reunião, que não tem relação com os objetivos estabelecidos.
Gerenciamento: O líder deve evitar na próxima reunião que os participantes
se desviem dos assuntos diretamente relacionados com os objetivos da reunião,
pedindo aos indivíduos que estiverem se desviando dos temas que voltem aos
assuntos da reunião. No caso de haver dúvidas quanto ao interesse de um
determinado assunto para o estabelecimento dos requisitos, deve ser demonstrada
a relevância das idéias com os objetivos da reunião.
Causas: 10 – Baixa coerência entre os requisitos obtidos e os objetivos da
reunião ou 20 – Alto grau de desvio dos participantes em relação aos objetivos da
reunião.
Terceira hipótese (com grau baixo das respostas): O(s) requisito(s) trarão
poucos benefícios porque os participantes convidados para a reunião não possuem
relação direta com o sistema a ser desenvolvido.
Conflito: Não funcional entre um planejamento adequado, que deveria
convidar para a reunião somente pessoas que tivessem relação com os objetivos
traçados e a participação de indivíduos que não serão beneficiados pelo uso do
sistema.
Gerenciamento: Devem ser convidadas para a próxima reunião somente
pessoas que serão diretamente afetadas pelo sistema a ser desenvolvido. Portanto,
os participantes sem relação com o sistema devem ser excluídos das próximas
reuniões. Com exceção de algum especialista que possa não estar diretamente
relacionado com o sistema, mas que precise ser chamado para sanar dúvidas sobre
uma determinada área de interesse da reunião.
59
Causa: 32 – Baixo relacionamento do sistema com as tarefas
desempenhadas pelos participantes em seu trabalho.
Quarta hipótese (com baixo grau das respostas): Os participantes possuem
relação direta com o sistema, porém o(s) requisito(s) obtido(s) são de baixa
qualidade, ocasionando o baixo benefício que eles trarão para os participantes.
Conflito: Não funcional entre os objetivos da reunião em se obter requisitos
de qualidade e o(s) requisito(s) obtido(s) na prática, que possuía(m) uma
qualidade abaixo da esperada.
Gerenciamento: Melhorar a qualidade do(s) requisito(s) obtido(s) através da
resolução das causas detectadas para esta hipótese. Devendo também o líder
motivar os participantes, fazendo papel de questionador, lançando dúvidas e
realizando perguntas diretas para que os especialistas das áreas que despertam
pouco interesse manifestem seu conhecimento.
Causas: 32 – Alto grau de relacionamento do sistema com as tarefas
desempenhadas pelos participantes em seu trabalho e (1 – Alto grau de
ambigüidade do requisito ou 2 - Alta necessidade de especialistas que possam
sanar dúvidas em relação ao requisito ou 3 – Baixo grau de consenso entre os
participantes em relação ao requisito ou 5 - Baixo grau de conhecimento do
requisito pelos os participantes após a reunião ou 8 – Baixo grau de
compatibilidade entre os requisitos obtidos ou 9 - Baixa qualidade da
documentação usada para representar os requisitos obtidos ou 14 – Baixo grau de
definição dos objetivos da reunião antes do seu inicio ou 15 – Primeira hipótese:
Baixo tempo de duração da reunião em função dos objetivos do sistema ou 15 –
Segunda hipótese: Alto de tempo de duração da reunião em função dos objetivos
do sistema devido ao surgimento de muitos impasses ou 15 – Terceira hipótese:
Alto de tempo de duração da reunião em função dos objetivos do sistema devido a
um desvio dos mesmos ou 17 – Baixa participação dos indivíduos durante a
reunião ou 18 - Alto grau de utilização de vocabulário difícil e/ ou termos técnicos
pelos participantes prejudicando a compreensão do requisito ou 19 – Alta
resistência demonstrada pelo grupo em relação as novas idéias ou 21 – Baixo grau
de conhecimento transmitido pelos participantes ou 22 – Baixa cooperação
mostrada pelo grupo ou 25 – Baixo grau com que os participantes embasaram suas
posições ou 26 - Baixo grau com que os participantes forneceram soluções para os
60
problemas que surgiram durante a reunião ou 33 - Baixo grau de importância que
os participantes classificam a fase de levantamento de requisitos ou 27 – Alto grau
de antagonismo entre os participantes da reunião ou 29 – Alto grau com que os
participantes deixaram de emitir suas opiniões por achar que todos já possuíam o
conhecimento daquilo que eles poderiam expressar ou 30 – Baixa identificação
dos participantes com o grupo ou 31 – Baixo grau em que os participantes sabiam
dos papéis que deveriam desempenhar durante a reunião ou 34 – Alto grau com
que as discussões conduziram a um aumento de tensão do grupo ou 35 – Baixa
qualidade do controle e da coordenação de atividades efetuadas pelo líder ou 36-
Alto grau de antagonismo do grupo em relação ao líder).
Bibliografia: Segundo [Mathias 94], a referência utilizada foi [Andriole 90].
7) Indique o grau em que influências internas à própria organização podem
afetar cada requisito do sistema.
Objetivo: Saber se condições internas à própria organização podem influir
no sistema, fazendo com que surja a necessidade de efetuar manutenções nos
requisitos e, em conseqüência, em todo o sistema.
Tipo da questão: absoluta.
Conflito (com grau alto das respostas): Não funcional entre o ideal de se ter
requisitos estáveis e a instabilidade gerada por condições internas à organização.
Gerenciamento: Os planejadores devem tomar consciência dos fatores
organizacionais que podem afetar determinados requisitos, gerando atrasos no
projeto ou manutenções constantes no sistema. A partir daí, os planejadores
podem tentar adotar medidas internas que reduzam a influência destes fatores
organizacionais nos requisitos do sistema.
Causa: Alterações na forma de desempenhar as tarefas nos setores da
organização devido a melhorias ou reestruturação das rotinas internas acabam por
causar mudanças nos requisitos que possuem relação com as mudanças efetuadas,
pois o sistema deve refletir o funcionamento da organização.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram
[Brabander, Thiers 84], [Cronan, Means 84], [Curtis et. al 88] e [Easterbrook 90].
B) Grupo de perguntas referentes aos requisitos como um todo.
61
8) Qual o grau de compatibilidade entre os requisitos do sistema obtidos na
reunião?
Objetivo: Observar se existem requisitos que não podem ser realizados
simultaneamente.
Tipo da questão: relativa.
Primeira hipótese (com grau baixo das respostas): A incompatibilidade entre
os requisitos é reflexo da má definição ou da incompatibilidade entre os objetivos
da reunião.
Conflito: Não funcional, pois a realização completa de um requisito implica
em uma não realização total ou parcial de outros requisitos.
Gerenciamento: A redefinição dos objetivos auxiliará na resolução da
incompatibilidade entre os requisitos, pois alguns requisitos terão que ser revistos
e alterados em função da mudança dos objetivos.
Causas: 13 – Baixo grau de compatibilidade entre os objetivos da reunião ou
14 – Baixo grau de definição dos objetivos da reunião antes do seu inicio.
Segunda hipótese (grau baixo das respostas): Os objetivos da reunião estão
bem definidos e são compatíveis entre si, mas os requisitos apresentam
incompatibilidades.
Conflito: Não funcional, pois a realização completa de um requisito implica
em uma não realização total ou parcial de outros requisitos.
Gerenciamento: Alterar na próxima reunião, através da negociação entre os
participantes, as partes dos requisitos que possuem incompatibilidades,
eliminando seus conflitos e permitindo sua completa realização simultaneamente.
Causas: 13 – Alto grau de compatibilidade entre os objetivos da reunião e
14 – Alto grau de definição dos objetivos da reunião antes do seu inicio e (2 - Alta
necessidade de especialistas que possam sanar dúvidas em relação ao requisito ou
3 – Baixo grau de consenso entre os participantes em relação ao requisito ou 9 -
Baixa qualidade da documentação usada para representar os requisitos obtidos ou
15 – Primeira hipótese: Baixo tempo de duração da reunião em função dos
objetivos do sistema ou 16 – Alto grau de coerção usada pelos participantes ou 18
- Alto grau de utilização de vocabulário difícil e/ ou termos técnicos pelos
participantes prejudicando a compreensão do requisito ou 21 – Baixo grau de
conhecimento transmitido pelos participantes ou 22 – Baixa cooperação mostrada
62
pelo grupo ou 25 – Baixo grau com que os participantes embasaram suas posições
ou 26 - Baixo grau com que os participantes forneceram soluções para os
problemas que surgiram durante a reunião ou 28 – Alto grau de monopolização da
reunião ou 29 – Alto grau com que os participantes deixaram de emitir suas
opiniões por achar que todos já possuíam o conhecimento daquilo que eles
poderiam expressar ou 30 – Baixa identificação dos participantes com o grupo ou
35 – Baixa qualidade do controle e da coordenação de atividades efetuadas pelo
líder ou 36- Alto grau de antagonismo do grupo em relação ao líder).
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram [Curtis
et. al 88] e [Pressman 87].
9) Qual a qualidade da documentação que foi elaborada para representar os
requisitos.
Objetivo: Verificar a qualidade da documentação dos requisitos, pois uma
documentação insuficiente dificultará a transmissão de conhecimento para os
demais membros da equipe de desenvolvimento do sistema além de sujeitar a
distorções e a esquecimentos dos requisitos que foram obtidos.
Tipo da questão: relativa.
Conflito (com grau baixo das respostas): Não funcional entre a qualidade
desejada da documentação dos requisitos e a documentação apresentada,
comprometendo seriamente a qualidade do projeto.
Gerenciamento: Documentar os requisitos obtidos com a participação de
todos os membros da reunião, para evitar distorções e tendências na
documentação que for elaborada.
Causas: 15 – Primeira hipótese: Baixo tempo de duração da reunião em
função dos objetivos do sistema ou 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder ou 37 – Baixo grau de satisfação
em relação à maneira a qual a reunião foi realizada.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram [Curtis
et. al 88], [Cronan, Means 84], [Duarte et. al 92], [Parnas, Clements 86], [Simões
70] e [Telem 88].
10) Qual o grau de coerência entre os requisitos obtidos e os objetivos da
reunião?
63
Objetivo: Verificar se houve um deslocamento dos objetivos durante a
reunião, o que é indicado por requisitos incoerentes como os objetivos traçados.
Tipo de questão: relativa.
Conflito (com grau baixo das respostas): Não funcional entre os objetivos da
reunião e os requisitos obtidos.
Gerenciamento: O líder deve efetuar uma monitoração constante das
próximas reuniões para evitar novos desvios dos assuntos em relação aos
objetivos que tem que ser atendidos.
Causas: 11 – Baixo grau de discussão gerada em torno dos objetivos da
reunião ou 13 – Baixa compatibilidade entre os objetivos da reunião ou 14 –
Baixo grau de definição dos objetivos da reunião antes do seu inicio ou 15 –
Primeira hipótese: Baixo tempo de duração da reunião em função dos objetivos do
sistema ou 20 – Alto grau de desvio dos participantes em relação aos objetivos do
sistema ou 31 – Baixo grau em que os participantes sabiam dos papéis que
deveriam desempenhar durante a reunião 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder.
Bibliografia: Segundo [Mathias 94], a referência utilizada foi [Curtis et. al
88] .
C) Grupo de perguntas referentes a cada objetivo da reunião.
Para cada objetivo traçado antes da reunião responda:
11) Para cada objetivo da reunião, apresente o grau de discussão que foi
gerada em torno de seus tópicos principais.
Objetivo: Verificar se houve uma discussão satisfatória em torno de todos os
tópicos de que a reunião deveria tratar ou se houve alguns temas sobre os quais
praticamente não houve discussões, não tendo sido alcançados plenamente todos
os objetivos da reunião.
Tipo da questão: relativa.
Conflito (grau baixo das respostas): Ausência de conflito funcional gerado
pelas discussões sobre os objetivos traçados.
Gerenciamento: Na próxima reunião, o líder deve enfatizar as discussões em
torno dos objetivos que tiveram pouca ênfase nas reuniões anteriores, cuidando
para que os participantes não se desviem do assunto discutido.
64
Causas: 12 – Baixa viabilidade do objetivo ou 13 – Baixo grau de
compatibilidade entre os objetivos da reunião ou 14 – Baixo grau de definição dos
objetivos da reunião antes do seu inicio ou 15 – Primeira hipótese: Baixo tempo
de duração da reunião em função dos objetivos do sistema ou 17 – Baixa
participação dos indivíduos durante a reunião ou 20 – Alto grau de desvio dos
participantes em relação aos objetivos do sistema ou 21 – Baixo grau de
conhecimento transmitido pelos participantes ou 22 – Baixa cooperação mostrada
pelo grupo ou 33 - Baixo grau de importância que os participantes classificam a
fase de levantamento de requisitos ou 29 – Alto grau com que os participantes
deixaram de emitir suas opiniões por achar que todos já possuíam o conhecimento
daquilo que eles poderiam expressar ou 30 – Baixa identificação dos participantes
com o grupo ou 31 – Baixo grau em que os participantes sabiam dos papéis que
deveriam desempenhar durante a reunião ou 32 – Baixo relacionamento do
sistema com as tarefas desempenhadas pelos participantes em seu trabalho ou 35 –
Baixa qualidade do controle e da coordenação de atividades efetuadas pelo líder.
Bibliografia: Segundo [Mathias 94], as referências utilizadas foram [Kahn
et.al 64] e [Wilensky 83].
12) Qual o grau de viabilidade de cada objetivo da reunião?
Objetivo: Saber se durante a reunião detectou-se que alguns objetivos não
podem ser satisfeitos, seja por necessitarem de recursos além do alcance da
organização, seja por precisarem de um tempo muito alto para a sua viabilização
ou por serem impossíveis de serem alcançados.
Tipo da questão: relativa.
Conflito (com grau baixo das respostas): Não funcional entre a necessidade
de se cumprir todos os objetivos traçados e a impossibilidade de realização de
alguns deles.
Gerenciamento: Excluir os objetivos inviáveis da pauta de discussões,
refazendo a agenda para as próximas reuniões.
Causas: 14 – Baixo grau de definição dos objetivos da reunião antes do seu
inicio. No caso desta regra ser falsa, será assumido que a causa é “Planejamento
incorreto, que delineou objetivos inviáveis”.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83] e [Wilensky 83].
65
D) Grupo de perguntas referentes aos objetivos da reunião como um
todo.
13) Qual o grau de compatibilidade entre os objetivos da reunião?
Objetivo: Saber se existem objetivos que não podem ser satisfeitos
simultaneamente, ou seja, se a realização de um objetivo implica na não
realização de outro.
Tipo de questão: relativa.
Conflito (com grau baixo das respostas): Não funcional entre a necessidade
de se atender todos os objetivos traçados e a incompatibilidade entre eles.
Gerenciamento: Os planejadores devem analisar os pontos de
incompatibilidade entre os objetivos e tentar efetuar alterações para que eles
passem a serem compatíveis entre si. Caso isto não seja possível, devem-se avaliar
quais são os objetivos mais importantes e eliminar aqueles com menos prioridade
da pauta de discussões.
Causas: 14 – Baixo grau de definição dos objetivos da reunião antes do seu
inicio. No caso desta regra ser falsa, será assumido que a causa é “Planejamento
incorreto, que delineou objetivos incompatíveis entre si”.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83], [Robbins 74] e [Wilensky 83].
14) Em que grau os objetivos da reunião foram bem definidos antes do seu
inicio?
Objetivo: Saber se não há dúvidas quanto ao que deve ser discutido na
reunião. Uma boa definição dos objetivos evita desvios em relação ao que deve
ser discutido, assim como minimiza a chance de surgirem ambigüidades e
conhecimento vago durante a reunião. A satisfação dos participantes também
aumenta quando vão para uma reunião com uma pauta bem definida.
Tipo da questão: absoluta.
Conflito (com grau baixo das respostas): Não funcional entre a necessidade
de se obter um conhecimento claro, preciso, estável e sem ambigüidades e os
objetivos mal definidos pelos planejadores da reunião.
66
Gerenciamento: Os planejadores devem definir de forma clara e sem
ambigüidades os objetivos da próxima reunião, disponibilizando a lista de
objetivos para os participantes antes da reunião seguinte.
Causa: Falha dos planejadores que não se preocuparam em definir
claramente os objetivos da reunião, trazendo prejuízos à reunião pela falta de uma
definição clara do que deveria ser discutido.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Andriole 90], [Curtis et. al 88], [Hampton 83], [Kahn et.al 64] e [Simões
70].
15) Qual a sua opinião em relação ao tempo de duração da reunião em
função dos objetivos da reunião?
Objetivo: No caso dos participantes terem achado curto o tempo de duração
da reunião, correlacionar com as respostas que dizem respeito à qualidade dos
requisitos obtidos e ao surgimento de idéias novas e questionamento de idéias
antigas para verificar se falhas nos requisitos obtidos surgiram em parte devido à
rápida duração da reunião.
Por outro lado, no caso de duração excessiva, verificar se houve discussões
muito longas que conduziram a impasses ou se houve muitos desvios em relação
aos objetivos da reunião que terminaram por gerar reuniões longas.
Tipo de questão: relativa.
Primeira hipótese (com grau baixo das respostas): A reunião foi muito
rápida, ocasionando poucas discussões e poucas idéias novas.
Conflito: Não funcional entre a necessidade de um tempo suficiente para
que surjam diversos pontos de vista e o tempo que ocorreu a reunião, insuficiente
para a obtenção e requisitos de qualidade.
Gerenciamento: Demonstrar a todos que a pressa em tomar decisões
acabará por conduzir a resultados de baixa qualidade. Revisões e manutenções no
sistema acabarão por exigir mais tempo do que se deseja, sendo mais vantajoso
um gasto maior de tempo nesta etapa de levantamento dos requisitos.
Causas: 2 - Alta necessidade de especialistas que possam sanar dúvidas em
relação ao requisito ou 6 – Baixo grau de beneficio que os requisitos trarão para os
participantes ou 11 – Baixo grau de discussão gerada em torno dos objetivos da
reunião ou 12 – Baixa viabilidade do objetivo ou 13 – Baixo grau de
67
compatibilidade entre os objetivos da reunião ou 14 – Baixo grau de definição dos
objetivos da reunião antes do seu inicio ou 17 – Baixa participação dos indivíduos
durante a reunião ou 31 – Baixo grau em que os participantes sabiam dos papéis
que deveriam desempenhar durante a reunião ou 32 – Baixo relacionamento do
sistema com as tarefas desempenhadas pelos participantes em seu trabalho ou 35 –
Baixa qualidade do controle e da coordenação de atividades efetuadas pelo líder
ou 37 – Baixo grau de satisfação em relação à maneira a qual a reunião foi
realizada.
Segunda hipótese (com grau alto das respostas): A reunião foi
excessivamente longa devido ao surgimento de muitos impasses durante as
discussões.
Conflito: Não funcional entre a necessidade de se alcançar resultados que
maximizem a satisfação do grupo e a quantidade de impasses surgidos, não
permitindo o alcance de soluções e conduzindo a um prolongamento exagerado do
tempo de discussão.
Gerenciamento: O líder deve auxiliar como mediador da negociação,
fazendo as intervenções necessárias para que as decisões não se estendam devido
a posições rígidas dos participantes.
Causas: 3 – Baixo grau de consenso entre os participantes em relação ao
requisito ou 19 – Alta resistência demonstrada pelo grupo em relação as novas
idéias ou 22 – Baixa cooperação mostrada pelo grupo ou 24 – Baixa importância
dos participantes para que os demais membros executem suas tarefas diárias com
qualidade ou 25 – Baixo grau com que os participantes embasaram suas posições
ou 26 - Baixo grau com que os participantes forneceram soluções para os
problemas que surgiram durante a reunião ou 30 – Baixa identificação dos
participantes com o grupo ou 34 – Alto grau com que as discussões conduziram a
um aumento de tensão do grupo ou 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder.
Terceira hipótese (com grau alto das respostas): Houve um desvio dos
objetivos da reunião, fazendo com que a reunião demorasse mais tempo do que o
necessário por levantar discussões sobre assuntos que não possuem relevância
com os objetivos traçados.
68
Conflito: Não funcional entre a necessidade de se manter os participantes
centrados nos temas discutidos e o gasto excessivo de tempo com assuntos fora da
relação dos objetivos do sistema.
Gerenciamento: O líder deve reconduzir os indivíduos aos temas centrais da
reunião, solicitando aos participantes que demonstrem a relevância dos assuntos
que parecem estar em desacordo com os objetivos propostos para a reunião.
Causas: 10 – Baixa coerência entre os requisitos obtidos e os objetivos da
reunião ou 14 – Baixo grau de definição dos objetivos da reunião antes do seu
inicio ou 20 – Alto grau de desvio dos participantes em relação aos objetivos do
sistema ou 31 – Baixo grau em que os participantes sabiam dos papéis que
deveriam desempenhar durante a reunião ou 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Cook et.al 87], [Curtis et.al 88], [Pressman 87] e [Simões 70].
E) Grupo de perguntas referentes a cada participante da reunião.
Para cada participante da reunião, responda (não considere o líder da
reunião, nem você mesmo nas suas respostas):
16) Qual o grau em que cada membro usou de coerção (ameaças) para fazer
prevalecer seus pontos de vista durante a reunião?
Objetivo: Verificar se algum participante se aproveitou do fato de possuir
alguma posição vantajosa na organização (mais poder, status, influência sobre a
carreira de algum participante) para fazer com que suas idéias prevalecessem
sobre a dos outros participantes.
Tipo da questão: absoluta.
Conflito (grau alto das respostas): Não funcional entre um dos objetivos do
método, o de levar em conta as posições individuais para o alcance de soluções e
o uso da coerção, limitando ou impedindo o surgimento de soluções que
pudessem levar em conta diferentes posições.
Gerenciamento: O líder deve propor que sejam levadas em conta as posições
dos participantes que sofreram coerção no estabelecimento das decisões. Deve,
ainda, conscientizar o indivíduo que usou de ameaças de que as idéias de todos
69
devem ser consideradas e que ninguém deve usar tentativas de coerção, pois a
opinião dos outros membros também é vital para a obtenção dos requisitos.
Causa: O participante que usou de coerção possui alguma vantagem em
relação aos demais, seja por possuir um status maior ou por ocupar um cargo
melhor na organização ou por possuir trunfos que o permite persuadir os demais
membros da reunião. Desta forma, o indivíduo utiliza a coerção como forma de
fazer valer suas idéias, prejudicando os resultados da reunião.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83] e [Robbins 74].
17) Qual o grau de participação de cada indivíduo durante a reunião?
Objetivo: Verificar se a participação de algum indivíduo foi baixa, fazendo
com que sua presença na reunião tenha parecido desnecessária.
Tipo da questão: relativa
Primeira hipótese (grau baixo das respostas): Houve um erro na convocação
dos participantes omissos, que não se manifestaram por não terem relação alguma
com os assuntos discutidos.
Conflito: Não funcional entre um planejamento correto, que só deveria
incluir na reunião pessoas que tivessem relação com os objetivos do sistema e a
convocação de indivíduos que não tem relação alguma com os objetivos traçados.
Gerenciamento: Exclusão dos indivíduos sem relação com o sistema das
próximas reuniões.
Causas: 32 - Baixo relacionamento do sistema com as tarefas
desempenhadas pelo participante em seu trabalho.
Segunda Hipótese (grau baixo das respostas): Um deslocamento dos
objetivos da reunião causou a omissão do participante, porque certos membros
acabaram tratando de assuntos diferentes das áreas de interesse do indivíduo
pouco participativo.
Conflito: Não funcional entre os objetivos da reunião e os assuntos
discutidos, que divergiam dos objetivos traçados.
Gerenciamento: O líder deve corrigir o rumo da próxima reunião, fazendo
uma monitoração constante sobre os participantes que estão se desviando dos
assuntos de interesse.
70
Causas: 10 – Baixa coerência entre os requisitos obtidos e os objetivos da
reunião ou 14 – Baixo grau de definição dos objetivos da reunião antes do seu
inicio ou 20 – Alto grau de desvio do participante em relação aos objetivos da
reunião ou 31 – Baixo grau em que o participante sabia dos papéis que deveria
desempenhar durante a reunião ou 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder.
Terceira Hipótese (grau baixo das respostas): Durante a reunião se observou
uma fraca integração entre os participantes.
Conflito: Não funcional entre a necessidade de uma alta coesão entre os
membros do grupo para que a comunicação surja fácil e naturalmente e a fraca
integração observada na prática entre os participantes.
Gerenciamento: Na próxima reunião, o líder deve fazer com que cada
participante se apresente aos demais, expondo suas habilidades e suas
experiências aos outros.
Estimular a coesão do grupo ressaltando características comuns aos
participantes, aumentando, desta forma, a identificação entre as pessoas.
Ressaltar a importância da contribuição individual de cada um para o
sucesso do projeto.
Causa: 23 – Baixo grau em que o trabalho do participante é conhecido pelos
demais membros da reunião ou 24 – Baixa importância do participante para que
os demais membros executem suas tarefas diárias com qualidade ou 30 – Baixa
identificação do participante com o grupo.
Quarta hipótese (grau baixo das respostas): O participante não foi aceito
pelo grupo.
Conflito: Não funcional entre a necessidade de aceitação de todos os
membros para uma boa produtividade na reunião e a rejeição do participante, que
acabou causando sua omissão durante a reunião.
Gerenciamento: O líder deve pedir aos participantes que possuem
antagonismos sobre algum membro da reunião, que separem problemas pessoais
de questões profissionais, para o beneficio do sistema. Caso os antagonismos
estejam difíceis de serem superados, o indivíduo rejeitado deve ser substituído por
outro que possua um melhor relacionamento com os demais membros do grupo.
71
Causa: 27 – Alto grau de antagonismo manifestado em relação ao
participante.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Simões 70] e [Telem 88].
18) Para cada participante, indique o grau que a utilização excessiva de
vocabulário difícil e/ ou termos técnicos prejudicou a compreensão dos requisitos.
Objetivo: Verificar se algum participante não soube colocar seu
conhecimento de forma compreensível para aqueles que não são especialistas em
sua área de atuação, prejudicando a aquisição de conhecimento.
Tipo da questão: relativa.
Conflito (grau alto das respostas): Não funcional entre o ideal de se obter
um conhecimento completo dos requisitos e a dificuldade de compreensão destes,
causada por uma lacuna semântica na comunicação entre os participantes.
Gerenciamento: O líder deve fazer com que os especialistas expliquem o
significado dos termos de difícil compreensão ou que manifestem seu
conhecimento de forma compreensível para quem não trabalha na sua área de
atuação.
Pode ser fornecida uma bibliografia para que os participantes que estão
tendo dificuldades de compreensão tirem suas dúvidas em relação aos termos
técnicos antes da próxima reunião.
Causa: Falta de conhecimento dos outros membros da reunião, dos
principais termos do projeto ou 21 - Baixo grau de conhecimento que o
participante transmitiu sobre os assuntos de sua alçada durante a reunião.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Cronan, Means 84], [Kim, Courtney 88], [McMaster, Grinder 80], [Prerau
87] e [Reubenstein 91].
19) Para cada participante, qual o grau de resistência demonstrado as novas
idéias que surgiram?
Objetivo: Verificar se a criativa teve boa receptividade ou se foram
observadas resistências a mudanças, reprimindo o surgimento de novas idéias.
Tipo da questão: absoluta.
72
Conflito (grau alto das respostas): Não funcional entre a resistência às novas
idéias e a necessidade de aceitação de novos pensamentos para a obtenção de
requisitos de qualidade.
Gerenciamento: O líder deve explicar aos indivíduos resistentes, que novas
formas de trabalho irão apenas alterar a maneira de executar suas rotinas atuais. E
que as resistências somente estão adiando a realização dos objetivos das reuniões
e contribuindo para que o sistema a ser desenvolvido não possua a qualidade
desejada.
Causa: Os indivíduos com resistência a novas idéias podem não estar
querendo alterar suas formas de trabalho atuais, seja por não aceitarem críticas
construtivas ou por medo de perda de poder ou de demissão.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Andriole 90], [Barondi et.al 86], [Hampton 83] e [Mailhiot 70].
20) Informe o grau em que cada participante se desviou dos objetivos
traçados pelos planejadores.
Objetivo: Verificar se a reunião está seguindo os caminhos traçados, que
conduzirá aos resultados esperados ou se as discussões estão seguindo por rumos
que não definirão requisitos coerentes com o que se pretende para o sistema.
Tipo da questão: relativa.
Conflito (grau alto das respostas): Não funcional entre os objetivos da
reunião e os assuntos discutidos, que não possuem relação com os objetivos.
Gerenciamento: Intervenções do líder a cada vez que as discussões
estiverem pendendo para assuntos que não são de interesse da reunião. Isto pode
ser feito através da solicitação da indicação da relevância do assunto mencionado
com os objetivos traçados. Se for demonstrada a relevância, o tópico deve ser
levado em conta. Caso contrário, o próprio participante perceberá que está se
desviando dos objetivos, sendo a reunião reconduzida ao caminho desejado.
Causas: 12 – Baixa viabilidade do objetivo ou 13 – Baixo grau de
compatibilidade entre os objetivos da reunião ou 14 – Baixo grau de definição dos
objetivos da reunião antes do seu inicio ou 31 – Baixo grau em que o participante
sabia dos papéis que deveria desempenhar durante a reunião ou 32 – Baixo
relacionamento do sistema com as tarefas desempenhadas pelo participante em
73
seu trabalho ou 35 – Baixa qualidade do controle e da coordenação de atividades
efetuadas pelo líder.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Floyd et. al 89] e [Simões 70].
21) Indique o grau de conhecimento que cada participante transmitiu sobre
os assuntos de sua alçada durante a reunião.
Objetivo: Verificar se foram convidados especialistas com um bom
conhecimento do seu domínio de aplicação. Observar ainda se omissões ou
dificuldades de expressão, entre outras causas, podem ter feito com que alguém
não transmitisse conhecimento suficiente sobre sua área de trabalho.
Tipo da questão: relativa.
Primeira hipótese (grau baixo das respostas): As informações que o membro
transmitiu ficaram abaixo do esperado porque o indivíduo não teve um
comportamento participativo durante a reunião.
Conflito: Ausência do conflito funcional gerado pelo compartilhamento dos
assuntos referentes às áreas de atuação de todos os membros. Ele não foi
identificado por causa do conhecimento insuficiente que o indivíduo efetivamente
transmitiu para os demais participantes.
Gerenciamento: Incentivar o membro a ter uma participação mais ativa,
devendo o líder fazer perguntas diretamente a ele quando o assunto estiver
girando em torno de uma de suas áreas de atuação.
Causas: 17 – Baixa participação do indivíduo durante a reunião ou 22 –
Baixa cooperação mostrada pelo participante ou 29 – Alto grau com que o
participante deixaram de emitir suas opiniões por achar que todos já possuíam o
conhecimento daquilo que eles poderiam expressar ou 30 – Baixa identificação do
participante com o grupo ou 32 – Baixo relacionamento do sistema com as tarefas
desempenhadas pelo participante em seu trabalho ou 33 - Baixo grau de
importância que os participantes classificam a fase de levantamento de requisitos
ou 35 – Baixa qualidade do controle e da coordenação de atividades efetuadas
pelo líder ou 37 – Baixo grau de satisfação em relação à maneira a qual a reunião
foi realizada.
74
Segunda hipótese (grau baixo das respostas): O participante não possui
conhecimentos suficientes sobre sua área de atuação, não tendo apresentado, em
conseqüência, informações substancias para os demais indivíduos.
Conflito: Não funcional entre o conhecimento que se esperava que o
participante tivesse e o fraco conhecimento observado na prática.
Gerenciamento: Excluir o participante das próximas reuniões, convidando
outra pessoa que realmente domine o assunto. Convidar um consultor externo a
organização para dar apoio nas áreas em que surgiu uma deficiência de
conhecimento.
Causas: 5 – Baixo grau de conhecimento dos requisitos pelo participante.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Curtis et. al 88], [Deutsch 73], [Kahn et. al 64] e [Kim, Courtney 88].
22) Qual o grau de cooperação demonstrado por cada participante da
reunião?
Objetivo: Ver se o ambiente da reunião foi de cooperação entre os
participantes, facilitando a troca de idéias e a obtenção de requisitos de qualidade.
Tipo da questão: relativa.
Primeira hipótese (grau baixo das respostas): Os interesses individuais
estavam acima dos interesses da organização.
Conflito: Não funcional entre o método utilizado para elicitar os requisitos
(reuniões baseadas em trabalho cooperativo) e o clima em que a reunião se
verificou (individualista ou competitivo).
Gerenciamento: Mostrar aos indivíduos que o sucesso dos objetivos da
reunião depende da maximização dos resultados de todos os participantes e que
soluções individualistas somente atrasarão o alcance dos objetivos desejados.
Causas: 6 – Baixo benefício que o requisito trará para o participante ou 33 -
Baixo grau de importância que os participantes classificam a fase de levantamento
de requisitos ou 32 – Baixo relacionamento do sistema com as tarefas
desempenhadas pelo participante em seu trabalho.
Segunda hipótese (grau baixo das respostas): Inibições ou falta de
entrosamento entre os participantes geraram um clima de pouca cooperação.
75
Conflito: Não funcional entre o método utilizado para elicitar os requisitos
(reuniões baseadas em trabalho cooperativo) e o clima em que a reunião se
verificou (individualista ou competitivo).
Gerenciamento: Deve ser promovida uma maior integração entre os
indivíduos, fazendo com que cada um se apresente aos demais, expondo sua
experiência anterior e suas habilidades profissionais, eliminando inibições
porventura existentes e aumentando a autoconfiança dos indivíduos mais tímidos.
Causas: 17 – Baixa participação do indivíduo durante a reunião ou 30 –
Baixa identificação do participante com o grupo ou 35 – Baixa qualidade do
controle e da coordenação de atividades efetuadas pelo líder.
Terceira hipótese (grau baixo das respostas): O(s) participante(s) não foram
aceito(s) pelo grupo.
Conflito: Não funcional entre a necessidade de cooperação entre todos os
participantes e a não aceitação de determinado(s) indivíduo(s), o que acabou
prejudicando o espírito cooperativo entre os membros do grupo.
Gerenciamento: O líder deve conversar com os participantes que possuem
antagonismos, pedindo que possíveis desavenças pessoais sejam deixadas de lado
para não prejudicar o trabalho em equipe. Somente o aspecto profissional deve ser
levado em conta nas reuniões de elicitação de requisitos.
Causa: 27 – Alto grau de antagonismo em relação ao participante.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Duarte et. al 92], [Easterbrook 90], [Ellis et. al 91], [Macaulay 92] e
[Stefik et. al 87].
23) Para cada participante da reunião, informe o grau em que você conhece
seu trabalho (ou o grau que passou a conhecer após a reunião).
Objetivo: Saber se os membros possuem conhecimento do tipo de atividades
desempenhadas pelos demais membros, pois a partir do conhecimento do
trabalho, das dificuldades e das necessidades dos demais, a aceitação de pontos de
vista distintos se torna mais fácil.
Tipo da questão: absoluta.
Conflito (grau baixo das respostas): Não funcional entre a necessidade do
conhecimento do trabalho de cada participante pelos demais membros para
76
facilitar a coesão, a integração, e a aceitação de pontos de vista distintos e o
desconhecimento do trabalho do(s) participante(s), o que dificulta a obtenção de
bons resultados durante a reunião.
Gerenciamento: O líder deve pedir ao(s) participante(s) que não tem seu
trabalho conhecido que faça(m) sua apresentação, explicando suas tarefas, suas
necessidades, suas dificuldades no dia a dia e suas expectativas em relação ao
sistema proposto para facilitar a compreensão dos motivos de suas posições pelos
demais participantes.
Causa: A reunião foi efetuada com algum sub-grupo que não trabalha junto,
ocasionando o desconhecimento do trabalho do(s) outro(s) participante(s).
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Duarte et. al 92], [Easterbrook 90] e [Simões 70].
24) Para cada participante, qual o grau de importância para você, que ele
execute suas tarefas diárias com rapidez e com a qualidade desejada?
Obs.: O líder não responde esta questão.
Objetivo: Saber o grau de dependência entre os participantes da reunião para
a correta execução das atividades diárias de cada indivíduo. Um alto grau de
dependência indica que os indivíduos procurarão agir de forma cooperativa, pois o
sucesso na execução de suas tarefas depende da boa execução das tarefas de
outros participantes.
Tipo de questão: absoluta.
Conflito (grau baixo das respostas): Não Funcional entre a necessidade de
dependência entre os participantes da reunião para a qualidade de suas tarefas
diárias, e o baixo grau de dependência identificado nas respostas.
Gerenciamento: Estimulo a este tipo de situação desde a fase de
planejamento da reunião, onde devem ser convidados indivíduos com alto grau de
dependência funcional. Quando forem substituídos participantes ao longo das
reuniões subseqüentes, este tipo de dependência também deve ser buscado nos
novos participantes. Isto é importante porque se um participante não tiver
interesse em cooperar com os outros estará prejudicando a si próprio. Desta
forma, a cooperação será sempre mantida para que a própria pessoa não se
prejudique ao deixar de cooperar.
77
Causa: A estrutura da organização, onde departamentos e indivíduos muitas
vezes não estão ligados, sendo independentes. Possibilitando que em certos casos,
o sucesso de um indivíduo não esteja condicionado a um bom trabalho de outras
pessoas.
Bibliografia: Conforme citado em [Mathias 94], a referência utilizada foi
[Kahn et. al 64].
25) Para cada participante, informe o grau com que ele embasou suas
posições, expondo argumentos para a sua linha de pensamento ao invés de
simplesmente colocar suas idéias sem maiores explicações.
Objetivo: Saber se os requisitos foram obtidos a partir de um conhecimento
que foi apresentado de forma completa, aumentando a probabilidade da criação de
requisitos de qualidade.
Tipo da questão: relativa.
Conflito (grau baixo das respostas): Não funcional entre o ideal de se obter
requisitos corretos e estáveis e o conhecimento sem base que foi apresentado
pelos participantes.
Gerenciamento: O líder deve solicitar aos participantes que embasem sua
linha de pensamento, apresentado fatos e hipóteses que confirmem as idéias que
estão sendo apresentadas. Se isto não puder ser feito, deve ser questionada a
veracidade e a relevância do conhecimento que foi colocado, através de
questionamentos que o líder deve estimular entre os participantes.
Causas: 6 – Baixo benefício que o requisito trará para os participantes ou 11
– Baixo grau de discussão gerada em torno dos objetivos da reunião ou 17 – Baixa
participação do indivíduo durante a reunião ou 21 – Baixo grau de conhecimento
transmitido pelo participante ou 22 – Baixa cooperação mostrada pelo participante
ou 29 - Alto grau com que o participante deixou de emitir suas opiniões por achar
que todos já possuíam o conhecimento daquilo que eles poderiam expressar ou 30
– Baixa identificação do participante com o grupo ou 32 – Baixo relacionamento
do sistema com as tarefas desempenhadas pelo participante em seu trabalho ou 33
- Baixo grau de importância que os participantes classificam a fase de
levantamento de requisitos ou 35 – Baixa qualidade do controle e da coordenação
de atividades efetuadas pelo líder.
78
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [McMaster, Grinder 80], [Mumford 87] e [Stefik et. al 87].
26) Qual o grau em que cada indivíduo forneceu soluções para os problemas
que surgiram durante a reunião.
Objetivo: Saber se cada indivíduo contribuiu para a resolução de problemas,
fornecendo soluções que podem ter ajudado no estabelecimento de um consenso.
Tipo da questão: relativa.
Primeira hipótese (grau baixo das respostas): O indivíduo foi pouco
participativo e cooperativo durante a reunião.
Conflito: Ausência do conflito funcional que surge da participação e
contribuição de todos no alcance da solução final não identificado.
Gerenciamento: O líder deve solicitar uma solução de um problema por
parte do indivíduo quando as discussões estiverem se concentrando dentro da sua
área de atuação, estimulando o surgimento de idéias.
Causas: 6 – Baixo benefício que o requisito trará para os participantes ou
17 – Baixa participação do indivíduo durante a reunião ou 21 – Baixo grau de
conhecimento transmitido pelo participante ou 22 – Baixa cooperação mostrada
pelo participante ou 33 - Baixo grau de importância que os participantes
classificam a fase de levantamento de requisitos ou 27 – Alto grau de antagonismo
manifestado em relação ao participante ou 30 – Baixa identificação do
participante com o grupo ou 32 – Baixo relacionamento do sistema com as tarefas
desempenhadas pelo participante em seu trabalho ou 35 – Baixa qualidade do
controle e da coordenação de atividades efetuadas pelo líder.
Segunda hipótese (grau baixo das respostas): O participante foi muito
participativo, porém não cooperativo.
Conflito: Ausência do conflito funcional que surge da contribuição de todos
no alcance da solução final não identificado.
Gerenciamento: O líder deve estimular o surgimento de idéias, por parte
deste indivíduo, principalmente por ser muito participativo, o que pode facilitar.
Mas principalmente tentar mostrar para ele, que o mais importante é participar de
forma construtiva, para tentar evitar perda de tempo com assuntos que não
79
desnecessário e improdutivos, que podem insistentemente surgir por parte deste
participante, o que acaba atrasando e prejudicando o andamento da reunião.
Causas: 6 – Baixo benefício que o requisito trará para o participante ou (17
– Alta participação do indivíduo durante a reunião e 22 – Baixa cooperação
mostrada pelo participante) ou 21 – Baixo grau de conhecimento transmitido pelo
participante ou 33 - Baixo grau de importância que o participante classifica a fase
de levantamento de requisitos ou 27 – Alto grau de antagonismo manifestado em
relação ao participante ou 30 – Baixa identificação dos participantes com o grupo
ou 32 – Baixo relacionamento do sistema com as tarefas desempenhadas pelo
participante em seu trabalho ou 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83] e [Simões 70].
27) Qual o grau de antagonismo que você possui em relação a cada
participante da reunião?
Objetivo: Saber se existiram antagonismos em relação a algum participante,
o que pode ter prejudicado o clima de cooperação da reunião.
Tipo da questão: absoluta.
Conflito (grau alto das respostas): Não funcional entre o ideal de haver um
clima de harmonia e de integração entre todos os participantes da reunião e os
antagonismos existentes, que podem ter prejudicado o clima de cooperação e de
troca de conhecimento entre os membros.
Gerenciamento: Os participantes que possuem antagonismos devem ser
chamados pelo líder, que deve solicitar que as diferenças pessoais sejam
resolvidas ou deixadas de lado para que não haja prejuízo ao clima de cooperação
da reunião.
Causa: Desavenças entre os membros devido a acontecimentos passados ou
discussões durante a reunião podem ter causado o surgimento de antagonismos
entre alguns indivíduos.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83] e [Simões 70].
80
28) Qual o grau de monopolização da discussão por parte de cada
indivíduo? (Indicar grau acima de 4, somente quando o participante tiver
prejudicado a manifestação dos demais membros através do domínio da
comunicação).
Objetivo: Verificar se houve alguém que praticamente tenha feito uso
exclusivo dos canais de comunicação, não tenha dado chance aos demais
membros de se manifestarem.
Tipo da questão: absoluta.
Conflito (grau alto das respostas): Não funcional entre o objetivo de
promover a integração de diversos pontos de vista e a participação individualista
de um ou mais membros que dominaram a reunião, prejudicando a manifestação
das idéias dos outros membros.
Gerenciamento: O líder deve intervir quando indivíduos monopolizadores
estiverem fazendo uso da palavra por tempo excessivo, solicitando que suas
conclusões sejam logo efetuadas ou pedindo licença e sugerindo a participação de
outros membros no assunto que está sendo tratado.
Causa: O indivíduo monopolizador fala em excesso, esquecendo-se de que
há outras pessoas na reunião que também tem o mesmo direito do uso da palavra.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83], [Simões 70] e [Weil et.al 66].
F)Grupo de perguntas referentes ao participante que está respondendo
o questionário.
29) Em que grau você deixou de emitir suas opiniões ou de apresentar suas
experiências por achar que todos já possuíam o conhecimento do que você poderia
expressar?
Obs.: O líder não responde esta questão.
Objetivo: Saber se o participante deixou de se manifestar por achar que
suas opiniões já faziam parte do senso comum entre os membros da reunião. É
sempre importante emitir suas opiniões, pois as pessoas muitas vezes acham
desnecessário falar sobre o que lhes parece óbvio, acabando por causar
importantes omissões que somente serão lembradas durante o projeto ou após o
81
sistema estar concluído. Ou seja, esta pergunta tenta descobrir se ocorreu o
problema do conhecimento tácito entre os participantes da reunião.
Tipo da questão: absoluta.
Conflito (grau alto das respostas): Não funcional entre a necessidade de
uma comunicação aberta sobre tudo o que for relevante para o grupo e a não
manifestação de alguns participantes, o que pode causar lacunas no conhecimento
adquirido.
Gerenciamento: O participante deve expor, nas próximas reuniões, o
conhecimento não apresentado na reunião anterior e, se for necessário, devem ser
efetuadas discussões, questionamentos e reavaliações sobre as idéias que
passaram a serem apresentadas.
Causa: O indivíduo que deixou de emitir suas opiniões imaginou que os
demais membros já conheciam suas idéias ou já haviam passado por experiências
semelhantes. Freqüentemente isto ocorre porque o indivíduo já possui um
conhecimento sobre um determinado assunto tão impregnado em sua mente que
sem perceber parte do pressuposto de que as outras pessoas possuem uma base de
conhecimento semelhante a sua, chamamos isso de conhecimento tácito.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Kim, Courtney 88] e [Simões 70].
30) Em que grau você se identificou com o grupo?
Obs.: O líder não responde esta questão.
Objetivo: Saber se o indivíduo identificou interesses comuns, afinidades e
comportamentos com os demais membros do grupo. A identificação é importante
para que o grupo possua uma boa produtividade.
Tipo da questão: absoluta.
Conflito (grau baixo das respostas): Não funcional entre a necessidade de
todos os participantes se sentirem parte do todo, identificando-se com o grupo, o
que ajuda na obtenção de requisitos de qualidade e a fraca identificação do(s)
participante(s) observada na prática.
Gerenciamento: O líder deve procurar ressaltar as semelhanças entre o(s)
participante(s) com baixa identificação e o restante do grupo. Necessidades e
problemas comuns também devem ser colocados, visando a um aumento da
identificação do(s) participante(s) com o grupo.
82
Causa: A baixa identificação do participante com o grupo vem a partir da
falta de visualização de objetivos, comportamentos e necessidades semelhantes as
dos demais indivíduos.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Hampton 83] e [Simões 70].
31) Em que grau você sabia dos papéis que deveria desempenhar durante a
reunião?
Objetivo: Saber se os participantes estavam cientes do tipo de
conhecimento que deveriam expressar e que função teriam durante a reunião, ou
seja, em que áreas deveriam expressar suas opiniões.
Tipo de questão: absoluta.
Conflito (grau baixo das respostas): Não funcional entre um planejamento
adequado, que deveria colocar todos os participantes a par da agenda da reunião e
dos papeis que eles deveriam desempenhar e o planejamento inadequado
observado na prática, que não colocou algum participante plenamente a par do que
era esperado dele durante a reunião.
Gerenciamento: Antes da próxima reunião, os planejadores devem deixar
bem claro para os participantes a agenda da reunião e a contribuição que é
esperada deles durante o estabelecimento dos requisitos.
Causa: Falhas no planejamento causaram este conflito, pois os
planejadores deveriam expor aos indivíduos convidados a agenda da reunião e a
participação que seria esperada deles durante os debates.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Carvalho, Fuks 92], [Cyert, MacCrimmon 68] e [Duarte et. al 92].
32) Qual o grau de relacionamento do sistema a ser desenvolvido com as
tarefas que você desempenha em seu trabalho?
Obs.: O líder não responde esta questão.
Objetivo: Saber se o participante está diretamente relacionado com os
objetivos do sistema, o que significa que deseja se observar se a convocação do
indivíduo para a reunião foi justificável.
Conflito (grau baixo das respostas): Não funcional entre um planejamento
correto, que só deveria considerar a convocação para a reunião de pessoas que
83
tivessem relação com o sistema a ser desenvolvido e a participação de indivíduos
que não estão envolvidos com os assuntos pertinentes ao sistema.
Gerenciamento: Excluir da próxima reunião os indivíduos sem relação
com os objetivos do sistema e verificar se há a necessidade de convocar em seu
lugar participantes que estejam relacionados com o sistema e que possuam um
bom conhecimento das áreas relevantes à reunião.
Causa: Falhas no planejamento fizeram com que indivíduos sem relação
com o sistema tivessem sido convocados para a reunião.
Bibliografia: Conforme citado em [Mathias 94], a referência utilizada foi
[Telem 88].
33) Com qual grau de importância você classifica a fase de levantamento
de requisitos, isto é, a fase onde procuramos entender as necessidades do projeto e
descrevê-las de forma mais clara possível?
Objetivo: Verificar se o participante acha importante o processo o qual
está envolvido.
Conflito (grau baixo das respostas): Não funcional entre a importância do
indivíduo está inserido em um processo que ele ache relevante e importante e a
baixa importância dada pelo participante ao processo.
Gerenciamento: O líder deve mostrar aos participantes a importância do
processo de elicitação de requisitos para o desenvolvimento do software. Se o
baixo interesse mostrado pelo(s) participante(s) continuar, o líder deve, se
possível, substituí-lo por outro que entenda a importância do processo. Já que uma
pessoa inclusa num processo que não aprova, não executa suas tarefas de maneira
cooperativa e proveitosa.
Causa: Falta de entendimento do participante da importância do processo
de levantamento de requisitos para um bom desenvolvimento de software.
G) Grupo de perguntas referentes à organização da reunião.
34) Em que grau as discussões que surgiram conduziram a um aumento na
tensão do grupo?
Objetivo: Verificar os efeitos não funcionais do estimulo a novas idéias.
Muitas vezes, pode surgir um grau de tensão elevado devido a hostilidades
84
anteriores à reunião entre os participantes ou devido a características de
personalidade de alguns participantes (agressivos, dominadores, sem habilidades
no trato social, resistentes a mudanças).
Tipo da questão: absoluta.
Conflito (grau alto das respostas): Não funcional entre a necessidade de se
promover o surgimento de diversos pontos de vista a partir da discussão amigável
de idéias e o clima tenso observado entre os participantes devido ao surgimento de
idéias distintas e de divergências.
Gerenciamento: Alteração da variável humana, no caso do problema ser
devido a características dos participantes, onde o líder deve pedir aos membros
mais tensos que não levem as discussões para o lado pessoal e que não encarem
concessões como um sinônimo de perdas.
Intervenção de um consultor externo para auxiliar no processo de tomada
de decisão, evitando que os ânimos se tornem muito exaltados ou que o excesso
de tensão influa negativamente nas decisões tomadas.
Causa: Hostilidades anteriores a reunião entre alguns participantes ou
características de personalidade de alguns membros (agressivos, dominadores,
sem habilidades no trato social, resistentes a mudanças) são causas prováveis para
este conflito.
Bibliografia: Conforme citado em [Mathias 94], a referência utilizada foi
[Weil et. al 66].
35) Qual a qualidade do controle e da cooperação de atividades efetuados
pelo líder durante a reunião?
Objetivo: Saber se a reunião foi bem conduzida e controlada pelo líder.
Tipo da questão: relativa.
Primeira hipótese (grau baixo das respostas): O líder apresentou falhas no
controle e na coordenação de atividades, mas foi bem aceito pelo grupo, não
havendo antagonismos dos participantes em relação a ele.
Conflito: Não funcional entre a proposta do método de se efetuarem
reuniões bem estruturadas e a forma pela qual ela foi conduzida pelo líder.
Gerenciamento: Os planejadores devem solicitar ao líder que este faça
uma avaliação de suas falhas, procurando corrigir as deficiências de controle e
85
coordenação de atividades. O líder deve ter uma postura mais firme, não deixando
que a reunião seja levada de uma forma muito solta.
Causas: 36- Baixo grau de antagonismo do grupo em relação ao líder.
Segunda hipótese (grau baixo das respostas): O líder apresentou falhas no
controle e na coordenação de atividades e não foi aceito pelo grupo, podendo ter
havido antagonismos em relação a ele.
Conflito: Não funcional entre a proposta do método de se efetuarem
reuniões bem estruturadas e a forma pela qual ela foi conduzida pelo líder.
Gerenciamento: Os planejadores devem substituir o líder por outro que
possua características mais adequadas para exercer a liderança e para manter um
bom relacionamento interpessoal.
Causas: 36- Alto grau de antagonismo do grupo em relação ao líder.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Macaulay 92], [Simões 70] e [Telem 88].
36) Qual o seu grau de antagonismo em relação ao líder da reunião?
Objetivo: Saber se os participantes possuem alguma coisa contra o líder da
reunião, o que pode prejudicar as tarefas de coordenação de atividades e o próprio
espírito cooperativo que a reunião deveria ter.
Tipo da questão: absoluta.
Conflito (grau alto das respostas): Não funcional entre a necessidade de
haver um clima de harmonia e de entendimento entre os membros da reunião e o
antagonismo observado entre o(s) participante(s) e o líder.
Gerenciamento: Os participantes que manifestaram antagonismos em
relação ao líder, assim como o líder, devem ser chamados pelos planejadores, que
devem tentar que todos resolvam suas diferenças pessoais antes da próxima
reunião visando a obtenção de bons resultados na elicitação de requisitos. Caso os
antagonismos sejam difíceis de superar, deve ser providenciada a substituição do
líder na próxima reunião.
Causa: Problemas pessoais já existentes no passado entre os participantes e
o líder ou então discussões surgidas durante a reunião podem ter causado o
antagonismo entre os participantes e o líder.
86
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Carvalho, Fuks 92], [Hampton 83] e [Simões 70].
37) Qual o seu grau de satisfação em relação à maneira a qual a reunião foi
realizada.
Objetivo: Saber se a reunião foi realizada de maneira adequada. Se esta foi
não presencial, saber se o meio de comunicação utilizado para realizá-la foi
satisfatório ou se apresentou problemas. Já se a reunião foi realizada de maneira
presencial, identificar se o local foi adequado, ou seja, se oferecia condição
mínima para que os participantes não sofram interferências, não se sintam
incomodados e não possuam nenhuma dificuldade de conduzir a reunião.
Tipo da questão: absoluta.
Conflito (grau baixo das respostas): Não funcional entre a importância de
uma reunião bem realizada e a reunião que foi realizada de maneira inadequada,
podendo ter prejudicado bastante no seu resultado final.
Gerenciamento: No caso da reunião realizada de maneira não presencial,
providenciar um meio de comunicação melhor para realização da próxima.
No caso da realizada de maneira presencial, procurar identificar o que prejudicou
os participantes e providenciar as melhoras para a próxima reunião.
Causa: Um planejamento mal feito da reunião realizado pelo planejador.
H) Grupo de perguntas referentes ao planejamento para as demais
fases do projeto.
38) Qual o grau em que as diretrizes estabelecidas pelos participantes serão
suficientes para garantir o cumprimento dos requisitos durante o desenvolvimento
do sistema?
Objetivo: Saber se foi dada continuidade a tarefa de planejamento adequado
para garantir o cumprimento dos requisitos, o que inclui o estabelecimento de
diretrizes para o futuro.
Tipo da questão: relativa.
Conflito (grau baixo das respostas): Não funcional entre a necessidade de
serem fixadas diretrizes para o cumprimento das decisões tomadas na reunião e a
ausência de diretrizes para as próximas etapas do projeto.
87
Gerenciamento: O líder deve fixar, juntamente com os demais participantes,
as diretrizes que visam a fornecer continuidade as decisões dos membros da
reunião e aos objetivos traçados pelos planejadores.
Causas: 15 – Primeira Hipótese: Baixo tempo de duração da reunião em
função dos objetivos do sistema ou 35 – Baixa qualidade do controle e da
coordenação de atividades efetuadas pelo líder. No caso de nenhuma destas causas
ser verdadeira, será assumido que a causa é “Falhas na continuidade do
planejamento pelo líder e pelos membros, pois estes não se preocuparam em
definir diretrizes que assegurassem o cumprimento dos requisitos obtidos”.
Bibliografia: Conforme citado em [Mathias 94], a referência utilizada foi
[Simões 70].
39) Qual o grau em que os compromissos firmados entre os participantes
serão suficientes para garantir que os requisitos sejam mantidos e atendidos pelo
sistema?
Objetivo: Saber se as pessoas firmaram compromissos (assumiram
responsabilidades) após as discussões, o que aumenta a probabilidade de que não
haja deslocamento das diretrizes traçadas antes e após a reunião.
Tipo da questão: relativa.
Conflito (grau baixo das respostas): Não funcional entre o baixo número de
compromissos que foram firmados após a reunião e a necessidade de se manter os
participantes comprometidos com o sucesso do projeto. A ausência de
compromissos da margem a que os participantes não cumpram as diretrizes
traçadas ou que se desviem dos objetivos devido ao não comprometimento em
relação ao que foi estabelecido após a reunião, eximindo-se de responsabilidades
no caso de insucesso do projeto.
Gerenciamento: O líder deve fazer com que os indivíduos firmem os
compromissos necessários ao alcance dos objetivos de acordo com as áreas de
atuação de cada membro da reunião, levando em conta a participação que cada
indivíduo teve nos requisitos obtidos após as discussões. Os compromissos
também devem ser firmados por aqueles que possuem responsabilidades na
execução das mudanças propostas e nas diretrizes a serem seguidas.
Causas: 15 – Primeira Hipótese: Baixo tempo de duração da reunião em
função dos objetivos do sistema ou 32 – Baixo relacionamento do sistema com as
88
tarefas desempenhadas pelos participantes em seu trabalho ou 35 – Baixa
qualidade do controle e da coordenação de atividades efetuadas pelo líder ou 38 –
Poucas diretrizes fixadas para garantir o cumprimento dos requisitos durante o
desenvolvimento do sistema. Se nenhuma destas causas for verdadeira, será
assumida a causa “Falhas na continuidade do planejamento pelo líder e pelos
membros, pois estes não se preocuparam em estabelecer compromissos que
garantissem que as diretrizes traçadas e os requisitos obtidos fossem cumpridos”.
Bibliografia: Conforme citado em [Mathias 94], as referências utilizadas
foram [Andersen et. al 86], [Easterbrook 90], [Prerau 87], [Robbins 74] e [Simões
70].
Com o término da apresentação de todas as perguntas do novo questionário,
explicaremos o motivo de todas as alterações realizadas no questionário original
que levaram a formação deste que acabou de ser apresentado.
3.4.3. Justificativas da reformulação do questionário
Nesta seção justificaremos as alterações realizadas em algumas perguntas do
questionário e também o motivo da retirada de outras.
Este estudo começou a partir da análise das questões vitais descritas em
[Mathias 94], que seriam as questões determinantes na condição de encerramento
do ciclo de reuniões. Ou seja, a condição de encerramento do ciclo de reuniões é a
não existência de conflitos em questões vitais. Concordando com a importância
das questões vitais, as questões relativas relacionadas com as vitais começaram a
serem analisadas. E assim um novo ciclo de questões começou a ser formado.
O principal objetivo desta reformulação foi a necessidade de diminuir o
número de perguntas, otimizando e simplificando o questionário. Será feita uma
justificativa para cada pergunta alterada ou retirada.
A ordem das justificativas vai se basear na seqüência em que as perguntas
aparecem no questionário de [Mathias 94]. Assim, como toda citação de grupo e
numeração das perguntas nesta seção, terá esta mesma referência.
Grupo A (Grupo de perguntas referentes a cada requisito obtido durante a
reunião)
89
1) Qual o grau de diferença entre os pontos de vista apresentados pelos
participantes em relação ao requisito?
Pergunta Removida!
Justificativa:
Esta pergunta foi removida, pois através das perguntas do grupo A de
número 2 (Para cada requisito, classifique o seu grau de ambigüidade ou falta de
clareza e precisão ao final da reunião?), número 3 (Qual o grau de necessidade de
especialistas adicionais que possam sanar dúvidas ou esclarecer melhor certos
pontos que foram discutidos referentes ao requisito?) e número 4 (Qual o grau de
consenso surgido entre os participantes no final da reunião em relação a cada
requisito obtido?), eu consigo obter os mesmos resultados e ainda com abordagens
mais diretas. Sendo assim possível o descarte desta.
5) Qual o grau de interesse que você manifestou em relação a cada requisito
obtido?
Pergunta removida!
Justificativa:
Esta pergunta foi removida, pois através da pergunta do Grupo A de número
2 (Qual o grau de consenso surgido entre os participantes no final da reunião em
relação a cada requisito obtido?), onde se pretende otimizar a satisfação dos
participantes e principalmente da de número 8 (Qual o benefício que cada
requisito obtido, quando implementado, trará para a execução de suas tarefas?),
que cobre o objetivo da pergunta eliminada e outros, sendo uma pergunta mais
abrangente e completa, dando a possibilidade da eliminação da 5.
Para garantir a completeza da pergunta 8, inserimos no gerenciamento da
quinta hipótese desta pergunta parte do gerenciamento da pergunta 5, onde esta
sugere ao líder lançar dúvidas e perguntas diretas para que os especialistas das
áreas que despertam pouco interesse, para que estes manifestem seu
conhecimento.
8) Qual o benefício que cada requisito obtido, quando implementado, trará
para a execução de suas tarefas?
Pergunta modificada!
90
O gerenciamento da terceira hipótese trata da importância de se convidar
para a reunião somente pessoas diretamente relacionadas com o sistema. Porém a
este gerenciamento, acrescentamos a importância do especialista na reunião,
apesar deste, se for o caso, não ter relação direta com o sistema.
Nesta pergunta verificamos a possibilidade de juntar a quinta hipótese à
quarta, pois a quinta hipótese trata do mesmo conflito da quarta, que são requisitos
de baixa qualidade. Na quinta hipótese fica explícito que os participantes tem uma
relação direta com o sistema apesar dos requisitos mal definidos. Já na quarta não
há nenhuma referência a relação dos participantes com o sistema, porém as duas
hipóteses se complementam.
Como acontece na terceira hipótese, onde ela trata as duas condições juntas,
ou seja, a baixa qualidade dos requisitos como causa da não relação dos
participantes com o sistema. Com a junção da quarta hipótese com a quinta, será
tratado o conflito gerado pela má qualidade dos requisitos apesar da relação dos
participantes com o sistema. Conseqüentemente combinamos o gerenciamento,
objetivo e causas das hipóteses na hipótese resultante da junção. Tornando as
hipóteses da pergunta mais concisas e coerentes.
Grupo B (Grupo de perguntas referentes aos requisitos como um todo).
13) Em que grau o tempo previsto para o projeto é suficiente para garantir
que todos os requisitos obtidos sejam atendidos?
Pergunta removida!
Notamos a necessidade da exclusão desta pergunta, por ser classificada
como uma pergunta de difícil análise. Já que estamos na fase de elicitação dos
requisitos, onde ainda não temos a lista dos requisitos do sistema pronta para ser
feito este tipo de análise.
Durante a elicitação tanto podem surgir novos requisitos, quanto modificar
ou excluir os já existentes por motivos diversos. Ou seja, esta lista fica em
constante mudança até o fechamento do ciclo de reuniões que visa elicitar os
requisitos do sistema. Só assim então, seria possível uma melhor análise desta
pergunta.
É importante lembrar, que mesmo após o fechamento da elicitação da lista
de requisitos, esta estará sempre aberta a possíveis modificações, porém espera-se
que menos intensas.
91
Grupo C (Grupo de perguntas referentes a cada objetivo da reunião).
14) Para cada objetivo da reunião, apresente o grau de discussão que foi
gerada em torno de seus tópicos principais.
Pergunta modificada!
Mudamos a descrição do tipo de conflito identificado por esta pergunta,
pois o que buscamos com ela é saber se está ocorrendo conflitos funcionais
gerados por discussões e troca de opiniões o que é extremamente importante para
o levantamento de requisitos de qualidade. Então se o grau de discussão em torno
de algum objetivo for baixo, estamos identificando a ausência de conflito
funcional e não a ocorrência de um conflito não funcional como estava descrito
anteriormente. Por isso realizamos a alteração da descrição.
Grupo E (Grupo de perguntas referentes a cada participante da reunião).
20) Qual o grau de participação de cada indivíduo durante a reunião?
Pergunta modificada!
Esta pergunta foi alterada, pois a causa da sua terceira hipótese baseava-se
na resposta da pergunta 32, que foi removida. A justificativa para remoção desta
encontra-se ainda nesta seção.
Desta forma, foi retirada a terceira hipótese da pergunta 20.
21) Para cada participante, indique o grau de resistência dele em
compartilhar o seu conhecimento com os demais membros do grupo?
Pergunta removida!
Esta pergunta foi retirada do novo questionário, por ter grande similaridade
com a pergunta 25 (Indique o grau de conhecimento que cada participante
transmitiu sobre os assuntos de sua alçada durante a reunião.), e seus objetivos
serem semelhantes também. Porém a pergunta 25 além de objetivar identificar a
existência de má transferência de conhecimento, ela visa também descobrir o
motivo da ocorrência. Já a 21 baseia-se em uma única causa, que seria a
resistência de compartilhar o conhecimento por medo de perder o poder deste
conhecimento. A solução foi manter a 25 acrescentando no gerenciamento de sua
primeira hipótese, que sugere que as informações não foram passadas pelo
comportamento não participativo do indivíduo, o gerenciamento da questão 21.
92
Pois se o participante não compartilhou o conhecimento por medo, isto faz parte
da personalidade dele, não está no objetivo do líder mudar isto, sendo o
participante então forçado através do gerenciamento para este conflito mudar de
atitude, que se baseia em explicar que a resistência só trará resultados negativos
para todos.
22) Para cada participante, indique o grau que a utilização excessiva de
termos técnicos prejudicou a compreensão dos requisitos.
Pergunta Modificada!
Esta questão foi modificada na formulação da pergunta, com o objetivo de
deixá-la mais abrangente. Sua nova formulação é: “Para cada participante, indique
o grau que a utilização excessiva de vocabulário difícil e/ ou termos técnicos
prejudicou a compreensão dos requisitos”.
Alteramos também a causa do conflito da questão. Isso ocorreu por que
como ela é uma questão relativa e sua única causa apontava para uma questão que
foi removida, notamos a necessidade de melhorá-la, não apenas excluindo ou
alterando a referência. Desta forma, a causa desta pergunta mudou para: “Falta de
conhecimento dos outros membros da reunião, dos principais termos do projeto ou
25 - Baixo grau de conhecimento que cada participante transmitiu sobre os
assuntos de sua alçada durante a reunião”.
25) Indique o grau de conhecimento que cada participante transmitiu sobre
os assuntos de sua alçada durante a reunião.
Pergunta modificada!
A justificativa da alteração da descrição do gerenciamento desta pergunta já
foi realizada juntamente com a da retirada da pergunta 21 (justificativa acima).
Outra alteração realizada nesta pergunta foi na descrição do tipo do conflito
identificado na sua primeira hipótese. Isso ocorreu porque na primeira hipótese
desta pergunta acreditamos identificar a ausência de um conflito funcional
caracterizado pela troca de conhecimentos através de um comportamento
participativo e não a identificação da ocorrência de um conflito não funcional
como estava descrito.
93
26) Qual o grau de cooperação demonstrado por cada participante da
reunião?
Pergunta modificada!
Retiramos a quarta hipótese desta pergunta, por esta tentar avaliar um
conflito difícil de ser identificado. Que se refere à falta de atenção que o
participante dispensou a reunião por estar preocupado com problemas alheios a
ela. Atitude difícil de ser admitida pelo participante. Pelo mesmo motivo a
pergunta 38 indicada como a causa desta hipótese também foi retirada do
questionário.
27) Qual o grau de motivação de cada participante da reunião?
Pergunta removida!
Retiramos esta pergunta, pois as perguntas 20 (Qual o grau de participação
de cada indivíduo durante a reunião?) e 26 (Qual o grau de cooperação
demonstrado por cada participante da reunião?) possuem objetivos bem
semelhantes, que se baseiam nas causas da falta de participação e cooperação dos
participantes, ou seja, conseqüentemente da falta de motivação. Porém estas
tratam as causas dos conflitos possíveis de forma mais completa e detalhada.
29) Qual a importância que cada participante tem para que você execute
suas tarefas diárias com rapidez e com a qualidade desejada?
Pergunta modificada!
Encontramos uma inconsistência nesta pergunta, pois no seu objetivo
mostrava a importância de se haver dependência entre as atividades diárias dos
participantes da reunião, para que se estimule a cooperação. Porém no conflito, ele
indica que este ocorre com um grau alto das respostas, ou seja, quando existe uma
grande dependência entre os participantes. E identifica como uma causa para este
conflito, a estrutura de algumas organizações que estimulam a interdependência.
O que mostra ainda uma grande inconsistência na pergunta é que no
gerenciamento, mais uma vez o autor trata da importância em sempre se estimular
uma dependência funcional entre os participantes.
Para resolver estas inconsistências, consertamos o conflito, sendo este
identificado agora com um grau baixo nas respostas, como já era citado nas listas
de causas possíveis de outras perguntas. Mostrando mais uma inconsistência, já
94
que o conflito estava sendo identificado com grau alto das respostas na descrição
da pergunta. E também foi refeita a descrição da causa, baseada agora no novo
conflito.
Além desses problemas, o enunciado da pergunta também foi identificado
como confuso e assim reformulado. E passou a ser: “Para cada participante, qual o
grau de importância para você, que ele execute suas tarefas diárias com rapidez e
com a qualidade desejada?”.
31) Qual o grau em que cada indivíduo forneceu soluções para os problemas
que surgiram durante a reunião?
Pergunta modificada!
Alteramos a descrição do tipo de conflito identificado pela pergunta, pois
acreditamos que esta pergunta identifica a ausência de um conflito funcional e não
a ocorrência de um conflito não funcional como estava descrito. Isso porque a
questão tenta identificar qual participante forneceu poucas soluções para os
problemas que surgiram, o que demonstra a ausência do conflito funcional gerado
pela troca de idéias e contribuições entre todos os participantes na busca de um
consenso para o problema.
Inserimos também uma segunda hipótese nesta pergunta, para identificar os
participantes que tem uma atuação bastante participativa na reunião, porém muito
pouco cooperativa. A identificação destes participantes é muito importante para
melhorar o andamento da reunião, evitando assuntos desnecessários e
improdutivos que eles normalmente insistem em levantar.
32) Qual a facilidade de comunicação demonstrada por cada participante?
Pergunta removida!
Esta pergunta foi retirada por sinalizar um conflito difícil de ser tratado pelo
líder que é causado por um problema de personalidade do indivíduo (introversão
ou timidez em excesso). Além disso, os principais problemas que podem surgir
por causa desta característica, que são a falta de participação e cooperação do
indivíduo e ainda a dificuldade de transmissão do seu conhecimento, já são
tratados respectivamente pelas perguntas 20 (Qual o grau de participação de cada
indivíduo durante a reunião?), 26 (Qual o grau de cooperação demonstrado por
95
cada participante da reunião?) e 25 (Indique o grau de conhecimento que cada
participante transmitiu sobre os assuntos de sua alçada durante a reunião).
Grupo F (Grupo de perguntas referentes ao participante que está
respondendo o questionário).
35) Qual o seu grau de interesse pelos objetivos do sistema?
Pergunta removida!
A remoção é justificada, pois o conflito identificado nesta pergunta é tratado
também pela pergunta 40 (Qual o grau de relacionamento do sistema a ser
desenvolvido com as tarefas que você desempenha em seu trabalho?), que analisa
de maneira mais clara e objetiva este conflito, sem ter como hipóteses, conflitos já
tratados em outras perguntas. Ela apenas tem a direta intenção de saber o grau de
relação do participante com os objetivos do sistema, para observar se a
convocação do indivíduo para a reunião foi justificável.
Desta forma, identificamos como mais conveniente manter a 40 para a
retirada da 35.
36) Em que grau você deixou de emitir suas opiniões ou de apresentar suas
experiências por achar que todos já possuíam o conhecimento do que você poderia
expressar?
Pergunta modificada!
Incluímos no texto do objetivo e do gerenciamento desta pergunta,
informações para deixar explícito que ela trata de uma pergunta que tenta
identificar se ocorreu o problema do conhecimento tácito entre os participantes da
reunião. Consideramos importante que isso ficasse explicito tanto no seu objetivo
para a visualização dos participantes ao responder o questionário, quanto no seu
gerenciamento para o líder.
38) Qual o grau com que problemas alheios à reunião o preocuparam
durante os debates?
Pergunta removida!
Como já explicamos na justificativa da retirada da quarta hipótese da
pergunta 26, esta é uma atitude difícil de ser admitida por um participante, e ainda
um conflito complicado de ser tratado já que inseri aspectos psicológicos no seu
96
gerenciamento. De qualquer forma, problemas relacionados com a falta de
participação e cooperação do indivíduo já são tratados de maneira mais objetiva
nas perguntas 20 (Qual o grau de participação de cada indivíduo durante a
reunião?) e 26 (Qual o grau de cooperação demonstrado por cada participante da
reunião?) respectivamente.
41) Em que grau você achou que sua presença foi necessária na reunião?
Pergunta removida!
Analisando a pergunta, esta se mostrou ser uma questão que mexe muito
com o ego do indivíduo. Que participante vai ter a coragem de admitir que sua
presença foi inútil à reunião? Mesmo que tenha sido, não será nesta pergunta que
isso será identificado, já que isso afeta psicologicamente o participante. É mais
fácil identificar este tipo de conflito em perguntas do tipo da 40 (Qual o grau de
relacionamento do sistema a ser desenvolvido com as tarefas que você
desempenha em seu trabalho?) e da 8 (Qual o benefício que cada requisito obtido,
quando implementado, trará para a execução de suas tarefas?) que foram incluídas
no questionário.
42) Em que grau você estava com pressa para encerrar a reunião devido a
compromissos marcados em seguida?
Pergunta removida!
Pela necessidade de diminuir a quantidade de perguntas do questionário,
identificamos esta pergunta como uma questão de pouca prioridade para o
método. Além de identificar um tipo de conflito muito difícil de ser evitado em
um ambiente de trabalho, onde o tempo do profissional é precioso e sua agenda
está constantemente lotada.
Grupo G (Grupo de perguntas referentes ao conhecimento, as idéias, e aos
questionamentos que surgiram durante a reunião).
Retiramos todas as perguntas pertencentes a este grupo, com exceção da
pergunta 47 (Em que grau as discussões que surgiram conduziram a um aumento
na tensão do grupo?), por termos identificado elas como perguntas que estão
fazendo um resumo da avaliação já feita pelos grupos de perguntas anteriores,
apenas com uma ótica um pouco diferente. Desta forma, desnecessária a inclusão
97
destas perguntas em um questionário que visa além de completeza, a objetividade
e a eficiência. Isto justifica a eliminação deste grupo do novo questionário, e a
pergunta 47 foi transferida para o novo grupo G, que como foi explicado na seção
anterior, trata de perguntas referentes à organização da reunião.
Além destas justificativas, será feita uma justificativa específica para cada
pergunta retirada deste grupo.
43) Qual o grau de preocupação, durante a reunião, em se obter um
entendimento completo do conhecimento do que ia sendo apresentado?
Pergunta removida!
Retiramos esta pergunta por estar diretamente ligada, conflitos e causas,
com perguntas 14 (Para cada objetivo da reunião, apresente o grau de discussão
que foi gerada em torno de seus tópicos principais.), 20 (Qual o grau de
participação de cada indivíduo durante a reunião?), 22 (Para cada participante,
indique o grau que a utilização excessiva de termos técnicos prejudicou a
compreensão dos requisitos) e 26 (Qual o grau de cooperação demonstrado por
cada participante da reunião?).
44) Em que grau surgiram idéias criativas durante a reunião?
Pergunta removida!
O conflito desta pergunta já é identificado e tratado de forma diferente em
outras três perguntas. Na pergunta 20 (Qual o grau de participação de cada
indivíduo durante a reunião?), 31 (Qual o grau que cada indivíduo forneceu
soluções para os problemas que surgiram durante a reunião?) e principalmente a
26 (Qual o grau de cooperação demonstrado por cada participante da reunião?).
45) Qual o grau de questionamentos em relação às idéias apresentadas?
Pergunta removida!
Removemos esta, por ter sido identificado que o texto da pergunta não
expressa de forma clara o objetivo da mesma, que seria verificar se podem ter
surgido novos pensamentos e idéias criativas a partir do questionamento de
normas antigas e enraizadas na cultura da organização. Descartamos também a
possível alteração e melhora da pergunta, por ser uma pergunta sem muita
importância para a qualidade da reunião e principalmente por ser difícil de ser
respondida por participantes de uma reunião que compõe uma equipe de
98
desenvolvimento distribuído de software. Onde na maioria dos casos, estes
pertencem a organizações diferentes.
46) Qual a tendência que houve durante a reunião em se adotar uma única
perspectiva dentre as diversas que iam surgindo em relação a um determinado
assunto?
Pergunta removida!
Isto ocorreu pela semelhança do objetivo desta pergunta com o de outras
que já identificam os conflitos e as causas de forma mais completa e efetiva. O
objetivo da pergunta 46 era saber se foram considerados diversos pontos de vista
ou se foram descartadas idéias alternativas. Objetivo extremamente semelhante
aos das questões 23 (Para cada participante, qual o grau de resistência
demonstrado as novas idéias que surgiram?) que objetiva verificar se a
criatividade teve boa receptividade ou se ocorreram resistências a mudanças,
reprimindo o surgimento de novas idéias, 19 (Qual o grau que cada membro usou
de coerção (ameaças) para fazer prevalecer seus pontos de vista durante a
reunião?) e 34 (Qual o grau de monopolização da discussão por parte de cada
indivíduo?) ambas buscam identificar conflitos que podem estar prejudicando na
promoção da integração de diversos pontos de vista.
Grupo H (Grupo de perguntas referentes às atitudes do líder durante a
reunião).
49) Qual o grau de utilização de estratégias de incentivo (à comunicação, ao
surgimento de novas idéias, à integração entre os indivíduos) pelo líder durante a
reunião?
Pergunta removida!
O objetivo desta pergunta baseava-se em identificar se o líder usou
estratégias para motivar os indivíduos, aumentando a produtividade da reunião.
Esta pergunta foi retirada por ter o objetivo e as hipóteses de conflito
extremamente semelhantes aos da pergunta 48 (Qual a qualidade do controle e da
coordenação de atividades efetuados pelo líder durante a reunião?), que o objetivo
é verificar se a reunião foi bem conduzida e controlada pelo líder. Escolhemos a
permanência da pergunta 48 por avaliarmos como uma pergunta mais bem
formulada e mais simples de ser entendida pelo respondente.
99
50) Qual o grau de aceitação do líder pelo grupo?
Pergunta removida!
O objetivo desta pergunta tratava de identificar se o líder foi aceito pelo
grupo, facilitando a coesão grupal e a coordenação de tarefas por intermédio do
líder. Esta pergunta foi retirada por ter o objetivo fortemente semelhante ao da
pergunta 51 (Qual o seu grau de antagonismo em relação ao líder da reunião?),
que o objetivo é verificar se os participantes possuem algo contra o líder da
reunião, o que poderia prejudicar as tarefas de coordenação e o espírito
cooperativo que a reunião deve ter. Desta forma, foi escolhida a permanência da
pergunta 51, por ser uma pergunta que o respondente vai dar a sua opinião a
respeito do líder, não responder sobre qual é a opinião que o grupo teria sobre ele.
Pois achamos que quando cada participante responde sobre sua relação com o
líder, o conjunto dessas respostas vai retratar melhor a verdade do que se cada um
respondesse sobre a relação do grupo com o líder.
Grupo I (Grupo de perguntas referentes a características organizacionais).
Este grupo possui duas perguntas 52 (Como você classifica a política de
incentivos funcionais usada pela organização?) e 53 (Qual o grau de alterações
estruturais que são efetuadas na organização visando a uma melhoria na qualidade
das tarefas que são desenvolvidas em seus departamentos?), e ambas foram
classificadas como não necessárias para o questionário proposto. Já que o novo
questionário se propõe a ser uma ferramenta de apoio a elicitação de requisitos no
ambiente de desenvolvimento distribuído de software, onde na maioria das vezes
participam funcionários de diversas organizações diferentes. O que seria inviável
uma avaliação baseada em características organizacionais.
52) Como você classifica a política de incentivos funcionais usada pela
organização?
Pergunta removida!
Justificativa feita acima.
53) Qual o grau de alterações estruturais que são efetuadas na organização
visando a uma melhoria na qualidade das tarefas que são desenvolvidas em seus
departamentos?
100
Pergunta removida!
Justificativa já feita acima.
Grupo J (Grupo de perguntas referentes ao local da reunião.).
Este grupo de perguntas tem como objetivo verificar as condições em que a
reunião ocorreu, se acústica, temperatura, iluminação e outras características
estavam adequadas para um bom andamento da reunião. Perguntas de importância
para uma reunião realizada de maneira presencial. Porém o método, como já dito
anteriormente, visa apoiar a elicitação de requisitos no ambiente de
desenvolvimento distribuído de software, onde na maioria dos casos as reuniões
são feitas de forma não presencial, realizada através de software de comunicação
pela Internet. Assim, nos casos em que as reuniões fossem realizadas deste modo,
este conjunto de perguntas estaria desapropriado.
Visando criar um conjunto único de perguntas que pudesse atender tanto aos
casos de reunião presenciais quanto não presenciais, substituímos as seis
perguntas pertencentes a esse grupo por uma que verificasse a existência de
problemas nas condições de realização da reunião, de modo imparcial em relação
à maneira como a reunião tenha sido realizada.
Desta forma as perguntas 54 (Acústica), 55 (Isolamento), 56 (Temperatura),
57 (Iluminação), 58 (Dimensão) e 59 (Disponibilidade de todos os recursos
necessários para os participantes) foram substituídas por uma única pergunta que
foi apresentada na seção 3.4.2, onde descrevo detalhadamente cada pergunta do
novo questionário.
Grupo K (Grupo de perguntas referentes ao grupo de trabalho)
60) Qual o grau de diferença entre as necessidades dos participantes?
Pergunta removida!
Esta é uma pergunta causal, ou seja, que serviria de causa para outras
perguntas. Como ela é muito pouco utilizada como pergunta causal para as
perguntas selecionadas para o novo questionário, foi removida.
61) Qual o grau de benefícios que as mudanças sugeridas pelos participantes
trouxeram para o resultado final da reunião?
Pergunta removida!
101
Identificamos esta pergunta como uma pergunta repetida ou que tenta
resumir um critério já analisado em outras. Pois analisar se a participação dos
indivíduos na reunião foi construtiva, já foi feito em outras perguntas como, a 23
(Para cada participante qual o grau de resistência demonstrado às novas idéias que
surgiram?) que verifica se houve algum tipo de resistência ao surgimento de novas
idéias, o que poderia prejudicar a obtenção de requisitos com qualidade. E
também pela 26 (Qual o grau de cooperação demonstrado por cada participante?),
30 (Para cada participante, informa o grau com que ele embasou suas posições,
expondo argumentos para a sua linha de pensamento ao invés de simplesmente
colocar suas idéias sem maiores explicações?) e 31 (Qual o grau em que cada
indivíduo forneceu soluções para os problemas que surgiram durante a reunião?).
62) Qual o grau de coesão do grupo durante a reunião?
Pergunta removida!
Isto ocorreu por ela ter sido identificada como uma pergunta que faz um
resumo dos resultados das outras. Pois a coesão do grupo já é identificada e
gerenciada de outras formas em outras perguntas, como por exemplo, na 28 (Para
cada participante da reunião, informa o grau em que você conhece seu trabalho?),
29 (Qual a importância que cada participante tem para que você execute suas
tarefas diárias com rapidez e com a qualidade desejada?), 33 (Qual o grau de
antagonismo que você possui em relação a cada participante da reunião?), 37 (Em
que grau você se identificou com o grupo?), 47 (Em que grau as discussões que
surgiram conduziram a um aumento na tensão do grupo?) e 51 (Qual o seu grau de
antagonismo em relação ao líder?). Todas estas perguntas citadas fazem uma
análise do relacionamento do grupo, cada uma apontando características
diferentes para o problema do entrosamento, mostrando assim a possibilidade da
eliminação da 61.
No caso das perguntas que foram removidas por causa da existência de
outras que a substituíam de melhor forma, pelo menos uma destas perguntas
substitutas, será referenciada no lugar da pergunta removida nas causas das
perguntas relativas que a referenciava. O mesmo acontece com perguntas
combinadas, onde a pergunta resultante será referenciada na lista de causas no
lugar das duas ou mais retiradas.
102
As demais perguntas do questionário original [Mathias 94] que não foram
citadas nesta seção foram usadas no novo questionário, já apresentado na seção
3.4.2, sem alterações significativas. Apenas em alguns casos realizamos alterações
sintáticas na formulação dos textos das perguntas, objetivos e gerenciamentos,
com o único intuito de permitir uma melhor compreensão do texto.
Além de todas estas modificações realizadas, o novo questionário contém
uma nova pergunta incluída no grupo F, de perguntas referentes ao participante
que está respondendo o questionário. A nova pergunta criada tenta identificar se o
participante acha importante o processo de levantamento de requisitos, já que
consideramos que a atuação de um indivíduo num processo depende bastante de o
quanto importante é, na sua visão, o processo no qual está envolvido. Abaixo está
o enunciado da nova pergunta:
Com qual grau de importância você classifica a fase de levantamento de
requisitos, isto é, a fase onde procuramos entender as necessidades do projeto e
descrevê-las de forma mais clara possível?
Encerrada a apresentação de todas as perguntas que compõem o novo
questionário e as justificativas de cada alteração realizada, é necessário agora
elaborar uma forma de efetuar a detecção dos conflitos que ocorreram em uma
reunião. Este assunto é abordado na próxima seção.
3.5. Identificando conflitos
Nesta seção iremos explicar como é feita a identificação dos conflitos a
partir das perguntas do questionário, quais as regras utilizadas e outros detalhes.
Como este é um novo estudo em cima da proposta inicial [Mathias 94] foram
feitas algumas mudanças na tarefa de identificação de conflitos. Desenvolvemos
novas regras para a identificação dos conflitos e criamos uma maneira mais
simples de tratar e explicar esta atividade.
3.5.1. Como os conflitos são identificados através do questionário
Cada pergunta do questionário tem a finalidade de detectar um conflito
específico, ou seja, o número de perguntas contidas no questionário corresponde
ao número possível de diferentes conflitos que podem ser identificados por ele.
Por isso, houve grande preocupação com a reformulação do conjunto de perguntas
103
do questionário para não deixar de avaliar um conflito importante e para não
avaliar mais de uma vez o mesmo conflito a partir de perguntas diferentes.
Algumas perguntas tentam detectar a ocorrência de conflitos não funcionais,
para desta forma, eles serem tratados e evitados. Outras tentam detectar a ausência
de conflitos funcionais, neste caso o gerenciamento indica um incentivo ao
surgimento do conflito funcional ou o tratamento dos problemas que possam estar
prejudicando o seu surgimento.
Para as perguntas pertencentes aos grupos A (cada requisito), C (cada
objetivo) e E (cada participante), as regras de identificação dos conflitos são
acionadas para cada um dos seus componentes separadamente. Nestes casos a
pergunta objetiva identificar conflitos em cada um dos requisitos, objetivos ou
participantes da reunião, dependendo do grupo que ela pertença. É uma única
pergunta que deve ser respondida para cada um dos seus componentes. Por
exemplo, se foram elicitados 10 requisitos em uma reunião, para cada pergunta do
grupo A, o participante deverá fornecer 10 notas diferentes, uma para cada
requisito.
Para fazer a análise das respostas do questionário utilizamos 3 grandezas,
como em [Mathias 94]:
• A intensidade que o conflito ocorreu.
A intensidade é calculada através da média aritmética de todas as
respostas a uma determinada questão, ou a um componente de uma
determinada questão, isso para os casos das questões do grupo A, C
e E, como já foi explicado anteriormente.
Por exemplo, se uma pergunta teve duas respostas com grau 1 e três
com o grau 2, então sua intensidade é:
1 + 1 + 2 + 2 + 2/ 5 = 1.8
• A probabilidade em que o conflito ocorreu.
A probabilidade é calculada a partir da quantidade de participantes
que responderam à pergunta com um grau favorável ao conflito,
dividido pelo total de respostas de todos os participantes, depois
multiplicado por cem.
Por exemplo, considere duas perguntas que identificam conflito com
o grau alto das respostas:
104
Perg.1) Todos os 4 participantes forneceram grau 4 (favorável).
4/4 * 100 = 100 %
Perg.2) Dois participantes forneceram grau 3 (neutro) e dois grau 5
(favorável).
2/4 * 100 = 50 %
Apesar dos dois exemplos terem intensidade igual a 4, a
probabilidade de ter ocorrido conflito é maior na pergunta 1, pois foi
maior o número de participantes que responderam de forma
favorável ao conflito.
• A utilidade do conflito, caso este tenha sido detectado.
A utilidade tem como objetivo principal dar um grau de relevância
para cada conflito identificado. De fato, é importante para o
planejador e líder da reunião saber quais são os conflitos mais graves
dentre os que ocorreram e quais as hipóteses das questões relativas
são as mais prováveis dentre as possíveis.
Exemplo 1: Para conflitos detectados com grau baixo das respostas.
Utilidade do conflito = (3,0 – intensidade) * probabilidade / 100.
Exemplo 2: Para conflitos detectados com grau alto das respostas.
Utilidade do conflito = (intensidade – 3,0) * probabilidade /100.
Podemos observar nas fórmulas que no numerador é calculado a
distância da intensidade do conflito com o grau médio. A ordem dos
termos varia para evitar que perguntas que identificam conflitos com
grau alto das respostas tenham uma utilidade sempre maior que
aquelas que identificam com grau baixo das respostas.
Para o cálculo da intensidade, probabilidade e conseqüentemente do conflito
e da utilidade, deve ser levado em conta o grupo que a questão pertence:
• Para questões dos grupos A (cada requisito), C (cada objetivo) ou E
(cada participante):
A intensidade é calculada para cada requisito, objetivo ou
participante de uma questão que pertença a um dos grupos acima.
Isto porque, neste caso, os conflitos serão considerados analisando
separadamente cada requisito, objetivo ou participante. Por exemplo,
105
uma pergunta do grupo E de uma reunião que tenha tido 5
participantes, pode ser que seja identificado conflito com 2 deles,
mas 3 estejam isentos de conflitos.
A probabilidade é calculada assim: 100 multiplicado (x) pelo
número de respostas individuais que indicaram conflito para o
mesmo requisito, objetivo ou participante, dividido (/) pelo número
de respostas de todos os participantes para o mesmo requisito,
objetivo ou participante da questão.
A identificação do conflito e o cálculo da utilidade, caso o conflito
tenha ocorrido, também é realizada analisando os dados de cada
requisito, objetivo ou participante de cada questão dos grupos acima.
• Para questões do grupo F (cada participante responde em relação a si
mesmo):
A intensidade será igual a resposta do participante à questão.
A probabilidade de ser identificada a ocorrência de conflito do
participante em relação a reunião nas perguntas de auto-avaliação,
será sempre de 0% ou 100%. Vai depender se a resposta dele for ou
não favorável ao conflito. Isso ocorre pois é considerada apenas a
resposta do próprio participante na sua auto-avaliação.
A identificação do conflito e da utilidade, caso o conflito tenha
ocorrido, também é realizada analisando as respostas de cada
participante sobre si mesmo.
• Para as questões dos demais grupos:
A intensidade, probabilidade e utilidade destas perguntas são
calculadas normalmente, como explicado no início desta seção.
A identificação do conflito também não tem nenhuma exceção para
estes grupos de perguntas.
3.5.2. Regras para identificação dos conflitos
Existem dois tipos padrões de perguntas no questionário: as que identificam
conflito com o grau alto das respostas e as que identificam com o grau baixo das
respostas.
Conforme [Mathias 94], serão identificados conflitos nos seguintes casos:
106
Se a pergunta identifica conflito com grau alto e
sua intensidade é > = 3,5
Então ocorreu conflito
Senão não ocorreu conflito
Fim se
Se a pergunta identifica conflito com grau baixo e
sua intensidade é < = 2,5
Então ocorreu conflito
Senão não ocorreu conflito
Fim se
Porém, a partir dos estudos realizados com o método e dos casos práticos,
foi identificada a necessidade de incluir regras que utilizassem não só a
intensidade, mas também a probabilidade como meio de identificar a ocorrência
de conflito. Analisando os resultados de 15 experimentos, observamos a
ocorrência de situações em que a intensidade do conflito ficava muito próxima da
exigida pela regra e, apesar da probabilidade de ocorrência acima de 55%, o
conflito não era identificado.
Por exemplo, uma pergunta que identificava conflito com grau alto das
respostas, ficou com intensidade em torno de 3.4 e probabilidade de 60%, porém
seu conflito não foi identificado pela regra.
Outro caso que podemos citar é o de uma pergunta que identificava conflito
com grau baixo das respostas, que obteve intensidade 2,57 e probabilidade 57% ,
mas também não foi identificado conflito.
Feita essa observação, achamos necessária a inclusão de regras que
levassem em consideração também a probabilidade de ocorrência do conflito.
Pois, como mostramos acima, é possível não identificar conflitos com
probabilidade de ocorrência acima de 55% e intensidade muito próxima da
exigida. Para garantir a identificação destes conflitos criamos duas novas regras:
Se a pergunta identifica conflito com grau alto e
sua intensidade é > = 3,4 e probabilidade >= 55%
Então ocorreu conflito
Senão não ocorreu conflito
107
Fim se
Se a pergunta identifica conflito com grau baixo e
sua intensidade é < = 2,6 e probabilidade >= 55%
Então ocorreu conflito
Senão não ocorreu conflito
Fim se
Como podemos verificar nas fórmulas acima, diminuímos em 0,1 a
intensidade exigida nas outras regras e combinamos com a exigência de uma
probabilidade acima de 55 %, para desta forma, podermos identificar os conflitos
que não eram identificados anteriormente. Assim, estamos tornando o método um
pouco mais sensível a identificação de conflitos sem cair no exagero de listar
conflitos muito sutis.
3.5.3. Identificando as causas
No caso das questões absolutas, caso o conflito seja detectado, a causa e a(s)
técnica(s) de gerenciamento indicada(s) são aquelas que foram descritas na seção
3.4.2. Portanto, neste caso, a detecção das causas é direta, já que elas são pré-
determinadas.
Para determinar as causas das questões relativas, é necessária uma análise
mais complexa já que para cada hipótese do conflito, caso ele tenha mais de uma,
existe uma correlação com o resultado de outras perguntas.
Como vimos na descrição das perguntas na seção 3.4.2, as causas das
perguntas relativas estão relacionadas com o resultado de outras perguntas. Por
exemplo, uma hipótese de uma pergunta relativa pode ter sua causa relacionada a
n perguntas. Para saber se os problemas identificados por estas perguntas
relacionadas podem ter sido realmente causas do conflito identificado pela
pergunta relativa, devemos verificar em quais dentre estas n perguntas também
ocorreu conflito. O método indica “Causa não detectada” no caso de nenhuma
dessas perguntas relacionadas com a causa da pergunta relativa tenha identificado
conflito (seção 3.4.2).
108
4– Ferramenta de apoio ao método
Uma ferramenta foi desenvolvida para fornecer apoio ao método no
gerenciamento dos conflitos. Esta ferramenta analisa as respostas de cada
participante para identificar os conflitos e apontar as melhores técnicas para o seu
tratamento de acordo com suas causas.
A ferramenta ajuda o líder e os planejadores da reunião em diversas tarefas.
A principal delas é automatizar a identificação dos conflitos, fornecendo um
relatório com a sua descrição e apontando as técnicas de gerenciamento mais
indicadas. A ferramenta ainda permite aos participantes responderem ao
questionário on-line de qualquer lugar do mundo através da Internet. Por fim, a
ferramenta automatiza o cadastramento dos projetos, usuários da ferramenta,
reuniões, participantes de cada reunião, objetivos e requisitos das reuniões.
Ela está disponível no endereço virtual http://reuniao.les.inf.puc-rio.br
4.1. Novas características da ferramenta
A ferramenta foi desenvolvida em PHP, HTML e Javascript com a base de
dados gerenciada através do MySQL e utiliza o servidor Web Apache, ganhando
uma nova possibilidade de interatividade e caracterizando desta maneira uma
aplicação em 3 camadas.
Além disso, a tarefa de identificação dos conflitos agora é realizada por um
sistema especialista integrado à ferramenta de apoio, desenvolvido através da
tecnologia do software CLIPS. Falaremos mais detalhadamente sobre a criação do
sistema especialista ainda neste capítulo.
109
Figura 4 – Arquitetura do sistema
4.2. Interface da ferramenta
A ferramenta é divida em três módulos, cada um responsável pelas
operações de um tipo de usuário. Uma para as tarefas do usuário planejador, outra
para o líder e uma terceira para o participante da reunião.
A seguir apresentaremos as principais interfaces e funcionalidades da
ferramenta.
4.2.1. Tela de acesso ao sistema
Na tela de entrada do sistema, o usuário digita o seu login e sua senha para
ter acesso às funcionalidades do sistema que ele for autorizado, dependendo do
tipo de usuário que ele represente.
Nesta tela existe uma opção que permite a pessoa interessada em utilizar a
ferramenta de apoio se cadastrar como usuário do tipo planejador de reuniões,
criando sua senha e seu login. A partir daí esta pessoa terá privilégio de acesso ao
módulo deste tipo de usuário e poderá cadastrar o projeto que deseja elicitar os
requisitos, os usuários do seu projeto, as reuniões, entre outras funcionalidades.
110
Figura 5 – Tela de acesso ao sistema
4.2.2. Tela de acesso aos módulos do líder e do participante comum
Caso o usuário seja do tipo planejador, ao fazer o login na tela de entrada ele
é direcionado diretamente para o módulo de tarefas do planejador. Caso não seja,
ele é direcionado então para uma tela intermediária. Nesta tela o usuário deve
selecionar o projeto que ele deseja trabalhar dentre os que ele está cadastrado.
Após isso, ele deve selecionar a reunião desejada, dentre as reuniões do projeto
selecionado e, a seguir, dizer qual foi seu perfil na reunião selecionada, líder
(moderador) ou participante comum da reunião.
Ao acionar o botão a ferramenta vai validar as informações para enviar o
usuário para o módulo de líder caso ele tenha escolhido uma reunião de um
projeto em que ele desempenhou este papel ou para o módulo de participante
comum se esta tiver sido sua escolha.
111
Figura 6 – Tela de acesso aos módulos do líder e do participante comum
4.2.3. Módulo dos planejadores
O usuário do tipo planejador deve entrar com sua senha para ter acesso ao
seu módulo. As tarefas que podem ser realizadas pelo planejador são: Cadastro
dos projetos, cadastro dos usuários e reuniões de cada projeto, cadastro dos
objetivos e participantes das reuniões e operações de avaliação dos conflitos.
Vamos detalhar cada uma a seguir.
Figura 7 – Módulo planejador
112
4.2.3.1. Cadastro dos projetos
Esta opção permite o cadastro dos projetos que terão seus requisitos
elicitados. Neste cadastro estão disponibilizadas as operações de inclusão,
exclusão, alteração e consulta. Para o usuário realizar qualquer tarefa relacionada
com um projeto, como incluir participante ou alterar a data de uma reunião, ele
deve selecionar o projeto que deseja trabalhar em uma caixa de seleção localizada
no alto da página.
4.2.3.2. Cadastro dos usuários dos projetos
Esta opção permite que o planejador cadastre os usuários que terão acesso
aos projetos gerenciados por ele. Para isso existem as operações de inclusão,
exclusão, busca e alteração.
Para incluir um novo usuário o planejador deverá informar o nome, o login
(que deverá ser único, caso contrário a ferramenta informará e solicitará a troca), a
senha provisória, o e-mail e a especificação se é um usuário do tipo planejador
também ou não. Ao confirmar o cadastro, a ferramenta envia automaticamente um
e-mail para o novo usuário informando que ele foi cadastrado na ferramenta e
sugerindo que ele a acesse para a troca da senha temporária.
4.2.3.3. Cadastro das reuniões
Nesta opção é que os planejadores fazem o cadastramento de cada reunião a
ser realizada para elicitar requisitos do projeto. Nela como nos demais cadastros,
são permitidas as operações de inclusão, exclusão, busca e alteração.
Para incluir uma reunião o planejador deve informar o tema, a data e a hora
da reunião.
113
Figura 8 – Módulo do planejador (Cadastro das reuniões)
4.2.3.4. Cadastro dos objetivos da reunião
Para realizar esta tarefa o usuário deve primeiro escolher a reunião que
deseja trabalhar no link “Reuniões”, pai do link que cadastra os objetivos.
No cadastro dos objetivos da reunião selecionada o usuário pode incluir,
excluir, alterar e listar os objetivos. Para incluir um objetivo é necessário apenas
entrar com sua descrição.
4.2.3.5. Cadastro dos participantes da reunião
Como explicado na seção anterior, para ter acesso a esta tarefa o usuário
deve primeiro selecionar a reunião que deseja trabalhar.
Para cadastrar os participantes da reunião o usuário deve escolher seu nome
na lista de usuários do projeto para o qual a reunião será realizada e depois
selecionar seu perfil, que poderá ser de participante comum ou de líder. Vale
lembrar que uma reunião tem apenas um líder.
Nesta funcionalidade como nas demais de cadastro ele poderá incluir,
excluir, alterar e listar os participantes.
114
4.2.3.6. Operações de avaliação dos conflitos
Existem três operações que são as responsáveis pelo gerenciamento dos
conflitos das reuniões por parte do planejador.
A primeira é a de controle, que visa informar quais participantes já
responderam ao questionário e quais ainda não responderam. Dentro dela ainda
existe uma opção para enviar e-mail para os participantes que ainda não
responderam, lembrando-os de realizar esta tarefa.
A segunda operação é a de detecção de conflito. Caso o número mínimo de
participantes já tenha respondido ao questionário, esta opção acionará o sistema
especialista ligado à ferramenta e realizará a identificação dos conflitos. Esta
tarefa pode ser realizada quantas vezes o usuário quiser, pois ele pode querer ir
acompanhando os resultados parciais, até todos os participantes finalmente
responderem ao questionário e ele poder solicitar o resultado final.
A terceira opção é responsável por listar os conflitos que foram
identificados na reunião e que devem ser tratados pelo planejador. O planejador
deve tratar apenas dos conflitos relacionados com o líder (moderador) da reunião,
desta maneira só estes serão listados. Os demais conflitos serão listados apenas
para o líder da reunião, no módulo que contém as tarefas deste tipo de usuário.
Figura 9 – Módulo do planejador (Listagem dos conflitos)
115
4.2.4. Módulo dos Líderes
O usuário do tipo líder deve informar o seu login e senha para acessar o
sistema. Após o seu acesso ter sido validado ele será direcionado para a tela
intermediária para escolher a reunião de um determinado projeto em que ele tenha
desempenhado este papel, para desta maneira ter acesso ao seu módulo. As
tarefas que podem ser realizadas pelo líder são: Cadastro dos requisitos da
reunião, operações sobre o questionário, operações de avaliação dos conflitos e
também a homologação da reunião. Vamos detalhar cada uma a seguir.
Figura 10 – Módulo do líder
4.2.4.1. Cadastro dos requisitos da reunião
Esta opção permite o cadastro dos requisitos da reunião, que é a soma dos
novos requisitos elicitados e os que já foram elicitados anteriormente e que
permanecem válidos. Este cadastro permite as operações de inclusão, exclusão,
alteração e consulta. Para inclusão de um novo requisito, existem três opções, uma
para cada tipo de requisito. Uma para requisitos funcionais, outra para não
funcionais e uma terceira para inversos.
Para facilitar a inclusão de requisitos que já tenham sido elicitados
anteriormente, é disponibilizada uma opção onde são listados os requisitos da
reunião homologada, possibilitando a seleção dos que se deseja incluir na reunião
que está sendo trabalhada. Reunião homologada é a reunião cujo conjunto de
requisitos retrata os requisitos do projeto.
116
4.2.4.2. Operações sobre questionários
Existem três tipos de operações que podem ser realizadas sobre o
questionário. A primeira delas é a geração das perguntas do questionário, onde nas
questões do grupo A (analisa cada requisito individualmente), C (analisa cada
objetivo) e E (cada participante) são incluídos conforme o grupo, os requisitos,
objetivos e participantes da reunião que devem ser avaliados.
O líder também deve responder o questionário de perguntas, por isso
também é disponibilizada esta funcionalidade para ele. Para responder o
questionário o usuário deve selecionar um grau entre 1 e 5 inclusive, para avaliar
o que está sendo perguntado. O usuário enquanto responde o questionário tem a
opção de clicar no link “objetivo”, que aparece em cada pergunta, que tem por
finalidade explicar ao usuário o objetivo pelo qual está sendo feita tal pergunta.
A opção de controle que também está disponível nas operações do
questionário é a mesma explicada na seção 4.2.3.6, que visa informar quais
participantes já responderam ao questionário e quais ainda não responderam.
Possuindo ainda a opção para enviar e-mail para os participantes que ainda não
responderam, lembrando-os desta tarefa.
Mostraremos a seguir um exemplo de um questionário gerado para uma
determinada reunião. Para simplificar omitiremos algumas perguntas.
1- Classifique o seu grau de ambigüidade ou falta de clareza e precisão ao
final da reunião referente a cada um dos requisitos. Objetivo
1.1- Listar os usuários cadastrados
1 2 3 4 5
1.2- Não demorar mais de 10 segundos para responder à pesquisa.
1 2 3 4 5
2- Qual o grau de necessidade de especialistas adicionais que possam sanar
dúvidas ou esclarecer melhor certos pontos que foram discutidos referentes ao
requisito? Objetivo
2.1- Listar os usuários cadastrados
117
1 2 3 4 5
2.2- Não demorar mais de 10 segundos para responder à pesquisa
1 2 3 4 5
3- Qual o grau de consenso surgido entre os participantes no final da reunião
em relação a cada requisito obtido? Objetivo
3.1- Listar os usuários cadastrados
1 2 3 4 5
3.2- Não demorar mais de 10 segundos para responder à pesquisa
1 2 3 4 5
11- Para cada objetivo da reunião, apresente o grau de discussão que foi
gerada em torno de seus tópicos principais. Objetivo
11.1- Levantar as principais funcionalidades do sistema.
1 2 3 4 5
12- Qual o grau de viabilidade de cada objetivo da reunião? Objetivo
12.1- Levantar as principais funcionalidades do sistema.
1 2 3 4 5
13- Qual o grau de compatibilidade entre os objetivos da reunião? Objetivo
1 2 3 4 5
14- Em que grau os objetivos da reunião foram bem definidos antes do seu
inicio ? Objetivo
1 2 3 4 5
118
16- Qual o grau em que cada membro usou de coerção (ameaças) para fazer
prevalecer seus pontos de vista durante a reunião? Objetivo
16.1- Andréa Vilas
1 2 3 4 5
16.2- Carlos José
1 2 3 4 5
17- Qual o grau de participação de cada indivíduo durante a reunião?
Objetivo
17.1- Andréa Vilas
1 2 3 4 5
17.2- Carlos José
1 2 3 4 5
35- Qual a qualidade do controle e da cooperação de atividades efetuados
pelo líder durante a reunião? Objetivo
1 2 3 4 5
37- Qual o seu grau de satisfação em relação à maneira a qual a reunião foi
realizada. Objetivo
1 2 3 4 5
39- Qual o grau em que os compromissos firmados entre os participantes
serão suficientes para garantir que os requisitos sejam mantidos e atendidos pelo
sistema? Objetivo
1 2 3 4 5
119
4.2.4.3. Operações de avaliação dos conflitos
Operações semelhantes foram explicadas no módulo do planejador na seção
4.2.3.6. A operação de detecção do conflito é a mesma explicada naquela seção, já
a operação de listar os conflitos apresenta uma diferença. Em vez de listar os
conflitos relacionados com o líder, como é feito no módulo do planejador, no
módulo do líder são listados todos os conflitos identificados na reunião, exceto, os
relacionados com o líder que já são listados no módulo do planejador como já foi
dito.
O relatório com a listagem dos conflitos é divido em quatro partes: conflitos
identificados nas questões que analisam cada requisito individualmente, conflitos
identificados nas questões que analisam cada objetivo individualmente, conflitos
identificados nas questões que analisam cada participante individualmente e
conflito nas demais questões. Dentro de cada divisão desta os conflitos são
ordenados pela sua utilidade, para facilitar o líder a identificar os conflitos mais
prioritários de cada tipo.
A seguir daremos um exemplo resumido da listagem de conflitos de uma
reunião.
• Conflito nas questões sobre cada requisito (ordenadas pela utilidade): Pergunta número 1 - Classifique o seu grau de ambigüidade ou falta de clareza e precisão ao final da reunião referente a cada um dos requisitos.
Conflito (grau alto das respostas): Não funcional entre a necessidade de se ter requisitos claros e bem definidos e o grau de ambigüidade ou de falta de clareza e precisão detectado.
Causa(s): 2 - Alto grau de necessidade de especialistas adicionais que possam sanar dúvidas ou esclarecer melhor certos pontos que foram discutidos referentes ao requisitos. 15 - Tempo de duração da reunião.
Gerenciamento: Na próxima reunião, o líder deve propor um esclarecimento do(s) requisitos ambíguo(s) e impreciso(s), onde os participantes devem colocar os pontos onde o(s) requisito(s) estão mal definidos visando uma melhora do seu entendimento.
Requisitos onde o conflito foi detectado (ordenados por utilidade):
* O sistema deve atualizar dados do diretor Grau_medio: 4.33 Probabilidade: 83% Utilidade: 1.10 * O sistema não deve demorar mais que 20 segundos para dar um resultado.
120
Grau_medio: 4.33 Probabilidade: 66% Utilidade: 0.88 * O sistema não deve parar de funcionar. Grau_medio: 4.00 Probabilidade: 50% Utilidade: 0.50
• Conflito nas questões sobre cada objetivo (ordenadas pela utilidade): Pergunta número 11 - Para cada objetivo do sistema, apresente o grau de discussão que foi gerada em torno de seus tópicos principais.
Conflito (grau baixo das respostas): Ausência do conflito funcional gerado pelas discussões sobre os objetivos traçados.
Causa(s): 15 - Tempo de duração da reunião. 35 - Baixa qualidade do controle e da cooperação de atividades efetuados pelo líder durante a reunião.
Gerenciamento: Na próxima reunião, o líder deve enfatizar as discussões em torno dos objetivos que tiveram pouca ênfase nas reuniões anteriores, cuidando para que os participantes não se desviem do assunto discutido.
Objetivos onde o conflito foi detectado (ordenados por utilidade):
* Criar empregos Grau_medio: 2.00 Probabilidade: 50% Utilidade: 0.50 * aumentar taxas de valores Grau_medio: 2.50 Probabilidade: 50% Utilidade: 0.25
• Conflito nas questões sobre cada participante (ordenadas pela utilidade): Pergunta número 16 - Qual o grau em que cada membro usou de coerção (ameaças) para fazer prevalecer seus pontos de vista durante a reunião?
Conflito (grau alto das respostas): Não funcional entre um dos objetivos do método, o de levar em conta as posições individuais para o alcance de soluções e o uso da coerção, limitando ou impedindo o surgimento de soluções que pudessem levar em conta diferentes posições.
Causa: O participante que usou de coerção possui alguma vantagem em relação aos demais, seja por possuir um status maior ou por ocupar um cargo melhor na organização ou por possuir trunfos que o permite persuadir os demais membros da reunião. Desta forma, o indivíduo utiliza a coerção como forma de fazer valer suas idéias, prejudicando os resultados da reunião.
Gerenciamento: O líder deve propor que sejam levadas em conta as posições dos participantes que sofreram coerção no estabelecimento das decisões. Deve, ainda, conscientizar o indivíduo que usou de ameaças de que as idéias de todos devem ser consideradas e que ninguém deve usar tentativas de coerção, pois a opinião dos outros membros também é vital para a obtenção dos requisitos.
121
Participantes onde o conflito foi detectado (ordenados por utilidade):
* Carlos Grau_medio: 5.00 Probabilidade: 100% Utilidade: 2
* Andrea Villas Grau_medio: 2.00 Probabilidade: 50% Utilidade: 0.50
• Conflito nas demais questões (ordenadas pela utilidade): Pergunta número 8 - Qual o grau de compatibilidade entre os requisitos do sistema obtidos na reunião?
Hipótese 1: A incompatibilidade entre os requisitos é reflexo da má definição ou da incompatibilidade entre os objetivos do sistema.
Conflito (grau baixo das respostas): Não funcional, pois a realização completa de um requisito implica em uma não realização total ou parcial de outros requisitos.
Causa(s): Não detectada!
Gerenciamento: A redefinição dos objetivos auxiliará na resolução da incompatibilidade entre os requisitos, pois alguns requisitos terão que ser revistos e alterados em função da mudança dos objetivos.
Hipótese 2: Os objetivos do sistema estão bem definidos e são compatíveis entre si, mas os requisitos apresentam incompatibilidades.
Conflito (grau baixo das respostas): Não funcional, pois a realização completa de um requisito implica em uma não realização total ou parcial de outros requisitos.
Causa(s): 2 - Alto grau de necessidade de especialistas adicionais que possam sanar dúvidas ou esclarecer melhor certos pontos que foram discutidos referentes ao requisitos. 15 - Tempo de duração da reunião. 16 - Alto grau de coerção (ameaças) usado pelos membros. 35 - Baixa qualidade do controle e da cooperação de atividades efetuados pelo líder durante a reunião.
Gerenciamento: Alterar na próxima reunião, através da negociação entre os participantes, as partes dos requisitos que possuem incompatibilidades, eliminando seus conflitos e permitindo sua completa realização simultaneamente.
Grau médio: 2.17
Probabilidade: 66 %
Utilidade: 0.55
122
4.2.4.4. Homologar reunião
Esta opção homologa uma reunião, o que significa que a lista de requisitos
desta reunião representa a lista de requisitos do projeto.
4.2.5. Módulo do participante comum
O usuário do tipo participante comum deve informar o seu login e senha
para acessar o sistema. Após o seu acesso ter sido validado ele será direcionado
para a tela intermediária para escolher a reunião de um determinado projeto em
que ele tenha desempenhado este papel, para desta maneira ter acesso ao seu
módulo. A principal tarefa disponível para o participante comum é a opção de
responder o questionário, já explicada na seção 4.2.4.2., além de poder solicitar a
visualização da lista de requisitos do projeto e dos objetivos da reunião como
também é possível nos demais módulos.
Figura 11 – Módulo do participante comum
4.3. Grafo de relacionamento das tabelas implementadas
Para modelar a base de dados utilizamos um grafo que defini os objetos que
compõem o sistema e seus respectivos relacionamentos. As caixas representam as
tabelas e as setas os seus relacionamentos.
123
Figura 12 – Grafo de relacionamento das tabelas implementadas
4.4. Sistema especialista para detecção dos conflitos
Nesta seção falaremos sobre o sistema especialista desenvolvido para
realizar a detecção dos conflitos da reunião.
124
4.4.1. O que é um Sistema Especialista
Edward Feigenbaum, professor da Universidade de Stanford, pioneiro na
tecnologia de sistemas especialistas - S.E.'s, define-os como "... um programa
inteligente de computador que usa conhecimento e procedimentos de inferência
para resolver problemas que são difíceis o suficiente para que sua solução
necessite de um grau significativo de perícia humana." [Feigenbaum 63] . Isto é,
um sistema especialista é um sistema de computação que emula a habilidade de
tomar decisões de um especialista humano.
O termo emular significa que se pretende que o sistema especialista aja em
todos os sentidos como um especialista humano. Uma emulação é muito mais
forte que uma simulação. Simulações agem como o elemento real em apenas
alguns aspectos.
Uma característica fundamental em sistemas especialistas é que o
conhecimento do(s) especialista(s) é armazenado através de regras. Regras, neste
contexto, são construções simples na forma: Se alguma condição é verdadeira,
então faça alguma coisa. O uso de regras é interessante em algumas situações
tendo em vista que permite a construção da definição de um determinado
comportamento de maneira compacta.
Se analisado em sua forma mais simples, um determinado comportamento
caracteriza-se por um conjunto de ações e um conjunto de condições sob as quais
as ações devem acontecer. Um sistema especialista continuamente analisa um
conjunto de elementos condicionais (conhecidos como regras) em relação a uma
base de fatos (também conhecida como base de conhecimento) para verificar se
alguma regra pode ser aplicada para aquele conjunto de fatos. Se a premissa é
verdadeira, então o sistema especialista executa as ações associadas gerando
novos fatos na base de conhecimento. Este processo de analisar a base e disparar
regras é realizado por um componente denominado máquina de inferência.
Um sistema especialista (SE) deve possuir alguns componentes essenciais
[Farreny 1985]:
• uma linguagem de expressão dos conhecimentos fornecidos pelos
especialistas;
125
• uma base de conhecimentos, para armazenar o conhecimento específico de
determinada aplicação, que pode ser diretamente fornecido por um especialista, ou
acumulado pelo sistema ao fim dos experimentos;
• um motor de inferência, programa relativamente geral que explora o
conhecimento da base de conhecimentos, considerando-a como fonte de
informações.
A aplicação desta tecnologia apresenta uma série de vantagens, dentre as
quais, algumas são citadas por Gardner [Gardner 92] a seguir:
• solucionar problemas importantes que, de outro modo, deveriam ser
solucionados por um perito humano;
• flexibilidade na integração de novos conhecimentos ao conhecimento já
armazenado;
• capacidade de mostrar seu conhecimento de uma forma facilmente
compreensível;
• capacidade de tratar sentenças simples em linguagens naturais.
4.4.2. Ambiente de Desenvolvimento
Utilizamos como ambiente de desenvolvimento o software CLIPS (C
Language Integrated Production System) desenvolvido pela NASA/Johnson
Space Center.
Por volta de 1985, a NASA decidiu unificar o desenvolvimento interno de
sistemas especialistas. O sistema usado até então, ART, não estava definido para
todas as plataformas utilizadas pela companhia, especificamente PCs e
Macintoshs. Como resultado, o setor de tecnologia de software do Johnson Space
Center criou um clone das capacidades de encadeamento progressivo e da sintaxe
de ART, introduzindo o CLIPS (C Language Integrated Production System)
[Giarratano 1998, Lopez 04] no domínio público, com a finalidade de gerar
soluções que apresentassem alta portabilidade, baixo custo e fácil integração com
sistemas externos.
CLIPS rapidamente conseguiu um grande número de usuários,
principalmente no meio acadêmico. Sua sintaxe em nada se assemelha à da
linguagem hospedeira (C). Entretanto, a sua semelhança com a sintaxe de outras
126
linguagens usadas pela comunidade de Inteligência Artificial, notadamente LISP,
permitiu o aumento do número de seus usuários [Giarratano 1998].
A representação de conhecimento em CLIPS pode ser feita de três formas:
regras (de produção), usadas principalmente para a representação de
conhecimento heurístico baseado em experiência; funções e funções genéricas,
para representação de conhecimento procedimental; ou programação orientada a
objetos, também usada na representação de conhecimento procedimental através
da linguagem de programação própria (COOL, ou CLIPS Object-Oriented
Language). No nosso trabalho nós utilizamos a representação do conhecimento
na forma de regras de produção.
Uma outra característica importante é a forma como é realizada a unificação
entre os objetos da base de fatos e as regras. O sistema utiliza o algoritmo Rete
[Forgy 1982], que elimina redundâncias de avaliações das pré-condições das
regras. Por exemplo, se uma regra pode ser disparada com um conjunto de
objetos, e uma segunda regra é disparada e não altera nenhum dos objetos do
primeiro conjunto, então não há necessidade de se testar novamente as pré-
condições da primeira, pois ela ainda está ativa com o mesmo conjunto de
instâncias. A idéia por trás do algoritmo é que apenas os objetos modificados no
disparo da última regra tenham que ser testados novamente para verificar se
tornam alguma outra regra ativa (ou desativa). O algoritmo Rete é usado na
maioria dos sistemas de produção existentes, apresentando um ótimo desempenho
para aplicações de porte razoável.
4.4.3. Representação do Conhecimento
Em CLIPS há uma diferença entre tipos estruturados de dados e classes, de
forma similar à diferença entre os construtores struct e class em C++. Tipos, ou
templates definem um agrupamento de valores, possibilitando o valor dos
atributos serem fatos, e não apenas valores atômicos.
Cada estrutura se subdivide em campos que identificam um atributo
importante das perguntas e das causas.
No caso das estruturas de perguntas temos:
número - o número da pergunta;
tipo - se ela é absoluta(1) ou relativa(2);
127
a hipótese - o número da hipótese se for pergunta relativa ou 0 se for
absoluta
grau_medio - o grau médio das respostas a esta pergunta;
grau_conflito – (1) Se identificar conflito com o grau alto das respostas ou
(0) se identificar conflito com grau baixo das respostas.
conflito – se ocorreu conflito (1) ou não (nil);
utilidade – o valor da utilidade, ou seja, da prioridade do conflito;
probabilidade – valor da probabilidade que pode ter ocorrido o conflito;
identificador – no caso de pergunta_requisito ou pergunta_objetivo ou
pergunta_participante o identificador é o número que identifica o requisito
ou objetivo ou participante respectivamente.
No caso da estrutura de causa temos:
pergunta – o número da pergunta relativa
hipótese_pergunta – número da hipótese da pergunta relativa
causa – número da pergunta que é uma possível causa do conflito
identificado pela pergunta relativa citada acima.
hipótese_causa – caso a pergunta possua mais de uma hipótese, o número da
hipótese que identifica a possível causa aparecerá neste campo, senão
aparecerá o número 0.
eh_causa - (1) se a causa ocorrer, ou permanece nil se não ocorrer.
Segue abaixo o script de criação das estruturas de dados:
(deftemplate pergunta
(slot numero ) (slot tipo ) (slot hipotese) (slot grau_medio) (slot grau_conflito)
(slot conflito) (slot utilidade) (slot probabilidade)
)
(deftemplate pergunta_requisito
(slot numero ) (slot tipo ) (slot hipotese) (slot identificador) (slot grau_medio)
(slot grau_conflito) (slot conflito) (slot utilidade) (slot probabilidade)
)
(deftemplate pergunta_objetivo
128
(slot numero ) (slot tipo ) (slot hipotese) (slot identificador) (slot grau_medio)
(slot grau_conflito) (slot conflito) (slot utilidade) (slot probabilidade)
)
(deftemplate pergunta_participante
(slot numero ) (slot tipo ) (slot hipotese) (slot identificador) (slot grau_medio)
(slot grau_conflito) (slot conflito) (slot utilidade) (slot probabilidade)
)
(deftemplate causa
(slot pergunta) (slot hipotese_pergunta) (slot causa) (slot hipotese_causa)
(slot eh_causa)
)
Fatos são colocados na base de fatos através da utilização do comando
assert, ou através do comando load que carrega um arquivo txt com os fatos. Os
atributos não inicializados recebem o valor nulo (nil).
Segue abaixo um exemplo do conjunto de fatos para identificar a pergunta 9
e suas causas:
Pergunta no formato texto -> 9 - Qual a qualidade da documentação que foi elaborada para
representar os requisitos.
Objetivo: Verificar a qualidade da documentação dos
requisitos, pois uma documentação insuficiente dificultará a
transmissão de conhecimento para os demais membros da equipe de
desenvolvimento do sistema além de sujeitar a distorções e a
esquecimentos dos requisitos que foram obtidos.
Tipo da questão: relativa.
Conflito: Não funcional entre a qualidade desejada da
documentação dos requisitos e a documentação apresentada,
comprometendo seriamente a qualidade do projeto.
Gerenciamento: Documentar os requisitos obtidos com a
participação de todos os membros da reunião, para evitar
distorções e tendências na documentação que for elaborada.
129
Causas: 15 – Primeira hipótese: Baixo tempo de duração da
reunião em função dos objetivos do sistema ou 35 – Baixa qualidade
do controle e da coordenação de atividades efetuadas pelo líder ou
37 – Baixo grau de satisfação em relação à maneira a qual a
reunião foi realizada.
Intensidade das notas recebidas na reunião x: 2
Probabilidade da ocorrência deste conflito na reunião x: 60%
Pergunta com seus dados em formato de fatos: (pergunta (numero 9)(tipo 2)(hipotese 1)(grau_medio 2)
(grau_conflito nil) (conflito nil) (utilidade nil) (probabilidade
60))
(causa (pergunta 9) (hipotese_pergunta 1) (causa
15)(hipotese_causa 1 ))
(causa (pergunta 9) (hipotese_pergunta 1) (causa
35)(hipotese_causa 1 ))
(causa (pergunta 9) (hipotese_pergunta 1) (causa
37)(hipotese_causa 0 ))
O campo eh_causa da estrutura de dados da causa não aparece, pois é
inicializado com valor nulo, já que é durante a execução das regras no sistema
especialista que é acertado seu valor.
4.4.4. A Implementação
Para um melhor entendimento, explicaremos um pouco sobre a estrutura de
criação de uma regra. As regras no CLIPS são definidas através do comando
defrule. Para construção das regras, você pode utilizar variáveis. As variáveis são
utilizadas para casar nos pré-requisitos de uma regra os valores dos fatos contidos
na base de conhecimento, para serem usados depois pela regra em testes ou como
base para outros cálculos. Vejamos por exemplo, a regra que verifica se uma
pergunta que identifica o conflito com grau alto das respostas detectou conflito:
(defrule verif_conflito_alto
(or ?id <- (pergunta (grau_medio ?x)(grau_conflito 1)(conflito
nil))
?id <- (pergunta_objetivo (grau_medio ?x)(grau_conflito 1)
(conflito nil))
130
?id <- (pergunta_requisito (grau_medio ?x)(grau_conflito 1)
(conflito nil))
?id <- (pergunta_participante (grau_medio ?x)
(grau_conflito 1) (conflito nil))
)
(test (>= ?x 3.5))
=>
(modify ?id (conflito 1)))
Como podemos observar, o que está contido antes da seta são os pré-
requisitos e após são as atividades que devem ser realizadas caso o fato satisfaça
os pré-requisitos.
Todos os fatos vão passar pelas linhas de pré-requisitos, testando se os
satisfazem. No caso do exemplo, os fatos vão tentar se encaixar em um dos tipos
de estruturas de dados solicitados, não em todos, já que estes estão dentro de uma
expressão “ou”. Para satisfazer este pré-requisito o fato do tipo pergunta ou
pergunta_requisito ou pergunta_objetivo ou pergunta_participante deve ter o grau
do conflito igual a 1, ou seja alto, e a informação sobre o conflito igual a nil, ou
seja, não foi detectado conflito ainda para esta pergunta.
Para o fato que conseguir este casamento iremos usar as variáveis ?x para
guardar o valor do campo grau médio. E utilizaremos também a variável ?id, que
guardará o valor do registro daquele fato na base de conhecimento.
Depois, como mostra na regra exemplificada acima, o fato deverá passar
pelo teste (test) que verifica se a variável ?x, que guarda o valor do campo grau
médio, é maior ou igual a 3.5. Se este pré-requisito também for satisfeito o fato
sofrerá a modificação imposta pela regra, que neste caso é modificar o fato
identificado pelo registro guardado na variável ?id, atualizando o campo conflito.
Para a implementação do sistema foram criadas onze regras, elas permitem
obter o grau do conflito de cada pergunta, verificar se a pergunta identificou
algum conflito e verificar as causas dos conflitos identificados por perguntas do
tipo relativas. Além de possibilitar a limpeza do conjunto de fatos resultante.
A seguir apresentaremos cada regra que foi construída, e junto mostraremos
através de um exemplo, como os fatos são modificados por elas.
Para isso selecionamos dois conjuntos de exemplos de fatos, o grupo 1 são
fatos que caracterizam a pergunta número 9, que é uma pergunta relativa, sem
131
subdivisão e contém apenas uma hipótese. Sua causa esta relacionada com os
resultados de outras 3 perguntas e suas respectivas hipóteses ( pergunta 15 -
hipótese 1, pergunta 35 - hipótese 1, pergunta 37 - hipótese 0).
O grupo 2 são os fatos referentes a pergunta número 4, que é uma pergunta
absoluta, com subdivisão e com causa pré-determinada, ou seja, sua causa não
depende da correlação com outras perguntas, por isso não aparece como fato. Ela
é uma pergunta com subdivisão, pois pertence ao grupo A, perguntas que
analisam cada requisito, então será subdividida conforme o número de requisitos
resultantes da reunião, para que cada requisito seja analisado separadamente
baseado em suas avaliações individuais (vide capítulo 3, seção 3.4). O campo
“identificador” da estrutura pergunta_requisito corresponde ao identificador do
requisito, como já foi explicado anteriormente.
Estado inicial dos fatos:
Grupo 1 (pergunta (numero 9 ) (tipo 2 ) (hipotese 1 ) (grau_medio 2
) (grau_conflito nil) (conflito nil) (utilidade nil)
(probabilidade 50) )
(causa (pergunta 9 ) (hipotese_pergunta 1 )(causa 15
)(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 )(causa 35
)(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 )(causa 37
)(hipotese_causa 0 ))
Grupo 2 (pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 7) (grau_medio 4 ) (grau_conflito nil) (conflito
nil) (utilidade nil) (probabilidade 75))
(pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 8) (grau_medio 3.4 ) (grau_conflito nil) (conflito
nil) (utilidade nil) (probabilidade 57))
Segue o conjunto de regras criadas para a realização do sistema, na ordem
em que são acionadas:
132
1) As regras grau_conflito_alto e grau_conflito_baixo são as primeiras a
serem acionadas, pois são as únicas que no momento os fatos satisfazem os pré-
requisitos. O objetivo é detectar qual o grau da resposta que identifica um conflito
na pergunta, grau alto ou baixo.
- Regra para identificar quais perguntas irão detectar conflito com o grau
alto das respostas ( defrule grau_conflito_alto
(or ?id <- (pergunta (numero ?x) (hipotese ?y)
(grau_conflito nil) )
?id <- (pergunta_objetivo (numero ?x) (hipotese ?y)
(grau_conflito nil))
?id <- (pergunta_requisito (numero ?x) (hipotese
?y)(grau_conflito nil))
?id <- (pergunta_participante (numero ?x) (hipotese
?y)(grau_conflito nil))
)
(or
(test (= ?x 1)) (test (= ?x 2)) (test (= ?x 4)) (test (= ?x
7)) (test (= ?x 16))
(test (= ?x 18)) (test (= ?x 19)) (test (= ?x 20)) (test (=
?x 27))(test (= ?x 28))
(test (= ?x 29)) (test (= ?x 34)) (test (= ?x 36))
(and (test (= ?x 15)) (or (test (= ?y 2)) (test (= ?y 3))))
)
=>
(modify ?id (grau_conflito 1))
)
- Regra para identificar quais perguntas irão detectar conflito com o grau
baixo das respostas ( defrule grau_conflito_baixo
(or ?id <- (pergunta (numero ?x) (hipotese ?y)
(grau_conflito nil))
?id <- (pergunta_objetivo (numero ?x) (hipotese
?y)(grau_conflito nil))
?id <- (pergunta_requisito (numero ?x)(hipotese
?y)(grau_conflito nil))
133
?id <- (pergunta_participante (numero ?x) (hipotese
?y) (grau_conflito nil))
)
(or
(test (= ?x 3)) (test (= ?x 5)) (test (= ?x 6))
(and (test (>= ?x 8)) (test (<= ?x 14)))
(test (= ?x 17))
(and(test (>= ?x 21)) (test (<= ?x 26)))
(and (test (>= ?x 30)) (test (<= ?x 33)))
(test (= ?x 35)) (test (= ?x 37)) (test (= ?x 38)) (test (=
?x 39))
(and (test (= ?x 15)) (test (= ?y 1)))
)
=>
(modify ?id (grau_conflito 0))
)
Estado dos fatos:
Grupo 1 (pergunta (numero 9) (tipo 2) (hipotese 1) (grau_medio 2)
(grau_conflito 0) (conflito nil) (utilidade nil) (probabilidade
50))
(causa (pergunta 9 ) (hipotese_pergunta 1 )(causa 15
)(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 )(causa 35
)(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 )(causa 37
)(hipotese_causa 0 ))
Grupo 2 (pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 7) (grau_medio 4) (grau_conflito 1) (conflito nil)
(utilidade nil) (probabilidade 75))
(pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 8) (grau_medio 3.6) (grau_conflito 1) (conflito
nil) (utilidade nil) (probabilidade 57))
2) As regras que são acionadas neste momento são a verif_conflito_alto,
verif_conflito_baixo, verif_conflito_alto_probabilidade e verif_conflito_baixo_
134
probabilidade, estas regras tem como objetivo identificar em quais perguntas
ocorreram conflito.
- Regra que verifica qual pergunta detectou conflito, para as perguntas que
detectam conflito com grau alto das respostas, verificando apenas se o grau médio
é maior ou igual a 3.5.
(defrule verif_conflito_alto
(or ?id <- (pergunta (grau_medio ?x) (grau_conflito 1)
(conflito nil))
?id <- (pergunta_objetivo (grau_medio ?x)
(grau_conflito 1) (conflito nil))
?id <- (pergunta_requisito (grau_medio ?x)
(grau_conflito 1) (conflito nil))
?id <- (pergunta_participante (grau_medio ?x)
(grau_conflito 1) (conflito nil))
)
(test (>= ?x 3.5))
=>
(modify ?id (conflito 1)))
- Regra que verifica qual pergunta detectou conflito, para as perguntas que
detectam conflito com grau baixo das respostas, verificando apenas se o grau
médio é menor ou igual a 2.5.
(defrule verif_conflito_baixo
(or ?id <- (pergunta (grau_medio ?x) (grau_conflito 0)
(conflito nil))
?id <- (pergunta_objetivo (grau_medio ?x)
(grau_conflito 0) (conflito nil))
?id <- (pergunta_requisito (grau_medio ?x)
(grau_conflito 0) (conflito nil))
?id <- (pergunta_participante (grau_medio ?x)
(grau_conflito 0) (conflito nil))
)
(test (<= ?x 2.5))
=>
(modify ?id (conflito 1)))
135
- Regra que verifica qual pergunta detectou conflito, para as perguntas que
detectam conflito com grau alto das respostas, verificando se o grau médio é
maior ou igual a 3.4 e se a probabilidade de ocorrência do conflito é maior ou
igual a 55 %. (defrule verif_conflito_alto_probabilidade
(or ?id <- (pergunta (grau_medio ?x) (grau_conflito 1)
(conflito nil) (probabilidade ?y))
?id <- (pergunta_objetivo (grau_medio ?x)
(grau_conflito 1) (conflito nil) (probabilidade ?y))
?id <- (pergunta_requisito (grau_medio ?x)
(grau_conflito 1) (conflito nil) (probabilidade ?y))
?id <- (pergunta_participante (grau_medio ?x)
(grau_conflito 1) (conflito nil) (probabilidade ?y))
)
(and (test (>= ?x 3.4))
(test (>= ?y 55))
)
=>
(modify ?id (conflito 1) ) )
- Regra que verifica qual pergunta detectou conflito, para as perguntas que
detectam conflito com grau baixo das respostas, verificando se o grau médio é
menor ou igual a 2.6 e se a probabilidade de ocorrência do conflito é maior ou
igual a 55 % (defrule verif_conflito_baixo_probabilidade
(or ?id <- (pergunta (grau_medio ?x) (grau_conflito 0)
(conflito nil) (probabilidade ?y))
?id <- (pergunta_objetivo (grau_medio ?x)
(grau_conflito 0) (conflito nil) (probabilidade ?y))
?id <- (pergunta_requisito (grau_medio ?x)
(grau_conflito 0) (conflito nil) (probabilidade ?y))
?id <- (pergunta_participante (grau_medio ?x)
(grau_conflito 0) (conflito nil) (probabilidade ?y))
)
(and (test (<= ?x 2.6))
(test (>= ?y 55))
)
=>
136
(modify ?id (conflito 1) ))
Estado dos fatos:
Grupo 1 (pergunta (numero 9) (tipo 2) (hipotese 1) (grau_medio 2)
(grau_conflito 0) (conflito 1) (utilidade nil) (probabilidade
50.0) (qtdrespostas 4) (qtdfavoraveis 2))
(causa (pergunta 9 ) (hipotese_pergunta 1 ) (causa 15 )
(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 ) (causa 35 )
(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 ) (causa 37 )
(hipotese_causa 0 ))
Grupo2 (pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 7) (grau_medio 4) (grau_conflito 1) (conflito 1)
(utilidade nil) (probabilidade 75.0))
(pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 8) (grau_medio 3.4) (grau_conflito 1) (conflito 1)
(utilidade nil) (probabilidade 57))
Podemos observar que o campo conflito foi atualizado, recebeu valor 1, ou
seja, ocorreu conflito nestas perguntas.
3) As regras ativadas agora foram as que calculam a utilidade do conflito,
chamadas calcula_utilidade_alto, que calcula a utilidade dos conflitos detectados
com grau alto das respostas e calcula_utilidade_baixo, para os detectados com
grau baixo das respostas. Apenas as perguntas onde os conflitos foram detectados
tiveram a sua utilidade detectada, pois satisfizeram os pré-requisitos da regra.
- Regra que calcula a utilidade, para as perguntas que detectaram conflito
com grau médio alto das respostas.
(defrule calcula_utilidade_alto
(or ?id <- (pergunta (conflito 1) (grau_conflito 1)
(grau_medio ?w) (probabilidade ?x) (utilidade nil))
137
?id <- (pergunta_requisito (conflito 1)
(grau_conflito 1) (grau_medio ?w) (probabilidade ?x) (utilidade
nil))
?id <- (pergunta_objetivo (conflito 1) (grau_conflito
1) (grau_medio ?w) (probabilidade ?x) (utilidade nil))
?id <- (pergunta_participante (conflito 1)
(grau_conflito 1) (grau_medio ?w) (probabilidade ?x) (utilidade
nil))
)
=>
(modify ?id (utilidade(/(*(- ?w 3) ?x)100)))
)
- Regra que calcula a utilidade, para as perguntas que detectaram conflito
com grau médio baixo das respostas.
(defrule calcula_utilidade_baixo
(or ?id <- (pergunta (conflito 1) (grau_conflito 0)
(grau_medio ?w) (probabilidade ?x) (utilidade nil))
?id <- (pergunta_requisito (conflito 1)
(grau_conflito 0) (grau_medio ?w) (probabilidade ?x) (utilidade
nil))
?id <- (pergunta_objetivo (conflito 1) (grau_conflito
0) (grau_medio ?w) (probabilidade ?x) (utilidade nil))
?id <- (pergunta_participante (conflito 1)
(grau_conflito 0) (grau_medio ?w) (probabilidade ?x) (utilidade
nil))
)
=>
(modify ?id (utilidade(/(*(- 3 ?w) ?x)100)))
)
Estado dos fatos:
Grupo 1
(pergunta (numero 9) (tipo 2) (hipotese 1) (grau_medio 2)
(grau_conflito 0) (conflito 1) (utilidade 0.5) (probabilidade
50.0))
(causa (pergunta 9 ) (hipotese_pergunta 1 ) (causa 15 )
(hipotese_causa 1 ))
138
(causa (pergunta 9 ) (hipotese_pergunta 1 ) (causa 35 )
(hipotese_causa 1 ))
(causa (pergunta 9 ) (hipotese_pergunta 1 ) (causa 37 )
(hipotese_causa 0 ))
Grupo 2 (pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 7) (grau_medio 4) (grau_conflito 1) (conflito 1)
(utilidade 0.75) (probabilidade 75.0))
(pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 8) (grau_medio 3.4) (grau_conflito 1) (conflito 1)
(utilidade 0.23) (probabilidade 57))
4) A regra acionada agora é a regra denominada
descobre_causas_perg_relativas, que calcula quais as causas, dentre o conjunto de
causas de cada pergunta, se tornaram ativas. Isso é verificado observando se a
pergunta contida na causa de uma pergunta que foi detectado o conflito, também
detectou conflito.
(defrule descobre_causas_perg_relativas
(or (pergunta (numero ?y) (conflito 1) (tipo 2) (hipotese
?x))
(pergunta_objetivo (numero ?y) (conflito 1) (tipo 2)
(hipotese ?x))
(pergunta_requisito (numero ?y) (conflito 1) (tipo
2) (hipotese ?x))
(pergunta_participante (numero ?y) (conflito 1)
(tipo 2) (hipotese ?x))
)
?id<-(causa (pergunta ?y)(hipotese_pergunta ?x) (causa
?c) (hipotese_causa ?h) (eh_causa nil))
(or (pergunta (numero ?c) (hipotese ?h) (conflito 1))
(pergunta_objetivo (numero ?c) (hipotese ?h)
(conflito 1))
(pergunta_requisito (numero ?c) (hipotese ?h)
(conflito 1))
(pergunta_participante (numero ?c) (hipotese ?h)
(conflito 1))
)
139
=>
( modify ?id (eh_causa 1))
)
Estado dos fatos:
Grupo 1 (pergunta (numero 9) (tipo 2) (hipotese 1) (grau_medio 2)
(grau_conflito 0) (conflito 1) (utilidade 0.5) (probabilidade
50.0))
(causa (pergunta 9) (hipotese_pergunta 1) (causa 35)
(hipotese_causa 1) (eh_causa 1))
(causa (pergunta 9) (hipotese_pergunta 1) (causa 15)
(hipotese_causa 1) (eh_causa nil))
(causa (pergunta 9) (hipotese_pergunta 1) (causa 37)
(hipotese_causa 0) (eh_causa nil))
Grupo 2 (pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 7) (grau_medio 4) (grau_conflito 1) (conflito 1)
(utilidade 0.75) (probabilidade 75.0))
(pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 8) (grau_medio 3.4) (grau_conflito 1) (conflito 1)
(utilidade 0.23) (probabilidade 57))
Como observado, apenas a causa 35 da pergunta 9 se tornou ativa. Isso
ocorreu porque não foram detectados conflitos nas perguntas 15, hipótese 1 e na
pergunta 37.
5) As regras remove_perguntas_sem_conflito, remove_causas_nao_satisfeitas
foram criadas para limpar o conjunto final de fatos. Elas são as últimas a regras
ativadas.
- Limpa o conjunto de fatos, retirando as perguntas que não detectaram
conflito. (defrule remove_perguntas_sem_conflito
(or ?id <- (pergunta (conflito nil) )
?id <- (pergunta_objetivo (conflito nil))
?id <- (pergunta_requisito (conflito nil))
140
?id <- (pergunta_participante (conflito nil))
)
=>
(retract ?id)
)
- Limpa o conjunto de fatos, retirando as causas que não se tornaram ativas. (defrule remove_causas_nao_satisfeitas
?id <- (causa (eh_causa nil) )
=>
(retract ?id)
)
Estado final dos fatos:
Grupo 1 (pergunta (numero 9) (tipo 2) (hipotese 1) (grau_medio 2)
(grau_conflito 0) (conflito 1) (utilidade 0.5) (probabilidade
50.0) (qtdrespostas 4) (qtdfavoraveis 2))
(causa (pergunta 9) (hipotese_pergunta 1) (causa 35)
(hipotese_causa 1) (eh_causa 1))
Grupo 2 (pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 7) (grau_medio 4) (grau_conflito 1) (conflito 1)
(utilidade 0.75) (probabilidade 75.0))
(pergunta_requisito (numero 4) (tipo 1) (hipotese 0)
(identificador 8) (grau_medio 3.4) (grau_conflito 1) (conflito1)
(utilidade 0.23) (probabilidade 57))
O controle de disparo das regras no CLIPS é baseado em um mecanismo
simples de prioridades, ou saliência de regras. O usuário pode especificar uma
saliência para uma regra, e em caso de mais de uma regra estar ativa no momento,
será escolhida para o disparo a regra com a maior prioridade.
O CLIPS contém a propriedade de refração, ou seja, uma regra não será
disparada mais de uma vez para o mesmo fato, ou conjunto de fatos.
141
4.4.5. O Processo
O processo para fazer a ligação entre a aplicação desenvolvida em PHP e o
sistema especialista desenvolvido em CLIPS é exemplificado através da figura
abaixo:
Figura 13 – O processo
A figura 13 mostra a troca de informações que é realizada entre o banco de
dados, a aplicação e o sistema especialista. Este processo começa quando a
aplicação busca no banco de dados as informações para construir o conjunto de
fatos iniciais que será salvo em um arquivo texto (Fatos), e posteriormente lido
pelo sistema especialista. A aplicação também aciona a execução de comandos
para o funcionamento deste, que para isso utiliza o conjunto de regras e a base de
fatos.
Após o sistema especialista trabalhar o conjunto de fatos enviado, ele grava
os fatos resultantes em um outro arquivo texto (Fatos resultantes) que é lido pela
aplicação através de expressões regulares e depois as informações necessárias
salvas no banco de dados.
As informações da pergunta que não serão trabalhadas pelo sistema
especialista, como a descrição da pergunta, do conflito e do gerenciamento não
entram como informações na estrutura de fatos. Apenas as informações que serão
modificadas pelo sistema especialista ou que serviram de informação no pré-
requisito das regras, é que são passadas como fatos para o sistema. Isto vale
também para a causa das perguntas absolutas, já que esta não é variável conforme
142
a reunião, como é o caso das causas das perguntas relativas. As informações que
não variam conforme a reunião são manipuladas apenas na aplicação PHP.
4.4.6. Vantagens na utilização do sistema especialista
Com a utilização do sistema especialista (SE) estamos flexibilizando não só
a manutenção das regras de identificação dos conflitos que nele estão
armazenadas, pela maior facilidade de compreensão, mas também a base de
conhecimento (questionário). Pois uma nova pergunta pode ser criada e também
alterada sem que o SE perca sua funcionalidade, já que o conhecimento do
especialista contido nele independe do conjunto de perguntas e seus
relacionamentos.
Além das vantagens já apresentadas acima e na seção 4.4.1, nós gostaríamos
de ressaltar a capacidade de expressar o conhecimento de uma forma facilmente
compreensível entre elas. Como exemplo, podemos fazer a comparação de como
algumas regras que foram escritas na linguagem do CLIPS ficariam escritas em
PHP. O código a seguir é para identificar quais perguntas detectaram conflitos, e
para as que detectarem, calcular sua utilidade:
// Busca no BD as informações sobre as perguntas sem
subdivisão
$pergunta=mysql_query("select id_pergunta, grupo, tipo,
grau_conflito, grau_medio, qtd, qtdfav from questao");
while ($linha=mysql_fetch_array($pergunta)) //Enquanto
existir pergunta
{
// Dando valores as variáveis
if (($grau_conflito==1) and ($grau_medio<=2.5))
{
$probabilidade = 100*$favoravel/$qtd;
$utilidade = (3-$grau_medio)*$probabilidade/100;
$conflito = 1;
}else
{
if (($grau_conflito==2) and ($grau_medio>=3.5))
{
$probabilidade = 100*$favoravel/$qtd;
143
$utilidade = ($grau_medio-3)*$probabilidade/100;
$conflito = 1;
}
else
{
$probabilidade = 0;
$utilidade=0;
$conflito = 0;
}
//Atualiza informações no BD
mysql_query("UPDATE questao SET conflito= '$conflito',
grau_medio='$grau_medio', probabilidade='$probabilidade',
utilidade = '$utilidade' WHERE id_reuniao='$reuniao'and
id_pergunta ='$id_pergunta' ") or print (mysql_error());
}
A seguir analisaremos as perguntas com subdivisão. Primeiro as perguntas
do grupo a, onde cada pergunta analisa todos os requisitos individualmente.
// Primeiro seleciona todos os requisitos da reunião
$requisitos=mysql_query("select id_requisito from requisito
where id_reuniao='$reuniao'");
while ($linha_req=mysql_fetch_array($requisitos))
{
// Seleciona as informações das perguntas que analisam o
requisito da vez
$pergunta=mysql_query("select id_pergunta, grupo, tipo,
grau_conflito, grau_medio, qtd, qtdfav from q_requisito where
id_requisito = $linha_req[id_requisito]");
while ($linha=mysql_fetch_array($pergunta)) //Enquanto
existir pergunta
{
if (($grau_conflito==1) and ($grau_medio<=2.5))
{
$probabilidade = 100*$favoravel/$qtd;
$utilidade = (3-$grau_medio)*$probabilidade/100;
$conflito = 1;
}else
{
144
if (($grau_conflito==2) and ($grau_medio>=3.5))
{
$probabilidade = 100*$favoravel/$qtd;
$utilidade = ($grau_medio-3)*$probabilidade/100;
$conflito = 1;
}
else
{
$probabilidade = 0;
$utilidade=0;
$conflito = 0;
}
//Atualiza informações no BD
mysql_query("UPDATE q_requisito SET conflito= '$conflito',
grau_medio='$grau_medio', probabilidade='$probabilidade',
utilidade = '$utilidade' WHERE id_reuniao='$reuniao'and
id_pergunta ='$id_pergunta' and id_requisito ='$linha_req[0]'") or
print (mysql_error());
}
}
O conjunto acima se repete para as perguntas com subdivisão de objetivos e
participantes
Para fazer a análise acima em regras de produção utilizamos as regras
grau_conflito_alto, grau_conflito_baixo, verif_conflito_alto, verif_conflito_baixo,
calcula_utilidade_alto e calcula_utilidade_baixo, que podem ser visualizadas na
seção 4.4.4.
No próximo código-fonte em PHP veremos como ficaria para detectar as
causas das perguntas relativas que detectaram conflito.
// Busca no BD as informações sobre as perguntas sem
subdivisão
$pergunta=mysql_query("select id_pergunta, id_hipotese from
questão where conflito ='1' and tipo = '2'");
while ($perg=mysql_fetch_array($pergunta)) //Enquanto
existir pergunta
{
// Busco as causas da pergunta
145
$causas=mysql_query("select id_causa, id_hipotese_causa from
causa where id_pergunta = $perg[id_pergunta] and id_hipotese =
$perg[id_hipotese]" );
while ($causa=mysql_fetch_array($causas)) // Para cada
causa
{
// Busco seu grupo
$grupo_causa = mysql_query("select grupo from pergunta where
id_pergunta = $causa[id_causa] and id_hipotese =
$causa[id_hipotese_causa]" );
$grupo=mysql_fetch_array($grupo_causa)
if ($grupo = ‘a’)
{
$verifica = mysql_query("select id_pergunta, id_hipotese
from q_requisito where conflito ='1' and id_pergunta =
$causa[id_causa] and id_hipotese = $causa[id_hipotese_causa]" );
}else
{
if ($grupo = ‘c’)
{
$verifica = mysql_query("select id_pergunta, id_hipotese from
q_objetivo where conflito ='1' and id_pergunta = $causa[id_causa]
and id_hipotese = $causa[id_hipotese_causa]" );
}
else
{
if ($grupo = ‘e’)
{
$verifica = mysql_query("select id_pergunta, id_hipotese
from q_participante where conflito ='1' and id_pergunta =
$causa[id_causa] and id_hipotese = $causa[id_hipotese_causa]" );
}
else
{
$verifica = mysql_query("select id_pergunta,
id_hipotese from questao where conflito ='1' and id_pergunta =
$causa[id_causa] and id_hipotese = $causa[id_hipotese_causa]" );
}
}
}
146
$num_linhas=mysql_num_rows($verifica);
if ($num_linhas<>0)
{
mysql_query ("insert into causa_ativa (id_pergunta,
id_hipotese, id_causa, id_hipotese_causa) values
($perg[id_pergunta] , $perg[id_hipotese], $causa[id_causa],
$causa[id_hipotese_causa])" );
}
}
}
O código acima se repetirá para verificar as causas das perguntas relativas
dos grupos com subdivisão em requisitos, objetivos e participantes.
Para realizar a análise feita acima em regras de produção utilizamos apenas
a regra descobre_causas_perg_relativas, vide seção 4.4.4.
Verificamos então que expressar o conhecimento através de regras de
produção é mais vantajoso, levando em conta a flexibilidade, a clareza do código
e a manutenibilidade.
5- Análise de caso prático
O método experimental que considera a proposição e avaliação do modelo
com estudos experimentais, foi o método de experimentação utilizado para avaliar
esta tese.
Uma informação mais detalhada a respeito do papel da experimentação na
engenharia de software pode ser encontrada em [Basili 96].
A seguir falaremos um pouco da preparação para a realização do caso
prático e nas próximas duas seções, detalharemos como foi realizado cada um dos
dois estudos de casos.
5.1. Preparação
Para avaliar o método de apoio a reuniões, realizamos um experimento no
qual tentamos simular um ambiente de definição de requisitos de um software,
onde esta tarefa fosse realizada a partir de reuniões com interessados e moderada
por um facilitador. Achamos interessante realizar dois casos distintos, um onde o
processo tivesse o apoio da ferramenta proposta nesta tese e o outro realizado sem
o apoio desta. Ambos iriam se basear na elicitação de requisitos para o mesmo
software, porém com equipes distintas, somente o líder foi o mesmo nos dois
casos, para não influenciar no resultado. A idéia partiu da importância identificada
de se relatar o andamento dos dois casos, sem o apoio da ferramenta e com o
apoio, na tentativa de ter mais um meio de avaliar o uso da ferramenta no apoio da
atividade de elicitação de requisitos através de reuniões.
O primeiro passo foi escolher qual projeto de desenvolvimento de software
seria utilizado para identificar seus requisitos nas reuniões. Então escolhemos o
projeto de um sistema multi-agente aberto para suporte ao gerenciamento de
submissões e revisões de artigos submetidos a uma conferência ou workshop,
chamado Expert Committee. O sistema oferece suporte a diferentes atividades: o
envio de trabalhos, a atribuição de um artigo a um revisor, a seleção de revisores,
a notificação da aceitação e recusa de artigos, entre outros.
148
Após isso partimos para a definição das equipes. Foram montadas duas
equipes, uma que participaria do experimento utilizando a ferramenta de apoio a
reuniões e a outra que não a utilizaria. Para isso pedimos a ajuda de pesquisadores
e estudantes de mestrado e doutorado do Departamento de Informática da PUC-
Rio, com a participação total de 14 pessoas.
Para cada reunião dos experimentos enviamos um e-mail com a convocação
dos participantes. Nele informamos a data e o local que ela seria realizada,
juntamente com a explicação detalhada do perfil de cada participante e quem
desempenharia cada papel. Em anexo também enviamos um resumo da
dissertação, para que os participantes entendessem melhor sobre o trabalho que
estaríamos avaliando.
Durante toda a descrição deste estudo as identidades dos participantes se
manterão ocultas, iremos chamá-los apenas de sujeito A, sujeito B, sujeito C e
assim por diante.
5.2. Estudo de Caso 1 - Com o uso da ferramenta de apoio a reuniões
Realizamos duas reuniões para esta análise de caso, sendo os dados de cada
uma apresentados abaixo. Desta forma poderemos fazer uma comparação dos
resultados da segunda com a primeira, após a aplicação do método de apoio a
reuniões.
O fluxograma abaixo ilustra a seqüência em que as tarefas foram realizadas
no estudo de caso 1:
Figura 14 – Fluxograma do estudo de caso 13
3 As atividades sinalizadas com dois retângulos são realizadas pela ferramenta de apoio.
149
Na primeira reunião, estiveram presentes seis participantes, que
desempenhavam os seguintes papéis (manteremos suas identidades ocultas) :
- O sujeito A desempenhou o papel de líder da reunião, sendo encarregado
de gerenciar todo o andamento da reunião, desde os preparativos até a avaliação
dos resultados, tudo através da ferramenta a ser experimentada. Além de
coordenar o trabalho da equipe e de representar em formato de lista os requisitos
obtidos.
- O sujeito B desempenhou o papel de chair de um evento. A principal
atribuição do chair é distribuir os artigos para os revisores e enviar o resultado das
revisões para os autores.
- O sujeito C desempenhou o papel de revisor. O revisor tem por atribuição
rever os artigos submetidos a um evento, e que lhe foram atribuídos pelo chair.
Após concluir a revisão de cada artigo, o revisor envia a revisão para o chair
juntamente com o seu parecer final sobre o artigo. O parecer final pode ser:
fortemente aprovado, aprovado com restrição, fracamente rejeitado e fortemente
rejeitado.
- O sujeito D desempenhou o papel de autor de artigos. O autor de um artigo
envia o artigo para o evento e espera a resposta da revisão. Caso o artigo seja
aceito, o autor envia o camera-ready do artigo, ou seja, a versão final do artigo.
- O sujeito E desempenhou o papel de desenvolvedor de software.
Transmitindo a opinião de um desenvolvedor de sistemas multi-agente.
- O sujeito F desempenhou o papel de um membro de um comitê de
programa. Os membros do comitê de programa avaliam os conflitos existentes nas
revisões dos artigos. Eles recebem do chair os artigos onde ocorreram conflitos e
suas respectivas revisões. Com base nas revisões, cada um vota pela aceitação ou
rejeição do artigo. Esta informação é enviada ao chair do evento.
A reunião foi planejada com o objetivo de levantar as principais
funcionalidades do sistema. Durante a realização da reunião, o líder procurou usar
técnicas de incentivo aos participantes de forma que todos manifestassem o maior
número de idéias possíveis referentes ao assunto em pauta.
A reunião demorou cerca de 1 hora e após seu término o líder representou os
dezesseis requisitos obtidos em formato de lista e lançou na ferramenta de apoio o
150
objetivo, os requisitos e os participantes da reunião de forma a produzir a listagem
com o questionário a ser respondido por cada participante.
Após verificar pela ferramenta que todos os participantes já responderam o
questionário, o líder dispara a execução do sistema especialista que obtém um
relatório com os conflitos identificados na reunião.
Para efeito de comparação entre os resultados das duas reuniões, será listado
abaixo um resumo onde são citadas as questões onde houve indicação de
ocorrência de conflito não funcional ou ausência de conflito funcional, sendo que
no caso das questões do grupo A (cada requisito), C (cada objetivo) ou E (cada
participante), será também indicado o número total de requisitos, objetivos ou
participantes onde foi observado o conflito.
5.2.1. Resumo dos conflitos na primeira reunião
A primeira reunião possui um objetivo, dezesseis requisitos e seis
participantes. Foram detectados conflitos nas questões:
Conflitos nas questões sobre cada requisito:
Pergunta número 3 - Baixo consenso surgido entre os participantes no
final da reunião em relação a cada requisito obtido.
Conflito identificado em 1 dos 16 requisitos.
Pergunta número 4 - Alto grau em que influências externas à organização
podem afetar o requisito.
Conflito identificado em 2 dos 16 requisitos.
Pergunta número 6 - Baixo benefício que cada requisito obtido, quando
implementado, trará para a execução de suas tarefas.
Conflito identificado em 4 dos 16 requisitos.
Pergunta número 7 - Alto grau em que influências internas à própria
organização podem afetar cada requisito do sistema.
Conflito identificado em 3 dos 16 requisitos.
Conflitos nas questões sobre cada participante:
Pergunta número 16 - Alto grau em que cada membro usou de coerção
(ameaças) para fazer prevalecer seus pontos de vista durante a reunião.
Conflito identificado em 1 dos 6 participantes.
151
Pergunta número 17 - Baixo grau de participação de cada indivíduo
durante a reunião.
Conflito identificado em 1 dos 6 participantes.
Pergunta número 20 - Alto grau em que cada participante se desviou dos
objetivos traçados pelos planejadores.
Conflito identificado em 1 dos 6 participantes.
Pergunta número 22 - Baixo grau de cooperação demonstrado por cada
participante da reunião.
Conflito identificado em 1 dos 6 participantes.
Pergunta número 23 - Para cada participante da reunião, informe o grau
em que você conhece seu trabalho (ou o grau que passou a conhecer após a
reunião).
Conflito identificado em 1 dos 6 participantes.
Pergunta número 25 - Para cada participante, informe o grau com que ele
embasou suas posições, expondo argumentos para a sua linha de pensamento ao
invés de simplesmente colocar suas idéias sem maiores explicações.
Conflito identificado em 1 dos 6 participantes.
Pergunta número 26 - Baixo grau em que o indivíduo forneceu soluções
para os problemas que surgiram durante a reunião.
Conflito identificado em 1 dos 6 participantes.
Pergunta número 28 - Alto grau de monopolização da discussão por parte
do indivíduo.
Conflito identificado em 2 dos 6 participantes.
Pergunta número 29 - Alto grau que o participante deixou de emitir suas
opiniões ou de apresentar suas experiências por achar que todos já possuíam o
conhecimento do que você poderia expressar.
Conflito identificado em 2 dos 6 participantes.
Pergunta número 31 - Baixo grau que o participante sabia dos papeis que
deveria desempenhar durante a reunião.
Conflito identificado em 2 dos 6 participantes.
Foram detectados um total de 14 conflitos. Dentre as 12 questões vitais,
foram detectados conflitos em 2 delas, as de número 3 e 6.
152
5.2.2.Técnicas de gerenciamento adotadas antes da segunda reunião
A partir do relatório de conflitos da primeira reunião, foram adotadas as
seguintes medidas antes da segunda reunião.
Convidamos para a segunda reunião o sujeito G, para desempenhar o papel
de revisor, desta forma tivemos mais uma pessoa representando este papel na
próxima reunião. Com o objetivo de tentar solucionar os conflitos identificados
nos requisitos relacionados com o revisor.
Foi substituído o sujeito F que desempenhou o papel de membro de um
comitê de programa, porque teve baixa participação e cooperação durante a
reunião, apresentando poucas soluções para os problemas que surgiram e não
realizando nenhum tipo de embasamento das suas posições. Além de o seu
trabalho ser pouco conhecido por parte dos demais participantes. O substituto foi
o sujeito H chamado para desempenhar o papel de membro de um comitê de
programa, por ter mais experiência na área acadêmica.
O objetivo da segunda reunião foi baseado nos resultados da primeira, para
tentar solucionar os problemas com os requisitos identificados na reunião anterior.
Ele foi elaborado de forma a ficar mais específico devido ao fato do objetivo da
reunião anterior ter sido muito abrangente, por isso não sendo completamente
cumprido.
5.2.3. Andamento da segunda reunião
De posse do relatório com os conflitos e com as técnicas de gerenciamento
sugeridas, iniciamos a segunda reunião, que durou cerca de 1 hora. Foram
reavaliados 9 requisitos da reunião anterior, onde 7 tiveram conflitos identificados
e 2 que não tiveram conflitos identificados, mas em conseqüência das mudanças
realizadas nos que foram identificados conflitos surgiu a necessidade de
modificação. Dos 9 reavaliados, o grupo decidiu excluir 4 por não serem
necessários para o sistema e modificar a definição de 5, de forma a torná-los mais
claros e livres de ambigüidades. Além disso, as discussões fizeram com que
fossem elicitados 5 novos requisitos, surgidos a partir das discussões sobre os
requisitos que foram excluídos. Desta forma, ao final da segunda reunião a lista
final de requisitos passou a contar com 17 requisitos.
153
5.2.4. Resumo dos conflitos na segunda reunião
A segunda reunião teve um objetivo, dezessete requisitos e 7 participantes.
Foram detectados conflitos nas questões:
Pergunta número 15 - Alto tempo de duração da reunião em função dos
objetivos do sistema.
Pergunta número 29 - Alto grau que o participante deixou de emitir suas
opiniões ou de apresentar suas experiências por achar que todos já possuíam o
conhecimento do que você poderia expressar.
Conflito identificado em 1 dos 7 participantes.
Foram detectados um total de 2 conflitos, sendo nenhum deles em questões
vitais.
5.2.5. Comparação entre as duas reuniões
A primeira conclusão imediata comparando os conflitos ocorridos nas duas
reuniões foi a enorme redução do número de conflitos não funcionais ocorridos.
Enquanto na primeira reunião foram detectados no total 14 conflitos, envolvendo
7 dos 16 requisitos e 5 dos 6 participantes, na segunda reunião foram identificados
apenas 2 conflitos, envolvendo apenas 1 dos 7 participantes.
Além disso, podemos afirmar que as discussões que o líder provocou com
base no relatório de conflitos fizeram com que os participantes avaliassem melhor
suas posições e lançassem mais discussões sobre os pontos que não ficaram claros
na reunião anterior. Isso ficou claro pelo aumento do número de manifestações e
novos pontos de vista demonstrado pelos participantes na segunda reunião.
Conseqüentemente eliminando os conflitos da primeira reunião que indicavam ter
havido poucos questionamentos e tendência em adotar uma única perspectiva,
principalmente pelo uso de coerção e monopolização da discussão realizada por
parte de alguns participantes.
Outra observação é que grande parte dos requisitos que tiveram conflitos
detectados em uma série de questões (baixo grau de consenso, baixo interesse do
grupo e alto grau de influências internas e externas) acabaram sendo excluídos na
segunda reunião, o que indica que eles podem ter sido elicitados precipitadamente,
sem que houvesse uma necessidade dos mesmos para o sistema.
154
5.3. Estudo de Caso 2 - Sem o uso da ferramenta de apoio a reuniões
Para este estudo de caso também foram realizadas duas reuniões, os detalhes de cada uma serão descritos nesta seção.
O fluxograma abaixo ilustra a seqüência em que as atividades ocorreram no estudo de caso 2:
Figura 15 – Fluxograma do estudo de caso 2
Na primeira reunião, estiveram presentes seis participantes que desempenhavam os seguintes papéis:
- O sujeito A desempenhou o papel de líder da reunião.
- O sujeito I desempenhou o papel de chair de um evento.
- O sujeito J desempenhou o papel de revisor.
- O sujeito L desempenhou o papel de autor de artigos.
- O sujeito M desempenhou o papel de desenvolvedor de software.
- O sujeito N desempenhou o papel do membro de um comitê de programa.
A descrição de cada papel já foi realizada no relato do estudo de caso 1.
A reunião foi planejada com o mesmo objetivo da primeira reunião do
estudo de caso 1, o de levantar as principais funcionalidades do sistema. Durante a
realização da reunião como ocorreu nas reuniões do estudo de caso 1, o líder
procurou usar técnicas de incentivo aos participantes de forma que todos
manifestassem o maior número de idéias possíveis referentes ao assunto em pauta.
A reunião demorou cerca de 55 minutos e após seu término, o líder representou os
155
dezessete requisitos obtidos em formato de lista e mandou o arquivo por e-mail
para cada participante.
5.3.1.Técnicas de gerenciamento adotadas antes da segunda reunião
Por motivos de indisponibilidade de participar da segunda reunião, tivemos
que substituir os participantes que desempenharam o papel de autor e membro do
comitê. Para a segunda reunião então foi chamado o sujeito O para desempenhar o
papel de autor e o sujeito P para o papel de membro do comitê.
Os objetivos da segunda reunião foram reavaliar os requisitos elicitados
anteriormente e continuar definindo as principais funcionalidades do sistema.
5.3.2. Andamento da segunda reunião
No início da segunda reunião o líder leu novamente a lista de requisitos
definidos na reunião anterior, com o objetivo de verificar e validar se estes foram
elicitados corretamente. A princípio foi levantada a necessidade de apenas uma
pequena correção em um requisito.
Conforme começaram a elicitar novos requisitos para o sistema, ocorreu a
mudança em outros 2 requisitos elicitados na reunião anterior e a exclusão de um,
que foi substituído por um novo requisito mais completo.
Durante a reunião foram definidos mais 9 requisitos, que na visão dos
participantes, representavam junto com os anteriores as principais funcionalidades
que o sistema deveria desempenhar. Desta forma, ao final da segunda reunião a
lista final de requisitos passou a contar com 25 requisitos.
5.3.3. Comparação entre as duas reuniões
Na primeira reunião foram definidos 17 requisitos, onde 3 destes tiveram
pequenas alterações realizadas na segunda reunião e um foi excluído e substituído
por um novo requisito mais completo. Na segunda reunião foram elicitados mais 9
requisitos
O líder apesar de não ter mais nada para se basear além da experiência da
primeira reunião, tentou estimular a geração de novas idéias e pontos de vista. E
também tentou controlar problemas em relação aos participantes, como uso de
156
coerção e falta de participação e cooperação, que já haviam sido notados por ele
desde a reunião anterior.
5.4. Conclusão do Experimento
No estudo de caso 1 a melhora ocorrida da primeira para a segunda reunião
após a utilização da ferramenta de apoio a reuniões de elicitação de requisitos foi
muito expressiva. Houve um aumento considerável da troca de idéias e pontos de
vista incentivados pelo líder, com o interesse de reavaliar os requisitos elicitados
anteriormente onde foram identificadas ocorrências de conflitos não funcionais.
Um ponto importante foi o melhor domínio e controle apresentado pelo líder, por
ter em suas mãos um estudo com uma avaliação do andamento do processo,
identificando e o ajudando a gerenciar todos os tipos de problemas que ocorreram
na reunião anterior, para que eles não se repetissem. Em conseqüência desse
trabalho realizado pelo líder verificamos a melhora no resultado da segunda
reunião, demonstrada pela grande redução dos conflitos não funcionais
identificados.
Um ponto positivo que não era esperado, mas foi claramente identificado,
foi a preocupação por parte dos participantes em definir requisitos de melhor
qualidade e apresentar um melhor comportamento. Percebemos que os
participantes vieram para a segunda reunião com um maior comprometimento em
executar um trabalho de qualidade. Acreditamos que pela experiência de interação
com a ferramenta e entendimento que estavam inseridos em um processo que se
preocupa muito com a qualidade do que está sendo executado.
Já no estudo de caso 2 não foi notada uma diferença muito expressiva entre
uma reunião e outra. Os participantes vieram com a meta maior de continuar do
ponto que foi parado na reunião anterior a elicitação de requisitos, do que
pensando na importância de rever os pontos fracos. Isso ficou claro pela
movimentação feita nos requisitos, ou seja, apenas em 3 foram feitas pequenas
modificações e a exclusão de um pela substituição de um mais completo e a
criação de 9 novos requisitos.
Vimos que no estudo de caso 2 houve uma ausência de discussão. Isso é
bastante distinto do que ocorreu no estudo de caso 1. Vale lembrar, que no caso 1
o líder dispunha de um relatório sobre a reunião, que continha as sugestões de
157
gerenciamento fornecidas pelo método. Já no caso 2 o líder só contava com sua
experiência, ficando difícil saber se deve estimular a discussão mais deste ou
daquele requisito, ou administrar mais o comportamento deste ou daquele outro
participante.
Concluímos, que apesar do estudo de caso 2, sem o uso do método, ter
elicitado mais requisitos, o estudo de caso 1, onde o método foi utilizado com o
apoio da ferramenta, elicitou requisitos de mais qualidade pelo maior
conhecimento agregado obtido pelos participantes, principalmente pelo líder,
através das reuniões.
6 – Conclusões e trabalhos futuros
No trabalho propomos um método de elicitação de requisitos por intermédio
de um ciclo de reuniões. A principal característica deste método é a utilização da
teoria de conflitos para gerenciar reuniões, com o objetivo de incrementar o
volume e a qualidade das informações elicitadas, conforme vislumbrado por
Mathias [Mathias 94] em sua dissertação de mestrado.
Nos dez anos que separam o nosso trabalho e o trabalho original houve uma
considerável mudança na infra-estrutura de software disponível. A infra-estrutura
utilizada por Mathias [Mathias 94] não dispunha nem de uma característica
distribuída e também não dispunha de facilidades de um sistema de software
voltado para o tratamento de conhecimento especialista. Além disso, o
questionário base utilizado por ele, com mais de 60 perguntas, tornava a aplicação
do método pouco amigável.
O ponto principal das nossas contribuições foi o aumento da aplicabilidade
do método, não apenas pelas novas tecnologias utilizadas na construção da nova
ferramenta, mas também pelo trabalho realizado em cima das questões do
questionário.
Nosso trabalho começou quando realizamos a reformulação do conjunto de
perguntas do questionário utilizado para apoiar a retroalimentação dos
participantes após cada reunião. Para isso realizamos um trabalho minucioso em
cima das perguntas, analisando seu objetivo, importância e clareza. Descartamos
as perguntas que se mostraram desnecessárias e repetidas, alteramos as confusas
ou incompletas e criamos uma pergunta nova. Com a redução do número de
perguntas para 39, contra as 64 anteriores, além de tornarmos o questionário mais
objetivo e aplicável, ele ficou mais eficiente na captura das informações dos
participantes. Desta maneira, melhoramos a qualidade da aplicação do método, já
que este se baseia fundamentalmente na análise da retroalimentação das
informações dos participantes da reunião através do questionário.
Em seguida desenvolvemos a nova ferramenta de apoio, permitindo suporte
desde a fase de planejamento da reunião até a fase de análise dos resultados
159
obtidos. Nós a desenvolvemos utilizando novas tecnologias, o que trouxe maior
facilidade de interação, pela possibilidade de uso on-line. Além disso, a
construção do sistema especialista trouxe uma maior eficiência na geração e
análise dos resultados e aumento na qualidade de manutenção do conhecimento.
A ferramenta apresenta arquitetura em três camadas, com acesso distribuído
através da Internet, facilitando qualquer usuário, no momento que desejar
conectar-se a ela de qualquer parte do mundo. Isto nos permite apoiar também
reuniões realizadas de maneira não presencial.
Outra contribuição foi a criação de duas novas regras para a identificação de
conflitos. Elas foram criadas para possibilitar a identificação de conflitos não só
analisando a intensidade com a qual eles ocorreram, mas também a probabilidade
deles terem ocorrido. Identificamos a necessidade dessas novas regras a partir de
testes, que simulavam situações reais, e da análise de caso prático. Ambas as
atividades foram realizadas utilizando a ferramenta.
A aplicação do método mostrou-se eficaz, tanto nos diversos testes
realizados quanto no caso prático, oferecendo um apoio importante aos
planejadores e ao líder das reuniões. Notamos no caso prático que uma reunião
bem planejada tem maiores probabilidades de sucesso, não deixando nos
participantes a sensação de perda de tempo por terem participando de uma reunião
improdutiva. Pelo contrário, percebemos que os participantes ficaram mais
estimulados e participativos ao compreenderem que estavam participando de um
processo preocupado com a qualidade e a produtividade do que está sendo
executado e onde o seu trabalho é avaliado por todos.
Acreditamos que em conseqüência dos debates e discussões que surgiram
durante as reuniões apoiadas pelo método, os requisitos apresentaram qualidade
superior aos elicitados pelo caso prático que não utilizou o método de apoio a
reuniões. Estimulados pelo método todos os participantes da reunião debateram,
opinaram e fizeram correções na descrição de cada requisito. Isso ocorreu
principalmente por causa do maior conhecimento agregado obtido pelo líder e
pelos participantes através das reuniões.
O presente trabalho contribui para a área de Engenharia de Requisitos ao
disponibilizar um método e um apoio automatizado que, segundo nosso
conhecimento, não encontram similares. O experimento realizado com o método e
o efetivo uso do software de apoio apresentou, em análise qualitativa, observações
160
pontuais, que acreditamos comprovam a utilidade do uso do método. Queremos
lembrar a citação de Fred Brooks sobre a bala de prata [RE 05] para entendermos
a importância de uma elicitação de requisitos de qualidade.
Acreditamos que trabalhos futuros devem concentrar-se no uso do método,
tanto para uma maior sintonia das regras, como para explorar oportunidades de
especialização da base de regras por áreas de conhecimento.
Precisamos também realizar outras aplicações do método em casos práticos,
principalmente nos casos em que as reuniões são realizadas de forma não
presencial. Este sempre foi um dos objetivos a serem alcançados com a evolução
do método, porém no decorrer do trabalho ele foi perdendo força para outros
aspectos mais importantes que foram sendo observados. Desta maneira, é
necessário realizar mais testes que validem o apoio do método a esta forma de
trabalho tão comum nos dias atuais.
Durante todo o desenvolvimento da ferramenta nos preocupamos sempre em
utilizar software de domínio público. Desta forma, a nova ferramenta de apoio ao
método é do tipo software livre. Acreditamos assim, que outros pesquisadores
terão mais facilidade para evoluir o método e sua ferramenta de apoio.
7– Bibliografia
[Andersen et. al 86] – Andresen, N. E.; Kensing, F.; Lassen, M.; Lundin, J.;
Mathiassen, L.; Munk-Madsen, A; Sorgaard, P. (1986) “Professional system
development: Experience, possibilities, and handling” – Copenhagen: Teknisk
forlag.
[Arango 94] - Arango, G. A Brief Introduction to Domain Analysis.
Proceedings of the 1994 ACM symposium on Applied computing, Phoenix, 1994.
Disponível no site da ACM: http://www.acm.org/
[Andrews 91] – Dorine C. Andrews. JAD: A crucial demension for rapid
applications development. Journal of Systems Management, pages 23-31, March
1991.
[Andriole 90] – Andriole, Stephen J. (1990) “Command and control
information systems engineering: Progress and prospects”, Advances in
computers, vol.31.
[Barondi et. al 86] – Barondi, Jack J; Olson, Margrethe H. e Ives, Blake
(1986) “An empirical study of the impact of user involvement system usage and
information satisfaction”, Communications of the ACM – March 1986, vol.29 (3).
[Basili96] – Basili V., “The role of experimentation in Software
Engineering: Past, Present, Future.”, Proceeding of the 18th International
Conference of Software Engineering, 1(2), pp. 133-164, 1996.
[Bertolin 98] - Bertolin J.C.G. Uma Análise de Técnicas da Psicologia para
a Elicitação de Requisitos de Software. Seminário de Andamento de Mestrado, III
Semana Acadêmica, Programa de Pós-Graduação em Computação da UFRGS,
Porto Alegre, Outubro, 1998.
[Boehm 81] – Boehm, B. W., Software Engineering Economics. Prentice-
Hall, 1981.
[Boehm 88] - Boehm, B. W., 'A Spiral Model of Software Development and Enhancement'. IEEE Computer, 1988. 21(5): 61-72.
162
[Bortoli 99] - De Bortoli, L.A. Um Método de Trabalho para Auxiliar a
Definição de Requisitos. Dissertação de Mestrado, Programa de Pós-Graduação
em Ciência de Computação da UFRGS, Porto Alegre, 1999.
[Brabander, Thiers 84] – Brabander, B. De; Thiers, G. (1984) “Successful
information system development in relation to situational factors which affect
communication between mis-users and edp-specialists”, Management Science,
vol. 30, n.2, February 1984.
[Brooks 87] - Brooks, F. – Essence and Accidents to Software Engineering
– IEEE Computer, vol.4 no. 3, 1987, pp.10-19.
[Carmel 93] - Carmel, E., Whitaker, R.D. & George, F.J. Participatory
Design and Joint Application Design: A Transatlantic Comparison.
Communications of the ACM, vol. 34, no. 4, June, 1993.
[Carvalho, Fuks 92] – Carvalho, Sonia S.; Fuks, Hugo (1992) “Groupware –
A incorporação de aspectos sociais ao software”, Monografia em Ciências da
Computação 6/92, Departamento de Informática, PUC/RJ.
[Castro 95] - Castro J.F.B. Introdução a Engenharia de Requisitos. Jornada
de Atualização em Informática do XIV Congresso da Sociedade Brasileira de
Computação, Canela, Agosto, 1995.
[Chen 1976] - Chen, P.P.S. "The entity-relationship model: Towards a
unified view of data". ACM Trans. Database System, 1, 1976.
[Cook et. al 87] – Cook, Peter; Ellis, Clarence; Graf, Mike; Rein, Gail;
Smith, Tom (1987) “Project Nick: Meetings argumentation and analysis”, ACM
Transactions on Office Information Systems – April 1987, vol.5, n.2.
[Cronan, Means 84] – Cronan, Timothy P. e Means, Thomas L. (1984)
“System Development: An Empirical Study of User Communication”, Data Base,
Spring 1984.
[Curtis et. al 88] – Curtis, Bill; Krasner, Herb e Iscoe, Neil (1988) “A Field
Study of the Software Design Process for Large Systems”, Communications of the
ACM, November 1988, vol.31, N. 11.
[Cyert, MacCrimmon 68] – Cyert, Richard M.; MacCrimmon, Kenneth R.
(1968) “Organizations in The handbook of social psychology” – Lindzey,
Gardner; Aronson, Elliot; Addison-Wesley Publishing Company – vol.1.
[Cysneiros 99] – Cysneiros, L.M.; Leite, J.C.S.P. – Integrating non-
functional requirements into data modeling , in Proceedings of the Fourth IEEE
163
International Symposium on Requirements Engineering, Limerick, Ireland, 1999
(to appear) (http://www.ul.ie/~isre99/).
[Chung00] - Chung, L, Nixon, B.A., Yu, E., Mylopoulos, J. Non-Functional
Requirements in Software Engineering, Kluwer Academic Publishers, 2000.
[Davis 90] – Alan M. Davis (1990). Software Requirements Analysis and
Specification. Prentice-Hall International.
[Deutsch 73] – Deutsch, Morton (1973) “The resolution of conflict”, New
Haven and London: Yale University Press.
[Duarte et. al 92] – Duarte, Renato C.; Fuks, Hugo; Lucena, Carlos J. P.
(1992) “Software design cooperativo: um estudo de caso”, Monografias em
Ciência da Computação 4/92, Departamento de Informática, PUC/RJ
[Easterbrook 90] – Easterbrook, Steve (1990) “Handling conflict between
domain descriptions with computer-supported negotiation”, Proceedings, 5th
AAAI workshop on knowledge acquisition for knowledge-based systems, Canada.
[Ellis et. al 91] - Ellis, C. A.; Gibbs, S. J.; Rein, G. L. (1991) “Groupware –
some issues and experiences”, Communications of the ACM, January 1991,
vol.34, n.1.
[Fagan 86] – Fagan, M. E. (1986). Advances in Software Inspections. IEEE
Transactions on Software Engineering SE-12(7): 744-51.
[Farreny 1985] - FARRENY, Henri. Les Systemes Experts: principles et
exemples. Toulouse: CEPADUES-Editions, 1985.
[Feigenbaum 63] - FEIGENBAUM, E.A. e FELDMAN,J. Computers and
thought. McGraw-Hill, New York, 1963.
[Fiorini 98] - Fiorini, S.T; Staa, A.v., Martins, R.B. Engenharia de Software
com CMM, Rio de Janeiro, Editora Brasport, 1998.
[Floyd et. al 89] – Floyd, Christiane; Mehl, Wolf-Michael; Reisin, Fanny-
Michaela; Schmidt, Gerhard e Wolf, Gregor (1989) “Out of Scandinavia:
Alternative approaches to software design and system development” Technical
University of Berlin, Human-Computer Interaction, Vol.4.
[Forgy 82] - Forgy, C.: Rete: A Fast Algorithm for the Many Pattern/Many
Object Pattern Match Problem. In Artificial Intelligence, v. 19, pp 17-37. 1982.
[Freeman 87] – Freeman, P. A., Software Perspectives: The System is the
Message, Addison-Wesley, Reading, Massachusetts, 1987.
164
[Gardner 92] - GARDNER, H. Multiple Intelligences - Theory in Practice,
Ed. Basic Books, 1992.
[Garg-Janardan, Salvendy 87] – Garg-Janardan, Chaya; Salvendy, Gavriel
(1987) “A conceptual framework for knowledge elicitation” Int. J. Man-Machine
Studies 26, 1987.
[Ghezzi 91] – Carlo Ghezzi, Mehdi Jayazeri and Dino Mandrioli (1991).
Fundamentals of Software Engineering. Prentice-Hall International Editions.
[Giarratano 1998] - GIARRATANO, J..: CLIPS User’s Guide, Version
6.10, 1998
[Gilb 97] - Gilb, T. Towards the Engineering of Requirements.
Requirements Engineering Journal, vol. 2, no. 3, 1997.
[Goguen 94] –Goguen, J. Requirements Engineering as the Reconciliation
of Social and Technical Issues. Requirements Engineering: Social and Technical
Issues, Academic Press Inc., London, England, 1994.
[Goguen 93] – Goguen, J. and Linde, C. (1993). Techniques for
Requirements Elicitation. Proc. RE´93, San Diego, California, IEEE Computer
Society Press.
[Gunther 78] – Gunther, R., Management Methodology for Software
Product Engineering, Wiley-Interscience Publication, Jonh Wiley & Sons, New
York 1978.
[Hampton 83] – Hampton, David R. (1983) “Administração
Contemporânea”, editora McGraw-Hill do Brasil.
[IEEE 97] - IEEE. IEEE Software Standards Collection. IEEE Computer
Society Press, Los Alamitos, USA, 1997.
[Jackson 95] – Jackson, M., Software Requirements & Specifications, First
edition, Addison – Wesley, 1995.
[Kahn et. al 64] - Kahn, Robert L.; Wolfe, Donald M.; Quinn, Robert P.;
Snoek, J. Diedrick (1964) “Organizational stress – Studies in role conflict and
ambiguity” , Jonh Wiley & Sons, Inc.
[Kim, Courtney 88] – Kim, Jungduck; Courtney, James F. (1988) “A survey
of knowledge acquisition techniques and this relevance to managerial problem
domains”, Decision Support Systems 4.
[Lamsweerde 02] - Axel van Lamsweerde - Formal Specification: a
Roadmap, Département d’Ingénierie Informatique Université catholique de
165
Louvain - In "The Future of Software Engineering", A. Finkelstein (ed.), ACM
Press.
[Lee 98] - Lee, W.J., Cha, S.D. & Kwon, Y.R. Integration and Analysis of
Use Cases Using Modular Petri Nets in Requirements Engineering. IEEE
Transactions on SoftwareEngineering, vol. 24, no. 12, December, 1998.
[Lehman 94] - Lehman M M, Evolution in the Context of Software
Technology, Encyclopaedia of Software Engineering, Wiley and Co., 1994, vol. 2,
pp. 1202 – 1208
[Leite 01] – Leite, J.C.S.P. , Qualidade de Software: Teoria e Prática, Orgs.
Rocha, Maldonado, Weber, Prentice-Hall, São Paulo, 2001. Capítulo 17.
[Leite 94] - Leite, J.C.S.P. Engenharia de requisitos. Rio de Janeiro : PUC-
RIO, 1994. (Notas de Aula).
[Leite 88] – Leite, Julio César Sampaio do Prado (1988) “Viewpoint
Resolution in Requirements Elicitation” PhD Thesis, University of California,
Irvine.
[Lima 69] – Lima, Lauro de Oliveira (1969) “Treinamento em dinâmica de
grupo”, Editora Vozes
[Lopez 04] - LOPEZ, F.: NASA CLIPS RULE-BASED LANGUAGE
HOME PAGE: In http://www.siliconvalleyone.com/clips.htm, Consultado em 24
de agosto de 2004.
[Macaulay 92] – Macaulay, Linda (1992) “Requirements capture as a
cooperative activity”, Department of Computation, University of Manchester
Institute of Science and Technology.
[Macedo 99] - Macedo, N.A.M. & Leite, J.C.S.P. Integrando Requisitos
Não Funcionais aos Requisitos Baseados em Ações Concretas. Anais do II
Workshop Iberoamericano de Engenharia de Requisitos e Ambientes de Software,
Alajuela, Costa Rica, Marzo, 1999.
[Mailhiot 70] – Mailhiot, Gerald Bernard (1970) “Dinâmica e gênese dos
grupos”, Livraria Duas Cidades.
[Mathias 94] - Mathias, Adolfo Gil. O Gerenciamento de Conflitos na
Elicitação de Requisitos. Dissertação de Mestrado, Programa de Pós-Graduação
em Ciência de Computação da PUC-Rio, 1994.
166
[McMaster, Grinder 80] – McMaster, Michael e Grinder, Jonh (1980)
“Precision: A New Approach to Communication”, Beverly Hills, California :
Precision Models.
[Mumford 87] – Mumford, E. (1987) “Sociotechnical systems design:
evolving theory and practice” in G. Bjerknes, P. Ehn & M. Kyng (Eds.),
“Computers and Democracy: A Scandinavian challenge”, Aldershot, England:
Avebury.
[Parnas, Clements 86] – Parnas, David Lorge & Clements, Paul C. (1986)
“A rational design process: how and why to fake it”, IEEE Transactions on
Software Engineering, vol. 12, n.2, February 1986.
[Prerau 87] – Prerau, David S. (1987) “Knowledge acquisition in the
development of a large expert system”, AI Magazine – vol.8, n.2, summer 1987.
[Pressman 87] – Pressman, Roger S. (1987) “Software Engineering – A
Practitioner´s Approach”, McGraw-Hill Book Company, Second Edition.
[RE 05] Requirements Engineering Conference 2005 site, Fred Brooks
quotation (IEEE Computer 1987) http://crinfo.univ-paris1.fr/RE05/
[Reubenstein 91] – Reubenstein, Howard B. (1991) “The requirements
apprentice: automated assistance for requirements acquisition”, IEEE
Transactions on Software Engineering, vol.17, n3, March 1991.
[Robbins 74] – Robbins, S. P., 1974, “Managing Organizational Conflict: A
non-traditional approach”, Prentice-Hall, NJ.
[Rosson et al 88] – Rosson, Mary Beth; Maass, Susanne Kellogg, Wendy A.
(1988) “The Designer as User: Building Requirements for Design Tools from
Design Practice”, Communications of the ACM, November 1988, Vol. 31, N.11
[Simões 70] – Simões, Roberto (1970) “Introdução à técnica de reunião”,
Editora Atlas S.A.
[Simos 96] Simos, M., et al. “Software Technology for Adaptable Reliable
Systems (STARS) Organization Domain Modeling (ODM) Guidebook” Version
2.0 (STARS-VC-A025/001/00). Manassas, VA: Lockheed Martin Tactical
Defense Systems, 1996. http://www.asset.com/WSRD/abstracts/ABSTRACT_1176.html
[Sommerville 98] Sommerville, I, Software Engineering, Fifth edition,
Addison-Wesley, 1998.
[Stefik et. al 87] – Stefik, M., Foster, G., Bobrow, D. G., Kahn, K., Lanning,
S. e Suchman, L. (1987) “Beyond the chalkboard: Computer support for
167
collaboration and problem solving in meetings”, Communications of the ACM 30
(1).
[Telem 88] – Telem, Moshe (1988) “Information requirements specification
II: brainstorming collective decision-making technique”, Information Processing
& Management vol.24, n.5
[Weil et. al 66] – Weil, Pierre; Schutzenberger, Anne Ancelin; Garcia, Célio
(1966) “Dinâmica de grupo e desenvolvimento em relações humanas”, Editora
Itatiaia.
[Wilensky 83] – Wilensky, Robert (1983) “Planning and understanding – a
computational approach to human reasoning” – Addison – Wesley Publishing
Company.
[Wikipedia 05] – Site Wikipédia - A Enciclopédia livre: In
http://pt.wikipedia.org/wiki/Conflito, visitado em 05 de Junho de 2005.
[Zowghi 02] - Zowghi, Didar. Does Global Software Development need a
diferent requirements engineering process? Proceedings of International
Workshop on Global Software Development 2002. 2002. 3p.
Top Related