Bastos Junior, P. R. O. - Elicitação de Requisitos de Software Através Da Utilização de Questionários

Paulo Roberto de Oliveira Bastos Junior
Elicitao de requisitos de software atravs da

utilizao de questionrios
Dissertao de Mestrado
Dissertao apresentada ao Programa de Ps-graduao em Informtica da PUC-Rio como requisito
parcial para obteno do ttulo de Mestre em
Informtica.
Orientador: Julio Csar Sampaio do Prado Leite

Rio de Janeiro
Abril de 2005
Todos os direitos reservados. proibida a reproduo total ou

parcial do trabalho sem autorizao do autor, do orientador e
da universidade.
Paulo Roberto de Oliveira Bastos Junior

Graduou-se em Engenharia de Computao pela PUC-Rio
em 2001. rea de interesse acadmico: Engenharia de
software, mais especificamente a sub-rea de Engenharia de
Requisitos. Atualmente trabalhando na multinacional de
consultoria Accenture como Consultor, atuando como
coordenador da equipe de operaes do sistema B2B Canal
Cliente da Petrobras, realizando as seguintes atividades:
levantamento de requisitos com o cliente; anlise e
especificao (tcnica e funcional) das atividades a serem
desenvolvidas; participao nas reunies/Atas e definies do
projeto.
A meus pais
Agradecimentos
A meus pais, pela fora e incentivo.

A Deus, por me iluminar e me dar foras para atingir esse objetivo.
A PUC-Rio, pelos auxlios concedidos, sem os quais esse trabalho no poderia ser
realizado.
A Julio Csar Sampaio do Prado Leite, orientador da dissertao, pelo apoio dado
durante essa jornada.
RESUMO
Bastos Junior, Paulo Roberto de Oliveira; Leite, Julio Csar Sampaio do

Prado; Elicitao de requisitos de software atravs da utilizao de
questionrios. Rio de Janeiro, 2005. 81p. Dissertao de Mestrado
Departamento de Informtica, Pontifcia Universidade Catlica do Rio de
Janeiro.
Um dos possveis meios utilizados para a coleta de fatos na elicitao de

requisitos o uso do questionrio. Um questionrio consiste num documento
usado para guiar uma ou mais pessoas a responder a uma ou mais perguntas. A
elaborao de um questionrio um processo bem mais complexo do que possa
aparentar. Um questionrio mal formulado pode levar a consideraes erradas, o
que acaba sendo prejudicial ao projeto em questo. No existe um mtodo padro
para a construo de questionrios, porm existem recomendaes de diversos
autores com relao a essa importante tarefa no processo de pesquisa cientfica. O
trabalho aqui apresentado detalha a tcnica de questionrios, identificando as
etapas necessrias e comuns criao de um questionrio eficaz. Ser proposto
um mtodo para a construo de perguntas de questionrios, que utiliza como base
uma listagem de requisitos para a construo de questionrios de qualidade, obtida
aps a realizao de uma extensa pesquisa nas reas de cincias sociais e
marketing. Posteriormente apresentamos uma ferramenta utilizada para elicitao
de requisitos de software, atravs da utilizao de questionrio, questionrio esse
gerado atravs do mtodo proposto no presente trabalho.
Palavras-Chave
Engenharia
questionrios.
de
Requisitos;
elicitao
de
requisitos;
informtica;
ABSTRACT
Bastos Junior, Paulo Roberto de Oliveira; Leite, Julio Csar Sampaio do

Prado;
Software
requirements
elicitation
through
the
use
of
questionnaires. Rio de Janeiro, 2005. 81p. Master degree thesis

Computer Science Department, Pontifcia Universidade Catlica do Rio de
Janeiro.
Questionnaire is one of the techniques available for
requirements
elicitation. A questionnaire is a document used to guide one or more people to

answer one or more questions. The elaboration of a questionnaire is a process
more complex than it can make look like. A questionnaire that is not well
formulated can lead to unreliable information and may be harmful to the project
in question. Although there is no standard method for the construction of
questionnaires, there are recommendations from diverse authors with regard to
this important task in the process of eliciting information. The work presented
here details a technique for identifying the necessary and common stages for the
creation of a questionnaire. A method for the construction of questions is
proposed, which uses as base a list of requirements for the construction of quality
questionnaires, obtained from the literature in the areas of social sciences and
marketing. A tool for the elicitation of software requirements, by means of
questionnaires is presented.
Keywords
Software Engineering; requirements elicitation; questionnaires.
SUMRIO
1. Introduo
1.1. Motivao
1.2. Objetivo da dissertao
11
1.3. Organizao da dissertao
12
2. Reviso da literatura
13
2.1. A utilizao de questionrios na Engenharia de Requisitos
13
2.2. A tcnica GQM
26
3. Questionrios
29
3.1. Tipos de questes
29
3.2. Requisitos para a construo de questionrios de boa qualidade
36
3.3. Erros comumente cometidos num processo de aplicao de

questionrios
40
3.4. Avaliao do questionrio
41
4. Um processo para a elaborao de perguntas de questionrios para a

elicitao de requisitos de software
44
4.1. Definio do processo
44
5. Experimento prtico
61
5.1. Caractersticas gerais da ferramenta
61
5.2. Apresentao da ferramenta
65
5.3. Mtodo utilizado para anlise das respostas e priorizao dos

requisitos
76
6. Avaliao, contribuio e desdobramentos
78
6.1. Avaliao do mtodo e da ferramenta propostos
78
6.2. Comparao com outras iniciativas
79
6.3. Contribuies
82
6.4. Trabalhos futuros
83
7. Referncias bibliogrficas
84
1
Introduo
O objetivo desse captulo estabelecer o contexto de nossa pesquisa. Em

primeiro lugar, so apresentados os aspectos de motivao dessa dissertao. Em
segundo, so detalhados os objetivos que se espera serem atingidos atravs do
desenvolvimento dessa dissertao. Em terceiro, so discutidos os aspectos de
contribuio do nosso trabalho no contexto da Engenharia de Software.
Finalmente, apresentado um sumrio dos prximos captulos dessa dissertao.
1.1.
Motivao
O desenvolvimento de software requer uma srie de levantamentos
necessrios para se definir as necessidades de um projeto a ser iniciado e que so
comuns a qualquer projeto de software, como por exemplo:
Identificao dos requisitos funcionais e no-funcionais do sistema a
ser construdo;
Identificao da infra-estrutura necessria;
Levantamento da quantidade de profissionais e suas respectivas
competncias;
Definio das tecnologias a serem utilizadas;
Planejamento das atividades a serem realizadas;
Planejamento do cronograma do projeto;
Definio do processo a ser adotado;
Definio dos mtodos a serem utilizados;
Muitas vezes difcil fazer reunies iniciais ou entrevistas para realizar o

levantamento de requisitos do software em funo da dificuldade em se reunir
todos os envolvidos ou interessados1 em um determinado projeto, seja por
1
Os envolvidos ou interessados em um projeto so denominados stakeholders do projeto.
10
questes geogrficas (distncia fsica), por indisponibilidade de agenda para a

presena de todos os envolvidos no projeto em questo ou at mesmo pelo no
envolvimento e desinteresse das pessoas nas fases iniciais dos projetos. Sendo
assim, alguns requisitos importantes no so documentados e priorizados e como
conseqncia acabam no sendo levados em considerao nos ciclos de
desenvolvimento do sistema em questo. Nesses casos, por exemplo, a tcnica de
questionrios poderia ser empregada, de forma que os respondentes pudessem
enviar as respostas quando lhes fosse mais conveniente.
Questionrios so um dos possveis meios utilizados para a coleta de fatos
na elicitao de requisitos. Um questionrio consiste num documento usado para
guiar uma ou mais pessoas a responder a uma ou mais perguntas. A elaborao de
um questionrio um processo bem mais complexo do que possa aparentar.
Segundo Goode & Hatt [1], este instrumento de coleta de dados pode ser
administrado por auto resposta ou por entrevista.
Segundo Parasuraman [3], um questionrio ...to somente um conjunto
de questes, feito para gerar os dados necessrios para se atingir os objetivos do
projeto. Embora o mesmo autor afirme que nem todos os projetos de pesquisa
utilizam essa forma de instrumento de coleta de dados, o questionrio muito
importante na pesquisa cientfica, especialmente nas Cincias Sociais.
Parasuraman [3] afirma tambm que construir questionrios no uma tarefa fcil
e que aplicar tempo e esforo adequados para a construo do questionrio uma
necessidade, um fator de diferenciao favorvel. Um questionrio mal formulado
pode levar a consideraes erradas, o que acaba sendo prejudicial ao projeto em
questo. No existe um mtodo padro para o projeto de questionrios, porm
existem recomendaes de diversos autores com relao a essa importante tarefa
no processo de pesquisa cientfica.
11
1.2.
Objetivo da dissertao
Nessa dissertao identificamos as etapas necessrias e comuns criao de
um questionrio, com objetivo de elaborar uma lista de requisitos a serem
utilizados como base para a gerao de questionrios. Este conhecimento foi
adquirido atravs da bibliografia existente sobre o assunto.
Aps a identificao das etapas necessrias, objetiva-se a elaborao de um
mtodo que apie o processo de gerao de perguntas de questionrios,
questionrios esses a serem utilizados para a coleta de requisitos e sua priorizao.
Ser provido ento ao Engenheiro de Software uma forma de ajud-lo no processo
de elaborao de questionrios, sobretudo no processo de elaborao de
perguntas, criao e formatao dos mesmos.
O objetivo no a construo de um questionrio que cubra todos os casos e
requisitos possveis; a idia que com o tempo ele v sendo incrementado e
ajustado. No o seu objetivo tambm substituir reunies ou entrevistas de
levantamento de requisitos, mas sim apoi-las, priorizando perguntas previamente
definidas (possveis requisitos) de acordo com a opinio dos respondentes. O
questionrio poder ser aplicado aos respondentes, por exemplo, antes da
realizao de reunies, com o objetivo de orientar o Engenheiro de Software a
identificar quais os pontos mais importantes a serem levantados, do ponto de vista
dos respondentes. Ele poder ser aplicado tambm na fase inicial de um projeto,
onde os resultados obtidos estaro apoiando, servindo de base para o ciclo de vida
do projeto, j que a qualquer momento teremos condies de confrontar os
requisitos que foram priorizados pelos usurios com os que esto sendo levados
em considerao no desenvolvimento do sistema em questo.
12
1.3.
Organizao da dissertao
Nessa dissertao ser apresentada uma estratgia para a coleta de requisitos
e sua priorizao baseada na utilizao da tcnica de questionrios. O objetivo
prover um apoio etapa inicial de elicitao de requisitos.
O captulo 2 apresenta uma reviso da literatura a respeito do estado da arte
no que diz respeito utilizao de questionrios na Engenharia de Requisitos.
Alm disso, tambm ser apresentada a tcnica GQM (Goal Question Metric),
utilizada no mtodo proposto nessa dissertao.
No captulo 3 sero apresentados os conceitos que fundamentam a tcnica
de questionrios. Alm disso, ser mostrado tambm que, aps a realizao de
uma extensa pesquisa nas reas de Cincias Sociais e Marketing, com objetivo de
colher as principais recomendaes de diversos autores a respeito das boas
prticas a serem consideradas na elaborao e formulao de questionrios em
geral, foi consolidada uma lista de requisitos para a construo de questionrios de
qualidade.
No captulo 4 ser apresentada a definio de um processo para a elaborao
de perguntas de questionrios para a elicitao de requisitos de software. O
objetivo prover ao Engenheiro de Software uma forma de ajud-lo no processo
de construo de questionrios, sobretudo no processo de elaborao e criao de
perguntas.
No captulo 5 ser apresentada uma ferramenta utilizada para o processo de
criao das perguntas de questionrios e avaliao dos resultados obtidos, atravs
das respostas enviadas pelos respondentes.
O captulo 6 ir discutir o mtodo e a ferramenta propostos, com objetivo de
avali-las. Posteriormente, ser feira uma comparao da nossa proposta com
outras iniciativas anlogas, ou seja, iniciativas relacionadas ao processo de
elicitao de requisitos atravs da utilizao de questionrios, que foram
identificadas no decorrer do processo de pesquisa. Apresentaremos a concluso,
as contribuies esperadas e sugestes de possveis desdobramentos dessa
dissertao.
13
2
Reviso da literatura
Esse captulo tem por objetivo apresentar o estado da arte no que diz
respeito utilizao de questionrios para a elicitao de requisitos, sobretudo
requisitos de software, no contexto da Engenharia de Software. Posteriormente,
ser apresentada a tcnica GQM (Goal Question Metric), que ser utilizada no
processo de elaborao de perguntas.
2.1.
A utilizao de questionrios na Engenharia de Requisitos
O trabalho estuda a tcnica de questionrios para a elicitao de requisitos
e sua priorizao. Questionrios so utilizados em diversas reas, sobretudo nas
Cincias Sociais e Marketing, sendo aplicados, por exemplo, em pesquisas de
opinio, censo e pesquisas de boca de urna em poca de eleio. Questionrios
tambm so bastante utilizados como uma tcnica auxiliar s tcnicas de
entrevistas e reunies, tcnicas essas amplamente utilizadas no processo de
elicitao de requisitos. Um dos objetivos aqui propostos estudar e explorar a
sua utilizao na rea de Engenharia de Requisitos, como uma tcnica a ser
utilizada para a elicitao de requisitos, sobretudo requisitos de software. O
objetivo prover ao Engenheiro de Software uma forma de ajud-lo no processo
de elaborao de questionrios, sobretudo no processo de elaborao de
perguntas, criao e formatao de questionrios.
Para que isso fosse possvel, foram realizadas vrias pesquisas com objetivo
de identificar iniciativas que utilizassem questionrios para a elicitao de
requisitos de software. A idia era tentar utilizar ao mesmo tempo tcnicas para a
formulao de bons questionrios (o que no envolve muito o conhecimento
tcnico, mas sim humano) e as tcnicas de Engenharia de Software destinadas a
esse fim. Esse processo deu-se atravs da realizao de pesquisas em duas reas
diferentes: pesquisas na rea de Engenharia de Software e mais especificamente
14
na rea de Engenharia de Requisitos; pesquisas em outras reas, tais como:

Cincias Sociais e Marketing [1-4, 7-8]. As pesquisas realizadas na segunda rea
resultaram positivamente, tendo o resultado dessas pesquisas gerado uma lista de
requisitos para a construo de questionrios de qualidade, com boas prticas para
a criao e formulao de bons questionrios.
J as pesquisas na rea de Engenharia de Software e mais especificamente
na rea de Engenharia de Requisitos, tambm foram realizadas pesquisas em
diversas fontes, tais como:
No site de buscas do Google;
Em peridicos, portais, workshops e conferncias da rea, tais como:
Workshop on Requirements Engineering [33, 34]; The 16th International

Conference on Advanced Information Systems Engineering [25]; Requirements
Engineering Journal [38]; REFSQ04 [39]; IEEE Computer Society [26]; Schloss
Dagstuhl International Conference and Research Center for Computer Science
[27]; SpringerLink [28]; M.E.Sharpe, Inc. [29]; Volere Requirements Resources
[40]; RE 2003 - 11th IEEE International Requirements Engineering Conference
[41]; RE 2004 - 12th IEEE International Requirements Engineering Conference
[42]; The Requirements Engineering Specialist Group of the British Computer
Society [43]; Journal of Management Information Systems [44]; Journal of
Information, Law e Technology [30]; Journal of Information e Knowledge
Management [31];
Nas bibliotecas central e setorial de informtica da PUC-Rio;
Foram trocados e-mails com alguns professores de universidades
estrangeiras da rea de Engenharia de Software, tais como: Luisa Mich

(Department of Information and Communication Technology - University of
Trento); Mark Bergman (Information and Computer Science Department University of California, Irvine); Al Davis (Information Systems College of
Business - University of Colorado); Glenn Browne (Texas Tech University);
Katrina Hands (Applied Computing University of Dundee); Sue Lewis (School
of Mathematics - University of Southampton); Alistair Sutcliffe (Systems
Engineering University of Manchester); Bashar Nuseibeh (Computing
Department The Open University);
15
Essas buscas no tiveram um resultado to positivo quanto o obtido na rea

de Cincias Sociais, porm, foram identificadas algumas fontes importantes para a
pesquisa que, mesmo no estando diretamente relacionadas a elicitao de
requisitos atravs da utilizao de questionrios (a maioria dos resultados obtidos
eram diretamente relacionados s tcnicas de entrevista ou de reunio), ajudaram
a servir de base para o processo de pesquisa e estudo do estado da arte do assunto.
Foram identificados dois principais artigos e uma dissertao de mestrado,
os quais descreviam cases que utilizaram indiretamente questionrios com esse
fim. O primeiro [23], discute o desenvolvimento de uma ferramenta de entrevistas
realizadas via computador, com objetivo de facilitar a elicitao de requisitos e
conduzir avaliaes de usurios. Esse artigo utilizou a tcnica de questionrios
como uma tcnica auxiliar, com objetivo de apoiar a tcnica de entrevistas.
Pesquisas realizadas analisaram as tcnicas e processos adotados por
entrevistadores especialistas humanos e simularam essas tcnicas e processos em
softwares. Um projeto de pesquisa foi ento desenvolvido como uma investigao
preliminar da potencial incorporao de uma ferramenta de entrevistas via
computador nas reas de usabilidade e de Engenharia de Software. O objetivo do
projeto, denominado UsE-IT, foi verificar se uma ferramenta de entrevista via
computador poderia ajudar a facilitar os processos de obteno de requisitos e
teste com usurio, que poderiam conseqentemente permitir de forma mais
eficiente a criao de um sistema que satisfizesse os usurios. Foi planejado
desenvolver uma ferramenta de entrevistas composta de duas partes: uma
interface hipermdia para entrevistas e uma interface hipermdia para a anlise das
entrevistas.
Abaixo apresentado um resumo dos principais requisitos definidos para o
sistema que foi construdo, em [23]:
Ordenao dinmica das questes: cada questo deveria ter associada a
ela um valor de prioridade, que poderia ter o seu valor alterado durante o curso da
entrevista dependendo das respostas dadas pelos entrevistados durante a
realizao da entrevista. Devem ser exibidas aos entrevistados as questes com
prioridade mais alta. Logo, as questes devem ser perguntadas em uma ordem
apropriada e apenas questes relevantes devem ser perguntadas.
16
Na figura abaixo possvel visualizar o processo de ordenao dinmica das

questes:
Figura 1 Processo de ordenao dinmica das questes de [23]
Tipos de questo: as questes podem estar numa variedade de formatos.
As de mltipla escolha devem ser utilizadas para questes fechadas e as de texto

livre devem ser utilizadas para questes abertas. Tambm poderia existir a
facilidade de utilizar ckeck-lists e listas drop-down conforme apropriado, de modo
a tornar o processo de entrevistas o mais simples possvel para o entrevistado.
Facilidade para rever as respostas: os entrevistados deveriam ser capazes
de rever todas as respostas que eles tivessem dado durante qualquer estgio da
entrevista.
Confirmao das respostas: deveria ser solicitado que os entrevistados
confirmassem suas respostas s questes de texto livre. Isso poderia permitir que
os entrevistados checassem se eles marcaram as respostas da forma que eles
realmente pretendiam.
Sem facilidade para alterar as respostas: os entrevistados no deveriam
ser capazes de alterar suas respostas uma vez que elas tivessem sido salvas na
base de dados. Isso para imitar as entrevistas face-a-face onde todas as respostas
dadas sero lembradas pelo entrevistador. Uma questo pode ser apresentada mais
de uma vez durante o processo de entrevista, podendo ser dadas respostas
diferentes para a mesma pergunta, mas todas as respostas devem ser gravadas na
base de dados.
17
Facilidade para adicionar comentrios: os entrevistados deveriam ser
capazes de adicionar comentrios a qualquer resposta dada, no momento em que

eles estiverem respondendo ou quando estiverem revendo as respostas dadas
anteriormente. Isso permite que expandam, expliquem ou justifiquem suas
respostas sempre que sentirem necessidade.
Foi decidido tambm que o processo de entrevista deveria ser extremamente
fcil de ser realizado por usurios de computador experientes e inexperientes. A
ferramenta deveria estar altamente acessvel, ento usabilidade e acessibilidade
foram consideradas importantes durante todo o processo de desenho. Foi
considerado importante implementar um sistema que se permitia um processo
interativo com o entrevistado. Essa interao entre os entrevistados e os
entrevistadores realizada perguntando aos entrevistados certas questes e depois
imediatamente perguntando questes diretamente relacionadas s respostas que
foram dadas anteriormente, conforme apropriado. Outra tcnica de entrevista
utilizada foi a de perguntar apenas questes relevantes aos entrevistados, j que os
mesmos tendem a responder mais favoravelmente se sentirem que cada questo
importante e significante.
As questes includas na entrevista e suas ordens correspondentes so
determinadas pelos autores da entrevista. Conforme as questes iam sendo
cadastradas na base de dados, foram sendo associadas prioridades a elas, o que
determinava a ordem em que elas iriam ser apresentadas aos entrevistados. Certas
regras foram sendo utilizadas para alterar as prioridades das questes conforme
necessrio, durante o processo atual de entrevistas. Foi desenvolvido um sistema
web, de forma a atender o requisito de que o sistema deveria estar disponvel a
usurios em uma variedade de localizaes geogrficas.
O segundo artigo [32], discute as causas razes da dificuldade de se capturar
requisitos arquiteturais significantes, sugerindo ento uma abordagem sistemtica
para a captura desses tipos de requisito, que so extremamente importantes, de
forma a garantir que eles no sejam negligenciados. Um requisito arquitetural
qualquer requisito arquiteturalmente significante, onde o nvel de significncia
pode estar implcito ou explcito. Requisitos arquiteturais implcitos so aqueles
que possuem atributos particulares. Por exemplo, qualquer requisito de alto risco,
alta prioridade ou baixa estabilidade pode ser considerado arquiteturalmente
18
significante. Entretanto o artigo foca primeiramente nos requisitos explcitos, os

quais so freqentemente tcnicos por natureza.
Alguns exemplos de requisitos arquiteturais explcitos:
Suporte a mltiplas linguagens;
O banco utilizado ser o Oracle 8i;
O sistema rodar sete dias por semana, vinte e quatro horas por dia;
Ser requerido um help on-line;
Toda a lgica de apresentao ser escrita em Visual Basic.
O mtodo prope uma abordagem sistemtica que proveja um framework

para classificar requisitos arquiteturais, de forma a garantir tambm que eles no
sejam negligenciados.
Nesse artigo [32] um sistema para a classificao de requisitos, o FURPS+
[32], foi desenvolvido por Robert Grady da empresa Hewlett-Packard. O
acrnimo FURPS+ representa:
Funcionalidade;
Usabilidade;
Confiabilidade;
Performance;
Suportabilidade.
O + em FURPS+ nos ajuda a lembrar interesses como:
Requisitos de desenho;
Requisitos de implementao;
Requisitos de interface;
Requisitos fsicos.
A sigla URPS restante descreve requisitos no funcionais que so

geralmente arquiteturalmente relevantes:
Usabilidade: interesse nas caractersticas como esttica e consistncia na
interface do usurio;
19
Confiabilidade: interesse nas caractersticas como disponibilidade,
acurcia nos clculos realizados pelo sistema, e habilidade do sistema se recuperar

no caso de falhas;
Desempenho: interesse nas caractersticas como transferncia de dados,
tempo de resposta, tempo para recuperao, tempo para inicializao.
Suportabilidade: interesse nas caractersticas como testabilidade,
adaptabilidade,
gerenciabilidade,
compatibilidade,
configurabilidade,
instalabilidade, escalabilidade e locabilidade.

O + no acrnimo FURPS+ utilizado para identificar categorias que
geralmente
representam
restries.
De
modo
simplificado,
mecanismos
arquiteturais representam uma soluo comum para um problema encontrado com

freqncia. Mecanismos arquiteturais so freqentemente utilizados para realizar
requisitos arquiteturais. A tabela abaixo, obtida em FURPS [32], mostra trs
categorias de mecanismos arquiteturais e como mecanismos arquiteturais so
expressos em cada uma das trs categorias:
Mecanismo de anlise
Mecanismo de desenho
Mecanismo de
implementao
Persistncia
RDBMS
Oracle
OODBMS
Ingres
ObjectStore
Comunicao
Object Request Broker
Orbix, VisiBroker
Message queue
MSMQ, MQSeries
Um mecanismo de anlise representa uma implementao independente de

soluo. Um mecanismo de desenho um refinamento do mecanismo de anlise.
Ele assume alguns detalhes do ambiente de implementao, mas no faz parte de
uma implementao especfica. Finalmente um mecanismo de implementao
um refinamento do mecanismo de desenho e especifica a implementao exata do
mecanismo.
20
A figura abaixo resume os relacionamentos entre requisitos e mecanismos

mostrando refinamentos dos requisitos do FURPS em diferentes nveis de
refinamento:
Figura 2 Relacionamentos entre requisitos e mecanismos [32]
A abordagem proposta para obter requisitos arquiteturais com FURPS foi a

seguinte, de acordo com [32]:
1. Mantenha uma lista completa de requisitos arquiteturais, sem levar em
considerao se os itens listados so relevantes ou no para um projeto
particular;
2. Para cada requisito arquitetural, formule uma ou mais questes que
possam ajudar no processo de especificao. Tenha certeza de que todos os
envolvidos no projeto possam entender essas questes;
3. Ajude os envolvidos no projeto mostrando a eles o impacto potencial
de responder uma questo de uma forma ou de outra;
4. Capture as respostas dadas a cada uma das questes;
5. Ajude o arquiteto assegurando que os envolvidos no projeto (em adio
s respostas das questes) atribuam uma prioridade ou um peso a cada requisito
arquitetural. Esse peso atribudo ajudar o arquiteto a fazer escolhas entre os
requisitos.
21
A tabela abaixo exemplifica um questionrio desse tipo, questionrio esse

proposto em FURPS [32], que inclui tambm exemplos de respostas:
Requisito
Questes
Impacto
Respostas
Priori
dade
Licenas
O sistema, ou
Quanto maior a
O mdulo de
parte dele ser
sofisticao do
controle de
licenciado?
mecanismo de
estoque ser
licenciamento,
comercializado
Existem muitas
maior o tempo para
como um
restries no
realizao da
componente
mecanismo
comercializao e
separado do
utilizado para
maior o custo de
sistema e ir
prover
manuteno.
requerer licena.
capacidade de
A ferramenta
licenciamento?
FlexLM
Mdia
utilizada por
toda nossa
organizao para
prover
capacidade de
licenciamento.
Disponibili-
Existe algum
Quanto maior a
Disponibilidade
dade
requisito a
disponibilidade,
uma
respeito do tempo maior o grau de
caracterstica
mdio entre
comercializao do
chave do
falhas do sistema
sistema.
produto. O
(MTBF)?
Alta
produto deve ter

um MTBF de 60
dias
Que plataformas
O desenvolvimento
O produto deve
Alta
22
Suporte a
o sistema deve
para uma nica
ser
plataformas
suportar?
plataforma pode
implementado
reduzir o potencial
para rodar nas
de comercializao
seguintes
do produto.Tambm plataformas
pode permitir uma
UNIX:
integrao com as
Sun Solaris
caractersticas das
IBM AIX
plataformas.
HPUX
J a dissertao da Ana Paula Gilvaz [5] prope uma estratgia na qual o

Engenheiro de Software conta com a ajuda de um assistente automatizado para a
conduo de entrevistas. Essa estratgia instancia um modelo conceitual durante o
processo de entrevistas, modelo conceitual esse que representa os elementos do
sistema objeto, segundo o enfoque dado por trs mtodos para a determinao de
requisitos de informao: BSP (Business System Planning), CSF (Critical Sucess
Factors) e E/M (End-Means Analysis). Esses mtodos utilizam uma estratgia
para a determinao dos requisitos do sistema de informao, tomando como base
a anlise das caractersticas do sistema envolvente ao sistema de informaes, que
a Organizao.
Aps a entrevista, o Engenheiro de Software dispe de uma base de
conhecimento organizada segundo o modelo conceitual proposto. O Engenheiro
de Software interage com o assistente e o cliente, conduzindo o processo de
entrevista. No decorrer da entrevista uma ferramenta (FAES), que consiste num
assistente para apoiar a entrevista, sugere a agenda de perguntas, fazendo crticas
com base em heursticas e informaes armazenadas na base de conhecimento. O
cliente vai fornecendo as respostas que vo sendo alimentadas na ferramenta pelo
Engenheiro de Software.
A ferramenta composta de quatro componentes:
Controle: trata da interao com o Engenheiro de Software e controla os
mecanismos para perguntar e aplicar as heursticas;
Agenda de perguntas: baseia-se no modelo conceitual e contm as
perguntas responsveis pela instanciao desse modelo;
23
Base de conhecimento: armazena as respostas fornecidas pelo cliente, as
crticas feitas pela ferramenta, e as entradas feitas pelo Engenheiro de Software;
Heursticas: foram derivadas do modelo conceitual e do seu uso em
experimentos pilotos.
Nessa dissertao [5], foi adotado um padro de questionrio utilizado para
instanciar o modelo que utiliza o conceito de unificao de variveis, isto , cada
pergunta composta de uma parte fixa mais uma parte varivel que corresponde
resposta de uma outra pergunta j respondida. Cada pergunta tem o objetivo de
instanciar um nodo no meta-modelo. A relao entre duas perguntas definida por
cada arco que liga um par de nodos do modelo. No decorrer da entrevista, os
nodos vo sendo instanciados com cada uma das respostas para cada pergunta
feita e os arcos vo ligando cada par de instncias de respostas que se relacionam.
Figura 3 Modelo conceitual de entrevista [5]
A estratgia apresentada na dissertao da Ana Paula Gilvaz [5] prope

cinco tipos de perguntas:
1.
Perguntas de instanciao: se referem s perguntas responsveis pelo
preenchimento do modelo;
24
2.
Perguntas de relao: foram derivadas a partir de um conjunto de
heursticas de relao. Tais heursticas tm o objetivo de descobrir novas relaes

no previamente definidas entre os elementos do modelo;
3.
Perguntas de complementao: foram derivadas a partir de algumas
heursticas de complementao. Seu objetivo verificar se uma informao

associada a algum elemento do modelo importante para algum outro elemento
do modelo que possua uma ligao direta com o elemento informao;
4.
Perguntas de inconsistncia: tem o propsito de alertar sobre
inconsistncias ocorridas a respeito de uma resposta;

5.
Perguntas de investigao: questionam sobre a existncia de
informaes que podem ter sido esquecidas de serem mencionadas, permitindo

que sejam acrescentadas no modelo novas instncias.
Aps a realizao da entrevista, temos uma base de conhecimento onde as
informaes armazenadas esto organizadas segundo o modelo conceitual. O
objetivo que esse modelo fornea os subsdios para que o Engenheiro de
Software possa iniciar o processo de definio de requisitos. O modelo documenta
a entrevista de uma forma estruturada, disponibilizando ao Engenheiro de
Software as respostas da entrevista organizadas segundo o papel de cada uma no
sistema objeto, permitindo que sejam feitas vrios tipos de consultas estruturadas
para extrair do modelo a mais variada gama de informaes.
O uso do modelo permitiu a representao de componentes do sistema
objeto e da relao entre eles, introduzindo uma clareza maior ao problema, alm
de possibilitar a definio de um conjunto de heursticas que criticam e validam as
informaes armazenadas no modelo. Essas heursticas foram derivadas do
modelo conceitual e procuram por relaes que possam fazer algum sentido. As
heursticas utilizadas se classificam em:
Heursticas de relao: esto baseadas na existncia de termos-
comuns entre as instncias do modelo pertencentes a classes conceituais distintas;
Heursticas de complementao: so aplicadas quando as heursticas
de relao so vlidas;
Heursticas de validao: ocorrem quando as heursticas de relao
no so vlidas e caracterizam regras de condio de validade de alguns

componentes do modelo;
25
Heursticas de consistncia: verificam a consistncia de um
componente do modelo.
O assistente atua em dois momentos: em tempo da entrevista, fornecendo
uma estratgia para o preenchimento do modelo conceitual e identificando
relaes
no
pr-definidas;
num
segundo
momento
(ps-entrevista)
disponibilizando o modelo preenchido, que pode ser manipulado para a extrao

de relatrios e estatsticas.
Como pde ser verificado, os artigos [23] e [32] no falam especificamente
da utilizao da tcnica de questionrios para a elicitao de requisitos, sobretudo
requisitos de software. Tanto em [23] quanto em [32], fica a cargo do prprio
Engenheiro de Software formular as perguntas que sero utilizadas nos
questionrios, assim como elabor-los, no existindo um mtodo que o apie
nessa tarefa.
J a dissertao da Ana Paula Gilvaz [5] utiliza a tcnica de questionrios
para a elicitao de requisitos, porm, ela aplicada como um apoio tcnica de
entrevistas. As perguntas do questionrio so geradas pelo assistente automatizado
proposto, com objetivo de conduzir as entrevistas realizadas pelo Engenheiro de
Software.
Esses dois resumos dos artigos [23] e [32] anteriormente detalhados, assim
como a dissertao da Ana Paula Gilvaz [5], foram os que acreditamos terem sido
os mais relevantes, aps as pesquisas que foram realizadas na rea de Engenharia
de Software e mais especificamente na rea de Engenharia de Requisitos. Eles
ajudaram a servir de base para o processo de pesquisa e estudo do estado da arte
do assunto.
26
2.2.
A tcnica GQM
Diversos atributos dos produtos, projetos e processos de software podem
ser medidos. No entanto, deve-se selecionar um conjunto de mtricas pequeno e
equilibrado, que ir ajudar a organizao a acompanhar o progresso na direo de
seus objetivos. Segundo Solingen & Berghout [14], a tcnica GQM Goal
Question Metric (Objetivo/Pergunta/Mtrica) excelente para selecionar as
mtricas apropriadas aos seus objetivos. A tcnica iniciada selecionando-se
alguns objetivos do processo ou da organizao. Declaram-se os objetivos de
modo que sejam quantificveis e mensurveis. Acreditamos que [14] fornece uma
boa explicao sobre GQM e resumimos abaixo seus pontos principais.
Para cada objetivo, identificam-se as perguntas que teriam de ser
respondidas, para saber se o objetivo est sendo alcanado. Se o seu objetivo era
reduzir os custos de manuteno em 50% no prazo de um ano, algumas
perguntas apropriadas poderiam ser: Quanto gasta em manuteno a cada ms?
Qual a parcela dos custos de manuteno que gastamos em cada aplicativo
suportado?
Finalmente, identificam-se mtricas que ajudaro a responder cada pergunta.
De acordo com Solingen & Berghout [14], algumas delas sero simples itens de
dados, contadas diretamente, tais como valor total gasto em manuteno. Outras
mtricas sero calculadas a partir de um ou mais itens de dados. Para responder a
ltima pergunta anterior, deve-se saber o nmero de horas gasto em cada um dos
trs tipos de manuteno citados, bem como o custo total de manuteno em um
dado perodo. As mtricas e sua interpretao refletem os valores e os pontos de
vista dos diferentes grupos afetados: colaboradores, usurios e operadores.
Conforme descrito acima, podemos concluir ento que a tcnica GQM define
certos objetivos, refina esses objetivos em questes e define mtricas que devem
prover informaes que respondam s questes. Respondendo s questes, os
dados medidos definem os objetivos de modo operacional podendo ento ser
analisados para identificar se os mesmos foram atingidos ou no.
27
O primeiro passo de um programa de mtricas estabelecer a baseline2

corrente, de forma que o progresso possa ser avaliado atravs de comparao com
ela e em termos dos objetivos.
O GQM define o modelo de medio em trs nveis, segundo Solingen &
Berghout [14]:
Nvel conceitual (Objetivo): um objetivo definido para um objeto, para
uma variedade de razes, com respeito aos vrios modelos da qualidade, dos
vrios pontos de vista e relativo a um ambiente particular. O conjunto de objetivos
baseado nas necessidades da organizao e seus projetos. O objetivo determina o
que deve ser melhorado ou aprendido. Segundo [14], o processo de definio de
objetivos suportado por templates como o descrito abaixo. Utilizando esses
templates possvel definir objetivos em termos de finalidade, perspectiva e
ambiente. A identificao de sub-objetivos, entidades e atributos relacionados aos
sub-objetivos feita nesse passo.
Finalidade: analisar alguns objetos (processos, produtos) com a finalidade de
melhorar, avaliar, motivar, caracterizar, predizer.
Perspectiva: com enfoque em custo, corretude, remoo de defeitos, mudanas,
segurana, do ponto de vista do usurio, cliente, gerente, desenvolvedor,
corporao.
Ambiente: nos contextos de fatores de problemas, pessoais, recursos, processos.
Nvel operacional (Questo): um conjunto de questes quantificveis so

utilizadas para definir modelos do objeto de estudo e depois focar nesse objeto
para caracterizar a avaliao ou a realizao de um objetivo especfico. Objetivos
de negcio so traduzidos em questes com foco na medio. As mesmas
questes podem ser definidas para suportar interpretaes de dados de mltiplos
objetivos;
Nvel quantitativo (Mtrica): um conjunto de mtricas, baseadas em
modelos, so associadas com cada pergunta com objetivo de responder-lhe de
uma maneira mensurvel. Nesse passo, as mtricas identificadas devem ser
adequadas para prover informaes que respondam s questes. Geralmente cada
mtrica pode fornecer informaes que respondam a vrias questes e algumas
2
Baseline: Conjunto de artefatos aceitos e controlados que sero utilizados em atividades
28
vezes so necessrias combinaes de mtricas para que uma questo seja

respondida.
Figura 4 A tcnica GQM [14]
Segundo Solingen & Berghout [14], uma vez que esses passos foram
identificados, dados so coletados e interpretados para produzir respostas s
questes quantificveis que foram definidas para completar os objetivos.
posteriores sua aceitao. [14]
29
3
Questionrios
Esse captulo tem por objetivo apresentar os principais conceitos envolvidos

na tcnica de questionrios, exibindo tambm os possveis tipos de questes,
respostas e formatos que podem ser apresentados em um questionrio.
Posteriormente, so listados requisitos para a construo de questionrios de boa
qualidade assim como os principais erros comumente cometidos em um processo
de pesquisa com base em questionrios.
3.1.
Tipos de questes
Questionrios podem ser elaborados e aplicados de diversas maneiras, de
acordo com as necessidades. A seguir, segundo Parasuraman [3], sero
apresentadas as principais formas de aplicao de questionrios:
Auto resposta (via correio ou e-mail): tem como vantagens o fato de poder
ser enviado a um grande nmero de pessoas de forma no muito dispendiosa e o
respondente pode preencher o questionrio quando lhe for mais conveniente. No
entanto, este tipo de questionrio tem tambm algumas desvantagens: baixa taxa
de resposta, no sendo indicado para perguntas que exijam respostas muito
detalhadas.
Auto resposta (em grupo): um grupo de pessoas reunido e as perguntas
so feitas simultaneamente, contudo cada pessoa responde individualmente ao seu
questionrio. Os grupos so reunidos mediante algum critrio de convenincia. Se
as pessoas que esto sendo questionadas no entenderem o significado de alguma
pergunta podem pedir ajuda ou esclarecer o propsito do estudo.
Auto resposta (porta a porta): este tipo de questionrio menos habitual.
O investigador, neste caso, desloca-se a casa ou ao local de trabalho dos
30
questionados, entrega e explica o questionrio e depois volta para receb-lo ou

pede que o devolvam pelo correio. Este tipo de questionrio tem a vantagem de
poder ser feito quando mais conveniente ao questionado tal como nos
questionrios via correio ou e-mail e tem a vantagem de ser possvel um contato
com o investigador com o fim de esclarecer dvidas na interpretao das respostas
ou no objetivo do estudo. A grande desvantagem deste tipo de questionrios so
os custos financeiros associados (custo com o deslocamento at os locais da
entrevista, tempo gasto para a realizao das entrevistas e apurao dos
resultados).
Entrevista (pessoal): atravs de uma entrevista, o investigador preenche o
questionrio com as respostas s perguntas que vai fazendo ao questionado. H
um contato pessoal e direto entre o investigador e o questionado. Ao contrrio dos
outros tipos de questionrios, o entrevistador tem a oportunidade de se certificar
que o questionado quer dizer mesmo o que disse. As entrevistas facilitam,
tambm, as respostas s perguntas que pedem opinies. O questionrio por
entrevista consome muito tempo e, conseqentemente, muito dispendioso. O
entrevistador considerado parte do instrumento da recolha de dados e precisa de
um treino prvio para aprender a conduzir uma entrevista e como ultrapassar as
dificuldades.
Entrevista (telefnica): este tipo de entrevista possibilita ao investigador ter
a informao rapidamente. Tal como as entrevistas pessoais, este tipo de
entrevista possibilita ao investigador o contato pessoal e direto com o
questionado, desta forma, facilitam as respostas a perguntas que pedem opinies a
questes de follow-up e do ao entrevistador a oportunidade de se certificar que o
questionado respondeu exatamente aquilo que queria dizer. Contudo tambm tem
desvantagens. Muitas pessoas no gostam que lhes telefonem para casa, outras
no tm telefone que conste nas listas telefnicas. Este tipo de entrevistas no
pode ser muito extenso.
Segundo Goode & Hatt [1], os preparativos de construo de um
questionrio vlido pressupem um conjunto de procedimentos metodolgicos e
tcnicos. Esses procedimentos vo desde a formulao do problema at
31
aplicao numa amostra reduzida (similar amostra - estudo no que se refere

distribuio de caractersticas), ao pr-teste, que constituindo um estudo piloto,
faculta dados empricos suscetveis de melhoramento do questionrio:
Formulao de um problema colocado sob a forma de uma questo
inicial que constitui a base para a construo do questionrio;
A pergunta base deve ser:

Clara (precisa, concisa, unvoca);
Exeqvel (realista, que se revele adequada aos recursos
temporais, materiais, tcnicos e pessoais); pertinente (neutra e que vise

compreenso);
Explicao dos objetivos da pesquisa, depois de esboado o quadro
terico de referncia e clarificadas definies e conceitos;
Formulao de hipteses, fazendo interagir a teoria e a verificao
emprica, constituindo deste modo um importante guia do trabalho de pesquisa e

uma valiosa orientao da obteno de dados;
Segundo Selltiz & Cook [4], a elaborao de um questionrio que
proporcione rigor de informao passa pela identificao dos conjuntos a inquirir;
pela opo por uma ou outra, ou por vrias modalidades e tipos de perguntas,
dependendo dos objetivos da pesquisa e das caractersticas e disponibilidades dos
inquiridos e tendo presentes os processos de tabulao e tratamento de dados
disponveis. A elaborao das perguntas decorre naturalmente dos indicadores
selecionados; as respostas que o leque de perguntas proporciona so funo da
qualidade da sua formulao.
Tendo em vista uma tabulao facilitada, usual codificar as perguntas.
Entretanto, se suspeitar que a codificao poder ocasionar dificuldade de leitura,
prefervel prescindir desta operao.
Segundo Mattar [2], a validao interna, apreciao crtica efetuada por
especialistas ou colegas do investigador, como garantia de um inqurito por
questionrio mais bem sucedido e o pr-teste, so operaes efetuadas em nome
da clareza e adequao do questionrio populao alvo.
Segundo Mattar [2], os tipos de questes so extremamente importantes
num instrumento de coleta de dados na medida em que tem efeito no tipo e
32
qualidade da informao obtida. Os tipos de questes mais usados em

questionrios so as questes de resposta aberta (qualitativas) e de resposta
fechada (quantitativas). Para decidir qual o tipo de questo que melhor se adeqe
ao questionrio, importante ter em conta o modo como planejamos usar a
informao obtida, pois a forma como estruturamos as nossas questes determina
a unidade de medida pela qual as respostas sero classificadas. Por sua vez, a
unidade de medida adotada dita quais os procedimentos estatsticos podem ser
aplicados aos dados e o modo como a informao possa ser analisada e
disponibilizada. Alm disso, na escolha entre questes de resposta aberta e
questes de resposta fechada, devemos ter em conta o propsito para o qual
determinada informao usada, as caractersticas da populao em estudo e o
mtodo proposto para comunicar os resultados.
Segundo Mattar [2], ambos os tipos de questes tm as suas vantagens e
desvantagens em situaes diferentes. At certo ponto, estas dependem do modo
de administrao do questionrio e do fato de estarem a ser usados para obter
informao sobre fatos ou sobre opinies.
Questes de resposta aberta (qualitativas): este tipo de pergunta no
apresenta respostas alternativas, proporcionando ao respondente plena liberdade
de resposta. Os respondentes tm que elaborar as suas respostas utilizando as suas
prprias palavras. Devem possuir uma justificativa e um objetivo. Ex: Porque
escolheu a PUC como Universidade para ingressar no curso de Informtica?. So
normalmente utilizadas no comeo do questionrio. Existe concordncia em que
se deve partir de questes gerais para especficas. Uma pergunta aberta geral, do
tipo "Quando se fala em poltica, o que vem sua cabea?", proporciona um
insight na estrutura de referncia do respondente e pode ser muito til na
interpretao de respostas a perguntas posteriores. Outro importante uso na
obteno de informaes adicionais e esclarecimentos, com indagaes como:
"Por que?", "Por favor, explique.", "Por que pensa dessa forma?".
A tabela detalhada a seguir, obtida em [36], lista as principais vantagens e
desvantagens decorrentes da utilizao de questes referentes a respostas do tipo
aberta (qualitativas) em questionrios:
33
Vantagens
Desvantagens
Estimula o pensamento
livre,
Requer um grande esforo para
solicita sugestes, explora a memria codificar a informao para posterior

das
pessoas,
esclarece
clarifica
opinies,
posies, anlise dos dados, dada a quantidade e
atitudes
e variedade de informao cedida pelo
percepes;
Permite
inquirido;
que
inquirido
se
Geralmente
requer
mtodos
expresse sem limitaes, resultando da qualitativos para codificar e analisar as

uma grande variedade de informao e respostas, o que exige mais tempo e um
eliminando
virtualmente
os
vieses julgamento
associados ao investigador;
mais
subjetivo
que
codificao das questes de resposta

fechada;
Indispensvel
para
estudos
Geralmente surgem dificuldades em
exploratrios nos quais o principal interpretar e categorizar as respostas;

objetivo do investigador encontrar a
informao mais relevante acerca de um
tpico, nomeadamente na preparao
para o desenvolvimento de questes de
resposta fechada para um questionrio
definitivo.
Difcil
significativas
construo
para
de
anlise
variveis
estatstica,
podendo ocorrer distoro das respostas

durante o processo de codificao;
preciso bastante tempo para
responder a este tipo de questes;
Maior probabilidade de ocorrerem
vieses associados ao entrevistador, no
caso de questionrios administrados por
entrevista;
Normalmente difcil determinar
numa resposta onde h erros de omisso.
34
Questes de resposta fechada (quantitativas): este tipo de perguntas limita o

inquirido opo entre duas ou mais respostas apresentadas, das quais ele
escolher a que melhor descreve a sua opinio. Ex: "Concorda com o mtodo de
ensino da PUC?" Sim, No. O exemplo apresentado anteriormente um exemplo
de uma questo dicotmica (bipolar), a qual adequada para muitas perguntas que
se referem a questes de fato, bem como a problemas claros e a respeito dos quais
existem opinies bem cristalizadas.
Nos casos de mltipla escolha, os respondentes optaro por uma das
alternativas, ou por determinado nmero permitido de opes. Segundo Mattar
[2], ao elaborar perguntas de respostas mltiplas, o pesquisador se depara com
dois aspectos essenciais: o nmero de alternativas oferecidas e os vieses de
posio.
Segundo Selltiz & Cook [4], podemos apontar algumas consideraes
importantes relacionadas s questes de mltipla escolha. As alternativas devem
ser coletivamente exaustivas e mutuamente exclusivas, ou seja, devem cobrir
todas as respostas possveis e uma alternativa deve ser totalmente incompatvel
com todas as demais. A opo Outros. Quais? ______" de grande ajuda para
garantir a excluso entre as possveis respostas. Para que sejam mutuamente
exclusivas cada respondente dever identificar apenas uma opo que represente
corretamente sua resposta, ou seja, a escolha de uma alternativa deve excluir todas
as demais. Quanto aos vieses de posio, estes ocorrem em funo da tendncia de
se escolher, no caso de palavras, as que aparecem como primeiras opes de
resposta e, quando se tratar de nmeros, a escolha daquele que ocupa a posio
central. No intuito de contornar esses vieses, pode-se alternar a seqncia de
apresentao das opes de resposta, durante a coleta de dados, atravs de
diversas formas para o questionrio.
Outro tipo de questo fechada so as do tipo gradativas, onde o usurio
seleciona uma dentre as possveis respostas graduais apresentadas. Normalmente
o usurio expressa o seu grau de conhecimento ou opinio a cerca de um
determinado assunto. Ex: Indique o seu grau de aprendizado da linguagem UML,
com base no que foi utilizado nas aulas experimentais. Respostas: 1 No
aprendi; 2 Aprendi, mas tenho dvida; 3 Aprendi o bsico; 4 Aprendi, mas
no sei usar sozinho; 5 Aprendi e sei usar.
35
A tabela detalhada a seguir, extrada de [36], lista as principais vantagens e

desvantagens decorrentes da utilizao de questes referentes a respostas do tipo
fechadas (quantitativas) em questionrios:
Vantagens
Contribuem
para
Desvantagens
maior
Conduzem
os
inquiridos
numa
uniformidade e simplificam a anlise das determinada direo, no permitindo que

respostas;
eles expressem a sua e potencialmente

nica resposta;
So mais rpidas e mais fceis de

responder;
As respostas so mais fceis de
tabular;
Falha pela falta de variedade e

profundidade;
H uma maior probabilidade de
erros do investigador porque este pode
selecionar os padres de resposta que lhe
interessam;
A sua anlise mais rpida e mais

econmica;
O padro de resposta dado para uma

questo pode condicionar a resposta do
inquirido de tal modo que esta pode no
refletir verdadeiramente a opinio do
inquirido, mas sim o grau de concordncia
ou discordncia deste em relao
opinio do investigador;
A lista de respostas possveis ajuda

a clarificar o significado da questo;
A facilidade em responder a uma

lista pr - determinada de respostas pode
criar a tendncia de escolher uma ou mais
categorias sem refletir sobre o assunto;
Adequadas a tpicos acerca dos

quais se dispe de muita informao;
So de difcil elaborao, pois

necessrio incorporar todas as possveis
respostas a uma determinada pergunta;
Segundo Mattar [2], a ordem das questes importante na medida em que

afeta a qualidade da informao, o interesse e at a disposio dos respondentes
na participao do estudo. Relativamente a este assunto, h duas correntes de
36
opinio: a primeira defende que as questes devem ser colocadas ao acaso; a

segunda, por sua vez, considera que as questes devem seguir uma progresso
lgica baseada nos objetivos do estudo (tcnica do funil), opinio que partilhada
pela maioria dos autores. Contudo, a primeira concepo til em situaes em
que o investigador quer que os respondentes expressem os seus acordos ou
desacordos em relao a diferentes aspectos de um tema. Neste caso, uma
listagem lgica de declaraes ou questes pode condicionar o respondente a
opinies expressas pelo investigador atravs das suas declaraes.
No que diz respeito tcnica do funil (as questes seguem uma progresso
lgica baseada nos objetivos do estudo), esta tem claras vantagens na medida em
que conduz gradualmente o respondente para os temas do estudo, comeando
pelos temas mais simples e prosseguindo para os mais complexos, estimulando o
respondente a responder s questes colocadas. Neste caso, as perguntas delicadas
ou complexas no devem ser colocadas no incio; as perguntas gerais devem
preceder as especficas; as mais concretas devem preceder as mais abstratas;
questes acerca de comportamento devem ser colocadas antes de questes acerca
de atitudes; devem ser colocadas primeiro as de carter impessoal e s depois as
de carter pessoal. necessrio evitar o mais possvel o chamado efeito de
contgio, ou seja, a influncia da pergunta precedente sobre a seguinte. As
primeiras questes, de descontrao do respondente, so chamadas de quebragelo porque tm a funo de estabelecer contato, colocando-o vontade.
3.2.
Requisitos para a construo de questionrios de boa qualidade
Realizamos uma pesquisa nas reas de Cincias Sociais e Marketing [1-4, 78], com objetivo de colher as principais recomendaes de diversos autores a
respeito das boas prticas a serem consideradas na elaborao e formulao de
questionrios em geral.
Inicialmente, as recomendaes dos autores da bibliografia estudada foram
coletadas e armazenadas. Aps a coleta, as recomendaes foram cruzadas, com
objetivo de identificar algum conflito ou contradio entre elas. Os conflitos e
contradies encontrados foram eliminados, restando apenas a lista de
37
recomendaes sem conflito, ou seja, uma lista de recomendaes de boas prticas

para a elaborao de questionrios, onde cada elemento da lista uma
recomendao que pode ser considerada um consenso, visto pelo autor dessa
dissertao, entre os autores da bibliografia estudada.
O resultado dessa lista foi consolidado em uma listagem de requisitos para a
apoiar o processo de construo de questionrios de qualidade, que ser detalhada
a seguir. Essa lista de requisitos poder ser utilizada como referncia por pessoas
que desejam elaborar questionrios e ser utilizada como base para o processo de
construo de questionrios. A seguir, sero listados esses requisitos:
Deve ser definida a amostra, ou seja, o grupo populacional ao qual ser
aplicado o instrumento de obteno de dados (neste caso, o questionrio); a

amostra condiciona a tcnica ou tcnicas de coleta de dados utilizadas e as
caractersticas do prprio questionrio;
Existe concordncia em que se deve partir de questes gerais para
especficas;
As perguntas gerais devem preceder as especficas;
As perguntas mais concretas devem preceder as mais abstratas;
Questes acerca de comportamento devem ser colocadas antes de
questes acerca de atitudes;
Devem ser colocadas primeiro as questes de carter impessoal e s
depois as de carter pessoal;
necessrio evitar o mais possvel o chamado efeito de contgio, ou
seja, a influncia da pergunta precedente sobre a seguinte;
As primeiras questes, de descontrao do respondente, so chamadas
de quebra-gelo porque tm a funo de estabelecer contato, colocando-o

vontade;
O desenho visual de um questionrio deve ser atrativo e facilitar o
preenchimento das questes na seqncia correta;
Se o formato for muito complexo, os respondentes tendem a evitar
questes, fornecer dados incorretos ou mesmo recusar-se a responder ao

questionrio;
38
O nmero de questes introduzidas deve ser levado em conta: se for
em nmero excessivamente reduzido podem no abranger toda a problemtica que

se pretende inquirir; se pelo contrrio forem demasiado numerosas, no s se
arrisca a ser de anlise impraticvel no tempo disponvel para a investigao como
tm um efeito dissuasor sobre os inquiridos, aumentando a probabilidade de no
resposta;
Um questionrio deve parecer curto. Por exemplo, podemos reduzir o
nmero de pginas, o que implica por sua vez num maior nmero de questes por
pgina;
Um questionrio no deve ser demasiado longo, pois a concentrao
quer do investigador quer do respondente tende a diminuir medida que se

aproxima o final do questionrio bem como o interesse deste ltimo. Alm disso,
a anlise torna-se bastante demorada;
O questionrio tambm no deve ser demasiado curto, pois no
permite obter a informao necessria e os respondentes podem sentir que no

tiveram oportunidade de exprimir as suas opinies;
No se deve separar a mesma questo por pginas diferentes;
As questes devem ser numeradas de forma conveniente;
Deve ser deixado espao suficiente entre os itens;
Quando so includas questes de resposta aberta, o espao de resposta
deve ser suficientemente grande;
Determinadas partes mais importantes devem ser sublinhadas ou
destacadas;
As instrues de preenchimento devem ser claramente distinguidas das
questes e respostas alternativas;
A identificao do respondente deve ser feita preferencialmente no
incio do questionrio. Colhe-se apenas o nome do respondente, deixando-se seus

dados gerais para o final do questionrio, com vistas a se evitarem vieses;
Solicitao de cooperao: importante motivar o respondente atravs
de uma prvia exposio sobre a entidade que est promovendo a pesquisa e sobre
as vantagens que essa pesquisa poder trazer para a sociedade e em particular para
o respondente, se for o caso;
39
Instrues: as instrues apresentadas devero ser claras e objetivas ao
nvel de entendimento do respondente e no somente ao nvel de entendimento do

pesquisador;
Informaes de classificao do respondente: os dados de classificao
do respondente, se necessrios, normalmente devero estar no final do

questionrio. Podem ocorrer distores se estiverem no incio porque o
entrevistado poder distorcer as respostas, caso seus dados pessoais j estejam
revelados no incio da pesquisa;
necessrio tambm que o pesquisador faa algumas reflexes, do
tipo: A pergunta realmente necessria?, Qual a sua utilidade?. Estas

perguntas por sua vez, desdobram-se nas seguintes questes:
O assunto exige uma pergunta separada, ou pode ser includo em outras
perguntas?
Existem outras perguntas que j incluem adequadamente este ponto?
A pergunta desnecessariamente minuciosa e especfica?
Vrias perguntas so necessrias sobre o assunto desta pergunta ou uma o
suficiente?
Deve-se evitar o uso de abreviao. No se devem tratar dois assuntos complexos
em uma mesma pergunta;
Todos os aspectos importantes sobre este tpico sero obtidos da forma como foi
elaborada a pergunta?
As pessoas tm a informao necessria para responder a pergunta?
Que objees algum poderia ter para responder esta pergunta?
O tema abordado muito ntimo, perturbador ou expe socialmente as pessoas, de
forma a causar resistncias e respostas falsas?
O tema embaraoso para o respondente colocar em perigo seu prestgio caso seja
contrrio a idias socialmente aceitas?
A pergunta devidamente neutra, a fim de no influenciar nas respostas?
Deve ser proporcionada ao respondente uma situao de liberdade, em
que a pessoa seja estimulada a apresentar francamente suas opinies.
40
3.3.
Erros comumente cometidos num processo de aplicao de
questionrios
Segundo Selltiz & Cook [4], em um processo de pesquisa podem ocorrer
dois tipos de erros, os erros amostrais e os erros no-amostrais. O primeiro est
ligado a falhas nos processos de escolha da amostra e da determinao do seu
tamanho. Quanto aos erros no-amostrais, inmeras so as fontes de sua
ocorrncia; entre elas, questionrios de dados mal elaborados, com questes
tendenciosas ou dbias e a escolha ou o uso incorreto de escalas de medio. A
mensurao sempre ocorre em situaes complexas, onde diversos fatores
influenciam as caractersticas medidas e o processo de mensurao, podendo gerar
erros no-amostrais.
De acordo com Selltiz & Cook [4], a variao entre resultados individuais,
num instrumento de medida aplicado a um grupo de pessoas, decorre de certo
nmero de fatores contribuintes. Parte da variao pode ser entendida como
resultante de diferenas reais, entre os indivduos, quanto caracterstica que est
sendo medida; parte dela representa erros na mensurao. O problema bsico na
avaliao de resultados de qualquer mensurao o de definir o que deve ser
considerado como diferenas reais na caracterstica medida e o que deve ser
considerado como variaes devidas a erro de mensurao. Selltiz & Cook [4]
aponta algumas das possveis fontes de diferenas nos resultados, num grupo de
indivduos:
Diferenas verdadeiras na caracterstica em anlise: idealmente, todas
as diferenas encontradas em um processo de mensurao deveriam referir-se,

exclusivamente, s diferenas reais quanto ao que se pretende medir;
Diferenas reais em outras caractersticas relativamente estveis do
indivduo, influindo nos resultados. Resultados obtidos num grupo refletem no

apenas diferenas na caracterstica que est sendo medida, mas tambm diferenas
em variveis tais como grau de formao, inteligncia, personalidade, as quais
vem contaminar os resultados de um questionrio de atitude ou as avaliaes de
um observador;
Diferenas devidas a fatores pessoais passageiros, tais como
indisposio momentnea, estado de fadiga, sade e distrao;
41
Diferenas devidas a fatores de situao: muitas vezes, as variaes na
situao em que ocorre a mensurao desempenham um grande papel nas

diferenas de resultados num grupo de indivduos. Assim, por exemplo, um
levantamento com uma dona de casa pode ser fortemente influenciado pela
presena de outras pessoas da famlia (marido e filhos);
Diferenas devidas s variaes na aplicao: mtodos inadequados ou
no-uniformes de aplicao de um questionrio podem contribuir para variaes

nos resultados. Apenas para exemplificar, os Engenheiros de Software podem
inverter a ordem das perguntas, omitir questes e responder perguntas no
respondidas baseando-se em julgamentos prprios a respeito do entrevistado;
Diferenas devidas amostragem de itens: por melhor que seja um
questionrio, provavelmente no ser capaz de abarcar todos os itens do universo

de itens significativos para a caracterstica que est sendo medida.
Falta de clareza do questionrio: as diferenas nas respostas podem
significar diferenas de interpretao do questionrio, e no diferenas reais nas

caractersticas que esto sendo medidas;
Questionrios mal elaborados, com questes tendenciosas, dbias, ou
seqencialmente mal posicionadas.

Percebe-se, portanto, a importncia de um questionrio bem construdo e
bem aplicado, garantindo ento uma significativa reduo no nvel do erro noamostral.
3.4.
Avaliao do questionrio
importante a realizao de um processo de anlise, porque provvel que
no se consiga prever todos os problemas ou dvidas que podem surgir durante a
aplicao do questionrio. Sem o processo de anlise, pode haver grande perda de
tempo, dinheiro e credibilidade caso se constate algum problema grave com o
questionrio j na fase de aplicao. Nesse caso o questionrio ter que ser refeito
e estaro perdidas todas as informaes j colhidas.
Goode & Hatt [1], afirmam que nenhuma quantidade de pensamento, no
importa quo lgica seja a mente e brilhante a compreenso, pode substituir uma
42
cuidadosa verificao emprica. Da a importncia em se saber como o

questionrio se comporta numa situao real atravs processo de anlise.
Segundo Mattar [2], os processos de anlise podem ser realizados inclusive
nos primeiros estgios, quando o instrumento ainda est em desenvolvimento,
quando o prprio Engenheiro de Software pode realiz-lo, atravs de entrevista
pessoal. O processo de anlise , segundo Goode e Hatt [1], um ensaio geral. Cada
parte do procedimento deve ser projetada e implementada exatamente como o ser
na hora efetiva da coleta de dados. As instrues para a coleta de dados devem
estar na formulao final e serem obedecidas rigorosamente, para se verificar se
so ou no adequadas. O questionrio deve ser apresentado na forma final e a
amostra (embora menor) deve ser obtida segundo o mesmo plano que gerar a
amostra final. Os resultados do processo de anlise so ento tabulados para que
se conheam as limitaes do instrumento. Isto incluir a proporo de respostas
do tipo "no sei", de questes difceis, ambguas e mal formuladas, a proporo de
pessoas que recusam a entrevista, bem como os comentrios feitos pelos
respondentes sobre determinadas questes.
Goode e Hatt [1] destacam alguns sinais que indicam algo errado com o
questionrio e que devero ser objeto de alteraes por parte do pesquisador aps
o processo de anlise:
Ausncia de ordem nas respostas: freqentemente, a causa uma
questo (ou questes) que no se refere mesma experincia em cada

respondente. Isto pode ser provocado pelo uso de palavras difceis, ou por
questes que buscam obter muitos dados de uma s vez. Respostas totalmente
desordenadas so um sinal de alerta;
Respostas "tudo-nada": questes a que todos respondem da mesma
maneira podem revelar uma resposta estereotipada ou clich;
Grande proporo de respostas do tipo "no sei" ou "no compreendo":
estes casos indicam questes formuladas inadequadamente, ou um mau plano de

amostragem;
Variao substancial de respostas quando se muda a ordem das
questes;
Alta proporo de respostas recusadas: aconselha-se rever com cuidado
cada questo cujas recusas ultrapassem cinco por cento.
43
Com relao ao processo de anlise, recomenda-se:
Seus respondentes devem pertencer populao alvo da pesquisa e ter
tempo suficiente para responder todas as questes;
Os Engenheiros de Software devem ser experientes;
Com relao aos elementos funcionais do questionrio, deve-se verificar no

processo de anlise:
A clareza e a preciso dos termos utilizados;
A necessidade eventual de desmembramento das questes;
A forma das perguntas;
A ordem das perguntas;
A introduo;
importante tambm se fazer uma reflexo sobre o valor de cada
pergunta.
Os questionrios tambm podem conter estruturas ou dependncias lgicas,
ou seja, a seqncia de perguntas pode depender das respostas enviadas pelos
respondentes. Essa abordagem funciona como uma espcie de dilogo entre o
questionrio e o Engenheiro de Software, na qual o dilogo vai se adaptando a
este ltimo.
Caso o processo de anlise revele necessidade de muitas alteraes, o
questionrio revisado dever ser ento novamente testado. O processo ser
repetido tantas vezes quantas forem necessrias, at que o instrumento se encontre
maduro, pronto para ser aplicado. De acordo com Mattar [2], para instrumentos
que foram cuidadosamente desenvolvidos, dois ou trs ciclos de processos de
anlise costumam ser suficiente.
44
4
Um processo para a elaborao de perguntas de
questionrios para a elicitao de requisitos de software
Esse captulo tem por objetivo apresentar um mtodo que foi criado com
objetivo de prover ao Engenheiro de Software uma forma de ajud-lo no processo
de elaborao de perguntas de questionrios. O mtodo proposto utiliza como
base a tcnica GQM, descrita anteriormente.
4.1.
Definio do processo
Com a finalidade de criar um mtodo que pudesse prover ao Engenheiro
de Software uma forma de ajud-lo no processo de elaborao de perguntas de
questionrios, foram realizadas diversas pesquisas com objetivo de identificar
quais os principais tipos de requisitos existentes, categoriz-los (funcionais e no
funcionais) e definir as principais atividades envolvidas no processo de
levantamento dos requisitos de software em geral. Com base nesse estudo, foi
elaborado um modelo conceitual, sujeito a alteraes, para a elicitao de
requisitos de projetos ou sistemas de software, modelo esse criado atravs de
pesquisas, da utilizao do SRS (Software Requirements Specification) da IEEE
[24] e do modelo proposto na dissertao da Ana Paula Gilvaz [5]. O modelo
flexvel est ilustrado a seguir:
45
Famlia de
Produtos
Pode pertencer a
Atende a
Indstria
Pertencem a
Sistema
Possui
Objetivos
Funcionais
Traz
Utilizam
Possui
Trazem
Contribuem
Possuem
Benefcios
Objetivos no
Funcionais
Definem
So relevantes em
relao a
Definem
Grupos de
Usurios
Possuem
Pertencem a
reas
Funcionais
Definem
Figura 5 Modelo conceitual
A idia que esse modelo sirva de base para a elaborao das perguntas de
questionrios, que sero utilizados para priorizar e elicitar alguns dos requisitos de
software de um sistema ou produto a ser construdo. O modelo no cobre todos os
casos possveis de requisitos, podendo ser utilizado ou no para ajudar no
processo de elaborao de perguntas, dependendo do domnio em questo, como
veremos atravs dos dois exemplos que sero apresentados adiante, os quais
utilizaro o mtodo proposto.
Posteriormente a tcnica GQM (Goal Question Metric) foi estudada, com
objetivo de utiliz-la na construo de um processo de elaborao de perguntas de
questionrios. O seguinte processo foi ento definido:
Conhecimen
to tcnico
Nvel de
Instruo
46
Modelo
UDI
Instanciar modelo
Relaes
Template da
tcnica GQM
Definir objetivos
Objetivos do GQM
Definir questes
Questes
necessrias
Definir mtricas
Mtricas
Especificar
perguntas
Ferramenta
Figura 6 Processo definido
1. As perguntas que instanciam o modelo sero transformadas em objetivos

do GQM, caso o modelo seja utilizado. Caso contrrio, devem ser definidos
objetivos a serem alcanados com o questionrio que ser construdo. Para a
definio dos objetivos, ser utilizado o seguinte template da tcnica GQM para a
criao de objetivos, obtido de [14]:
Finalidade: analisar alguns objetos (processos, produtos, outros modelos) com a
finalidade de melhorar, avaliar, motivar, caracterizar, predizer.
Perspectiva: com foco em custo, corretude, remoo de defeitos, mudanas,
segurana, do ponto de vista do usurio, cliente, gerente, desenvolvedor, corporao.
Ambiente: no contexto de fatores de: problemas, recursos e processos.
Abaixo, segue um exemplo de obteno de uma relao do modelo. A

relao abaixo obtida atravs da pergunta: Que objetivos no funcionais o
sistema dever possuir?.
Perguntas do
questionrio
47
Figura 7 Obteno de uma relao do modelo
Aplicando o template de criao de objetivos anteriormente detalhado, a

pergunta que instanciou a relao anteriormente transformada no seguinte
objetivo:
Analisar o sistema a ser construdo com a finalidade de identificar os
requisitos no funcionais que o sistema dever possuir, com a perspectiva de
documentao dos requisitos no funcionais do sistema a ser construdo, do ponto
de vista do usurio, no contexto da companhia onde o sistema ser implantado.
2. Sero listadas, para cada um dos objetivos obtidos do passo 1, as
questes necessrias para que o objetivo seja atingido;
3. Sero listadas, para cada questo, as mtricas que sero utilizadas de
forma que as questes dos objetivos possam ser respondidas. Essas mtricas
definidas sero as perguntas a serem aplicadas no questionrio.
A seguir, com o objetivo de exemplificar a utilizao do mtodo proposto,
aplicaremos o mtodo na criao de perguntas de questionrios para dois
contextos diferentes:
1.
Avaliao de aprendizagem atravs de questionrios, obtido em
[37]: construir uma estratgia de avaliao de um curso de Engenharia de

Software, com o objetivo de verificar se um curso, que possui uma estratgia
prpria, teve o efeito esperado. O objetivo tentar avaliar se os alunos da matria
48
Princpios de Engenharia de Software (PES) conseguiram assimilar aquilo que o

curso procura enfatizar;
2.
Elicitao de requisitos para a especificao de um sistema multi-
agente (Expert Committee - EC) aberto para suporte ao gerenciamento de

submisses e revises de artigos submetidos a uma conferncia ou workshop [45].
O sistema oferece suporte a diferentes atividades: o envio de trabalhos, a
atribuio de um artigo a um revisor, a seleo de revisores, a notificao da
aceitao e recusa de artigos, entre outros.
Para o primeiro problema, como o modelo conceitual foi criado com
objetivo de elicitar requisitos de software, no faz sentido utiliz-lo para a criao
dos objetivos das questes do questionrio, pois nesse caso estamos tentando
avaliar um curso de Engenharia de Software ao invs de elicitar requisitos de um
software a ser construdo. Sendo assim, ao invs de utilizar o modelo conceitual
para a definio dos objetivos, inicialmente definimos os objetivos das questes
sem a utilizao do modelo conceitual, onde os objetivos no so definidos
atravs da instanciao dos nodos do modelo.
Objetivos definidos para as questes que utilizam o conceito de unificao
de variveis, isto , cada pergunta composta de uma parte fixa mais uma parte
varivel:
1.
Saber o que o sujeito entende que aprendeu sobre [tpico] em aula
expositiva [grau] e em aula experimental [grau];

2.
Saber a razo, caso o sujeito no tenha aplicado na aula
experimental o que aprendeu sobre [tpico] em aula expositiva.

Tpicos a serem abrangidos:
1.
Linguagens de modelagem (UML);
2.
Cenrios;
Aplicando o tpico 1 (UML) ao objetivo 1, teremos o seguinte objetivo:

Saber o que o sujeito entende que aprendeu sobre a linguagem de modelagem
UML em aula expositiva [grau] e em aula experimental [grau]. Agora esse
objetivo deve ser transformado em um objetivo do GQM, atravs da utilizao do
template para a criao de objetivos:
49
Analisar as opinies dos alunos matriculados na matria PES no perodo de

2004.1, com a finalidade de avaliar o grau de aprendizado da linguagem de
modelagem UML em aulas expositivas e em aulas experimentais, com a
perspectiva de documentao das opinies dos alunos, do ponto de vista dos
alunos da matria, no contexto da Universidade (PUC-Rio) onde a matria foi
aplicada.
Seguindo o mtodo de criao de perguntas de questionrios definido
anteriormente, sero aplicados os prximos passos:
1.
Sero listadas, para cada objetivo, as questes necessrias para que o
objetivo seja atingido; fica a cargo do Engenheiro de Software definir essas

questes, assim como as mtricas para que as questes possam ser respondidas;
2.
Sero listadas, para cada questo, as mtricas que sero utilizadas, para
que as questes dos objetivos possam ser respondidas. Essas mtricas definidas
sero as perguntas a serem aplicadas no questionrio;
Questes
1) Como voc avaliaria o seu
Mtricas (Perguntas)
Indique
grau de aprendizado da linguagem de aprendizado
da
seu
grau
linguagem
de
de
modelagem UML apresentada nas aulas modelagem UML, com base no que foi
expositivas da matria PES na PUC- apresentado nas aulas expositivas da
Rio, no perodo de 2004.1?
matria PES na PUC-Rio, no perodo

de 2004.1.
Respostas:
1 No aprendi; 2 Aprendi,
mas tenho dvida; 3 Aprendi o
bsico; 4 Aprendi, mas no sei usar
sozinho; 5 Aprendi e sei usar;
Indique
grau de aprendizado da linguagem de aprendizado
da
seu
grau
linguagem
de
de
modelagem UML utilizada nas aulas modelagem UML, com base no que foi
experimentais da matria PES na PUC- utilizado nas aulas experimentais da
matria PES na PUC-Rio, no perodo

de 2004.1.
50
Respostas:
Aplicando o tpico 2 (Cenrios) ao objetivo 1, teremos o seguinte objetivo:
Saber o que o sujeito entende que aprendeu sobre a tcnica de Cenrios em aula
expositiva [grau] e em aula experimental [grau]. Agora esse objetivo deve ser
transformado em um objetivo do GQM, atravs da utilizao do template para a
criao de objetivos, anteriormente detalhado:
2004.1, com a finalidade de avaliar o grau de aprendizado da tcnica de Cenrios
em aulas expositivas e em aulas experimentais, com a perspectiva de
documentao das opinies dos alunos, do ponto de vista dos alunos da matria,
no contexto da Universidade (PUC-Rio) onde a matria foi aplicada.
1.
Sero listadas, para cada objetivo, as questes necessrias para que
o objetivo seja atingido;

2.
Sero listadas, para cada questo, as mtricas que sero utilizadas,
para que as questes dos objetivos possam ser respondidas. Essas mtricas
definidas sero as perguntas a serem aplicadas no questionrio;
Questes
Mtricas (Perguntas)
Indique
seu
grau
de
grau de aprendizado da tcnica de aprendizado da tcnica de Cenrios,

Cenrios
apresentada
nas
aulas com base no que foi apresentado nas
expositivas da matria PES na PUC- aulas expositivas da matria PES na

PUC-Rio, no perodo de 2004.1.
51
Respostas:
Indique
seu
grau
de
grau de aprendizado da tcnica de aprendizado da tcnica de Cenrios,

Cenrios
utilizada
nas
aulas com base no que foi utilizado nas aulas
experimentais da matria PES na PUC- experimentais da matria PES na PUCRio, no perodo de 2004.1?
Rio, no perodo de 2004.1.

Respostas:
Aplicando o tpico 1 (UML) ao objetivo 2, teremos o seguinte objetivo:

Saber a razo, caso o sujeito no tenha aplicado na aula experimental o que
aprendeu sobre a linguagem UML em aula expositiva. Agora esse objetivo deve
ser transformado em um objetivo do GQM, atravs da utilizao do template para
a criao de objetivos, anteriormente detalhado:
2004.1, com a finalidade de identificar a razo, caso o aluno no tenha aplicado
nas aulas experimentais o que ele aprendeu sobre a linguagem UML nas aulas
expositivas, com a perspectiva de documentao das opinies dos alunos, do
ponto de vista dos alunos da matria, no contexto da Universidade (PUC-Rio)
onde a matria foi aplicada.
Seguindo o mtodo de criao de perguntas de questionrios definida, sero
aplicados os prximos passos, onde sero listadas as questes e as mtricas a
serem definidas:
52
Questes
Mtricas (Perguntas)
1) Qual seria a razo de no ter
Caso a sua avaliao em relao
sido
aplicado
nas
aulas ao grau de aplicao da linguagem UML
experimentais da linguagem UML o nas aulas experimentais da matria PES na

que
foi
apresentado
nas
aulas PUC-Rio, no perodo de 2004.1, de acordo
expositivas da matria PES na PUC- com o que foi apresentado nas aulas
expositivas tenha sido ruim (ser ruim se

voc tiver selecionado 1 ou 2 como
resposta s duas questes anteriores),
identifique a razo disso no seu ponto de
vista:
Respostas:
1 No foi aplicada porque a infraestrutura no permitia; 2 No foi
aplicada porque o grupo no estava de
acordo; 3 No foi aplicada porque seria
necessrio muito esforo; 4 No foi
aplicada porque eu no sabia utilizar a
ferramenta apresentada; 5 Outros:
_______________________________;
Aplicando o tpico 2 (Cenrios) ao objetivo 2, teremos o seguinte objetivo:

Saber a razo, caso o sujeito no tenha aplicado na aula experimental o que
aprendeu sobre a tcnica de Cenrios em aula expositiva. Agora esse objetivo
deve ser transformado em um objetivo do GQM, atravs da utilizao do template
para a criao de objetivos, anteriormente detalhado:
2004.1, com a finalidade de identificar a razo, caso o aluno no tenha aplicado
nas aulas experimentais o que ele aprendeu sobre a tcnica de Cenrios nas aulas
expositivas, com a perspectiva de documentao das opinies dos alunos, do
ponto de vista dos alunos da matria, no contexto da Universidade (PUC-Rio)
onde a matria foi aplicada.
53
Seguindo o mtodo de criao de perguntas de questionrios definida, sero

aplicados os prximos passos, onde sero listadas as questes e as mtricas a
serem definidas:
sido
Questes
Mtricas (Perguntas)
1) Qual seria a razo de no ter
Caso a sua avaliao em relao
aplicado
nas
aulas ao grau de aplicao da tcnica de
experimentais da tcnica de Cenrios Cenrios nas aulas experimentais da

o que foi apresentado nas aulas matria PES na PUC-Rio, no perodo de
expositivas da matria PES na PUC- 2004.1, de acordo com o que foi
apresentado nas aulas expositivas tenha

sido ruim (ser ruim se voc tiver
selecionado 1 ou 2 como resposta s duas
questes anteriores), identifique a razo
disso no seu ponto de vista:
Respostas:
1 No foi aplicada porque a infraestrutura no permitia; 2 No foi
aplicada porque o grupo no estava de
acordo; 3 No foi aplicada porque seria
necessrio muito esforo; 4 No foi
aplicada porque eu no sabia utilizar a
ferramenta apresentada; 5 Outros:
_______________________________;
Para o segundo problema, o modelo conceitual que foi criado com objetivo
de elicitar requisitos de software foi parcialmente utilizado para a criao dos
objetivos das questes do questionrio, pois nesse caso estamos tentando elicitar
requisitos de um software a ser construdo, tomando como base um modelo
previamente definido para atingir essa finalidade. Os objetivos foram definidos
parcialmente atravs da instanciao dos nodos do modelo. Alm da instanciao
54
dos nodos do modelo, foram definidos outros objetivos adicionais, que no

estavam contemplados no modelo. Objetivos definidos para as questes:
Levantados atravs da utilizao do modelo (nesse caso, as questes sero
reutilizadas da base de conhecimento):
1.
Que objetivos no funcionais o sistema EC dever possuir?
Levantados sem a utilizao do modelo:

2. Saber o grau de necessidade do sistema oferecer um cadastro de
usurios, onde fosse possvel associ-los a congressos ou workshops.
3. Saber qual o grau de importncia do sistema oferecer uma
funcionalidade onde fosse possvel cadastrar artigos de diferentes
maneiras (ttulo, palavra-chave e autores).
4. Saber qual o grau de necessidade do sistema oferecer a possibilidade
de realizao de upload de artigos.
5. Saber o grau de necessidade do sistema notificar automaticamente o
revisor, caso existam artigos para serem revisados.
O modelo ser reutilizado para a definio do objetivo 1. Inicialmente,
obtemos a relao do modelo que diz respeito ao objetivo 1, conforme detalhado
na figura 7. Essa relao definida atravs da pergunta: Que objetivos no
funcionais o sistema dever possuir?.
O prximo passo transformar esse objetivo obtido num objetivo do GQM
de acordo com o sistema que ser desenvolvido (Expert Committee), atravs da
utilizao do template para a criao de objetivos, anteriormente detalhado:
Analisar o sistema Expert Committee a ser construdo com a finalidade de
identificar os principais requisitos no funcionais que o sistema dever possuir,
com a perspectiva de documentao dos requisitos no funcionais do sistema, do
ponto de vista do usurio, no contexto da companhia onde o sistema ser
implantado.
Seguindo o mtodo de criao de perguntas de questionrios definido no
incio dessa seo, sero aplicados os prximos passos, onde sero listadas as
questes e as mtricas a serem definidas. Fica a cargo do Engenheiro de Software
definir:
55
As questes necessrias para que o objetivo seja atingido, de acordo com o

universo de informaes do sistema que ser desenvolvido;
As mtricas que sero utilizadas, para que as questes dos objetivos
possam ser respondidas.
Como o modelo est sendo reutilizado para o objetivo 1, podemos obter as
perguntas do questionrio que atingem esse objetivo diretamente da base de
conhecimento. As perguntas so na realidade as mtricas que foram utilizadas
para que as questes pudessem ser respondidas, mtricas essas definidas pelo
Engenheiro de Software.
Os requisitos no funcionais que foram considerados importantes pelo
Engenheiro de Software, sendo ento levados em considerao na criao das
mtricas foram os seguintes: portabilidade, reusabilidade, segurana e
extensibilidade. As mtricas obtidas atravs dessa lista de requisitos no
funcionais definida foram posteriormente cadastradas na base de conhecimento do
modelo, podendo ser alteradas e adaptadas de acordo com a necessidade.
Detalhamos abaixo a questo que foi definida para atingir o objetivo e as
mtricas criadas para responder a questo.
Questes
Mtricas (Perguntas)
1) Quais os principais requisitos
Indique o grau de relevncia
no funcionais que so importantes em
relao
portabilidade
para o sistema Expert Committee a ser (possibilidade de o sistema executar em

construdo?
diversas plataformas) do sistema.

Respostas:
1 Sem relevncia; 2 Pouco
relevante; 3 Razoavelmente relevante;
4 Relevante; 5 Muito relevante;
Indique o grau de necessidade
do
ser
facilmente
reutilizvel
(facilidade de reutilizao do sistema).
56
Respostas:
1 Sem necessidade; 2 Pouco
necessrio;
Razoavelmente
necessrio; 4 Necessrio; 5 Muito

necessrio;
do sistema autenticar os usurios que
queiram utiliz-lo.
Respostas:
necessrio;
Razoavelmente

necessrio;
Indique o grau de relevncia
em
relao
extensibilidade
(possibilidade de as funcionalidades do
sistema serem facilmente evoludas) do
sistema.
Respostas:
1 Sem relevncia; 2 Pouco
relevante; 3 Razoavelmente relevante;
4 Relevante; 5 Muito relevante;
J os demais objetivos no reutilizaram perguntas do modelo proposto.
Sendo assim, de acordo com o processo detalhado no incio dessa seo, para
obter as perguntas do questionrio, o Engenheiro de Software deve:
Transformar o objetivo definido num objetivo do GQM, aplicando o
template para a criao de objetivos, anteriormente detalhado;
Definir questes para que o objetivo seja atingido, de acordo com o
universo de informaes do sistema que ser desenvolvido;
Definir mtricas que sero utilizadas, para que as questes dos objetivos
possam ser respondidas. Essas mtricas definidas pelo Engenheiro de Software
sero as perguntas do questionrio.
57
Esses passos sero detalhados abaixo para a criao de mtricas referentes

ao objetivo 2.
Transformando o objetivo 2 em um objetivo do GQM, atravs da utilizao
do template para a criao de objetivos, anteriormente detalhado:
identificar o grau de necessidade do sistema oferecer um cadastro de usurios,
onde fosse possvel associ-los a congressos ou workshops, com a perspectiva de
documentao dos requisitos funcionais do sistema, do ponto de vista do usurio,
no contexto da companhia onde o sistema ser implantado.
1.

2.
Questes
Mtricas (Perguntas)
1) Qual a necessidade do sistema
EC oferecer um cadastro de usurios, do sistema EC oferecer um cadastro de

onde fosse possvel associ-los a usurios, onde fosse possvel associcongressos ou workshops?
los a congressos ou workshops.

Respostas:
necessrio;
Razoavelmente

necessrio;
identificar o grau de importncia do sistema oferecer uma funcionalidade onde
fosse possvel cadastrar artigos de diferentes maneiras (ttulo, palavra-chave e
autores), com a perspectiva de documentao dos requisitos funcionais do
58
sistema, do ponto de vista do usurio, no contexto da companhia onde o sistema

ser implantado.
1.

2.
Questes
Mtricas (Perguntas)
1) Qual o grau de importncia do
Indique o grau de importncia
sistema
EC
oferecer
uma do
sistema
EC
oferecer
uma
funcionalidade onde fosse possvel funcionalidade onde fosse possvel

cadastrar artigos de diferentes maneiras cadastrar artigos de diferentes maneiras
(ttulo, palavra-chave e autores)?
(ttulo, palavra-chave e autores).

Respostas:
1 Sem importncia; 2 Pouco
importante;
Razoavelmente
importante; 4 Importante; 5 Muito

importante;
identificar o grau de necessidade do sistema oferecer a possibilidade de realizao
de upload de artigos, com a perspectiva de documentao dos requisitos
funcionais do sistema, do ponto de vista do usurio, no contexto da companhia
onde o sistema ser implantado.
1.
59
2.
Questes
Mtricas (Perguntas)
1) Qual o grau de necessidade do
sistema EC oferecer a possibilidade de do sistema EC oferecer a possibilidade

realizao de upload de artigos?
de realizao de upload de artigos.

Respostas:
1 Sem importncia; 2 Pouco
importante;
Razoavelmente
importante; 4 Importante; 5 Muito

importante;
identificar a necessidade do sistema notificar automaticamente o revisor, caso
existam artigos para serem revisados, com a perspectiva de documentao dos
requisitos funcionais do sistema, do ponto de vista do usurio, no contexto da
companhia onde o sistema ser implantado.
1.

2.
60
Questes
Mtricas (Perguntas)
1) Qual o grau de necessidade do
sistema EC notificar automaticamente o do
sistema
revisor, caso existam artigos para serem automaticamente

revisados?
EC
o
notificar
revisor,
caso
existam artigos para serem revisados.

Respostas:
necessrio;
Razoavelmente

necessrio;
61
5
Experimento prtico
Nesse captulo ser apresentada uma ferramenta web, que foi desenvolvida
com objetivo de criar questionrios para coleta e priorizao de requisitos de
software. Ela tambm apia o Engenheiro de Software no processo de criao das
perguntas de questionrios e avalia os resultados obtidos, atravs das respostas
enviadas pelos respondentes.
5.1.
Caractersticas gerais da ferramenta
Foi desenvolvida uma ferramenta que consiste em um gerador de
questionrios, cujas perguntas a serem apresentadas so as perguntas geradas
atravs da utilizao do processo aqui proposto detalhado anteriormente. O
processo de definio e especificao da ferramenta foi realizado atravs da
utilizao das tcnicas de cenrio e lxico, onde foram definidos e detalhados os
cenrios que deveriam ser contemplados pelo sistema.
Depois ento, tomando como base os cenrios que foram gerados no
processo de definio e especificao da ferramenta, foi elaborado um prottipo
do sistema. No processo de escolha da plataforma de desenvolvimento, foi
considerado que deveria ser utilizado somente software livre. Sendo assim, a
linguagem de programao utilizada para o desenvolvimento da ferramenta foi a
linguagem Java (jdk verso 1.4 da Sun MicroSystems), juntamente com o banco
de dados MySQL (verso 4.0.13) e o servidor Tomcat (verso 5.0). Atravs da
utilizao da linguagem de modelagem UML, foram criados os diagramas de
classe e seqncia do sistema, gerando tambm os cdigos das classes do sistema
(somente a estrutura, mtodos e atributos das classes).
62
Questionario
projeto : String
administrador : Administrador
descricao : String
assuntoEmail : String
criado por
dataLimite : Date
categorias : Array List
perguntas : Array List
respondentes : Array List
Categoria
descricao : String
possui
consultarCategorias()
cadastrarCategQuest()
1..*
pertence a
criado por
1
v erif icarSeRespondenteEnv iouQuest()

consultarQuestionariosEmAndamento()
consultarQuestionariosPorDescricao()
consultarInf ormacoesDoQuestionario()
v erif icarSeQuestionarioJaExiste()
criarQuestionario()
cadastrarQuestionario()
Administrador
nome : String
f uncao : String
senha : String
login : String
email : String
ef etuarLogin()
cadastrarAdministrador()
criarQuestionario()
v erif icarSeLoginJaCadastrado()
setarAtributosAdm()
1
1
possui
1..*
QuestionarioFacade
Pergunta
resposta : Resposta
projeto : String
PerguntaGeral
categoria : Categoria
tipoPergunta : TipoPergunta
titulo : String
id : int
criarQuestionario()
env iaEmail()
possui
cadastrarPerguntasRespostas()
retornarPerguntasDaCategoria()
cadastrarPerguntas()
retornarPerguntasDoProjetoResp()
getPE_resposta()
retornarPerguntasDoProjeto()
obterRelev anciaPergunta()
1
possui
possui
1
1..*
1..*
T ipoPergunta
Resposta
descricao : String
id : int
retornarRespostasDaPergunta()
cadastrarRespostasParaRespondentes()
v erif icarSeUsuarioJaRespondeuQuestionario()
remov erTodasRespostas()
getRG_tipoResposta()
adicionarRespostaRespondente()
inserirRespostasDoUsuario()
possui
T ipoResposta
id : int
descricao ; String
Respondente
emailRespondente : String
resposta : String
observ acao : String
email : String
respostas : Array List
responde
1..*
responderQuestionario()
cadastrarRespondentes()
cadastrarQuestResp()
setRD_tipoRespondente()
obterNumeroRespondentesDoProjeto()
obterNumRespQuestProj()
RespostaGeral
id : int
titulo : String
Figura 8 Diagrama de classes
Foi construdo tambm o Modelo de Entidades e Relacionamentos, que

serviu de base para a construo do banco de dados do sistema (vide figura 8). O
script de criao dos objetos do banco pde ento ser criado e validado.
63
id
(1,n)
Categoria
projeto
(1,n)
Pertence
Questionario
(1,n)
(1,n)
Possui
login
(0,n)
Cadastra
Administrador
(1,n)
(1,n)
Possui
(1,1)
Responde
Possui
(1,n)
(1,1)
(1,1)
id
Pergunta_Geral
Pergunta
(1,1)
Possui
(1,n)
(1,n)
Respondente
(1,n)
id
id
email
(1,n)
Envia
(1,n)
Tipo_Pergunta
Possui
Possui
(1,1)
(1,1)
(1,1)
Resposta_Geral
id
Resposta
(1,1)
Possui
(1,n)
Tipo_Resposta
id
Figura 9 Modelo de Entidade e Relacionamentos
Atendendo o mtodo de gerao de perguntas para a coleta e priorizao de

requisitos de software aqui proposta, a ferramenta possui um modelo de dados
com tabelas que implementam uma estrutura de perguntas genricas, com objetivo
de mapear o modelo conceitual proposto nessa dissertao.
Dessa forma, possvel reutilizar perguntas (categorizadas como funcionais
e no funcionais, por exemplo, para identificar se a pergunta elicitar um requisito
id
64
funcional ou um requisito no funcional) em diversos questionrios, montando

dessa forma uma base de conhecimento. Ao criar um questionrio, alm de poder
reutilizar perguntas e respostas previamente definidas, o usurio tambm poder
criar as suas prprias perguntas e respostas, de acordo com a necessidade do
questionrio sendo criado.
Aps a criao de um questionrio, pelo administrador do sistema utilizando
o mdulo administrativo, o sistema envia-o automaticamente via e-mail para os
respondentes que iro participar do questionrio, respondentes esses cujos e-mails
foram informados pelo prprio administrador do sistema. Conforme os
respondentes vo respondendo os questionrios, o sistema avalia as respostas
obtidas. De acordo com a opinio dos respondentes, o conjunto de requisitos que
foram anteriormente caracterizados como necessrios implementao do sistema
avaliado podem ser priorizados, proporcionando tambm a deteco de possveis
conflitos. Esse sistema poder ser utilizado pelos participantes do projeto via web,
por exemplo, antes de uma reunio, servindo assim como uma base e auxlio ao
Engenheiro de Software envolvido, ou at mesmo em substituio a uma reunio
inicial de levantamento e priorizao de alguns dos requisitos de um sistema a ser
desenvolvido. O fato de ser um sistema web facilita a participao dos
respondentes que, independente de sua localizao fsica podero responder o
questionrio quando lhes for mais conveniente. Facilita tambm a avaliao das
respostas, de acordo com o envio das respostas dos participantes, sendo possvel
realizar uma contabilizao e avaliao on-line das respostas enviadas (esse
procedimento encontra-se detalhado na seo 5.3), o que no seria possvel caso
fosse, por exemplo, um questionrio em papel.
65
5.2.
Apresentao da ferramenta
A seguir, a ferramenta proposta ser apresentada. A ferramenta foi utilizada
na simulao do estudo de caso Elicitao de requisitos para a especificao de
um sistema multi-agente (Expert Committee - EC), onde as perguntas geradas
atravs da utilizao do mtodo proposto foram detalhadas no captulo 4 dessa
dissertao. Vale ressaltar que a ferramenta um prottipo, cujo objetivo
mostrar a possibilidade de automao de parte do processo proposto nessa
dissertao. As telas da ferramenta que esto expostas a seguir resultam de sua
utilizao por outro aluno de mestrado, tambm da rea de Engenharia de
Software.
As seguintes perguntas (mtricas obtidas atravs da aplicao do processo
proposto nessa dissertao) e respostas foram previamente inseridas na ferramenta
(cadastradas no modelo de dados exibido na figura 9 da seo 5.1), aps terem
sido geradas atravs da utilizao do mtodo de gerao de perguntas, processo
esse detalhado na seo 4.1. Foram definidos objetivo e justificativa para cada
questo criada, de forma a esclarecer a questo para os respondentes:
Indique o grau de relevncia em relao portabilidade do sistema. #
Objetivo: Identificar a necessidade do sistema ser portvel. # Justificativa: A
portabilidade permite que o sistema execute em plataformas diferentes. Respostas:
Sem relevncia; Pouco relevante; Razoavelmente relevante; Relevante; Muito
relevante.
Indique o grau de relevncia em relao extensibilidade do sistema. #
Objetivo: Identificar a necessidade do sistema ser extensvel. # Justificativa: A
extensibilidade permite que as funcionalidades sejam facilmente evoludas.
Respostas: Sem relevncia; Pouco relevante; Razoavelmente relevante; Relevante;
Muito relevante.
Indique o grau de necessidade do sistema ser facilmente reutilizvel. #
Objetivo: Identificar a necessidade do sistema ser reutilizvel. # Justificativa:
Quanto mais reutilizvel for o sistema mais fcil ser o seu reuso. Respostas: Sem
necessidade; Pouco necessrio; Razoavelmente necessrio; Necessrio; Muito
necessrio.
66
Informe o seu nvel de instruo de acordo com as opes abaixo: #

Objetivo: Identificar o nvel de instruo do participante. # Justificativa: A
identificao do nvel de instruo ajuda a traar o perfil do participante.
Respostas: Nvel mdio; Superior Incompleto; Superior completo.
Indique o seu nvel de conhecimento tcnico. # Objetivo: Identificar o
nvel de conhecimento tcnico do participante. # Justificativa: A identificao do
nvel de conhecimento tcnico ajuda a traar o perfil do participante. Respostas:
Nenhum conhecimento tcnico; Pouco conhecimento tcnico; Bom conhecimento
tcnico; Muito bom conhecimento tcnico.
As seguintes perguntas e respostas foram cadastradas atravs da utilizao
da ferramenta, aps terem sido geradas atravs da utilizao do mtodo de gerao
de perguntas, processo esse tambm detalhado no captulo 4:
Indique o grau de necessidade do sistema autenticar os usurios que
queiram utiliz-lo. # Objetivo: Identificar a necessidade de autenticao dos
usurios. # Justificativa: A autenticao garante que o usurio realmente quem
ele alega ser. Respostas: Sem necessidade; Pouco necessrio; Razoavelmente
necessrio; Necessrio; Muito necessrio.
Indique o grau de necessidade do sistema EC oferecer um cadastro de
usurios, onde seja possvel associ-los a congressos ou workshops. #Objetivo:
Identificar a necessidade de implementao. #Justificativa: Caso seja considerado
necessrio, ser implementado. Respostas: Sem necessidade; Pouco necessrio;
Razoavelmente necessrio; Necessrio; Muito necessrio.
Indique o grau de importncia do sistema EC oferecer uma funcionalidade
onde fosse possvel cadastrar artigos de diferentes maneiras. # Objetivo:
Identificar a necessidade de implementao. # Justificativa: Caso seja considerado
necessrio, ser implementado. Respostas: Sem importncia; Pouco importante;
Razoavelmente importante; Importante; Muito importante.
Indique o grau de necessidade do sistema EC oferecer a possibilidade de
realizao de upload de artigos. # Objetivo: Identificar a necessidade de
implementao. # Justificativa: Caso seja considerada necessria, a funcionalidade
dever ser implementada. Respostas: Sem necessidade; Pouco necessrio;
67
Indique o grau de necessidade do sistema EC notificar automaticamente o

revisor, caso existam artigos para serem revisados. # Objetivo: Identificar a
necessidade de implementao. # Justificativa: Caso seja considerada necessria,
ser
implementada.
Respostas:
Sem
necessidade;
Pouco
necessrio;

A ferramenta possui um mdulo administrativo, atravs do qual possvel,
dentre outras coisas, criar questionrios, acompanhar e avaliar on-line o
andamento das respostas que so enviadas pelos respondentes. Para acessar o
mdulo administrativo, necessrio possuir um login e senha de acesso ao
sistema.
Figura 10 Tela de login do mdulo administrativo do sistema
Aps efetuar o login com sucesso, o sistema exibe sua tela principal,
atravs da qual possvel o administrador do sistema utilizar suas
funcionalidades.
Figura 11 Tela inicial do mdulo administrativo do sistema
68
Opo Criar questionrio: essa funcionalidade permite que um novo

questionrio seja criado, com objetivo de realizar o levantamento de informaes
de um determinado projeto, de acordo com as necessidades do Engenheiro de
Software (no papel de administrador do sistema) em questo. Ao clicar nessa
opo o sistema exibir a seguinte tela:
Figura 12 Tela inicial de criao de questionrios
O usurio dever ento informar:

o
O nome do projeto: o administrador deve informar um nome de projeto
que ainda no tenha sido cadastrado no sistema, ou seja, que no tenha sido criado
ainda algum questionrio com esse nome de projeto informado. Esse o projeto
que se deseja elicitar requisitos de software, atravs da aplicao do questionrio
aos respondentes. No estudo de caso em questo, o nome do projeto cadastrado foi
Expert Committee.
o
Descrio do projeto: breve descrio do projeto para o qual o
questionrio est sendo criado. No estudo de caso em questo, a descrio

cadastrada foi Sistema multi-agente.
o
O administrador dever selecionar quais as categorias de requisitos ele
deseja elicitar ou verificar a relevncia para o projeto em questo. Se o

administrador selecionar uma dentre as opes Objetivos funcionais e/ou
Objetivos no funcionais, o sistema ir incluir no questionrio sendo criado
69
perguntas previamente cadastradas e categorizadas como sendo funcionais e/ou

no funcionais, de acordo com as perguntas do modelo conceitual que foram
criadas, atravs da utilizao do mtodo aqui proposto. Se o administrador
selecionar a opo Cadastrar novas perguntas, o sistema permite que sejam
criadas novas perguntas e suas respectivas opes de respostas (alm da
possibilidade
de
reutilizar
perguntas
previamente
cadastradas,
caso
administrador selecione pelo menos uma das duas opes anteriormente

detalhadas) para o questionrio. No estudo de caso realizado, foram selecionadas
as opes Objetivos no funcionais e Cadastrar novas perguntas, pois o usurio
desejava re-utilizar nesse novo questionrio apenas as perguntas que foram
categorizadas como no funcionais, ou seja, perguntas referentes a requisitos no
funcionais.
o
E-mails dos respondentes: o administrador deve digitar os e-mails dos
respondentes do questionrio sendo criado (um e-mail por linha), para os quais
ser enviado o questionrio;
o
Assunto do e-mail: assunto do e-mail que ser enviado aos
respondentes do questionrio sendo criado;

o
Data limite para resposta do questionrio: data limite at a qual os
respondentes podero enviar suas respostas.

Aps clicar no boto de envio, caso o usurio no tenha selecionado a opo
Cadastrar novas perguntas, o sistema exibe uma tela de confirmao. Caso o
usurio confirme, o questionrio ser criado e sua url de acesso ser enviada por
e-mail para os respondentes. Se o usurio tiver selecionado a opo Cadastrar
novas perguntas (que foi o caso do estudo de caso realizado), o sistema exibir a
tela abaixo, atravs da qual possvel criar novas perguntas (alm de categorizlas como sendo referentes a objetivos funcionais ou no funcionais) e suas
respectivas opes de respostas. No estudo de caso realizado, o usurio cadastrou
ento cada uma das novas perguntas listadas anteriormente:
70
Figura 13 Tela de criao de novas perguntas para o questionrio
Aps ter digitado cada uma das novas perguntas que foram cadastradas e
ter informado no desejar cadastrar mais novas perguntas, o sistema exibe a tela
de confirmao abaixo:
Figura 14 Tela de confirmao de cadastro do questionrio
71
Opo Consulta de questionrio por projeto: ao clicar nessa opo, o

sistema exibe a tela abaixo:
Figura 15 Tela de consulta de questionrios por projeto
O usurio dever informar o nome e/ou a descrio do projeto e clicar no

boto de confirmao. Caso no existam questionrios que atendam s restries
dos parmetros da consulta, o sistema exibir uma mensagem informando que no
existem questionrios cadastrados que atendam aos parmetros informados. Caso
existam questionrios que atendam s restries dos parmetros da consulta, o
sistema ir list-los:
Figura 16 Tela de resultado da consulta de questionrios por projeto
72
O sistema exibe duas opes de relatrios, para a visualizao dos

resultados obtidos atravs do envio das respostas dos respondentes:
o
Relatrio classificatrio: ao clicar nessa opo, o sistema exibe uma
tela com o resultado das estatsticas do questionrio, exibindo as seguintes

informaes para cada pergunta do questionrio: a categoria da pergunta
(Objetivos funcionais referentes a requisitos funcionais, Objetivos no
funcionais referentes a requisitos no funcionais, Classes de usurios para
elicitar informaes dos futuros usurios do sistema); a classificao de cada uma
das perguntas, do ponto de vista dos usurios (Alta, Baixa ou Mdia), de acordo
com as respostas dadas para elas. Alm disso, o sistema exibe o nmero de
participantes e o nmero de pessoas que j responderam o questionrio at o
momento. Dessa forma, possvel o administrador do sistema acompanhar on-line
o andamento das respostas enviadas pelos respondentes, visualizando tambm a
classificao atribuda a cada pergunta (o processo de classificao das perguntas
detalhado na seo 5.3).
Figura 17 Tela que exibe o relatrio classificatrio de um questionrio
73
Relatrio estatstico: ao clicar nessa opo, o sistema exibe uma tela
com o resultado das estatsticas do questionrio, exibindo as seguintes

informaes para cada pergunta do questionrio: o ttulo da pergunta; as possveis
respostas para a pergunta e o percentual de cada resposta enviada pelos
respondentes. Alm disso, o sistema exibe o nmero de participantes e o nmero
de pessoas que j responderam o questionrio at o momento. Dessa forma,
possvel o administrador do sistema acompanhar on-line o andamento das
respostas enviadas pelos respondentes, visualizando o percentual atribudo a cada
uma das respostas, de acordo com as opes selecionadas pelos participantes.
Figura 18 Tela que exibe o relatrio estatstico de um questionrio
74
Opo Consulta de questionrios em andamento: ao clicar nessa opo,

o sistema exibe os questionrios cujas datas limites para resposta ainda estejam
vigentes:
Figura 19 Tela que exibe o resultado da consulta de questionrios em andamento
Opo Cadastro de administrador: ao clicar nessa opo, o sistema exibe

a tela inicial de cadastro de novos administradores:
Figura 20 Tela de cadastro de novos administradores do sistema
Nessa tela, o usurio dever informar: o nome do novo administrador; a

funo exercida pelo novo administrador; o e-mail de contato do administrador;
login (que ainda no tenha sido cadastrado anteriormente) e senha de acesso ao
sistema do novo administrador.
Opo Heursticas: ao clicar nessa opo, o sistema exibe todos os
requisitos necessrios construo de questionrios de boa qualidade, que
encontram-se detalhados no captulo 3 dessa dissertao, com objetivo de guiar o
Engenheiro de Software no processo de construo de questionrios.
75
Figura 21 Tela que exibe as heursticas para a construo de questionrios de

qualidade
Respondendo um questionrio cadastrado e enviado por um dos

administradores do sistema: aps o administrador do sistema cadastrar um novo
questionrio, os respondentes recebem por e-mail uma url para que o questionrio
seja respondido por eles. Essa url ser acessada pelos respondentes que devero
ento responder todas as perguntas solicitadas pelo questionrio at a sua data
limite para resposta. O administrador poder acompanhar atravs das
funcionalidades de consulta disponveis no sistema descritas anteriormente as
estatsticas do questionrio conforme os respondentes vo enviando suas
respostas.
Figura 22 Tela que exibe as perguntas do questionrio enviado aos respondentes
76
5.3.
Mtodo utilizado para anlise das respostas e priorizao dos
requisitos
As estatsticas das respostas de cada pergunta realizada atravs do relatrio
classificatrio, que so apresentadas ao administrador do sistema, foram
elaboradas num formato que fosse possvel o administrador saber qual o nvel de
relevncia, do ponto de vista do respondente, acerca dos assuntos levantados pelas
perguntas do questionrio. Dessa forma, possvel o administrador ter uma idia a
respeito da prioridade de cada uma delas, sendo possvel, por exemplo, priorizar
os requisitos sendo elicitados atravs da aplicao das perguntas.
Conforme os respondentes vo enviando as suas respostas, as perguntas vo
recebendo as seguintes classificaes possveis: BAIXA (requisito pouco
importante), MEDIA (requisito razoavelmente importante) ou ALTA
(requisito muito importante, positivo). Essas classificaes visam apoiar o
Engenheiro de Software no processo de priorizao dos requisitos de software. Se
uma determinada pergunta foi classificada como tendo prioridade ALTA, quer
dizer ento que se trata de um requisito muito importante (do ponto de vista dos
respondentes do questionrio), devendo ento ser priorizado. Todas as respostas
so apresentadas aos respondentes no formato gradativo, sendo atribudos valores
(por exemplo, de 1 a 5) para cada uma das possveis respostas (ex.: 1 pouco
importante; 5 muito importante). Sendo assim, o algoritmo utilizado para
classificar uma pergunta como BAIXA, MEDIA ou ALTA, de acordo com as
respostas enviadas pelos respondentes foi o seguinte:
1.
Os valores atribudos s respostas da pergunta em questo so
somados, para cada um dos respondentes;

2.
Divide-se o valor obtido no passo anterior pelo nmero de pessoas
que j tenham respondido a pergunta;

3.
Os valores obtidos no passo 2 indicam o grau de relevncia da
pergunta, que classificada da seguinte forma:

Se o valor obtido menor ou igual a 2: a pergunta recebe uma classificao
de relevncia BAIXA;
Se o valor obtido igual a 3: a pergunta recebe uma classificao de
relevncia MEDIA;
77
Se o valor obtido maior que 3: a pergunta recebe uma classificao de

relevncia ALTA;
J as estatsticas das respostas de cada pergunta realizadas atravs do
relatrio estatstico, so expostas ao administrador do sistema num formato em
que o sistema exibe as estatsticas percentuais das respostas enviadas pelos
respondentes, acerca dos assuntos levantados pelas perguntas do questionrio.
Conforme os respondentes vo enviando as suas respostas, elas vo recebendo os
percentuais de acordo com a opinio dos participantes. Esse tipo de formato o
mais utilizado na maioria dos sistemas que utilizam questionrios.
Os questionrios gerados atravs da ferramenta no contm estruturas ou
dependncias lgicas, ou seja, a seqncia de perguntas no depende das respostas
anteriores enviadas pelos respondentes.
A ferramenta genrica o suficiente para suportar outros tipos de resposta
possveis, como por exemplo: check-box, combo-box e caixa de texto. No entanto,
a anlise dos resultados aqui proposta foi realizada atravs do formato de
respostas graduais, sendo as respostas apresentadas em opes radio-button
(mutuamente exclusivas).
78
6
Avaliao, contribuio e desdobramentos
Esse captulo ir discutir o mtodo e a ferramenta propostos, com objetivo

de avali-las, detalhando seus pontos fortes e os benefcios trazidos, identificando
tambm os possveis pontos fracos e as fragilidades das mesmas. Posteriormente,
faremos uma comparao da nossa proposta com outras iniciativas anlogas, ou
seja, iniciativas relacionadas ao processo de elicitao de requisitos atravs da
utilizao de questionrios, que foram identificadas no decorrer do processo de
pesquisa.
6.1.
Avaliao do mtodo e da ferramenta propostos
O mtodo proposto nessa dissertao possui o objetivo de apoiar o
Engenheiro de Software no processo de gerao de perguntas de questionrios.
Conforme j detalhado anteriormente, as perguntas dos questionrios gerados
seriam as mtricas obtidas atravs da utilizao do mtodo. Essa uma
abordagem interessante, pois normalmente o processo de gerao de perguntas
no uma tarefa simples, logo, ter um mtodo que apie esse processo certamente
traz benefcios. Como as perguntas so geradas tomando como base os objetivos a
serem atingidos atravs da utilizao do questionrio (atravs da utilizao da
tcnica GQM), subentende-se que os objetivos do questionrio sero alcanados
atravs da aplicao das perguntas (mtricas) geradas.
Todas as perguntas previamente definidas com a utilizao do modelo (e
categorizadas como objetivos funcionais e objetivos no funcionais) foram
geradas atravs da aplicao do mtodo proposto. Como o modelo no abrange
todos os casos possveis, as perguntas geradas conseqentemente tambm no
abrangem todos os casos de requisitos possveis. Entretanto, o modelo flexvel a
ponto de poder ser alterado conforme a convenincia do usurio, podendo at no
ser utilizado, ou seja, os objetivos podem ser definidos separadamente, sem a
79
utilizao do modelo proposto. Caso o usurio no queira gerar as perguntas

atravs da utilizao do mtodo, a ferramenta proposta possui a flexibilidade dele
poder simplesmente criar as novas perguntas que desejar, as quais podem ter sido
geradas ou no atravs da utilizao do mtodo proposto, pois a ferramenta
independente do mtodo proposto. Ao cadastrar uma nova pergunta, o usurio
informa se a pergunta referente a um objetivo funcional (para a elicitao de
requisitos funcionais) ou no funcional (para a elicitao de requisitos no
funcionais).
Todas as respostas geradas atravs da verso corrente da ferramenta
proposta so respostas fechadas e graduais. Porm, o modelo de dados da
ferramenta permite a criao de todos os tipos de resposta, sejam elas abertas ou
fechadas. A restrio imposta pelo fato das respostas serem apenas do tipo
graduais restringe um pouco a amplitude das perguntas que podem ser criadas,
como, por exemplo, perguntas abertas, respostas textuais ou campos de data. As
respostas do tipo graduais por outro lado, facilitam o processo de anlise dos
resultados obtidos, o que certamente seria muito mais custoso caso as respostas
pudessem ser textuais (abertas).
Os processos de anlise adotados permitem o administrador do sistema ter
uma boa viso a respeito do nvel de relevncia, do ponto de vista do respondente,
acerca dos assuntos levantados pelas perguntas do questionrio alm tambm de
poder apresentar as estatsticas percentuais das respostas enviadas pelos
respondentes, o que certamente tambm ajuda o Engenheiro de Software no
processo de anlise dos resultados obtidos.
6.2.
Comparao com outras iniciativas
Agora, iremos comparar as principais diferenas em relao s abordagens
sugeridas pelos artigos [23] e [32], pela dissertao [5] e o mtodo aqui proposto.
As principais diferenas encontradas foram as seguintes:
O mtodo proposto por esta dissertao d a possibilidade de se tomar
como base um modelo conceitual, flexvel, atravs do qual possvel em um nvel
mais abstrato definir os principais requisitos a serem priorizados e os seus
80
relacionamentos e dependncias. A dissertao [5] tambm instancia um modelo

conceitual durante o processo de entrevistas, obtendo automaticamente perguntas
que conduziro o Engenheiro de Software no processo de entrevista, modelo
conceitual esse que representa os elementos do sistema objeto. Ao contrrio da
dissertao [5], o processo de gerao das perguntas dessa dissertao, como
mostrado na seo 4.1, pode ser baseado ou no nesse modelo previamente
definido. Alm disso, proposto um mtodo a ser utilizado para o processo de
gerao das perguntas, utilizando a tcnica GQM. No artigo [23], as perguntas so
definidas pelos prprios usurios, ficando a cargo deles tambm definir um valor
de prioridade para cada uma das questes. No artigo [32], tambm fica a cargo do
usurio definir a lista completa de requisitos arquiteturais e a partir dessa lista so
formuladas as questes, sem a definio de um processo para a gerao das
mesmas.
O mtodo proposto por esta dissertao utiliza uma lista de requisitos a
serem utilizados como base para o processo de gerao das perguntas (boas
prticas). O artigo [23] utiliza uma srie de boas prticas adotadas no processo de
entrevistas em geral, onde essas prticas so simuladas no software que foi
implementado. A dissertao [5] prope a utilizao de um conjunto de
heursticas (derivadas do modelo conceitual) que criticam e validam as
informaes armazenadas no modelo.
O sistema proposto por esta dissertao, analogamente ao proposto pelo
artigo [23] foi desenvolvido para a plataforma web, atravs do qual os
respondentes enviam as suas opinies, sendo possvel interpret-las em uma
funcionalidade utilizada para a anlise estatstica das respostas enviadas. No artigo
[23], o relatrio estatstico apresenta os percentuais de resposta enviados para
cada uma das perguntas, enquanto que o mtodo proposto por esta dissertao,
alm de utilizar essa abordagem, utiliza tambm o mtodo detalhado no item 5.3
dessa dissertao. J o mtodo proposto no artigo [32] no sugere a
implementao de um sistema desse tipo, o que dificulta bastante o processo de
envio, coleta e anlise das questes. J o assistente para entrevistas proposto na
dissertao [5] no foi desenvolvido para plataforma web.
O artigo [23] prope que sejam atribudos valores de prioridade s
questes. J o artigo [32] prope que os prprios respondentes atribuam valores de
prioridade a elas. No mtodo proposto, a idia anloga ao artigo [32], pois os
81
respondentes atribuem graus de prioridade medida que as questes vo sendo

respondidas, sendo possvel prioriz-las (identificando possveis requisitos, do
ponto de vista dos respondentes) automaticamente pelo sistema, o que por sua vez
no realizado no artigo [32]. Na ferramenta proposta na dissertao [5], o
modelo documenta a entrevista de uma forma estruturada, disponibilizando ao
Engenheiro de Software as respostas da entrevista organizadas segundo o papel de
cada uma no sistema objeto.
As questes no artigo [23] podem estar numa variedade de formatos. As
de mltipla escolha devem ser utilizadas para questes fechadas e as de texto livre
devem ser utilizadas para questes abertas. Tambm poderia existir a facilidade de
utilizar ckeck-lists e listas drop-down conforme apropriado. No artigo [32], assim
como na dissertao [5], todas as questes so abertas. J no mtodo aqui
proposto, as questes so fechadas do tipo gradativas, com o objetivo do usurio
prioriz-las de acordo com as suas opinies. Porm, o modelo genrico o
suficiente para suportar outros tipos de resposta possveis, como por exemplo:
check-box, combo-box e caixa de texto. Dessa forma, o modelo apia a gerao de
questionrios qualitativos, que podem ser construdos para atender diversos tipos
de pergunta, alm das perguntas do tipo gradual, utilizadas nessa dissertao.
O artigo [23] prope um procedimento de ordenao dinmica das
questes, atravs do qual cada questo deve ter associada a ela um valor de
prioridade, que pode ter o seu valor alterado durante o curso da entrevista
dependendo das respostas dadas pelos entrevistados durante a realizao da
entrevista. No mtodo aqui proposto a ordenao das questes e sua conseqente
ordem de exibio so definidas no momento em que as mesmas so cadastradas,
no sendo possvel alterar dinamicamente a sua ordem;
Tanto na ferramenta apresentada no artigo [23] quanto na ferramenta
proposta por esta dissertao pode existir a facilidade de os usurios adicionarem
comentrios a qualquer resposta dada, no momento em que ele estiver
respondendo as questes. Isso permite que eles expandam, expliquem ou
justifiquem suas respostas sempre que eles sentirem necessidade;
Tanto na ferramenta apresentada no artigo [23] quanto na ferramenta
proposta por esta dissertao no existe um tempo previamente definido para que
os usurios respondam s questes. O que existe uma dada limite para que o
82
questionrio seja respondido. No assistente proposto na dissertao [5] tambm

no existe um tempo previamente definido para que o Engenheiro de Software
responda as questes apresentadas pela ferramenta no decorrer da entrevista. A
perguntas vo sendo respondidas durante a realizao da entrevista.
O artigo [32] foca na elicitao apenas de requisitos do tipo arquiteturais,
enquanto que no mtodo aqui proposto no h restrio.
6.3.
Contribuies
Entendemos que a dissertao traz as seguintes contribuies:
Uma lista de requisitos para apoiar a construo de questionrios, que
poder ser utilizada como referncia por pessoas que desejam elaborar
questionrios.
A definio de um mtodo que ajude a construo de perguntas de
questionrios, que tambm poder ser utilizado por pessoas que desejam elaborar
perguntas de questionrios a serem construdos. Esse mtodo utiliza a tcnica
GQM (Goal Question Metric), com objetivo de demonstrar a eficcia de sua
utilizao nesse contexto.
Uma ferramenta web para criao de questionrios, que permite o usurio
utilizar perguntas previamente formuladas e devidamente categorizadas (ex.:
requisitos funcionais ou no funcionais) atravs do processo definido, permitindo
tambm que o usurio cadastre perguntas que lhe forem mais convenientes. A
ferramenta ir, de acordo com a opinio dos respondentes, priorizar os requisitos
funcionais e no funcionais que foram considerados necessrios implementao
de um sistema a ser desenvolvido, alm de exibir tambm uma anlise estatstica
das repostas enviadas. Vale salientar que no um conjunto de requisitos
completo; poder ser incrementado e modificado conforme necessrio.
Um modelo conceitual extensvel que cobre alguns casos que foram
considerados importantes, para a priorizao e elicitao de requisitos de projetos
e/ou sistemas de software. Foi demonstrado que a partir de um modelo possvel
gerar um conjunto de perguntas de questionrios (possveis requisitos), que so
por sua vez priorizadas de acordo com a opinio dos respondentes.
83
6.4.
Trabalhos futuros
Nossa contribuio envolve uma estratgia para a elicitao e priorizao de
requisitos de software atravs da utilizao de questionrios, gerados atravs de
uma ferramenta web assistente em todo o processo (gerao das perguntas e
anlise dos resultados obtidos).
Do ponto de vista dessa estratgia, identificamos a aplicao da estratgia
em outros estudos de caso em domnios de sistemas de informao e outros
domnios, como por exemplo, na rea de Cincias Sociais e Marketing, para se ter
uma avaliao mais completa da sua eficcia em outros domnios. Existe tambm
a possibilidade de se incrementar e adaptar o modelo conceitual proposto. Alm
disso, poderia ser realizada uma investigao de como o modelo conceitual
proposto pode ser integrado a mtodos de especificao de requisitos,
funcionando como uma base de conhecimento.
Do ponto de vista da ferramenta, poderamos ter a implementao de:
tcnicas de resoluo de conflitos para a anlise das respostas; outras tcnicas para
anlise estatstica dos resultados obtidos; outros tipos de pergunta (atualmente o
modelo genrico, mas implementamos somente perguntas com respostas do tipo
graduais) fechadas e at mesmo abertas, sendo que a anlise dos resultados de
perguntas abertas muito mais trabalhosa e no prevista pelo modelo proposto
nessa dissertao.
84
7
Referncias bibliogrficas
GOODE, W. J.; HATT, P. K. Mtodos em Pesquisa Social. 4a ed. So

Paulo: Comp. Ed. Nacional, p. 35-67,1960.
MATTAR, F. N. Pesquisa de marketing. 3a. ed., So Paulo: Atlas, p. 12-55,
2001.
3
PARASURAMAN, A. Marketing research. 2. ed., Addison Wesley

Publishing Company, p. 21-60, 1991.
SELLTIZ, C.; COOK, S. W. Mtodos de pesquisa nas relaes sociais. 2a.

ed., So Paulo: E.P.U., p. 31-55, 1987.
GILVAZ, A. P. FAES Um Assistente para Entrevistas. Dissertao de

Mestrado, PUC-Rio,1994.
MATHIAS, A. G. O Gerenciamento de Conflitos na Elicitao de

Requisitos. Dissertao de Mestrado, PUC-Rio, 1994.
LACERDA, P. M. A vingana dos anexos : como a elaborao de um

questionrio tornou-se, ela mesma, uma pesquisa. Dissertao de Mestrado,
PUC-Rio, 2000.
KITCHENHAM, B. Survey Methods. 17 SBES, MT1, 2003.
WIEGERS, K.E. Software Requirements. Microsoft, p. 22-44, 1999.
10 ROBERTSON, S.; ROBERTSON, J. Mastering the Requirements Process.

Addison Wesley Publishing Company, p. 10-23, p. 104-136, 1999.
11 SCOTT, A. C.; CLAYTON, J. E.; GIBSON, E. L. A Pratical Guide to
Knowledge Acquisition. Addison Wesley Publishing Company, 1991.
12 GOGUEN, J.A.; LINDE, C. Techiques for Requirements Elicitation. In:
Proceedings of the First IEEE International Symposium on Requirements
Engineering, San Diego, Ca, IEEE Computer Society Press, p. 1-14, 1994.
13 CYSNEIROS, L. Requirements Engineering in the Health Care Domain.
RE03-IEEE Joint International Requirements Engineering Conference Essen, Alemanha, 2003.
85
14
SOLINGEN, R. V.; BERGHOUT, E. The Goal Question Metric Method:

A
Practical Guide for Quality Improvement of Software Development.
McGraw-Hill, 1999.
15
CHUNG L. et al. Non-Functional Requirements in Software Engineering.

Kluwer Academic Publishers, 1 ed., 1999.
16 Sun Microsystems. Architecting and Designing J2EE Applications. SL

425 Student Guide; Revision A.3, p. 22-55, 2001.
17 LEITE, J. C. S. P. et al. A Scenario Construction Process. Requirements
Engineering, 2000.
18 MICH, L.; FRANCH, M., PIERLUIGI, N. I. Market research for
requirements analysis using linguistic tools. Springer, Verlag London
Limited, p. 2-14, 2003.
19 NIKULA, U.; SAJANIEMI, J.; KALVIAINEN, H. A state of the practice
survey on requirements engineering in small and medium sized
enterprises. Lappeenranta, 2000;
20 GORDON, T. J. The Delphi Method. AC/UNU Millennium Project, p. 4-33,
1994;
21 DUPPLAW, D. P. et al. A web-based knowledge elicitation system
(GISEL) for planning and assessing group screening experiments for
product development. University of Southampton, p. 1-13, 2004.
22 SCAPOLO, F. Eliciting Expert Judment SMIC Method. Regional
Foresight Methods Training Workshop, 2003.
23 HANDS, K.; PEIRIS, D. R.; GREGOR, P. Development of a computerbased interviewing tool to enhance the requirements gathering process.
Requirements Eng., p. 1-13, 2004.
24 IEEE. Recommended Practice for Software Requirements
Specifications. Std 830, 1998.
25 The 16th International Conference on Advanced Information Systems
Engineering. CAiSE'04 in Porto, Portugal, Jun. 2004.
Disponvel em: <http://www.cs.rtu.lv/caise2004>. Acesso em: 30 jul. 2004.
26 IEEE Computer Society. 2004. Disponvel em: <http://www.computer.org>.
Acesso em: 15 jul. 2004.
27 Schloss Dagstuhl International conference and Research Center for
86
Computer Science. 1996-2005. Disponvel em: <http://www.dagstuhl.de>.

Acesso em: 20 jun. 2004.
28 SpringerLink. Disponvel em: <http://springerlink.metapress.com>. Acesso
em: 02 mai. 2004.
29 M.E.Sharpe, Inc. 2004. Disponvel em: <http://www.mesharpe.com>.
Acesso em: 25 mai. 2004.
30 Journal of Information, Law and Technology. Disponvel em:
<http://elj.warwick.ac.uk/jilt>. Acesso em: 10 jun. 2004.
31 Journal of Information & Knowledge Management. 2005. Disponvel em:
<http://www.worldscinet.com/jikm/jikm.shtml>. Acesso em: 12 ago. 2004.
32 EELES, P. Capturing Architectural Requirements. IBM, Abr. 2004.
Disponvel em:
<http://www-106.ibm.com/developerworks/rational/library/4706.html>.
Acesso em: 10 mai. 2004.
33 VII Workshop on Requirements Engineering. Dez. 2004, Tandil,
Argentina. Disponvel em: <http://www.exa.unicen.edu.ar/wer2004/>.
Acesso em: 01 fev. 2005.
34 VI Workshop on Requirements Engineering. Nov. 2003, So Paulo, Brasil.
Disponvel em: <http://www.inf.puc-rio.br/wer03/>.
Acesso em: 12 mar. 2004.
35 CHAGAS, A.T.R. O questionrio na pesquisa cientfica. FECAP, Mar. 2000,
So
Paulo,
Brasil.
Disponvel
em:
<http://www.fecap.br/adm_online/art11/anival.htm>. Acesso em: 22 abr.

2003.
36 SANTOS, C.A. et al. Desenho de questionrios. FMUP - Faculdade de
Medicina do Porto. Disponvel em:
<http://intro.med.up.pt/t12_g1/web_t12_g1/index.htm>. Acesso em: 09 mar.
2003.
37 SILVA, L.F.; LEITE, J.C.S.P.; BREITMAN,K. K. Ensino de Engenharia de
Engenharia de Software: Relato de Experincias, XII WEI - Workshop de
Educao em Informtica, Salvador, 2004, pp. 994-1005.
38 Requirements Engineering Journal. Information Systems Group,
Department of Computation, UMIST. Disponvel em:
<http://rej.co.umist.ac.uk/>. Acesso em: 05 ago. 2004.
87
39 International Workshop on Requirements Engineering. Riga, Latvia, Jun.

2004. Disponvel em:< http://research.it.uts.edu.au/re/re-archive/1740.html>.
Acesso em: 12 ago. 2004.
40 Volere Requirements Resources. The Atlantic Systems Guild Inc., 2004.
Disponvel em: < http://www.volere.co.uk/>. Acesso em: 21 set. 2004.
41 RE 2003 - 11th IEEE International Requirements Engineering
Conference. Monterey Bay, California, EUA, Set. 2003. Disponvel em:
<http:// www.re03.org>. Acesso em: 25 set. 2004.
42 RE 2004 - 12th IEEE International Requirements Engineering
Conference. Kyoto, Japo, Set. 2004. Disponvel em:
<http:// www.re04.org>. Acesso em: 12 dez.2004.
43 The Requirements Engineering Specialist Group of the British Computer
Society. BCS Specialist Group. Disponvel em: < http://www.resg.org.uk>.
Acesso em: 06 out. 2004.
44 Journal of Management Information Systems. M.E. Sharpe. Disponvel
em: < http://www.mesharpe.com/mall/results1.asp?ACR=MIS>. Acesso em:
19 mai. 2004.
45 Robichez, G. et al. Expert Committee. Introduo a Engenharia de Software
para Sistemas Multi-Agentes, PUC-Rio, 2004.

Bastos Junior, P. R. O. - Elicitação de Requisitos de Software Através Da Utilização de Questionários

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bastos Junior, P. R. O. - Elicitação de Requisitos de Software Através Da Utilização de Questionários

Uploaded by

Copyright:

Available Formats

Paulo Roberto de Oliveira Bastos Junior

Elicitao de requisitos de software atravs da

Orientador: Julio Csar Sampaio do Prado Leite

Todos os direitos reservados. proibida a reproduo total ou

Paulo Roberto de Oliveira Bastos Junior

A meus pais, pela fora e incentivo.

Bastos Junior, Paulo Roberto de Oliveira; Leite, Julio Csar Sampaio do

Um dos possveis meios utilizados para a coleta de fatos na elicitao de

Bastos Junior, Paulo Roberto de Oliveira; Leite, Julio Csar Sampaio do

questionnaires. Rio de Janeiro, 2005. 81p. Master degree thesis

elicitation. A questionnaire is a document used to guide one or more people to

1.2. Objetivo da dissertao

1.3. Organizao da dissertao

2.1. A utilizao de questionrios na Engenharia de Requisitos

2.2. A tcnica GQM

3.1. Tipos de questes

3.2. Requisitos para a construo de questionrios de boa qualidade

3.3. Erros comumente cometidos num processo de aplicao de

3.4. Avaliao do questionrio

4. Um processo para a elaborao de perguntas de questionrios para a

4.1. Definio do processo

5.1. Caractersticas gerais da ferramenta

5.2. Apresentao da ferramenta

5.3. Mtodo utilizado para anlise das respostas e priorizao dos

6. Avaliao, contribuio e desdobramentos

6.1. Avaliao do mtodo e da ferramenta propostos

6.2. Comparao com outras iniciativas

6.4. Trabalhos futuros

O objetivo desse captulo estabelecer o contexto de nossa pesquisa. Em

Identificao dos requisitos funcionais e no-funcionais do sistema a

Identificao da infra-estrutura necessria;

Levantamento da quantidade de profissionais e suas respectivas

Definio das tecnologias a serem utilizadas;

Planejamento das atividades a serem realizadas;

Planejamento do cronograma do projeto;

Definio do processo a ser adotado;

Definio dos mtodos a serem utilizados;

Muitas vezes difcil fazer reunies iniciais ou entrevistas para realizar o

Os envolvidos ou interessados em um projeto so denominados stakeholders do projeto.

questes geogrficas (distncia fsica), por indisponibilidade de agenda para a

na rea de Engenharia de Requisitos; pesquisas em outras reas, tais como:

No site de buscas do Google;

Em peridicos, portais, workshops e conferncias da rea, tais como:

Workshop on Requirements Engineering [33, 34]; The 16th International

Nas bibliotecas central e setorial de informtica da PUC-Rio;

Foram trocados e-mails com alguns professores de universidades

estrangeiras da rea de Engenharia de Software, tais como: Luisa Mich

Essas buscas no tiveram um resultado to positivo quanto o obtido na rea

Ordenao dinmica das questes: cada questo deveria ter associada a

Na figura abaixo possvel visualizar o processo de ordenao dinmica das

Figura 1 Processo de ordenao dinmica das questes de [23]

Tipos de questo: as questes podem estar numa variedade de formatos.

As de mltipla escolha devem ser utilizadas para questes fechadas e as de texto

Facilidade para rever as respostas: os entrevistados deveriam ser capazes

Confirmao das respostas: deveria ser solicitado que os entrevistados

Sem facilidade para alterar as respostas: os entrevistados no deveriam

Facilidade para adicionar comentrios: os entrevistados deveriam ser

capazes de adicionar comentrios a qualquer resposta dada, no momento em que

significante. Entretanto o artigo foca primeiramente nos requisitos explcitos, os

Suporte a mltiplas linguagens;

O banco utilizado ser o Oracle 8i;

Ser requerido um help on-line;

Toda a lgica de apresentao ser escrita em Visual Basic.