发现非功能需求

像所有需求一样，非功能需求可能随时出现。但是，有一些地方为我们发现非功能需求提供了更好的机会。
1用博客记录需求
如果你正试图提取非功能需求，博客和wiki会相当有用。利用模板中的非功能需求小节和子小节作为标题开始博客，即不要只说“易用性需求”，而是用子小节“易于使用”、“个性化和国际化”、“学习的容易程度”、“可理解性和礼貌”以及“可用性”。不要限制人们的贡献，要鼓励你的团队和利益相关者，在这些分类中贡献出他们认为正确的产品属性。你肯定会收到一些解决方案，它们不是需求，但你可以基于它们进行抽象，发现背后的需求。
2 用例
你可以从非功能需求的角度来考虑每个用例。例如，IceBreaker产品有一个产品用例名为“检测结冰的道路”。它得到道路除冰调度表，展示了要处理的道路和分配给这些道路的卡车。相关的利益相关者告诉你，调度表会被一名初级或中级工程师使用。对于每种非功能需求类型，与这些利益相关者探讨产品的需求。
例如(我们按需求在模板中的顺序列出它们)，进度表的观感应该让新工程师(他们的流动率很高)立即感到舒服。
描述:该产品应该让新工程师觉得熟悉
理由:我们常常会有新的初级工程师，希望产品的外观能让他们接受。
量化这项需求有一点困难，但在阅读了第12章之后应该能为它写下合适的验收标准。目前写下利益相关者的意图就够了。
接下来是易用性和人性化需求。利益相关者希望调度表能让工程师易于指派卡车到正确的道路上。需求看起来是这样的。
描述:该产品应该产生一份易于阅读的调度表。
理由:只处理正确的道路是很重要的。
这个理由告诉我们，希望调度表易读与道路处理的准确性有关。因此，在为这项需求编写验收标准时，可以加入正确处理的道路作为量化指标，从而检测产品是否成功实现这项需求。执行需求关注多少、多快等问题。在这个例子中，调度表必须在工程师等待的数秒中内产生:
用户发出请求后，产品应该在3秒内得到调度表。

还有另一项执行需求:
产品应该能够对5000条道路进行冰情预测计算。
操作和环境需求关注物理操作环境。在IceBreaker的例子中，它们对所有产品用例来说都是样的。自然，只需要写一次即可，它们从总体上描述了产品要求的计算机、数据库等。
可维护性和支持需求规定了一些特殊条件，适用于保持产品更新或移植到另一个环境。IceBreaker产品的客户打算为不同的道路管理部门监控道路，所以可维护性需求是这样写的:
产品应该在2天内加入新的道路管理区域。
同时，因为这个产品用例常常在夜间启动，所以我们有如下需求。
描述:产品应该实现自支持。
理由:帮助平台会没有人。也没有其他用户可以提供帮助。安全性需求关注对产品的访问。对于IceBreaker产品来说，客户不希望未授权的人运行调试程序:
产品应该只允许高级或更高级别的工程师访问。
也存在审计需求，道路管理部门必须能够证明他们正确地处理了道路:
对所有进行调度的情况，产品应该保留所有的冰情预测。
这个产品用例的文化需求是考虑适合工程师的工作方式:
产品应该使用工程师社区接受的术语
最后是法律需求。许多道路管理部门有法定的义务，要证明他们尽职地监控并处理了他们控制的道路:
产品应该得到所有道路调度表和后续处理的审计报告，这必须符合IS093.080.00.