许式伟的架构课
许式伟
七牛云CEO
立即订阅
19977 人已学习
课程目录
已更新 71 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (8讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册

17 | 架构:需求分析 (上)

许式伟 2019-06-11
你好,我是七牛云许式伟。
前面我们多次提到过,架构的第一步是需求分析。那么,为什么要做需求分析?如何做好需求分析?
今天让我们一起聊一聊需求分析这个话题。

关于需求分析的那些事

为何要做需求分析?
首先,当然是因为我们做软件本身就是为了满足用户需求。那么,用户需求到底为何,我们需要清楚定义。
其次,需求边界定义的需要。用户需求理清楚了,不代表产品理清楚了。用户需求的满足一定会有行业分工,我们做什么,合作伙伴做什么,需要厘清大家的边界。
最后,架构设计的需要。架构需要切分子系统,需要我们梳理并对用户需求进行归纳与抽象。架构还需要防止过度设计,把简单的事情复杂化。
但什么是过度设计?不会发生的事情你考虑了并且为它做足了准备,就是过度设计。所以判断是不是过度设计是很困难的,需要对需求未来演化有很强的判断力。
从这几个维度来看,需求分析过程必然会涉及以下这些内容。
我们要面向的核心用户人群是谁?
用户原始需求是什么?最核心问题是哪几个?
已经有哪些玩家在里面?上下游有哪些类型的公司,在我们之前,用户是怎么解决他们的问题的?我们的替换方案又是怎样的?
进而,我们的产品创造的价值点是什么?用户最关注的核心指标是什么?
用户需求潜在的变化在哪些地方?区分出需求的变化点和稳定点。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(27)

  • Geek_9102
    架构的设计是宏观的,但是要落到实处是微观的,在考虑架构的时候,我觉得还要装着目前团队的资源、战略、技术结构等,要看是否需要变化,从宏观来设计,从微观来验证,反复循环,才能落到实处。我和同事经常说的一句话,没有落到实处的架构设计,就相当于没有设计。

    作者回复: 👍

    2019-06-12
    25
  • Cordova
    产品的一体两面很赞同!另外我也觉得产品和架构方面负责人都有责任让自己的团队去知道产品当前的定位、上下游关系、产品边界、功能边界、帮助团队每一位成员理清楚稳定需求、扩展需求、和未来可扩展需求的方向,理清楚满足这些需求已使用技术方案、和可使用技术条件,这样,我们每个成员都能思考这个产品是什么,做什么,会成什么样,以及我该有怎样的技术储备,而不是上班简单完成任务,下班随意学习这样一个状态。谢谢许老师的分享!

    作者回复: 👍

    2019-06-14
    11
  • 苟范儿
    ”产品是桥,它一端连接了用户需求,一端连接了先进的技术“,老师这句话对技术、产品、需求关系的描述太精辟了~
    2019-06-12
    5
  • ljf10000
    产品经理和架构师是一体两面,这句总结得牛
    2019-06-11
    5
  • 我在你的视线里
    架构更多的是宏观的东西。看未来远不如看过去清楚。心里装着用户。最好的架构应该是符合人的本能。
    2019-06-11
    5
  • 潘华引Simon Pan
    用思考的方式去记忆
    2019-06-12
    4
  • Aaron Cheung
    打卡17 目前感觉需求分析可能占六七成
    2019-06-12
    2
  • lckfa李钊
    看了两遍,不得不感慨需求分析确实是一件很难的事情,在实际开发中有一个问题就是,有时我们根本不知道现有的技术栈能不能实现某个需求,调研是必不可少的,也可能做着做着,就不得不砍需求了;需求的临时变更是让人无语,架构的设计也可能因为某些个需求的加入或者删除而不得不变化.怎么把变化也考虑到架构中是一个很困难的事情,也可能有公司制度的问题,具体问题当然是要具体分析的,多思考总结,架构师都是野生的,需野蛮生长啊.
    2019-06-12
    2
  • peter
    老许,我最近在写c,对.h文件中函数的申明,认为自己做的一直不满意。但又找不到好的需求分析模板或方法。您今天说的需求分析比较庞大,我的问题相对小一点。我的理解,编写.h头文件,本质是在将需求分析翻译成代码的过程。希望关于这个点,能听听您的建议。

    作者回复: 没错,.h 写的是模块接口,要自然体现需求。觉得对 .h 的函数不满意,其实是对模块架构定义的接口不满意

    2019-06-11
    2
  • 郝洪范
    终于进入正题了,豁然开朗,只有趟过坑才知道,这里面说的多务实
    2019-09-20
    1
  • 阿西吧
    红绿色盲看到的都是绿点~~
    2019-07-08
    1
  • Dimple
    需求分析,在大公司工作的时候,这是第一步,而且是需要严格执行的,所以看到这部分特别有感触。好的需求分析,能带来一个产品往好的方向上走,如果来一个需求就做,那这个产品是做不好的
    2019-06-19
    1
  • 晓凉
    需求分析确实太难了,平时说需求分析大多是分析客户需求,但要做出好产品,不只要分析客户的需求。产品的研发和运营的过程中,有大量的利益相关者,它们的需求可能都需要分析。还有大量技术或非技术的制约条件,不是一般人容易看清楚的。能在行业或社会尺度上搞清楚需求的,都已经成为大佬,或将会成为大佬。
    2019-06-15
    1
  • 82
    老师好,以下是我的理解。
    感觉需求分析的过程就是架构产品的过程。抽象最核心最根本想解决的问题点,围绕它构建产品模型。

    技术设计感觉像是根据产品模型构建领域模型,将大的问题分解成小的领域模型处理的过程。

    另外,以前在设计时总是脑补可能的未来场景,想着如何兼容拓展,进而带出一堆暂时用不上的设计。这种过度设计也许就是对产品需求理解的不深吧。

    我想也许是宏观上的架构一定要考虑长远发展,相对具体的业务要结合具体需求设计,切记避免过度设计。

    作者回复: 想着如何扩展肯定是好事,比想不到强太多,过度设计,这是架构师成长的必经之路。要想构建自己对需求发展的预判能力,就要分清楚需求的稳定点和变化点,这个是需要花时间在用户的需求理解上的,不可能一蹴而就。

    2019-06-14
    1
  • 雨巷
    许老师: 你把产品,需求,技术三者的关系 形容成 产品是一座桥连接了技术和需求,这个比喻不太好,会给人感觉产品就像一个媒婆, 连接了男方和女方。 实际上产品是最终的一个输出或者目标,技术是一个手段, 按照需求的定义 用来实现这个目标的。 桥这个这个比喻无法直观体现手段与目的这个关系

    作者回复: 好吧😂

    2019-06-13
    1
  • 在路上
    关于需求分析那些事儿中的[其次]部门
    [用户需求的满足一定会有行业分工,我们做什么,合作伙伴做什么,需要厘清大家的边界。]
    厘清应该为理清吧。

    作者回复: 好像有厘清这个词

    2019-06-11
    1
  • 一门深入 长时薰修
    2019-06-11
    1
  • 丁丁历险记
    很多都知道,但就是不成体系。
    2019-10-27
  • panqing
    请问老师,"我们要避免把行业方案视作产品的一部分。"的意思是说 产品本身作为一层,然后再加上一层,这一层把产品整合到企业的行业方案,是这个意思吗?

    作者回复: 是的

    2019-09-30
  • 小风
    对这章内容深有同感,我们团队通过几年的实践和反复总结也逐渐认识到需求分析的重要性。对于常规的业务应用系统,需求/产品人员往往按照用户提出的需求做出原型,设计/开发人员基于界面原型完成接口设计和开发。实际上,需求人员并没有真正去分析用户需求背后隐含的根源需求,而设计人员也没有意识到他所谓的接口只是和界面耦合的实现,完全体现不出稳定通用的业务内核。导致的直接结果就是界面层次的频繁变动连带后台服务的不断修改。究其一点原因,现在很多开发人员入门的时候(很多需求人员也是从开发转过去的),面对的就是mvc,orm等各个层次成熟的框架和组件,设计开发系统就是熟练运用这些框架和组件实现功能,逐渐逐渐也就潜意识地认为设计就是组合使用这些框架和组件,去从框架的角度做需求和设计来迎合框架的使用,从而也就忽视了或没有意识到真正的需求分析和设计应该是什么。

    作者回复: 👍

    2019-09-28
收起评论
27
返回
顶部