验证
　　虽然主动处理NFR很重要，但仍有必要进行验证。如果你有手动代码审查（Code Review）的经验，可以检查用户故事中作为验收标准出现的NFR。然而，如果仅使用手动代码审查，很多约束的验证将是非常棘手或者繁重的。静态分析工具则可以自动检查编码标准的遵守情况，其中一些产品特别关注安全方面。将你的静态分析工具与持续集成过程整合在一起，可以帮助你始终遵守编码标准。但也务必注意，不要一味依赖于代码审查。防范特定领域缺陷——如HTTP参数篡改——的NFR要求对背后的业务领域有深刻的理解。将手动验证与针对特定攻击的自动测试结合起来，可以帮助我们建立一套对于特定领域缺陷拥有更强抵抗力的系统。
　　可见度
　　难以将安全需求集成进敏捷项目的另一方面原因是安全需求通常缺乏可见度。面向客户的会议，如Scrum的Sprint评审会议)，容易使开发人员产生一种固有的倾向，即实现用户故事或修复缺陷时倾向于那些能直接改善用户体验的故事或缺陷。一部分非功能属性，例如易用性和性能，对于系统的使用体验有具体的影响，因此也比较容易向客户展示。而另外一些——如安全性——却很难在Sprint评审会议上给客户留下很好的印象。实际上，某些安全特性，如账号封锁（Account Lockout），可能给客户体验带来相当负面的影响。大多数安全特性对系统的影响，普通用户很难察觉。因此，安全性NFR是不可见的，它们必须和可见度更好的特性竞争，以夺得宝贵的开发周期。在软件开发初期，准确的说在程序员应该构建安全特性的时候，处理这些“隐形”需求的机会成本会特别高。
　　让安全特性可见
　　对于敏捷团队来说，没有“银弹”能让安全需求在开发伊始拥有高优先级。但有一些方法可以让安全NFR对客户和/或PO可见。
　　图形化安全用户故事：如果你在应用程序安全方面足够专业，可以针对已知的安全弱点创建一套全面的安全控制。然后将它们与NFR用户故事匹配起来，并绘制简单的图形，用以说明系统中已实现的和未实现的安全用户故事数量。这个图可以放在大型可视图表中。

 　　图1：安全用户故事图

　　当然，这个图没必要局限于安全用户故事，你可以将其他重要的NFR囊括进来。实际上，你可以使用故事点（Story Point）取代用户故事数量，从而更准确的反映工作量。另外，你有可能希望图中只记录那些针对高风险安全问题的、拥有高优先级的用户故事或控制。每完成一个故事，“已完成”数量都会增加，客户也会籍由此图直观地了解项目的进度。
　　展示可利用性（exploitability）：没有什么比可利用性展示更能让人们理解一个安全漏洞的各个方面了。这是安全性渗透测试和漏洞评估的主要区别。你可以展示在上一版本的应用中如何成功地利用了漏洞，而在新的版本中却没办法这么做了。然后你可以从对业务和／或客户影响的角度解释漏洞的方方面面。这非常有利于解释为什么在安全控制上花的时间是合理的。
　　结论
　　主动处理NFR，特别是安全特性，在敏捷环境中非常重要。不少专家对于如何处理此类需求——特别是当它们与创建用户故事相关时——给出了建议。全面地处理约束是个相当大的挑战。记住本文讨论的提议，你可以极大地增加维护一系列约束的价值。即使不能完全做到以上所提的四点内容以改善对约束的管理，但从长远来看，任何一点改进都能带来很高的回报。进行验证能保证团队始终遵守NFR。后，提高安全特性的可见度，可以让你证明用在NFR上的时间是合理的，算它们对系统的改善不能反映到用户体验上。