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.