ISSN 2316-2872

T.I.S. So Carlos, v. 3, n. 2, p. 122-130, mai-ago 2014

Tecnologias, Infraestrutura e Software

Aplicando a Metodologia gil Scrum para apoio ao

Gerenciamento de Requisitos
Felipe Luiz Carnevali, Daniel Lucrdio
Resumo: Este trabalho apresenta um estudo de caso que aplica a metodologia gil Scrum para o gerenciamento de requisitos. So levantados

os dados das quais a empresa estudada usa para realizar o seu prprio gerenciamento de requisitos. Baseando nas prticas e regras do Scrum
foi proposta uma implementao que se adeque realidade da empresa, alterando a sua forma estrutural nas responsabilidades dos
profissionais e tambm modificando o ambiente de trabalho aplicando as tcnicas citadas neste estudo de caso, focando na qualidade, prazos,
custo, agilidade e satisfao do cliente.

Palavras-Chave: Scrum, metodologia gil, requisitos.

Applying Scrum agile methodoly to support the requirements Management
Abstract: This paper presents a case study that applies Scrum agile methodology for requirements management. Data used by the studied
company to carry out its own management requirements is raised. Based on Scrum practices and rules, an implementation that fits the reality
ofthe company was proposed, changing its structural form in the responsibilities ofprofessionals and also changing the working environment
by applying the techniques mentioned in this case study, focusing on quality, deadlines, cost, agility and customer satisfaction.

Keywords: Scrum, Agile methodoly, requirements.

I. INTRODUO
Diversos estudos (LEFFINGWELL et al., 2003);
(SOMMERVILLE; SAWYER, 1997) levantaram e
comprovaram que uma grande quantidade de projetos de
software so cancelados ou simplesmente fracassam por no
atenderem totalmente s necessidades dos clientes ou
excederem prazos e oramentos propostos no contrato. Esses
problemas geralmente acontecem devido constante
mudana do mercado, o que faz com que os requisitos
mudem frequentemente. Apesar das mudanas, h grande
deficincia no levantamento dos requisitos, um dos principais
contratempos no fracasso dos projetos de software.
Com essas anlises alguns estudiosos passaram a
considerar a engenharia de requisitos incluindo todo o
processo de elicitao (coleta de requisitos), especificao,
viabilidade e validao como um fator muito importante
dentro da rea de engenharia de software. Todavia a
engenharia de software j vem sendo estudada no mundo
acadmico h mais de 40 anos (ESPINDOLA et al., 2004), e
muitos destes sistemas vem sendo utilizados at hoje.
A engenharia de requisitos uma forte candidata para
ocupar-se de responsabilidades com relao garantia,
necessidades, qualidade, prazos e oramentos que so
estimados aos clientes, bem como lidar com as dificuldades
que surgem no dia dia do desenvolvimento de sistemas.

Porm esse processo costuma ser muito rigoroso e demorado.

H algumas dcadas criaram-se algumas metodologias que
propem melhorar o andamento dos projetos, as quais so
chamadas de metodologias geis. Entre elas existem vrias
metodologias tais como Extreme Programming (XP), Feature
Driven Development (FDD), Adaptive Software
Development (ASD), Dynamic Systems Development
Method (DSDM), Scrum, Crystal Methods (CM) entre outras.
Abrahamsson et al. (2002) confirma que quanto mais de uma
metodologia gil utilizada ao mesmo tempo, melhora-se o
processo de agilidade. Entretanto, de acordo com AGILE
SURVEY (2012), duas das mais populares metodologias que
so utilizadas no contexto de metodologias geis so Extreme
Programming (XP) e o Scrum. Por esse motivo, decidiu-se
focar o estudo de caso em uma dessas, que a metodologia
gil Scrum.
O Scrum foi criado por Shwaber em 1995, com foco no
processo de gesto de projetos de software complexos.
Conforme (SCHWABER; BEEDLE, 2002), sua teoria
atender as necessidades do negcio baseando-se em sistemas
adaptativos. Schwaber e Beedle (2002) afirmam ainda que a
principal caracterstica do Scrum a comunicao entre as
equipes que participam direta ou indiretamente e no h
especificaes referentes a prticas de construo, pois o
mtodo enfatiza que as equipes sejam auto-organizadas e os
Departamento de Computao - Universidade Federal de So Carlos (UFSCar)
Caixa Postal 676 13.565-905 So Carlos SP Brasil

Autor para correspondncia:

felipe.carnevali@hotmail.com, daniel@dc.ufscar.br

Felipe Luiz Carnevali, Daniel Lucrdio

processos so orientados a objetivos e resultados.

Este trabalho apresenta uma anlise de como funciona a
engenharia de requisitos, considerando seu processo bsico, e
as prticas e regras da metodologia gil Scrum. O objetivo
desse estudo propor uma melhoria no processo de
engenharia de requisitos no contexto de uma empresa de
software localizada na cidade de Ribeiro Preto (SP), que
possui um sistema j consolidado no mercado h mais de 20
anos com uma cartela de clientes em todo o pas. Seus
processos de organizao de levantamento de requisitos
foram estudados e foi proposta uma melhoria com base nas
tcnicas, prticas e regras acadmicas citadas neste trabalho.
A seo II apresenta a composio da engenharia de
requisitos e na seo III a metodologia gil Scrum. A seo
IV apresenta o estudo de caso utilizado neste trabalho,
detalhando o contexto da empresa estudada, e a proposta
realizada para a melhoria de desempenho, utilizando-se dos
papis e prticas do Scrum com os resultados preliminares e
discusses de maior importncia para o resultado esperado. A
seo V apresenta os trabalhos relacionados e as concluses e
trabalhos futuros so descritos na seo VI.
II. ENGENHARIA DE REQUISITOS
Com a grande demanda e crescente complexidade de
software requerida, ausncia de qualidade comea a ser
percebida, pois os produtos no conseguem prover a
capacidade necessria. Atualmente utilizada a engenharia
de requisitos para sistematizar o processo de definio de
software. Essa sistematizao necessria, pois ajuda os
engenheiros de requisitos a entenderem melhor o problema.
Uma boa definio de requisitos dada por como sendo a
"condio necessria para a obteno de certo objetivo, ou

para o preenchimento de certo objetivo. Leite (1994).

A engenharia de requisitos foca no processo e se torna
responsvel pelas evidncias que mais podem causar
problemas srios, podendo ser destacadas as mudana de
requisitos e especificaes, requisitos e especificaes
incompletos e falta de engajamento do usurio
(LEFFINGWELL et al., 2000).
Os usurios esperam um sistema que atenda as suas
necessidades, tarefas e facilite o seu trabalho dirio. Os
financiadores aguardam um sistema que obtenha um retorno
adequado ao investimento fornecido. A equipe de
desenvolvimento cria expectativas em desenvolver um
sistema com qualidade, prazo e custo estipulado atendendo
todas as reais necessidades dos usurios (LEFFINGWELL et
al., 2000), porm a realidade quase sempre no atende a esses
quesitos, devido grande abrangncia em que os softwares
vm fazendo na sociedade.
A engenharia de requisitos uma atividade responsvel por
criar e manter documentos de especificaes de requisitos de
sistemas chamados DERS segundo (KOTONYA;
SOMMERVILLE, 1998). Este processo como um todo
composto por quatro grandes processos: o estudo de
viabilidade, em qual aspecto o sistema ser vivel ao negcio
a ser utilizado, a elicitao de requisitos, com a descoberta e
levantamento dos requisitos, a especificao, onde a
organizao dos requisitos apresentada em um padro e a
validao, com a descoberta e validao dos requisitos que
foram registrados e definem a necessidade que o usurio
deseja para o sistema.
Na figura 1 possvel visualizar o modelo de como
funciona o processo da engenharia de requisitos:

Figura 1 O processo de Engenharia de Requisitos segundo (KOTONYA; SOMMERVILLE, 1998)

Segundo (KOTONYA; SOMMERVILLE, 1998), este que j foram realizadas como em um espiral. Aps o estudo
processo bem flexvel, pois pode voltar s fases anteriores de viabilidade, temos as fases de elicitao, especificao e
T.I.S. 2014; 3 (2): 122-130

123

Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos

validao, que podem ser divididas em subfases.

A elicitao a fase que coleta os requisitos, dividida em
duas subfases chamadas Elicitao dos Requisitos do
Sistema,que foca no levantamento das funes e restries do
sistema de uma forma mais detalhada, e Elicitao dos
Requisitos do Usurio, onde realizado o levantamento, em
linguagem natural ou por diagramas, de quais funes que o
sistema deve fornecer e quais restries se devem operar.
A especificao composta de trs subfases: Especificao
dos Requisitos de Sistema e Modelagem, que descreve as
caractersticas de um sistema ou produto, Especificao dos
Requisitos de Usurio, que consiste em descrever as
atividades efetuadas pelos usurios na organizao que ir
utilizar o sistema, e Especificao dos Requisitos de
Negcio, que descreve em termos de negcio o que deve ser
entregue ou conseguido para fornecer valor ao sistema.
A validao dividida em trs subfases: Estudo de
Viabilidade, onde se avalia do ponto de vista organizacional e
tecnolgico se o projeto vivel, Prototipao, que uma
apresentao visual final do produto que est sendo
desenvolvido, e Revises, onde analisam sistematicamente as
especificaes produzidas para garantir que o projeto
corresponde ao que foi pretendido.
III. METODOLOGIAS GEIS
Segundo (ZANATTA, 2004), em 2001, vrios
pesquisadores denominados de "Aliana gil" (Agile
Alliance), dentre eles vrios conhecidos internacionalmente
no contexto da engenharia de software tais como Martin
Fowler, Alistair Cockuburn, Jim Highsmith, Kent Beck, Mike
Beedle entre outros, com grande experincia no mundo do
desenvolvimento de software, foram motivados a iniciar uma
discusso de como ter uma forma eficaz e rpida para se obter
produtos de software com qualidade e que atendesse as
necessidades dos clientes de forma simples. Nesta ideia
nasceu o chamado Manifesto gil que abrange essas
caractersticas, com os dizeres (AGILE MANIFESTO, 2013):
Gostaramos de descobrir como
desenvolver software e ajudar a outros a fazer
software da melhor maneira possvel
seguindo os melhores caminhos; Queremos
valorizar os seres humanos que participam
desse processo com ferramentas eficazes; O
software deve possuir uma documentao
clara, compreensiva e simples; Queremos
estar aptos s mudanas contando com a
colaborao do cliente e obtendo um feedback
atravs de uma ideia especfica.

Como qualquer processo, mtodos e prticas no

desenvolvimento de software, foram criados alguns princpios
para os mtodos geis:

A nossa maior prioridade satisfazer o cliente

atravs da entrega rpida e contnua de uma verso do
software sempre atualizada.

Alteraes sobre os requisitos mesmo sendo tardia,

sempre sero bem vindas, pois isto pode ser um diferencial

competitivo ao cliente.

Entrega de software com maior frequncia, de

preferncia a cada semana ou ms, sempre visando o menor
tempo possvel.

Os stakeholders, analista de requisitos e os

desenvolvedores trabalham juntos diariamente no projeto.

Manter uma equipe focada e motivada, aderindo

confiana e ambiente necessrio para o trabalho.

A principal comunicao da equipe que participa do

projeto baseada em uma conversa face-a-face.

A simplicidade essncia do negcio.

Software funcionando a medida principal do

progresso.

A ateno contnua a excelncia tcnica e um bom

foco no projeto mantm a agilidade.

As melhores arquiteturas, requisitos, e projetos

emergem de equipes auto-organizadas.

A equipe em intervalos regulares reflete sobre como

se tornar mais efetivo, por isso a mesma se ajusta e aperfeioa
o seu comportamento de acordo com a necessidade.

Promover a evoluo do desenvolvimento

sustentvel. Todos stakeholders devem ser capazes de manter
um ritmo constante visando sempre melhoria.
Baseando-se nestes princpios do manifesto gil, notrio
que alguns valores existentes nos mtodos atuais so e
continuam sendo muito importantes, como por exemplo, a
modelagem de dados e a documentao que so discutidas por
Fowler (2013). Porm a preocupao o excesso de papis
que so gerados com documentos que muitas vezes os
mesmos nunca sero lidos. Outro fator o planejamento, que
extremamente importante que seja utilizado, mas existe a
consequncia de limitaes em termos de organizaes,
cultura do ambiente, comunicaes entre pessoas, entre
outras.
possvel considerar os mtodos geis uma forma eficaz
para realizar o gerenciamento de requisitos, na qual
subdivido em dois aspectos bsicos (ZANATTA, 2004): ser
adaptativo ao invs de preditivo e ser orientado a pessoas ao
invs dos processos.
Existem algumas formas que se destacam nos mtodos
geis quando se fala em desenvolver um software, conforme
(BECK et al., 2000): deve ser priorizado a satisfao do
cliente, atravs da entrega rpida e contnua de software com
qualidade, deve-se alterar os requisitos de forma rpida e
eficaz, deve-se buscar um desenvolvimento sustentvel e
orientar todos que participam do projeto a praticar
simplicidade.
A) Scrum

Scrum (SCWABER; BEEDLE, 2002) um processo para

projetos que realizam desenvolvimento de software que seja
focado nas pessoas no qual o ambiente tenha uma mudana
constante nos requisitos. O Scrum pode ser tambm
considerado uma tcnica utilizada para realizar o
gerenciamento de processo para o desenvolvimento de
software.
Abrahamsson et al. (2002) relatam que a etapa de
124

TI.S. 2014; 3 (2): 122-130

Felipe Luiz Carnevali, Daniel Lucrdio

desenvolvimento do Scrum inclui as fases tradicionais que

existe no desenvolvimento de software como requisitos de
usurio e requisitos de sistema; a anlise; projeto e a entrega
final do produto, ressaltando que todas essas questes
precisam ser adaptveis durante o seu processo.
O Scrum foi inicialmente desenvolvido pelas organizaes
de software Advanced Development Methods e VMARK
Software,em meados dos anos 90, e os seus criadores foram
Ken Schawber e Jeff Sutherland com o intuito de gerenciar
projetos de software (HIGHSMITH et al., 2002).
O nome Scrum nasceu por meio de uma jogada de rugby,
que este nome dado pela disputa da bola, onde todo o time
avana, trabalhando em equipe com os seus jogadores como
se fosse um s, passando sempre a bola pra um e para outro,
para que marquem o mximo de pontos possveis. Essa a
ideia no desenvolvimento de software, justamente definir
papis bem especficos para todas as pessoas que esto
envolvidas no projeto, com o intuito que a equipe realize o
mximo de tarefas possveis para ter uma nova interao
(release) do produto final.
Sua caracterstica bsica so equipes pequenas entre 8 a 10
pessoas; os requisitos so desconhecidos ou mesmo instveis
e as interaes so em um prazo curto de tempo. O
desenvolvimento realizado em intervalos de no mximo 30
dias, denominados de Sprints. Os requisitos levantados no
Product Backlog so selecionados para serem feitos e
quebradas em tarefas para ser realizadas no Sprint, porm
essas tarefas no podem exceder o tempo de execuo de uma
semana. Caso isso ocorra necessrio que haja um novo
desmembramento naquele item. de extrema importncia
ressaltar que durante o Sprint, no h nenhuma mudana nas
tarefas que estejam em desenvolvimento.
Outra caracterstica importante o encontro dirio (Daily
Meeting) que so reunies curtas de quinze minutos
realizadas diariamente para que a equipe do projeto se
atualize de como est o andamento e que possa expor as
dvidas encontradas durante a realizaes das tarefas no
Sprint.
Este mtodo no possui ou impe nenhuma tcnica
especfica para que se realize o desenvolvimento do software,
porm so estabelecidos conjuntos de prticas e regras para
gerenciar e devem ser adotadas para que obtenha sucesso no
projeto.
IV. APLICAO DA METODOLOGIA GIL S CRUM NA
ENGENHARIA DE REQUISITOS
O estudo de caso foi realizado em uma empresa situada em
Ribeiro Preto (SP) que atua no mercado de desenvolvimento
de software h mais de 20 anos na qual o seu produto atende
clientes em todo o pas e possui um processo de
gerenciamento de requisitos que parte desde a sua entrada,
manuteno e a sada que o software pronto para o uso
final. Conforme o levantamento, no existe nenhuma
metodologia aplicada junto ao processo de gerenciamento de
requisitos, e a empresa criou o seu prprio gerenciamento
descrito mais adiante.
A empresa possui oitenta funcionrios tcnicos, seis
T.I.S. 2014; 3 (2): 122-130

funcionrios administrativos, um gerente e dois diretores.

O sistema comercializado pela empresa nico, que
alugado a clientes e cobrado por manutenes e customizao
especficas dos clientes, de acordo com as suas necessidades.
As solicitaes so implementadas e todos os clientes tm
direito do uso das funcionalidades disponveis independente
se os mesmo foram solicitados por eles.
Nessa estrutura, o processo de gerenciamento de requisitos
realizado conforme descrio a seguir:

A empresa possui um sistema pronto que

comercializado. O processo comea com a implantao desse
sistema, com as pessoas responsveis por realizar toda a
instalao e treinamento do sistema para os novos clientes que
iro utiliz-lo. Na maioria das vezes so necessrias vrias
adaptaes decorrentes da implantao. Essas adaptaes
consistem nos primeiros requisitos a serem levantados. A
equipe de implantao tambm responsvel por realizar
visitas de ps-implantao e peridicas para saber como est
satisfao do cliente com o software utilizado. Nessas visitas
tambm ocorrem solicitaes de novos requisitos.

A equipe de atendimento (help desk) realiza o

suporte, sanando dvidas e realizando configuraes que s
vezes so necessrias para o cliente utilizar o software. Essas
solicitaes podem tambm incluir novos requisitos, que
precisam ser tratados. Na maioria das vezes em que um novo
requisito entra por esta equipe trata-se de correes de
problemas ou erros inesperados no sistema.

A equipe de qualidade tambm responsvel pelo

levantamento de requisitos. Na realizao dos testes de
validao para a liberao de uma nova verso, muitas vezes
so encontrados erros pr-existentes ou falhas no processo
que podem ser relacionados com requisitos para melhoria no
sistema.
Os tipos de requisitos so avaliados de trs maneiras:

Erro: quando o sistema no funciona como esperado,

potencialmente causando problemas.

Customizao: novos requisitos que so solicitados a

pedido do cliente, geralmente para adaptao.

Melhoria: so novas funcionalidades que agregam

valor ao sistema sem gerar nenhum custo a quem realizou a
solicitao.
Esses requisitos so registrados em uma ferramenta prpria
chamada Dirio. Essa ferramenta permite que as diferentes
pessoas envolvidas no processo, tais como atendentes de help
desk, implantadores, programadores, testadores, analista de
negcios e a gerncia, que participam desde a entrada,
manuteno e sada desse requisito, consigam acompanhar
como est o andamento do mesmo. Dessa forma, todos podem
ficar cientes de quando sair uma prxima verso para
satisfazer as pendncias que so aguardadas pelos clientes.
So definidos trs tipo de requisitos, porm os requisitos de
erros no precisam passar pelo processo de engenharia de
requisitos. Esses trs itens so tratados de forma conjunta,
pois os problemas so comuns a todos. Os erros so
classificados nesse contexto para chegarem at
desenvolvimento, teste e liberao da correo do software.
Quando um novo requisito solicitado, existem duas
125

Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos

pessoas responsveis por avali-lo. Essas pessoas, que so

analistas de negcio, verificam, por exemplo, se os erros
realmente so erros ou se so apenas uma falta de
entendimento do sistema. Tambm verificam se necessrio
realizar uma customizao solicitada ou se existe outra opo
j disponvel no sistema. E decidem se melhorias solicitadas
realmente iro agregar valor para o sistema. Porm, quando
os analistas de negcios realizam esse processo so
encontradas algumas falhas.
Uma das principais falhas a falta de comunicao, que
observada atualmente na empresa. A falta de comunicao
com os clientes um dos principais problemas, podendo
resultar no levantamento de requisitos desnecessrios, e
muitas vezes causando desconforto no momento da
implementao do software. A comunicao interna tambm
escassa, pois a equipe de atendimento e implantadores, que
so os que tm maior interao com os clientes, no tm a
prtica e regra de conversarem com os analistas de negcios
ou mesmo programadores.
Os analistas de negcios conversam entre si, porm nem
sempre ambos tm o conhecimento de toda a ferramenta
completa devido falta de documentao, que outro
problema observado. Assim, quando os requisitos so
validados por eles, comum serem registrados requisitos de
melhorias, customizaes e, principalmente, correes de
erros, que no so realmente necessrios para o sistema. Se
houver uma melhor interao entre a equipe do
desenvolvimento junto aos analistas de negcio este problema
pode ser resolvido.
Alm disso, h o problema de falta de qualificao das
pessoas que levantam os requisitos. Atendentes de help desk
nem sempre so pessoas qualificadas para fazer esse tipo de
trabalho por falta de conhecimento tcnico e de negcio, o
que dificulta um pouco o processo.
Cita-se tambm o fato de que os implantadores
dificilmente ficam na empresa, pois os mesmo esto
constantemente realizando viagens de instalaes e
treinamentos. Eles so os maiores responsveis por trazerem
requisitos de customizaes, que so normalmente aqueles
que causam maior impacto. Como resultado, a comunicao
com esses profissionais tambm dificultada.
Por ltimo, a forma de conduzir os requisitos que esto
sendo implementados atualmente falha. Muitas vezes,
devido ao tempo escasso e a necessidade de alterar os
requisitos que esto sendo implementados, muitas tarefas so
abortadas e novos requisitos so implementados sem nenhum
planejamento e isso um fator prejudicial em termos da
qualidade, pois com isso podem ser gerados repetidos
requisitos de erros.
Nota-se, portanto, que h uma srie de problemas no
processo da empresa. Para tentar resolv-los, prope-se aqui a
utilizao da metodologia gil Scrum que, com a sua
facilidade de uso pode ser adaptvel a realidade da empresa.
A ideia propor solues para se obter um melhor resultado a
cada liberao de um incremento (verso release) do software
proprietrio.

A) Proposta de melhoria utilizando o Scrum

Seguindo as regras e prticas do Scrum, a principal

caracterstica a comunicao da equipe. Esta prtica se for
aplicada no caso estudado, reduziria drasticamente esta falha.
Mas tambm notria a falta de papis dentro da empresa.
Tanto a equipe de atendimento como implantadores fazem um
mesmo trabalho de levantamento de requisitos, o que pode
ocasionar problemas de responsabilidade e hierarquia. Assim
sendo, se forem atribudos os papis descritos no Scrum h
maiores chances de respeito hierarquia e senso de
responsabilidade. Isso pode tambm tornar a comunicao
mais eficaz. Muitas vezes a prpria gerncia e diretoria tm
influncia nesse tipo de problema, querendo passar requisitos
que no foram analisados como prioritrios para adquirir
novos clientes.
A. 1) Uso de papis Scrum

Na metodologia gil Scrum existem papis e

responsabilidades diferentes na qual o objetivo executar os
trabalhos durante a utilizao das prticas. Abaixo sero
descritos esses papis (SCHWABER; BEEDLE, 2002):
Product Owner - o dono do produto, geralmente um
cliente ou especialista do negcio o qual est sendo
desenvolvido. Ele defende os interesses do negcio e tem
como objetivo e responsabilidade de priorizar e manter os
itens do Product Backlog. No caso da empresa estudada, o
Product Backlog consiste no conjunto de requisitos
constantemente levantados para o sistema. Na empresa
analisada, prope-se que esse papel seja desempenhado pelos
analistas de negcios, pois so eles quem mais sabem sobre os
interesses dos requisitos e se os mesmo iro agregar valor ao
sistema.
Na prtica do Scrum, a ideia que o Product Owner seja
uma nica pessoa. Porm na empresa estudada existem
claramente dois profissionais com essas atribuies. Portanto
a proposta que o papel seja atribudo a apenas um deles por
cliente, e o outro atuar em seu auxlio. Essa pessoa
representar o cliente, sempre realizando os contatos
peridicos com a maioria deles, pois a empresa possui vrios
clientes e nem sempre os mesmos solicitam ou necessitam de
algo nas mesmas circunstncias.
Scrum Master - Este papel responsvel pela aplicao de
valores, prticas e pelo objetivo concretizado no final do
Scrum. Ele considerado como um "facilitador" das reunies
removendo os obstculos ou qualquer impedimento que
comprometa o projeto. Tambm protege a equipe fazendo com
que eles no se comprometam a realizar tarefas que o time no
pode sanar. Ele a principal chave que une o negcio e as
tecnologias e segundo (ZANATTA, 2004) suas principais
atividades so organizar as Daily Meetings, representar o
gerente do projeto e o tcnico, gerenciar todo processo Scrum
dentro da organizao, e remover os impedimentos que
comprometam o projeto.
Com o conceito definido deste papel, foi analisado que a
melhor pessoa por esse papel seria uma pessoa da gerncia ou
diretoria, pois na empresa existem dois scios e o gerente de
126

TI.S. 2014; 3 (2): 122-130

Felipe Luiz Carnevali, Daniel Lucrdio

projeto, o qual tambm faz o papel de analista de negcio.

Ambos so divididos na seguinte questo: Um diretor
responsvel pela implantao e outro responsvel pelo
desenvolvimento. O gerente de projetos faz o papel de
gerncia e de analista de negcio.
Analisando o papel do Scrum Master o que melhor se
adaptaria seria o gerente de projetos, pois ele o que tem
maior afinidade e contato com os clientes, e tambm por
possuir um vasto conhecimento no negcio ele tambm
capaz de sanar as dvidas tcnicas. Mesmo sabendo que os
diretores so os que participam mais no gerenciamento de
novos clientes, nem sempre ser possvel encontr-lo presente
na empresa, assim dificultado o processo do Scrum.
Scrum Team - Por meio de encontros com o Scrum Master,
o Scrum Team representado pela equipe de
desenvolvimento. No h necessidade de uma diviso entre
os integrantes desta equipe como, por exemplo, o
programador, o analista de banco de dados, o testador, entre
outros. O foco principal que todos trabalhem juntos no
projeto para entregarem o conjunto de trabalho a qual foi
prometido durante a Sprint. A equipe tpica costuma-se ter
entre 8 a 10 integrantes, podendo-se variar dependendo do
ambiente em que se aplica. Pode existir mais de um Scrum
Team dentro de uma organizao, e eles iro trabalhar
separadamente, porm quando se tem grandes equipes e
existe a necessidade de criar outras, usado o conceito de
"Scrum of Scrums" (DESENVOLVIMENTO GIL, 2013).
Em cada Scrum Team ser necessrio que um integrante
freqente o Scrum of Scrums Meeting, para que eles
conversem entre si para que as mesmas possam coordenar o
trabalho de mltiplas equipes.
Atualmente na empresa a equipe de desenvolvimento
composta por programadores, testadores e analistas de banco
de dados, totalizando 21 integrantes. Baseando-se nas
recomendaes do Scrum prope-se criar trs equipes, cada
uma composta por cinco desenvolvedores, um analista de
banco de dados e um testador. Essa diviso foi realizada na
tentativa de incluir as trs principais categorias de
profissionais necessrios para realizar implementaes
completas em todos os aspectos do sistema. A diviso
tambm tenta manter em uma mesma equipe profissionais
especializados nos mesmo mdulos do sistema, mantendo
assim as equipes mais coesas. Por existir mais de uma equipe,
existiu a necessidade de deixar uma responsabilidade maior
para um dos integrantes realizar o Scrum of Scrums Meeting.
Esta questo no foi trivial, pois dentro da empresa j existia
um conceito de que uma pessoa de cada mdulo fosse lder de
um determinado mdulo. Esse perfil de um desenvolvedor
com maior experincia no mdulo e conseqentemente com
mais tempo de colaborao.
A. 2) Prticas do Scrum

Alm da definio dos papis descrita anteriormente,

prope-se a utilizao de algumas prticas para realizar o
gerenciamento com o Scrum tais como o Product Backlog,
Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog
e Sprint Review Meeting.
T.I.S. 2014; 3 (2): 122-130

Product Backlog na onde se inicia todo o processo do

Scrum, sendo considerada a prtica responsvel pela parte da
elicitao da rea de engenharia de requisitos onde os
analistas de requisitos realizam as coletas dos requisitos
(SCHWABER; BEEDLE, 2002).
Realizando reunies e tcnicas de levantamento de
requisitos com todos stakeholders do projeto, so levantados e
registrados os itens com todas as necessidades dos requisitos
de negcios e tcnicos para serem desenvolvidos, padres,
tecnologia entre outros fatores. Em outras palavras, para a
empresa em questo, o Product Backlog a lista de atividades
que sero desenvolvidas no projeto.
Esta prtica pode ser realizada usando a ferramenta
proprietria Dirio, pois ela contm todos os requisitos que
so necessrios para o desenvolvimento do produto e o seu
trmino seria o software completo conforme solicitado. Um
aspecto interessante dessa ferramenta que possvel saber
quem fez uma solicitao, quem a realizou, e quem a aprovou.
Apesar de que Scrum o foco o resultado e no a
rastreabilidade (ZANATTA, 2004), acreditamos que isto pode
contribuir para a melhoria no processo.
Linda e Norman (2000) explicam que Daily Scrum so as
reunies realizadas dentro do Scrum durante o
desenvolvimento do projeto. Na maioria das vezes so feitas
diariamente, com durao de quinze minutos
aproximadamente, lembrando que esse tempo no pode
exceder o mximo de trinta minutos. Essa reunio realizada
para que a equipe Scrum possa expor suas dificuldades ou
impedimentos que esto tendo durante a implementao do
projeto. importante ressaltar que essas reunies no so
utilizadas para a soluo do problema e sim, para expor os
problemas. de responsabilidade do Scrum Master encontrar
uma melhor maneira de solucionar esses problemas. O Scrum
Master, durante as reunies, deve levar equipe trs
importantes perguntas (ZANATTA, 2004) APUD
(SCHWABER; BEEDLE, 2002): o que j foi finalizado desde
a nossa ultima reunio, existe alguma dificuldade encontrada
nos trabalhos que esto sendo realizados, e quais so as
prximas atividades que sero entregues no nosso prximo
encontro.
No estudo de caso realizado essas reunies seriam uma
prtica muito eficaz, pois a falta de comunicao interna
evidente e isso contribuiria com o alinhamento de todas as
pessoas que fazem parte do processo. Apesar dessa prtica no
incidir tanto no processo dos requisitos de customizao, ela
pode agregar valor no momento em que o desenvolvimento
encontre falha nos processo de requisitos de melhorias e erros.
Com relao a Sprint pode-se dizer que considerada a
principal parte do Scrum, pois nela que so executados os
itens que foram adicionados no Product Backlog pelos
Product Owner e os stakeholders do projeto. Esta etapa no
pode exceder 30 dias, mas em mdia pode durar de uma a
quatro semanas. No Sprint normalmente adota-se a mesma
diviso tradicional no processo do desenvolvimento do
software: requisitos, anlise, projeto e entrega. Ao trmino de
cada Sprint a equipe Scrum cria uma demonstrao simples
para ilustrar ao cliente como est o andamento do projeto, e
127

Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos

com isso gerada uma sensao que o desenvolvedor

executou sua tarefa com xito (BEEDLE et al., 1999). O teste
um fator muito importante a ser realizado dentro desta
etapa, pois assim possvel garantir a qualidade e validar se
os requisitos foram implementados de acordo com o
especificado, significando menos problemas e redues na
lista do Product Backlog. Caso seja encontrada alguma falha
e a Sprint ainda no tenha terminado, o mesmo deve ser
corrigido, ou gerado um novo item no Product Backlog como
dficit tcnico para ser realizado no prximo Sprint.
Para alinhamento dessa prtica no presente estudo de caso,
uma das maiores contribuies seria a organizao nos
requisitos em andamento, evitando assim o problema de
duplicao de requisitos descrito anteriormente, pois a forma
de conduzir os requisitos que esto sendo implementados
falha. Muitas vezes devido ao tempo escasso e a necessidade
de alterar os requisitos que esto em andamento, muitas
tarefas so abortadas e novos requisitos so implementados
sem nenhum planejamento e isso o principal fator que
prejudicial nos termos de qualidade. Essa a principal
questo levantada que fazem gerar erros inesperados. A ideia
da Sprint ter uma durao de no mximo 30 dias atualmente
j suprida, pois nos dados levantados a empresa j trabalha
com prazos curtos de desenvolvimento. O acompanhamento
de como est implementao dos requisitos tambm j
existe de uma forma simples. A nica alterao proposta a
implementao de uma taskboard dentro da ferramenta
Dirio, para que os desenvolvedores e testadores consigam
alterar o andamento de como est o desenvolvimento de um
determinado requisito, o que hoje no possvel.
O Sprint Planning Meeting a reunio que realizada na
qual devem estar presentes o Product Owner, o Scrum Master
e todo a equipe do Scrum (DESENVOLVIMENTO GIL,
2013). nesta etapa que o Product Owner descreve quais as
funcionalidades so de maior importncia e que tm maior
relevncia para serem desenvolvida primeiro. No
necessrio que o Product Owner descreva todas as
prioridades e sim, de preferncia a quais iro participar
daquele Sprint. Nesse momento o Scrum Team ir realizar
perguntas de modo que seja possvel o refinamento dos
Backlog Items em Task (tarefas) tcnicas logo aps a
reunio. Esses conjuntos de Tasks daro a origem ao Sprint
Backlog. Aps a criao do Sprint Backlog o Scrum Team e
o Product Owner iro definir o objetivo daquele Sprint, que
ser uma breve descrio do que ir ser entregue e qual ser
o objetivo dos requisitos implementados. Muitas vezes esses
requisitos podem ser implementaes implcitas que pode
obter nenhum resultado final palpvel pelo cliente, porm
isso discutido e explicado durante o Sprint Planning
Meeting. Aps toda a definio e o Sprint Backlog aprovado
pela equipe Scrum possvel se iniciar a Sprint.
Essa prtica, se introduzida na empresa estudada, apesar
de aparentemente ocupar tempo produtivo, faria com que os
desenvolvedores e analistas de negcios expusessem mais as
ideias do que j existe na ferramenta, e o que realmente
existe a necessidade de implementar, pois conforme
levantado muitos requisitos eram solicitados e os mesmo j

existiam ou havia uma outra forma de utilizao no sistema.

Essa proposta tem como objetivo reduzir
consideravelmente grande parte de requisitos ambguos e
desnecessrios. Outro fator a ser considerado a maior
facilidade em se medir os esforos e tempos para a entrega de
um requisito durante as reunies. Existem muitos requisitos
solicitados com prazos escassos, e promessas feitas ao cliente
sem a consulta prvia equipe sobre o impacto que o mesmo
poderia causar. A reduo de estresse na equipe de
desenvolvimento e a presso dos clientes sero reduzidas
notavelmente, pois as negociaes dos requisitos so
melhores planejadas.
O Sprint Backlog como mencionado acima, uma lista de
tarefas que gerada a cada Sprint Planning Meeting, a qual a
equipe Scrum se compromete a cumprir durante a Sprint
corrente. Esses itens so extrados do Product Backlog, os
quais foram priorizados pelo Product Owner, baseando-se na
complexidade e tempo que ser necessrio para se realizar
aqueles requisitos. Cabe ao Scrum Team determinar a
quantidade de itens que sero implementados do Product
Backlog, pois o Sprint Backlog j a total responsabilidade
do time com relao a uma Sprint (DESENVOLVIMENTO
GIL, 2013). O papel do Scrum Master nesta etapa manter
o Sprint Backlog atualizado, para que toda a equipe e ele
possam refletir sobre quais as tarefas foram completadas e
qual ser o tempo necessrio para poder terminar as demais
que ainda esto na lista para serem feitas. Na prtica pode
acontecer de alguns dos itens que foram selecionados no
Sprint Backlog no poderem ser implementados, por isso
cabe ao integrante do Scrum Team expor isso nas Daily
Scrum para que o Scrum Master possa verificar o que pode
ser feito, como por exemplo, passar a Task para outro
integrante do time, ou mesmo negociar com Product Owner.
Realizando a adaptao dessa prtica para a empresa
estudada, a sobrecarga de trabalho no Scrum Team, caso
exista, passar a ficar explcita, pois depois de definidos os
itens que sero entregues em cima dos prazos
comprometidos, so evitados os requisitos passados sem
nenhum planejamento. Tambm fica notrio para os diretores
e gerente que todos os colaboradores da equipe possuem
tarefas e que ambos esto se empenhando no projeto.
Na finalizao de cada Sprint realizada a Sprint Review
Meeting. Nesta reunio, o Scrum Team mostra o que foi
realizado durante a Sprint. Formalmente, isso pode ser
apresentado em uma demonstrao ou uma prvia descrio
das novas funcionalidades. Essa reunio realizada junto
equipe do Scrum, Scrum Master, Product Owner e os demais
stakeholders que compem o projeto. O Scrum Master junto
ao Product Owner mais os stakeholders iro analisar se o
incremento satisfaz o que foi comprometido na Sprint
Planning Meeting. Mesmo que todos ou alguns itens no
tenham sido implementados no Sprint Backlog, a ideia
principal que a equipe atinja o objetivo final daquela Sprint.
Adotando-se esta prtica no estudo de caso, a proposta
haver um aumento da satisfao do cliente e
conseqentemente a satisfao da equipe de
desenvolvimento, pois nessas reunies, conforme a
128

TI.S. 2014; 3 (2): 122-130

Felipe Luiz Carnevali, Daniel Lucrdio

apresentaes das demonstraes os clientes podem ter a

confiana da utilizao da nova funcionalidade produzida em
um pequeno espao de tempo.
B) Resultados preliminares e discusso

A proposta de melhoria est em estgio avanado de

implementao, tendo j implementado a taskboard e todos
os papis e algumas prticas do Scrum tais como o Product
Backlog, Daily Scrum, a Sprint, a Sprint Backlog e o Sprint
Review Meeting. Com os papis bem definidos foi simples
organizar algumas prticas dentro da organizao, e com a
implementao da taskboard no aplicativo Dirio a equipe
pode acompanhar como est o andamento dos requisitos.
Uma prtica que ainda falta ser implementada Scrum of
Scrums Meetting, pois est sendo necessrio realizar algumas
adaptaes de horrios e pessoas entre as reunies dirias,
para que depois implemente as reunies entre as equipe. O
Sprint Planning Meeting foi parcialmente implementado pois
existem trabalhos atrasados e precisam ser realizados devido
aos prazos prometidos anteriormente.
Analisando os resultados ficou explicita a questo de como
a metodologia gil melhorou o processo da engenharia de
requisitos. Focando nos pontos principais que so a
elicitao, especificao e validao, a utilizao das prticas
e regras do Scrum, junto com a definio de papis aplicado
dentro da empresa, obteve-se um resultado satisfatrio. A
reduo de requisitos desnecessrios e redundantes foi
efetivamente observada, causando grande impacto em termos
de agilidade.
Outro ponto positivo que, mesmo que a utilizao de
algumas prticas provoque alguma perda de tempo produtivo
com reunies, este tempo sutilmente pequeno analisando o
tempo que se perdia implementando requisitos sem
necessidade ou mesmo o tempo que era gasto para se fazer o
levantamento do mesmo. Observou-se alguma reclamao,
mas principalmente por parte da gerncia. No geral, a equipe
e os clientes mostraram-se satisfeitos com o resultado.
Com as tarefas sendo registradas, e com o explicativo de
que aquele requisito faz, foi possvel aumentar a capacidade
dos envolvidos em saber como est o software atualmente.
Com relao ao foco na comunicao, a utilizao de
papis mais bem definidos levou a elicitao a um nvel mais
produtivo. Foi possvel aproximar no s os clientes e
analistas de requisitos, mas todos os integrantes da equipe,
tais como programadores, testadores e outros, que passaram a
ter uma melhor viso do negcio e do produto a ser
implementado. Dar essa importncia a todos da equipe
emotiva e aumenta as ideias para encontrar uma melhor
soluo para o incremento final do produto.
A especificao tambm tornou-se mais clara, sendo que o
Scrum Team j obteve o conhecimento do contexto e o
objetivo final do que tem que ser feito, pois as conversas
realizadas com o Product Onwer e os stakeholders fizeram
com que eles entendessem melhor o dia a dia e a dificuldade
que os usurios tem em manusear o software, assim obtendo
uma ideia e planejamento melhor na hora de realizar a
implementao para que satisfaa o cliente da maneira que
T.I.S. 2014; 3 (2): 122-130

foi solicitada.
A validao passou a ser mais sucinta, pois com os clientes
presentes a cada levantamento e a cada apresentao do
incremento, j era realizada a aprovao se o que foi realizado
abrange a necessidade acordadas no incio de cada Sprint.
Realizando a apresentao formal, foi possvel analisar a
satisfao do cliente quanto ao que foi prometido. A satisfao
um ponto muito importante no Scrum quando se refere ao
cliente, mas isto foi recproco a equipe tambm, pois ver o
resultado positivo do produto fez com que a equipe se
motivasse mais fazendo com que haja harmonia e um bom
relacionamento entre eles. Este ponto, alis, uma das
caractersticas que a metodologia gil foca: A valorizao das
pessoas que fazem parte do projeto.
Em resumo, com a realizao das trs principais fases da
engenharia de requisitos aplicados junto metodologia gil
Scrum foi possvel obter um documento de todos os itens que
foram e sero implementados de forma simples, clara e
objetiva sem muita burocracia. Foi tambm adquirida a to
importante comunicao que fez acontecer um melhor
planejamento do produto a ser implementado realizando a
integrao do time como se fosse um s com o principal
objetivo de obter o que foi acordado com qualidade, agilidade
e a satisfao do cliente.
V. TRABALHOS RELACIONADOS
Na metodologia Scrum a simplicidade e a agilidade so os
principais aspectos as quais suas prticas induzem realizar o
gerenciamento baseado principalmente nas pessoas e nos
processos. Diferente de outras prticas de gerenciamento de
requisitos que envolvem regras e tcnicas na qual o principal
processo realizar um gerenciamento mais burocrtico perdese a eficincia da praticidade. Para o Scrum esses quesitos so
diferenciais, pois o seu principal objetivo a satisfao do
cliente, e para se garantir isso necessrio que haja qualidade
e gerenciamento eficaz. Na literatura, possvel encontrar
alguns esforos em se aplicar mtodos geis e mtodos de
gerenciamento de requisitos.
Zanatta (2004) prope a utilizao da metodologia gil
Scrum para a gerncia de requisitos utilizando as prticas do
CMMI e fazendo uma adaptao. O resultado foi satisfatrio,
mas nem todas as prticas abordadas pelo Scrum so
atendidas pelo conceito do CMMI. Segundo o autor, isso se
deve ao fato de que o CMMI introduz prticas de
gerenciamento burocrticas, e por isso muitos de seus itens
CMMI no seriam contemplados.
Espindola et al. (2004) realizam uma anlise crtica do mau
gerenciamento dos requisitos e enfatiza o impacto das
negociaes dos requisitos. Os autores afirmam que a analise
responsvel por identificar requisitos conflitantes,
esquecidos, ambguos ou irreais. Entretanto esta atividade
realizada com os interessados do projeto pode ser prejudicada
devida falta de interao entres os stakeholders e o analista
de requisitos. O Scrum prope que a constante interao entre
os interessados do projeto uma das principais caractersticas
para o sucesso do negcio, e um dos princpios baseados na
metodologia.
129

Aplicando a Metodologia gil Scrum para apoio ao Gerenciamento de Requisitos

O presente estudo de caso vem corroborar outras

observaes da literatura, como por exemplo, a praticidade do
Scrum e a importncia da comunicao. Com isso aumenta-se
a evidncia em favor dessa prtica gil j bastante difundida.
VI. CONCLUSES E TRABALHOS FUTUROS
Conclumos com este trabalho que importante ressaltar
que quando os requisitos no so bem definidos, a obteno
da qualidade dificultada, assim como cumprimento de
prazos e custo dentro do contexto do desenvolvimento de
software. Problemas similares foram relatados com base em
um estudo de caso em uma empresa de software, que vivencia
na prtica essa realidade.
Com as melhorias propostas, observou-se que a
metodologia gil Scrum pode proporcionar esse fator de
qualidade, prazo e custo como as demais metodologias
convencionais, porm visando a agilidade e a satisfao do
cliente, obtendo softwares mais rpidos e pertinentes
conforme a solicitao do cliente. Com os papis, prticas e
regras do Scrum, so explcitas as melhorias que foram
aplicadas na utilizao desta metodologia.
Como trabalhos futuros, sugere-se a realizar a utilizao de
mais de uma metodologia gil em conjunto, como por
exemplo, o Scrum e o Extreming Programming (XP), pois de
acordo com Abrahamsson et al. (2002) quando mais de uma
metodologia gil utilizada ao mesmo tempo, melhora-se o
processo de agilidade. Por exemplo, um ponto forte da
utilizao do XP seria o apoio na melhoria no fator da
utilizao das prticas da engenharia de software tais como
Test Driven Development (TDD), Refactoring, Pair
Programming entre outras. Como o Scrum no define o uso
desse tipo de tcnica, o XP seria um bom complemento ao
processo, proporcionando maior agilidade tambm no mbito
da programao.
REFERNCIAS
LEITE, J.C.S.P. Engenharia de Requisitos- Notas de Aula.,
1994.
KOTONYA, G.; SOMMERVILLE, I. Requirements
Engineering: Processes and Techniques., Jonh Wiley &
Sons Ltd., 1998.
LEFFINGWELL, D.; WIDRIG, D. Managing Software
Requirements: a unified approach., Addison-Wesley, 2000.
LEFFINGWELL, D,; WIDRIG, Don. Managing Software
Requirements A Use Case Approach. Addison-Wesley.

2003, 492p.
SOMMERVILLE, I.; SAWYER, P. Requirements Engineering
a good practice guide. New York: John Wiley & Sons
Ltd, 1997, 391p.
ESPINDOLA, R. S.; MAJDENBAUM, A.; AUDY, J. L. N.
Uma Anlise Crtica dos Desafios para Engenharia de
Requisitos em Manuteno de Software. In: VII Workshop
on Requirements Engineering, 2004, Tandil, Argentina,
2004.
AGILE SURVEY; 7th Annual Survey: 2012 The State of
Agile Development Conducted: June-July, 2012 Disponvel em: http://www.versionone.com/ Acessado em:
10 agosto 2013.
BEEDLE, M.; DEVOS, M.: SCRUM: A Pattern Language for
Hyperproductive Software Development. In Pattern
Languages of Program Design 4, editado por N. Harrson,
B. Foote, e H. Rohnert. Addison-Wesley (1999).
SCHWABER, K.; BEEDLE M.: Agile Software Development
with Scrum, Upper Saddle River, NJ, Prentice Hall.
(2002).
ZANATTA L. A. xScrum: uma proposta de extenso de um
Mtodo gil para Gerncia e Desenvolvimento de
Requisitos visando adequao ao CMMI. Florianpolis,
2004. 180 pginas. Dissertao (Mestrado em Cincia da
Computao) - Curso de Ps-Graduao em Cincia da
Computao, Universidade Federal de Santa Catarina.
FOWLER, M. The New Methodology. Disponvel em:
<http://www.martinfowler.com/articles/newMethodology.h
tml>. Acesso em : set 2013.
HIGHSMITH, J.; Agile Software Development Ecosystems.
Addison Wesley, 2002.
LINDA R.; NORMAN J.,: The SCRUM Software
Development Process for Small Teams, IEEE Software,
July-August 2000.
DESENVOLVIMENTO GIL; Disponvel em: <
http://desenvolvimentoagil.com.br/>. Acesso em 26 set,
2013.
GILE
MANIFESTO;
Disponvel
em:
<http://www.agilemanifesto.org/principles.html>. Acesso
em 23 set, 2013.
ABRAHAMSSON, P.; SALO, O.; RONKAINEN, J.;
WARSTA, J. Agile Software Development Methods:
Review and Analysis. Espoo, VTT Electronics, 107 p.
Publicao VTT 478. (2002).
BECK, K. Extreme Programming: Embrace Change. Addison
Wesley. 2000.

130

TI.S. 2014; 3 (2): 122-130