usuario. Tratam-se de uma especie de "tributo" cobrado sobre os esforcos de desenvolvimento. Exigir de todos os desenvolvedores a validacao de informacoesprovenientes de campos de formularios HTTP em aplicacoes web e um exemplo de restricao.Lidar com a primeira categoria e simples e direto; basta criar um conjunto de historias de requisitos nao funcionais e adiciona-las a fila de itens a serem desenvolvidos, como por exemplo um backlog. Lidar com a segunda categoria e consideravelmente mais dificil.Desafios com restricoes de requisitos nao funcionaisAlguns agilistas propuseram algumas solucoes para o trabalho com restricoes, incluindo:Adicionar as devidas restricoes como criterios de aceite em algumas historias de usuario especificas;Manter uma lista de todas as restricoes em um repositorio central, como um documento afixado de forma visivel em uma parede ou numa wiki.Nenhuma das abordagens oferece um mecanismo para selecionar quais restricoes podem ser aplicadas a quais historias. Nossa experiencia no mapeamento de requisitos de seguranca naSD Elements indica que essas tecnicas tendem a ser dificies de escalar. Considere, por exemplo, o subconjunto de requisitos de seguranca para uma aplicacao web tipica:Vincular variaveis em declaracoes SQL para prevenir injecao de SQL (SQL injection);Verificar a integridade de informacoes somente-leitura fornecidas pelo cliente com o intuito de prevenir a manipulacao de parametros;Fazer o "escape"de informacoes nao-confiaveis no HTML, nos atributos HTML, nas folhas de estilo CSS e em codigo JavaScript, para prevenir o Cross Site Scripting (XSS);Evitar XSS sobre DOM no JavaScript do lado do cliente;Utilizar aritmetica segura para evitar estouro de inteiros;Desabilitar redirecionamentos externos para evitar redirecionamentos abertos;Autorizar paginas protegidas para prevenir a escalada de privilegios;Utilizar tokens contra a "Falsificacao de solicitacao entre sites" (CSRF - Cross Site Request Forgery);Validar a entrada de dados;Utilizar expressoes regulares nao vulneraveis a ataques de negacao de servico;Implementar autenticacao transacional para transacoes de alto valor;Nao gravar senhas no codigo ou em arquivos de configuracao.Estas provavelmente representam menos da metade das restricoes que os desenvolvedores precisam considerar ao implementar uma historia de usuario. E o conjunto de restricoes aumenta quando o ambiente tiver que ser aderente a padroes como o Padrao de Seguranca da Informacao da Industria do Pagamento por Cartoes de Credito (PCI DSS). Caso sejam adicionadas outras restricoes de requisitos nao funcionais (NFRs), como acessibilidade, a lista de restricoes pode crescer rapidamente. Quando a lista comeca a crescer sem controle, nossa experiencia e que os desenvolvedores passam a ignora-la completamente, apoiando-se apenas em suas memorias para aplicar as restricoes em requisitos nao funcionais.Como o numero de NFRs continua crescendo indefinidamente em dominios especializados como seguranca de aplicacao, o peso cognitivo sobre a memoria dos desenvolvedores e imenso. Portanto, existe uma enfase muito grande em tecnologias de analise estatica para detectar restricoes de NFRs no codigo. Estudos indicam que a analise estatica pode detectarpor volta de 40% dos defeitos possiveis de se prevenir. Isso ainda leva a uma grande quantidade de restricoes que escapam da deteccao da analise estatica, incluindo controles de seguranca especificos de dominio. Sem contar o desafio de buscar falsos positivos gerados pela analise estatica sem customizacao.Tratando desafios de restricoes de NFRsPara resolver o problema do excesso de restricoes