程序需求文档怎么写（怎么做出好的功能需求文档）
程序需求文档怎么写（怎么做出好的功能需求文档）（1）用户来这个产品/你要设计的功能 是干嘛的？你为用户提供了什么价值？这个价值真的是用户所需要的吗？进行用户使用的app产品设计，一般在正式画app的界面前要确认以下信息，这些信息和界面息息相关，千万别偷懒，我建议新同学们直接动笔记录回答，在界面设计中反复回来查看。我刚转行做产品经理，我该怎么画原型图？随着带产品新人经验越来越多，一遍遍纠正新人在画原型图中的缺点，陆续就沉淀了一套通俗易懂的方法。希望未来还有人问我相同问题，我可以用这篇文章解答TA的相关问题。
作者：Jocelyn酱
本文在PMCAFF社区发布（www.pmcaff.com），转载请注明作者及出处。
在做产品的这几年，总会有人来问我：
我想做一个软件，我该怎么画原型图？
我刚转行做产品经理，我该怎么画原型图？
随着带产品新人经验越来越多，一遍遍纠正新人在画原型图中的缺点，陆续就沉淀了一套通俗易懂的方法。
希望未来还有人问我相同问题，我可以用这篇文章解答TA的相关问题。
一、动手之前进行用户使用的app产品设计，一般在正式画app的界面前要确认以下信息，这些信息和界面息息相关，千万别偷懒，我建议新同学们直接动笔记录回答，在界面设计中反复回来查看。
（1）用户来这个产品/你要设计的功能 是干嘛的？你为用户提供了什么价值？这个价值真的是用户所需要的吗？
（没有价值、价值不是用户需要的，或者需要这个的用户数很少，建议降低优先级，去想更核心的功能）
（2）你认为这个产品/你要设计的功能 和市场上同类app差异化是什么？共同点又是什么？你认为你进行的需求设计在哪些方面和竞品要有差异化？这种差异化是否与产品给用户核心价值相关？
（如果差异化不成立，不建议天马行空的浪费研发成本，这种差异化的存在可能是：产品定位不同、产品目标群体差异等
（3）确认你设计产品/功能的目标用户。调研和了解这群人的画像。
（功能的用户画像不一定是产品的用户画像，比如直播间家族用户群可能是公会用户为主，而非app所有人）
（4）确认你设计产品/功能用户核心任务。张小龙说：一个产品只能有一个主线功能。
所以，判断自己这个产品/要设计的这个功能 主线的用户任务是什么？
好的，以上想明白了。你在产品设计/功能设计上的背景是想明白了。
这里建议产品实习生等新同学主动和上级沟通明白这些逻辑，要不然设计出的原型图就是靠自己想象的背景画出来的。
二、开始设计产品开始设计产品，错误做法：
一上来就打开软件，开始画图。边画图边想这个页面要什么功能、什么信息。
这会导致你的原型图走偏，和你要设计这个产品/功能的目的不一致，也不能系统的显性出产品/功能的差异点。
所以，我建议复杂的产品/功能设计还是多花点时间在前期的思考上，把画图留在最后。
接下来我列一下画图之前要写出的内容，其中部分内容也会在标准的需求文档中体现。（需求文档结构我在文末列出来给大家哈！）
1、用例图
用例图类似图中这种。（图片来源于网络）
用例图包含：角色、干什么事/任务
【价值】：帮助你整理你的设计中需要涉及到的角色（普通用户 or 运营人员 or kol ）。尤其是梳理需要运营后台设计的功能，这个贼好用。
2、流程图
流程图是C端设计中常用的。（图片来源于网络）
我经常用的是用户任务流程图。写清楚用户在产品/功能中主要完成任务的流程。
【价值】：会帮助你梳理设计中所需要的功能、需要判断的关键信息（如登录与否，是否已有×数据），不同关键背景用户完成任务流程的差异。
当然，app设计还会用到“业务流程图”，业务流程图是为了让产品经理更清楚产品底层的流程，和其他业务模块交互情况。
比如：
一个内容发布的用户任务流程图是：用户点击发布按钮，判断是否登录，编辑blabla，点击完成按钮。
一个内容发布的业务流程图是：用户发布内容，内容进入第三方平台自动化鉴定，鉴定完到运营后台，运营人员审核。
业务流程图如下：（图片来源于网络）
在画原型图之前，用到用户任务流程图比较多。
在进行模块和业务设计之前，用到业务流程图比较多。
C端需求文档根据需求复杂度和具体功能可以选用不同流程图
3、信息结构图
信息结构图是用来说明：
产品页面或者产品某个内容有什么具体信息字段的。
我举个例子：
如果我需要设计一个电商商品的模块，我需要思考商品都有哪些信息字段，比如：商品封面图、商品名称、商品评价等。我考虑首页需要推荐商品，所以商品的信息架构中我会加入“是否编辑推荐”这个字段。
但同时，我需要输出一份C端商品详情页面的信息结构，让别人来帮我设计商品页面原型图。那么我不会把“是否编辑推荐”这个字段写上去，因为我不希望C端显示出来。
我还需要设计一个商品列表页面。商品列表页面中每个商品露出的信息字段一定是在商品的信息字段中的，也会少于C端商品详情页显示的信息。因为列表位置有限，我只能挑选更核心的字段拿出来展示。
总结就是：页面的信息结构整理的只是当前这个页面能看见的信息。有一些信息字段是存在，但不在这个页面展示，或者是在使用但用户没看见的。
产品从0-1的过程中，我们更需要设计模块，和具体内容的信息字段。
成熟产品的功能/页面需求，梳理的更多是页面信息结构。比如：微博的内容有很多信息字段，如果让你设计一个微博内容站外分享打开的H5页面，你会挑选哪些信息展示呢？会新增哪些信息呢？
【页面信息结构的价值】
让你更关注于目标用户在特定场景下需要的信息。
如果一开始就上手画图，边画图边思考这个页面需要什么信息，容易被图中的排版干扰，忽略场景下用户最需要的信息字段。
所以，页面信息结构的输出过程，更像是让你梳理明白内容的所有信息字段，结合用户特征和场景筛选出你这个页面最需要的信息字段的过程。
新手产品可能一开始难抽象思考信息结构，那也可以边画图边思考。不过我建议画图后，再审视下页面信息是不是用户需要。
4、原型图
终于到原型图这一步。
上面我们梳理了：产品/功能价值、目标用户画像、核心任务、竞品差异化、用户用例、用户任务流程图、页面信息结构。
基本可以确认：需要几个页面，不同页面的功能点是什么、页面除了功能按钮，还需要展示的信息是哪些。
那开始排版吧！
排版可不是排列组合的事情，我们是需要解决：
（1）用户第一眼感受和认知是什么、
（2）用户看了页面后是否优先获取了自己最想知道的信息，是否足够吸引用户查看？或者帮助用户解决问题？
（3）核心任务的操作是否可随时随地找到。是否符合用户交互习惯。
一般来说，我们会借鉴用户感知类似的产品界面设计，也会在自己想体现的核心差异化上做创新。
这个需要大家多分析竞品和多练习啦～
附录：需求文档格式我列一下标准的需求文档的格式。基本C端的功能设计需求、新的产品模块设计都适用。
其他技术类需求、B端需求就自行辨别哈。
（1）人员分工
确认自己需求所需要的人员资源，后期团队确认后，添加到具体人名，方便团队成员查阅和责任到人。
常用的角色有：产品负责人（就是自己）、技术负责人、客户端、前端、服务端、AI、设计、测试、运营
（2）需求背景
讲清楚这个需求是如何产生的。把自己的思考逻辑写清楚即可。比如发现了什么用户的什么需求没被满足。
如果有量化数据，也建议加上，说服力更强。
（3）需求目的
自己需求的主观目的，比如提升什么、改变什么、解决什么
（4）需求目标
需求最终考量是否达成目的的量化数据，也可以作为自己需求的北极星目标。
（5）核心逻辑
向团队解释你做这个需求方案为什么能达成需求目的。
这里是要说明白自己方案的思考逻辑，同样达成目的的多种方式里，为什么采用了这个方式方法。
（6）用户任务流程
不解释了，看上面具体说明。
（7）需求详情
需求详情包括：
需求项目——哪个功能点、哪个页面
需求原型图
需求说明——结合原型图说清楚自己的具体需求，包括什么信息字段，字段从哪里产生的，字段格式，字段特殊说明；功能需求、特殊情况说明、特殊提示。
（8）运营需求
配套的运营需要干的事情。
一个好的产品经理是纵观全局的，不是生完孩子就啥也不管了，那你的功能可能永远都跑不出来。
（9）埋点
埋点需求是提给DA或者研发的，不同团队要求不同。
埋点的目的是：让自己后期能监测到关注的功能的用户情况，方便继续迭代和发掘问题。
（10）需求变更记录
我用过几次，主要是记录自己的变更记录。方便其他成员查看。但是简单的功能我基本没怎么用过。毕竟我感觉口头沟通后，直接改需求详情更好。
