Wellington Vasconcelos - Priorização de requisitos

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Instituto Tércio Pacitti de Aplicações e Pesquisas Computacionais - NCE
WELLINGTON GOMES DE VASCONCELOS
PRIORIZAÇÃO DE REQUISITOS VISANDO OBTER RETORNO DE
INVESTIMENTO
Rio de Janeiro
2013

ii
WELLINGTON GOMES DE VASCONCELOS
PRIORIZAÇÃO DE REQUISITOS VISANDO OBTER RETORNO DE
INVESTIMENTO
Monografia apresentada ao Instituto Tércio Pacitti
de Aplicações e Pesquisas Computacionais da
Universidade Federal do Rio de Janeiro, como parte
dos requisitos necessários à conclusão do curso de
especialização em Gerência de Desenvolvimento de
Sistemas Distribuídos com ênfase em Internet
(IS-Expert ).
Orientador: Rodrigo Toledo
Rio de Janeiro
2013

iii
AUTORIZAÇÃO
WELLINGTON GOMES DE VASCONCELOS, autorizo o Instituto Tércio Pacitti de
Aplicações e Pesquisas Computacionais (NCE) da UFRJ a divulgar total ou parcialmente a
presente monografia através de meio eletrônico e em consonância com a orientação geral do
SiBI.
Rio de Janeiro, 27/11/2013.
Assinatura

iv
RESUMO
Este estudo demonstra que a priorização de requisitos que agregam maior valor de
acordo com as necessidades dos usuários pode resultar em maior retorno de investimento.
Porém, muitas vezes, ocorre de um investimento em uma solução que não atende ao que
realmente era esperado. Desta forma, o sistema não possui os processos definidos de acordo
com a necessidade do negócio da organização. Um erro nas fases iniciais do processo de
desenvolvimento de software reflete uma análise de requisitos mal sucedida, na qual resultará
na produção de um software que não atende às expectativas dos stakeholders. O objetivo deste
trabalho é apresentar maneiras para avaliar requisitos, priorizando os que mais impactam, de
forma a atender as principais necessidades dos usuários e visando maior grau de retorno de
investimento. Então, o estudo, se divide os módulos de dois sistemas em dois tipos:
arquiteturais e pequenos conjuntos de funcionalidades que agregam valor. Então, juntamente
com a técnica de priorização Buy a Feature e também de análise de projetos visa responder a
seguinte questão: Como atender as necessidades e expectativas de stakeholders para retorno
de investimento através de priorização de requisitos que possuem maior valor na criação de
um sistema computacional?
Palavras-chave: Priorização de Requisitos, ROI, Retorno de Investimento, Buy a Feature

v
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................................6
1.1 CARACTERIZAÇÃO DO PROBLEMA ..............................................................................................6
1.2 RELEVÂNCIA......................................................................................................................................8
2 REFERENCIAL TEÓRICO ..................................................................................................................... 11
2.1 REQUISITOS ...................................................................................................................................... 11
2.2 ENGENHARIA DE REQUISITOS ..................................................................................................... 12
2.3 PRIORIZAÇÃO DE REQUISITOS..................................................................................................... 14
2.4 BUY A FEATURE............................................................................................................................... 15
2.5 METODOLOGIAS ÁGEIS ................................................................................................................. 16
2.6 TÉCINCAS DE ANÁLISE DE PROJETOS........................................................................................ 17
3 METODOLOGIA DE PESQUISA ........................................................................................................... 20
3.1 TIPO DE PESQUISA........................................................................................................................... 20
3.2 SELEÇÃO DOS SUJEITOS................................................................................................................ 20
3.3 COLETA E ANÁLISE DE DADOS .................................................................................................... 21
4 DESCRIÇÃO DO CASO ........................................................................................................................... 22
4.1 CASO A - GPSPHONE........................................................................................................................ 22
4.2 CASO B – SISVENDAS...................................................................................................................... 23
5 ANÁLISE DO CASO ................................................................................................................................. 25
5.1 CASO A – GPSPHONE....................................................................................................................... 25
5.2 CASO B – SISVENDA ........................................................................................................................ 28
5.3 CASO A X CASO B............................................................................................................................. 30
6 CONCLUSÃO............................................................................................................................................. 32
7 REFERÊNCIAS BIBLIOGRÁFICAS...................................................................................................... 34
8 ANEXOS...................................................................................................................................................... 36
8.1 ANEXO I – ORÇAMENTO DA EMPRESA 1 .................................................................................... 36
8.2 ANEXO II – ORÇAMENTO DA EMPRESA 2................................................................................... 38

6
1 INTRODUÇÃO
O objetivo deste trabalho é demonstrar que a priorização de requisitos que agregam
maior valor de acordo com as necessidades dos usuários pode resultar em maior retorno de
investimento. Para o experimento, é apresentado um estudo onde os módulos de dois sistemas
são avaliados, segundo Denne e Cleland-Huang (2004), como arquiteturais (AE) e como
pequenos conjuntos de funcionalidades que agregam valor (MMF), juntamente com a técnica
de priorização Buy a Feature e também de análise de projetos.
Este trabalho apresenta-se subdividido em 6 capítulos:
Inicia-se com o capítulo 2 onde se descreve o referencial teórico utilizado para
entendimento dos pontos principais a serem discutidos e que levaram à motivação da
confecção desse trabalho, tais como: Requisitos de Software, Engenharia de Requisitos,
Priorização de Requisitos, Técnica de Priorização Buy a Feature, Metodologias Ágeis e
Técnicas de Análise de Projetos.
A seguir, no capítulo 3 determina a metodologia de pesquisa a ser adotada, a seleção
de sujeitos e como ocorrera a coleta de dados. Foram utilizados 4 profissionais de Tecnologia
da Informação e 2 empresa cujo suas especialidades é o desenvolvimento de projetos de
software.
No capítulo 4, foi utilizado para detalhar as descrições dos casos onde são
apresentados os dois sistemas (GPSPHONE e SISVENDA) que serviram como base para o
andamento desta pesquisa.
O capítulo 5 especifica a análise dos casos da seguinte forma: Fora pedido para os
sujeitos que avaliassem os sistemas propostos, os profissionais para priorizar os módulos dos
sistemas e as empresa para fazerem um orçamento de quanto custaria cada módulo para ser
confeccionado.
Por fim, o capítulo 6 apresenta uma conclusão sobre a pesquisa mostrando pontos
como a importância de um requisito para um software, a priorização baseada na necessidade
do cliente e demonstra a maneira de observar se um projeto possui uma taxa de retorno de
investimento que atende às expectativas dos stakeholders.
1.1 CARACTERIZAÇÃO DO PROBLEMA
Os softwares são utilizados para apoiar a tomada de decisões e também como
ferramentas que auxiliam na execução de importantes atividades e tarefas nas organizações.
Porém, muitas vezes, ocorre de um investimento em uma solução que não atende ao que

7
realmente era esperado. Desta forma, o sistema não possui os processos definidos de acordo
com a necessidade do negócio da organização. Este trabalho visa responder a seguinte
questão: Como atender as necessidades e expectativas de stakeholders para retorno de
investimento através de priorização de requisitos que possuem maior valor na criação de um
sistema computacional? Para Freitas (2011), um software deve possuir características que
contribuam para a solução de problemas e melhoria da qualidade de trabalho dos usuários,
tendo como consequência a melhoria da qualidade do serviço ou produto da empresa à qual o
software se destina. Portanto, é preciso utilizar uma forma adequada de identificar e priorizar
os requisitos, que constituem o software.
Souza e Santander (2011) afirmam que não raramente negligencia-se o processo de
elicitação, análise, validação e documentação de requisitos. Isto ocorre por inúmeros motivos
tais como falta de um processo de engenharia de requisitos bem definido, falta de
comprometimento ou valorização dos envolvidos em relação à etapa de engenharia de
requisitos, uso de técnicas e estratégias inadequadas ao contexto organizacional que norteia os
trabalhos de engenheiros e clientes, pressão do cliente para entrega rápida de uma versão do
sistema, entre outros aspectos. O que se obtém como consequência é uso de práticas que
levam ao desenvolvimento de sistemas computacionais que não atendem em sua plenitude aos
anseios dos seus clientes e usuários.
Entretanto Withall (2007) diz que os requisitos definem o problema que terá de ser
solucionado: para que o sistema é e o que ele precisa resolver. Eles não definem a solução.
Um requisito é único, um objetivo mensurável que o sistema deve solucionar. Uma
especificação de sistema é um documento informando todas as suas exigências e acrescenta o
material de apoio necessário para torná-lo legível e compreensível. Ele tem de definir todas as
funcionalidades e outras características que o sistema deverá possuir.
Para Duan et al. (2009), alguns requisitos possuem maior impacto na satisfação dos
usuários em relação ao software. Ramires (2011) define que nas fases iniciais do processo de
desenvolvimento de software, os intervenientes do processo contribuem com ideias vagas e
incompletas relativamente aos seus objetivos. É frequente não haver uma ideia clara de quais
são os requisitos desejáveis. Deste modo é difícil definir requisitos a fim de se obter um
sistema que corresponda às expectativas.
Em complemento faz-se necessário utilizar um método para padronizar a escrita dos
requisitos de software para auxiliar na comunicação interna, facilitando o reuso do
conhecimento adquirido baseado em experiências reais e que se mostra eficiente na solução

8
de problemas acidentais ou inesperados. Segundo Silva e Benitti (2011), a utilização de
padrões na área de requisitos é considerada uma solução que “agiliza” o processo de
elicitação de requisitos de software e também pode aumentar a qualidade dos documentos
gerados e, também, que padrões de requisitos têm o objetivo de estabelecer requisitos com
uma maior qualidade de escrita, isso com maior agilidade e menor esforço.
Um erro nas fases iniciais do processo de desenvolvimento de software reflete uma
análise de requisitos mal sucedida, na qual resultará na produção de um software que não
atende às expectativas dos stakeholders. O objetivo deste trabalho é apresentar maneiras para
avaliar requisitos, priorizando os que mais impactam, de forma a atender as principais
necessidades dos usuários e visando maior grau de retorno de investimento.
1.2 RELEVÂNCIA
Freitas (2011) afirma que, a elicitação de requisitos é uma das atividades que ocorre
no início do desenvolvimento de software. Erros gerados nesta atividade, se não são
corrigidos, se estendem até o final do desenvolvimento e após a verificação de cada erro,
todas as fases anteriores precisam ser refeitas.
Nuseibeh e Easterbrook (2000) entendem que a maneira como os requisitos são
levantados e gerenciados influencia diretamente no sucesso de um projeto de software e
determina a qualidade dos sistemas entregues ao cliente.
Para Cohn (2006), a terceira razão pela qual o planejamento tradicional para
desenvolvimento de software não é conduzida de forma consistente para um produto de alto-
valor é porque a descrição do plano de trabalho não é priorizada de acordo com o valor para
seus usuário e clientes. Muitos planos tradicionais pressupõem que todas as atividades
identificadas serão concluídas. Isto significa que o trabalho é normalmente priorizado e
sequenciado pela equipe de desenvolvimento. Para o autor, o planejamento deve atender as
necessidades de alto-valor que são sequenciadas e priorizadas pelo cliente, sendo definidas na
atividade de análise de requisitos.
Ramires (2004) aponta que a definição de prioridades ajuda os stakeholders a definir
as bases do sistema e a focalizar a atenção nas reuniões, especialmente se estiver associada a
uma análise de risco. A identificação explícita de requisitos prioritários ajuda igualmente os
stakeholders responsáveis pelo desenvolvimento do sistema a decidir sobre a arquitetura e a
resolver os conflitos que surjam.

9
De acordo com Karlsson e Ryan (1996) um dos maiores riscos enfrentados por
organizações que desenvolvem software está associado ao não atendimento das necessidades
e expectativas dos usuários.
Souza e Santander (2011) entendem que o ponto inicial para reduzir os problemas de
elicitação de requisitos passa pela necessidade de utilizar estratégias que permitam levantar e
analisar requisitos da forma mais efetiva possível considerando particularmente o
usuário/cliente como maior detentor do conhecimento necessário a especificação e descrição
de uma necessidade apontada pelo mesmo. Contudo, sabe-se que elicitar informações sobre
necessidades de usuários em relação a sistemas computacionais não é um processo trivial,
pois, geralmente, o usuário possui uma visão simplificada da situação, na qual, na maioria das
vezes não se tem claro os resultados esperados. Uma possível solução que diminui
consideravelmente os problemas neste processo de elicitação e análise é fazer com que o
usuário/cliente seja considerado como protagonista do processo e o trabalho do engenheiro de
requisitos seja orientado sob esta perspectiva. Quando se descreve algum requisito, seja ele
funcional ou não, o envolvido na escrita assume um compromisso maior com o processo e as
avaliações do que se está escrevendo, o que ocorre quase que instintivamente.
Cordeiro (2011) consideram que são as necessidades dos usuários que justificam o
investimento em um projeto de software, não faz sentido que o foco principal do projeto seja
outro senão a solução para essas demandas. Embora essa seja uma afirmativa lógica, a
realidade mostra que são muito comuns os objetivos de um projeto de software se distanciar
das necessidades de seus usuários. Por esta razão, as fases de elicitação e análise de requisitos
podem ser compreendidas como base para todas as outras atividades relativas ao
desenvolvimento de software.
Os requisitos são definidos durante as fases iniciais no processo de desenvolvimento
de software e são considerados descrições comportamentais ou atributos de um sistema.
Então, a partir deles são geradas especificações a serem implementadas para atender às
necessidades dos stakeholders.
Souza e Santander(2011) também apontam que efetuar uma abordagem de análise de
problema e elicitação de requisitos voltada ao stakeholder mais importante do processo, o
cliente. Sob esta perspectiva é a partir das necessidades do cliente que surge um projeto de
software. Vários trabalhos realizados na área de engenharia de requisitos apresentam modelos
de elicitação nos quais o cliente é ou deve estar comprometido com uma visão de T.I. mais
aprofundada.

10
De acordo com Hermsdorf, V. O. et al. (2011) um erro proveniente da especificação
de requisitos detectado em uma fase avançada do desenvolvimento irá exigir retrabalho, com
possibilidade de introdução de novos erros.
Com isso, percebemos que é necessário que os stakeholders usuário ou não participem
ativamente como protagonista nos processos da Engenharia de Requisitos, principalmente nas
atividades de elicitação e análise. Por sua vez, o Analista de requisitos tem de identificar,
juntamente com as partes interessadas, quais são seus requisitos prioritários, possibilitando à
equipe de desenvolvimento a criação de um produto de alto-valor que terá ótima aceitação
pelos usuários finais satisfazendo às suas necessidades.

11
2 REFERENCIAL TEÓRICO
2.1 REQUISITOS
Requisitos são configurados como as necessidades que as partes interessadas levantam
como valorosas para seu contexto e que serão implementados em um software como
funcionalidades, atributos ou alguma outra característica que ele deva contemplar. Com os
requisitos bem especificados fornece a visão de que o sistema é e sobre o que ele tem de fazer.
Young (2004) afirma que requisitos são atributos necessários em um sistema para que
ele tenha valor e utilidade para os clientes e usuários. Então, Robertson (2006) explica que os
requisitos são como algo que o produto deve fazer ou uma característica que o produto deve
ter, e que é necessário ou desejado pelos stakeholders.
Ramires (2011) entende que os requisitos são a definição de pontos de vista dos
stakeholders sobre o sistema. Estes pontos de vista entram no processo de desenvolvimento
de software e originam um conjunto de soluções.
Withall (2007) afirma que os requisitos definem o problema que terá de ser
solucionado: para que o sistema é e o que ele precisa resolver. Eles não definem a solução.
Um requisito é único, um objetivo mensurável que o sistema deve solucionar. Uma
especificação de sistema é um documento informando todas as suas exigências e acrescenta o
material de apoio necessário para torná-lo legível e compreensível. Ele tem de definir todas as
funcionalidades e outras características que o sistema deverá possuir.
Os requisitos podem ser de dois tipos:
 Requisitos funcionais: Uma parte importante que diz o sistema tem de fazer, as
atividades que o sistema está habilitado a executar.
 Requisitos não funcionais: representam um grande contexto de desempenho,
segurança, capacidade nos quais o sistema deve contemplar.
Então Withall (2010) define alguns princípios genéricos para aplicar em qualquer
ocasião de especificação de requisitos:
1. Especifica o problema, não a solução: os requisitos definem “o que, mas não
como”, não têm o papel de tentar especificar a solução ou parte dela. Essa é uma distinção
importante para não ser quebrada;
2. Especifica o problema, não o projeto: Requisitos definem o que o sistema deve
fazer: Eles são os objetivos. Um projeto é a mobilização de uma equipe em uma duração
temporária para alcançar seus objetivos.

12
3. Separa as partes formais e informais: Uma especificação de requisitos é como
um contrato que define o que os construtores e fornecedores devem entregar. Os requisitos se
constituem na parte formal da especificação: o que oficialmente o sistema deve fazer. Outras
coisas são informais.
4. Evitar repetições: Expressar cada unicamente cada item. Repetições criam
trabalhos extras e abrem oportunidades de inconsistências.
Segundo Magalhães (2006), para que um software seja considerado de qualidade é
preciso que esteja em conformidade com os seus requisitos, atenda as expectativas do cliente
e seja bem aceito por seus usuários.
2.2 ENGENHARIA DE REQUISITOS
Souza e Santander (2011) afirmam que a engenharia de requisitos tem um papel
fundamental no processo de desenvolvimento de software. Particular atenção deve ser
dedicada ao processo e técnicas utilizados para gerar especificações de requisitos não
ambíguas, consistentes e completas.
Para Cordeiro (2011) o processo é constituído por várias etapas e ações que devem ser
realizadas com o objetivo de obter um produto de software.
Withall (2010) define um par de princípios para orientar todo o processo de requisitos
ágil:
1. Distinguir problema da solução: Este princípio diz que é boa prática para
reconhecer o que fazer e como fazer separadamente e o que será priorizado. Descriminando o
que poderá ser avaliado qualitativamente e o comparar os méritos das soluções sugeridas.
2. Se encontrar um requisito, grave-o e de tal forma que alguém possa encontrá-
lo: Este princípio diz onde e em qual forma os requisitos serão guardados.
Então Sommerville e Sawyer (1997) apontam alguns problemas ao processo de
engenharia de requisitos:
 Normalmente ultrapassa o orçamento ou tempo planeado;
 As pessoas envolvidas não têm tempo/reursos suficientes para realizar as
tarefas requeridas;
 Existem queixas acerca do entendimento/conclusões do documento produzido;
 Os stakeholders que desenvolvem o sistema queixam-se de trabalho inútil
devido a erros nos requisitos;

13
 Os stakeholders que utilizam o sistema falham em usar todas as capacidades do
sistema;
 Ocorre um grande volume de pedidos de alteração logo após a entrega do
sistema aos stakeholders;
De acordo com Cordeiro (2011), um software deve possuir características que
contribuam para a solução de problemas e a melhoria da qualidade de trabalho dos usuários,
tendo como consequência a melhoria da qualidade do serviço ou do produto da empresa.
Portanto, é preciso utilizar uma maneira adequada para identificar (elicitar) e priorizar tais
aspectos, que constituem os requisitos.
Souza e Santander (2011) explicam que, considerando as boas práticas da engenharia
de requisitos, existe uma suposta agilidade no envio de e-mail ou realização de telefonema, no
qual isenta o próprio usuário do desconforto de uma análise mais aprofundada sobre o
problema. Esta falsa agilidade pode ser percebida pelas inúmeras falhas, inconsistências e
esforço extra nas empresas de desenvolvimento de software que adotam a mesma prática. E
que é necessário fazer com que o cliente realize uma descrição mais aprofundada do problema
que quer solucionar, incentivando o mesmo a envolver sua equipe no projeto podendo
mensurar com mais precisão a complexidade do trabalho a ser desenvolvido e
consequentemente entender e valorizar o trabalho de engenharia necessário para elaborar uma
solução computacional para esse problema. Com a grande possibilidade do envolvimento do
cliente no processo há dados iniciais concisos e com qualidade, os quais possibilitam reduzir
os contatos posteriores com usuários e clientes, permitindo desta forma, focar os esforços no
desenvolvimento do projeto nas fases posteriores. Para os autores, na maioria das vezes o
responsável por encaminha a solicitação de um novo projeto pode não deter todas as
informações necessárias para um novo projeto. Sendo assim, sugerem que o contato seja
induzido com perguntas objetivas direcionadas aos usuários chaves, fazendo com que a
equipe se envolva com o processo melhorando a Engenharia de Requisitos.
Em complemento Cordeiro (2011) afirma que a elicitação de requisitos tem sido
reconhecida como uma das etapas determinantes para a qualidade de software. Para Larman
(2004), requisitos são capacidades e condições às quais o sistema – e de forma mais ampla, o
projeto – deve atender. Definem também que uma elicitação ineficaz traz consequências 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 construída, as falhas decorrentes daí
podem continuar acontecendo e até mesmo se tornar mais complexas posteriormente.

14
Segundo Karlsson, Wohlin e Regnell (1998), os requisitos devem ser alocados em
diferentes versões do software e, para Berander (2004), a seleção “correta” dos requisitos que
farão parte de cada versão é a etapa principal em direção ao sucesso de um projeto ou
produto.
No entendimento de Ramires (2011), um requisito que pode ser aceito por um
stakeholder pode não ser aceito por outro. O processo de decisão na negociação envolve
procurar uma única alternativa (ponto de intersecção) dentro de um conjunto de opções
aceitáveis pelos participantes e tecnologicamente possíveis.
Para Cordeiro (2011) as técnicas de elicitação visam à identificação dos requisitos. No
entanto, devido a restrições de tempo e orçamento, pode ser difícil atender a todos os
requisitos identificados para um sistema. Os requisitos geralmente são desenvolvidos em
etapas e a priorização ajuda a definir quais devem ser implementados primeiro.
Pressman (2002) cita a necessidade de conformidade aos requisitos funcionais, aos
padrões de desenvolvimento claramente documentados e às características implícitas
esperadas de todo software profissionalmente desenvolvido. A ausência de conformidade com
os requisitos é falta de qualidade.
Logo, Ambrózio (2008) afirma que empregar a rastreabilidade de requisitos possibilita
um gerenciamento das correções e das alterações de requisitos, permitindo verificar os seus
efeitos sobre o orçamento do projeto. A rastreabilidade de um requisito consiste em identificar
e manter os artefatos que o originam, como os planos de negócios, e os artefatos originados a
partir de cada requisito, como os artefatos de desenho, de implementação e de testes.
2.3 PRIORIZAÇÃO DE REQUISITOS
Segundo Ramires (2011) estudos recentes comprovam que dos projetos de software
concluídos, apenas uma pequena parte corresponde às expectativas, tendo-se observado que o
problema se centra principalmente numa deficiente análise de requisitos. Então, Souza e
Santander informam que a engenharia de requisitos tem um papel fundamental no processo de
desenvolvimento de software. Particular atenção deve ser dedicada ao processo e técnicas
utilizados para gerar especificações de requisitos não ambíguas, consistentes e completas.
Para Cordeiro (2011) acredita-se que os requisitos priorizados podem servir como
referência para as etapas que constituem o processo de desenvolvimento de software.
A seguir serão listados alguns métodos são destacados para a priorização de requisitos:

15
 Atribuição Numérica: Através de uma escala de valores inteiros de 1 a 5, deve
ser identificado pelos stakeholders, em qual nível cada requisito corresponde;
 Métodos dos 100 pontos: Distribui-se 100 pontos para os requisitos e aos mais
importantes atribuem-se os maiores;
 Triagem de Requisitos: Define a prioridade dos requisitos, define recursos e
aperfeiçoa a probabilidade de sucesso do projeto através de subconjuntos de requisitos;
 Método AHP (Analytic Hierarch Process): Utiliza-se em casos que múltiplos
objetivos estão presentes. Usa-se a comparação por pares para calcular a importância de cada
requisito.
 Buy a Feature: Prática de priorização de histórias ou funcionalidades e consiste
em “comprar” as histórias mais importantes de um determinado produto.
Como descrito, é possível utilizar métodos para identificar os requisitos prioritários
para que seja possível atender às necessidades e expectativas dos stakeholders.
2.4 BUY A FEATURE
A técnica tem como objetivo priorizar requisitos através de uma relação de features.
Para essa lista é necessário os clientes atribua valores a cada uma delas, podendo utilizar
preços fictícios ou o real valor do custo de desenvolvimento.
Torna-se necessário para esse jogo uma reunião com vários clientes com a intenção de
motivá-los a comprar o produto, descobrir quais recursos irão satisfazê-los. Para isso, abre-se
uma negociação entre os clientes, pois, o jogo consiste em distribuir entre os eles valores que,
certamente, não será suficiente para a compra de todas as features. Assim, com a junção de
dois clientes, por exemplo, eles conseguirão comprar as desejadas e não terão como adquirir
outras. Como resultado, terá a priorização do que realmente terá valor para eles.
Sendo assim, os clientes compram as features que necessitam para próxima versão,
usando dinheiro do jogo que ele recebe. Alguns requisitos receberão um preço maior do que
um cliente possa comprá-lo, dando o incentivo para os clientes juntarem seus valores para
adquirir características mais importantes.
Escolher os requisitos corretos pode ser a diferença entre o fracasso em curto prazo ou
o sucesso em longo prazo. Esta escolha é feita, muitas vezes, pelo gerente sem envolver os
clientes interessados. Com esta técnica, os clientes ajudam a definir a solução que mais lhes
agregam valores, melhorando qualidade do produto e a satisfação do usuário.

16
2.5 METODOLOGIAS ÁGEIS
O desenvolvimento de software ágil é fundamentado nos princípios declarado no
Manifesto Ágil que foi criado pela Aliança Ágil. Segundo Cohn (2006), este manifesto foi
escrito e assinado por dezessete “lightweight methodologists", como eram chamados na
época. Em seu documento deram um nome à forma como eles estavam desenvolvendo
software e forneceram uma lista de declarações. Com isso, foram definidos quatro valores
principais:
 Os indivíduos e suas interações acima de procedimentos e ferramentas;
 O funcionamento do software acima de documentação abrangente;
 A colaboração dos clientes acima da negociação de contratos;
 A capacidade de resposta às mudanças acima de um plano pré-estabelecido
Libardi e Barbosa (2010) explicam que o Manifesto Ágil não rejeita os processos e
ferramentas, a documentação, a negociação de contratos ou o planejamento, mas
simplesmente mostra que eles têm importância secundária quando comparado com os
indivíduos e interações, com o software funcionando, com a colaboração com o cliente e as
respostas rápidas a mudanças e alterações.
Os princípios do desenvolvimento ágil estão divididos em 12 princípios:
 Garantir a satisfação do consumidor entregando rapidamente e continuamente
softwares funcionais;
 Softwares funcionais são entregues frequentemente (semanas, ao invés de
meses);
 Softwares funcionais são a principal medida de progresso do projeto;
 Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
 Cooperação constante entre pessoas que entendem do 'negócio' e
desenvolvedores;
 Projetos surgem através de indivíduos motivados, e que deve existir uma
relação de confiança.
 Design do software deve prezar pela excelência técnica;
 Simplicidade;
 Rápida adaptação às mudanças;
 Indivíduos e interações mais do que processos e ferramentas;
 Software funcional mais do que documentação extensa;

17
 Colaboração com clientes mais do que negociação de contratos;
 Responder a mudanças mais do que seguir um plano.
Para Libardi e Barbosa (2010) uma característica das metodologias ágeis é que elas
são adaptativas ao invés de serem preditivas. Dessa forma, elas se adaptam a novos fatores
durante o desenvolvimento do projeto, ao invés de tentar analisar previamente tudo o que
pode ou não acontecer no decorrer do desenvolvimento. Os autores também explicam que os
métodos ágeis utilizados para desenvolvimento de software é um diferencial que promete
aumentar a satisfação do cliente agregando maior valor ao produto final, produzindo software
alta qualidade e acelerando os prazos de desenvolvimento de projetos.
De acordo com Cohn (2006) as equipes ágeis valorizam mais o software funcionando
do que a documentação abrangente, obtendo uma versão estável, progressivamente
aumentando o produto no final de cada interação. Isto faz com que seja possível desde o
início, o feedback frequente sobre o produto e o processo. Como o software desenvolvido
cresce a cada interação, pode ser exibido para os usuários prováveis ou reais. Os comentários
destes usuários são utilizados no processo de desenvolvimento para certificar de que a equipe
está sempre trabalhando com os recursos mais bem valorizados e que esses recursos irão
satisfazer as expectativas dos usuários.
Então os processos ágeis definem adições incrementais para o software que será
envolvido por expansões graduais de um conjunto de requisitos. A especificação de requisitos
é suficiente para mostrar para o cliente que o que ele espera para o software foi entendido e
obter sua aprovação. Então, ao iniciar o desenvolvimento, especificam-se os requisitos
detalhadamente para o que é preciso.
2.6 TÉCINCAS DE ANÁLISE DE PROJETOS
Segundo Bordeuax-Rêgo (2010), o método mais utilizado para a analise de
investimento é o fluxo de caixa descontado. Ele depende da projeção dos fluxos da estimativa
de valor residual e da determinação da taxa de desconto. Diz também que, a projeção do fluxo
de caixa do projeto é a etapa fundamental do orçamento de capital. Normalmente, se
subdivide em investimento inicial e fase de operação do projeto que gera os fluxos de caixa
líquidos anuais.
Para isso é necessário conhecer os indicadores Financeiros:

18
 Janela de oportunidades: Tempo decorrido entre o início do projeto e o
momento em que o produto final do projeto tem que ser substituído por um outro mais
adequado as necessidades do mercado.
 Necessidade Total de Capital: Total de recursos financeiros necessários para
executar um projeto.
 Período de Investimento: Tempo decorrido entre o início do projeto e instante
de tempo em que o projeto não requer novas injeções de capital.
 Período de Recuperação: Tempo necessário para recuperar o capital investido.
 Período Lucrativo: Instante de tempo a partir do qual o total das receitas supera
o total das despesas.
 Taxa Mínima de Atratividade - TMA: Entende-se como Taxa de Mínima
Atratividade a melhor taxa, com baixo grau de risco, disponível para aplicação do capital em
análise. Existem várias taxas que podem ser usada para estimar a TMA e as que mais
impactam são:
o Taxa Básica Financeira (TBF);
o Taxa Referencial (TR);
o Taxa de Juros de Longo Prazo (TJLP);
o Taxa do Sistema Especial de Liquidação e Custódia (SELlC).
 Valor Presente Liquido: O valor presente de recebimentos e pagamentos
futuros descontados a uma TMA, menos o custo do investimento inicial. O VPL é uma função
decrescente da TMA, significando que quanto maior for (TMA) menor será o VPL e, por
consequência, mais difícil à viabilização de projetos, isto é, encontrar projetos com VPL > 0.
Entende-se também que o valor da taxa a ser utilizada em um processo de descapitalização do
fluxo de caixa deve ser a TMA da empresa.
 Retorno sobre investimento: É a relação entre o dinheiro ganho ou perdido
através de um investimento, e o montante de dinheiro investido.
 Taxa interna de retorno: Taxa de juros necessários para igualar o valor de um
investimento (valor presente) com os seus respectivos retornos futuros.
Invest
VPL
Invest
Lucro
ROI 
n
n
TMA
VF
TMA
VF
TMA
VF
TMA
VF
VPL
)1()1()1()1( 3
3
2
2
1
1







 
.
%)11(
120
1
InvestVPL 


0
)1()1()1( 2
2
1
1






 n
n
i
VF
i
VF
i
VF
VPLi 

19
Então Bordeuax-Rêgo(2010) afirma que o método do valor presente liquido (VPL) faz
uma comparação do investimento realizado com o valor presente de fluxo de caixa gerados
pelo projeto. Se observarmos bem, vemos que o método do payback descontado faz, período a
período, a atualização do saldo (investimento – valor presente do fluxo). Ao chegar ao final, o
saldo acumulado do payback descontado é, portanto, o próprio Valor Presente Líquido do
projeto. Os autores ainda afirmam que, VPL leva em conta todos os fluxos de caixa, e não
apenas o instante de tempo em que o saldo acumulado se torna positivo. Assim pode nos dar
uma medida de riqueza adicionada (VPL maior que zero) ou destruída (VPL menor que zero).
Em conclusão, quando o VPL é maior do que zero, o projeto pode ser aceito. Quando
VPL é igual à zero, é indiferente, podendo ser aceito ou não. Logo, se o VPL é menor que
zero, o projeto será rejeitado.

20
3 METODOLOGIA DE PESQUISA
3.1 TIPO DE PESQUISA
Em estudo sobre técnicas de priorização de requisitos, percebe-se que são abordadas,
principalmente, técnicas que trabalham com identificação das necessidades com maior valor
para os stakeholders no processo de desenvolvimento de software, porém, muitos poucos
falam de técnicas para redução de custo. Tendo em vista que a pesquisa exploratória tem
como preocupação central proporcionar maior familiaridade com o problema tornando-o mais
explícito ou construindo hipótese a cerca do tema, este trabalho se baseará no neste tipo de
pesquisa. Seu desenvolvimento terá como base material já elaborado constituído
principalmente de livros e artigos científicos.
3.2 SELEÇÃO DOS SUJEITOS
A seleção dos sujeitos foi feita no Centro de Computação da Aeronáutica e
profissional da iniciativa privada, mais precisamente do setor de desenvolvimento de
software. Então, eles são apresentados abaixo:
 Entrevistado 1: Washington Gomes de Vasconcelos, Especialista em
Engenharia de Software pela Universidade Federal de Minas que trabalha como Analista de
Sistemas Sênior na empresa ENGESOFT de Belo Horizonte;
 Entrevistado 2: Alberto Carlos El Kaid Santos, Bacharel em Ciência da
Computação e exerce a função de Chefe da Sub Seção de Testes do Centro de Computação da
Aeronáutica do Rio de Janeiro;
 Entrevistado 3: Hudson Ummen Veloso, Bacharel em Engenharia da
Computação e exerce a função de Chefe da Sub Seção de Analise do Centro de Computação
da Aeronáutica do Rio de Janeiro como Analista de Sistemas;
 Entrevistado 4: Rodrigo Santos Borges, Especialista em Gerência de Projetos
pela FGV-RJ e exerce a função de Chefe da Seção de Gerenciamento de Projetos do Centro
de Computação da Aeronáutica do Rio de Janeiro como Gerente de Projetos;
Também, para o estudo foi necessário coletar dados com empresas especializadas em
desenvolvimento de software como as seguintes:
 Empresa 1: WTD3 Informática LTDA;
 Empresa 2: MindTek – Informática & tecnologia.

21
3.3 COLETA E ANÁLISE DE DADOS
A coleta de dados será feita a partir de envio de planilhas, pelos sujeitos, onde serão
relacionados seis módulos para dois sistemas. Também serão utilizados os orçamentos das
empresas entrevistadas como base para a pesquisa de mercado. Os dados serão interpretados e
auxiliarão na identificação de técnicas para serem utilizadas na priorização de requisitos para
redução de custos e calculo de retorno de investimento.

22
4 DESCRIÇÃO DO CASO
O trabalho consiste em aplicar a técnica de Buy a Feature para a priorização de
requisitos e utilizar técnicas de análise de projetos, como VPL (Valor Presente Liquido), para
obter uma estimativa de retorno de investimento para confecção de software.
Como objeto de estudo foi definido dois sistemas diferentes e seus módulos foram
priorizados por um Analista de Sistema, um Cientista da Computação, um Gerente de Projetos
e um Engenheiro da Computação.
Os módulos são divididos em 2 tipos, segundo Denne e Cleland-Huang (2004) :
 Elementos Arquiteturais (AE): Permitem que a arquitetura seja entregue de
acordo com a demanda, reduzindo ainda mais o investimento inicial necessário para se
executar um projeto.
 Minimum Marketable Feature (MMF): De acordo com Denne e Cleland-
Huang (2004), são módulos com pequenos conjuntos de funcionalidades que podem ser
entregues de forma rápida e que criam valor para o negócio.
Para o estudo foram definidos dois sistemas:
 GPSPHONE: Software para ser utilizado como navegador GPS em celulares
com a funcionalidade de localizar amigos e serviços de assinaturas para acesso ao sistema.
 SISVENDAS: Sistema utilizado para auxilio na gerencia e tomada de decisões
de uma empresa com fins de estocar e vender produtos. Com isso o sistema faz controle de
estoque, gastos, vendas e produtos.
A coleta dos dados para a pesquisa foram enviadas, para os entrevistados, as duas
tabelas 1 e 2, citadas nos itens 4.1 e 4.2 respectivamente, referentes aos requisitos dos
sistemas em questão. Então, baseado na técnica Buy a Feature, foram disponibilizadas para
eles 100 moedas fictícias para cada sistema, nas quais, teriam de indicar quanto pagariam por
cada módulo baseando em funcionalidades que agregariam valor para seu negócio.
4.1 CASO A - GPSPHONE
Definiu-se que o software será produzido modularmente e cada entrega seria
disponibilizada em uma unidade de tempo. A tabela abaixo descreve a divisão dos módulos
necessários a serem produzidos para o sistema:
Id Tipo Nome e Descrição
Mod1 AE
Serviço de Assinatura - permite que os clientes se inscrevam e/ou cancelam
a assinatura do serviço.

23
Mod2 AE Análise de Crédito – Utilizado no Pagamento de assinaturas.
Mod3 MMF
Onde estou? - Permite aos clientes saibam a sua localização geográfica em
todos os momentos.
Mod4 MMF
Navegador - permite aos clientes escolher e seguir a melhor rota entre dois
pontos.
Mod5 AE
Grupo de Amigos - permite aos clientes criar um grupo, solicitar a adesão de
grupos existentes e cancelar uma filiação existente.
Mod6 MMF
Onde estão meus amigos? - Revela o paradeiro de pessoas que pertencem ao
mesmo grupo de familiariza.
Tabela 1: Definição dos módulos do sistema GPSPHONE
Os módulos estão dispostos na seguinte sequencia e relação de dependência:
Figura 1: Sequência de módulos do Sistema GPSPHONE
Abaixo as indicações de valores por entrevistado:
Id Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4
Mod1 30,00 5,00 20,00 20,00
Mod2 20,00 5,00 15,00 15,00
Mod3 15,00 30,00 15,00 20,00
Mod4 15,00 40,00 30,00 20,00
Mod5 15,00 10,00 10,00 15,00
Mod6 5,00 10,00 10,00 10,00
Tabela 2: Priorização de acordo com os entrevistados - GPSPHONE
4.2 CASO B – SISVENDAS
A tabela abaixo descreve a divisão dos módulos necessários a serem implementados
para o sistema:
Id Tipo Nome e Descrição
Mod1 AE Cadastro de Produtos- Registrar produtos a serem vendidos
Mod2 MMF Gerência de Estoque - Controle de Estoque de produtos disponibilizados

24
Mod3 AE Cadastro de Clientes - Registrar Clientes que efetuam compras na loja
Mod4 MMF Gerenciar Vendas - Controlar as vendas efetuadas na loja
Mod5 MMF Registro de gastos - Registro de gastos efetuados pela Loja
Mod6 MMF Fluxo de caixa - Permite ao Gerente calcular o fluxo de caixa da loja
Tabela 3: Definição dos módulos do sistema SISVENDAS
Os módulos estão dispostos na seguinte sequencia e relação de dependência:
Figura 2: Sequência de módulos do Sistema SISVENDA
Abaixo as indicações de valores por entrevistado:
Id Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4
Mod1 17,00 10,00 20,00 20,00
Mod2 16,00 20,00 20,00 25,00
Mod3 17,00 10,00 5,00 10,00
Mod4 25,00 20,00 30,00 10,00
Mod5 15,00 22,00 10,00 15,00
Mod6 10,00 18,00 15,00 20,00
Tabela 4: Priorização de acordo com os entrevistados – SISVENDA

25
5 ANÁLISE DO CASO
De acordo com a técnica de Buy a Feature, foi necessário que os entrevistados
entrassem em um consenso, pois foram utilizadas 300 moedas por sistema, mas teriam apenas
100, para cada um, para a resolução do problema. Conclui-se então que para os clientes os
módulos dos sistemas mais prioritários foram os que eles depositaram os valores maiores.
5.1 CASO A – GPSPHONE
A técnica de Buy a Feature prevê que uma reunião deveria ser feita para chegar a um
consenso sobre qual o valor de cada módulo. Para este trabalho, a tabela abaixo foi gerada
calculando a média dos valores discriminados pelos entrevistados, na qual, não interfere nos
resultados:
Id Valor
Mod1 18,75
Mod2 13,75
Mod3 20,00
Mod4 26,25
Mod5 12,50
Mod6 8,75
Tabela 5: Resultado da média dos valores dos entrevistados – GPSPHONE
O período para as entregas de cada módulo do sistema ficou definido de acordo com a
tabela que segue:
Sequência
Período de Desenvolvimento
1 2 3 4 5 6 7 8 9 10
S1
Mod 1
Mod 2
Mod 3
Mod 4
Mod 5
Mod 6
Tabela 6: Período de desenvolvimento do sistema GPSPHONE
Tendo isto, foi pedido para as empresas que fizessem uma avaliação e um orçamento
para cada módulo do sistema específico.
Abaixo as suas respostas:
 Empresa 1:
Módulos Valor

26
Mod 1 R$ 6.834,00
Mod 2 R$ 5011,88
Mod 3 R$ 7.290,00
Mod 4 R$ 9.568,13
Mod 5 R$ 4.556,25
Mod 6 R$ 3.189,38
Total R$ 36.450,00
Tabela 7: Orçamento apresentado pela empresa 1.
Então, utiliza-se a tabela criada pelos stakeholders com a priorização dos módulos
para gerar o fluxo caixa para o período de desenvolvimento. Como discriminado abaixo:
Módulo Tipo
Fluxo de Caixa
1 2 3 4 5 6 7 8 9 10
Mod3 MMF -19.136,25 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50
Mod4 MMF -9.568,13 26,25 26,25 26,25 26,25 26,25 26,25 26,25 26,25
Mod6 MMF -7.745,63 21,25 21,25 21,25 21,25 21,25 21,25 21,25
Tabela 8: Fluxo de Caixa para o sistema GPSPHONE de acordo com a empresa 1.
Utilizando os indicadores já especificados na seção 2.6 deste trabalho e, também, os
dados já descriminados pela empresa contratante, podem-se chegar aos seguintes valores que
dizem respeito do projeto:
1. Janela de Oportunidades: 10 períodos;
2. Necessidade de Capital: R$ 36.450,00;
3. Período de Investimento: Períodos de 1 ao 3;
4. Taxa de reajuste: 2,0;
5. Valor Presente Liquido para o Investimento = R$ 20.658,74
6. Valor Presente Liquido para o custo = R$ 734,54
7. Retorno de Investimento (ROI): 0,035 moeda/real;
 Empresa 2:
Módulos Valor
Mod 1 R$ 8.000,00
Mod 2 R$ 5.000,00

27
Mod 3 R$ 10.000,00
Mod 4 R$ 10.000,00
Mod 5 R$ 7.000,00
Mod 6 R$ 7.000,00
Total R$ 47.000,00
Tabela 9: Orçamento apresentado pela empresa 2
Então, utiliza-se a tabela criada pelos stakeholders com a priorização dos módulos
para gerar o fluxo caixa para o período de desenvolvimento. Como discriminado abaixo:
Módulo Tipo
Fluxo de Caixa
1 2 3 4 5 6 7 8 9 10
Mod3 MMF -23.000,00 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50 52,50
Mod4 MMF -10.000,00 26,25 26,25 26,25 26,25 26,25 26,25 26,25 26,25
Mod6 MMF -14.000,00 21,25 21,25 21,25 21,25 21,25 21,25 21,25
Tabela 10: Fluxo de Caixa para o sistema GPSPHONE de acordo com a empresa 2.
dados já descriminados pela empresa contratante, podem se chegar aos seguintes valores que
dizem respeito do projeto:
2. Necessidade de Capital: R$47.000,00;
Após a reunião de negociação dos stakeholders, gera-se o um fluxo de caixa com base
nos dados especificados pela equipe de pesquisa das empresas contratantes e, utilizando os
indicadores financeiros já especificados na seção 2.6 deste trabalho, define-se se um projeto é
viável e sua taxa de retorno de investimento (ROI).
Com isso, de acordo com o orçamento de cada empresa contatada e baseando na
analise feita pelos entrevistados, o projeto a ser executado pela primeira empresa é mais
vantajoso do que o orçado pela outra empresa, pois sua taxa de ROI é maior.

28
5.2 CASO B – SISVENDA
A técnica de Buy a Feature prevê que uma reunião deveria ser feita para chegar a um
consenso sobre qual o valor de cada módulo. Para este trabalho, a tabela abaixo foi gerada
calculando a média dos valores discriminados pelos entrevistados, na qual, não interfere nos
resultados:
Tabela 11: Resultado da média dos valores dos entrevistados – SISVENDA
Os períodos para a confecção de cada módulo do sistema ficou definido de acordo
com a tabela que segue:
Sequência
Período de Desenvolvimento
1 2 3 4 5 6 7 8 9 10
S1
Mod 1
Mod 2
Mod 3
Mod 4
Mod 5 Mod 6
Tabela 12: Período de desenvolvimento do sistema SISVENDA
Tendo isto, foi pedido para as empresas já descriminadas que fizesse uma avaliação e
um orçamento para cada módulo do sistema específico. Abaixo as suas respostas:
 Empresa 1:
Módulos Valor
Mod 1 R$ 4.187,50
Mod 2 R$ 5.112,50
Mod 3 R$ 2.625,00
Mod 4 R$ 5.312,50
Mod 5 R$ 3.875,00
Mod 6 R$ 3.937,50
Total R$ 25.050,00
Id Valor
Mod1 16,75
Mod2 20,25
Mod3 10,50
Mod4 21,25
Mod5 15,50
Mod6 15,75

29
Então, utiliza-se a tabela com a priorização dos módulos e gera-se o fluxo caixa para o
sistema.
Módulo Tipo
Fluxo de Caixa
1 2 3 4 5 6 7 8 9 10
Mod 2 MMF -9.300,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00
Mod 4 MMF -7.937,50 31,75 31,75 31,75 31,75 31,75 31,75 31,75 31,75
Mod 5 MMF -3.875,00 15,50 15,50 15,50 15,50 15,50 15,50 15,50
Mod 6 MMF -3.937,50 15,75 15,75 15,75 15,75 15,75 15,75
Tabela 14: Fluxo de Caixa para o sistema SISVENDA de acordo com a empresa 1.
dados já descriminados pela empresa contratante, o que faz-se possível chegar aos seguintes
valores que dizem respeito do projeto:
1. Janela de Oportunidades:10 períodos;
8. Necessidade de Capital: R$ 25.050,00;
 Empresa 2:
Módulos Valor
Mod 1 R$ 5.000,00
Mod 2 R$ 8.000,00
Mod 3 R$ 5.000,00
Mod 4 R$ 8.000,00
Mod 5 R$ 7.000,00
Mod 6 R$ 7.000,00
Total R$ 40.000,00

30
Então, utiliza-se a tabela com a priorização dos módulos e gera-se o fluxo caixa para o
sistema.
Módulo Tipo
Fluxo de Caixa
1 2 3 4 5 6 7 8 9 10
Mod 2 MMF
-
13.000,00
37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00 37,00
Mod 4 MMF
-
13.000,00
31,75 31,75 31,75 31,75 31,75 31,75 31,75 31,75
Mod 5 MMF
-
7.000,00
15,50 15,50 15,50 15,50 15,50 15,50 15,50
Mod 6 MMF -7.000,00 15,75 15,75 15,75 15,75 15,75 15,75
Tabela 16: Fluxo de Caixa para o sistema SISVENDA para a empresa 2
dados descriminados pela empresa contratante geram os seguintes valores que dizem respeito
do projeto:
2. Necessidade de Capital: R$40.000,00;
4. Taxa de reajuste: 2,0%;
6. Valor Presente Liquido para o Custo = R$ 695,67
Após a reunião de negociação dos stakeholders, gera-se o um fluxo de caixa com base
nos dados especificados pela equipe de pesquisa das empresas contratantes e, utilizando os
indicadores financeiros já especificados na seção 2.6 deste trabalho, define-se se um projeto é
viável e sua taxa de retorno de investimento (ROI).
Com isso, de acordo com o orçamento de cada empresa contatada e baseando na
analise feita pelos entrevistados, o projeto a ser executado pela primeira empresa é mais
vantajoso do que o orçado pela outra empresa, pois sua taxa de ROI é maior.
5.3 CASO A X CASO B
Para esta seção foi pedido para os profissionais em tecnologia da informação que
avaliassem os dois sistemas informando, ainda baseado na técnica de priorização utilizada no
estudo, com 100 moedas, por quanto comprariam cada sistema e resultou-se na seguinte
tabela:

31
Sistemas Entrevistado 1 Entrevistado 2 Entrevistado 3 Entrevistado 4 Média
GPSPHONE 40,00 58,00 30,00 45,00 43,25
SISVENDA 60,00 42,00 70,00 55,00 56,75
Tabela 17: Respostas dos entrevistados
Então, baseado nesses dados, se conclui que para os entrevistados o segundo sistema é
de maior valia do que o primeiro. Na análise dos casos A e B, chegou-se às taxas para os
melhores projetos apresentados pelas empresas de 0,035 ROI para o GPSPHONE e 0,029 ROI
para o SISVENDA.
Entretanto, se analisarmos os valores financeiros, para o segundo sistema ser melhor
investimento que o primeiro, deveria ter uma taxa de, aproximadamente, ROI 1,30 vezes
melhor do que o primeiro. Calculo este obtido através da divisão das médias do SISVENDA
pelo GPSPHONE.
Conclui-se então que para os usuários o SISVENDA é mais rentável que o
GPSPHONE, porém o seu retorno de investimento é relativamente menor do que o outro.
Porém, se ele tivesse 1,30 vezes mais retorno de investimento seria um projeto mais rentável.

32
6 CONCLUSÃO
Softwares são ferramentas que auxiliam na execução de atividades, tarefas e tomadas
de decisões em organizações. Porém, o investimento em uma solução que não atende às
expectativas dos stakeholders ocasiona perda de tempo e recursos. Para Freitas (2011), um
software deve possuir características que contribuam para a solução de problemas e melhoria
da qualidade de trabalho dos usuários, tendo como consequência a melhoria da qualidade do
serviço ou produto da empresa à qual o software se destina.
O processo de elicitação, análise, validação e documentação de requisitos por alguns
motivos como falta de processo, de comprometimento dos envolvidos, uso de técnicas
inadequadas e pressão para entregas rápidas, levam ao uso de práticas que não atendem aos
anseios de clientes e usuários.
De acordo com Withall (2007) diz que os requisitos definem o problema que terá de
ser solucionado: para que o sistema é e o que ele precisa resolver. Eles não definem a solução.
E, para Duan et al. (2009), alguns requisitos possuem maior impacto na satisfação dos
usuários em relação ao software. Erros nas fases de analise de sistemas podem impactar no
desenvolvimento do software causando defeitos em áreas principais do sistema.
Então Karlsson e Ryan (1996) um dos maiores riscos enfrentados por organizações
que desenvolvem software está associado ao não atendimento das necessidades e expectativas
dos usuários.
Cordeiro (2011) explica que as técnicas de elicitação visam à identificação dos
requisitos. No entanto, devido a restrições de tempo e orçamento, pode ser difícil atender a
todos os requisitos identificados para um sistema. Os requisitos geralmente são desenvolvidos
em etapas e a priorização ajuda a definir quais devem ser implementados primeiro.
Então, no entendimento de Ramires (2011), um requisito que pode ser aceito por um
stakeholder pode não ser aceito por outro. O processo de decisão na negociação envolve
procurar uma única alternativa (ponto de intersecção) dentro de um conjunto de opções
aceitáveis pelos participantes e tecnologicamente possíveis.
O desenvolvimento de software ágil é fundamentado nos princípios declarados no
Manifesto Ágil que foi criado pela Aliança Ágil. Libardi e Barbosa (2010) explicam que ele
não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o
planejamento, mas simplesmente mostra que eles têm importância secundária quando
comparado com os indivíduos e interações, com o software funcionando, com a colaboração
com o cliente e as respostas rápidas a mudanças e alterações.

33
Para Cordeiro (2011) acredita-se que os requisitos priorizados podem servir como
referência para as etapas que constituem o processo de desenvolvimento de software. Então,
utilizamos para este trabalho a técnica Buy a Feature é uma espécie de jogo onde se resulta na
priorização de histórias ou funcionalidades e consiste em “comprar” as mais importantes de
um determinado produto.
Então, se reúnem vários clientes com a intenção de motivá-los a comprar o produto,
descobrir quais recursos irão satisfazê-los. Para isso, abre-se uma negociação entre os clientes,
pois, o jogo consiste em distribuir entre os eles valores que, certamente, não serão suficientes
para a compra de todas as features. Assim, com a junção de dois clientes, por exemplo, eles
conseguirão comprar as desejadas e não terão como adquirir outras. A técnica tem como
objetivo priorizar requisitos através de uma relação de features. Para essa lista é necessário os
clientes atribua valores a cada uma delas, podendo utilizar preços fictícios ou o real valor do
custo de desenvolvimento.
Segundo Bordeuax-Rêgo (2010), o método mais utilizado para a análise de
investimento é o fluxo de caixa descontado. Ele depende da projeção dos fluxos da estimativa
de valor residual e da determinação da taxa de desconto.
Através dessa priorização, gera-se uma tabela com valores (em moedas) para cada
módulo de entrega que são utilizados como entradas de capital e o custo (em dinheiro) para a
produção de cada módulo, expressando a necessidade de capital a ser investido para a
execução do projeto. Então, o Valor Presente Líquido é definido para o custo e para as
entradas. Com isso, defini-se uma taxa de retorno através da unidade ROI que é obtida com a
operação moeda por dinheiro. Conclui-se que, quanto maior a taxa de ROI mais vantajoso é o
projeto.

34
7 REFERÊNCIAS BIBLIOGRÁFICAS
COHN, M. Agile Estimating and Planning. New York: Addison-Wesley, 2006.
WITHALL, S. Software Requirement Partterns. Washington D.C.: Mycrosoft Press, 2007
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em
http://agilemanifesto.org, acesso em 06/06/2013.
FREITAS, A. L. P. Priorização de requisitos para o desenvolvimento de software: uma
abordagem multicritério utilizando o método AHP. [EDITORIAL]. Produto & Produção,
vol. 12, n. 2, p. 87 - 107, jun. 2011.
DE SOUZA, C. F.; SANTANDER, V. F. A. Uma Proposta de Elicitação e Análise de
Requisitos no Contexto de Médias e Pequenas Empresas de Desenvolvimento de Software.
Anais do WER11 - Workshop em Engenharia de Requisitos, Rio de Janeiro - RJ, Brasil, p.
285-296. abr. 28-29, 2011.
CORDEIRO, A. G. Priorização de requisitos e avaliação da qualidade da qualidade de
software segundo a percepção dos usuários. [EDITORIAL]. Ciência da Informação, vol. 40,
n. 2, p. 160 – 179, mai./ago. 2011.
SILVA, R. C.; BENITTI, F. B. V. Padrões de Escrita de Requisitos: Um mapeamento
sistemático da literatura. Anais do WER11 - Workshop em Engenharia de Requisitos, Rio
de Janeiro, Brasil, p. 285-296. abr. 28-29, 2011.
RAMIRES, J. J. C. V. Negociação de requisitos no processo de desenvolvimento de
software. Lisboa, 2004. Dissertação (Mestrado em Informática). Faculdade de Ciências,
Universidade de Lisboa, Lisboa, 2004.
AMBRÓSIO, B. G. Modelagem da fase de requisitos em processos de desenvolvimento de
software: Uma abordagem utilizando dinâmicas de sistemas. Viçosa, 2008. Dissertação (Pós-
Graduação em Ciência da Computação). Universidade Federal de Viçosa, Viçosa, 2008.
HERMSDORF, V. O., et al. Modelagem da atividade de elicitação de requisitos utilizando a
técnica de entrevista: uma abordagem utilizando dinâmica de sistemas. Anais do WER11 -
Workshop em Engenharia de Requisitos. Rio de Janeiro, Brasil, p. 309 – 320. abr. 28-29,
2011.
LIBARDI, P. L. O.; BARBOSA, V. Métodos Ágeis. Limeira, 2010. Dissertação (Pós-
Graduação em Computação) Faculdade de Computação, Universidade Estadual de Campinas,
Limeira, 2010.
DUAN, C. et al. Towards automated requirements prioritization and triage.
Requirements Engineering, v. 14, p. 73–89, 2009.
PRESSMAN, R.S. Engenharia de Software. 5. ed., Rio de Janeiro: McGraw-Hill, 2002. 843p.
KARLSSON, J.; WOHLIN, C.; REGNELL, B. An evaluation of methods for prioritizing
software requirements. Information and Software Technology. v.39, p. 939-947, 1998.

35
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.
KARLSSON, J.; RYAN, K. Supporting the selection of Software Requirements. In:
INTERNATIONAL WORKSHOP ON SOFTWARE SPECIFICATION AND DESIGN
(IWSSD ‘96), 8th. Proceedings, p. 146-149. 1996.
YOUNG, R.R. The requirements engineering handbook. Boston: Artech House, p. 251.
2004.
Bordeaux-Rêgo, Ricardo. Viabilidade econômico-financeira de projetos / Ricardo
Bordeaux-Rêgo, Gorete Pereira Paulo, Ilda Maria de Paiva Almeida Spritzer, Luiz Péres
Zotes. 3 ed. – Rio de Janeiro : Editora FGV, 2010.
Denne, Mark e Cleland-Huang, Jane. Software by numbers: low-risk and High return
development, Prentice Hall, 2004.

36
8 ANEXOS
8.1 ANEXO I – ORÇAMENTO DA EMPRESA 1

38
8.2 ANEXO II – ORÇAMENTO DA EMPRESA 2

Wellington Vasconcelos - Priorização de requisitos

Recomendados

Recomendados

Más contenido relacionado

Similar a Wellington Vasconcelos - Priorização de requisitos

Similar a Wellington Vasconcelos - Priorização de requisitos (20)

Wellington Vasconcelos - Priorização de requisitos