PROPOSTA DE AVALIAÇÃO DA QUALIDADE DE REQUISITOS IDENTIFICADOS POR MEIO DA ABORDAGEM ÁGIL SCRUM

Transcrição

1 PROPOSTA DE AVALIAÇÃO DA QUALIDADE DE REQUISITOS IDENTIFICADOS POR MEIO DA ABORDAGEM ÁGIL SCRUM Renata Dutra Braga 1 Olisséa Artiaga da Silva 1 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 {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 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 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.

2 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 obter um produto que satisfaça as necessidades do usuário normalmente requer uma abordagem iterativa para o

3 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 Sprint 1, 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].

4 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 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 Características Definição Correto É 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

5 subsequentes do processo ou em uma melhoria da documentação do sistema. Assim como a Norma IEEE , existem outras abordagens que visam especificar requisitos com boa qualidade. Dentre elas, é possível mencionar a ISO 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.

6 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.

7 Figura 1 - Processo de Desenvolvimento do Scrum. Fonte: 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 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.

8 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 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.

9 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 [IEEE 1998]. A tabela a seguir ilustra o checklist elaborado que contém, para cada característica presente na Norma IEEE , os itens a verificar nos requisitos registrados em cada Sprint do projeto. Tabela 3 - Checklist proposto. Fonte: O autor. ID Itens a Verificar Escala 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 (0- NA/Não Atende; 5- Atende Parcialmente; 10- Atende Completamente)

10 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?

11 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 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.

12 Tabela 4 - Interpretação dos resultados ID Gráfico Interpretação C.1 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 verificação foi detectado que 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 tanto na mesma quanto em outra Sprint. Porém, uma taxa de 29% possui algum tipo de conflito e os outros 29% não atende essa verificação.

13 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 facilitar a modificação de requisitos registrados na 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.

14 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.

15 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, Disponível em Acessado em 03.Jan Associação Brasileira de Normas Técnicas (2003). NBR ISO/IEC : 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: Acesso em 24.Mar 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 Acesso em 24.Mar Guia do Scrum (2009), Oficial Website. Disponível em: Acessado em 15 de Fevereiro de 2012.

16 Highsmith, J (2002). Agile Software Development Ecosystems. Addison -Wesley, Boston, MA. IEEE Std 830 (1998) IEEE Recommended Practice for Software Requirements Specifications. ISBN Kaindl, H., Svetinovic, D (2010). On confusion between requirements and their representations. Requirements Engineering. Volume 15, Number 3, 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: MPS.BR (2009)b. Guia Geral do Modelo de Processo de Software (MPS) Brasileiro. Disponível em: 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: Acesso em 24.Mar 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 Acessado em 03.Jan 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: Acessado em 15.Jan RUP (2012)b. Conceitos: Gerenciamento de Requisitos. Disponível em Acesso em 22.Mar Salgado, A (2010). Aplicação de um Processo Ágil para Implantação de Processos de Software baseado em Scrum na Chemtech.

17 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: