目录
一、需求获取
二、需求分析
1.结构化需求分析
2.面向对象分析方法OOA
三、UML 4+1视图
四、UML 图
(1)用例图
(2)类图、对象图
(3)顺序图
（4）活动图
（5）状态图
（6）通信图
- 软件需求指用户对系统在功能、行为、性能、设计约束等方面的期望
- 软件需求指用户解决问题或达到目标所需的条件和能力是系统或系统部件要满足合同、标准、规范、或其他正式规定文档所需具有的条件和能力，以及反映这些条件的能力的文档说明。
- 需求获取，通过开会、调查等手段了解客户的原始需求；需求分析，对获取到的需求信息进行整合，并发现其中的问题；需求定义，落下需求规格说明书等需求文档，确立需求基线SRS，按照基线的规划进行；需求验证，把需求规格说明书交付给客户确认，了解自己分析的内容
一、需求获取
需求在技术维度上可以分类成，业务需求、用户需求、系统需求。业务需求通常指的决策层例如CEO提出来的需求，软件项目的创立目的。而用户需求指的是 软件使用方的需求。而把这些功能计算机化就落成了系统需求,分成功能需求、性能需求、除此之外需求就界定为设计约束。
需求在管理维度上可以分为基本需求（用户明确提出来的要求，必须做的）、期望需求（客户没提但是也应该做的需求）、兴奋需求（客户没提，不是必须要做的，但是包含在客户期望中）。兴奋需求在项目管理中要特别识别，积极完成兴奋需求不可取，否则容易造成白白损失工作量，报酬。
二、需求分析
1.结构化需求分析
它会完成功能模型（通常用DFD进行建模），数据模型（通常用ER图进行建模），行为模型（通常用状态转换图进行建模）。并用数据字典描述数据的详细字段
2.面向对象分析方法OOA
面向对象分析有五个活动：分别是认定(识别)对象；组织对象；描述对象间的相互作用；确定对象的操作；定义对象的内部信息。
关于面向对象的一下概念：
- 对象，对应的现实生活中的具体的人、物，三要素是 属性，id，方法。而将对象进行抽象就是类。
- 类分成实体类，边界类，控制类。实体类就是一个抽象实体的信息。而边界类用于外部系统交互，例如打印机，窗体等。
| 实体类 | 描述系统中的实体，通常可以用数据库进行存储。它包含存储和传递数据的类，还包括操作数据的类。 |
| 边界类 | 用于描述外部参与者于系统间的交互，位于系统于外界的交界处。包括窗体、报表、打印机、扫描仪等硬件的接口，以及其他系统的接口 |
| 控制类 | 用于实现应用程序的执行逻辑，可以降低界面和数据库之间的耦合。通常用“动词+名词”的方式。是控制用例工作的类。比如身份验证 |
- 泛化指多个实体类将共性部分抽象出来成为一个父类。而继承是从父类上生成一个子类，子类拥有父类的特性。
- 多态类型如下表
| 通用多态(不同的类型值，执行相同的代码) | 参数多态 | 例如c++中的template（静态联编时候实现） |
| 包含多态 | 类似于虚函数（动态联编时候实现） | |
| 专用多态(不同的类型值，执行不同的代码) | 强制多态 | 类型的隐式转换（静态联编时候实现） |
| 重载多态 | 类似于函数重载（静态联编时候实现） |
三、UML 4+1视图
统一建模语言主要用画图的形式进行设计模型。构造块的事物包含4个事物，其中分组事物、注释事物不详细讲。结构事物对应的是“静”，而行为事物对应的是“动”。
UML图如下
| 类型 | 名称 | 功能 |
| 静态图 (结构图) | 类图 | 侧重强调类、接口、协作和它们之间的关系 |
| 对象图 | 侧重强调对象及它们之间的关系 | |
| 构件图 | 侧重强调封装的类和它的接口 | |
| 部署图 | 侧重强调软件和硬件之间的映射 | |
| 制品图 | 侧重强调系统的物理结构 | |
| 包图 | 侧重强调由模型本身分解而成的的组织单元，以及它们之间的依赖关系 | |
| 组合结构图 | ||
| 动态图 (行为图) | 用例图 | 侧重强调系统与外部参与者之间的交互 |
| 顺序图/时序图 | 侧重强调按时间顺序 | |
| 通信图/协作图 | 时序图的变种，侧重强调对象的组织关系 | |
| 状态图 | 侧重强调状态转换变迁 | |
| 活动图 | 强调对象间的控制流程以及并行、同步行为 | |
| 定时图 | 侧重强调实际时间点运行状况 | |
| 交互概览图 |
4+1视图：就是逻辑视图，实现视图，进程视图，部署视图还有用例视图。逻辑视图表现系统功能，实现视图表现程序的组件，进程视图强调线程进程的并发，部署视图强调软件到硬件的映射关系。
UML在需求分析的建模工作，主要建立用例模型和分析模型。分析模型要定义一些类，还有类之间的关系，以及它们的职责。而用例模型要识别参数者，以及获取参与者所需要的功能，之后细化这些功能描述
四、UML 图
(1)用例图
用例图描述了一组用例，参与者与它们之间的关系。参与者是触发系统内部逻辑的外部因素，比如用户，管理员，定时器，温度计等。而用例就是在用户角度所描述的功能。
其中关系包括3种：
包含关系：提取出来的公共用例称之为抽象用例，而把原始用例称为基本用例或基础用例系，当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。即完成基本用例必定完成包含用例，用“虚箭头+include”表示。
扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。即完成基本用例可选择完成扩展用例，用“虚箭头+extend”表示，箭头指向基本用例。例如ATM机系统，取款用例(基本用例)与打印取款凭证(扩展用例)的关系。
泛化关系：是一种用例之间的父子关系，用实心箭头的表示
用例建模，首先要了解这个系统是要给谁用的，也就是识别参与者 ；然后从参与者中了解它们想要的功能，也就是获得用例。之后还要对用例进行细化，描述用例具体要表达的含义，例如登记外接信息要做什么，有什么注意事项，还有信息具体是什么。
细化用例描述如下，其中主事件流表示完成用例功能必须的流程，而备选事件流就是当达到某些条件会触发的流程。
(2)类图、对象图
类图和对象图类似，在图形种的表示，对象图的实体名称是 "类名:对象名"。
- 依赖关系:例如A方法中调用了B方法，说明了A依赖于B，因为B的行为发生变化，参数变化，方法名变化都会影响到A。
- 泛化关系：也是一种 抽象—具体关系，父子关系，子指向父。
- 关联关系：包含了聚合关系和组合关系，聚合关系像是子对象的关系，比如汽车与轮子；组合关系像是集合，比如书籍列表和书籍
- 实现关系：接口与实现接口的类之间的关系
(3)顺序图
顺序图/时序图是一种交互图，它强调对象之间的消息发送的顺序，同时显示对象之间的交互。
（4）活动图
活动图每一个节点表示系统或者人员要完成的事情，可以表示并发。用控制流和数据量表示进程运行的流程。强调对象间的控制流程
- 并发分叉:达到条件后并发执行后续任务
- 并发汇合:前面的任务都完成后才会执行后续的
（5）状态图
状态图描述一个状态机，它由状态、转移、事件和活动组成。每一个节点表示某个物体状态。
状态图包括简单状态和组合状态、转换。可以利用fork和join使组合状态再某一时刻同时达到多个子状态。中途从组合状态中退出，后续再进入组合状态时进入原先退出前的子状态，而不是从初态从新开始。
（6）通信图
通信图与时序图大同小异，只不过它不像时序图那样按照严格的顺序去走，只不过把大致的流程显现出来，把消息打上序号而已。通信图强调的是对象的组织结构。
