免费网站模板 html,水产养殖网站模板源码,苏州保洁公司钟点工,集约化网站建设的函需求分析#xff0c;即分析需求#xff0c;分析软件用户需要解决的问题。
需求分析的下一环节是软件的整体架构设计#xff0c;需求是输入#xff0c;架构是输出#xff0c;需求决定了架构。
决定架构的是软件的所有需求吗#xff1f;肯定不是#xff0c;真正决定架构…需求分析即分析需求分析软件用户需要解决的问题。
需求分析的下一环节是软件的整体架构设计需求是输入架构是输出需求决定了架构。
决定架构的是软件的所有需求吗肯定不是真正决定架构设计的是关键需求或用户要解决的关键问题其余非关键性的需求或非关键性的问题可以用来验证软件架构设计的合理性。
需求分析是在谈什么谈识别关键需求。 如何识别关键需求呢
关键需求具有决定性的意义和价值根据笔者所参与研发过软件总结为关键需求往往是基础需求、核心需求和高风险需求。 基础需求基础需求体现在软件上是基础功能往往具有 “稳定” 和 “原子化” 特征基础功能很稳定很少受到需求变动的影响而且基础功能往往不会再拆分基于基础功能软件往往会衍生出更多的扩展功能在电商系统中像 “商品”、“订单”、“支付” 等属于软件的基础功能以此为基础进行扩展的 “营销”、“评论”、“客服” 则属于软件的扩展功能。 核心需求核心需求很容易理解往往是软件必须要提供的能力失去了核心需求软件则没有意义比如移动手机系统的电话功能、智能汽车的驾驶功能、微信软件的聊天功能等等识别关键需求往往从识别用户必须要解决的关键问题入手来确认核心需求。 高风险需求高风险需求往往会影响软件研发的成败必须在软件架构设计时充分考虑其高风险性提出解决方案降低或消除其风险高风险需求更多体现在非功能需求方面比如在电商系统中用户搜索任何一类商品必须在 0.5 秒内看到结果在水利监测系统中任意1~3台服务器宕机都不会影响水情警报的告警。
所以架构师在接触到纷繁复杂的一堆需求时切忌眉毛胡子一把抓地逐一分析而应该将精力放在识别关键需求上面。
关键需求 基础需求 || 核心需求 || 高风险需求。 普适需求分析模型
这里以 IM 系统为例总结一个普适性的需求分析模型见下图。 首先对所有需求点进行筛选区分出 “功能需求” 和 “非功能需求”然后对 “功能需求” 进行分析识别出 “基础功能需求” 和 “扩展功能需求”这样则将一团需求点从同一视角出发拆分成了同类要素整体化繁为简。 基础功能需求基础功能需求是整个系统的核心往往体现关键需求中的 “基础需求” 和 “核心需求” IM 系统的基础功能需求包括三部分 “用户”、“联系人” 和 “消息”“用户” 描述的是当前登录者 “联系人” 描述的是当前登录用户的好友“消息” 是 IM 系统最最核心的功能包括 “私信消息”、“系统消息”、“云消息” 和 “离线消息”。 扩展功能需求是对基础功能需求的扩展扩展功能需求的典型特征就是 “变动” 和 “扩展”需求最不稳定在实现扩展功能需求时往往基于基础功能进行。IM 系统的基础功能需求决定了 整个 IM 的业务框架IM 系统的扩展功能需求如 “群消息”、“多媒体消息”、“子母号”、 “红包” 等都是基于 IM的 “基础功能需求” 实现的据说微信的 “摇一摇” 功能是由三个实习生用了不到一周时间就上线的功能。 非功能需求非功能需求更多体现的是关键需求中的 “高风险需求”软件的非功能需求很多我们对其进行归类和抽象总结为高扩展需求、高吞吐需求和稳定性需求。 高扩展—高扩展包括功能的高扩展和容量的高扩展 功能的高扩展是指基于现有功能和代码通过简单改造就可以轻松实现新的功能这要求系统的基础功能的实现做到合适粒度的 “高内聚” 和 “低耦合”在《架构技能三扩展性》一文中有详细分析 容量的高扩展是指可以轻松地对集群进行线性横向扩容以处理更高流量规模的访问请求。 高吞吐—是互联网系统一直孜孜不倦的所追求的目标如何提高系统的吞吐量呢需要从两个方面着手一是提高系统的并发量一是提高系统的处理性能也就是 “高吞吐” 依赖 “高并发” 和 “高性能”这里需要注意严格地说在系统资源未耗尽之前提高并发量可以在一定程度上提高吞吐量高吞吐、高并发、高性能是系统在同一维度三个不同视角的描述一体三面相互关联。 稳定性—稳定性包括两个方面分别是可用性和可靠性 可用性是指系统持续工作的能力比如系统可以 7 * 24 连续工作 可靠性是指系统对于正确的输入一定会有正确的输出。可用性通常依赖于系统的整体架构设计而可靠性通常更多的依赖于合理地程序编写。 直播答题案例
需求分析时需要识别关键需求对关键需求进行重点剖析从而由关键需求导出系统的架构设计。下面以百万直播答题系统为例演示整个过程。
百万直播答题系统需求描述如下
直播答题是在视频直播的基础上增加了答题的玩法每场12道题每次下发一道题答题时间10s作答时间结束几秒后下发答案和统计数据全部答对者平分奖金答错或者超时未作答不可继续答题。
对上述文字描述进行分析画出直播答题系统的客户端与服务端之间的交互流程时序图如下 综合文字描述和时序图可以确定系统模块边界业务范围框图如下 明确了直播答题系统的业务流程、模块边界、功能需求和非功能需求后可以进一步分析出其关键需求。 百万用户同时在线答题集中在10秒内提交答案对系统的并发访问和造成的瞬时负载是非常高的这是首当其冲最不能忽视的一点所以 “高并发访问” 作为非功能需求体现了关键需求的高风险需求类型 直播答题是在视频直播的基础上增加的答题的玩法视频直播是整个系统的基座体现了关键需求的基础需求类型 直播答题系统解决的是多个用户在线集中答题的问题用户答题是系统必不可少的功能体现了关键需求的核心需求类型另外“平分奖金” 的诱惑肯定会吸引 “黑客用户” 的蜂拥而至因此 “防用户作弊” 也是系统的关键需求。
根据上述分析百万直播答题系统的关键需求包括 高并发访问 视频直播 用户答题 防用户作弊
在充分考虑上述四项关键需求后可以推导出系统的架构设计见下图。 如何根据关键需求推导出系统的架构设计系统的架构是如何实现上述关键需求的以及怎样用非关键需求验证架构设计的合理性在后续的文章中逐步进行分析。 最后总结文中关键 真正决定架构设计的是关键需求非关键性需求用来验证软件架构设计的合理性 关键需求往往是基础需求、核心需求和高风险需求 普适性的需求分析模型中将需求划分为功能需求和非功能需求功能需求可划分为基础功能需求和扩展功能需求 百万直播答题案例中关键需求包括高并发访问、视频直播、用户答题、防用户作弊。
