菡萏如佳人标识关键质量和场景分析
关键质量识别
质量属于非功能性需求分析，标识出最关键的质量需求，以便通过有效的技术手段来保证系统能够达到要求，为业务提供稳定、可靠的支持。
下面是标识关键质量任务指引图：
识别关键质量要点
识别之前需要通过逆向思考和场景化思考方式进行
- 识别重要质量属性：包含了安全性、可靠性、易用性、性能、可维护性、可移植性
-
对重要的质量属性进行排序：通过威胁的影响度和频率综合考虑，可根据指引图中的权重进行，打分的时候两个维度分别交给不同的人/团队进行，曲奇乘积进行排序
质量场景分析
标识出关键质量需求之后，还需要进一步细化，找出具体的质量场景，然后与研发团队一起讨论，采取合适的手段来实现。
下面是质量场景分析任务指引图：
大部分的PRD中关于非功能性需求，往往都是乱写一气，充斥着大量的定性描述，还存在盲目的定量、全局化描述等典型问题。
比如：系统要求高扩展性，高弹性.....，研发人员看到后绝对是一脸懵逼，系统到底想往哪里扩展，哪里弹？项目成本是固定的，不可能不计时间和资源成本，无限扩展。
所以这种所谓的质量描述毫无意义也毫无营养。产品人员应该具体指明哪个业务流程会发生变化，可能会怎么变，希望要哪些扩展和配置化？
除了定性的问题外，定量也会存在问题。比如：平均用户学习时间要求1.25小时，平均无故障时间2127小时......如果你去问写的人：这些量化指标你是如何计算的？
答案无非是：COPY来的，我自己脑补的.......你心中可能有一万只草泥马奔腾而过。
如果是为了量化而量化，最后结果反而会适得其反，最好是能够积累历史数据，在有效理解的基础上，给出科学、严谨的量化描述。
另外还要警惕那种：所有查询都应在多少秒内响应的描述，那种数据量超大的年报之类，很可能就无法做到；而有的查询如果超过3秒用户可能就等不住了。如果你无法预估出质量指标，你应该写出功能的使用频率等有效信息。
这里给出一个关于系统响应时间上恰当的描述示例，大家自行体会下：
系统在95％的情况下，一般时段响应时间不超过1.5秒，高峰时段不超过4秒。定位系统从点击到第一个界面显示出来所需要的时间不得超过300毫秒。在网络畅通时，拨号连接GPRS网络所需时间不得超过5秒。在网络畅通时，电子地图刷新时间不超过10秒。在推荐配置环境下：登录响应时间在2秒内，刷新栏目响应时间在2秒内，刷新条目分页列表响应时间2秒内，打开信息条目响应时间1秒内，刷新部门、人员列表响应时间2秒内。在非高峰时间根据编号和名称特定条件进行搜索，可以在3秒内得到搜索结果。
质量分析要点
- 识别质量场景：运用逆向思维(站在对立面)，场景化思维(给出具体场景)
-
制订对策：针对质量场景的影响、威胁采用什么手段来避免或降低风险，注意每种措施都会带来新问题和影响，同时还要来了项目的成本
-
验证矛盾并解决：验证对策的影响，确定对策；比如防止客户乱发短信，一般需要增加一个验证码，通过验证再触发短信发送，牺牲了易用性带来了安全性
业务规则与约束分析
业务规则
大多数系统规则，我们可以在流程分析时一并给出，但是针对规则特别多，系统特别复杂的情况，建议单独对业务规则进行整理。
业务规则的整理指引图如下：
- 按作用域规则：如果系统中有大量的规则，研发在工作中可能会经常顾此失彼，为了不遗漏最好对规则进行分类，一种是按照作用域归类。影响整个问题域的整理成专门的章节；只影响某个业务流程的在流程分析中描述即可；只影响某个业务场景的在业务场景中描述即可。
-
按类型二次归类规则：业务规则非常细的时候，还需要再进一步归类。行为类：影响业务流程，场景执行的规则；数据类：用于控制数据格式与内容；权限类：用于控制用户执行和数据查看。
-
分析规则后的动机：最后也是最重要的一点，理解规则背后的动机，包含业务动机和可执行性；业务动机帮助发现改规则是否存在欠考虑的地方，可执行性帮助更好优化规则。
比如某电商平台通过复杂的优惠券规则，使得分开多单下其实更加优惠，结果反而增加了系统的负担，增加了物流成本，浪费了用户时间。更好的方案难道不是根据订单总额来限制优惠券的使用吗？
还有机场规定随身携带的液体不能超过100ml，机场并不会对液体进行测量，一般是根据瓶子大小和人为预估的，这也是处于可执行考虑。
约束分析
约束实际属于非功能需求，非功能需求包括了质量和约束两类，质量是我们的要求，约束是对我们的限制。约束可以分为两类：项目约束和设计约束。
下面是约束分析粪污指引图：
约束分析要点按照指引图中所示有六个小步骤，其实可以归纳成两个：
- 明确项目约束：从进度、资源、预算三个角度进行整理
-
明确实现约束：从技术选型、部署环境、开发角度进行整理
这部分没有特别的技巧，按照指引按步骤的执行就可以了。
小结
本小结介绍了质量场景的分析和业务规则与约束分析。
质量场景分析中特别要注意的是避免采用定性的描述或者盲目的定量描述。要根据系统的历史数据或对于实际的业务有效理解的基础上，给出科学、严谨的量化描述。要知道有时候一个不严谨的质量要求会浪费组织大量的资源。
业务规则和约束分析在流程、业务场景分析中可能都会涉及，但是不建议大家在流程分析或业务场景分析时一并将其完成。特别是复杂的系统，放在和其他流程分析一起完成，一个是增加了其他流程分析的难度，另一个是也容易导致规则和约束遗漏。
附录
当我们完成关键质量和场景分析后，需要输出质量描述文档，模板如下图所示：
当我们完成业务规则和约束分析后，需要输出约束描述文档，模板如下图所示：
