像所有需求一样非功能需求可能随时出现。但是有一些地方为我们发现非功能需求提供了更好的机会。1用博客记录需求如果你正试图提取非功能需求博客和wiki会相当有用。利用模板中的非功能需求小节和子小节作为标题开始博客即不要只说“易用性需求”而是用子小节“易于使用”、“个性化和国际化”、“学习的容易程度”、“可理解性和礼貌”以及“可用性”。不要限制人们的贡献要鼓励你的团队和利益相关者在这些分类中贡献出他们认为正确的产品属性。你肯定会收到一些解决方案它们不是需求但你可以基于它们进行抽象发现背后的需求。2 用例你可以从非功能需求的角度来考虑每个用例。例如IceBreaker产品有一个产品用例名为“检测结冰的道路”。它得到道路除冰调度表展示了要处理的道路和分配给这些道路的卡车。相关的利益相关者告诉你调度表会被一名初级或中级工程师使用。对于每种非功能需求类型与这些利益相关者探讨产品的需求。例如(我们按需求在模板中的顺序列出它们)进度表的观感应该让新工程师(他们的流动率很高)立即感到舒服。描述:该产品应该让新工程师觉得熟悉理由:我们常常会有新的初级工程师希望产品的外观能让他们接受。量化这项需求有一点困难但在阅读了第12章之后应该能为它写下合适的验收标准。目前写下利益相关者的意图就够了。接下来是易用性和人性化需求。利益相关者希望调度表能让工程师易于指派卡车到正确的道路上。需求看起来是这样的。描述:该产品应该产生一份易于阅读的调度表。理由:只处理正确的道路是很重要的。这个理由告诉我们希望调度表易读与道路处理的准确性有关。因此在为这项需求编写验收标准时可以加入正确处理的道路作为量化指标从而检测产品是否成功实现这项需求。执行需求关注多少、多快等问题。在这个例子中调度表必须在工程师等待的数秒中内产生:用户发出请求后产品应该在3秒内得到调度表。还有另一项执行需求:产品应该能够对5000条道路进行冰情预测计算。操作和环境需求关注物理操作环境。在IceBreaker的例子中它们对所有产品用例来说都是样的。自然只需要写一次即可它们从总体上描述了产品要求的计算机、数据库等。可维护性和支持需求规定了一些特殊条件适用于保持产品更新或移植到另一个环境。IceBreaker产品的客户打算为不同的道路管理部门监控道路所以可维护性需求是这样写的:产品应该在2天内加入新的道路管理区域。同时因为这个产品用例常常在夜间启动所以我们有如下需求。描述:产品应该实现自支持。理由:帮助平台会没有人。也没有其他用户可以提供帮助。安全性需求关注对产品的访问。对于IceBreaker产品来说客户不希望未授权的人运行调试程序:产品应该只允许高级或更高级别的工程师访问。也存在审计需求道路管理部门必须能够证明他们正确地处理了道路:对所有进行调度的情况产品应该保留所有的冰情预测。这个产品用例的文化需求是考虑适合工程师的工作方式:产品应该使用工程师社区接受的术语最后是法律需求。许多道路管理部门有法定的义务要证明他们尽职地监控并处理了他们控制的道路:产品应该得到所有道路调度表和后续处理的审计报告这必须符合IS093.080.00.