非功能性需求之性能需求分析

非功能性需求包括性能、可修改性、可用性、易用性、安全性、环境要求等，在最初的需求方案分析阶段很容易被忽略，而这些内容的考虑往往会影响到产品的实现，包括功能架构、操作方式、界面展现、后台处理方式、数据库设计方式等，所以到产品集成测试甚至回归测试时才考虑性能，往往就为时晚矣，可能就需要大量修改前期已完成的功能。甚至有些项目就是因为性能满足不了实际使用要求，导致整个项目的失败。

本文结合近期工作，总结下非功能性需求中性能相关内容，包括以下几部分：

□什么是性能需求分析

□性能需求分析对产品设计有哪些影响

□如何进行性能需求分析

 

什么是性能需求分析？

性能指标一般包括响应时间、吞吐量、并发用户数等。

响应时间指功能完成的时间，和客观环境、数据量级、主观感受等都有关系。客观环境中硬件包括服务器配置、客户端机器配置等，软件包括数据库部署方式、客户端使用的浏览器等，另外还有网络环境。确定响应时间的指标，需要根据实际所需的数据量级来要求，例如项目管理中，一个项目包含1千条计划和1万条计划，功能本身的操作相应时间是不一样的，需根据实际情况确定指标要求。主观感受指用户的可接受程度，例如同样的响应时间，加上进度条等处理方式，用户感受就大为不同。

吞吐量是给定时间内系统可处理的事务/请求的数量等，例如网络传输的数据流量。这个指标对于互联网软件更为关键，目前我们尚未进行定量分析和测试。

并发用户数用来衡量系统的同步协调能力，我们更关注多个用户同时操作同一功能或数据时，对系统性能的影响。

在产品的需求分析过程中，即需要针对业务对象、具体功能等，考虑这些指标的要求，进行需求分析和产品设计。

 

性能需求分析对产品设计有哪些影响？

功能层面：

1.会影响到功能架构

例如一个功能需要处理的内容很复杂，如果提前考虑到性能完全满足不了，很有可能就会考虑将该功能拆分为更小的单元，逐步再实现复杂功能。如果性能能满足，则可以考虑更为集成的功能架构方式。

2.会影响到功能操作方式，进而影响用户体验

例如，先分别设置部门、人员信息，再为部门添加人员，这种一对多的方式，和每次仅需新增一两条数据，操作方式对体验就影响很大。点击新增按钮，弹出人员选择页面，选中一条数据、点确定，这几个动作单独只需要做一次或两次，并不会让人觉得很繁琐。但是如果每次都必须新增几十条，那这种操作方式就很麻烦了，在最初设计功能时，就更可能会考虑设计为一次性批量多选的方式。

3.会影响数据的展示方式：

例如一个功能的数据量很大，可以考虑采用用分页、懒加载等方式。

4.会影响页面的布局或查看方式等

例如，一个树形结构，如果只有几十个节点，那么点击节点逐层展开还能接受，但是如果有成百上千条数据，可能就需要考虑更为合理的查看方式

技术层面：

需处理的数据量不同，对技术层面的设计也会影响很大，需求分析阶段提出来要求到就可以帮助技术人员在概要设计时进行考虑。

例如数据库的设计方式。表数量、表结构、单表数据量等如果达到某量级，用惯常的方式性能就支持不了，就需要考虑采用特殊方式，例如读写分离等。

例如服务器的部署方式。并发用户数或单一时间对应用服务器的请求次数多，就需要考虑服务器的处理能力，例如进行多Tomcat分压部署等，而是否采用这种方式也会影响到功能的详设。

另外，需要注意不仅仅是针对业务对象进行分析，涉及到该对象的其他相关功能，如果增删改查等操作时会有关联，很有可能也会受到影响，需尽量考虑全面。

如何进行性能需求分析？

首先，需要明确哪些业务对象会有大数据量要求，响应时间指标是多少。

业务对象可能会产生的数量级是多少？这和客户行业、规模、产品模式、使用方式等都有关系。如果有客户提出的比较明确的要求，可以作为参考，但是需要分析清楚是否合理、是否必要。也可通过问卷等形式收集具体客户的实际运行数据，还可以收集竞品的性能数据或行业常见标准，或询问售前或销售人员相关要求。

第二，考虑功能对于并发用户数的要求。

并非所有功能都需要考虑，可着重考虑频率高、更关键、资源占用严重的。有些是产品平台统一考虑的，例如登录、首页门户等，有些则需要根据业务情况考虑。有些互联网产品根据用户总数通过公式计算出并发数，但是企业软件更多需要从应用场景出发，估算并发数。例如有些功能每个部门使用人数是固定的，就可以结合部门数量估算，有些功能的使用时间比较固定，则可以根据该时段的应用人数估算。

明确了数量要求后，在分析时就需要结合业务对象、场景等进行设计。例如功能响应时间较长时，可考虑增加提示性内容。据统计，空白等待会让人体验上延长时间的感觉，大多数用户只等待8.5秒左右就关闭功能或重启，使用漏斗或旋转圆圈等提示的界面会把用户的等待时间延长到20秒左右，使用动画的鼠标指针漏斗提示界面则会让用户的等待时间超过1分钟，而进度条则可以让用户等待到最后。实际需要时可结合功能场景，选择更适合的处理方式。另外，不同浏览器对页面的渲染速度差别很大，在时间、成本等允许的情况，可考虑多种浏览器，以提升产品的适用性。但是如果是项目型软件，或者已知目标客户的大多数浏览器标准，则适度进行支持即可。所以在分析时也需要考虑对浏览器的要求。

最后，对性能需求的描述，需要做到准确无歧义，不能使用主观用语。目前一般操作响应时间要求为2、5、8,2秒内优秀、5秒内良好、8秒内可接受。上传下载等可依据用户体验情况，酌情考虑性能的指标要求。

扫码体验