BT
x Por favor preencha a pesquisa do InfoQ !

Dominando os Requisitos Não-funcionais

por Vikas Hazrati , traduzido por Reinaldo Braga em 27 Jun 2011 |

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. 

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.