需求分析.md

Chapter 1 介绍

软件开发的战略性技术

1. 需求工程
2. 项目管理
3. 软件体系结构设计

项目的成功标志

在规定的时间内，在规定的成本条件下，达到或超过项目利益干系人的需求

软件开发的本质

1. 复杂性
2. 一致性
3. 可变性
4. 不可见性

软件开发的偶然性因素

1. 利益干系人
2. 过程
3. 建模、模型

利益干系人

客户 投资人 老板 用户 开发人员 竞争对手 项目管理人员 政府 开发人员家属……

过程

1. 顺序
2. 成果物
3. 分配人
4. 标准

软件开发模式

1. 瀑布式
2. 敏捷
3. 增量迭代
4. RUP

开发方法（技术

1. 面向对象
2. 面向功能（结构化）
3. 面向数据

面向对象和结构化方法的区别

1. 分解方法 a. 功能 b. 对象
2. 代码层面
3. 开发方式 以五子棋为例

   • 结构化：

     1. 开始
     2. 黑子先行
     3. 绘制棋盘
     4. 判断输赢
     5. 轮到白子
     6. 绘制棋盘
     7. 判断输赢
     8. 返回步骤2.
     9. 输出结果

   • 面向对象：

     1. 棋子 移动 ……
     2. 棋盘 绘制
     3. 规则系统（由配置文件决定） 判断输赢

回顾

1. 软件开发的战略性技术
2. 软件开发的本质
3. 软件开发的偶然性因素
   1. 利益干系人
      • 用户侧
      • 开发侧
   2. 过程模型<通用模型>
      • 顺序
      • 时间 成果物
      • 分配人
      • 标准
   3. 建模 UML语言 对象描述语言
4. 面向对象和结构化区别

系统规划

• efficiency强调效率 更快地朝目标前进 正确地做事 “方法论”
• effectiveness强调效能 确保向目标前进 做正确的事

企业上层人员需要effectiveness,企业基层人员需要efficiency

SWOT approach

strengths weakness opportunities threats

• 任务目标
  • 内部分析
    • 优势
    • 弱点
  • 外部分析
    • 机会
    • 威胁

系统类型

• OLTP（事务处理）
• OLAP（分析）

软件开发生命周期

1. 建模方法
2. 阶段划分
3. 开发方法和开发模式

阶段不可跨越，但阶段成果物可以省略

生命周期

1. 需求分析
   • 功能性需求和非功能性需求
2. 系统设计
   • 架构设计
   • 细节设计
3. 实现
   • 编码
   • round-trip engineering 往返工程
4. 集成和部署
5. 运作和维护

省略成果物的影响

• 只能参照代码做测试
• 隐藏了问题
• 只能不断修改代码

本章小结

1. 软件开发的战略性技术
2. 软件开发的偶然性因素
3. 过程模型（方法论）
4. 面向对象和结构化区别
5. 软件开发的生命周期

Chapter 2 需求分析

软件开发的第一步

• 需求确定
• 需求调研
• 需求获取

需求获取的重要性

1. 最困难
2. 最关键
3. 最易出错
4. 最需要交流

最困难

需求获取是否准确的前提条件

1. 领域知识（行业）
2. 沟通能力

复合型人才

1. 业务与技术
2. 管理与技术
3. 外语与技术
4. 文学与技术
5. 销售与技术

什么是IT解决方案（方法论）

1. 商业解决方案（业务 商业模式）
2. 实现业务流程（业务场景）
3. 触发业务流程改进
4. IT基础架构
5. 形成商品和产品

什么是需求

提出的事物及其品质要求 谁需要什么样的东西 三位一体

• 谁：需求主体（最终用户）
• 什么样的：需求的形式（样式 布局 颜色 交互）
• 东西：需求的内容（数据 信息）

需求的种类

• 功能需求
• 非功能需求
  • 质量要求
    • 扩展性
    • 灵活性
    • 可靠性
    • 性能
    • ……
  • 约束 例子：ATM机

1. 能验证卡的有效性——功能需求
2. 3秒内验证用户身份——非功能需求
3. 限制每天取款不超过1万元——功能需求
4. 使用C++实现——肺功能需求

系统软件架构

由非功能需求决定

需求层次

• 业务需求：业务目标（系统目标）——行动力、指导性（纲领性—）
• 用户需求：用户期望系统实现的功能——这里的功能是指完成的事情
• 功能需求：软件开发人员应实现的功能——这里的功能是指功能点
• 技术需求：技术细节

变更的频度

从上到下，变更产生影响逐渐变大，变更频度逐渐变小

• 呈现样式
• 展现逻辑
• 业务逻辑
• 业务流程
• 数据结构

需求层次细说

• 业务需求、用户需求：用户侧，只要用户说的就是，不管多细
• 功能需求、技术需求：软件开发侧 需求分析就是从用户侧需求分析得到软件开发侧需求的过程

需求获取总体流程

前提条件

• 领域知识
• 沟通能力

具体流程

1. 组织队伍
2. 确定需求调研计划和调研问题
3. 发给用户方确认
4. 组织实施需求调研工作（需要采用需求获取技术）
5. 整理和确认调研结果

需求获取技术

1. 访谈 面对面交流（2~4人） 风险：获取障碍，人的情绪会影响

2. 问卷调查 问题设计 问题类型

   1. 封闭性（一般疑问句） 确认
   2. 开放性 5W 1H who where why when what how

   一般选择半封闭性的问题

   步骤

   1. 目的 目标
   2. 设计
   3. 小范围实验
   4. 修改完善
   5. 发出/收集/整理

3. 观察/示范 （风险：做样子） 要有同理心 要使最终用户感到友好和易用

4. 文档研究 （风险：文档可能过时，不符合实际情况） 文档指

   1. 行业标准、国家国际标准
   2. 规章制度
   3. 工作流程（操作手册）
   4. 各类报表、报告、表格

5. 会议 会前：

   1. 会议计划 目的
   2. 准备会议材料
   3. 发送给与会人员

   会中

   1. 时长1.5h左右
   2. 设立会议主席控制进程
   3. 确定发言时长

   会后：

   1. 整理会议记录
   2. 形成会议纪要

6. 原型法 方法：

   1. 纸/笔
   2. 画图工具
   3. 原型开发工具
   4. HTML+CSS

7. 头脑风暴

需求获取的主要工作

1. 相关人员分析 相关人员即直接或间接从系统中受益的人 针对具体的人确定具体的问题 将业务需求和用户需求获取完善、准确
2. 针对性的问题提纲
   • 问题类型
   1. 宏观（全局）
   2. 中观（局部）
   3. 微观（细节）

模型种类

• 业务模型
• 需求模型
• 架构模型
• 应用模型
• 数据库模型

业务模型

一、创建系统环境模型

系统的边界 上下文图 例：学生信息管理系统

模型：

• 图
• 描述性文字

接口：

1. 系统间接口——需求分析
2. 模块间接口（子系统）——架构分析
3. 类间接口——详细设计

系统间接口：

1. 通信协议
2. 数据内容与格式
3. 数据获取的方式
4. 数据同步方式

人机接口：

• 友好性
• 易用性

二、创建业务流程模型（带泳道的活动图）

用户的业务过程 例子：

三、业务用例模型

业务用例与系统用例区别

四、业务流程模型

五、业务场景模型

系统边界：

• 系统环境模型
• 业务用例模型

用户的业务过程

• 业务流程模型
• 业务场景模型

核心数据

• 业务结构模型

何时完成需求获取

1. 如果用户不能想出更多的业务场景
2. 如果用户提出新的业务要求，分析员可以从其他需求中获得这些业务要求
3. 如果用户开始重复原先讨论过的问题
4. 如果用户提出对将来产品的需求

需求调研的系统功能特性（用户侧）

结构化功能规格说明

使用功能规格说明表达需求的不足

1. 通常忽略其关联的用户及其为用户提供的利益
2. 不够精确，难以区分在不同场景下系统所表现出的行为差异
3. 不容易表达系统与其上下文之间的关系
4. 非功能需求与功能需求说明被人为割裂，难以清晰地表达两者间的联系
5. 功能规格说明与测试用例间存在明显的鸿沟，不能直接转化

第三讲

state model

设计的结果

1. 类图
2. 包图

behavior model

设计的过程

1. 用例图
2. 活动图
3. 交互图（时序图、协作图）

什么是用例模型

从最终用户角度看的系统的功能和环境 是用户和开发者之间的契约

为什么要构建用例模型

1. 用例模型允许用户和系统开发者之间用一种用户可以理解的语言交流系统要做什么
2. 是用户和开发者之间的可视化契约（可见 可感受 可测量 可衡量）

用例建模的作用和意义

是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过用户与系统之间的交互关系描述了系统对外提供的功能特性

面向对象的用例建模过程

需求分析——>用例建模技术（方法）——>用例模型——>《需求分析说明书》（文档）

什么是用例

用户（参与者）与系统功能特性间的交互关系（一系列步骤）就是用例

用例建模过程

1. 确定系统范围
   • 系统环境模型
   • 业务用例模型
2. 识别参与者（最终用户）及其目标
3. 基于参与者识别用例
   • 概要层
   • 用户目标层
4. 用例详述（交互）
5. 分解 合并关系

用例建模的步骤和方法

识别参与者

• 参与者类型

1. 人
2. 系统
3. 硬件
4. 定时器

参与者=最终用户 相关人员包含参与者

相关人员直接或间接 参者直接

每个参与者需要一个具有业务意义的简短名称 每个参与者必须有简短描述，它从业务角度描述参与者是什么 例: 学生：是指软件学院全日制本科生

用例是参与者想要系统做的事 是参与者与系统的一系列交互

识别用例

用例详述

用例活动图

包含和扩展用例区别

用例模型包含的内容

1. 用例图
2. 用例详述（功能需求 技术需求）
3. 活动图
4. 主要界面原型

第四讲 分析到设计

用例分析的作用和目的------？？？？？

确定执行用例事件流（外在结构）的类（系统内部对象）

分析类的种类和职责

通过职责分类

1. 边界类：Boundary class 边界对象的抽象，通常是用来完成参与者（用户、外部系统）与系统之间交互的对象，例如：From、对话框、菜单、接口等
2. 控制类：Control class 控制对象的抽象，主要用来体现应用程序的执行逻辑，将其抽象出来，可以使变化不影响用户界面和数据库中的表
3. 实体类：Entity class 实体对象的抽象，通常来自域模型（现实世界），用来描述具体的实体，通常映射到数据库表格与文件中

分析类是对设计类和子系统的一种抽象，一个分析类往往代表了一批设计类

识别分析类的方法

基于用例详述去识别分析类 名词抽取？？？？？

概念模型

1. 数据结构 2，静态系统

概念模型建模步骤

1. 找到备选类
2. 决定候选类

类的职责：

• 类所维护属性、属性值
• 类所执行的行为（方法）

类的关系 强弱排列：依赖（临时调用）<关联<聚合<组合<继承

1. 所有的继承关系都可以转换为聚合
2. 最多三层继承
3. 优先考虑聚合，其次是继承

需求分析说明书

• 用例模型（动态） 系统外在行为特征
• 概念模型（静态） 系统结构特征

分析模型包含的内容

动态模型（交互模型）

• 时序图
• 协作图

创建交互模型用以确定每个对象的职责

如何检验交互模型？ 与事件流一致

信息隐藏是手段 封装是结果

第五讲

架构分析

软件体系结构设计核心内容之一

1. 组件（模块）、构件
2. 组件的接口

模块+接口

用例分析

基于用例描述分析系统内部有哪些对象及对象间的交互作用

架构设计基础

用例模型 组件：

• 层
• 包
• 子系统

概念架构

直指目标

1. 设计思想
2. 重大选择

layer型架构模式

系统分为构件组

• 上层只能使用下层提供的服务
• 每一层只与相邻层相关

三层经典模式

• 呈现层
• 业务逻辑层
• 数据访问层

如何识别组件

1. 针对识别确定分析类归纳
2. 基于分层架构识别确定每个组件
3. 通过创建组件间的交互模型来确定每个组件职责

组件精化方法

1. 组件单一职责
2. 纵向切分 功能（职责）并列关系
3. 横向切分 功能（职责）有依赖关系

细化架构设计阶段（多视图法）

1. 逻辑架构设计（模块+接口） 创建模块的交互模型 确定模块的职责 实现了用例行为
2. 开发架构设计 （开发纪律）
3. 物理架构设计 部署
4. 运行架构
5. 数据架构（安全架构）

• 应用安全
• 数据安全
• 物理、网络安全

第六讲 详细设计

什么是设计

创建交互模型的过程

设计结果

得到设计模型（设计类图）

设计类图

• 属性
• 方法

对象（类）

• 职责：宏观概念、业务层面
• 操作：具体说明 方法的抽象
• 方法：可以用代码具体实现的功能

例：老师

1. 职责：教书
2. 操作：
   • 课前 备课
   • 课中 讲授
   • 课后 答疑、测试
3. 方法
   • 查找资料
   • 编写教学讲义
   • 设计案例 交互练习
   • 模拟演练

设计元素包含

1. 设计类：最后成果物
2. 接口：行为集（操作）
3. 设计子系统（组件）
4. 设计包（组件）

设计子系统

• 包的语义：容器（集合）
• 类的语义：
  1. 封装（信息隐藏）
     • 属性
     • 方法的实现
  2. 接口（方法）

1. 容器
2. 行为表现形式接口
3. 内部结构对外不可见

子系统和包的区别

• 子系统比包的封装性好
  • 子系统有接口
  • 包没有接口
• 子系统具有行为，而包没有

子系统接口如何确定

根据子系统的职责确定 根据子系统和其他子系统的交互确定 整个子系统里至少有一个proxy，一定是public

如果可能，尽量复用已经存在的组件

子系统设计

不要暴露细节，仅显示接口

将子系统行为分配给子系统元素

• 具体步骤
  • 对于每个接口，决定参与接口实现的类或子系统必要时需要创建新的类以及子系统
  • 让类和子系统交互来完成接口定义的行为，需要结合框架机制

子系统元素类型

1. 负责通信的类
2. 负责算法、业务逻辑的类
3. 负责数据
4. 辅助类、基础类

记录子系统元素

具体工作

• 描述类和子系统的责任
• 确定类和子系统的属性和关系
• 整合类和子系统

记录子系统的内部结构，要用一个或多个类图

设计模型

1. 类的交互模型（时序图）
2. 设计类图

详细设计 设计类图

1. 类名、可见性、职责
2. 属性（与生俱来） 可见性、类型初始值
3. 方法名、出参、入参 职责、功能 伪代码

软件公司（解决方案）定制化

1. 项目经理
2. 需求分析（咨询顾问）
3. 架构师（懂业务）

设计原则与模式

自底向上

• 面向对象思想 公理
• GRASP设计原则 定理
• 高级设计原则（SRP） 推论
• 设计模式（GOF） 定式
• 组件（AOP） 应用

下面三层不会改变

高级设计原则

• OCP（开放-封闭原则）
• SRP（单一职责原则）
• LSP（里氏替换原则）
• DIP（依赖倒置原则）
• ISP

OCP

• 类模块应该是可扩展的，不可修改的
• 对扩展开放，对更改封闭
• 在设计一个模块时，这个模块可以在不被修改的前提下被扩展

优点： 所有的软件系统都有一个共同的性质，需求都会随时间的推移而发生变化。在软件系统面临新的需求时，系统的设计必须是稳定的。

如何在OO中引入OCP

• 不允许更改的是系统的抽象层，允许扩展的是系统的实现层
• 把对实体的依赖改为对抽象的依赖

对OCP的追求适可而止，不要陷入过度设计

SRP

• 违反SRP通常由于过于真实地设计了一个类
• 往更高一层进行抽象化提取，将对某个类的依赖改变为对一组接口或抽象类的依赖

LSP

同一个继承体系中的对象应该有共同的行为特征

继承且覆盖超类方法时，子类方法的可见性必须大于等于超类方法的可见性，子类方法所抛出的受检查异常智能是超类中对应的方法所抛出的受检查异常的子类

如果违反了LSP 城建一个新的抽象类C

DIP

高层模块不应该依赖于低层模块。二者都应该依赖于抽象。

三个基本面向对象设计原则

• 针对接口编程，不是针对实现编程
• 优先使用对象组合，而不是类继承
• 封装变化点

如何设计好的面向对象

Chapter 7 GUI Design

UI UE

1. 布局
2. 风格（颜色、对比）
3. 字体
4. 图书
5. 图标

人文学科

1. 文学
2. 沟通能力
3. 管理学

UE

1. 交互、过程
2. 人体工学

架构师角色

1. 半技术专家
2. 半文学家
3. 半政治家
4. 半导师
5. 半传教士

Server solutions make the software Client solutions sell the software

PC端：微软 B/S端：模仿

Chapter 8 持久化和数据库

数据库类型

1. 关系型数据库
2. 对象型数据库
3. 对象关系型数据库

数据模型的层次

1. 概念数据模型 E-R模型 概念模型（实体类）
2. 数据库逻辑模型 表结构
3. 物理数据模型 a.与具体的数据库有关 b.存储 c.硬盘

参照完整性

1. Upd(R) Del(R)
2. Upd(C) Del(C)
3. Upd(N) Del(N)
4. Upd(D) Del(D)

第一种：只有当子表数据都删除之后才能删除 第二种：删除父表时删除所有相关的子表数据 第三种：子表项相关数据设为null 第四种：子表项相关数据设为默认

最常用的组合是Upd(C) Del(R)

1. 存储过程
2. SQL语句

存储过程运行速度快 但无法跨平台执行

应用表用view 基础表用table

视图对基础表起到了封装性的作用，数据库底层改了程序不需要大改

对象映射

对象属性是集合

对象关联关系的映射

1. 多重性的方向
2. 多对多关系的映射

聚合关系的映射

继承关系的映射

第一讲

1. 软件的本质
2. 软件开发的偶然性因素
   • 利益干系人
   • 过程
   • 模型
3. 软件开发的生命周期
4. 过程模型
   • CMMI
   • ISO 9000
5. 面向对象和结构化区别
6. 面向对象分析/设计

第二讲

1. 什么是需求
2. 需求种类
3. 需求层次
4. 需求获取重要性
5. 需求获取的步骤和流程
6. 需求获取技术
7. 需求获取障碍

第三讲

1. 什么是用例模型
2. 用例模型的作用是什么
3. 什么是用例
4. 用例建模的步骤和方法
   • 识别参与者
   • 识别用例
   • 用例详述
   • 用例活动图
5. 包含和扩展用例区别
6. 用例模型包含内容

第四讲 分析到设计

1. 用例分析的作用和目的
2. 分析类的种类和职责
3. 识别分析类的方法
4. 创建分析模型的步骤
5. 概念模型的作用和意义
6. 创建概念模型的步骤和方法
7. 分析模型包含的内容

第五讲

1. 架构分析与用例分析
2. 架构设计的总体步骤
3. 概念架构设计的方法与意义
4. 细化架构多视图法

第六讲 详细设计

1. 组件的构成
2. 设计元素
3. 设计子系统和包的区别
4. 设计子系统设计的方法

第七讲

1. 用户界面设计的原则

第八讲

1. 数据模型的层次
2. 对象模型和关系模型的映射