参考

提需求时，千万别漏了非功能性需求（2019-01-29）
http://www.woshipm.com/pd/1890597.html/comment-page-1
如何洞悉隐性需求（2015-12-07）
https://blog.csdn.net/weixin_30823227/article/details/96200264
常见的非功能性需求和应对方式（2020-02-14）
http://www.woshipm.com/pmd/3391140.html

非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括安全性、可靠性、互操作性、健壮性等。

大多时候我们关注的是功能需求，比如B端业务方的需求、C端用户的需求，展开需求调研与分析后，就开始投入功能设计。（需求调研与分析——功能设计）过多关注功能性需求，会忽略非功能性需求（是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性)
非功能性需求：性能需求、安全性、可维护与可扩展性、可靠性、易用性。
非功能性需求，影响着产品是否能够持续稳定并且高效的提供服务。

一、性能需求

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

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

关于性能需求，作为产品经理，需要提前与开发人员沟通，反馈所需支持的业务量与需要达到的性能指标，遇到瓶颈，共同商讨解决。
目的是减少上线后出现性能问题，也避免出现问题后，互相推诿责任。

二、安全性

随着互联网的发展，安全性越来越重要。
现在，大多用户的数据都存在于各个企业中，所以对于数据的安全性，重视程度也越来越高。开发过程中，有时开发人员会有忽略，作为产品经理，具备一定的安全意识，能够更好与开发人员共同做好安全工作。

  • 保密性：数据加密保护，保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。业务数据需要在存储时进行加密，确保不可破解。
  • 防泄漏：通过对文档进行读写控制、打印控制、剪切板控制、拖拽、拷屏/截屏控制、和内存窃取控制等技术，防止泄漏机密数据。
  • 权限控制：根据用户权限控制访问数据，进行操作记录等等。

  • 防攻击：IP限制、高频访问限制等等，如：用户高频点击，有时不是恶意，但也有可能造成系统异常。我们在进行产品设计时，是否需要控制点击频率，或者点击后是否将按钮修改为不可点击状态。这些也是需要我们考虑的地方。

    三、可维护性与可扩展性

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

  • 模块性：当某类业务流程变动多，此时将系统功能模块化，支持灵活配置，有利于减少重复开发量。

  • 可复用性：站在产品的角度，个人觉得类似组件。如时间组件，系统多处会使用到时间组件，应该将其统一设计，需要用到的地方，可以进行微调，然后进行调用。即可以满足各类场景，又能减少用户的使用成本。
  • 易分析性：易诊断缺陷或者失效原因，如日志记录系统，可追踪系统的历史使用情况。

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

四、可靠性

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

  • 易恢复性：在发生故障后，重建其性能水平并恢复直接受影响数据的能力。如发布新版本，需要做好回滚方案，以备异常紧急处理。文件误删除可进行恢复，
  • 容错性：在系统出错时，不影响用户的行为操作与数据，比如：掉网，数据的录入做好本地保存，在网络恢复后，自动上传保存。
  • 成熟性：系统故障率需要保持在一定的水平下。

    五、易用性

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

隐性需求

  1. 细节变更需求
    细节变更可以说是无法避免的，设计时要尽可能的考虑周全。开发人员唯一能做的就是，设计程序结构和逻辑时，尽量预留出可扩展的能力。比如模块的增删，字段的增减，页面样式的微调等。
    2. 跨平台需求
    最初规划的时候先在一个平台尝试，比如先规划了 PC 端，但是 PC 端的某些功能又会忽然很急促的移植到移动端。虽然看起来功能差不多，页面长的差不多，但各个平台无论在架构部署，还是操作体验上都有着天壤之别，需要提前做好规划。
    3. 扩展需求
    随着业务量的增长，以及产品运营人员欲望的膨胀，都会催生出各种扩展需求。任何固定数量的，都会增加。任何单一需要的，都会变成多个。比如页面上设计了三个商品推荐位，就要预留出变成六个、九个，甚至分页的能力。一个接口是给某个业务专用的，某天就可能变成通用的。一个简单的静态页面，某天就可能变成附带管理后台的复杂系统。
    4. 异常流需求
    异常流需求往往容易被忽略。常见的异常流有图片数据加载不出，图片不存在，接口挂掉，网速慢，未登录，登录态丢失，查询出错，查询无数据，内容溢出，用户输入溢出，用户输入非法，视觉遮挡不可用等。对这些异常流情况，要有配套的前端提示给用户，引导用户进行其他操作。
    5. 内容运营需求
    所有静态的内容，都可能变成运营需求。静态广告位可能变成轮播广告位，轮播广告位可能变成需要运营后台填写数据，而不是直接写死在页面里。或者某一天可能变成从另外一个自动数据源拉取数据。
    6. 内容校验需求
    运营工具是由运营人员自己来填写的。要尽量操作简洁，并且可以校验输入。比如空格、英文逗号。
    7. 内容复用需求
    运营填写的数据一定是有复用需求的。比如 h5 页面上运营的数据，有可能还需要给原生 app 使用，甚至给 pc 端也用一套数据。一个广告图片和链接，可能被插入到多个页面的顶部或底部一起更新。
    8. 内容历史需求
    有运营需求，就可能有运营的历史记录需求。比如一个坑位，每次都改掉内容来更新，上一次的就没了，那么鬼知道一天改了多少次？一周做了多少次更新？
    9. 排序&打标需求
    排序需求其实也是内容运营需求的一种，无论是运营填写的还是自动拉取的内容，永远都会有调整顺序的需求。不同的坑位对应不同的关注度，不同的视觉焦点，浏览路径。运营需要通过调整位置或者加些标记来突出某些内容。比如商品列表，可能近期有几个商品比较好卖，就挪到前面，打上 hot 或者 new 的标记，从而促成更多的销量。对于排序和打标需求，往往从后台开始就要预留可扩展字段，到前端也要可以方便的调整位置和加 icon 标记才行。
    10. 筛选需求
    对应于排序和打标，筛选也是经常用到的。比如搜集了一坨数据，又想挑一部分来展示，这时候往往需要一个可以方便操作的地方，类似帖子加精，评论置顶等。
    11. 数据统计需求
    产品运营最初往往觉得要个 PV UV 就够用了，过几天可能说要统计下按钮的点击量，再过几天恨不得把所有的操作都埋点，再加上访问路径、购买路径、转化率、蹦失率、页面停留时间、点击热图、鼠标轨迹。再给出个月度季度报表，趋势图等。数据统计需求可以独立于正常的需求，作为单独的数据统计需求整体梳理后提出。
    12. 翻旧账需求
    凡是进到系统里的数据，都希望有个方便的形式可以看到。比如用户创建的 UGC，一定要有个唯一的地址可以看到这个资源。用户录入的信息，要有个方便的地方可以导出，或者下载 excel。即使当前的需求不需要你展示历史记录或者以前的任何内容，也要预留出方便的查询接口备用。
    13. 报销需求
    对于涉及到钱的活动来说，唯一的凭据可能就是数据库里的数据。所以有关钱的需求，最好开始就确认好报销需要哪些内容，比如用户的真实手机等（确认是真人参与活动，没有造假），以此来作为最终报销的凭据，否则就只能运营同学自己出血了。
    14. 扩容需求
    当访问量骤增的时候，快速扩容就迫在眉睫了。扩容包含很多方面，一些性能方面的问题会在高并发时迅速凸显，比如查询低效，PHP慢速，无静态化 web，并发压力大等等。此时关于性能优化的一切知识都可以派上用场了，静态化、缓存、查询优化、锁表等等。而机器扩容也没那么简单，除了机器内容的复制还有相应服务的批量启动，定时任务的执行，日志的归集等等。所以，如果评估时预计业务会有爆发性增长（如微信活动），在资金允许的情况下不妨多准备些机器。
    15. 安全需求
    安全问题的范围非常广泛，虽然有专业的同事负责安全以及运维相关的工作，但是在需求初期如果能稍微做些防范就会避免很多问题。一般的公司都会有个基础的安全规范，比如如何防止 XSS, CSRF 攻击，如何防止 SQL 注入，如何屏蔽脚本攻击等。还有一些外部接口需要鉴权的，有时可能做了基本的鉴权，却没有更高级的防护。比如一个人虽然登录了，可以看到自己的某些资料，但是如果这个登录的用户还可以通过相同的接口查看其他人的某些信息，那就是安全问题了。有可能这个信息是存储在相对独立的表中，并没有严格挂在这个用户id下，那么查询的时候就一定要再检查一下数据和用户的对应关系。对于安全需求，普通前后台开发人员能做的其实并不多，能按部就班做好这些基础防护就不容易了。加上公司公共的安全扫描平台，基本上可以杜绝绝大部分安全问题了。