@阿德 谢邀！

简单来说，还是不够理解，详单侃两句：

1、兼容性：

（1）帐号角色

• ①是否存在不同登录状态下展示内容或操作有不同（登录、未登录、帐号异常状态）？
• ②是否存在不同用户状态下展示内容或操作有不同（非会员，不同等级的会员，特殊付费会员等）？
• ③是否考虑多账号切换，切换时，本地缓存数据是否需要同步清空？
• ④是否允许多终端同时登录同一帐号，若允许，操作同一数据时是否产生冲突？

（2）网络状况

• ①WiFi网络；
• ②移动网络（4G）；
• ③连接超时，多久为超时？
• ④无网络显示什么内容？是否给予用户友好引导检查网络或重试按钮？
• ⑤网络变化从WiFi到4G网络环境时，是否需要提示？

（3）服务器问题

服务器出问题返回数据失败时，是否给予用户友好提示或重试按钮？

（4）旧版本兼容

是否存在高低版本兼容问题（浏览器页面缓存、APP旧版本）？

2、辅助功能（后期运营）

（1）数据埋点

1. 是否存在用户漏斗埋点需求？
2. 是否存在运营数据报表需求？
3. 是否定义功能可用性标准？

（2）通知机制

• 操作交互是否需要触发推送消息，推送内容是什么，推送时间节点是什么？
• 是否确定当前通知的类型（短信、推送、微信消息）？
• 是否确定当前通知的失效策略？

3、易用性、扩展性

1. 设计时是否结合了用户画像、用户习惯、业务场景等因素；
2. 架构层次是否清晰，是否足够扁平，是否容易能使用户理解；
3. 所有信息均需要进行重要级评定，以决定在界面和功能中的重要程度；
4. 信息分类是否合理，一定要“高内聚，低耦合”；
5. 架构拓展性是否足够大，后续对信息模块进行增删改查时，是否容易施行。

4、安全性

      1）功能风险

• ①是否存在关联功能的改造点
• ②是否完整梳理当前规划内容下线后的影响点
• ③是否已预估业务高峰数据爆发量级，及其处理措施
• ④是否已计划好功能上线后的验证方法

5、可靠性

    （1）对核心用户的影响程度，尽可能量化；

    （2）对核心业务的贡献程度，尽可能量化。

6、业务培训及后期维护工作

     （1）版本上线计划是否确定，是否及时同步给运营或其他相关部门人员，及布置相关工作

     （2）若需求内容较大，是否在上线前做好业务人员培训？

总结：有实力的产品人，需求文档里大概率藏着一头沉睡的猛兽，而他在渐渐地苏醒。

讲一个实际的例子：统计查询的响应时间

需求背景：某个区域下统计多个企业下的不同部门的业务完成情况，分已完成、未完成。

问题：产品V1.0为了快速上线，统计功能研发直接查询数据库mysql，最终测试团队反馈统计查询响应时间为42S，用户的最长忍耐是7S，大多数用户一定是等几秒钟就会关页面，然后抱怨系统问题，我们预期把查询速度做到3S以内；

解决方案：为了解决这一问题，在用户进行业务操作的每个入口，比如新增、编辑、删除时把相应的数据统计到Elasticsearch（一种读取比较快的数据库,通常用作大数据仓库，下面简称ES），然后统计功能直接用ES数据库查询。这一方案的设计需要考虑以下三个问题：

（1）到底在哪些入口存储/删除数据？

（2）ES数据库的统计数据结构设计；

（3）历史数据的处理（脚本处理）。

确定了解决方案后，最终开发测试花了将近2周的时间上线，上线后统计查询响应时间为2S以内。

总结：造成这个问题的原因是企业数量太多（5000+），导致业务数据太多，mysql查询慢，用户体验很差。显然，这个问题不属于功能性需求，属于非功能性需求里的性能需求，所以最初考虑需求时，要尽可能考虑到响应时间、用户量、并发量（比如12306，高并发）等等非功能性需求，这种非功能性需求是影响到开发设计技术架构的，否则后续调整会减少用户信任感，团队也会疲于奔命。

仅站在ToB、ToG产品角度，回答非功能性需求定义？阐述这个问题之前，先回归需求的定义。

一、什么是需求？

1. PMP项目管理体系 — 需求是相关方已量化的需要和期望。收集需求是为实现项目目标定义和记录相关方的需求，需求是工作分解结构的基础

2. IEEE软件工程标准术语 - 用户所需的解决某个问题或达到某个目标所要具备的条件或能力；系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力

3. RUP统一软件开发过程 - 需求描述了系统必须满足的情况和提供的能力，它可以直接来自客户需要，也可以来自合同、标准、规范或其他正规约束力的文档。

二、非功能需求常见来源

 招投标文件、合同、标准、规范、其他正规约束力的文档、产品能力提升...

三、回答楼主“几乎没有人重视这部分的内容?”

1.接触不到，或者很少接触“招投标文件、合同、标准、规范、其他正规约束力的文档”这些文件

2.产品类型（硬件产品、软件产品、项目型产品、研发型产品...）暂时没涉及到这方面问题

3.产品角色（数据、商业、功能型产品经理），产品当前发展阶段暂时不关心这部分问题

4.公司组织架构分工明细，有项目经理等角色专门负责这部分内容，有PMO专门定义这部分标准，但信息没有同步到产品经理，产品经理当前角色只是负责用户功能需求和产品逻辑

5.很多纳入了到规范，上升到行业，国家级标准，这方面内容一是组织内化，二是质量需要...

四、非功能需求的常见分类

下面每个点都能扩展很多，仅从数据一方面概述说明

1.高可信：数据完整性、准确性，传输数据可信任，能辅助车辆自动驾驶

2.高可靠：传输的稳定、实时性

3.完整性：数据传输完整性

这些都是很基础的数据方面非功能需求，数据产品经理是一定会考虑的。

同一个功能，给10个人用，跟一万个人用，跟百万人用，给更多的人用。其实并不是一回事儿。

它们的差异在哪儿?其实主要就在“非功能性”需求内。

描述这些“非功能性”需求的价值和意义是啥?

--如果不描述，这个功能就无法正常生效，有时候的不生效不仅仅是体验差，甚至会出错、崩溃。

产品经理的本质是帮用户解决问题，为用户提供价值。设计方案不是最终目标，传递价值才是。而很多时候，如果不描述“非功能性”需求，就无法传递价值。毕竟墨菲定律在，不管理 = 失控 = 灾难

非功能需求个人理解就是和业务非强关联的需求，可以搞可以不搞，看你产品所处的阶段，初期肯定没必要
---------------
PS.按照产品的三个层级描述，1层是解决问题，2层是更好的解决问题，这个更好更多的就是体现在这些非功能性需求层面

感谢邀请。

首先，必须要承认的是，再多数情况下产品经理们都更愿意去思考和关注功能性问题，因为它是能直接解决用户问题的切入点，也是真正可以快速做出成绩的地方。

也是因为这种惯性思维，很多人实际是接到需求就开始设计画原型，然后进入UI设计接到，然后做评审，然后开发上线，这种工作习惯，带来的后果就是明明在测试服务器验证体验的功能都反馈良好，但正式上线后却饱受诟病。

非功能性需求，涉及很多维度的内容，但通常来说（特别是中小型企业/产品），能够充分考虑三个非核心需求即可。

分别是：可用性、可靠性、及时性，当产品经理能够在需求文档里面理清楚这3个指标，则 用户体验 将不再是一句虚无缥缈的空头支票。

01、可用性（易用）

也许你不知道，“对用户友好”这个口号最早出现在80年代中期，和互联网其实没啥关系，只是互联网让这个口号更深入人心而已，这个口号也就是人机界面可用性的概念。

它的准确定义是，一个产品被特定的用户在特定的境况中，有效、高效并且满意得达成特定目标，这个定义也是ISO9241/11的标准，目的就是确保产品在外部资源得到保障的情况下，产品能够在规定的条件和时间要求下处于可执行规定功能的状态和能力。

ps，在这个定义中，涵盖了关于产品最基础的定义。

可见，可用性是产品最重要的指标，是最核心的竞争力，对用户来说，可用性包括有效、易学、高效、好记、少错和令人满意的程度6大指标，即用户能否用产品完成他想要完成的“任务”——用户需求，效率如何，主观感受怎样，实际上是从用户角度所看到的产品质量，这个综合性指标的概括性描述也叫“用户体验”。

从这个点出发，你也就能真正理解用户体验是一个完整性感受，而不仅仅是某个单点的愉悦感，更不是一个界面按钮的美观度。它包括界面的设计，也包括实现产品的整体技术，还涉及到用户在使用的环境，用户的心理也会影响用户对体验的评价，如疲劳、注意力分散等情况会让对产品产生不一样的体验评价。

一般说，可用性（用户体验）被表达为“对用户友好”、“直观”、“容易使用”、“不需要长期培训”、“不费脑子”等。

产品经理也常用小白思维来描述，本质上都是为了让用户能把知觉和思维聚焦在自己想要完成的任务上，可以按照自己对世界理解来完成某些操作，而不必花费心力寻找功能菜单和按钮，更无需去理解复杂的产品结构、图标含义，即使在非正常环境和情景时，用户仍然能够正常进行操作。

需要注意的是，易于使用（易用性）仅仅是可用性的一部分，两者属于包含关系而不是对等关系。易用性 - Easy of Use，指的是产品对用户来说意味着易于学习和使用，没有记忆负担，但易用性好也可能是产品的功能少。比如一个网页版的产品，能够在所有电脑的所有浏览器都可以正常打开，那它相比于要求先安装一个google浏览器显然就更容易使用。

很多时候，产品经理就常常在这个问题上犯错，他们没有能主动去了解用户现有具备的条件，要知道用户如果不能从他们可用的渠道使用你的产品，那么这个产品的价值是什么呢？浏览器的兼容性就是一个典型性问题。还包括各种场景的文件格式问题，事实上这些问题都是产品经理不应该犯的错。

用户体验是技术问题吗？

不是，它属于心理学的范畴，也是一个主观感受问题，有的人觉得mac好用，有的人则很排斥，有的人喜欢用wps，但另外一些人很难接受。用户体验的评价受认知能力，知识背景，使用经验和外部环境影响，对任何一款产品来说，抓住典型用户特征是做好产品的基础。

用户体验指标（或者说可用性/易用性）指标，可以概况为3个层面：

1、易理解性

很多产品之所以被吐槽为“反人性”，就是产品的功能特性和逻辑，不能被用户快速理解，或者需要产品的设计者讲解培训才能接受。

界面UI最能体现产品的易理解性，拟物化设计是典型案例，它的思路简单的说就是模拟真实世界来降低用户的认知障碍。比如备忘录的设计，目的就是让用户觉得自己在用一个真实的备忘录。

2、易学习性

为什么触摸屏会被如此风靡，就是因为它完全不需要额外的学习就能操作并能快速得到反馈，“所见即所得”符合用户最低的学习成本。

易学习性通常和界面导航设计相关，友好的导航和帮助、提示等都有助于用户缩短学习操作时间，特别是无需用户记忆面向计算机硬件软件的知识。

3、易操作性

指的是与用户操作相关的产品特性，比如带首字母筛选功能的下拉列表就能极大的提升效率（关键词联想）。

易操作性通常和界面元素的设计有关，包括各种导航的分类归纳等，它对设计者的逻辑抽象要求很高，要求做到用户理解和操作出错较少，能够对用户的环境和条件有预判，即使出错用户仍然能够正常进行操作。

02、可靠性

关于产品的可靠性，可能纯软件的产品经理对这个概念不熟悉。但这个概念可以说是一个产品的核心需求。简单的说，可靠性就是指一个产品能在多长时间什么条件下正常的使用，完成具体的功能，比如数据是否能正确的显示，按钮是不是能正常点击。

这个就像我们说一个人是不是可靠一个逻辑，说到做到就是可靠的人。对产品也一样，宣传的能力都能正常实现，要求它工作时都能满足需求，就是可靠的，反之则为可靠性差。

对软件产品来说，可靠性可以归纳为三个维度：

1、恢复性

比如文件丢失或误删除以后可以恢复，版本发出后可以回滚，都属于产品的易恢复性特性。

2、容错性

俗称防呆，要求系统能够对各项数据和操作有检查校验，能够防止数据异常。最简单的就是对输入框的校验，比如手机号码不能是非数字。这个时候最准确的描述应为“仅支持阿拉伯数字”。容错性也称之为产品的健壮性，要求产品自身能够对各种异常情况进行校验和预防。而不是坐等bug。

3、成熟性

如果你使用过，或者做过AI类产品比如智能音箱，其中有一项指标叫误触发率，业内的指标通常为48小时4次为可接受范围，这个就叫产品的成熟度。包括bug概率小于5%，7*24小时允许全年累计故障时间不超过10小时，都是对系统成熟度的要求指标。

这些指标，都不是功能本身，但它直接决定了一个产品是否能够真正大规模的推广和应用，也决定了它的价值。多数情况下，B端产品在稳定性更容易提出可靠性指标，这个可能和传统软件工程诞生于企业业务有关，而C端的可靠性除涉及金融等敏感和关键性信息以外，多数情况都被有意或者无意的忽略了，特别是互联网的快速响应文化，导致PM们更容易琢磨功能。

这一点，和硬件产品经理存在显著差别。硬件由于它的特性，可靠性是一个重要且复杂的课题，完全不是三言两语可以描述清楚，本文暂时不再详尽展开。

03、及时性（性能）

及时性也就是用户对性能的要求了，随着近年来硬件水平的提供，各种参数党满天飞，性能评分成为了评价一个产品的最直接指标。

性能指标直接影响用户体验，多一秒延迟都会让用户感觉不爽，同时性能指标也直接决定采用的技术方案和产品成本。不管是数据结构的设计和服务器的部署方式都严重依赖产品的性能需求。比如，当业务数据量达到一定数量级，则惯常的方式就可能导致支持不了，必须考虑采用读写分离等特色方式。

不同的通常，其性能要求差异很对。对软件产品来说，至少要首先搞定3个指标：

1、业务量

每日最大成交订单数1000笔业务和每日10000笔业务，其业务规模是两个完全不同的概念，这个和行业、规模、商业模式、使用方式等密切相关，在设计产品架构时，可以从历史数据进行评估，也可以收集行业和竞品数据，然后再次之上进行预估未来一段时期内的业务，并适当乘以冗余量。这个就是产品的设计容量。

ps，多说一句，任何一个产品都是由其商业模式决定的，产品经理一定要多去思考业务，而不仅仅是功能。

2、响应时间

你有没有思考过一个问题，app的一个弹窗提示应该停留2秒还是3秒？

响应时间是最直接的体验，一个数据一个页面多1秒和少1秒的使用感受存在很大差别，各种loading动画，进度条，分页显示技术都是为了减小用户在等待期间的焦虑情绪。

一般来说，页面响应和加载时间应该控制在2秒以内，超过3秒就会让用户有一短“慢”的感觉，因为3秒时间对人来说就是可以很直观感受的时间差。当打开一个信息条目超过1秒时，用户也会开始产生不连贯的视觉差。

登录响应时间在2秒内，刷新栏目响应时间在2秒内，刷新条目分页列表响应时间2秒内，打开信息条目响应时间1秒内，刷新部门、人员列表响应时间2秒内。

3、并发数

并发，也就是单位时间可以可以完成的功能和处理的数据。游戏为什么要假设那么多服务器？根本性原因就是要解决瞬时的并发数，过多的玩家同时挤入一个服务器，会直接导致游戏的流畅性。所有的业务系统，都受这个指标影响，必须找到一个可以相对准确估算业务并发的公式，并在系统设计之初就综合考虑整体的架构设计。

对业务系统来说，也存在固定并发的情况，例如某个功能仅限定财务部门使用，部门的使用人数是固定的，就可以结合部门数量估算，切记过度考虑并发数甚至夸大，因为它往往带来更多的产品成本。

作者：杜松

公众号：产品微言

频率问题，几乎没人关注，特别是小项目……

当然主要是很多人不会写只会抄，所以只有download……

加上时间那么赶，成本没人愿意付，所以干脆不考虑……

突然被邀请，之前回答邀请规则的时候，知道PMCAFF的邀请规则，是无规则……所以我并不能系统回答这个问题，但是分享三个小故事。

1、刚做产品那会，有一次领导交代，找出所有我们的软件产品卡的地方，让开发优化，那时候第一感觉是？？难道卡还能解决？如果能解决，做的时候为啥不做好一些。后来我们找出来，从策略和代码上优化了一波，果然软件顺畅了很多。

2、有一次做活动，活动刚上线，直接卡死了，活动无法继续，开发一查，原来是并发不够。原来是产品上线一直不温不火，活动让用户暴增，是开发那边没想到的，各种增加并发后，我们的产品顺利迎来了第一个爆点。

3、有一次做活动，产品页面有一个输入框，口头交代开发，这个地方产品方面是不限制字符格式的，如果开发有安全性考量，请对需要的特殊字符进行限制输入。后来，页面除了问题，被恶意注入了，造成了一些损失。后悔没有把这些需求写进文档。

作为c端产品，这些比较边缘细节的需求，往往在产品测试的时候才能发现，如果前期未考虑这么多，则可以通过快速版本迭代进行修正。

价值很定是有的，至于说为什么现在很多公司/产品经理都不重视这一块的内容，我想跟现在产品的节奏有关系，很多公司都是抢着时间上线功能，一周一迭代的情况已经很普遍了，准确点来讲，不是大家不重视，而是大家选择性地放弃掉了，这一块的内容对于多数产品来讲并不会产生直接明显的影响，但是，并不代表这一部分内容不重要。理性看待、权衡选择。

谢邀，个人看来，在写需求文档时，涉及到交互的一些规则和用户体验一类的非功能性需求，是要去写的 。比如查询时间、某些界面相应的文本框提示文字、特定场景下时间的上下限设定等，但是主要还是根据自己的产品来写文档，这个才是关键。 不要为了写文档而写文档，那样直接从网上拔下来就是了。

价值肯定有。不管是从产品需求规范和标准上来说都具备一定的价值。楼上几位也说得很清楚，点赞。

意义：无。

（算了，还是补充下吧，大部分甚至绝大部分产品其实都是为了写而写，不管是炫技也好还是 KPI 也好，都没啥意义，也比较难实行，落地太差。有些标准也很模糊，估计评审会上产品自己也说不清楚。）

鄙人拙见，非功能性需求是必须考虑的，只是要分下深度和广度，这种一般都要包括软硬件

一方面是存在应用部署在自己购买服务器，然后放在IDC，自己做服务器运维，自己买防火墙，请第三方做渗透、压力测试等等。

一方面基于云服务的普及，越来越多的会产品会选择云服务，而云服务提供商早已为你提供好了解决方案，比如网络安全、性能的问题。

非功能性需求，这个定义和理解就是有问题的，安全性，稳定性，抗压性都是产品必不可少的，往往老板或客户挂在嘴边的。

把安全，稳定，抗压这些脱离产品实际业务流程操作的称为“非业务功能需求”，这样就不会困惑了；

非业务功能需求，看项目使用要求，不同的项目对非业务功能需求的侧重点不一样，不管做好哪一方面都很牛逼。

在回答这个问题前，我觉的先问下自己，“自己把这个“产品”定义成了什么”。

需求文档仅是一个通用模板，只是我们这些“产品经理”大多数都是“软件产品”（被框住了，）。但是这个需求文档并不是针对“软件产品”的。（关于软件的非功能性需求，看别人回答即可。）

所以，跳出这个软件行业的这个前提考虑。假如这个产品是汽车、手机这样子的硬件产品呢，那么我们很多人除了“操作”上的需求，是不是更关注各种“性能”？

在我看来就是那些不影响，或者影响概率很小的非业务需求。简而言之，没它，业务路径能跑通，业务不会中断，可能就是用起来不爽等等。