专门做英雄联盟h漫的外国网站/搜索引擎在线观看

需求分析，即分析需求，分析软件用户需要解决的问题。

需求分析的下一环节是软件的整体架构设计，需求是输入，架构是输出，需求决定了架构。

决定架构的是软件的所有需求吗？肯定不是，真正决定架构设计的是关键需求或用户要解决的关键问题，其余非关键性的需求或非关键性的问题，可以用来验证软件架构设计的合理性。

需求分析，是在谈什么？谈识别关键需求。

如何识别关键需求呢？

关键需求具有决定性的意义和价值，根据笔者所参与研发过软件，总结为：关键需求往往是基础需求、核心需求和高风险需求。

• 基础需求：基础需求体现在软件上是基础功能，往往具有 “稳定” 和 “原子化” 特征；基础功能很稳定，很少受到需求变动的影响；而且，基础功能往往不会再拆分；基于基础功能，软件往往会衍生出更多的扩展功能；在电商系统中，像 “商品”、“订单”、“支付” 等属于软件的基础功能，以此为基础进行扩展的 “营销”、“评论”、“客服” 则属于软件的扩展功能。

• 核心需求：核心需求很容易理解，往往是软件必须要提供的能力，失去了核心需求，软件则没有意义；比如，移动手机系统的电话功能、智能汽车的驾驶功能、微信软件的聊天功能等等；识别关键需求，往往从识别用户必须要解决的关键问题入手来确认核心需求。

• 高风险需求：高风险需求往往会影响软件研发的成败，必须在软件架构设计时充分考虑其高风险性，提出解决方案，降低或消除其风险；高风险需求更多体现在非功能需求方面，比如：在电商系统中用户搜索任何一类商品必须在 0.5 秒内看到结果，在水利监测系统中任意1~3台服务器宕机都不会影响水情警报的告警。

所以，架构师在接触到纷繁复杂的一堆需求时，切忌眉毛胡子一把抓地逐一分析，而应该将精力放在识别关键需求上面。

关键需求 = 基础需求 || 核心需求 || 高风险需求。

普适需求分析模型

这里，以 IM 系统为例，总结一个普适性的需求分析模型，见下图。

首先对所有需求点进行筛选，区分出 “功能需求” 和 “非功能需求”；然后对 “功能需求” 进行分析，识别出 “基础功能需求” 和 “扩展功能需求”，这样则将一团需求点从同一视角出发，拆分成了同类要素，整体化繁为简。

• 基础功能需求：基础功能需求是整个系统的核心，往往体现关键需求中的 “基础需求” 和 “核心需求”； IM 系统的基础功能需求包括三部分： “用户”、“联系人” 和 “消息”，“用户” 描述的是当前登录者， “联系人” 描述的是当前登录用户的好友，“消息” 是 IM 系统最最核心的功能，包括 “私信消息”、“系统消息”、“云消息” 和 “离线消息”。

• 扩展功能需求：是对基础功能需求的扩展，扩展功能需求的典型特征就是 “变动” 和 “扩展”，需求最不稳定；在实现扩展功能需求时往往基于基础功能进行。IM 系统的基础功能需求决定了 整个 IM 的业务框架，IM 系统的扩展功能需求，如： “群消息”、“多媒体消息”、“子母号”、 “红包” 等都是基于 IM的 “基础功能需求” 实现的；据说，微信的 “摇一摇” 功能，是由三个实习生用了不到一周时间就上线的功能。

• 非功能需求：非功能需求更多体现的是关键需求中的 “高风险需求”；软件的非功能需求很多，我们对其进行归类和抽象，总结为高扩展需求、高吞吐需求和稳定性需求。

  • 高扩展—高扩展包括功能的高扩展和容量的高扩展； 功能的高扩展是指基于现有功能和代码，通过简单改造就可以轻松实现新的功能，这要求系统的基础功能的实现做到合适粒度的 “高内聚” 和 “低耦合”（在《架构技能（三）：扩展性》一文中有详细分析）； 容量的高扩展是指可以轻松地对集群进行线性横向扩容，以处理更高流量规模的访问请求。

  • 高吞吐—是互联网系统一直孜孜不倦的所追求的目标，如何提高系统的吞吐量呢？需要从两个方面着手，一是提高系统的并发量，一是提高系统的处理性能；也就是 “高吞吐” 依赖 “高并发” 和 “高性能”，这里需要注意，严格地说，在系统资源未耗尽之前提高并发量可以在一定程度上提高吞吐量；高吞吐、高并发、高性能是系统在同一维度三个不同视角的描述，一体三面，相互关联。

  • 稳定性—稳定性包括两个方面，分别是可用性和可靠性； 可用性是指系统持续工作的能力，比如系统可以 7 * 24 连续工作； 可靠性是指系统对于正确的输入一定会有正确的输出。可用性通常依赖于系统的整体架构设计，而可靠性通常更多的依赖于合理地程序编写。

直播答题案例

需求分析时，需要识别关键需求，对关键需求进行重点剖析，从而由关键需求导出系统的架构设计。下面以百万直播答题系统为例，演示整个过程。

百万直播答题系统需求描述如下：

直播答题是在视频直播的基础上增加了答题的玩法，每场12道题，每次下发一道题，答题时间10s，作答时间结束几秒后下发答案和统计数据，全部答对者平分奖金，答错或者超时未作答不可继续答题。

对上述文字描述进行分析，画出直播答题系统的客户端与服务端之间的交互流程，时序图如下：

综合文字描述和时序图，可以确定系统模块边界，业务范围框图如下：

明确了直播答题系统的业务流程、模块边界、功能需求和非功能需求后，可以进一步分析出其关键需求。

• 百万用户同时在线答题，集中在10秒内提交答案，对系统的并发访问和造成的瞬时负载是非常高的，这是首当其冲最不能忽视的一点，所以 “高并发访问” 作为非功能需求，体现了关键需求的高风险需求类型；

• 直播答题是在视频直播的基础上增加的答题的玩法，视频直播是整个系统的基座，体现了关键需求的基础需求类型；

• 直播答题系统解决的是多个用户在线集中答题的问题，用户答题是系统必不可少的功能，体现了关键需求的核心需求类型；另外，“平分奖金” 的诱惑肯定会吸引 “黑客用户” 的蜂拥而至，因此 “防用户作弊” 也是系统的关键需求。

根据上述分析，百万直播答题系统的关键需求包括：

• 高并发访问

• 视频直播

• 用户答题

• 防用户作弊

在充分考虑上述四项关键需求后，可以推导出系统的架构设计，见下图。

如何根据关键需求，推导出系统的架构设计？系统的架构是如何实现上述关键需求的？以及怎样用非关键需求验证架构设计的合理性？在后续的文章中逐步进行分析。

最后，总结文中关键：

1. 真正决定架构设计的是关键需求，非关键性需求用来验证软件架构设计的合理性；

2. 关键需求往往是基础需求、核心需求和高风险需求；

3. 普适性的需求分析模型中，将需求划分为功能需求和非功能需求，功能需求可划分为基础功能需求和扩展功能需求；

4. 百万直播答题案例中，关键需求包括：高并发访问、视频直播、用户答题、防用户作弊。