7.5 如何获取非功能性需求
像所有功能性需求一样，非功能性需求可能随时出现。但是有一些地方为发现非功能性需求提供了更好的机会。
常见的非功能性需求分类如下：
（1）观感；
（2）易用性；
（3）性能；
（4）可操作性；
（5）可维护性；
（6）安全性；
（7）文化和政策；
（8）法律。(https://www.daowen.com)
从上到下查看这个清单。有哪些是适用的？对薪酬管理系统的功能性需求得到的一些非功能性需求有：
（1）产品将具有一个公司产品的外观；
（2）产品将能被财务人员等便捷使用；
（3）产品将在每月初自动计算上月度薪酬基本情况；
（4）产品调整员工岗位级别的功能只限于人力资源经理；
（5）产品将对每月最终核定的薪资表进行备份，不允许任何人修改，以便审计和核对等。
在对用户进行访谈时持有一份非功能性需求类型的检查清单是有好处的，至少要针对某个使用情况，检查该清单以找出各类需求的实例。请注意，非功能性需求的内容要比一份规矩的检查清单丰富得多。
原型可以用于导出一些非功能性需求。原型让潜在用户有机会尝试功能，因此需求收集者可以观察用户对该功能的考虑方式。这将导致非功能性需求的确定，诸如易用性、观感、安全性等等。
在满足了功能性需求的前提下，可能是非功能性的品质使顾客决定他（她）是否购买产品。请考虑想购买的或已购买的产品的非功能性属性，然后问一下的客户，这与正在关注的产品有多大程度的相关性，客户或者市场部门将告诉你是什么使用户购买该产品。
非功能性需求放在用例规约里是不合适的。通常情况下，在统一软件开发过程中提供了两份模板用来记录非功能性需求，一份是用例补充规约，另一份是软件需求规约。用例补充规约是专门为某个用例服务的，如果某个非功能性需求只与该用例有关，例如仅有某个用例需要特别的安全性，那么可以写在用例补充规约中。软件需求规约是针对整个软件的，所以如果非功能性需求是针对整体软件的，就应当写在软件需求规约文档中。
