在做需求原型的时候，不管自己写再细，到了评审或研发测试阶段，研发同事经常找你咨询需求中的具体细节问题，而这些刚好你是没有考虑到，或者没有写进文档里面。
那如何去避免需求遗漏这样的问题呢，在实战过程中，我通常会分5个步骤检验自己的需求是否完整。
1. 业务流程
首先，理清业务流程，用户在什么场景基于什么目的使用该业务。
流程要做到以下3点：
- 来源；
- 去向；
- 异常情况的处理规则，穷尽回归法。
举个发帖流程例子，填写帖子内容>>发布>>发布成功，生成一条帖子>>跳转到我的帖子页面。如果发布过程中遇到网络异常，则无法生成帖子，停留当前页面，toast提示用户“网络异常”。当然这只是简单的例子，细心的朋友会发现还有很多需要补充的地方。
2. 内容数据
数据交互是普遍存在的场景，比如：商量列表，搜索结果等都有用到。数据类型一般分两种，一种是静态数据，一种是动态数据。静态数据相对简单点，只要保持数据的完整和准确性就好。
动态数据就需要考虑到数据的来源和交互规则，重点是交互规则，通常要做到两点：
（1）排列规则
按内容权重，按时间
（2）加载规则
- 数据加载方式：全屏式加载、整页加载、自动加载、智能加载、离线加载；
- 怎么触发加载：本地缓存、手动加载刷新、自动刷新加载；
- 加载时间：加载时间多久、多久加载一次；
- 加载状态：加载成功、加载失败。
3. 功能触发
业务功能中的控件交互触发规则，按触发的状态来检验。
- 触发前：要有提前设定好的初始内容，比如：灰度、默认值、提示文本、限定值。
- 触发中：是否要预检，触发规则。
- 触发后：结果显示规则，异常情况处理（弹窗、toast、警示窗）。
下面以后台添加数据为例：
4. 网络规则
交互过程中的网络规则有两种，一种是一直没有网络，另外一种是的促发的过程中遇到网络中断。遇到一直没有网络的情况，推荐走全局交互规则，一般适用于所有功能。
重点是网络中断时，应该怎么交互：
- 中断任务，让用户重新操作；
- 重试，多长时间重复一次，限制多少次；
- 前端提示成功，后台进行数据同步处理（处理方式同第二条）。
5. push消息推送
该业务执行过程中，是否会触发到消息推送规则，给出push消息交互所对应的结果。
最后
我相信需求原型做到了上述的内容，你的需求完整度已经达到95%以上了。一个产品总有自己没有想到的细枝末节，实战的时候如果发现的话，那就慢慢完善吧。
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。