非功能需求 - 提需求时，千万别漏了非功能性需求 - 《产品学科知识宇宙》

个人总结了再提交需求时容易遗忘的5个非功能性需求，希望对大家有所帮助。
提需求时，千万别漏了非功能性需求 - 图1
作为产品经理，大多时候我们关注的是功能需求，比如来自B端业务方的需求、C端用户的需求，展开需求调研与分析后，就开始投入功能设计。

过多关注功能性需求，有时会让我们忽略了非功能性需求（是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性)，如：性能、安全等。

非功能性需求，影响着产品是否能够持续稳定并且高效的提供服务。

笔者在非功能性需求踩过多次坑，例如：曾设计一个功能，在测试服体验时，无论产品同事或者受邀参与体验的用户，都表示很好用。

但是一到正式环境，却饱受诟病——原来是性能那一块没做到位，导致一个本来用于提升效率的功能，却因为性能问题，影响效率……

后来也踩过安全性、可靠性等一些坑；虽然这一块与开发人员的关系较大，但是作为产品经理，势必要考虑产品的方方面面。因此，下定决心做好总结，将非功能性需求进行整理，并做好反思，避免此类错误再次发生。

下面，为大家介绍一些常见的非功能性需求，可以用于日常产品设计过程中的自我检查。

一、性能需求

用户对于性能的要求是无止境的，但是过度重视性能，导致成本过高，显然是不合理的。作为产品经理，应该对业务所需支持的性能有所了解，与技术人员共同协商，制定符合实际使用的产品性能指标。

响应时间：如页面间跳转时间≤3秒，精确搜索反馈结果≤1秒。有时，在当下情况，性能已经到达瓶颈。我们作为产品设计者，也可以从产品体验这一块做出优化，比如某个页面数据量大，导致加载时间长，我们给用户提供加载进度条，预计加载时间，减少用户焦虑。还有日常使用的分页加载，像刷微博一样，每次加载部分数据，当用户进行操作时，再逐渐加载。
吞吐量：单位时间内成功地传送数据的数量。这一块与系统并发相关，根据业务量估计，我们的系统需要支持多少并发。
资源利用率：指企业投入服务器这类资源，所发挥的资源利用百分比。我们都希望投入的资源最大化的利用，而不被闲置。像我们新增项目，需要进行业务评估，然后与技术人员沟通，确定支撑项目所需要的服务器配置。

关于性能需求，作为产品经理，需要提前与开发人员沟通，反馈所需支持的业务量与需要达到的性能指标，遇到瓶颈，共同商讨解决。

这样能够减少上线后出现性能问题，也避免出现问题后，互相推诿责任。

随着互联网的发展，安全性越来越重要。

现在，大多用户的数据都存在于各个企业中，所以对于数据的安全性，重视程度也越来越高。

开发过程中，有时开发人员会有忽略，作为产品经理，具备一定的安全意识，能够更好与开发人员共同做好安全工作。

保密性：数据加密保护，保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。业务数据需要在存储时进行加密，确保不可破解。
防泄漏：通过对文档进行读写控制、打印控制、剪切板控制、拖拽、拷屏/截屏控制、和内存窃取控制等技术，防止泄漏机密数据。
权限控制：根据用户权限控制访问数据，进行操作记录等等。
防攻击：IP限制、高频访问限制等等，如：用户高频点击，有时不是恶意，但也有可能造成系统异常。我们在进行产品设计时，是否需要控制点击频率，或者点击后是否将按钮修改为不可点击状态。这些也是需要我们考虑的地方。

三、可维护性与可扩展性

互联网高速发展，也意味着系统需要具备对业务需求变化或者技术更新的支持能力；当其变化时，我们能够尽量以较小的代价与更短的时间适应变化。

模块性：当某类业务流程变动多，此时将系统功能模块化，支持灵活配置，有利于减少重复开发量。
可复用性：站在产品的角度，个人觉得类似组件。如时间组件，系统多处会使用到时间组件，应该将其统一设计，需要用到的地方，可以进行微调，然后进行调用。即可以满足各类场景，又能减少用户的使用成本。
易分析性：易诊断缺陷或者失效原因，如日志记录系统，可追踪系统的历史使用情况。

除此之外，还有易修改性、易测试性等等，这些作为产品经理，参与很少，不做赘述，大家有兴趣可自行了解。

指产品在一定时间内，一定条件下故障地执行指定功能的能力。可靠性越高，用户对于产品的信任度越高，就像一个可靠的朋友一般。

指的是产品对用户来说意味着易于学习和使用，我们在进行产品设计时，这一块的关注还是蛮大，因此不做赘述。仅将其中的各种特性分享给大家：易学习性、易操作性、用户错误防御机制、用户界面美观等。

以上是根据个人经验总结出容易忽略的非功能性需求：性能需求、安全性、可维护与可扩展性、可靠性、易用性。大家可以根据自身需要建立自查表，在平时工作中使用，既考虑功能性需求，也不遗漏非功能性需求，将产品做得更好。

希望大家看完本文有所收获。

作者：彬，微信公众号“有个思享”，专注读书与产品心得分享，欢迎交流。