de NFRs, precisamos tratar quatro pontos principais:Priorizacao: Assim como defeitos e historias de usuarios, as restricoes de requisitos nao funcionais devem ter prioridades diferentes. Por exemplo, tratar ou validar informacoes pouco confiaveis nos cabecalhos da resposta HTTP, para prevenir o HTTP Response Splitting (divisao da resposta HTTP) nao e tao importante como tratar dados pouco confiaveis provenientes do HTML para evitar Cross Site Scripting. Deve-se partir do principio que os desenvolvedores raramente terao tempo para tratar cada restricao, e oferecer um mecanismo para sugerir prioridades relativas entre as restricoes em questao.Dizemos "sugerir", pois as prioridades podem mudar dependendo do contexto e os desenvolvedores precisam decidir quais sao as prioridades relativas em seus codigos especificos. Pode-se escolher usar prioridades simples como "Alta, Media e Baixa" ou uma escala numerica, como de 1 a 10.Filtragem: Utilizando criterios simples, pode-se frequentemente reduzir ou remover grandes quantidades de restricoes de NFRs para uma historia de usuario especifica. Por exemplo, suponha que se esteja trabalhando em uma historia de usuario que nao tenha influencia sobre a camada de visualizacao. Pode-se, com seguranca, ignorar um muitas restricoes particulares da camada de apresentacao. Utilizando-se tags ou mesmo um filtro simples do Excel, pode-se cortar o numero total de restricoes para uma historia em particular. Abaixo estao alguns exemplos de filtros de seguranca relevantes para aplicacoes web:A historia preve a entrada de dados pelo usuario?A historia envolve o uso de informacoes confidenciais, tais como senhas, numeros de cartoes de credito ou informacoes nao publicas?A resultado da historia e uma saida como uma pagina web, gerada ou alterada pelo usuario?Ha interacao com banco de dados?A historia envolve a utilizacao de chamadas a APIs RESTful ou SOAP, seja para consumo, seja para exposicao de informacoes?Ha consumo de informacoes protegidas (ex.: informacao que nem todos os usuarios deveriam poder ver/modificar)?Contexto: E mais facil para os desenvolvedores lembrar-se de aplicar as restricoes quando estao codificando ou definindo historias de usuario. Seria ideal que pudessem ter acesso a lista de restricoes dentro do proprio IDE, ou em algum sistema de tarefas, para acesso as restricoes durante a codificacao. Muitos IDEs tem a funcionalidade de navegadores web embutidos; assim, a utilizacao de uma pagina web leve ou um site SharePoint podem ajudar a atingir este objetivo.Framework: Frameworks podem reduzir bastante o "tributo" cobrado pelas restricoes. Por exemplo, um framework como Django, que ja inclui protecao contra CSRF, torna possivel aos desenvolvedores ignorar uma restricao, exceto se ativamente desligarem a protecao fornecida. Em nossa experiencia, as maiores aplicacoes tem algum framework customizado que requer investimento muito alto no inicio do projeto. Mas caso as restricoes sejam entendidas como uma especie de "tributo" cobrado a cada historia de usuario desenvolvida, a reducao do numero de restricoes e semelhante a reducao permanente da aliquota de um tributo.ValidacaoO tratamento proativo das NFRs e importante, mas nao dispensa validacoes posteriores. Caso se possua a pratica de revisao manual do codigo, os revisores podem prestar atencao a requisitos nao funcionais listados explicitamente como criterios de aceite nas historias. Muitas restricoes, contudo, podem ser traicoieras, ou trabalhosas para serem encontradas por meio de