7.6 非功能性需求验收的标准
非功能性需求的验收标准是对这些品质进行量化，从而进行评估和验收。某些非功能性需求初看上去很难量化，但是，总可以为它们加上数字标准。如果不能对一项需求进行量化和度量，那么很可能此项需求其实不是一项需求，而是多项需求，或者可能是一项没有考虑好的需求，它也许就不是一项需求，应该从规格说明书中删除。那么就让我们来看一些例子。
案例&知识：
描述：产品应该用户友好
这初看上去很模糊，有二义性，不能清楚表明如何进行量化，但是可以找到度量它的方法。我们可以这样开始，问一下客户，看看他是否能提供关于“用户友好”更准确的含义。例如，他的意思是指易于学习、易于使用、吸引人或其他的某种含义？
假定他澄清了意图，说“我希望我的用户能快速学会如何使用该产品”。这表明了一个度量尺度——掌握给定任务所需的时间。通过制定一组标准任务，度量能成功地使用它们所花的学习时间，或者可以指定使用产品到一定标准所需的培训时间。对于用户成功地了解该产品的另一种度量方式是求助电话的次数和查看在线帮助的次数。
对“用户友好”需求的一项建议的验收标准是：在新用户第一次使用该产品时，他们将能够在30分钟内完成添加、修改、删除等操作。
有时，当帮助用户考虑需求时，可以定义一个大家间接的接受标准。换言之，通过使需求可度量，从而使它变得清楚。
但是有些时候，可能会遇到品质度量不能达成一致的情况，因此不能得到验收标准。在这些情况下，可能最初的需求事实上是几项需求，每项需求都有它自己的度量方法，或者需求非常模糊，它的意图非常不切实际，以至于根本不可能知道它是否已被满足。例如：“我希望有一个产品，如果我的祖母还在世的话，她将喜欢它。”
1.主观测试
有时候，某些需求将通过主观测试。
案例&知识：
验收标准：产品不会让测试组80%的人感觉到被冒犯。测试组由可能与产品发生联系的人员代表组成。测试组所代表的利益团体感觉到被冒犯的不超过10%。由于实际业务误差的存在，你不能指望100%的人通过所有的测试。在这种情况下，业务误差保护了产品，不至于受到少数极端观点的攻击，同时又允许使用原型对“感觉到被冒犯”进行度量，而不是提交的产品。
验收标准中的数字不是任意的。假定有一个验收标准：“把操作某项任务的时间减少目前所用时间的25%。这表示当前的时间必须知道并记录下来，而不仅仅是猜测。减少25%这一目标的原因必须很好理解，并经用户的认可。理想情况下，期望是25%而不是20%或者30%的理由应该来自研究业务得出的经验数据。
2.观感需求
观感需求是关于产品的外观精神和用户对产品的感知。例如，在公共区域使用的产品必须要求用“公共的颜色”。颜色是可度量度最高的，可以通过RGB值、CMYK值、Pantone色号或其他颜色标度来指定，同时上色的表面区域的百分比也是可度量的。
对于要求可读的产品来说，有一些可读性评分系统。例如，Flesch阅读容易程度评分（Flesch Reading Ease Score）根据文本中的一些因素给出一个分数，最高分是100，建议的分数在60～70之间。Flesch-Kincaid平均水平评分将与美国学校的年级理解能力对应起来。例如8.0的分数表示八年级的学生能理解它。标准文档建议的分数值在7.0至8.0之间。
3.易用性需求
易用性需求与产品的用户有关。产品通常要求易于使用、易于学习、能被特定类型的用户使用等等。要为这些需求编写验收标准，必须发现可度量度最大的尺度，能够量化需求的目标。让我们来看一些例子。
描述：产品将是直观的和自我解释的。
为了度量“直观的”，必须考虑“直观的”是针对什么用户而言的。在本例中，被告知用户会是财务人员，他们将拥有管理学位，并有会计学方面的经验。当知道这些，“直观的”就具有了特定的意义。
验收标准：在首次使用该产品时，财务人员将能够在10min内得到一份正确的薪资表。
用户有时说“直观”，实际上他的意思是“易于学习”。在这种情况下，必须询问可以花多少时间用于培训，从而得到类似以下的验收标准：
验收标准：在经过一天的培训后，10个财务人员中有9个将能够成功地完成选择的任务清单。(https://www.daowen.com)
易用性需求的验收标准也可以使用最后完成给定任务允许的时间、允许的差错率（量化易于使用）、用户的满意度、易用性实验室的评分等等。最重要的是发现需求的真正含义。
4.性能需求
性能需求是关于产品的速度、精度、容量、可用性、可靠性等方面。大多数时候，性能需求的本质将指出度量尺度是什么。让我们来看一些例子：
描述：响应应该足够快，以避免打断用户的思路。“快”表明要度量时间。建议的验收标准是：在95%的情况下，响应时间将不超过1.5s，在其他情况下不超过4s。类似地，对可用性需求的验收标准可能如下。
验收标准：在操作的前三个月中，早上8：00至晚上8：00产品的可用时间覆盖率应该达到98%。
因为多数的性能需求本身就是量化的，所以编写合适的验收标准应该很直接、很自然，如果需求是以正确的最优方式给出，那么验收标准和需求就是一回事。
可操作性需求这类需求指明了产品将操作的环境。在某些情况下，产品必须在有害的或是不一般的情况下使用。例如，气象台站数据收集的系统。
描述：产品将在夜间、结冰的温度下使用；极有可能会下雨或下雪；产品预计会接触到盐和水；照明情况可能很差；操作者将戴着手套。
验收标准是在要求的环境下使用是否容易作为使用是否成功的量化标准。以上的可操作性需求在某种程度上说有些特殊，验收标准应该量化操作完成特定任务的能力，以及产品经受住环境考验的能力。
案例&知识：
验收标准：在模拟的25年一遇的暴风雨（这是一个客户接受的量化的气象条件）条件下，操作者应该能在给定的时间内成功地完成任务的清单。在暴露24h后，产品仍能操作正常。
可操作性条件也可能指明产品必须与之共存的伙伴协作系统。在这种情况下，验收标准将引用伙伴系统的规格说明书。
验收标准：与气象站的接口将符合气象数据收集系统发布的规格说明书。这是可测试的，至少可以由来自气象局的信息化工程师测试。它向产品的构建者指明了一份已知的被接受的标准。
5.可维护性需求
这些需求指明了对产品维护方面的期望。通常针对这类需求的验收标准量化了做一定改动所允许的时间。这并不是说所有的维护性改变都可以预计到，但是如果预计将发生一些改动，那么就可能对加入这些改动所需的时间进行量化。
验收标准：新的用户将能被加入系统，并且对现存用户的打断不超过5min。如果产品是一件软件产品，并且存在移植到其他计算机的需求，那么也在可维护部分进行说明。验收标准量化了满意地进行移植所需要的时间和工作量。
6.安全性需求
安全性需求包括了产品的许多方面，其中就有操作的安全性。最明显的安全性需求是：谁在什么情况下允许访问产品的哪些部分。验收标准可能类似下面这样。
描述：只有使用A类权限登录的工程师能够修改气象站的数据。
验收标准：在1000次气象数据的修改中，全部由A类权限登录的工程师完成，没有例外。文件完整性（file integrity）是安全性的一部分，最常见的对计算机文件的损坏是由未获授权的用户偶然改变了文件造成的，因此必须至少有一项需求是针对文件完整性的。验收标准可能类似下面的情况。
验收标准：产品关于静态实体（气象站、道路等）的数据应该与所有外部权威机构掌握的保持一致。
该验收标准表明产品的数据必须与数据的权威来源保持一致。因为多数数据是从外界（道路的更改，新的传感器，等等）传入产品的，传送者必须是权威机构，所以，如果产品的数据与权威机构的数据一致，那就是正确的。
