需求分析方案 第1篇
通过分析用户体验路径，找到各个接触点，了解用户在使用的整个流程中遇到的问题，结合关键因素分析提出合适的解决方案。并完善流程中的各个步骤。在实际过程中，也可以以对比竞品的用户体验路径来完善自己的产品。
整理关键因素，归纳解决方案，确定和各个部门的任务，提高效率。
根据各个接触点的问题提出如下的解决方案设想。
不要盲目的去画线框图，只有在设计方案前，更好的理解和分析了需求，才能很好地服务用户帮助用户使用产品。同时，只有站在用户的角度去分析理解产品，才可以帮助产品站在全局的视角提升用户体验和设计需求，从而打造优秀的用户体验。
需求分析方案 第2篇
目标用户是指使用某一产品或服务的典型群体，不是个体。目标用户同时也是产品或服务的直接接触对象。比如小凌如果报名学习线上英语，但是付款的是他的爸爸而不是他自己的时候，这里的直接服务的人是小凌而不是小凌的爸爸，所以目标用户是小凌，而不是小凌的爸爸。
在分析用户需求时需注意，用户描述的需求一般都是外在表象，用户自己不可能提出自己认知外的方法。用户体验目标是指用户在使用产品时，期望得到的最终成果，这才是内在的原因和动机。
需求分析方案 第3篇
当系统复杂、涉及到不同的业务时，就需要通过业务子系统划分，将系统分解成更小的业务单元，以解决系统过于复杂的问题。根据系统特点，选择合适的划分策略进行分解。
对于支持管理业务的系统而言，最典型的业务子系统划分策略就是按部门职能进行划分的。
通常在开发外部服务系统时，可以先梳理出业务结构，然后以不同的产品服务作为划分线索。
对于新开发的系统而言，最常用的策略是按业务职能分解、按产品/服务分解、职能/服务双维度划分、按关键特性分解。
对于系统优化的开发而言，最适合的方法是分析有哪些新增、修改，有哪些影响。
需求分析方案 第4篇
接口分析主要目的是了解各业务子系统之间的服务关系。
接口由哪些子系统实现更为合理？
哪些子系统会使用这些接口、什么时候使用、实现什么业务价值？
接口的使用频率如何、接口相关的业务发生的频率如何？
接口的交互由谁发起？
需要几次交互？
都是什么数据？
数据传输、通讯、内容包需要采用特定的协议标准吗？
接口实现时受到硬件、网络、操作系统的限制吗？
接口的性能要求如何、要支持多大的并发、要达到什么样的相应速度？
接口相关的安全性、可靠性要求如何？
需求分析方案 第5篇
一般项目方面的约束，可以从预算、资源、进度三个角度来分析。实现方面的约束，可以从技术选型、部署环境、开发环境来分析。
系统最晚何时上线？
可以分阶段满足吗？
用户方的指定接口人是否明确？
是否应要求客户成立项目组？
是否应要求客户提供场地、设备等资源支持？
用户有明确的预算限制？
预算范围是多少？
涉及的业务范围有多大？
同类系统的建设资金在什么范围？
有相关技术规范做出明确要求吗？
服务器、终端、网络选型会对系统实现产生约束？
法规对系统实现有哪些潜在约束？
用户的文化、使用环境对实现有约束？
系统的生命周期会对实现产生约束？
开发团队能力、开发工具、环境对系统带来约束？
扩展：
产品需求的三个层次：基础性需求、期望性需求、兴奋性需求
马斯洛需求五个层次：生理需求、安全需求、社交需求、尊重需求、自我实现
需求管理的四个环节：采集需求、分析需求、筛选需求、处理需求
需求分析四象限：重要并紧急、重要不紧急、不重要但紧急、不重要不紧急
需求分析方案 第6篇
当确定了业务数据以后，还需要细化每个业务数据的构成细节，另外也需要对数据应用、数据特点进行分析。
该业务数据有哪些字段构成？
这些字段是什么类型的？
最大长度、取值范围、非空、键值吗？
哪些流程会用到该数据？
这些流程中会增删改查该数据的记录吗？
每个流程需要使用的数据字段有哪些？
哪些字段是常用的？
哪些字段常为空值？
哪些字段会作为关键字搜索？
哪些数据有扩展需求？
需求分析方案 第7篇
在接收一个需求的时候，需要搞清楚这个需求的使用场景是什么，用户是谁，用来解决什么问题。当我们清晰的了解问题以后，就可以对产生的原因进行分析，然后制定相应的解决方案。
在需求沟通时，需要挖掘用户的潜在需求吗？需要注意只需要挖掘问题，不挖掘方案。因为在问题级的探讨中用户是理性的，而在方案级的探讨中用户是感性的。用户只是问题专家，我们才是解决方案专家。
使用场景：细化业务场景，分析有多少个流程，整理用户预期的正常流程，再确认存在变化的情况。
存在问题：针对这些流程，从用户的角度思考当前存在的问题，会遇到什么问题。
解决方案：针对这些问题，思考系统应该提供什么样的功能。
需求分析方案 第8篇
识别业务流程时涉及两种边界，一是职能边界，就是跨越了我们未涉及的业务领域；二是系统边界，就是不属于系统关注的部分，做好边界分析，确定系统的边界。
信息系统的核心价值包括支持管理和支持业务，支持管理的核心是通过管理流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化；支持业务的核心是对业务流程的固化、优化和重构。
强调每个角色执行的活动：跨职能流程图
强调各角色间的协作交互：顺序图
强调数据处理过程：数据流图
从提出服务请求开始到服务被满足的流程中涉及哪些角色？
每个角色负责完成哪些独立的业务活动？
这些业务活动如何协作起来，串行、并行、异步？
有针对不同情况的处理过程吗？
在过程中应加入哪些审核点，以便控制风险？
在流程各环节有什么相关的规则？
有完全无法按这个流程执行的特殊情况？
管理者如何来监控流程执行的进度效率？
管理者对流程的哪些异常关注？如何来监控？
需求分析方案 第9篇
通常在团队多人的情况下进行，具体步骤如下：
1）N*4*4头脑风暴 N=组员人数，4分钟，4个idea；每个人写完向右手边传；收到的人先看一遍继续写不同的 2）分类重组卡牌，找到新的解决方案 最好不按照工种和人群来划分 3）先排定分组优先级，再排定卡牌优先级，并进行编号 看需求发生频率和体验，优先解决大用户量的高频问题和见效快且开发难度不大的问题 4）明确MVP阶段的流程设计 5）设计关键流程的MVP原型
如图，通常在产品探索阶段进行，找到产品的核心方向
图片来自于百度搜索
傲慢/妒忌/暴怒等常用在游戏上，三国杀、王者排位等 懒惰常用于代步工具和外卖上，如美团、饿了么、短程公交 贪婪常常出现在活动中，如满减、免费等字眼 暴食常出现在事物分享平台，如大众点评 _食色性也，如探探、陌陌等社交软件
KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意度之间的非线性关系。 KANO模型从两个维度来评估评估需求：
两个维度结合得到四类需求：
图片来自于百度搜索
四象限法则是时间管理理论中的一个重要概念。
图片来自于百度搜索
1 - 是用户需求，是分析的起点，代表着用户的观点和行为，包含谁，在什么时候什么地点，想要什么，想要做什么 2 - 是需求背后的目标和动机，其中包括企业目标、用户目标以及产品目标 3 - 是产品功能，相关实施的人员能看懂的解决方案，即用什么方案，做多少，做多久 4 - 是人性，是需求的本质。
由1到2和2到4进行分析的时候，多问为什么深挖目标和动机，找到需求的本质。 由4到2和2到3进行分析的时候，是找解决方案，看要怎么做，怎么解决，朝着哪个方向去解决。
图片来自于百度搜索
需求分析方案 第10篇
需求分析时，确认关键干系人至关重要，决定着上线的功能是否满足了用户需求。
干系人分析需要侧重他们的关注点，就是正需求，不过他们的阻力点（担心点，负需求）也是十分重要的，有时候用户特别关注不能怎么做。
读组织架构图，将相关业务部门负责人标识为关键干系人。
如果这些部门有分支机构则分支机构负责人也标识为关键干系人。
意见领袖、业务专家标识为关键干系人。
对一大批基层用户带来影响的，则基层用户是关键干系人。
具有一票否决权的，也是关键干系人。
技术实施存在风险的，开发团队也是关键干系人。