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 主题域13.2.1 概述【用上下文关系表表示该主题域的范围】3.2.2 业务事件3.2.2.1业务事件1【包括流程分析、领域类分析、用例分析】......3.2.2.n 业务事件n3.2.3 报表3.3.4.1 Report1【用领域类图片表示涉及数据，用用例图标识具体的报表项】......3.2.3.n Reportn3.3 主题域n
4.具体需求4.1主题域14.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需求验证

结束。