2022年1月4日9时，西安一码通又崩溃了。这是半个月内，一码通第二次出现故障。
一方面，软件开发方有责任，开发的系统可用性太差。而另一方面，软件的需求方也需写清楚要求，这也往往是产品经理的工作，具体而言就是定义清楚产品需求、验收标准、违约责任。
否则研发只需一句话——“是产品经理没有定义清楚需求，所以责任不在我”，这就可将责任推掉。而我们如做好这些工作，就能分清责任，明确义务，避免背锅。
这些工作涉及面很广，本文仅探讨其中的非功能需求的部分，也就是产品经理如何定义清楚一码通的非功能需求。
一码通的功能需求很简单，就是查询自己的核算检测信息，个人健康信息。难是难在了非功能需求，下面我们就用3000字来逐一说明。
一、需求的全貌
产品经理要明确的需求众多，在我的书《图解产品》中，我将这些需求做了归类，并命名为PURPS+模型，具体就是：
而产品经理需逐一定义这些需求，才能将文档写全面。下面我们重点说说其中的可用性、可靠性、性能和可支持性需求如何写，这些内容在《图解产品》中有更多说明。
二、可靠性需求
可靠性定义了系统的健壮性，如可靠性高则说明产品的软件、硬件故障少，能正常运行。而这些故障常常会严重影响用户的使用。
而软件的故障多是因为软件BUG，因此很难预估MTBF值，有时会给个承诺值。
（2）可靠性
同样该值也较难预估，惯例是厂商会承诺99.99%或99.999%的可靠性。
三、可用性需求
可靠性是从系统角度看的，也就是反应了软件有没有问题；而可用性则是从人的角度看的，也就是人觉得产品可用不可用。有时两者是一回事，但有时两者不是一回事。
而所采取的手段是，当疑似有问题后，该系统会自动重启系统或重启某进程。所以从用户的角度看，其可用性尚可；但从系统角度看，其可靠性很差，系统总是坏掉。
现在的互联网系统也多是分布式部署，从而将单点故障的影响降到最低，提升用户的可用性。
而西安一码通也需定义清楚可用性。如当软件、硬件出现故障后，系统应尽可能支持一定的恢复手段，同时也要实现分布式部署等。
但从本次一码通的故障看，主要是性能问题，此时靠重启进程等手段是不能解决问题的，由此需要定义清楚性能需求。
四、性能需求
1.用户访问情况
用户访问情况需确认峰值访问量、平均访问量和访问的业务。对于一码通业务，需依据历史数据做预估。如预估每日10点-11点为峰值访问，且同时使用的人数是多少人，并应尽可能精确到每秒的峰值。
定义清楚了用户访问情况后，就要再从软件角度定义性能指标，如能定义清楚这些指标，就可避免不合适的软件架构设计，这些指标如下。
（2）新建数
（3）并发数
定义了当访问系统的特定应用时，能同时维持的连接数量。据统计西安有1300万人口，按照最大10%的市民同时扫码（已经很大了），也就是要支持百万的并发量。
（4）吞吐量
该系统定义清楚吞吐量，很多性能问题就可避免。
按照一些研发的分析，认为一码通的问题集中在该系统所有的js/css/img静态资源全都从一个出口进行提供，没上CDN。
粗略估算了一下，js/css/img数据总共约500kB。而按照某个群里得到的数据（暂且认为是准的），健康码的请求量峰值达到了3.3wqps，也就是吞吐量要33000x500x8bps≈125Gbps这个出口量级很难用单机房承载，由此系统挂掉。
该指标和系统实现方案有密切关系，需要由经验丰富的研发来分析、明确。
五、可维护性需求
（1）可支持性需求
定义了开发人员是否可以方便地升级系统、用户是否可以很方便地升级。
而据每日经济新闻报道，一码通的升级需要人工删除小程序，并清除数据。这就是没有做好可支持性需求。
（2）可移植性需求
括用户的增长和数据量的增长。用户量的增长是指当用户量增加后，系统应能方便地扩容。数据量的增长是指当存储的数量增加后，系统也能很好地支持。而一码通半个月后又出故障，由此可看出其可移植性需求做的并不好。
六、总结
以上就是一码通需定义的主要非功能需求，而这些需求涵盖面又广又重要。除了这些指标外，还有一些次要需求，本文就不再赘述，你可参考《图解产品》继续完善。
其实该系统的实现不算难，实现方案也颇为成熟，甚至优秀的应届生都能搞定，确实不该出问题。
有人可能会问，工作中我没有定义这些内容，研发一样工作。是的，对于互联网公司的自研产品多数不需这么详细，但对于这种关系民生的定制开发则必须明确，从而避免上线失败。
如一些实现细节不清楚，需求方也可列出框架，由开发方填写。
而需求方还应基于以上指标，再定义验收标准，违约责任，并进行压力测试，由此来约束开发方的行为。这样开发方就不至于敢派经验不足的研发来应付事，更可避免扯皮，分清责任。
作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者、UML建模、数据建模研究者，公众号：图解产品设计
本文由@公众号：图解产品设计原创发布于人人都是产品经理。未经许可，禁止转载。