Requisitos não-funcionais são frequentemente associados com o estado do sistema e não com as funcionalidades oferecidas; incluem características do sistema, como escalabilidade, interoperabilidade, facilidade de manutenção, desempenho, portabilidade e segurança. Equipes ágeis geralmente têm dificuldades em estimar e definir requisitos não-funcionais. Em posts e artigos recentes, especialistas apresentaram recomendações e boas práticas para lidar com esses requisitos em projetos ágeis.
Mike Cohn indicou em seu blog que quase todos os requisitos não-funcionais podem ser expressos como histórias de usuário (user stories) e ofereceu alguns exemplos de histórias para mostrar que os requisitos não-funcionais podem se encaixar nesse modelo:
- Como um cliente, quero ser capaz de executar o seu produto em todas as versões do Windows, do Windows 95 até a versão atual.
- Como CTO (diretor de tecnologia), quero que o sistema use nosso banco de dados de pedidos ao invés de criar um novo banco, para não termos mais um banco de dados para manter.
- Como usuário, quero que o site esteja disponível 99,999% do tempo em que tentar acessá-lo, para que eu não fique frustrado e procure outro site.
No entanto, Cohn adverte que o modelo de história de usuário deve ser usado apenas como um exercício de raciocínio, e não como um modelo fixo para todos os requisitos não-funcionais.
Nota: Há um debate sobre o uso do termo "requisito não-funcional". Mike Cohn, por exemplo, prefere usar "restrição"; já Tom Gilb defende o termo "requisito de qualidade".
Em um comentário sobre o post de Cohn, Jason Little sugere que ao invés de tentar resolver os requisitos não-funcionais (RNF) em nível de histórias de usuário, as equipes deveriam ser melhor capacitadas para vê-los como parte do cenário geral. De acordo com ele, sua equipe tentou lidar com os requisitos não-funcionais no nível de histórias, mas isso não ajudou. No entanto, recomenda:
Gosto da ideia de colocar na parede as histórias de usuário para RNF e publicá-las na área de trabalho como um lembrete, para que a equipe leve em consideração essas restrições ao fazer estimativas.
Mike Cohn sugeriu ainda uma forma definitiva de estimar requisitos não-funcionais. Segundo ele, os requisitos não-funcionais têm dois custos associados:
- Custo de conformidade inicial – A quantidade de trabalho que a equipe gastaria para satisfazer o requisito não-funcional. No exemplo citado acima, este seria o esforço gasto em testes de desempenho na quinta sprint.
- Custo de conformidade contínua – Quantidade de trabalho necessário para manter a conformidade com o requisito não-funcional nas sprints subsequentes.
Uma vez que a equipe aceita um requisito não-funcional para o projeto (como fez na quinta sprint), a equipe precisa permanecer em conformidade com o requisito não-funcional até o final do projeto. Realizar testes de desempenho, ou manter a conformidade com qualquer requisito não-funcional, cria uma carga adicional que pode ser vista como um "imposto", e esse imposto deve ser pago regularmente.
Para efeitos de estimativa, Mike Cohn recomenda que estes dois "custos" sejam considerados separadamente. O custo de conformidade inicial deve ser estimado como qualquer outra história de usuário ou item de backlog do produto. Com relação ao custo de conformidade contínua, a equipe e o Product Owner precisam decidir a frequência com que se deve trabalhar para manter a conformidade:
Suponha, por exemplo, que a equipe e o Product Owner concordam em fazer testes de desempenho a cada quatro sprints de duas semanas. A equipe então calcula que levará seis pontos a cada quatro sprints, ou seja 1,5 por sprint. Se a equipe tem a velocidade de 30 pontos por sprint, pode-se considerar que 1,5 pontos são um imposto de 5%.
Nick Xldis faz uma observação interessante sobre o custo de conformidade contínua:
Se o imposto continuar subindo com o tempo, há problemas com a arquitetura adotada ou com o processo que precisam de atenção. Desse modo, o imposto se torna um bom indicador de dívida técnica (technical debt).
Scott Ambler discutiu em um artigo no Dr. Dobbs sobre como gerenciar requisitos não-funcionais através da delegação de poderes para uma equipe de testes independente. Em outra linha de pensamento, Mohamad Kassab e outros autores introduziram um método de medição do tamanho de requisitos não-funcionais (NFSM em inglês) para reduzir incertezas na sua estimativa.
Levando tudo isso em conta, observa-se que tratar requisitos não-funcionais pode não ser tão penoso. O fundamental é lidar com esses requisitos o mais cedo possível e estar atento aos custos contínuos gerados por eles.