软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

17 | 需求分析到底要分析什么?怎么分析?

宝玉 2019-04-04
你好,我是宝玉,我今天想与你分享的主题是“需求分析”。
通过前面的学习,我们知道在瀑布模型中,第二个阶段就是需求分析阶段,同时需求分析的结果也决定了后续的系统设计、开发、测试等阶段能否顺利如期进行。即使是用敏捷开发,同样也少不了对需求的分析整理。
可以说需求就是整个产品的源头,所以需求分析的结果往往决定了产品的成败。如果没有正确把握客户需求,可能就会一步错,步步错!
客户想要一个给三个孩子玩的秋千;产品经理以为就是一个板子加两绳子就行;架构师发现除非把树截开,否则秋千没法荡起来的;程序员以为用绳子和板子连一起就完事了;而真正满足客户需求的,也就只要在绳子上挂个轮胎而已!
所以在本篇文章中,我将带你去了解:需求分析到底要分析什么?以及我们怎么样才能做好需求分析,抓住用户的真实需求,做出来客户想要的软件产品,避免失败或浪费。

什么是需求?

我们日常在项目中,经常会听到“需求”这个词,比如说:
项目经理对产品经理说:用户给我们提了一个需求,想要一个给三个孩子玩的秋千,你分析一下;
产品经理对架构师说:我们现在有一个需求,在树上栓两绳子,再吊一块板子,你做一下设计。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • Charles
    思考1(需求分析没做好失败案例):
    客户做了好多年澳洲海鲜批发生意,发现很多C端用户只有在少数大酒店才能吃到真正比较好品质的澳洲海鲜,所以想做个面向熟悉城市的地方性商城,自己搭建仓促、物流、售后等,让用户在家里就可以吃到好的澳洲海鲜产品,最终由于线上运营成本方面考虑,只做了线下的类似生鲜门店和餐厅的结合体,线上部分做了一半就没有进行下去。跟着老师的文章思路,现在看来当时只做到挖掘了客户而非用户的真实需求,接着就直接提出解决方案和技术可行性发现没问题,没有在成本方面和客户探讨是否能支撑到位想做的事情。

    思考2(AB测试):
    了解AB测试,但是目前的项目中更多的是人工方式去分析新功能是否可行,比如做了某个功能,入口隐藏掉,但是网址可以访问,提供给部分用户网址让用户使用新功能,收集反馈,也算吧?😀

    思考3:
    极客时间课程音频功能满足几个用户需求点:1. 上下班路上或开车等场景下不方便看文字,先听一遍音频,到了方便看文字的场景再过一遍音频里有时候消化不了的内容,利用不同的场景结合提高学习效率和效果 2.一边听音频一边看对应的文字,对于那些看书困难户,体验很好没有心理负担

    作者回复: 挖掘客户真实需求这事,属于典型的知易行难,做好确实不容易。

    AB测试如果配合数据分析,会效果更好。用户反馈可能会说谎,数据不会:)

    赞,分析很到位👍

    2019-04-04
    5
  • bearlu
    今天这篇文章信息量很大。我想问问,我是否总结成一个思维导图,方便形成模式?

    作者回复: 👏如果你能总结成思维导图那再好不过了,无论对你自己,还是分享出来对其他人,都很有帮助

    2019-04-04
    4
  • 一路向北
    经常犯的错误是,对客户的需求理解不够底层,导致在项目做了一段时间之后,根本不是客户想要的产品。这也是文章里说的,需要表层分析,深层分析,底层分析。没有这个递进式的分析,即使能够做出符合用户的产品,也是有很大的运气成份。
    极客的产品有音频,主要是分析了用户的需求,很多时候用户不想对着电脑屏幕或者手机学习的情况,听音频也有一种互动的效果,和上课的学习比较贴近。

    作者回复: 👍很好的反思。

    极客时间的音频,确实是使用场景确定的,有时候不是不想,而是不能对着电脑屏幕,比如在路上、在开车。

    2019-04-07
    2
  • 风翱
    突然接到一个通知,需要和第三方的人员开会,当时也不知道需求是什么,参加会议后,听明白对方需要的,和上级领导确认他的目标后,发现两者,各自有各自的目的,是对立的。反馈后,上级领导还是坚持要做。结果对接上线后,完全没有使用过。这种情况也不止一两次了,感觉很是无奈,总是做一些无用功,却又没办法改变现状。

    作者回复: 大家目标不一致很正常的,合作,就是要寻找共同的目标,找到折中的解决方案。

    举个相似的例子:
    我们程序有些功能是通过Http Header的值来控制开启的,某个功能默认是不开启的。

    前几天我们测试的同事希望开发能打开这个功能,不需要设置Http Header。开发的同事就不愿意了,因为改了后可能还会影响其他组使用,另外过些天他们测完,估计还得改回去。

    所以我问了一下测试,原来他们的测试工具不支持设置http header。也就是他如果能通过其他方式测试也是OK的,并不需要修改默认行为,于是建议开发增加支持通过url参数开启功能的方式,对测试来说达到目的,对开发来说改动也不大,也不影响其他组和后续的维护。

    这个例子不一定和你的情况一样,只是作为一个参考,这样下次你也可以尝试思考一下有没有折中的方案。

    2019-04-07
    2
  • hua168
    老师,需要分析不是产品经理的事吗,我们开发不用需求分析的吧?
    不是产品经理把需求文档交给开发,开发有什么不懂再和产品经理沟通吗?
    是不是大家理解一致,开发知道产品经理这个需求的作用、解决什么问题,然后大家理解的是不是一致就好了?
    需求分析好像与开发关系不大呀?

    作者回复: 这是个好问题。理论上来说,需求分析是产品经理的事,但不意味着程序员不需要懂。

    具体我在下一篇《19 | 作为程序员,你应该有产品意识》有详细解释,为什么开发也应该懂一些需求分析的知识。

    2019-04-06
    2
  • kirogiyi
    目前还没遇到因需求分析没做好而失败的项目,只是遇到过因需求分析没有做好而完成得非常艰难的项目,不断变更,不断调整,不断加班...,有点绝望中死不足惜的那种味道。

    需求分析在项目中的重要性不言而喻,不过大部分软件项目对它的重视基本上都来源于“没有需求就不能开工”,更像是一种仪式,并且还要求仪式做到尽善尽美,否则延期的锅就是需求分析的人来背。真正实施项目的人不会在乎需求是否合理,是否某些方面值得改进,即使在乎也只是在心里嘀咕两句就算了,谁也不愿意惹事。项目做完是我的责任,项目做错是你的责任。

    我觉得这里比较重要的一点是:需求跟踪,有了跟踪就有了不断改进和完善的空间,有了将项目不断拉回预定轨道的可能,只要在需求跟踪过程中控制好变更的时机和频率,无论对产品需求还是对具体的项目实施人员都是非常有利的,项目的成功率也会大大增加。


    作者回复: 没需求当然不能开工,需求是项目的源头。

    没想清楚就开工,然后边做边改也是软件项目一大特色。

    不过没有想清楚的需求,第一版最好快猛糙快速原型式开发,另外聚焦核心需求,否则后期变更太痛苦。

    2019-04-04
    2
  • 冰封血影
    经常出现用户自己都不知道自己想要什么,而是希望先有个东西,然后他们再在这基础上来提出自己想要的。做成音频个人观点:
    1、本身这个群体每天看着电脑等都很疲劳了。
    2、看文稿时,如果有微信、QQ等消息时,人会不自觉的去看看,一看可能一会就搞其他去了,注意力就不在了。
    3、听的同时给予了更多的思考空间,然后再结合文稿就更能巩固其中的知识点。

    作者回复: 是的,很多时候用户并不知道自己想要什么,你得先给他看到一个东西,然后他再会想到更多的需求。

    但是如果被用户牵着鼻子走成本就太高了,所以要分析需求,要做原型设计低成本的确认需求。

    分析的挺好,音频就是契合用户的各种特殊使用场景的需求。

    2019-04-04
    2
  • 小老鼠
    1、汽车不是比跑得更快的马车成本更高,与游乐场与秋千区别是什么?
    2、上课时老师说需求是作什么,设计是怎么做?您说的是用户需求是作什么,产品需求是怎么做。好像有矛盾。
    3、如何分析隐性需求?
    4、需求分析做不做这个产品与可行性分析好像有共同处?
    5、立项什么时候做,做什么?
    6、产品工程师与需求分析师工作内容有什么区别?

    作者回复: 1. 成本是相对的,需要在成本和满足需求之间寻找平衡。这就好比手机从几百到上万都有,能满足不同层次需求。
    游乐场和秋千的差别主要也在于成本的差异。

    2. 产品需求也叫产品设计,应该不矛盾

    3. 分析隐性需求可参考文中“挖掘真实需求”

    4. 可行性研究的基础也是要先了解清楚用户的需求,在根据需求去寻找可能解决方案以及可行性

    5. 立项一般是在对需求了解,并做完可行性研究觉得可行之后再立项

    6. 似乎没有产品工程师,只有产品设计师。需求分析师一般是去了解业务,了解用户的需求是什么,把专业的需求翻译的让产品设计能理解;产品设计师基于理解的需求设计出来相应的解决方案。

    举例来说,建筑行业软件的需求分析师需要懂建筑行业的专业知识,能明白建筑行业的专业术语,同时也要懂一些产品设计和软件开发,他们要把建筑行业的专业需求提取成软件中可行的需求,描述成产品设计师、软件工程师能理解的语言。

    2019-09-12
    1
  • fei
    宝玉老师,需求分析师在进行提出解决方案阶段的时候,需要拉上产品经理或者程序员和测试工程师一起制定么?解决方案和产品经理xiede产品文档最大的不同是什么呢?

    作者回复: 提出解决方案阶段,产品经理、程序员和测试一起参与是非常必要的,这样可以协助提出技术上的可行性分析、估算工作量,避免提出一些不切实际或者成本过高的需求。

    解决方案写的文档是从客户的需求角度,提出要解决什么问题,比如客户说想要一个交通工具帮助通行。
    产品经理写的文档是从设计的角度,提出如何解决问题,比如说设计一个马车。
    程序员则是对方案进行具体实施,比如建造马车。

    2019-09-08
    1
  • 一铖
    宝玉老师,这个课程有ppt或其他整理成册的文字材料吗?

    作者回复: 抱歉,暂时没有其他形式的文字材料

    2019-05-16
    1
  • 宝宝太喜欢极客时间了
    老师,需求分析的过程对应于UML,收集需求是否对应于业务用例模型,分析需求对应于概念用例模型及系统用例模型,设计需求就是进行原型设计呢?

    作者回复: 不建议你把需求分析和UML放一起理解,UML是一种用来做设计时的手段,是偏向对已经设计好的产品需求进行建模分析的。

    收集需求通常是指的用户原始需求,产品经理需要进一步分析处理才能变成最终的产品需求。

    用例模型一般是针对已经设计好的产品需求,对用例进行建模。

    原型设计只是对产品设计的一种有效手段,但也不是唯一的手段,比如有的程序员,自己在脑子里就能构建出产品的模型,然后代码实现,都不需要借助原型。

    2019-04-28
    1
  • Jay.Soul
    做软件外包,前期需求分析的时候虽然每个功能点都能分析到,但是后期给客户测试的时候,总是会提很多小问题小功能的修改,就导致项目成本增加。不知道老师有没有好的解决方案。

    作者回复: 建议参考我后面需求变更那一章的策略,比如可以提升客户变更的成本,或者降低响应变更的成本。

    另外可以把客户提前确认,在半成品的时候确认时提出的小修改相对容易加进去,正式发布了问题也会少一点。

    2019-04-28
    1
  • 果然如此
    我认为需求分析的其中两个环节需求评估和方案验证好像是有关联的,因为只有看能不能提出合理的方案才能知道需求是否合理,老师对这这两个环节区别怎么理解的?

    作者回复: 你说的对,这两个环节是有关联的,所以我在文章的图片是用的环形表示,因为整个过程是迭代进行的,评估后提出方案验证,验证后修改再评估。

    2019-04-12
    1
  • 果然如此
    音频的好处除了地铁、开车,还有是能快速过一遍文章,然后再仔细读每个段落。
    这篇让我醍醐灌顶,看了好几遍!
    另外,我也把看过的章节总结到云笔记里。

    作者回复: 👍是的,音频主要还是结合用户使用场景的。
    总结是很好的学习习惯

    2019-04-11
    1
  • hua168
    老师问一个题外问题:
    1. 在国内英文差怎办?很多国外前进的文章看起来比较吃力,老记不住英文单词,出现过几十次就能记住了。
    网上有很多说通过读文章学英文四级,不知道靠谱不?英文四级够用了吧?
    2. 去国外需要考雅思/托福吗?

    作者回复: 1. 多练练就好了,刚开始肯定吃力,多看看就越来越熟了。
    2. 如果不是上学不需要。但是英语不好确实限制很多,比如不便于工作上的交流。

    2019-04-11
    1
  • 天天快乐
    音频更方便程序员们在上下班途中,比如地铁中收听。闭上眼睛,收听极客时间的音频课程,一方面打发无聊的时间,休息一下疲劳的双眼;另一方面,学习新的知识,充实自己。

    作者回复: 👍是的,其实主要和文章中的知识点“使用场景”相关的。

    2019-04-04
    1
  • rubyniu
    支持音频对于看书就困的人来说,是很有好处的。😂

    作者回复: 你可以尝试从用户场景角度再考虑一下:)

    2019-04-04
    1
  • Change
    1. 收集需求
        * 头脑风暴
        * 用户调研
        * 竞品分析
        * 快速原型
    2. 分析需求
        * 表层需求:用户对解决问题的期望
        * 深层需求:用户的深层动机,诉求产生的原因
        * 底层需求:人性本能的需求
    3. 需求评估
        * 可行性:技术能否实现
        * 成本:人工成本、时间成本
        * 商业风险和收益:有没有商业的风险,收益是否合理
        * 紧急性与重要性:是不是用户迫切的需求
        * 评估其优先级:紧急重要四象限
    4. 需求设计
    5. 验证需求
    2019-10-17
  • dancer
    mark需求收集方法以及KANO~
    2019-04-04
收起评论
19
返回
顶部