软件需求分析-需求开发-需求分析与建模和需求描述

C6需求分析与建模

一、要点

需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架爱，以指导后续的设计、开发工作。
需求分析就是先分解、再提炼，在这个过程中消除矛盾。
1.需求分析做些什么

• 分解

a.业务流程为主线索的分解结构
按“事”的角度进行分解。对于联机事务处理系统、管理信息系统非常适用。
目标系统——>主题域的分解依据的是“目标决定范围”
主题域——>业务事件、报表类型所做的是理清脉络
业务事件——>业务活动、报表类型——>报表所做的是填充细节

b.程序结构为主线索的分解结构
适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件等
c.基于场景的分解结构
对于决策支持系统，决策场景、使用场景就是主要线索。向上可以总结成一类相似的集合，在总结成一系列的关注点或功能域。向下可以分解成具体的决策步骤或操作任务。
d.基于数据结构的分解结构
以数据为主线的分解，诸如数据仓库之类的数据类项目

小结：在选择了何时的分解结构后，就可以吧需求规格说明书的大纲确定闲下来，知道应该捕获什么信息

• 提炼
  抽取共性的部分，建立针对整个系统的全局领域模型

• 消除矛盾

2.建模的目的与要点
目的：帮助我们按照实际情况或按我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个知道系统构造的模板；对我们所周的决策进行文档化。
模型是用来沟通的。
3.建模工具的选择
UML统一建模语言
UML图的选择

二、周期一：理清框架和脉络

输入：需求定义阶段产生的业务事件列表和报表类型
输出：领域模型和用例模型
结束的标志：标识除了绝大部分的用例，生成了领域模型
任务：
业务流程分析：每个业务事件的过程
业务实体分析：了解业务术语间的关系
用例分析：确定不同角色的任务
1.业务流程分析
业务流程分析主要信息来源是负责该业务流程的中层管理人员，因此访谈的对象就是这类人员。
具体来说就是，针对每一个业务事件，，分析并识别现有业务活动，确定业务活动之间的关系；了解这些业务活动需要接收哪些信息，又将会产生哪些数据（表单），确定数据传送的路线；同时标识处业务活动是由那些部门、岗位负责等信息。
1）流程是有层次的
流程有组织机构、部门级、岗位级三个层次。其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。
2）流程是由类型的
生产性流程
管理性流程
支持性流程
3）流程分析的产物
跨职责流程图——工具：Visio
活动图——工具Rose、Together
数据流图——工具：Visio

书上的建模例子挺不错的，也很助于理解。尤其是数据流图
我觉得在数据流部分的0层图和1层图的划分有点小问题，0层图我认为应该是只有中间一个系统的，当把系统功能细化后应该就是1层图了吧。阿不，它是对的。中间只有一个系统的是顶层图，往下依次为0层图，1层图…

2.业务实体分析
业务实体（或称业务数据、业务术语）。识别业务实体及其之间的关系的过程就是所谓的领域建模、概念建模
针对每一个业务事件、每一类报表进行领域类图片的绘制时，主要步骤有三：

识别出业务实体
确定实体之间的关系（语义关系和数量关系）
定义实体的关键属性

业务实体分析产物有两种可选类型：
类图
E/R图
书上有类图和E/R图的例子，由于我再复习软件设计师的时候认真学过了就快速浏览了一遍
类图应用基础
在需求建模时，可以大胆使用中文命名建模的类名和类的属性，易于理解
E-R图应用基础
描述业务实体之间的关系除开使用类图外，也可以使用传统的E-R模型。他的优势在于能够很好地与后续的数据库设计结合，缺点在于语义相对弱一点，同时对买向对象开发的指导作用相对差一些。
1）数据建模过程
2）主要元素
基本元素：实体、属性、关键属性（键值）、关系
元素之间的关系：1:1,1:n.n:m

3.角色与使用场景分析
使用用例图分析，可以更好的完成以“人”的视角梳理需求
1、用例图
系统边界：方框内是系统，系统外的都是方框外，例如人、参与者都是系统外的
参与者与用例的关系：用一根带箭头的线表示两者之间可以进行通信。
用例之间的关系 ：包含、扩展、泛化。
4.周期一的产物
1）工作任务说明
在需求分析的第一阶段，核心任务就是结合业务流程、报表的需求，梳理出结构框架（领域模型）和行为 脉络（流程图——>用例模型），为第二阶段的需求分析工作指出方向。
2）业务事件分析
业务流程分析——可以使用泳道流程图
业务实体分析——类图
角色-使用场景分析
3）报表分析
1.why目标
2.what内容
相关业务实体分析
报表项分析
数据项及计算方法分析
4）抽象与整理
1）抽象用例模型
2）抽象类模型
5）填充需求规格说明书

三、周期二：确定需求细节

阶段任务：对用例模型、邻域模型标识处用例、领域类的细节进行填充。
填充组织行为需求用例的事件流
填充组织数据（结构）需求的领域类的字段和格式

四、其他需求

接口需求
非功能需求的跟踪

C7需求描述

需求描述的风格与格式

1.常见的描述风格与格式
1）自然语言
2）图形化语言
3）形式化规格描述
4）建议：
自然语言为主，辅之以图形化模型——最常见，绝大多数IS系统、软件产品
图形化模型为主，辅之以自然语言作为补充——RUP所推荐的方法
以形式化规格语言为主，辅之以图形化模型，以自然语言为补充——适用于以质量要求很高的邻域，例如航天、军工项目。
2.典型软件需求规格说明书解析
3.自定义模板的技巧
示例：
SERU需求规格说明书模板

1.文档概述
	1.1 编写的目的
	1.2 背景
	1.3 定义
	1.4 参考资料
2.任务概述
	2.1 业务需求
	2.2 Stakenholder利益分析
	2.3 用户特点分析
	2.4 相关事实与假定
3.需求概述
	3.1 系统概述【主题域划分，用构件图表示】
	3.2 主题域1
		3.2.1 概述【用上下文关系表表示该主题域的范围】
		3.2.2 业务事件
			3.2.2.1业务事件1【包括流程分析、领域类分析、用例分析】
			......
			3.2.2.n 业务事件n
		3.2.3 报表
			3.3.4.1 Report1
			【用领域类图片表示涉及数据，用用例图标识具体的报表项】
			......
			3.2.3.n Reportn
	3.3 主题域n
4.具体需求
	4.1主题域1
		4.1.1用例模型
			4.1.1.1UC_B_xx（B类）
				（1）概述【编号、名称、概述、相关Stakenholder】
				（2）事件流描述【前、后置条件，基本、扩展、子事件流】
				（3）相关需求与功能点
				（4）界面原型【交互过程与界面详解】
				 (5)规约与约束
			4.1.1.2UC_R_xx(R类)
				（1）概述【名称、用户部门与职位、业务意图、相关场景】
				（2）报表内容【领域类图、数据项】
				（3）输入、输出格式
				（4）其他
			4.1.1.3UC_I_xx（I类）
				（1）使用者【名称、业务目的、时机、频率】
				（2）内容与格式【交互过程、数据包说明】
				（3）设计与实现约束【诸如协议格式要求、性能要求等】
				.......
		4.1.2.领域模型
			4.1.2.1xx领域类
				（1）概述【类名称、别名】
				（2）数据窗口分析
				（3）数据组成与格式
				（4）其他
	4.n主题域n
5.补充规约
	5.1 设计约束
		5.1.1 技术选择的限制条件
		5.1.2运行环境[建议用部署图表示]
		5.1.3预期的使用环境
	5.2质量属性【本部分建议直接分解成需要开发的技术功能点】
		5.2.1安全性要求
			5.2.1.1访问安全性要求
			5.2.1.2数据安全性要求
			5.2.1.3通信安全性要求
			5.2.1.4.其他安全性要求
		5.2.2可靠性要求
			5.2.2.1容错性要求
			5.2.2.2可恢复性要求
			5.2.2.3其他可靠性要求
		5.2.3易用性要求
		5.2.4性能要求
		5.2.5可维护性要求
		5.2.6可移植性要求
		5.2.7其他质量属性要求
	5.3其他需求
		

C8需求验证

结束。