先划重点：
功能需求 就是把具体的用户需求，变成软件的功能要求。 比如客户要把交通事故照片通过app发给保险公司。这是用户需求。
那么功能需求就是在这个模块下，要具有提交报险事故照片功能，上传现场照片。
功能需求 是基于业务需求和用户需求进行需求分析的结果，为满足业务需求和用户需求提出的一组产品功能列表，功能需求构成了一个完整的产品抽象模型，是产品设计团队进行产品设计和产品研发团队进行产品研发的基础。
需求文档2.0：三个原因，解答我为什么用excel写需求文档
产品需求文档模板演示实例：
护工助手app产品需求文档
PAGES需求清单
产品需求文档丨云之家V1.0版需求文档
Axure需求文档应用：手机流量监控产品功能设计
小程序产品需求文档prd（案例详解万字）
需求、功能、交互说明
很多人在写功能说明、交互说明时，总是会遗漏一些细节，逻辑不严谨。从以下几个维度去说明，将会让你考虑的更加全面：
字段、字段说明、数据来源
前置条件、排序机制、刷新机制
状态流转（一个页面可能有多个状态，需要说明）
交互操作（正常操作、异常操作）
下面，笔者将以一个页面做举例说明：
需求、功能、交互说明
功能
功能就是指具体能干什么了。要描述清楚这一部分，同样需要从过程、条件、元素三个方面入手。首先我们要说清楚这个功能是如何实现的；其次要描述清楚在实现这个功能的过程中，会有哪些限制条件，例如视频网站中有些视频资源是会员用户才能看；最后还需要明细功能所附带的元素，例如，用户要删除自己上传的视频，那就需要添加确认信息框，信息框上有哪些按钮，分别有什么作用，文字如何描述，都需要进行说明。
这个是前两天我们软件主管和我的谈话内容
目标：
一个月时间：最多一个半月
表格形式，所有功能列出来
使用者的程度了解功能是什么，做成什么样的，需求文档
开发者的角度，后台有数据接口，列清楚，变成设计文档
所有代码啃过来，之后怎么实现
问测试看一下所有bug，根据bug看怎么解决的，为什么会出现，不要求整理文档，
功能是什么。做成什么样。
功能应该实现的逻辑。
什么样这个功能算是ok了
要成为验收软件合格不合格的依据。
传到后台的数据
开发目标
7.17
乍一看，是让我写一份需求文档，于是百度找了很多的资料
写了一个登录，然后拿给主管看了，
你猜他会说什么
他说我没理解对，
可是我还专门搜了专业的，人家教我那样写的啊
黑人问号脸？？
又和我解释了一遍，要从用户的角度
或许我应该写一个 需求说明书 站在客户的角度讲产品功能
《软件需求规格说明书》简称SRS，SRS一般不是企业方（委托方）所做，而是开发方（被委托方）根据企业方的非标准文本或口述资料整理所得。SRS也不仅仅是为了明确需求，更是为了协调各方（企业用户、架构师、开发者、测试人员、部署人员）统一目标的第一个标准文档。一旦项目比较庞大，跨越多组织多部门时，这个文档就很重要，省去很多沟通上的众多麻烦。https://www.jianshu.com/p/f9bcf52f4321
从理论上讲，需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。
参考 这个
写一下
去问了一下ui，站在用户的角度写的需求文档，他和我说这个叫做 prd文档
产品小白如何写PRD？PRD文档入门实例——人人都是产品经理APP需求文档：
我们的产品需求文档究竟是写给谁看？这些不同角色的人都关注什么？
产品实际用户：这是我们产品上线后实习使用的用户，他们关注的是原型。通过页面原型而不是文字描述让他们感知这是一个什么的产品，知道各个功能块，以及操作流程，从而能给我们建议。
交互设计师：关注页面呈现、操作逻辑，让他们了解产品功能和逻辑，从而在视觉和交互上优化产品。
前端：原型页面、功能、交互逻辑、操作逻辑，涉及到产品最终呈现效果。
后端：业务逻辑、技术逻辑，其次是原型。
测试：页面细节、功能细节、各种情况出现的相应方案。
leader/其他部门同事：产品目标背景、产品迭代历史、产品最终效果，这类用户更关注的是我们为什么要做这个产品？这个产品被我们做成了什么样子？
发现自己有时候真的在理解别人和找资料上面花费了好长好长时间，导致效率低下
7.22
写了一周的需求表，发现还是没有理解自己要写的内容
贴出来写的一部分
带着这个我又跑去问主管了
之前你说使用者的程度了解功能是什么，做成什么样的
是不是场景描述或者流程
他给我举例，你去买眼镜，这个需求是什么
我说：好看，薄啊
然后他说，拿给你个老花镜是不是满足需求了，
旁边宋哥就说，需求就是度数啊，恍然大悟
就是把功能点一句话描述出来
这回是真的理解了
看一下别人解释的业务需求，用户需求，功能需求的区别
知乎：业务需求、用户需求、功能需求是什么意思？有什么区别？
用户需求
是从某一类用户的视角看他使用这个软件的需求。比如，作为用户你用淘宝，找东西，拍货，付款，你有怎样的需求。作为卖家，你用淘宝怎么收款，发货，管理订单。 这就是一个个的use case 或者 user story。 所以 写user story ， 开头第一句就是 As a xxx. 这都是从个人视角去看需求的。
业务需求
你整理完不同视角的需求，就要一个更高层面，更全局话的角度看需求。就要把这些需求串联起来。特别是把全局的流程梳理出来。从个人角度，是看不到全局的流程的。但是要想把业务梳理清楚，特别是数据流。就需要这种全局视角下的梳理。我们才清楚 use case/user story 是在什么场景下。 特别是有时候，不同的用户的需求可能存在冲突。通过这种全局性的业务需求梳理，可以去发现潜在冲突，并平衡需求。
功能需求
就是把具体的用户需求，变成软件的功能要求。 比如客户要把交通事故照片通过app发给保险公司。这是用户需求。 那么功能需求就是在这个模块下，要具有提交报险事故照片功能，上传现场照片。如果再具体下去，就是界面交互图。 现在互联网公司一提产品管理，需求设计，基本就是UX。 需求过于碎片化。
作者：淡淡的忧伤
链接：https://www.zhihu.com/question/24191618/answer/88163277
业务需求需要从两个层面来理解，一方面是2B领域的概念，指在2B软件实施的过程中，业务部门（如销售部门、财务部门等）基于日常经营过程中的各种业务往来提出的解决方案需求；另一方面是站在企业的角度，基于公司商业需求和核心用户需求提出的高层次的需求概述。
用户需求用户需求需要从两个层次去理解，一种是用户的本质需求，即我们通常所说的用户的need，比如：用户“饿了，想吃东西”，解决饿了的问题，就是用户的需求；另一种是用户想要的解决方案，即我们通常所说的用户的want，比如：用户“饿了，想吃饭”，吃饭就是用户的需求。
功能需求功能需求是基于业务需求和用户需求进行需求分析的结果，为满足业务需求和用户需求提出的一组产品功能列表，功能需求构成了一个完整的产品抽象模型，是产品设计团队进行产品设计和产品研发团队进行产品研发的基础。
链接：https://www.zhihu.com/question/24191618/answer/173896639
业务需求，可以理解为想法只是一个想法，但这个想法是基于公司内部的，
例如一个阅读软件，
老板提出一个 阅读器阅读时要可以翻页，这就是一个业务需求，
产品经理根据老板提出的这个需求，提出来通过声控翻页，这就是一个用户需求；
产品经理提出来之后交给开发，开发通过调用语音识别系统实现声控翻页，就是功能需求；
业务需求最直白，用户需求提出方案，功能需求实现结果。
作者：无限
链接：https://www.zhihu.com/question/24191618/answer/523691459
了解了一个新名词：需求边界
PRD（Product Requirement Document，产品需求文档），顾名思义是阐述产品需求的一种文档，其核心是将需求描述清楚。
首先，先了解清楚PRD的阅读对象，使用者。
PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。
功能需求
功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：
简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。
业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。
界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。
使用者说明：对产品使用者做出说明，可融入简要说明中。
前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
后置条件：操作后引发的后续处理。
主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明（这是非常重要的）。
看过很多的PRD，文档中对既没有前提条件，也没有后置条件，只对主流程做了说明，但是在描述主流程时却没有描写主流程中每个功能流程的各种走向，只有一个主走向，让人感觉prd成了操作手册。事实上，对分支的介绍是非常重要的，开发和测试中提出的各类问题均与对分支的定义不明有关。一个合格的PRD不仅要描述主流程，同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。PRD的特征一定是明确的、全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案（虽然PRD不可能百分之百的覆盖所有的可能，但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则）。另外，在描写功能需求时给出的办法中不能出现“可能”、“或者”等词，一定是明确的，唯一的描述。如果有别的方案，建议写入“可选方案”，在产品构建的早期可选方案可以为功能实现提供更多的选择，当方案确定后可在文档中注明本次使用了哪种方案。
推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。
产品分析报告：万字长文，全方位拆解国民应用微信 http://www.woshipm.com/evaluating/487857.html?utm_source=wechat_session&utm_medium=social&utm_oi=631585448561086464