Requisitos não-funcionais descrevem qualidades do sistema (o que o sistema é) ao invés de seus comportamentos (o que ele faz). Scott Ambler causou muita discussão quando ele recentemente declarou "O conceito de product backlog do Scrum funciona bem para requisitos funcionais simples, mas... se torna insuficiente para requisitos não-funcionais e restrições de arquitetura." em um artigo no Dr. Dobb's Portal.
O artigo despertou discussão no Scrum Development Yahoo Group, à medida que as pessoas compartilhavam seus pontos de vista em como Scrum poderia lidar com requisitos não-funcionais. Ron Jeffries ajudou a focar as discussões fornecendo um requisito de exemplo: que o sistema mantenha um percentual de uptime de 99.9%.
Uma maneira proposta de lidar com este requisito era fazê-lo funcional, e então testável, definindo um time-box em torno dele. O requisito se tornaria: O sistema manterá 99.9% de uptime por [insira um período de tempo aqui]. Requisitos funcionais adicionais foram sugeridos como criar um mecanismo de monitoramento e notificação.
Diversas pessoas sugeriram outra abordagem, onde requisitos deste tipo seriam tratados na 'definição de pronto' do time. Isto é, cada história não é considerada pronta até que tenha sido determinado que a implementação da história provavelmente não cause tempos de parada. Esta análise seria feita através de um processo de revisão e/ou testes de carga, por exemplo.
Deixe um comentário e compartilhe como seus times Scrum lidam com requisitos não-funcionais.