非功能需求编写原则

一、需求分类

• 主要需求（Primary）：体现了功能、内容、安全性需求。
• 可用性需求（Usability）：体现了用户体验、帮助和培训文档等需求；
• 可靠性需求（Reliability）：体现了故障率，维修时间等需求。
• 性能需求（Performance）：体现了响应时间、并发数、吞吐量等需求；
• 可支持性需求（Supportability）：体现了可维护性、可扩展性等需求。
• 其他需求（+）：如数据统计、授权、接口、包装等需求
  二、可靠性需求
  可靠性定义了系统的健壮性，如可靠性高则说明产品的软件、硬件故障少，能正常运行。而这些故障常常会严重影响用户的使用。
  可靠性需求指标分别是平均无故障时间 （MTBF）、可靠性、维护响应时间、平均维护时间
  平均无故障时间 （MTBF）

该时间是指产品出现一次故障的平均时间。一般可用经验数据和实验数据，大致预估硬件的MTBF。而软件的故障多是因为软件BUG，因此很难预估MTBF值，有时会给个承诺值。

可靠性

软件的故障次数越少越好，但如不幸出现了故障，则希望有故障的时间尽可能短，这个指标就是可靠性。 如可靠性为99.999%，就是指在1年时间里，该业务会中断5.26分钟，计算公式为（1-99.999%）× 365 × 24 ×60，其中365 × 24 × 60为全年的分钟数。 同样该值也较难预估，惯例是厂商会承诺99.99%或99.999%的可靠性。

维护响应时间和平均维护时间

维护响应时间：是指从发现故障到开始维修所需要的时间。可要求开发方支持7×24小时的随时响应，并要求10分钟内开始维修。
平均维护时间（MTTR）：虽然开发方能够快速响应，但是要修好还需时间，由此需要定义平均维护时间，这个时间包括在途时间（如需要）和到达现场维修好的时间。该指标也需要根据业务情况定义，如要求必须1小时内修好。

三、可用性需求

可靠性是从系统角度看的，也就是反应了软件有没有问题；而可用性则是从人的角度看的，也就是人觉得产品可用不可用。有时两者是一回事，但有时两者不是一回事。

四、 性能需求

性能需求要先定义用户访问情况，再定义系统的响应时间、新建数、并发数、吞吐量。

用户访问情况

用户访问情况需确认峰值访问量、平均访问量和访问的业务。

响应时间、新建数、并发数和吞吐量

定义清楚了用户访问情况后，就要再从软件角度定义性能指标，如能定义清楚这些指标，就可避免不合适的软件架构设计，这些指标如下：

响应时间
指标反映了网站响应用户请求的速度，也就是我们日常所说的网络快慢。影响响应时间的因素有系统延迟、网络延迟和用户端的延迟，一般可由开发方给个响应时间。

新建数

每个用户使用一码通查看信息时，系统都会新建建立一个连接。该指标与用户访问指标比较类似。比如登录要新建、查询要新建，这就是两个新建。有时一次查询需要几个新建，需由研发确认。

并发数

定义了当访问系统的特定应用时，能同时维持的连接数量。

吞吐量
该指标和系统实现方案有密切关系，需要由经验丰富的研发或产品经理来分析、明确。

五、可维护性需求

可维护性需求可分为可支持性需求和可移植性需求。

可支持性需求

定义了开发人员是否可以方便地升级系统、用户是否可以很方便地升级。

可移植性需求

包括用户的增长和数据量的增长。用户量的增长是指当用户量增加后，系统应能方便地扩容。数据量的增长是指当存储的数量增加后，系统也能很好地支持。