PROPOSTA DE AVALIAÇÃO DA QUALIDADE DE
REQUISITOS IDENTIFICADOS POR MEIO DA
ABORDAGEM ÁGIL SCRUM
Renata Dutra Braga1
Olisséa Artiaga da Silva1
1
Pós-Graduação Lato Sensu em Qualidade e Gestão de Software – Pontifícia Universidade
Católica de Goiás (PUC-GO) – Goiânia – Brasil Agosto de 2012.
{renatadbraga, olissea}@gmail.com
Olisséa 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 métodos adotados para alcançar a qualidade de requisitos e
desenvolver um checklist que poderá ser utilizado nas iterações do projeto que utiliza o
Scrum como forma de verificar a qualidade dos requisitos registrados. Métodos: Foi
realizado um estudo bibliográfico, em seguida, a elaboração do checklist e, por fim, a
validação do mesmo entre a comunidade acadêmica e empresas do setor de Tecnologia da
Informação. Resultados: O conteúdo do checklist foi elaborado em conformidade com a
Norma IEEE 830-1998. A validação semântica do mesmo, assim como a sua utilização em
uma Sprint de um projeto real foram realizadas. Conclusão: A utilização do checklist
revelou a importância para identificar e verificar as características de qualidade de cada
requisito definido na Sprint.
Palavras-Chave: Qualidade de Requisitos, Metodologia Ágil, Scrum.
1. Introdução
O mercado, progressivamente, vem exigindo maior qualidade nos produtos desenvolvidos
por empresas em diferentes setores de atividades. No que se refere à indústria de software
não poderia ser diferente.
“A qualidade de software destaca-se como um diferencial de mercado visto que sua
importância está no fato de produzir sistemas cada vez melhores e, assim, assegurar a
satisfação do cliente” [MPS.BR 2009a].
O termo qualidade, dependendo do ponto de vista e contexto, possui diferentes
significados em relação à construção 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 gerência e desenvolvimento de software visando alcançar
a qualidade do produto desenvolvido são encontradas na literatura. Tem-se as abordagens
“tradicionais”, tais como: modelo cascata, evolucionário, 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, além de ser um framework de desenvolvimento e gerência de
projetos de software [Guia do Scrum 2009], ele também pode ser utilizado na implantação
de processo de melhoria de software [Salgado 2010] e gerência de portfólios de projetos
[Schwaber 2004]. Além disto, “o Scrum destaca-se dos demais métodos ágeis pela maior
ênfase dada ao gerenciamento do projeto e reúne atividades de monitoramento e feedback,
em geral, reuniões rápidas e diárias com toda a equipe, visando a identificação e correção
de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento” [Marçal
2009].
Considerando que ao utilizar a abordagem Scrum, as necessidades dos usuários
quanto ao desenvolvimento do software são evoluídas e entendidas a cada iteração no
decorrer da execução do projeto, torna-se fácil entender a descrição que a International
Standardization Organization (ISO) menciona na norma 9126-1 “obter um produto que
satisfaça as necessidades do usuário normalmente requer uma abordagem iterativa para o
desenvolvimento de software com feedback contínuo sob a perspectiva do usuário”. [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 propõe investigar métodos adotados para alcançar a qualidade de
requisitos e desenvolver um checklist que poderá ser utilizado em cada iteração do projeto
que utiliza a metodologia Scrum como forma de verificar a qualidade do conjunto de
requisitos registrados para um determinado domínio de problema.
É importante ressaltar que o foco do presente trabalho está na verificação da
qualidade dos requisitos do produto e não na verificação da qualidade dos requisitos do
processo. Adicionalmente, o mesmo está organizado nas seguintes seções: a seção 2
apresenta uma descrição sobre a qualidade de requisitos, enquanto que as características da
metodologia ágil Scrum são estabelecidas na seção 3; na seção 4, os procedimentos
metodológicos são detalhados; na sessão 5 os resultados encontrados são caracterizados,
assim como uma discussão sobre o assunto é apresentada. Por fim, na sessão 6, as
considerações finais são apresentadas.
2. Qualidade de Requisitos
A qualidade de software é definida pelo Instituto de Engenheiros Eletricistas e Eletrônicos,
ou em inglês 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 usuários [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 [SAYÃO 2003]. Na maioria desses
modelos, uma das áreas que possui maior preocupação e, por isso, é uma das primeiras a
ser implementada é a área de Gerência de Requisitos [MPS.BR (2009)c], [CMMI 2006].
1
Sprint “é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento”
[Agile Manifesto 2011].
Dessa forma, é possível perceber que especificar requisitos com qualidade é
essencial para alcançar a qualidade do software desejada, tanto na perspectiva do cliente
quanto técnica.
O termo requisito é definido como “uma condição ou capacidade necessária para um
usuário resolver um problema ou atingir um objetivo” [IEEE 1998] ou ainda, é “uma
condição 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 características para um requisito (ou, o documento de
requisito) ter uma boa qualidade, tais como, ser correto, não ambíguo, completo,
consistente, classificado por importância, verificável, modificável e rastreável [IEEE 1998].
A definição de cada característica é apresentada na tabela a seguir.
Tabela 1 - Características de uma boa especificação de requisitos.
Fonte: Norma IEEE 830-1998.
Características
Correto
Definição
É correto se, e somente se, cada requisito expresso for encontrado
também no software.
Não ambíguo
É não ambíguo se, e somente se, cada requisito declarado seja
suscetível a apenas uma interpretação.
Completo
É completo se, e somente se, conter toda e apenas a informação
necessária 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 importância
Se existe indicações no documento quanto à importância ou
/ estabilidade
estabilidade do requisito.
Verificável
É verificável se, e somente se, para cada um dos requisitos contidos no
documento, existe um processo finito e economicamente viável
através do qual uma pessoa ou máquina possa assegurar que o produto
de software atende ao requisito.
Modificável
É modificável se, e somente se, modificações possam ser agregadas ao
documento de forma fácil, completa e consistente, com relação a sua
estrutura e estilo.
Rastreável
É rastreável se, e somente se, a origem de cada um de seus requisitos é
clara e a referência a cada um deles é facilitada nos documentos
subsequentes do processo ou em uma melhoria da documentação do
sistema.
Assim como a Norma IEEE 830-1998, existem outras abordagens que visam
especificar requisitos com boa qualidade. Dentre elas, é possível mencionar a ISO 122072008 e ISO 9001, bem como os modelos de processos de software que definem um padrão
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 crítico de sucesso para a
indústria de software” [MPS.BR 2009b].
3. Métodos Ágeis: Características do Scrum
Em 2001, dezessete especialistas reuniram-se e compartilharam princípios comuns entre
todos os métodos ágeis existentes, criando assim o Manifesto Ágil e a Aliança Ágil [Soares
2004].
No total, doze princípios foram definidos, entre eles a satisfação do cliente,
adequação a mudanças, indivíduos motivados e entrega rápida de software funcionando
estão contemplados. A tabela a seguir, apresenta tais princípios.
Tabela 2 - Princípios por trás do manifesto ágil. Fonte [Agile Manifesto 2011].
1.
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de
software de valor.
2.
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se
adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
3.
Entregar software funcionando com frequência, na escala de semanas até meses, com
preferência aos períodos mais curtos.
4.
Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e
diariamente, durante todo o curso do projeto.
5.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte
necessário, e confiar que farão seu trabalho.
6.
Método mais eficiente e eficaz de transmitir informações para, e por dentro de um Time de
desenvolvimento, é através de uma conversa cara a cara.
7.
Software funcional é a medida primária de progresso.
8.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e
usuários, devem ser capazes de manter indefinidamente, passos constantes.
9.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de Times auto-organizáveis.
12. Em intervalos regulares, o Time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo.
Tal manifesto propõe que novas maneiras para desenvolver software estão sendo
descobertas, onde através deste trabalho, passam a valorizar [Agile Manifesto 2001]:

Indivíduos e interação entre eles mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano
O framework Scrum é uma abordagem empírica baseada na flexibilidade,
adaptabilidade e produtividade em que a escolha das técnicas de desenvolvimento fica a
cargo do time [Marçal 2009].
Três pilares asseguram a implementação dessa abordagem empírica [Guia do Scrum
2009]:

Transparência: garante que aspectos do processo que afetam o resultado devem ser
visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem
ser transparentes, mas também o que está sendo visto deve ser conhecido.

Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma
frequência suficiente para que variações inaceitáveis no processo possam ser
detectadas.

Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos
do processo estão fora dos limites aceitáveis e que o produto resultante será
inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse
ajuste deve ser feito o mais rápido possível 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 é possível perceber que o framework Scrum sugere
que as equipes sejam pequenas, entre cinco e, no máximo, sete pessoas. “Quando há menos
do que cinco membros em um Time, há menor interação e, como resultado, há menor ganho
de produtividade” [Guia do Scrum 2009]. O framework, também, sugere que os ciclos de
cada Sprint sejam curtos de no máximo trinta dias.
A fase de preparação, presente na Figura 1, “tem por objetivo identificar os
requisitos e priorizá-los (pelo menos para a próxima Sprint). Divide o Product Backlog em
Sprints, de acordo com a priorização realizada, levando em consideração a produtividade
do Time” [Marçal 2009]. É nesta fase que o resultado do presente trabalho se propõe a
avaliar e verificar a qualidade de tais requisitos identificados.
3.1. Papéis do Scrum
A metodologia ágil Scrum estabelece um framework iterativo e incremental, onde as
atividades executadas por cada Time são exercidas por três principais papéis [Schwaber
2004] [Guia do Scrum 2009]:

Scrum Master: é responsável por garantir que o processo seja compreendido e
seguido, em outras palavras, que o Time é adepto aos valores, às práticas e às regras
do Scrum; e também é responsável por remover os impedimentos do projeto.

Product Owner: é responsável 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 construídas prioritariamente. Somente o Product Owner muda a prioridade de
um item.

Time: é responsável por executar o trabalho propriamente dito. O Time consiste em
desenvolvedores com todas as habilidades necessárias para transformar os requisitos
do Product Owner em um pedaço potencialmente entregável do produto ao final da
Sprint. Ele é auto-organizável.
3.2. Artefatos
Ao longo do desenvolvimento do produto, poucos artefatos são 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 necessário no
produto.

Sprint Backlog: é uma lista de tarefas para transformar o Product Backlog, por uma
Sprint, em um incremento do produto potencialmente entregável. 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. Métodos
Esta é uma pesquisa aplicada que utilizará estudo bibliográfico, de campo e a elaboração de
um checklist que objetiva verificar a qualidade dos requisitos registrados por meio da
abordagem ágil Scrum.
Para o estudo bibliográfico será realizada a busca em diferentes bases de dados
científicas (IEEE Xplore, ACM, Periódicos da CAPES, Google Scholar), assim como em
revistas e livros.
Para a elaboração do checklist, após a análise da literatura por meio do estudo
bibliográfico, a ferramenta BrOffice.org Calc será utilizada. Tal checklist será validado
entre a comunidade acadêmica e empresas do setor de Tecnologia da Informação, utilizando
a tecnologia Google Docs.
5. Resultados e Discussão
Como resultado da análise da literatura e pesquisas para verificar a qualidade de requisitos,
foi proposto um checklist, estruturado em um conjunto de perguntas em conformidade com
as características de qualidade estabelecidas pela Norma IEEE 830-1998 [IEEE 1998].
A tabela a seguir ilustra o checklist elaborado que contém, para cada característica
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/Não 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 não funcional) foi registrado de
forma clara e objetiva?
C.3
O cliente reflete, quando aplicável, se o requisito registrado
atende às suas reais necessidades?
NA - NÃO AMBÍGUO
NA.1
O requisito registrado na Sprint é suscetível a apenas uma
interpretação?
NA.2
De acordo com o requisito registrado, é possível validar seu
conteúdo com o cliente?
NA.3
De acordo com o requisito registrado, é possível 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 definição das respostas do
software a todos os tipos de dados de entrada em todas as
situações possíveis, válidas ou inválidas?
CO.3
Os requisitos alocados na Sprint contêm toda e apenas a
informação necessária 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 IMPORTÂNCIA
CI.1
Uma escala de prioridade/estabilidade para os requisitos foi
definida juntamente com o cliente?
CI.2
Existe indicação quanto à importância ou à estabilidade do
requisito definido na Sprint?
CI.3
A prioridade/estabilidade do requisito foi classificada juntamente
com o cliente?
V - VERIFICÁVEL
V.1
É possível determinar se o requisito registrado é satisfeito pela
implementação no final da Sprint?
V.2
O requisito definido é passível 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 - MODIFICÁVEL
M.1
Um mecanismo que facilita a modificação de requisitos na Sprint
é utilizado?
M.2
Antes de realizar a modificação de requisito, os impactos são
analisados?
M.3
Modificações podem ser agregadas no requisito definido na Sprint
de forma fácil, completa e consistente?
R - RASTREÁVEL
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
formulário desenvolvido para realizar a validação do mesmo encontra-se em
https://docs.google.com/spreadsheet/viewform?formkey=dHJzWEJQeEJsZ1ZJU2hoNlZ4b
TA1eGc6MQ8.
A validação semântica do checklist elaborado foi realizada na Fábrica de Software
de uma instituição de ensino superior privada e outra pública, ambas localizadas em
Anápolis-GO. A mesma validação, também, foi realizada pela comunidade acadêmica e por
alguns colaboradores de empresas do setor de Tecnologia da Informação (TI) localizados
em Goiânia-GO. Foram sugeridas algumas melhorias no checklist, as quais estão descritas
abaixo:

Acrescentar itens a verificar no checklist relacionados aos tópicos 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 consideração a
rastreabilidade e prevenção de mudanças.
O checklist foi utilizado em uma Sprint, com duração de uma semana, em um
projeto real em desenvolvimento na Fábrica de Software de uma instituição de ensino
superior privada, localizada em Anápolis-GO.
Na Sprint, sete requisitos foram registrados. Para cada um deles, uma verificação foi
realizada tomando como base os itens a verificar presente no checklist. Dos vinte e cinco
itens a verificar, somente um de cada característica foi escolhido e os respectivos resultados
estão ilustrados nos gráficos a seguir. O número do ID (identificador) é o mesmo definido
na Tabela 3.
Tabela 4 - Interpretação dos resultados
ID
C.1
Gráfico
Interpretação
De acordo com a verificação,
57% dos requisitos foram
implementados parcialmente
na Sprint, enquanto que 43%
foram
completamente
implementados.
Percebe-se que o time não
teve um desempenho 100%
esperado. Novas adaptações
devem ser analisadas para
melhorar o desempenho da
equipe.
NA.1
71% dos requisitos registrados
na Sprint são suscetíveis a
apenas
uma
interpretação.
Somente 14% deles atende
parcialmente esse item e os
demais 14% são ambíguos.
CO.3
Nessa
detectado
verificação
que
foi
43%
dos
requisitos alocados na Sprint,
contêm toda e somente a
informação necessária para
produzir o software, enquanto
que 29% dos requisitos atende
parcialmente essa verificação.
CT.1
43% dos requisitos registrados
na Sprint não está em conflito
com qualquer outro requisito
definido
quanto
tanto
em
na
mesma
outra
Sprint.
Porém, uma taxa de 29%
possui algum tipo de conflito
e os outros 29% não atende
essa verificação.
CI.3
Essa verificação demonstrou
que a prioridade de 71% dos
requisitos
é
classificada
juntamente com o cliente (ou
o Product Owner). 14% dos
requisitos não se define a
prioridade juntamente com o
cliente, enquanto que 14%
não define nenhum tipo de
prioridade.
V.1
A
avaliação
desse
item
permite constatar que 57%
dos requisitos é satisfeito pela
implementação ao término da
Sprint de forma parcial. Um
valor
de
43%
atende
completamente
essa
satisfação. Um fator positivo é
que 0% não é satisfeito ou não
atende.
M.1
O
resultado
desse
item
demonstra que um mecanismo
que
objetiva
modificação
registrados
facilitar
de
na
a
requisitos
Sprint
é
utilizado em 43% deles. 29%
não 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%
não
utilizam
nenhum tipo de identificador.
Após a utilização do checklist na Sprint desse projeto real, a análise dos resultados
obtidos foi realizada, assim como uma reunião de lição aprendida. Nesta reunião todas as
sugestões e melhorias identificadas com a aplicação do checklist foram registradas e os
métodos para melhorar para a próxima Sprint no projeto foram identificados.
É importante ressaltar que a adoção do Scrum é de suma importância para
identificar e entender as reais necessidades do cliente (Product Owner) e fazê-lo entender
(ou ele mesmo chegar nesse objetivo) quais são suas necessidades. E, então, em cada
Sprint, estabelecer um planejamento, executá-lo e entregar uma versão funcionando do
produto ao Product Owner.
Segundo a ISO, “as necessidades explicitadas pelo usuário nem sempre refletem
suas reais necessidades porque: (1) frequentemente, o usuário não está consciente de suas
necessidades reais; (2) as necessidades podem mudar após terem sido explicitadas; (3)
usuários diferentes podem ter ambientes operacionais diferentes e (4) pode ser impossível
consultar todos os tipos de usuários, particularmente para produtos de software de
prateleira. Então, requisitos de qualidade não podem ser completamente definidos antes do
início do projeto. Além disto, é necessário entender as necessidades reais do usuário tão
detalhadamente quanto possível e representá-las nos requisitos. A finalidade não é,
necessariamente, atingir a qualidade perfeita, mas a qualidade necessária e suficiente para
cada contexto de uso especificado quando o produto for entregue e utilizado pelos
usuários” [ABNT 2003].
Essa afirmação vem de encontro com a política de desenvolvimento do Scrum, pois
ele é iterativo e incremental e, por isso, uma vez identificada qualquer modificação ou
adaptação com relação às necessidades do cliente, a mesma pode ser planejada, preparada e
desenvolvida em uma nova Sprint.
Sendo assim, desenvolver um checklist utilizando as práticas de uma norma que há
anos foi elaborada e, além de ser muito bem conceituada no cenário nacional e
internacional, permite avaliar um diferencial no conteúdo e na qualidade de bons requisitos
definidos para alcançar a qualidade do software desenvolvido.
6. Conclusão
Os resultados obtidos através da validação semântica revelaram a importância em adotar um
checklist, em cada Sprint do projeto, para verificar a qualidade dos requisitos registrados.
Dessa forma, a elaboração dessa proposta de checklist pode facilitar na identificação de
possíveis falhas presentes nos requisitos registrados em cada Sprint de um projeto de
desenvolvimento de software e contribuir para alcançar altos índices de qualidade do
produto produzido. No entanto, sabe-se que, embora sejam importantes, as perguntas
presentes no checklist são apenas parte do conjunto de fatores que influenciam na qualidade
dos requisitos definidos. Dedicação, interação e auto-organização, tanto do Time quanto do
Product Owner, são fatores primordiais para a garantia da qualidade do produto final em
relação às expectativas do Product Owner.
O Scrum, por ser uma metodologia que não descreve o que fazer em cada situação
que pode surgir no decorrer do desenvolvimento do projeto, propõe 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 satisfaça as necessidades do Product Owner. Sugere-se a
aplicação do checklist proposto na execução de um projeto real, do início ao fim, para
verificar possíveis melhorias e avaliar a eficácia da sua utilização.
Referências
Agile Manifesto (2001). Manifesto for Agile Software Development. Agile Alliance, 2001.
Disponível em http://www.agilemanifesto.org/. Acessado em 03.Jan.2012.
Associação Brasileira de Normas Técnicas (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. Disponível 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.
Disponível em http://www.mountaingoatsoftware.com/articles/27-advantages-of-userstories-for-requirements. Acesso em 24.Mar.2012.
Guia do Scrum (2009), Oficial Website. Disponível 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.
Marçal, A. S. C. (2009). SCRUMMI: Um processo de gestão ágil baseado no SCRUM e
aderente ao CMMI. Dissertação de mestrado, Universidade de Fortaleza.
MPS.BR (2009)a. Guia de Implementação – Parte 4: Fundamentação para Implementação
do Nível D do MR-MPS. Disponível em: http://www.softex.br.
MPS.BR (2009)b. Guia Geral do Modelo de Processo de Software (MPS) Brasileiro.
Disponível em: http://www.softex.br.
MPS.BR (2009)c. Guia de Implementação – Parte 1: Fundamentação para Implementação
do Nível G do Modelo de Referência-Modelo de Processo de Software (MR-MPS).
Disponível 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.
Disponível
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).
Disponível
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.
Disponível
em
Acesso
em
22.Mar.2012.
Salgado, A (2010). Aplicação de um Processo Ágil para Implantação de Processos de
Software baseado em Scrum na Chemtech.
Sayão, M., Leite, J. C. S. P. (2003). Rastreabilidade de Requisitos. Departamento de
Informática, Pontifícia Universidade Católica do Rio de Janeiro.
Schwaber, K (2004). Agile Project Management With Scrum, Microsoft Press, Redmond,
Washington, USA.
Soares, M. S. (2004). Comparação entre Metodologias Ágeis e Tradicionais para o
Desenvolvimento de Software. Universidade Presidente Antônio Carlos. Gigante.
Sommerville, I (2011). Engenharia de Software. trad. André Maurício de Andrade Ribeiro.
9a ed. São 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. Disponível em:
http://www.swebok.org.