前言:
在愿景分析+商业分析之后,就是用户需求开发,然后就是需求分析。
在业务需求分析领域,主要完成三个输出:
需求列表:功能需求、质量需求、约束条件 =》 第5章
用例图 =》 第6章
领域建模 =》 第7章
上述工作,通常是由需求分析工程师或系统工程师SE完成,也可以由架构师完成。
![](https://img-blog.csdnimg.cn/img_convert/649b1c66f70d4e35deb78be1b9f6045f.png)
第5章 需求分析
![](https://img-blog.csdnimg.cn/img_convert/8679a888e5abfaa9e5bb00030c8ecd9d.png)
架构师要想知道需求是如何影响架构,首先要懂得如何进行需求分析,或者说,需要懂得需求分析的主要行为动作与主要的输出结果,这些输出结果,是架构设计的输入。
需求开发的上半场:业务愿景分析 + 商业缝隙
需求开发的下半场:需求分析=》用户需求:功能列表 + 用例图
领域建模=》用户需求:领域模型(是对用例图的进一步建模:流程图、活动图、时序图、状态图)
系统分析=》产品需求:软件需求、系统需求规格
5.1 需求开发(上)—— 愿景分析 =》愿景与范围文档/市场需求文档/产品需求文档/项目立项建议书/可行性研究报告/项目立项书
5.1.1 从概念化阶段说起
![](https://img-blog.csdnimg.cn/img_convert/96c81db3496d3f48a3f97f690216edf3.png)
![](https://img-blog.csdnimg.cn/img_convert/b7dee3b2c286986c0acf26ee9c923334.png)
5.1.2 愿景:环境?背景?好处?目的?为什么要做?
![](https://img-blog.csdnimg.cn/img_convert/0a0488c991c7e12684cc1174854c9757.png)
![](https://img-blog.csdnimg.cn/img_convert/251dcfe7b6fbedf1b1329e0da62d6df8.png)
![](https://img-blog.csdnimg.cn/img_convert/bc29848d3f6ab16f2c2b13b1f95933cd.png)
备注:
项目型公司与产品型公司的区别
项目型公司:使用市面上成熟的产品、原配件做方案和系统集成,赚取的方案集成的利润
产品型公司:研发自己的产品,用自己的产品提供解决方案,赚取的是产品研发的利润和方案利润
混合型:研发自己的产品、同时为用户提供解决方案(可以是自己的产品,也可以是第三发产品)
5.1.3 Context上下文图
![](https://img-blog.csdnimg.cn/img_convert/ab6774f5ca8a5687533cf85f3a7204f6.png)
上下文图把目标系统看成是一个黑盒子,阐述目标系统与外部系统的交互以及目标系统呈现的外部功能行为。
![](https://img-blog.csdnimg.cn/img_convert/da5be34ba6b2253db5fe63c780c296ca.png)
5.1.3.1 与物理架构视图的比较
![](https://img-blog.csdnimg.cn/img_convert/104ecfce055cf058147fb2f2e6a7005d.png)
![](https://img-blog.csdnimg.cn/img_convert/7acea4fdd7a8d46eff6b1193c33f2ea9.png)
5.1.3.2 与逻辑架构图的比较
![](https://img-blog.csdnimg.cn/img_convert/1f280e41bd33c7dbd2b33a2326937069.png)
![](https://img-blog.csdnimg.cn/img_convert/88edcbb6c2dd23a713f4233471d02d08.png)
5.1.3.3 Context上下文图与用例图的比较
![](https://img-blog.csdnimg.cn/img_convert/c46f9765bfb75a75fc1f16739a5d47f3.png)
![](https://img-blog.csdnimg.cn/img_convert/6397aff59a0b1bc4eb7e9e0d6a3d9c6d.png)
![](https://img-blog.csdnimg.cn/img_convert/fd5934e469166a3173c9eca9259ac5e3.png)
Context上下文图:关注的外部环境。
用例图:关注为外部不同用户提供的不同功能。
5.1.4 愿景分析实践要领(如何描述业务愿景)
![](https://img-blog.csdnimg.cn/img_convert/6fcb5678c608706bd76aa03c02a85647.png)
业务目标:简短的文字描述目标系统的业务目标、好处、原因。
feature:功能特征
范围:明确目标系统的边界,哪些是目标系统的职责,哪些不是目标系统的职责。
上下文图:明确目标系统边界外的环境,即上下文。
![](https://img-blog.csdnimg.cn/img_convert/cd3f24fd0cae42c7ac504d820b56c50c.png)
5.1.5 愿景分析的输出
![](https://img-blog.csdnimg.cn/img_convert/251dcfe7b6fbedf1b1329e0da62d6df8.png)
5.2 需求开发(下)—— 需求分析 =》 需求列表
![](https://img-blog.csdnimg.cn/img_convert/be7bf7ec9a741683d131e39da4f67b91.png)
5.2.1 需求捕获vs.需求分析vs.系统分析
![](https://img-blog.csdnimg.cn/img_convert/309b012eef3056d57700598a84eda147.png)
需求捕获=》各方需求捕获=》需求列表
需求分析=》用户需求分析 =》获得用户需求规格 =》用例(用例图和用例规格)
系统分析=》系统需求分析 =》软件系统需求规格 =》需求建模
![](https://img-blog.csdnimg.cn/img_convert/8fa0e9e273981a7d62429d44d6bf74c8.png)
上述不是两个阶段,而是两个活动,是同一个阶段持续迭代的两个活动。
![](https://img-blog.csdnimg.cn/img_convert/586a189025cdc60a3c4f5030874a3970.png)
![](https://img-blog.csdnimg.cn/img_convert/0832c6369cc4f8a67a5ef21dcc5163aa.png)
需求分析和系统分析,相同点都是分析,但分析的对象不同,导致结果不同。
所谓分析:就是先解构,然后再综合的过程,称为分析。
需求分析,分析的是用户的需求,属于做“什么“的问题。对用户的需求进行解构,然后结构化,结果输出是用例(用例图+用例规格)
系统分析,分析的待实现的软件系统,属于”怎么做“的问题。对软件系统进行结构,然后结构化。结果输出是(领域建模)
5.2.2 需求捕获及成果 =》用户原始需求列表以及说明
![](https://img-blog.csdnimg.cn/img_convert/a1dc571c7756d8025d280f02efa7729d.png)
![](https://img-blog.csdnimg.cn/img_convert/96c81db3496d3f48a3f97f690216edf3.png)
5.2.3 需求分析及成果 =》 需求建模 =》SRS和用例图+用例规约
![](https://img-blog.csdnimg.cn/img_convert/131c3aacb8675f82697d445f492fd6bc.png)
用例图和需求规格说明书SRS,都是对用户的需求进行解构和综合的结果。
![](https://img-blog.csdnimg.cn/img_convert/7e8716108afa00937497058c334a0cb7.png)
5.2.4 系统分析及成果 =》
![](https://img-blog.csdnimg.cn/img_convert/45eaad2cb92f96fadcfa726a7789c102.png)
《面向对象的编程》:用面对对象的方法进行软件编程
《面向对象的分析》:设计范畴,把现实领域转换成对象的方法。
系统分析的本质就是根据用户的需求进行初步的架构设计。
5.3 掌握的需求全不全 =》 架构师需要全面了解各种层面、各个维度的需求
![](https://img-blog.csdnimg.cn/img_convert/6310877b815d507c92e43a6926b206f6.png)
5.3.1 二维需求观与ADMEMS矩阵
为了确保需求的完备性,需要从如下的矩阵模型中收集需求。
![](https://img-blog.csdnimg.cn/img_convert/789e8435b7606e5e50bb9ddaaa16a4f8.png)
![](https://img-blog.csdnimg.cn/img_convert/932b59362295f2c52b26463136b0ea35.png)
![](https://img-blog.csdnimg.cn/img_convert/a1623a2928223347347857a9d6427e79.png)
![](https://img-blog.csdnimg.cn/img_convert/13f0bc9afc8a007975f190ca28e2ac1b.png)
![](https://img-blog.csdnimg.cn/img_convert/94567221f12b04ac3fd8bb6b700ee417.png)
5.3.2 功能性需求(最常见的需求)
![](https://img-blog.csdnimg.cn/img_convert/41a7201196e07f5a9b4733bebb3238d4.png)
![](https://img-blog.csdnimg.cn/img_convert/8b576348308c9e514765e640fcaaa06c.png)
![](https://img-blog.csdnimg.cn/img_convert/e9f7ddf958383a54dbba1ab7db56173d.png)
5.3.3 质量性需求
![](https://img-blog.csdnimg.cn/img_convert/649358c32112aad5a665688efb43857c.png)
![](https://img-blog.csdnimg.cn/img_convert/56a14db6407ac1d7f4ec43ed661adfff.png)
![](https://img-blog.csdnimg.cn/img_convert/1e3a1c6f1285a61152365cdf4956036d.png)
![](https://img-blog.csdnimg.cn/img_convert/bcf2148f499a0c546bc33290ffad2df4.png)
![](https://img-blog.csdnimg.cn/img_convert/c8591e321880135d0a516f5f34967dcd.png)
![](https://img-blog.csdnimg.cn/img_convert/db7b37dc086bb3321c0f80486ce71280.png)
![](https://img-blog.csdnimg.cn/img_convert/188ee9c45f3d0ed40abe508eaa71b221.png)
软件的质量,取决于如下的因素:
软件质量属性的需求收集与需求分析
软件架构设计
软件程序设计
程序员的编码能力
程序的态度
公司的软件开发流程
项目管理
业务部门的管理
所有上述这些因素共同决定了软件的质量属性。
5.3.4 约束
![](https://img-blog.csdnimg.cn/img_convert/a2d7c5aa60675ed175d1356bb7e7eed8.png)
![](https://img-blog.csdnimg.cn/img_convert/40aae22823381e43938051544ceffbeb.png)
5.4 如何把"需求"转换成“架构设计”:需求决定架构的方式?
需求决定架构,不存在没有软件需求的软件架构!!!
需求层次包括:业务需求、用户需求、产品需求。
需求维度包括:功能需求、非功能需求:质量属性、非功能需求:质量属性(运行期+开发期)
![](https://img-blog.csdnimg.cn/img_convert/3bc0c2229978acce07e4f9d6a049524a.png)
5.4.1 “理性设计”还是“拍脑袋”
![](https://img-blog.csdnimg.cn/img_convert/78e2b89779533af90dc8f191e3a50013.png)
备注:这里有一个基本观点,把需求转换成架构设计,不是靠拍脑袋,也不仅仅靠经验,把需求转换成架构设计有方法可循。
![](https://img-blog.csdnimg.cn/img_convert/7af7dd7e1e01b899c4f30ae80e4e1a49.png)
5.4.2 功能:职责协作链 =》转化为软件架构中的子系统、模块、组件等
![](https://img-blog.csdnimg.cn/img_convert/ef21e6ef3916f228d7b24efcef73c725.png)
备注:
用户给定的是功能需求,架构师需要为不同的用户功能设计职责协作链,即为了满足某种功能,需要哪些子系统参与,相互协作才能完成才功能,不同子系统的职责是什么?并为子系统的职责定义相关的接口、协作方式。
因此,功能设计相对比较直观,架构师的主要任务:
定义子系统的个数、各自的职责
把用户的功能需求,进行职责链分解
把职责分配到不同的子系统中
为子系统的对应的职责定义新的接口
为子系统之间交互定义协作方式
5.4.3 质量:完善驱动力 =》转化了软件系统的性能和功能要求
![](https://img-blog.csdnimg.cn/img_convert/0e529df93c864b7b9eac02a8efe37b1f.png)
备注:
在完成需求的基础之上,进一步完善软件架构,完善质量需求。
质量需求是对现有系统不断精进的过程 。
质量需要开始于需求分析,构建于架构设计,贯穿于开发流程和项目管理流程的每个环节。
5.4.4 约束:设计并不自由 =》转化成质量要求=》功能要求=》运行环境要求等
导致产品研发失败的大量风险被隐藏在约束条件和质量属性中!!!!
![](https://img-blog.csdnimg.cn/img_convert/e57ee972ad7e458949ef051436de77c3.png)
![](https://img-blog.csdnimg.cn/img_convert/69d5d4174b8c76ee981c172966248413.png)
5.5 实际应用(3)——PM Suite贯穿案例之需求分析
5.5.0 基本思路:用三横、三纵替代三纵两纵
三横,即三个层次的需求:业务目标、高层次级需求、用户级需求(用例)
三纵,即三个维度的需求:功能性需求、非功能性需求、约束性需求
![](https://img-blog.csdnimg.cn/img_convert/a7e72db23a88d110281e0d6e8de688e1.png)
![](https://img-blog.csdnimg.cn/img_convert/d842b4064eb6e62c60e1d6a195228d6b.png)
5.5.1 PM Suite案例背景介绍
![](https://img-blog.csdnimg.cn/img_convert/195a9aa1c6cc8d0b023567e5e2c1c994.png)
5.5.2 第1步:第一纵第一横(层次)需求:明确系统业务目标
![](https://img-blog.csdnimg.cn/img_convert/71d7abc2a3583edc4a63d7afe5d450cb.png)
系统业务目标是组织运营服务的。
5.5.3 第2步:第一纵第二横(层次)需求:范围 + Feature + 上下文图
![](https://img-blog.csdnimg.cn/img_convert/a886e076780428e535b5046c36b4c021.png)
(1)需求范围
![](https://img-blog.csdnimg.cn/img_convert/acd25db45a335df9f573a73b03eedc53.png)
![](https://img-blog.csdnimg.cn/img_convert/a31f3275a3ce7c6482a77b5d235316b1.png)
备注:
scope:英语单词,名词、动词,作名词时意为“范围;余地;视野;眼界;导弹射程”.
需求范围 requirment scope:就是目标系统特征的大的特征,大的框架。框架内属于需求范围,框架之外需求范围之外。
需求范围是可以分层次、分组、分阶段的。
![](https://img-blog.csdnimg.cn/img_convert/3a663f1dd945dbcd2a884c5ee73fe3ab.png)
需求框架和架构框架并不是一回事
需求框架:是组织目标系统需求的一种架构化、图形化的方式。
软件架构:是代码实现软件系统需求的一种架构化、图形化的方式。
可以把软件架构设计成与需求框架一致的架构,也可以设计成不一致的架构!!!
(2)需求特征/特性Feature
![](https://img-blog.csdnimg.cn/img_convert/7acf2d27c5e482503da3613800267583.png)
![](https://img-blog.csdnimg.cn/img_convert/bbd8ae5240a31e85fa1324c42583cf1d.png)
![](https://img-blog.csdnimg.cn/img_convert/9450d461790066e304fe72b8803b5fb8.png)
![](https://img-blog.csdnimg.cn/img_convert/7efdd9979f4fbb2f664a850842c9ce68.png)
![](https://img-blog.csdnimg.cn/img_convert/3d4f50720cef3173b33ba52a7d76e98e.png)
![](https://img-blog.csdnimg.cn/img_convert/222f63d58b2a5c8d3d97b3c32e579357.png)
(3)需求上下文Context图
![](https://img-blog.csdnimg.cn/img_convert/e6dd7cb4d160fdc4f16b0bb554fd740c.png)
![](https://img-blog.csdnimg.cn/img_convert/907c9f75deec80f70470d5662d1e92c1.png)
5.5.4 第3步:第一纵第三横(层次)需求:画用户用例图
用例图:描述的是软件系统的需求,而不是用户需要,因为,因为用例图中的actor不仅仅包括用户,还包括还其他系统,以及内部的定时器 。
![](https://img-blog.csdnimg.cn/img_convert/b8c76034322b81e162d3e0a36335e010.png)
![](https://img-blog.csdnimg.cn/img_convert/3d655e1cab19495b2b510a96755031cb.png)
![](https://img-blog.csdnimg.cn/img_convert/b6e8448231894e5c9078f7389c323274.png)
![](https://img-blog.csdnimg.cn/img_convert/a25d904e98001b8e03b9aa3fed8013d8.png)
5.5.5 第4步:第一纵第三横(层次)需求:写用例User Case/senario)规约
用例User Case/senario)规约是对用户用例图的详细描述,需求文档中需要定义各种大量的User Case/senario以及对应的详细流程描述。
![](https://img-blog.csdnimg.cn/img_convert/e29c57077f2492768bc7a3c6fd45f64e.png)
![](https://img-blog.csdnimg.cn/img_convert/19a6bfc06d14818ad9cf618f74dace01.png)
备注:
每个用例有包含数据处理流程,用例User Case规约用于描述用例的输入、处理、输出等信息。
开发人员用此用例规约实现代码。(类似测试用例或业务场景senario)
测试人员用词用例规约验证代码的实现情形(类似测试用例或业务场景senario)
5.5.6 插曲:第一纵(功能性需求迭代):原型开发、需求启发与需求验证
![](https://img-blog.csdnimg.cn/img_convert/c57a3ab53d7710c29795538a340aa20d.png)
![](https://img-blog.csdnimg.cn/img_convert/b14c6ac12978051043c1fd0aad6bd3b0.png)
![](https://img-blog.csdnimg.cn/img_convert/acbb8479ebd7dceeda22604857f356c7.png)
说明:
在某些领域,用户机界面是产品需求,如互联网产品的用户界面,在这种场合下,产品经理代表用户会严格定义产品的用户界面的布局、内容、美观等需求。
然而,在大多数领域,界面不是需求,产品经理不并关注用户界面的设计,而关注的是界面要包含的内容,甚至内容也不关注,只关注系统完成的功能。在这种场合中,用户界面就是设计,而不是需求!!!
也就是说,用户 界面,有时候是需求,有时候是设计,取决于场合。
5.5.7 插曲:第二纵(非功能性)需求:非功能需求
![](https://img-blog.csdnimg.cn/img_convert/e43de4cd5a84a5a5b2b750c8926a2bb8.png)
5.5.8 输出:《需求规格》与基于ADMEMS矩阵的需求评审
![](https://img-blog.csdnimg.cn/img_convert/45d5fa226cd7c834a19d25408246d696.png)
![](https://img-blog.csdnimg.cn/img_convert/5e475133df0880b1660b6cb22d7a9883.png)