软件生命周期
软件生命周期：软件定义、软件开发、软件维护
软件定义：问题定义、可行性研究、需求分析
软件开发：总体设计、详细设计、编码和单元测试、综合测试
软件维护：改正维护、适应性维护、完善性维护、预防性维护
改正维护：软件运行中发生异常进行维护
适应性维护：针对软件的兼容性（系统兼容性、环境兼容性）进行维护，如win7开发环境，后期用户系统设计为win10，那么需要将软件维护可在win10系统正常运行
完善性维护：用户边使用边提问题边维护
预防性维护：开发期需要兼容未来环境，如开发期觉得未来流行大数据，因此在开发过程中需要考虑到未来兼容大数据环境
工作步骤
方法的顺序、交付的文档、管理措施、各个阶段完成的标准、任务分配
敏捷开发
敏捷开发的价值观
1.个体与交互胜过过程和工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划
用户模式
用户规模决定需求市场，甚至产品价值，只有足够的用户规模才能支持一款产品的成功，一般来说，用户的规模都可以从一些权威报告中获取关键数据。善用搜索引擎或者多关注一些行业报告以及购买定制专业的调查报告，都能够获取到这些关键数据。
商业模式
商业模式就是公司通过什么途径或方式来转赚钱，例如移动公司通过收取手机花费赚钱，快递公司通过送快递来赚钱，最重要商业模式要清晰。
AARRR模型
1.引流
2.激活用户
3.留存
4.变现
4.自传播
三级火箭模型
第一级：引流，带来用户
第二季：沉淀商业场景，留存
第三季：赚钱，可持续赚钱
5W2H
5W
what:做什么（事件）
why：为什么做（起因）
where:在什么地方做（地点）
when:什么时间做（时间）
who：谁做（人物）
2H
how do：怎么做
how much: 花费
SWTO分析方法论
SWTO分析方法是一种企业内部分析方法。即根据企业自身的既定内在条件进行分析，找出企业的优势、劣势及核心竞争力之所在，从而将公司的战略与公司内部资源、外部环境有机结合。
S优势
1.强大的平台支持
2.数量众多规范商家和有保障的产品
3.密集的客流量
4.服务优势
W弱势
1.产业链庞大运营成本较高
2.后端供应链和物流服务有待提高
T威胁
1.购物网站用户信息泄露
2.激烈的竞争
3.低价竞争压力大，商户盈利能力低
4.行业物流配送服务能力提升慢
O机会
1.互联网的普及，网购用户的增加
2.国家政策的支持
3.计算机技术的发展，网络购物安全提高
分析
S+O(优势+机会)为增长型：可以最大限度的利用机会，强势快速发展
W+O（弱势+机会）为扭转型：需要调整策略，寻求差异化竞争，避免与竞争产品正面交锋
S+T（优势+威胁）为多点型：需要调整策略，寻求多点突破
四象限模型
用户分析
用户分析是对用户角色（画像）与属性分析，首先，形成的用户角色需要有代表性，能够代表产品的主要受众和目标群体。据此分析用户的需求所在，以及用户认同使用产品的可能性，使用用户画像能够让我们在用户的动机和行为上进行产品设计，避免在个人喜好的基础上虚构用户带来的设计偏差。
用户画像一般包含且不限于以下静态标签：
姓名
照片
年龄
所在地
家庭状况
工作收入
场景/活动
计算机技能/知识
目标/动机
喜好/习惯
观念/生活态度
其他
功能描述
功能描述主要是产品原型与功能描述，在市场需求文档中，原型一般无需带交互，但是建议包含产品结构图（思维导图）和线框图，来表达产品结构，功能设计和使用场景。
业务三要素
业务三要素：业务目标、用户角色、职责。
业务目标：要完成一件什么事
用户角色：为了完成业务目标，那些人要参与
职责：为了完成业务目标，每个角色各自需要做什么事情
流程：为了完成业务目标，每个角色的职责顺序
如何得到业务三要素？
通过竞品分析，用户访谈或者产品经理自己的经验
什么是需求分析
原始需求-》产品需求-》产品方案
原始需求：用户描述自身的需求（有可能是伪需求）
产品需求：产品根据用户的原始需求进行挖掘用户真实的需求，如用户说想要一匹更快的马（伪需求），产品需求：用户想要更快的到达目的
产品方案：根据产品需求给出的解决方案，如坐跑车，坐电车，坐火车，坐飞机都能让用户达到自己的想要更快到达目的的需求
需求分析的重要性：
需求：朝廷想要一匹更快的马，接到需求之后不同的产品经理的解决方案如下：
产品经理1：
原始需求：想要更快的马-》挑选优质的马匹-》进行训练-》改善马的伙食-》提高马匹的伙食-》更快的马
产品经理2：
原始需求：想要更快的马-》为什么要更快的马？-》跑的更快-》为什么需要马跑得更快呢-》信件快速送达-》优质的信鸽
产品经理1：需要花费大量的人力，财力，时间完成了用户的一个伪需求
产品经理2：直接找到替代品快速完成用户真正的需求
核心要素：
1.挖掘用户本质需求（why）
2.确定产品解决方案(how)
需求获取
为什么要迭代？
用户的需求在不断的变化，所以产品为了满足用户的需求需要不断的迭代。
需求是什么？
需要被满足的要求
需要：预期和现状存在差异，产生“需”
要求：包括提出的问题，希望达成的目的或者想要的解决方案
例：
如朝廷想要一匹更快的马
需求：其实是更快的送信
要求：更快的马，更快的马是需求方自己给自己的一个解决方案
可知：这个方案并一定是最好的，并且还有可能迷惑解决方案方
当用户提出伪需求时，和我们的产品契合不是很高，我们可以深入挖掘用户的真实需求，结合产品给出用户解决方案
需求它在哪？
1.谁在使用它？
用户
2.谁提供服务？
业务相关方，产品开发设计者
3.产品价值？
给用户带来服务，给业务相关方带来利益，解决社会问题
4.外部因素？
市场的县长。行业的特性，政策的约束
外部因素：遵循PEST法则、市场环境、用户需求、推动社会
PEST法则:服务于政治、经济、科技、市场
内部因素：公司资源、使用场景、使用频次、用户体验
怎么从这些渠道获取渠道？
通过人
获取对象：人（--用户，--业务相关方，--产品开发设计者）
获取方式：用户访谈、调查问卷、头脑风暴
头脑风暴： 1.找到需要创意的原点 2.通过创意原点进行完全发散 3.通过第一轮发散点，继续进行第二轮发散 4.继续之前的发散过程，进行第三轮发散 4.经过多次发散，创意之门就被打开了
通过事
获取对象：事（--产品价值，--外部因素）
获取方式：业务分析、竞品分析、数据分析、文献分析
交互说明
1.交互说明是用于体现产品经理对产品的想法
2.交互说明是产品与开发沟通的工具
交互说明是针对产品的规则做描述
信息规则：
信息：文字、数字、图片、视频、直播等
1.页面包含哪些信息，以及信息的来源，比如用户头像，用户是来源，头像是信息
2.信息的显示格式或者样式，比如长度、行数、字数、数量等规则
3.信息在不同条件下的显示格式或者样式，条件包括：网络条件、登录条件、有无条件、加载条件、不同用户角色等
功能规则：
功能：指产品能做的操作，比如点击、滚动、输入等
1.页面能做那些操作，比如点击、滑动、输入等
2.操作后的反馈，比如跳转到别的页面、弹窗、toast提示等
3.在不同条件下（条件包括：网络条件、登录条件、有无条件、加载条件、不同用户角色等）的操作，有什么限制或者反馈的不同
调研
调研准备阶段
调研计划（大纲）
-
调研目的
风险控制/降本增效/用户体验/提升转化
风险控制：上线之后可控可回溯，规范流程，避免风险发生的危害和概率
降本增效: 降低系统操作复杂度，减少运营及开发维护人力，提高工作效率
用户体验：页面结构清晰，逻辑合理，下单过程流畅，风格统一化，页面排版，样式搭配，页面布局
提升转化：提升sku, 流量，下单转化率，付款率，GMV（商品交易总额），营收，拉新，复购率
-
调研对象
内部:一线业务/技术人员/高层领导/普通同事
外部：竞品/用户
-
调研时间
调研实施时间（调研者开始执行调研流程时间）/调研对象的工作时间（用户的时间）
-
调研地点
根据实际调研方法有所不同（办公室/会议室/咖啡厅/饭局...）
-
调研内容（围绕调研目的）
需求背景/做什么/怎么做/存在问题
-
调研方法
问卷调查/个人访谈/焦点小组/观察/头脑风暴/标杆对照
-
资料准备
用户资料/系统功能/问题清单/规划方案
调研实施阶段
-
调研步骤
观察 -> 提问 -> 记录 -> 分析 -> 操作 -> 观察
观察：观察调研对象的工作内容和方式
提问：对不明白和想了解的内容大胆提问
记录：对调研的所有内容进行如实记录（使用笔记录或者录音笔方便后期回溯）
分析： 对收集的结果进行整理和分析
操作：对需要了解的内容进行操作验证
-
调研内容
做什么：人员角色、工作内容、重要程度、对接对象、输出成果
怎么做：工作步骤、工作方式、处理频率、处理耗时、参考依据
存在的问题：流程问题、系统问题、相关需求
5W2H（提问方法论）
5W:
what:做什么（事件）
why：为什么做（起因）
where:在什么地方做（地点）
when:什么时间做（时间）
who：谁做（人物）
2H:
how do：怎么做
how much: 花费（时间投入、资金投入、人力投入）
案例
1940年代，杰弗逊纪念堂墙比周围其他建筑有更多的裂纹，这就需要每年花大量资金来修补墙。
负责的人就找来专家分析原因。一开始认为，问题出在清洗墙体用的清洁剂上，所以解决办法就是减少冲洗次数，或者更换清洁剂。
后来专家又追问了5个为什么（5w）：
1）为什么要冲洗墙？因为墙上有很多的鸟粪。 2）为什么有很多鸟粪？因为有很多燕子在大厦周围筑巢。 3）为什么有很多燕子？因为墙上有很多燕子爱吃的蜘蛛。 4）为什么有很多蜘蛛？因为大厦四周有蜘蛛喜欢吃的飞虫。 5）为什么有很多飞虫？因为大厦窗户大，阳光充足，飞虫聚在大厦里，繁殖很快
所以，问题的根源找到了，是因为大厦窗户光照太充足导致的。
最后的解决办法也变得简单了：加个窗帘。就这样，本来需要几百万美元解决的问题，靠一个“窗帘”就解决了。
-
注意事项
1.不要立刻或者匆忙地进入调研状态
自己罗列大纲/提前了解需求方
自己来的目的，寒暄一下
2.不要刻意引导客户，不要回避问题
让需求方讲出问题，不说解决方案/自己也不轻易抛方案
3.注意倾听，不要一直不断地提问
不要轻易打断对话，注意抛问题的节奏
4.注意收集异常情况，挖掘真实问题
自己之前没关注到的地方，特别留心
5.调研时间不要过长
控制在1H左右
6.核心内容需要跟多个人进行调研确认
不听片面之词
7.调研的内容需要得到确认
内部需求可行性分析、再次和客户进行需求确认
录音，内部确认，邮件、书面确认
8.基本职业要求
自己不应该知道的数据等
调研信息记录格式
文章来源地址https://www.toymoban.com/news/detail-407009.html
| 调研信息记录 | |
| (一)权限开通 | |
| 处理范围 | xx后台，统计站和xx平台的权限开通 |
| 处理频率 | 3H/天 |
| 处理数量 | 平均每天25个申请 |
| 工作流程 | 1.xx后台和统计站直接申请，部分角色需邮件申请 |
| 2.部门领导审批后转风控审核 | |
| 3.风控审核后，申请同事获得对应的权限 | |
| 存在的问题 | 1.有些权限后台角色不满足，需要单独开权限，需多出人力 |
| 2.后台权限功能存在历史遗留问题 | |
| 材料收集 | 供管风控字【2018】第1号 权限申请规范 |
| 备注 | 目前已逐步推荐优化/目前新功能在分析阶段 |
文章来源：https://www.toymoban.com/news/detail-407009.html
整理分析阶段
-
整理分析 （调研信息记录）
1.工作内容（做什么）
事项
步骤
频率
耗时
问题
事项名称 子项 频率 平均耗时 线上化 具体步骤 存在问题 页面检查 OTA页面检查 每天 3H/天 是 1.定期对应页面进行检查
2.检查结果登记反馈
3.督促整改，整改率要求百分之百部分风控点依靠人工进行检查，增加工作量同时准确性不能完全控制 OTA页面检查 每天 3H/天 是 APP页面检查 每天 3H/天 是 淘宝页面检查 每天 3H/天 是 自营页面检查 每天 3H/天 是 主题页面检查 每天 3H/天 是 动态自由行页面检查 每天 3H/天 是 官网专题页面检查 每天 3H/天 是 2.文件材料（怎么 做）
培训材料
标准规范
考核标准
往来邮件
日常数据
3.问题汇总（存在的问题）
流程问题
系统问题
相关需求
-
落实需求
-
注意事项
需求拆分，功能分界，敏捷开发，持续运营、持续改进
案例分享
-
调研计 划
举例分享-1
调研目的：了解风控部门全部工作，发现工作中存在的问题，挖掘出可以通过系统手段增效降本的地方，同
时为系统优化改进提供依据
调研对象： 风控管理组
调研时间： 2023.01.08-2023.01.09
调研地点：02会议室
调研内容： 风控的具体工作和工作中的问题
调研方式： 观察+访谈+电话沟通
调研前需要做的工作：
1.确认需要轮岗的部门，联系相关负责人
2.初步安排每天调研的对象和时间，提前约好
3 .现场调研，了解人员分工，调节调研安排
4.实时调研，观察+提问+记录+分析+操作
5.调研内容进行记录和整体
6.第二天查漏补缺+ 继续调研
7.参加一次晨会、周会、专项过堂
8.整理汇总、分析
9.取得认可，落实后续工作
-
资料准备
-
整理分析
用户调研报告
一、调研目的
本次调研的目的是熟悉XXX风控管理（以下简称“风控部门”）的工作流程，了解工作过程中存在的问题，为实施智能化的风控管理提供基础。
二、调研范围及安排
| 时间安排 | 被调查人 | 调研地点 | 调查方式 |
| 2022-01-09 | 张一 | 公司 | 访谈 + 观察 |
| 2022-01-09 | 张二 | 公司 | |
| 2022-01-09 | 张三 | 公司 | |
| 2022-01-09 | 张四 | 公司 |
三、调研报告
本次调研主要通过访谈和观察的方式记录风控部门各业务同时每天的工作流程，形成调研文档，通过收集到的工作流程，整理和汇总出存在的问题。
（一）用户信息
风控部门人员
| 序号 | 姓名 | 工号 |
| 1 | 张一 | 2022001 |
| 2 | 张二 | 2022002 |
| 3 | 张三 | 2022003 |
| 4 | 张四 | 2022004 |
| 5 | 张五 | 2022005 |
(二)工作内容
| 事项名称 | 子项 | 频率 | 平均耗时 | 线上化 | 具体步骤 |
| 页面检查 | OTA页面检查 | 每天 | 3H/天 | 是 | 1.定期对应页面进行检查 2.检查结果登记反馈 3.督促整改，整改率要求百分之百 |
| OTA页面检查 | 每天 | 3H/天 | 是 | ||
| APP页面检查 | 每天 | 3H/天 | 是 | ||
| 淘宝页面检查 | 每天 | 3H/天 | 是 | ||
| 自营页面检查 | 每天 | 3H/天 | 是 | ||
| 主题页面检查 | 每天 | 3H/天 | 是 | ||
| 动态自由行页面检查 | 每天 | 3H/天 | 是 | ||
| 官网专题页面检查 | 每天 | 3H/天 | 是 |
（三）问题汇总
| 事项名称 | 子项 | 存在问题 |
| 页面检查 | OTA页面检查 | 部分风控点依靠人工进行检查，增加工作量同时准确性不能完全控制 |
| APP页面检查 | ||
| 淘宝页面检查 | ||
| 自营页面检查 | ||
| 主题页面检查 | ||
| 动态自由行页面检查 | ||
| 官网专题页面检查 |
到了这里，关于需求分析和调研流程的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
