Priorizao de requisitos e avaliao da qualidade

de software segundo a percepo dos usurios

Aline Gomes Cordeiro

Mestre em engenharia de produo pela Universidade Estadual do

Norte Fluminense Darcy Ribeiro. Professora do Instituto Federal
Fluminense Darcy Ribeiro Centro de Cincias e Tecnologias,
Laboratrio de Engenharia de Produo. Campos dos Goytacazes,
RJ Brasil
E-mail: acordeiro@iff.edu.br

Andr Lus Policani Freitas

Doutor em engenharia de produo pela Universidade Estadual do

Norte Fluminense Darcy Ribeiro, Brasil Professor da Universidade
Estadual do Norte Fluminense Darcy Ribeiro, Centro de Cincias e
Tecnologias, Laboratrio de Engenharia de Produo. Campos dos
Goytacazes, RJ - Brasil
E-mail: andrepolicani@yahoo.com

Resumo
Atualmente softwares tm sido reconhecidos como
importante ferramenta de apoio s diversas atividades
e tomada de decises. No entanto, existem relatos a
respeito de projetos de desenvolvimento de software
fracassados. A questo problema apresentada por este
artigo a seguinte: Como possvel realizar a avaliao
da qualidade de um produto de software desde as
etapas iniciais do projeto, de forma que seja possvel
realizar as melhorias com menor esforo? O artigo traz
uma abordagem metodolgica para a priorizao dos
requisitos de software e a avaliao da qualidade do
produto de software, segundo a percepo dos usurios.
Em especial, a abordagem prope o emprego da Anlise
Importncia-Desempenho (IPA) e do mtodo dos 100
pontos para a etapa de priorizao, e para a etapa de
avaliao de desempenho, o emprego da IPA e da escala
contnua. Por meio de estudo de caso, a abordagem
proposta foi aplicada a um projeto de desenvolvimento
de software para gesto de recursos humanos. A partir
desse uso foi possvel captar os julgamentos, determinar
as prioridades dos requisitos conforme a percepo dos
usurios e sugerir aes relevantes com o objetivo de
melhorar a qualidade do software. Acredita-se que a
abordagem proposta seja aplicvel ao desenvolvimento
de produtos de software de pequeno porte.

160

Palavras-chave
Priorizao de requisitos. Qualidade de software. Produto
de software.

Prioritizaion of requirements and evaluation

of software quality according to the users
perspective
Abstract
Nowadays software has been recognized as an
important tool to support various activities and decision
making. However, there are several reports regarding
failures on development of software projects. In this
scenario, the phase of requirements elicitation, allied
to users satisfaction, has been highlighted as leading
to the improvement of the software development
process. Thus, the main issue presented by this article
is defined as follows: How is it possible to assess the
quality of software product from the initial stages of
design, so we can make improvements with less effort?
This article proposes a methodological approach for
prioritizing software requirements and evaluating the
quality of software products according to the users
perspective. In particular, such approach proposes the
use of Importance-Performance Analysis (IPA) and the
100-points method for prioritizing the requirements, and
the use of IPA and the continuous scale for doing the
performance evaluation stage. By conducting a case
study, the proposed approach was applied to a software
development project for human resource management.
By doing so, users evaluations were collected, the
software requirements were prioritized according to their
perspectives and relevant actions were suggested in
order to improve the quality of the software. It is believed
that the proposed approach may be suitable to the
development of small software products.
Keywords
Requirements prioritization. Software quality. Software
product.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

Introduo
Atualmente, softwares tm sido cada vez mais
utilizados nas organizaes como instrumento de
apoio s diversas atividades e tomada de decises.
possvel observar sua presena como ferramenta
em diferentes ramos de negcios, como sade,
educao e indstrias. As melhorias obtidas a partir
de sua utilizao podem ser notadas e geralmente
justificam os investimentos necessrios.
Apesar da importncia do software para as
organizaes, um dos grandes desafios refere-se
ao fato de que, s vezes, o investimento feito em
sistemas informatizados no fornece o retorno
esperado, ou seja, os sistemas no se adequam
realidade das empresas onde so implantados.
Os processos de negcio nesses casos no so
condizentes com os processos definidos pelo
sistema informatizado.
Para Karlsson e Ryan (1996), um dos maiores riscos
enfrentados por organizaes que desenvolvem
software comercial est associado ao no atendimento
das necessidades e expectativas dos usurios. Para
esses autores, esse risco pode ocasionar danos na
reputao, perda de pedidos e reduo dos lucros
da empresa.
Pesquisas que visam identificao das causas para
o problema citado apontam a fase de elicitao de
requisitos, tambm conhecida como levantamento
de requisitos, como bsica para a melhoria do
processo. Ela uma das atividades que ocorre no
incio do desenvolvimento de software. Erros gerados
nessa etapa, se no forem corrigidos, estendem-se
at o final do processo, e aps a verificao de cada
erro, todas as fases anteriores precisam ser refeitas.
Para Sadraei et al. (2007), os requisitos de software so
determinantes crticos da sua qualidade.

se com a qualidade do processo de desenvolvimento

ou com o produto final gerado. O foco de estudo
deste artigo est relacionado ao produto. Este tipo
de abordagem busca analisar a qualidade do produto
obtido no desenvolvimento de software.
A abordagem baseada no produto tem contribudo
para elevar a qualidade de softwares. No entanto,
ela possui algumas limitaes. A principal est
relacionada ao fato de a avaliao da qualidade ser
realizada apenas quando o produto j tiver sido
implementado. Neste caso, aps a avaliao so
identificadas correes e melhorias. Porm, nesta
etapa do projeto, o esforo necessrio para alterar
caractersticas do software grande.
Caracteriza-se assim o problema de pesquisa tratado
por este artigo: como possvel realizar a avaliao
da qualidade do produto de software desde as etapas
iniciais, de modo que seja possvel realizar as
melhorias com menor esforo?
Alm da introduo, o artigo apresenta breve
referencial terico relacionado avaliao da qualidade
de software e ao seu processo de desenvolvimento; a
abordagem metodolgica proposta para avaliar a
qualidade de software, desde a etapa de elicitao
de requisitos com sua priorizao, e a avaliao de
desempenho do produto de software; os resultados
de um estudo realizado com o intuito de investigar
o emprego da referida abordagem na elaborao de
um software de pequeno porte; a anlise dos resultados
segundo a percepo da gerncia de projetos; as
consideraes finais; e por ltimo, os apndices
contendo os questionrios utilizados.
Referencial Terico
Qualidade de software e avaliao

Nesse sentido, a avaliao da qualidade de software

tem sido identificada como uma possibilidade de
minimizao do problema. A qualidade, como
tratada atualmente na literatura cientfica, preocupa-

comum encontrar definies de qualidade de

software que remetem ao fato de ele ter que atender
aos requisitos, ou seja, s necessidades dos usurios,
que variam de usurio para usurio, o que torna
ainda mais complexa a obteno de uma definio.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

161

Aline Gomes Cordeiro / Andr Lus Policani Freitas

Para Denning (1992), a satisfao dos usurios

uma referncia para a qualidade. Os usurios no se
preocupam com detalhes estruturais, mas sim com
o quanto o software facilita o trabalho.
Pressman (2002) cita a necessidade de conformidade
aos requisitos funcionais, aos padres de
desenvolvimento claramente documentados e s
caractersticas implcitas esperadas de todo software
profissionalmente desenvolvido. A ausncia de
conformidade com os requisitos falta de qualidade.
Segundo Magalhes (2006), para que um software
seja considerado de qualidade preciso que esteja
em conformidade com os seus requisitos, atenda
aos requisitos e expectativas do cliente e seja bem
aceito por seus usurios.
Os estudos supracitados evidenciam a importncia
do papel do usurio para obter qualidade. Por isso,
neste artigo considera-se que a percepo dos
usurios o foco para avaliao do software. Eles
podem ser compreendidos como as pessoas que
fazem ou faro uso do software.
De maneira complementar, necessrio ressaltar
a distino entre a qualidade voltada para o
produto e a qualidade voltada para o processo
de desenvolvimento. A primeira tradicionalmente
se refere avaliao do softwar e aps seu
desenvolvimento. Dentre os estudos desenvolvidos
visando avaliao da qualidade do produto
destacam-se os realizados por Punter et al. (2004);
Jung (2007); Boente e Mor (2009); Larsen (2009);
Saini et al. (2011); e Garofalakis et al. (2011).

Rosqvist et al. (2003); Belgamo et al. (2005); Gousios

et al. (2007); Janzen e Saiedian (2008); Bertrn (2009);
e Srivastava et al. (2011).
O processo de desenvolvimento de software
O aspecto no repetitivo do desenvolvimento de
software torna essa atividade difcil e at mesmo
imprevisvel. Apenas pequena parcela da construo
de software corresponde a atividades relativas
montagem. Por isso, a atividade de desenvolvimento
de software caracteriza-se como uma tarefa complexa
(KOSCIANSKI e SOARES, 2007).
O processo constitudo por vrias etapas e aes
que devem ser realizadas com o objetivo de obter
um produto de software. Ao longo do tempo, diversos
modelos tm sido criados e testados. Segundo
Pressman (2002), o modelo mais adequado para um
projeto deve ser escolhido com base na natureza do
projeto e da aplicao, nos mtodos e ferramentas
a serem usados, e nos produtos intermedirios e
finais requeridos.
O desenvolvimento iterativo incremental uma das
metodologias mais usadas para a implementao de
software. Segundo esta abordagem, o desenvolvimento
constitudo de uma srie de miniprojetos,
chamados de iteraes. Cada uma visa obteno
de um produto com qualidade superior oriundo da
iterao anterior. Vrias iteraes ocorrem para que
no final resulte um software pronto para ser utilizado
(LARMAN, 2004). A figura 1, a seguir, ilustra esse
processo.

J a qualidade de software focada na abordagem para

o processo almeja a qualidade do produto final
pelo alcance da qualidade nas etapas intermedirias
do processo de desenvolvimento. Em geral,
metodologias que visam qualidade do processo
inserem tarefas e mtodos que devem ser realizados
durante cada etapa. Um exemplo tpico so os
mtodos de teste de software. Dentre os estudos
usando essa abordagem, destacam-se os feitos por

Na figura 1 tem-se a re presentao das

necessidades do usurio como ponto de partida
para o desenvolvimento do software. A partir da, o
processo ocorre pela execuo de suas etapas. No
desenvolvimento iterativo, a cada iterao as etapas
so executadas e uma entrega feita aos usurios.
Aps vrias iteraes tem-se o produto pronto,
mesmo sendo comum sofrer vrias modificaes
para adaptao realidade dos usurios ou para
correo de erros.

162

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

FIGURA 1
Viso simplificada de um processo de desenvolvimento de software

Fonte: Cordeiro e Freitas (2008).

Metodologias que buscam a qualidade do produto de

software definem atividades desempenhadas ao final
do processo de desenvolvimento, com o software j
testado. J as metodologias que visam qualidade
do processo de desenvolvimento definem atividades
realizadas durante o processo com a melhoria das
etapas intermedirias: anlise de requisitos; anlise
e projeto; implementao e teste. Tais mtodos
interferem no modo como os envolvidos executam
as atividades.
A etapa de anlise dos requisitos um dos aspectos
centrais para o entendimento do estudo descrito por
este artigo. Por isso, as sees seguintes descrevem
algumas atividades executadas nessa etapa.
Elicitao e priorizao de requisitos
Um software deve possuir caractersticas que
contribuam para a soluo de problemas e a melhoria
da qualidade de trabalho dos usurios, tendo como
consequncia a melhoria da qualidade do servio ou
do produto da empresa. Portanto, preciso utilizar
uma maneira adequada para identificar (elicitar) e
priorizar tais aspectos, que constituem os requisitos.
Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Robertson e Robertson (2006) conceituam requisitos

como algo que o produto deve fazer ou uma
caracterstica que o produto deve ter, e que
necessrio ou desejado pelos stakeholders. Young
(2004) corrobora esse conceito, afirmando que
requisitos so atributos necessrios em um sistema
para que ele tenha valor e utilidade para os clientes
e usurios. Para o autor, os requisitos do sistema
so importantes porque fornecem a base para
todo o trabalho de desenvolvimento de software
subsequente.
Considerando que so as necessidades dos usurios
que justificam o investimento em um projeto
de software, no faz sentido que o foco principal
do projeto seja outro seno a soluo para essas
demandas. Embora essa seja uma afirmativa lgica,
a realidade mostra que muito comum os objetivos
de um projeto de software se distanciarem das
necessidades de seus usurios. Por esta razo, a fase
de elicitao de requisitos pode ser compreendida
como base para todas as outras atividades relativas
ao desenvolvimento de software.

163

Aline Gomes Cordeiro / Andr Lus Policani Freitas

Leffingwell e Widrig (1999) asseguram que erros

na elicitao de requisitos representam a classe
mais significativa de problemas relacionados ao
desenvolvimento de software, sendo tambm os
mais caros de se corrigir. Uma elicitao ineficaz
traz consequncias que podem levar ao fracasso do
projeto. Isso pode ser explicado pelo fato de tal etapa
constituir a base para as atividades subsequentes.
Se a base mal construda, as falhas decorrentes
da podem continuar acontecendo e at mesmo se
tornar mais complexas posteriormente. Segundo
Larman (2004), a indstria de software est repleta
de projetos fracassados que no forneceram o que
as pessoas realmente demandavam.
Segundo Boehm (1983), quando os problemas so
detectados em fases mais avanadas, a correo se
torna mais difcil e vrias etapas precisam ser refeitas.
O retrabalho tem consequncias negativas para o
projeto, como o aumento dos custos e atrasos no
cronograma. Devido a esses aspectos, para Babar
et al. (2011), a identificao correta dos requisitos
interfere na qualidade do software.
Tcnicas para a elicitao de requisitos so
importantes porque facilitam a comunicao entre as
pessoas envolvidas e devem ser definidas de acordo
com as caractersticas dos requisitos e do negcio
onde o software est inserido (COUGHLAN E

MACREDIE, 2002). O quadro 1 apresenta tcnicas

descritas por Maiden e Rugg (1996).
As tcnicas de elicitao visam identificao
dos requisitos. No entanto, devido a restries
de tempo e oramento, pode ser difcil atender a
todos os requisitos identificados para um sistema.
Os requisitos geralmente so desenvolvidos em
etapas e a priorizao ajuda a definir quais devem
ser implementadas primeiro (ALLEN et al., 2008).
Segundo Karlsson, Wohlin e Regnell (1998), os
requisitos devem ser alocados em diferentes verses
do software e, para Berander (2004), a seleo
correta dos requisitos que faro parte de cada
verso a etapa principal em direo ao sucesso de
um projeto ou produto. Por isso, preciso distinguir
aqueles que tero maior impacto para a satisfao
dos usurios. Alguns mtodos destacados por Allen
et al. (2008) so descritos no quadro 2.
Outro mtodo utilizado para priorizao de
requisitos de software a Anlise ImportnciaDesempenho (Importance-Performance Analysis IPA),
proposta por Martilla e James (1977). Segundo
Hudson, Hudson e Miller (2004), a IPA mostra
a relevncia de vrios atributos e o desempenho
do produto no que se refere ao estudo e anlise
desses atributos. Na aplicao do mtodo, cada
respondente deve julgar a importncia de cada

QUADRO 1
Tcnicas de elicitao de requisitos

164

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

atributo, bem como a sua percepo de desempenho

para cada um.
Leeworthy e Wiley (1996) explicam que a IPA
oferece uma forma de visualizao simples, na
qual a apresentao dos dados feita por meio de
quatro quadrantes que formam a matriz da anlise
importncia-desempenho. O eixo vertical da matriz
referente importncia e o horizontal percepo
de desempenho. Depois de realizada a mensurao,
os atributos so dispostos na matriz e, de acordo
com a posio onde ficam situados, obtm-se o
resultado relativo satisfao dos clientes.
Skok, Kophamel e Richardson (2001) realizaram a
avaliao do sucesso de investimentos em sistemas
de informao em uma organizao da rea de
sade utilizando a anlise importncia-desempenho.
Segundo os autores, ela tem se revelado uma
ferramenta de gesto simples e efetiva. O baixo custo
de aplicao torna vivel sua aplicao em outras
avaliaes para acompanhamento das melhorias
realizadas.

Cordeiro e Moll (2006) aplicaram a IPA para avaliar

a qualidade de produto de software utilizando como
critrios requisitos no funcionais. O mtodo
mostrou-se satisfatrio para identificar os requisitos
que necessitavam de melhorias.
A A b o r dag e m m e to d o l gica
proposta
A abordagem metodolgica proposta sugere a
avaliao da qualidade do produto de software, para
que seja possvel buscar a qualidade desde o incio do
desenvolvimento. Tal abordagem caracteriza-se por
ser de uma pesquisa de natureza exploratria, tendo
como objetivo prover percepes e compreenses
a respeito de um problema. Segundo Malhotra
(2006), a pesquisa exploratria usada em casos nos
quais necessrio definir o problema com maior
preciso, identificar cursos relevantes de ao ou
obter dados adicionais antes de poder criar uma
abordagem conclusiva. A amostra, selecionada para
gerar o mximo de discernimento, pequena e no
representativa.

QUADRO 2
Mtodos para priorizao de requisitos de software

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

165

Aline Gomes Cordeiro / Andr Lus Policani Freitas

Neste artigo, o carter exploratrio advm do fato

de que no h um consenso entre pesquisadores e
desenvolvedores acerca do processo mais adequado
para a elaborao de produtos de software. Alm disso,
no possvel transpor os resultados obtidos neste
estudo para outras situaes, devido a eventuais
diferenas entre as realidades existentes.

que precisam ser desenvolvidos. Contudo, neste

momento, os desenvolvedores no sabem quais
requisitos so mais relevantes para os usurios,
por isso necessrio prioriz-los. Para atender aos
requisitos de acordo com a percepo dos usurios,
utiliza-se o mtodo dos 100 pontos em conjunto
com a avaliao de importncia da anlise IPA.

Apesar de existir a preocupao com a qualidade

desde o incio, no seria correto afirmar que a
referida abordagem baseada no processo, pois o
foco do estudo no est nas atividades executadas
em cada etapa do desenvolvimento. O foco
concentra-se na satisfao do usurio em relao ao
produto de software resultante do processo. A figura
2 representa o modelo conceitual que sintetiza a
abordagem proposta e relaciona conceitos relevantes
para o entendimento do estudo de caso.

A priorizao relevante porque os usurios

tm expectativas em relao ao software que est
sendo gerado. A entrega dos requisitos segundo
a percepo dos usurios, alm de contribuir
para a satisfao deles, pode ser essencial para a
continuidade do projeto. Para exemplificar, na figura
2 esto representados cinco nveis de prioridades,
variando de P1 a P5.

Acredita-se que a conformidade do software aos

requisitos seja essencial para a satisfao dos
usurios e que a satisfao dos usurios, por sua vez,
seja determinante para a melhoria da qualidade do
software. Neste sentido, prope-se a priorizao dos
requisitos no incio do desenvolvimento e a avaliao
de desempenho quando o produto j est em uso,
conforme ilustrado na figura 2. Aps a elicitao
dos requisitos, obtm-se uma lista de requisitos

Caso o software seja elaborado de forma iterativa, vrias

iteraes podem ocorrer at que o primeiro mdulo
seja considerado pronto. Nesta circunstncia,
entregas intermedirias devem ser feitas para que
os usurios comecem a utiliz-lo. Quando todos
os requisitos ou a maior parte deles j tiver sido
desenvolvida e o mdulo estiver em uso, possvel
realizar a avaliao de desempenho do produto,
utilizando-se uma escala contnua e a avaliao de
desempenho da anlise IPA.

FIGURA 2
Modelo Conceitual

166

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

Os resultados da avaliao de importncia e da

avaliao de desempenho da IPA devem ser usados
para a construo da matriz de anlise importnciadesempenho. A matriz permite a identificao
dos atributos, neste caso requisitos, que requerem
melhorias. Alteraes necessrias podem ser
realizadas no mdulo A.
Aps as atividades de melhoria, novas avaliaes
de desempenho podem ser feitas com o intuito
de obter um produto mais adequado percepo
dos usurios. A seguir, so apresentadas as etapas
da abordagem que constituram o estudo de caso
efetuado para avaliar a qualidade de software segundo
a percepo dos usurios. Os resultados obtidos
esto descritos em cada fase.
Identificao de uma equipe de desenvolvimento
Como este artigo busca a qualidade de software
desde o incio do desenvolvimento, foi preciso
acompanhar o trabalho de uma equipe que
estivesse comeando um projeto. O estudo de
caso foi realizado na criao de software de uma
fundao situada no municpio de Campos dos
Goytacazes, Estado do Rio de Janeiro. A fundao
mantenedora de unidades de sade vinculadas
ao Sistema nico de Sade (SUS). Oobjetivo
elaborar um software que apoie as atividades de
gesto de recursos humanos (RH).
Elicitao de requisitos
A escolha das tcnicas para elicitao de requisitos
depende da equipe e das caractersticas do projeto.
Para o software em estudo foram utilizadas quatro
das tcnicas descritas anteriormente: i) entrevista
no estruturada; ii) entrevista estruturada; iii)
prototipagem rpida; iv) anlise de cenrio. Essas
tcnicas foram consideradas adequadas pela
equipe de desenvolvimento, pois permitiram
o entendimento do domnio onde o software se
insere. Uma lista inicial contendo 12 requisitos foi
identificada.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao dos requisitos

De acordo com o contexto da aplicao, os requisitos
foram atribudos a um dos cinco grupos. Um
questionrio contendo os requisitos foi elaborado de
acordo com os mtodos definidos para priorizao:
a anlise IPA (etapa de avaliao da importncia)
e o mtodo dos 100 pontos (Ver Apndice 1).
Visando obter dados confiveis e para evitar que
os usurios interferissem nas opinies alheias, os
questionrios foram aplicados individualmente a
10 pessoas que atuavam no domnio onde o software
seria implantado.
a. Priorizao dos requisitos segundo a IPA
Os usurios avaliaram a importncia de cada
requisito utilizando uma escala ordinal de 5 pontos,
cujos conceitos e valores foram denotados por: nada
importante (1), pouco importante (2), neutro (3),
importante (4) e muito importante (5). Para cada
requisito, a tabela 1, a seguir, apresenta a frequncia
de atribuio dos julgamentos s categorias da
escala de avaliao de importncia da IPA, a
mdia da importncia e a ordem de importncia
(prioridade). Orequisito 1.1 (registro de frequncia)
foi considerado mais importante (ordem de
prioridade 1). J o requisito 5.2 (solicitao e entrega
de declaraes) foi considerado o menos importante.
Alm disso, nota-se uma tendncia relacionada
aplicao da IPA: os avaliadores tendem a atribuir
altos valores de importncia para os itens. Esta
tendncia tambm foi notada por Ainin e Hisham
(2008) e Duke (2002).
b. Priorizao dos requisitos segundo o mtodo
dos 100 pontos
Cada usurio distribuiu 100 pontos, atribuindo
pontuao maior aos requisitos considerados mais
importantes. A tabela 2, a seguir, apresenta a mdia
das pontuaes para cada requisito. Assim como o
resultado obtido por meio da IPA, o requisito 1.1
foi o de maior prioridade.

167

Aline Gomes Cordeiro / Andr Lus Policani Freitas

TABELA 1
Importncia mdia dos requisitos segundo a IPA

A utilizao de dois mtodos resultou em duas

listas distintas de requisitos priorizados, conforme
observado no quadro 3, a seguir. possvel afirmar
que o requisito mais relevante est relacionado
necessidade de controle de frequncia dos
funcionrios da instituio. Para os demais itens,
houve variao em relao prioridade. O resultado
pode ser explicado pelo fato de alguns usurios
terem julgado aspectos como muito importante.
No entanto, no mtodo dos 100 pontos, eles
forneceram julgamentos diferenciados. Vale ressaltar
que o esforo cognitivo para o julgamento pelo
mtodo dos 100 pontos pode ser considerado maior
do que o necessrio para a escolha de uma das
categorias da escala ordinal de importncia. Neste
caso, onde h divergncia, recomenda-se a utilizao
do resultado do mtodo dos 100 pontos.
Desenvolvimento
O desenvolvimento se deu tendo como referncia
a lista de requisitos. Aevoluo do processo foi
acompanhada pelos usurios que validaram as
funcionalidades, sugeriram melhorias e identificaram
possveis erros. Como a metodologia utilizada
pelo projeto em questo o desenvolvimento
168

iterativo incremental, os usurios tiveram acesso aos

requisitos identificados gradativamente e puderam
iniciar o uso do software pelos aspectos considerados
mais importantes.
Aps o desenvolvimento do software ou aps
a realizao de vrias iteraes, sugere-se que
seja verificado por um checklist se os requisitos
prioritrios foram atendidos. S aps tal verificao
deve-se implantar e avaliar o desempenho do software,
visto que a ausncia de requisitos prioritrios pode
causar insatisfao nos usurios, o que prejudicial
para o projeto como um todo.
Para a realizao do checklist, utilizou-se o rol
de requisitos definidos a partir do mtodo dos
100 pontos. Apenas os itens 5.1 e 5.2 no foram
observados, por uma deciso gerencial. Os gestores
perceberam, em reunies com os usurios, que as
necessidades relativas a esses requisitos no estavam
no contexto de aplicao do software (tratam de
aspectos relativos a vrios setores e no apenas aos
setores ligados aos recursos humanos). Vale destacar
que esses requisitos no foram considerados
prioritrios pelos usurios.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

TABELA 2
Resultados da distribuio dos 100 pontos

QUADRO 3
Lista de requisitos priorizados

Implantao

Avaliao de desempenho

A primeira verso do software entregue aos usurios

foi disponibilizada no dia 23 de outubro de 2008,
mas eles comearam a utilizar o sistema no dia 12 de
janeiro de 2009. O atraso est associado limitao
de funcionrios no setor. Entre outubro de 2008 e
outubro de 2009 ocorreram aproximadamente 150
atualizaes no software. Destas, 64 foram externas
(percebidas pelos usurios e, em alguns casos,
derivadas de solicitaes de usurios).

Elaborou-se um questionrio composto pela lista

de requisitos desenvolvidos (Apndice 2) e que
permitiu o uso da escala contnua e da anlise IPA
(avaliao de desempenho). O questionrio foi
aplicado a 14 usurios em outubro de 2009, ou seja,
um ano aps o questionrio de priorizao.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

169

A experincia dos usurios em relao ao software

uma caracterstica que influencia a capacidade de
avaliar o desempenho luz dos requisitos. Neste
sentido, foram considerados os registros das aes

Aline Gomes Cordeiro / Andr Lus Policani Freitas

de insero, excluso e alterao realizadas por

usurio, a partir de determinado computador, alm
da data e hora de ocorrncia.
A Anlise dos Quartis, proposta por Freitas,
Manhes e Cozendey (2006) foi utilizada para
classificar os usurios em relao quantidade de
aes realizadas. A tcnica usa a medida de posio
denominada Quartil para atribuir itens em quatro
nveis de prioridade de interveno (crtica, alta,
moderada ou baixa) e empregada com sucesso
em diversos estudos (Freitas, Rodrigues e Costa
(2009) e Freitas, Bolsanello e Viana (2008), por
exemplo), o que motivou sua utilizao. Os Quartis
so interpretados como valores de fronteira, ou
seja, valores que separam cada nvel de prioridade.
Neste estudo, usurios que realizaram aes em
menor quantidade do que o primeiro Quartil
foram descartados (figura 3). Dos 14 questionrios
respondidos, 10 foram considerados.
a. Avaliao de desempenho segundo a IPA
Os usurios avaliaram o desempenho de cada
requisito utilizando uma escala ordinal de 5 pontos
cujos valores e conceitos foram denotados por
muito ruim (1), ruim (2), neutro (3), bom (4) e
muito bom (5). Para cada requisito, a tabela 3, a
seguir, apresenta a frequncia dos itens da escala de
julgamentos da avaliao de desempenho da IPA, as
mdias de desempenho e a ordem de prioridade. O
requisito 2.1 obteve a maior mdia de desempenho
(ordem 1). Os requisitos 1.2, 3.2 e 4.2 tiveram as
menores mdias.

Para identificar os requisitos crticos por meio da IPA,

as anlises de importncia e desempenho devem ser
feitas em conjunto. Assim como no estudo realizado
por Hudson et al. (2004), as avaliaes de importncia
e desempenho da IPA foram feitas em momentos
distintos. A tabela 4, a seguir, mostra as mdias para
cada requisito.
Segundo Magal e Levenburg (2005), a interseo
dos eixos da matriz IPA pode ser definida a partir
das mdias globais de importncia e desempenho.
Aqui, essas mdias foram, respectivamente, 4,52 e
3,74. A figura 4, a seguir, apresenta a matriz IPA,
na qual cada requisito est representado por um
smbolo de acordo com o quadrante onde se situa.
Os requisitos 1.1 e 2.1 esto posicionados no
quadrante manter o bom trabalho. So requisitos
prioritrios, mas apresentam bom desempenho
segundo a percepo dos usurios. Nessas
circunstncias, aes de melhoria nesse conjunto
no so prioritrias.
Os requisitos 2.2, 3.3 e 4.1 se situam no quadrante
possvel excesso. So aspectos menos urgentes
na avaliao de importncia, mas que tiveram bom
desempenho. A localizao nesse quadrante indica
que recursos podem estar sendo alocados aos itens
de forma indevida, ou seja, os mesmos recursos
poderiam ser usados para melhorar o desempenho
de itens prioritrios. No entanto, neste estudo, os
requisitos j foram desenvolvidos e os recursos j
foram empregados.

FIGURA 3
Classificao dos usurios segundo a quantidade de aes realizadas (Anlise dos Quartis)

170

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

TABELA 3
Desempenho mdio dos itens segundo a Anlise Importncia-Desempenho (IPA)

TABELA 4
Mdias de importncia (I) e desempenho (D) para os requisitos

Os requisitos 1.2, 3.1, 3.2 e 4.2 possuem baixa

prioridade porque, comparados aos demais,
possuem menor importncia e baixo desempenho.
Apenas o requisito 1.3 est posicionado no
quadrante concentrar aqui, onde as necessidades
de melhoria so prioritrias. No entanto, preciso
notar que outros requisitos esto situados bem
prximos a esse quadrante (requisitos 1.2, 3.1,
3.2 e 4.2). Sugere-se que esses requisitos sejam
cuidadosamente observados, pois um pequeno
aumento na importncia tambm os deslocaria para
o quadrante de aes prioritrias.
b. Avaliao de desempenho segundo a escala
contnua
A escala contnua representada por uma reta cujos
valores possveis variam de zero (muito ruim) a cem
pontos (muito bom), onde os usurios marcaram
Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

um valor representativo da sua percepo

acerca do desempenho do software luz de cada
requisito (Apndice 2). A tabela 5, a seguir, traz
o desempenho mdio de cada requisito. Com os
resultados obtidos pela matriz IPA, nota-se que os
requisitos 1.2, 3.1, 3.2 e 4.2, situados prximos ao
quadrante concentrar aqui tambm tiveram as
piores mdias pela escala contnua. Entretanto, o
requisito 1.3, que segundo a matriz IPA necessita
de aes urgentes, na escala contnua o quinto
em ordem de prioridade. Apesar disso, para
planejamento das aes de melhoria, recomenda-se
considerar crticos os cinco requisitos.
Definio e execuo das melhorias para os
requisitos crticos
A tcnica 5W1H foi utilizada para identificar
possveis aes de melhoria para os requisitos
171

Aline Gomes Cordeiro / Andr Lus Policani Freitas

FIGURA 4
Matriz de Anlise Importncia-Desempenho

crticos. A exemplo do mtodo utilizado por Dantas

et al. (2005), utilizou-se um sistema de controle de
verses para a coleta das informaes necessrias
para compor o 5W1H. O quadro 4 apresenta
aes de melhorias referentes aos requisitos 1.2
e 3.1. Acoluna o que representa possibilidades

de melhoria ou correo de erros identificados.

A coluna por que justifica a necessidade de
implementao da correo. A coluna quando
identifica a data de identificao da necessidade
de alterao. A coluna quem indica quem
identificou a ao a ser realizada - identificam-se

TABELA 5
Mdias de desempenho obtidas pela escala contnua

172

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

os desenvolvedores pela letra D e os usurios

por U. Finalmente, a coluna como descreve
resumidamente como a alterao deve ser feita.
Para o requisito 1.2 foram percebidas apenas duas
possibilidades de melhorias. As alteraes necessrias
no requisito 3.1 caracterizam-se por intervalos de
tempo relativamente longos (dois meses) para
identificar as aes. Esta pode ser considerada uma
caracterstica negativa porque revela que os usurios
no utilizaram o requisito nesse perodo.
Nova avaliao de desempenho
No caso do software em questo, nova avaliao de
desempenho pode ser feita aps a execuo de todas
as aes de melhoria identificadas.

Anlise segundo a Gerncia do

Projeto
Uma reunio foi realizada com o intuito de notar
a opinio do gerente do projeto a respeito dos
resultados obtidos. Destacam-se as seguintes
consideraes:
Discordncia em relao aos resultados de
dois requisitos: Segundo o gerente, o requisito
3.1 (emisso de crachs) tem desempenho muito
bom, atende s necessidades dos usurios, no
apresenta falhas e, por conseguinte, o sistema agiliza
o processo de emisso de crachs. No entanto, o
processo de negcio relativo a esse requisito mostra
algumas dificuldades. Os usurios confundem isso
e associam as dificuldades ao sistema. J o requisito
4.1 (controle de frias) mais importante do que os

QUADRO 4
5W1H para os requisitos 1.2 e 3.1

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

173

Aline Gomes Cordeiro / Andr Lus Policani Freitas

usurios avaliaram, visto que se trata de um processo

bastante complexo e bsico para o funcionamento
da instituio. Alm do mais, h o que melhorar
nesse item. Logo, o desempenho do requisito seria
pior do que o informado pelos usurios.

desejados pelos usurios. Considerando essa

dificuldade, este artigo apresentou uma abordagem
metodolgica para avaliar a qualidade de produtos
de software desde as fases iniciais, tendo sempre como
foco a percepo dos usurios.

Dificuldade em seguir as prioridades:

Apriorizao dos requisitos essencial para o
desenvolvimento de software porque os desenvolvedores
podem focar nos requisitos mais importantes. Porm,
na instituio onde o estudo foi realizado existem
usurios de diferentes nveis gerenciais. O diretor da
fundao, por exemplo, pode determinar que um item
seja visto primeiro, e solicitaes desse tipo precisam
ser atendidas. Por esse motivo, nem sempre possvel
seguir exatamente a ordem de prioridades apontada
pelos usurios.

Acredita-se que a satisfao dos usurios seja

preponderante para o sucesso de um projeto de
e a continuidade de utilizao de um software. Por
isso, a abordagem buscou o alinhamento entre as
necessidades dos usurios e o software criado. Esperase que essa abordagem permita aumentar as chances
de sucesso dos projetos de desenvolvimento e elevar
a qualidade dos produtos de software.

Relao de dependncia entre usurios e

sistema: A priorizao dos requisitos de acordo
com a percepo dos usurios permite que tenham
contato com requisitos importantes desde o incio,
o que de certo modo possibilita que estabeleam
uma relao de dependncia com o sistema. Essa
caracterstica pode ser considerada relevante para a
continuidade do projeto de elaborao do software.
Dependncia entre requisitos: A dependncia
entre os requisitos pode ser ressaltada como
um fator que dificulta a aplicao da abordagem
metodolgica. Ou seja, como desenvolver o
requisito A prioritrio, se para ele funcionar o
requisito B deve estar pronto? Neste caso, os
criadores tendem a desenvolver logo o requisito B.
Para seguir as prioridades em situaes desse tipo,
necessrio atender basicamente os requisitos menos
prioritrios, inserindo posteriormente regras de
negcio, por exemplo.
Consideraes Finais
Um dos maiores problemas relatados na literatura a
respeito dos projetos de desenvolvimento de software
refere-se a sua no conformidade aos requisitos
174

O estudo objetivou verificar a viabilidade de

aplicao da abordagem proposta. A partir dessa
aplicao, conclui-se que possvel us-la em
projetos de desenvolvimento de software de pequeno
porte. Os resultados sugerem a obteno de dois
benefcios:
a) priorizao dos requisitos com base na percepo
dos usurios do software, permitindo que os
desenvolvedores tivessem uma base metodolgica
para conduzir o trabalho de desenvolvimento, tendo
como referncia os requisitos mais relevantes de
acordo com a percepo dos usurios, e;
b) estabelecimento de um mtodo para avaliar o
desempenho do software, tendo como critrios os
requisitos funcionais, importantes para percepo
dos usurios em relao ao software. Em geral, os
usurios criam expectativas relacionadas a esse
tipo de requisito. Aes foram sugeridas visando
melhoria contnua do software.
Entretanto, algumas dificuldades e limitaes foram
encontradas. A principal delas refere-se ao fato
de que nem sempre so os desenvolvedores que
decidem a ordem de atendimento dos requisitos.
Ou seja, influncias externas podem impedir que os
responsveis sigam exatamente a lista de requisitos
priorizada.
Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

Por tratar-se de um estudo de caso, os resultados

so especficos para o contexto onde a aplicao
foi feita. Por exemplo, no possvel afirmar que
em um projeto de grande porte os resultados sero
satisfatrios. Alm disso, as equipes participantes
(desenvolvedores e usurios) foram reduzidas
(amostras pequenas), o que restringe a realizao
de anlises estatsticas mais elaboradas. Contudo,
buscou-se envolver todos os usurios do setor cliente.
Em relao aos mtodos utilizados, segundo Duke
e Mount (1996), a matriz de anlise importnciadesempenho possui como limitao a falta de testes
de significncia estatstica.
Por fim, uma das caractersticas do desenvolvimento
de software a capacidade de os requisitos mudarem,
seja por fatores externos ou internos. Essas
alteraes podem dificultar a etapa de priorizao
dos requisitos, caracterizando-se como mais uma
dificuldade enfrentada pela abordagem proposta e
tcnicas correlatas.

BABAR, M. I.; RARNZAN, M.; GHAYYUR, S. A. K.

Challenges and Future Trends in Software Requirements
Prioritization. In: COMPUTER NETWORKS
AND INFORMATION TECHNOLOGY
INTERNATIONAL CONFERENCE (ICCNIT11),
2011. Proceedings... p. 319-324.
BELGAMO, A.; FABBRI, S.; MALDONADO,
J. C. Avaliando a qualidade da tcnica GUCCRA
com tcnica de inspeo. In: WORKSHOP ON
REQUIREMENTS ENGINEERING, 7., 2005,
Porto. Proceedings
BERANDER, P. Prioritization of Stakeholder Needs
in Software Engineering Understanding and Evaluation.
Thesis (Licentiate of Technology in Software
Engineering) - Department of Systems and Software
Engineering, Blekinge Institute of Technology,
Sweden, 2004, 172p.

Agradecimentos

BERTRN, I.M. Avaliao da qualidade de software

com base em modelos UML. Dissertao (Mestrado)Depar tamento de Infor mtica, Pontifcia
Universidade Catlica do Rio de Janeiro, Rio de
Janeiro, 2009.

Os autores agradecem o apoio concedido pelo

Conselho Nacional de Desenvolvimento Cientfico
e Tecnolgico (CNPq).

BOEHM, B.W. Seven basic principles of software

engineering. The Journal of Systems and Software. v. 3.
p. 3-24, 1983.

Data de submisso: 26-10-2010

Data de aceite: 12-07-2012

Referncias
AININ, S.; HISHAM, N.H. Applying ImportancePerformance Analysis to Information Systems:
An Exploratory Case Study. Journal of Information,
Information Technology, and Organizations, v. 3, p. 95103, 2008.
ALLEN, J.H.; BARNUN, S.J.; ELLISON, R.J.;
MCGRAW, G.; MEAD, N.R.. Software security
engineering: a guide for project managers. Upper
Saddle River, NJ : Addison-Wesley. 2008. 368 p.
Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

BOENTE, A.N.P.; MOR, J.D. Um modelo Fuzzy

para avaliao da satisfao dos gerentes de projetos
de produtos de software de uma fundao pblica
estadual. In: ENCONTRO NACIONAL DE
ENGENHARIA DE PRODUO, 29., Salvador,
2009.
CORDEIRO, A.G.; MOLL, R.N. Pesquisa de
satisfao de usurios de software de gesto
hospitalar utilizando os critrios da ISO 9126.
In: X CONGRESSO BRASILEIRO D E
INFORMTICA EM SADE, 10., Anais...
Florianpolis, 2006.
CORDEIRO, A.G.; FREITAS, A.L.P. O cenrio
atual da qualidade de software. In: SIMPSIO DE
ENGENHARIA DE PRODUO, 15., Anais...
Bauru, 2008.
175

Aline Gomes Cordeiro / Andr Lus Policani Freitas

COUGHLAN, J.; MACREDIE, R.D. Effective

communication in requirements elicitation: a
comparison of methodologies. Requirements
Engineering, v. 7, p. 4760, 2002.
DANTAS, C.R.; MURTA, L.G.P.; WERNER,
C.M.L. Consistent evolution of UML models
by automatic detection of change traces. In:
EIGHTH INTERNATIONAL WORKSHOP ON
PRINCIPLES OF SOFTWARE EVOLUTION
(IWPSE05), 2005. Proceedings..., 2005, p. 14-147.
DENNING, P.J. What is software quality.
Communications of ACM, v. 35, n. 1, 1992.
DUKE, C.R.; MOUNT, A.S. Rediscovering
performance-importance analysis of products.
Journal of Product & Brand Management, v. 5, n. 2, p.
43-54, 1996.
DUKE, C.R. Learning outcomes: comparing student
perceptions of skill level and importance. Journal of
Marketing Education, v. 24, p. 203-217, 2002.
FREITAS, A.L.P.; MANHES, N. R. C.;
COZENDEY, M. I. Emprego do SERVQUAL na
avaliao da qualidade de servios de tecnologia
da informao: uma anlise experimental. In:
ENEGEP, 26., 2006. Anais... 2006. p. 1-8.
FREITAS, A.L.P.; RODRIGUES, S.G.; COSTA,
H.G.. Emprego de uma abordagem multicritrio
para classificao do desempenho de instituies
de ensino superior. Ensaio: aval.pol.pbl.Educ. v.17,
n. 65, p. 655-674, 2009.
FREITAS, A.L.P.; BOLSANELLO, F.M.C.; VIANA,
N.R.N.G. Avaliao da qualidade de servios de uma
biblioteca universitria: um estudo de caso utilizando
o modelo Servqual. Cincia da Informao, v. 37, n. 3,
p. 88-102, 2008.
GAROFALAKIS, J.; STEFANI A.; STEFANIS,
V. A framework for the quality evaluation of
B2C M-Commerce services. International Journal of
Handheld Computing Research., v. 2, n. 3, p. 73-91, 2011.

176

G O U S I O S , G . ; K A R A K O I D A S , V. ;
STROGGYLOS, K.; LOURIDAS, P.; VLACHOS,
V.; SPINELLIS, D. Software quality assessment
of open source software. In: PANHELLENIC
CONFERENCE ON INFORMATICS, PCI 2007,
11th., Athens, 2007. p. 303315
HUDSON, S.; HUDSON, P.; MILLER, G.A. The
measurement of service quality in the tour operating
sector: a methodological comparison. Journal of
Travel Research, v. 42, p. 305-312, 2004.
JANZEN, D.S.; SAIEDIAN, H. Does test-driven
development really improve software design quality?
IEEE Software, v. 25, n 2, p. 77-84, 2008.
JUNG, H. Validating the external quality
subcharacteristics of software products according
to ISO/IEC 9126. Computer Standards & Interfaces,
v. 29, p. 653-661, 2007.
KARLSSON, J.; RYAN, K. Supporting the selection
of Software Requirements. In: INTERNATIONAL
WORKSHOP ON SOFTWARE SPECIFICATION
AND DESIGN (IWSSD 96), 8th. Proceedings
1996, p. 146-149.
KARLSSON, J.; WOHLIN, C.; REGNELL, B.
An evaluation of methods for prioritizing software
requirements. Information and Software Technology. v.39,
p. 939-947, 1998.
KOSCIANSKI, A.; SOARES, M.S. Qualidade de
software: aprenda as metodologias e tcnicas mais modernas
para o desenvolvimento de software. 2. ed., So Paulo:
Novatec, 2007. 395 p.
LARMAN, C. Utilizando UML e padres: uma introduo
anlise e ao projeto orientado a objetos e ao Processo Unificado.
2. ed., Porto Alegre: Bookman, 2004. 607p.
LARSEN, T.J. A multilevel explanation of enduser computing satisfaction with an enterprise
resource planning system within an international
manufacturing organization. Computers in Industry,
v. 60, n. 9, p. 657-668, 2009.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

LEEWORTHY, V.R.; WILEY, P.C. Importance and

satisfaction ratings by recreating visitors to the Florida Keys/
Key West. The University of Georgia, 1996. 27p.

ROBERTSON, S.; ROBERTSON, J. Mastering

the requirements process. 2. ed., Addison Wesley
Professional. 592 p. 2006.

LEFFINGWELL, D.; WIDRIG, D. Managing

Software Requirements. Addison Wesley, 1999. 528 p.

ROSQVIST, T.; KOSKELA, M.; HARJU, H. Software

quality evaluation based on expert judgement. Software
Quality Journal. v.11, n. 3955, 2003.

MAGAL, S.R.; LEVENBURG, N.M. Using

importance-performance analysis to evaluate
e-business strategies among small businesses. In:
HAWAII INTERNATIONAL CONFERENCE
ON SYSTEM SCIENCES, 38th, 2005. Proceedings
MAGALHES, A.L.C. A Garantia da qualidade e
o SQA: sujeito que ajuda e sujeito que atrapalha.
ProQualiti Qualidade na produo de software, v. 2, n.2,
p. 9-14, 2006.
MAIDEN, N.A.M.; RUGG, G. ACRE: selecting
methods for requirements acquisition. Software
Engineering Journal, v. 11, n. 3, p. 183-192, 1996.
MALHOTRA, N. Pesquisa de Marketing: uma orientao
aplicada. 4. ed., Porto Alegre: Bookman, 2006. 720p.
MARTILLA, J.A., JAMES, J.C. Importanceperformance analysis. Journal of Marketing, n.9,
p.41-77, 1977.
PRESSMAN, R.S. Engenharia de Software. 5. ed., Rio
de Janeiro: McGraw-Hill, 2002. 843p.
PUNTER, T.; KUSTERS, R.; TRIENEKENS,
J.; BEMELMANS, T.; BROMBACHER, A. The
w-process for software product evaluation: a
method for goal-oriented implementation of the
ISO 14598 standard. Software Quality Journal, v. 12,
p. 137158, 2004.

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

SADRAEI, E.; AURUM, A.; BEYDOUN, G.;

PAECH, B. A field study of the requirements
engineering practice in Australian software industry.
Requirements Engineering. v. 12, p.145-162, 2007.
SAINI, R.; DUBEY, S. K.; RANA, A. Analytical
study of maintainability models for quality
Evaluation. Indian Journal of Computer Science and
Engineering, v. 2, n. 3, p. 449-454, 2011.
SKOK, W.; KOPHAMEL, A.; RICHARDSON,
I. Diagnosing information systems success:
importanceperformance maps in the health club
industry. Information & Management, v. 38, p. 409419, 2001.
SRIVASTAVA, P. R.; KUMAR. S; SINGH, A.P.;
RAGHURAMA, G. Software testing effort: an
assessment through fuzzy criteria approach. Journal
of Uncertain Systems. v.5, n. 3, p. 183-201, 2011.
YOUNG, R.R. The requirements engineering handbook.
Boston: Artech House, 2004. 251 p.

177

Aline Gomes Cordeiro / Andr Lus Policani Freitas

APNDICE 1
Questionrio de priorizao de requisitos

178

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

Priorizao de requisitos e avaliao da qualidade de software segundo a percepo dos usurios

APNDICE 2
Questionrio de avaliao de desempenho com base nos requisitos

Ci. Inf., Braslia, DF, v. 40 n. 2, p.160-179, maio/ago., 2011

179