Vous êtes sur la page 1sur 17

PROPOSTA DE AVALIAO DA QUALIDADE DE

REQUISITOS IDENTIFICADOS POR MEIO DA


ABORDAGEM GIL SCRUM
Renata Dutra Braga1
Olissa Artiaga da Silva1
1

Ps-Graduao Lato Sensu em Qualidade e Gesto de Software Pontifcia Universidade


Catlica de Gois (PUC-GO) Goinia Brasil Agosto de 2012.
{renatadbraga, olissea}@gmail.com

Olissa Artiaga da Silva Especialista

Abstract. Objective: To investigate methods adopted to achieve the quality requirements


and develop a checklist that can be used in the iterations of the project using Scrum as a
way to verify the quality of recorded requirements. Methods: We conducted a literature
research, then the elaboration of the checklist, and finally, validation of the same between
the academic community and companies in the sector of Information Technology. Results:
The content of the checklist has been prepared in accordance with IEEE Standard 8301998. The semantic validation of the same, as well as its use in a sprint a real design was
performed. Conclusion: The use of the checklist revealed the importance to identify and
verify the quality of each requirement defined in the Sprint.
Resumo. Objetivo: Investigar mtodos adotados para alcanar a qualidade de requisitos e
desenvolver um checklist que poder ser utilizado nas iteraes do projeto que utiliza o
Scrum como forma de verificar a qualidade dos requisitos registrados. Mtodos: Foi
realizado um estudo bibliogrfico, em seguida, a elaborao do checklist e, por fim, a
validao do mesmo entre a comunidade acadmica e empresas do setor de Tecnologia da
Informao. Resultados: O contedo do checklist foi elaborado em conformidade com a
Norma IEEE 830-1998. A validao semntica do mesmo, assim como a sua utilizao em
uma Sprint de um projeto real foram realizadas. Concluso: A utilizao do checklist
revelou a importncia para identificar e verificar as caractersticas de qualidade de cada
requisito definido na Sprint.
Palavras-Chave: Qualidade de Requisitos, Metodologia gil, Scrum.

1. Introduo
O mercado, progressivamente, vem exigindo maior qualidade nos produtos desenvolvidos
por empresas em diferentes setores de atividades. No que se refere indstria de software
no poderia ser diferente.
A qualidade de software destaca-se como um diferencial de mercado visto que sua
importncia est no fato de produzir sistemas cada vez melhores e, assim, assegurar a
satisfao do cliente [MPS.BR 2009a].
O termo qualidade, dependendo do ponto de vista e contexto, possui diferentes
significados em relao construo de software. Por exemplo, a qualidade do processo de
desenvolvimento [RUP (2012)a e MPS.BR (2009)b], a qualidade do produto, que por sua
vez, definida em qualidade interna, qualidade externa e qualidade em uso [ABNT 2003].
Diversas metodologias de gerncia e desenvolvimento de software visando alcanar
a qualidade do produto desenvolvido so encontradas na literatura. Tem-se as abordagens
tradicionais, tais como: modelo cascata, evolucionrio, espiral [Sommerville 2011] e Guia
do Conhecimento em Gerenciamento de Projetos [PMI 2008], dentre outras; assim como,
as abordagens geis, tais como: Extreme Programming [Beck 1999], Scrum [Schwaber
2004], Feature Driven Development [Highsmith 2002], Adaptive Software Development
[Highsmith 2002] e Crystal [Cockburn 2004].
Dentre as abordagens citadas, em especial s geis, um destaque diferenciado deve
ser dado ao Scrum que, alm de ser um framework de desenvolvimento e gerncia de
projetos de software [Guia do Scrum 2009], ele tambm pode ser utilizado na implantao
de processo de melhoria de software [Salgado 2010] e gerncia de portflios de projetos
[Schwaber 2004]. Alm disto, o Scrum destaca-se dos demais mtodos geis pela maior
nfase dada ao gerenciamento do projeto e rene atividades de monitoramento e feedback,
em geral, reunies rpidas e dirias com toda a equipe, visando a identificao e correo
de quaisquer deficincias e/ou impedimentos no processo de desenvolvimento [Maral
2009].
Considerando que ao utilizar a abordagem Scrum, as necessidades dos usurios
quanto ao desenvolvimento do software so evoludas e entendidas a cada iterao no
decorrer da execuo do projeto, torna-se fcil entender a descrio que a International
Standardization Organization (ISO) menciona na norma 9126-1 obter um produto que
satisfaa as necessidades do usurio normalmente requer uma abordagem iterativa para o

desenvolvimento de software com feedback contnuo sob a perspectiva do usurio. [ABNT


2003].
Dessa forma, manter a qualidade dos requisitos ou users histories identificados,
torna-se mais complexo com o uso desta abordagem sob o ponto de vista do cliente
(Product Owner). Portanto, como verificar que os requisitos, ao final de uma Sprint1,
possui qualidade?
Esse trabalho prope investigar mtodos adotados para alcanar a qualidade de
requisitos e desenvolver um checklist que poder ser utilizado em cada iterao do projeto
que utiliza a metodologia Scrum como forma de verificar a qualidade do conjunto de
requisitos registrados para um determinado domnio de problema.
importante ressaltar que o foco do presente trabalho est na verificao da
qualidade dos requisitos do produto e no na verificao da qualidade dos requisitos do
processo. Adicionalmente, o mesmo est organizado nas seguintes sees: a seo 2
apresenta uma descrio sobre a qualidade de requisitos, enquanto que as caractersticas da
metodologia gil Scrum so estabelecidas na seo 3; na seo 4, os procedimentos
metodolgicos so detalhados; na sesso 5 os resultados encontrados so caracterizados,
assim como uma discusso sobre o assunto apresentada. Por fim, na sesso 6, as
consideraes finais so apresentadas.

2. Qualidade de Requisitos
A qualidade de software definida pelo Instituto de Engenheiros Eletricistas e Eletrnicos,
ou em ingls Institute of Electrical and Electronics Engineers - IEEE, como "o grau com
que um sistema, componente ou processo atende aos requisitos especificados e s
expectativas ou necessidades de clientes ou usurios [SWEBOK 2004].
Visando atingir a qualidade de software, diversos modelos de processos foram
desenvolvidos, tais como Capability Maturity Model Integration (CMMI), Modelo de
Processo de Software Brasileiro (MPS.BR) e ISO 9001 [SAYO 2003]. Na maioria desses
modelos, uma das reas que possui maior preocupao e, por isso, uma das primeiras a
ser implementada a rea de Gerncia de Requisitos [MPS.BR (2009)c], [CMMI 2006].

Sprint uma iterao de um ms ou menos, de durao consistente com o esforo de desenvolvimento


[Agile Manifesto 2011].

Dessa forma, possvel perceber que especificar requisitos com qualidade


essencial para alcanar a qualidade do software desejada, tanto na perspectiva do cliente
quanto tcnica.
O termo requisito definido como uma condio ou capacidade necessria para um
usurio resolver um problema ou atingir um objetivo [IEEE 1998] ou ainda, uma
condio ou uma capacidade com a qual o sistema deve estar de acordo [RUP (2012)b].
Para tanto, visando garantir a qualidade dos requisitos definidos, o IEEE definiu a
Norma 830-1998 que estabelece as caractersticas para um requisito (ou, o documento de
requisito) ter uma boa qualidade, tais como, ser correto, no ambguo, completo,
consistente, classificado por importncia, verificvel, modificvel e rastrevel [IEEE 1998].
A definio de cada caracterstica apresentada na tabela a seguir.

Tabela 1 - Caractersticas de uma boa especificao de requisitos.


Fonte: Norma IEEE 830-1998.
Caractersticas
Correto

Definio
correto se, e somente se, cada requisito expresso for encontrado
tambm no software.

No ambguo

no ambguo se, e somente se, cada requisito declarado seja


suscetvel a apenas uma interpretao.

Completo

completo se, e somente se, conter toda e apenas a informao


necessria para que o software correspondente seja produzido.

Consistente

consistente se, e somente se, nenhum dos requisitos do documento,


tomado individualmente, est em conflito com qualquer outro
requisito do mesmo documento.

Classificado por importncia

Se existe indicaes no documento quanto importncia ou

/ estabilidade

estabilidade do requisito.

Verificvel

verificvel se, e somente se, para cada um dos requisitos contidos no


documento, existe um processo finito e economicamente vivel
atravs do qual uma pessoa ou mquina possa assegurar que o produto
de software atende ao requisito.

Modificvel

modificvel se, e somente se, modificaes possam ser agregadas ao


documento de forma fcil, completa e consistente, com relao a sua
estrutura e estilo.

Rastrevel

rastrevel se, e somente se, a origem de cada um de seus requisitos


clara e a referncia a cada um deles facilitada nos documentos

subsequentes do processo ou em uma melhoria da documentao do


sistema.

Assim como a Norma IEEE 830-1998, existem outras abordagens que visam
especificar requisitos com boa qualidade. Dentre elas, possvel mencionar a ISO 122072008 e ISO 9001, bem como os modelos de processos de software que definem um padro
para a garantia da qualidade de software, como o CMMI e o MPS.BR.
Portanto, verificar a qualidade de requisitos, independentemente do tipo de
metodologia de desenvolvimento adotada, quer seja tradicional ou gil, torna-se relevante,
pois sabe-se que a qualidade caracterizada como um fator crtico de sucesso para a
indstria de software [MPS.BR 2009b].

3. Mtodos geis: Caractersticas do Scrum


Em 2001, dezessete especialistas reuniram-se e compartilharam princpios comuns entre
todos os mtodos geis existentes, criando assim o Manifesto gil e a Aliana gil [Soares
2004].
No total, doze princpios foram definidos, entre eles a satisfao do cliente,
adequao a mudanas, indivduos motivados e entrega rpida de software funcionando
esto contemplados. A tabela a seguir, apresenta tais princpios.

Tabela 2 - Princpios por trs do manifesto gil. Fonte [Agile Manifesto 2011].
1.

Nossa maior prioridade satisfazer o cliente, atravs da entrega adiantada e contnua de


software de valor.

2.

Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento. Processos geis se


adequam a mudanas, para que o cliente possa tirar vantagens competitivas.

3.

Entregar software funcionando com frequncia, na escala de semanas at meses, com


preferncia aos perodos mais curtos.

4.

Pessoas relacionadas negcios e desenvolvedores devem trabalhar em conjunto e


diariamente, durante todo o curso do projeto.

5.

Construir projetos ao redor de indivduos motivados. Dando a eles o ambiente e suporte


necessrio, e confiar que faro seu trabalho.

6.

Mtodo mais eficiente e eficaz de transmitir informaes para, e por dentro de um Time de
desenvolvimento, atravs de uma conversa cara a cara.

7.

Software funcional a medida primria de progresso.

8.

Processos geis promovem um ambiente sustentvel. Os patrocinadores, desenvolvedores e


usurios, devem ser capazes de manter indefinidamente, passos constantes.

9.

Contnua ateno excelncia tcnica e bom design, aumenta a agilidade.

10. Simplicidade: a arte de maximizar a quantidade de trabalho que no precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de Times auto-organizveis.
12. Em intervalos regulares, o Time reflete em como ficar mais efetivo, ento, se ajustam e
otimizam seu comportamento de acordo.

Tal manifesto prope que novas maneiras para desenvolver software esto sendo
descobertas, onde atravs deste trabalho, passam a valorizar [Agile Manifesto 2001]:

Indivduos e interao entre eles mais que processos e ferramentas

Software em funcionamento mais que documentao abrangente

Colaborao com o cliente mais que negociao de contratos

Responder a mudanas mais que seguir um plano


O framework Scrum uma abordagem emprica baseada na flexibilidade,

adaptabilidade e produtividade em que a escolha das tcnicas de desenvolvimento fica a


cargo do time [Maral 2009].
Trs pilares asseguram a implementao dessa abordagem emprica [Guia do Scrum
2009]:

Transparncia: garante que aspectos do processo que afetam o resultado devem ser
visveis para aqueles que gerenciam os resultados. Esses aspectos no apenas devem
ser transparentes, mas tambm o que est sendo visto deve ser conhecido.

Inspeo: Os diversos aspectos do processo devem ser inspecionados com uma


frequncia suficiente para que variaes inaceitveis no processo possam ser
detectadas.

Adaptao: Se o inspetor determinar, a partir da inspeo, que um ou mais aspectos


do processo esto fora dos limites aceitveis e que o produto resultante ser
inaceitvel, ele dever ajustar o processo ou o material sendo processado. Esse
ajuste deve ser feito o mais rpido possvel para minimizar desvios posteriores.
A Figura 1 ilustra o processo de desenvolvimento do Scrum.

Figura 1 - Processo de Desenvolvimento do Scrum. Fonte: http://scrumforteamsystem.com

De acordo com a figura anterior possvel perceber que o framework Scrum sugere
que as equipes sejam pequenas, entre cinco e, no mximo, sete pessoas. Quando h menos
do que cinco membros em um Time, h menor interao e, como resultado, h menor ganho
de produtividade [Guia do Scrum 2009]. O framework, tambm, sugere que os ciclos de
cada Sprint sejam curtos de no mximo trinta dias.
A fase de preparao, presente na Figura 1, tem por objetivo identificar os
requisitos e prioriz-los (pelo menos para a prxima Sprint). Divide o Product Backlog em
Sprints, de acordo com a priorizao realizada, levando em considerao a produtividade
do Time [Maral 2009]. nesta fase que o resultado do presente trabalho se prope a
avaliar e verificar a qualidade de tais requisitos identificados.

3.1. Papis do Scrum


A metodologia gil Scrum estabelece um framework iterativo e incremental, onde as
atividades executadas por cada Time so exercidas por trs principais papis [Schwaber
2004] [Guia do Scrum 2009]:

Scrum Master: responsvel por garantir que o processo seja compreendido e


seguido, em outras palavras, que o Time adepto aos valores, s prticas e s regras
do Scrum; e tambm responsvel por remover os impedimentos do projeto.

Product Owner: responsvel por maximizar o valor do trabalho que o Time de


Scrum faz; define os fundamentos do projeto definindo requisitos iniciais e gerais
(Product Backlog), retorno do investimento, objetivos e planos de entregas; prioriza
o Product Backlog a cada Sprint, garantindo que as funcionalidades de maior valor
sejam construdas prioritariamente. Somente o Product Owner muda a prioridade de
um item.

Time: responsvel por executar o trabalho propriamente dito. O Time consiste em


desenvolvedores com todas as habilidades necessrias para transformar os requisitos
do Product Owner em um pedao potencialmente entregvel do produto ao final da
Sprint. Ele auto-organizvel.

3.2. Artefatos
Ao longo do desenvolvimento do produto, poucos artefatos so gerados ao utilizar o
Scrum, dentre eles quatro principais se destacam [Guia do Scrum 2009]:

Product Backlog: uma lista priorizada de tudo que pode ser necessrio no
produto.

Sprint Backlog: uma lista de tarefas para transformar o Product Backlog, por uma
Sprint, em um incremento do produto potencialmente entregvel. Um burndown
uma medida do backlog restante pelo tempo.

Burndown de Release: mede o Product Backlog restante ao longo do tempo de um


plano de release.

Burndown de Sprint: mede os itens do Sprint Backlog restantes ao longo do tempo


de uma Sprint.

4. Mtodos
Esta uma pesquisa aplicada que utilizar estudo bibliogrfico, de campo e a elaborao de
um checklist que objetiva verificar a qualidade dos requisitos registrados por meio da
abordagem gil Scrum.
Para o estudo bibliogrfico ser realizada a busca em diferentes bases de dados
cientficas (IEEE Xplore, ACM, Peridicos da CAPES, Google Scholar), assim como em
revistas e livros.

Para a elaborao do checklist, aps a anlise da literatura por meio do estudo


bibliogrfico, a ferramenta BrOffice.org Calc ser utilizada. Tal checklist ser validado
entre a comunidade acadmica e empresas do setor de Tecnologia da Informao, utilizando
a tecnologia Google Docs.

5. Resultados e Discusso
Como resultado da anlise da literatura e pesquisas para verificar a qualidade de requisitos,
foi proposto um checklist, estruturado em um conjunto de perguntas em conformidade com
as caractersticas de qualidade estabelecidas pela Norma IEEE 830-1998 [IEEE 1998].
A tabela a seguir ilustra o checklist elaborado que contm, para cada caracterstica
presente na Norma IEEE 830-1998, os itens a verificar nos requisitos registrados em cada
Sprint do projeto.

Tabela 3 - Checklist proposto. Fonte: O autor.


ID

Itens a Verificar

Escala
(0- NA/No Atende; 5- Atende
Parcialmente; 10- Atende
Completamente)

C - CORRETO
C.1

O requisito registrado foi implementado na Sprint?

C.2

O requisito (seja funcional ou no funcional) foi registrado de


forma clara e objetiva?

C.3

O cliente reflete, quando aplicvel, se o requisito registrado


atende s suas reais necessidades?
NA - NO AMBGUO

NA.1

O requisito registrado na Sprint suscetvel a apenas uma


interpretao?

NA.2

De acordo com o requisito registrado, possvel validar seu


contedo com o cliente?

NA.3

De acordo com o requisito registrado, possvel verificar se o


software correto foi produzido?
CO - COMPLETO

CO.1

Uma lista de requisitos que inclui os mais significantes para a


Sprint definida

CO.2

O requisito registrado aborda a definio das respostas do

software a todos os tipos de dados de entrada em todas as


situaes possveis, vlidas ou invlidas?
CO.3

Os requisitos alocados na Sprint contm toda e apenas a


informao necessria para que o software correspondente seja
produzido?
CT - CONSISTENTE

CT.1

O requisito registrado na Sprint est em conflito com qualquer


outro requisito definido na mesma Sprint ou em outra?
CI - CLASSIFICADO POR IMPORTNCIA

CI.1

Uma escala de prioridade/estabilidade para os requisitos foi


definida juntamente com o cliente?

CI.2

Existe indicao quanto importncia ou estabilidade do


requisito definido na Sprint?

CI.3

A prioridade/estabilidade do requisito foi classificada juntamente


com o cliente?
V - VERIFICVEL

V.1

possvel determinar se o requisito registrado satisfeito pela


implementao no final da Sprint?

V.2

O requisito definido passvel de teste?

V.3

Para cada um dos requisitos definido na Sprint, o(s) respectivo(s)


caso(s) de teste(s) foi elaborado e executado?

V.4

Ao final da Sprint, o cliente assegura que o produto entregue,


atende ao requisito registrado?
M - MODIFICVEL

M.1

Um mecanismo que facilita a modificao de requisitos na Sprint


utilizado?

M.2

Antes de realizar a modificao de requisito, os impactos so


analisados?

M.3

Modificaes podem ser agregadas no requisito definido na Sprint


de forma fcil, completa e consistente?
R - RASTREVEL

R.1

O requisito possui um identificador nico?

R.2

A origem do requisito registrado clara?

R.3

Existe um mecanismo que permite realizar a rastreabilidade do


requisito definido na Sprint?

R.4

A rastreabilidade deste requisito com os demais registrados na


Sprint foi definida?

R.5

Existe rastreabilidade com todos os requisitos definidos na


presente Sprint com as demais Sprint?

Este checklist destina-se aos interessados que empregam a metodologia gil Scrum.
Seu objetivo avaliar a qualidade dos requisitos registrados em cada Sprint do projeto. O
formulrio desenvolvido para realizar a validao do mesmo encontra-se em
https://docs.google.com/spreadsheet/viewform?formkey=dHJzWEJQeEJsZ1ZJU2hoNlZ4b
TA1eGc6MQ8.
A validao semntica do checklist elaborado foi realizada na Fbrica de Software
de uma instituio de ensino superior privada e outra pblica, ambas localizadas em
Anpolis-GO. A mesma validao, tambm, foi realizada pela comunidade acadmica e por
alguns colaboradores de empresas do setor de Tecnologia da Informao (TI) localizados
em Goinia-GO. Foram sugeridas algumas melhorias no checklist, as quais esto descritas
abaixo:

Acrescentar itens a verificar no checklist relacionados aos tpicos abaixo:


o Analisar se o requisito registrado est dentro do escopo da Sprint;
o Analisar se o requisito registrado j foi alocado em outra Sprint ou se o
mesmo duplicado / conflitante com outro;
o Analisar se a causa raiz do requisito foi identificada na Sprint.

Propor um processo para tratar dos requisitos levando em considerao a


rastreabilidade e preveno de mudanas.
O checklist foi utilizado em uma Sprint, com durao de uma semana, em um

projeto real em desenvolvimento na Fbrica de Software de uma instituio de ensino


superior privada, localizada em Anpolis-GO.
Na Sprint, sete requisitos foram registrados. Para cada um deles, uma verificao foi
realizada tomando como base os itens a verificar presente no checklist. Dos vinte e cinco
itens a verificar, somente um de cada caracterstica foi escolhido e os respectivos resultados
esto ilustrados nos grficos a seguir. O nmero do ID (identificador) o mesmo definido
na Tabela 3.

Tabela 4 - Interpretao dos resultados


ID
C.1

Grfico

Interpretao
De acordo com a verificao,
57% dos requisitos foram
implementados parcialmente
na Sprint, enquanto que 43%
foram

completamente

implementados.
Percebe-se que o time no
teve um desempenho 100%
esperado. Novas adaptaes
devem ser analisadas para
melhorar o desempenho da
equipe.
NA.1

71% dos requisitos registrados


na Sprint so suscetveis a
apenas

uma

interpretao.

Somente 14% deles atende


parcialmente esse item e os
demais 14% so ambguos.
CO.3

Nessa
detectado

verificao
que

foi

43%

dos

requisitos alocados na Sprint,


contm toda e somente a
informao necessria para
produzir o software, enquanto
que 29% dos requisitos atende
parcialmente essa verificao.
CT.1

43% dos requisitos registrados


na Sprint no est em conflito
com qualquer outro requisito
definido
quanto

tanto
em

na

mesma

outra

Sprint.

Porm, uma taxa de 29%


possui algum tipo de conflito
e os outros 29% no atende
essa verificao.

CI.3

Essa verificao demonstrou


que a prioridade de 71% dos
requisitos

classificada

juntamente com o cliente (ou


o Product Owner). 14% dos
requisitos no se define a
prioridade juntamente com o
cliente, enquanto que 14%
no define nenhum tipo de
prioridade.
V.1

avaliao

desse

item

permite constatar que 57%


dos requisitos satisfeito pela
implementao ao trmino da
Sprint de forma parcial. Um
valor

de

43%

atende

completamente

essa

satisfao. Um fator positivo


que 0% no satisfeito ou no
atende.
M.1

resultado

desse

item

demonstra que um mecanismo


que

objetiva

modificao
registrados

facilitar
de

na

requisitos
Sprint

utilizado em 43% deles. 29%


no adota esse mecanismo e
os demais 29% utiliza apenas
parcialmente esse mecanismo.
R.1

71% dos requisitos registrados


na

Sprint

possuem

um

identificador nico, enquanto


que

29%

no

utilizam

nenhum tipo de identificador.

Aps a utilizao do checklist na Sprint desse projeto real, a anlise dos resultados
obtidos foi realizada, assim como uma reunio de lio aprendida. Nesta reunio todas as
sugestes e melhorias identificadas com a aplicao do checklist foram registradas e os
mtodos para melhorar para a prxima Sprint no projeto foram identificados.
importante ressaltar que a adoo do Scrum de suma importncia para
identificar e entender as reais necessidades do cliente (Product Owner) e faz-lo entender
(ou ele mesmo chegar nesse objetivo) quais so suas necessidades. E, ento, em cada
Sprint, estabelecer um planejamento, execut-lo e entregar uma verso funcionando do
produto ao Product Owner.
Segundo a ISO, as necessidades explicitadas pelo usurio nem sempre refletem
suas reais necessidades porque: (1) frequentemente, o usurio no est consciente de suas
necessidades reais; (2) as necessidades podem mudar aps terem sido explicitadas; (3)
usurios diferentes podem ter ambientes operacionais diferentes e (4) pode ser impossvel
consultar todos os tipos de usurios, particularmente para produtos de software de
prateleira. Ento, requisitos de qualidade no podem ser completamente definidos antes do
incio do projeto. Alm disto, necessrio entender as necessidades reais do usurio to
detalhadamente quanto possvel e represent-las nos requisitos. A finalidade no ,
necessariamente, atingir a qualidade perfeita, mas a qualidade necessria e suficiente para
cada contexto de uso especificado quando o produto for entregue e utilizado pelos
usurios [ABNT 2003].
Essa afirmao vem de encontro com a poltica de desenvolvimento do Scrum, pois
ele iterativo e incremental e, por isso, uma vez identificada qualquer modificao ou
adaptao com relao s necessidades do cliente, a mesma pode ser planejada, preparada e
desenvolvida em uma nova Sprint.
Sendo assim, desenvolver um checklist utilizando as prticas de uma norma que h
anos foi elaborada e, alm de ser muito bem conceituada no cenrio nacional e
internacional, permite avaliar um diferencial no contedo e na qualidade de bons requisitos
definidos para alcanar a qualidade do software desenvolvido.

6. Concluso
Os resultados obtidos atravs da validao semntica revelaram a importncia em adotar um
checklist, em cada Sprint do projeto, para verificar a qualidade dos requisitos registrados.

Dessa forma, a elaborao dessa proposta de checklist pode facilitar na identificao de


possveis falhas presentes nos requisitos registrados em cada Sprint de um projeto de
desenvolvimento de software e contribuir para alcanar altos ndices de qualidade do
produto produzido. No entanto, sabe-se que, embora sejam importantes, as perguntas
presentes no checklist so apenas parte do conjunto de fatores que influenciam na qualidade
dos requisitos definidos. Dedicao, interao e auto-organizao, tanto do Time quanto do
Product Owner, so fatores primordiais para a garantia da qualidade do produto final em
relao s expectativas do Product Owner.
O Scrum, por ser uma metodologia que no descreve o que fazer em cada situao
que pode surgir no decorrer do desenvolvimento do projeto, prope uma abordagem onde
o produto desenvolvido e entregue parcialmente (dividido em Sprints). Dessa forma,
verificar a qualidade dos requisitos definidos em cada Sprint uma forma de garantir a
entrega de um produto final que satisfaa as necessidades do Product Owner. Sugere-se a
aplicao do checklist proposto na execuo de um projeto real, do incio ao fim, para
verificar possveis melhorias e avaliar a eficcia da sua utilizao.

Referncias
Agile Manifesto (2001). Manifesto for Agile Software Development. Agile Alliance, 2001.
Disponvel em http://www.agilemanifesto.org/. Acessado em 03.Jan.2012.
Associao Brasileira de Normas Tcnicas (2003). NBR ISO/IEC 9126-1: Engenharia de
Software Qualidade de Produto. Parte 1: Modelo de Qualidade.
Beck, K (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley.
CMMI (2006). Capability Maturity Model Integration (CMMI) for Development. Version
1.2. Disponvel em: http://www.sei.cmu.edu/. Acesso em 24.Mar.2012.
Cockburn, A (2004). Crystal clear: a human-powered methodology for small teams.
Boston: Adisson-Wesley.
Cohn, M. (2004). Advantages of User Stories for Requirements. Informit Network.
Disponvel em http://www.mountaingoatsoftware.com/articles/27-advantages-of-userstories-for-requirements. Acesso em 24.Mar.2012.
Guia do Scrum (2009), Oficial Website. Disponvel em: http://www.scrum.org>. Acessado
em 15 de Fevereiro de 2012.

Highsmith, J (2002). Agile Software Development Ecosystems. Addison -Wesley, Boston,


MA.
IEEE Std 830 (1998) IEEE Recommended Practice for Software Requirements
Specifications. ISBN 0-7381-0332-2.
Kaindl, H., Svetinovic, D (2010). On confusion between requirements and their
representations. Requirements Engineering. Volume 15, Number 3, 307-311.
Maral, A. S. C. (2009). SCRUMMI: Um processo de gesto gil baseado no SCRUM e
aderente ao CMMI. Dissertao de mestrado, Universidade de Fortaleza.
MPS.BR (2009)a. Guia de Implementao Parte 4: Fundamentao para Implementao
do Nvel D do MR-MPS. Disponvel em: http://www.softex.br.
MPS.BR (2009)b. Guia Geral do Modelo de Processo de Software (MPS) Brasileiro.
Disponvel em: http://www.softex.br.
MPS.BR (2009)c. Guia de Implementao Parte 1: Fundamentao para Implementao
do Nvel G do Modelo de Referncia-Modelo de Processo de Software (MR-MPS).
Disponvel em: http://www.softex.br. Acesso em 24.Mar.2012.
Nanda C. S (2007). Using an ethnographic process to conduct requirements analysis for
agile systems development. College of Business and Economics, West Virginia
University.

Disponvel

em

http://www.springerlink.com/content/y68254178n327u27/fulltext.html.

Acessado

em

03.Jan.2012.
PMI (2008). PMBOK Guide: Um guia do conjunto de conhecimentos do gerenciamento de
projetos. Project Management Institute (PMI). Pennsylvania: Project Management
Institute, 4. ed.
RUP (2012)a. Conceitos: Qualidade do Processo. Rational Unified Process (RUP).
Disponvel

em:

http://wthreex.com/rup/process/workflow/environm/co_sqlty.htm.

Acessado em 15.Jan.2012.
RUP

(2012)b.

Conceitos:

Gerenciamento

de

Requisitos.

http://www.wthreex.com/rup/process/workflow/requirem/co_rm.htm.

Disponvel

em

Acesso

em

22.Mar.2012.
Salgado, A (2010). Aplicao de um Processo gil para Implantao de Processos de
Software baseado em Scrum na Chemtech.

Sayo, M., Leite, J. C. S. P. (2003). Rastreabilidade de Requisitos. Departamento de


Informtica, Pontifcia Universidade Catlica do Rio de Janeiro.
Schwaber, K (2004). Agile Project Management With Scrum, Microsoft Press, Redmond,
Washington, USA.
Soares, M. S. (2004). Comparao entre Metodologias geis e Tradicionais para o
Desenvolvimento de Software. Universidade Presidente Antnio Carlos. Gigante.
Sommerville, I (2011). Engenharia de Software. trad. Andr Maurcio de Andrade Ribeiro.
9a ed. So Paulo: Pearson Addison Wesley.
SWEBOK (2004). Guide to the Software Engineering Body of Knowledge. Version. A
project of the IEEE Computer Society Professional Practices Committee. Disponvel em:
http://www.swebok.org.