一. 一个好的需求要能够被理解
1. 需求的评价标准
a. 为何要做：市场背景，收益分析，在单里有非常清晰的体现
b. 怎么做：从框架到细节，从前段到后台逻辑，体验到性能（比如直播：评论之后是否所有人都看的到，讲师时间是否跟听众一致），跨平台都考虑细致，图文并茂
c. 做得如何：有非常清晰的衡量标准，包括完整的abc思路，上线查看（功能的渗透率，做了优化提升率，口碑上吐槽点修复）
d. 严格遵守提单流程：分类正确，标题，必填字段符合规范，提单时间不晚于每周截止时间（需求单需要在固定的评审时间写好）
二. 从用户和数据视角判断“为什么做”
需求背景（为什么做）
1. 需求来源（核心：用户反馈+数据分析）
a. 用户调研/反馈？
b.数据分析？
c.猜想（from老板）？
d.产品推理？
e.竞品？
2. 需求目标
a.用户当前痛点是什么
b.如何解决
c.解决平台什么问题
d.是数据导向？口碑导向？还是创新导向？
3. 需求容量的预估（需要通过公开数据或APP内部数据+经验预估容量）
a.多少人会使用这个需求？
b.使用这个需求的人有多频繁？
（不要把自己的需求当需求）
4. 竞品分析
a.市面上是否有竞品？
b.满足用户程度如何
c.体验如何
d.是否已经形成口碑
e.我们的差异是什么
f.我们做这个需求的优势是什么？
比如:视频类APP：海外有YouTube，国内有爱奇艺，优酷，腾讯视频，B站。弹幕的体验上，氛围口碑远比不上B站。从哪个地方可以突破，做这个点是否可以跟其他产品产生不同，突围而出
5. 需求紧急程度（老板类需求应指明，有版本或时间关联需指明）
a.为什么现在做？是否可以推迟？
b.有外部环境压力？大大老板压力？
c.抢先布局
6. 需求量化收益
是否可以量化？量化后服务什么指标？预计收益？eg：做增长的功能，新用户进入app给他一些任务或者权益，让他连续7天都要来（签到功能），签到功能能提升多少留存率，这个功能可能跟大盘有影响，把这个影响量化下来。总结：在需求评审时，可以提出：这个需求对这个app的帮助是怎么怎么样的，它可以提升多少留存，有了这些留存，可以提升多少活跃度
7.补充背景说明
a.过往需求单，帮助了解背景（迭代版本）
b.过往需求数据，辅助评估收益（比如：增长功能上线的收益是怎样的）
三. 从需求规范和描述学会“怎么做”
1. 需求简介
a. 一句话到多句话描述这个需求通过哪些功能满足用户，分工角色各自是如何的（只讲需求要点）（概要）
b. 根据需求分类，决定用什么图例给予大家一个全局视野
· 交互视觉流程图：适用于前段逻辑较多，后段逻辑较少的需求
· 逻辑跳转/泳道图：适用于后段逻辑较多，但数据传输较多的
· 算法策略list：适用于纯算法类，枚举策略（偏后台）
（算法表格：用户行为->推荐结果->推荐结果预期->歌单推荐模块应有的反馈）
·交互视觉图： 适用于单个页面优化
c. 为后续模块标记编号，方便后续需求对应
2. 分模块控件需求描述
a. 模块间（需求大的情况下需要将需求进行拆单）
· 超大型如“歌手主页” 动辄几十天工作量的需求，可考虑拆单，主单保留背景，简介，分模块子单介绍（比如：首页：banner, 歌曲推荐模块，视频推荐模块，评论推荐模块）
·模块间关联
·按照前面模块编号分开描述
将大需求拆分成小需求，更好理解需求点在哪，需求开发理解的地方在哪）
b. 单个模块
·由于模块是由多个系统控件（按钮，列表等）+自定义空间组合而成，必须熟读控件规范，写每一个控件时，应该知道控件特性以及要注意的点，避免遗漏（比如：按钮：左边取消，右边确定；添加歌曲使用➕；播放按钮是▶️
·由于控件内的数据填充是写死或下发的，尤其下发需要注意数据延迟（网络+后台数据拉取压力）loading,数据不完备前是否可交互等问题（保证第一屏第二屏是有显示的，用户体验好）
3. 非功能需求
a.性能：包括页面流畅性，动画，数据延迟，后台或前段并发数
b.安全：是否需要接入安全，UGC的尤其需要考虑->写操作->评论，发动态，发各自内容
c.产品兼容性需求
·单端改造会不会影响其他平台（官方歌单更新在移动端先做有可能影响pc）
· 需求是否影响其他需求（如需求是否支持换肤，影响皮肤）
· 高低版本是否兼容问题（高版本接口或数据影响低版本导致crash等）比如 1.0版本可以看视频，2.0可以看直播。直播就无法在1.0版本上。那么1.0版本的用户在这个模块显示什么样的，会不会跟之前的版本有冲突
四. 加分项：做好这几件事情能让你的工作更加分
1. 需求分类
a.按业务类型分
· 纯前段需求
· 纯后段需求
· 纯数据需求
· 纯运营后台需求
· 混合型需求
b.按需求目标分
· 新需求：创造新的用户价值（比如：视频app中本没有弹幕评论，增加弹幕功能
· 优化类需求：优化已有的价值：比如：目前有评论功能，但没有评论点赞的功能/或收到点赞通知的功能）
2. 交互规范
a.统一规范
1)是什么？解决用户什么问题？
2)适用范围（场景）
3)交互前样式：是否可点可操作/是否有换肤相关,比如弹窗：左边确定，右边取消（确定按钮是不是要变红，取消是不是要保持灰色，是不是可以点击，要营造一种button的点击感）
4）交互：及时反馈（点了确定之后，是不是有个弹窗告诉用户操作成功）/加载过程（动画）（loading ）
5）交互后样式（关注up主，关注前，按钮是亮的；关注后，显示已关注，按钮是灰的；如果取消关注，需要找到这个人的个人主页，点击取消，降低取消概率
b. 分样式规范
1) 按钮：图形按钮；文字按钮
2) 提示：对话框；弹出框；toast（点击后，停留两秒自动小时）
3) 列表：横向列表；纵向列表
4) 速度指示（loading）（一致性）
局部：进度条；菊花
页面
加载异常：页面加载失败重试/页面缓慢提示
5) 空状态：没有数据的情况
比如：我的粉丝，关注数为0，需要设计统一，比如推荐一些人
6）输入控件：文字输入框（必填有红色星星，输入框有些解释）；上传；单选；多选；筛选框；时间选择器
7）导航控件：tab（web 端）
8）展示内容：
文字：字的大小间距，多少个字
图片：可以展示多少张图片，超过9张改怎么展示
视频：滑倒是否要自动播放，自动播放是否需要有声音
9）复合控件
评论中：点赞，写，删，转发
feed 卡片
c. 文案规范
1. 数字规范：如数量超过999，显示999+，超过9999，显示10000+
2. 语言规范：如登陆还是登录；取消还是关闭，后退还是后退箭头，都需要统一。
总结：需求端的核心作用是将我们的需求转化为文字，能够让所以团队中的成员按照这文字进行后续的工作，比如说开发，测试，运营看到你的需求单，知道你要做什么，他需要做什么，是否满足产品经理的要求。在标注时，最好原型图和文字结合，需求单越详细越好。比如下拉出现几个视频，需要写清楚。而交互只是需求的很小的一部分，在临摹需求的时候，要理解为什么要做，核心诉求是什么？记住产品经理更关注的是业务！
