一、软件需求简介
在开发周期中发现需求理解错误的时间越早越好，修正错误的代价按发现错误时间的指数增加。
需求分析的位置（位于软件定义时期末尾）：
软件需求的特性：
- 可验证的：需求是测试的依据，尽可能量化表述
- 除了行为属性，还可能有其它属性，如：优先级
- 产品需求
- 过程需求：对开发过程的要求，如：使用某种语言或者工具
- 功能性需求(Functional Requirements, FR)
- 非功能性需求(Non-Functional Requirements, NFR)：可进一步分为：性能要求，可维护性要求，安全要求等
注意FR和NFR的区分。
二、需求分析
需求分析的四个步骤：
- 需求获取：从用户处得到N(Needs) 需求分析：从多方面考虑获取到的需求：
- 完整性：包括全部必要信息
- 正确性：各项需求准确无误，无歧义
- 合理性：各项需求之间，需求与系统之间无矛盾
- 可行性：技术，经济，社会等方面可行
- 充分性：需求是否全面，周到，是否还需添加需求
- 需求定义：编写《需求规格说明》SRS: Software Requirement Specification
- 需求验证：检验需求的完整性，非二义性，内外连贯性，需要用户参与
需求获取：
- 采访（传统方式）
- 设定情景：给出用例图
- 原型：获取不明确的用户需求
- 会议
- 观察（开发者以用户的身份）
需求分析：
- 结构化分析模型
- 面向对象分析模型
需求验证：通常以需求审查会议的形式进行。
SRS通过需求验证后，就成为基线（Baseline）被冻结起来。实际的需求是迭代的，是随着开发的过程不断演变的。
得到了基线后，开发过程中原需求进行了变更。这就是需求管理要解决的问题：
- 需求跟踪
- 需求变更控制：
三、结构化分析方法SA(Structured Analysis)
基本策略：自顶向下，逐步细化
核心：数据字典
围绕这个核心，有三种图：
- 数据流图（Data Flow Diagram, DFD）用于功能建模
- 实体-关系图（Entity-Relationship, E-R图）用于数据建模
- 状态转换图 （State Transition Diagram, STD）用于行为建模
功能建模：
数据流图：
环境图，又称顶层（0层）数据流图：仅包括一个【数据处理过程】，目的是确定系统在其环境中的位置。
数据建模：
与面向对象（OO）不同的是，SA只封装数据，不包含对数据的操作。
E-R图：
其中，圆角矩形表示属性，矩形表示实体，菱形表示关系名。关系也可以有属性。
行为建模：
一个状态图STD里，只能有一个初态，可以有0个或多个终态。
将功能建模，数据建模和行为建模黏合在一起的：数据字典：
- 定义式
- Warnier图
定义式中的符号：
加工规格说明：可以用文字， 数学公式，决策图，决策树等表示。说明每一个基本加工的规则。
决策表： 条件茬 条件项
动作茬 动作项
决策表可以合并（例如上表，2和4）。
决策树：
四、面向对象的分析方法OOA(Object-Oriented Analysis)
面向对象分析的模型有三个：
- 用例模型：用例图，是功能模型
- 对象模型：类图，用类和对象表示的静态模型
- 动态模型：状态图和交互图，表示的交互模型
面向对象分析使用最广泛的是UML(Unified Modeling Language)统一建模语言。由事物，关系和图组成。
普遍的做法是从建立用例模型开始：
用例图：
用例之间的关系有：泛化，包含，扩展。
泛化：查找书籍是父用例，精确查找和模糊查找是子用例。
包含：一个用例所执行的功能总是包括另一个用例的功能。箭头指向被包含的用例。
扩展：一个用例的执行需要由其它基础用例的功能来扩展。箭头指向基础用例。
其中，基础用例并不知道扩展用例的细节，仅为扩展用例提供扩展点。
include和extend的区别：
- 用例模型是从用户的角度描述对系统的需求。
- 用例的主要内容是书写用例规格说明，而不是画图。
对象模型：
- 划分主题：对于很小的系统，无需划分主题
- 确定类与对象：
- 实体类：系统将跟踪的持久信息
- 边界类：参与者与系统之间的交互
- 控制类：负责用例的实现
- 确定关联
- 关联的多重性：
- 关联类：当关联较简单时，关联关系的语义用名字来概括。关联较复杂时，可以建立关联类，用虚线连接关联类。
- 聚合：（特殊的关联），描述部分和整体的关系。用菱形表示，菱形在整体一边。
- 泛化：泛化类和特化类的关系，用空心三角形表示，三角形在泛化类一边。（泛化关系没有多重性，而关联关系有多重性）
- 关联的多重性：
- 确定属性
- 确定服务
类图示例：
动态模型：
交互图（包括顺序图，协作图）：
顺序图：
协作图：
顺序图的另一种表示形式。更适合涉及很多对象的情况。
状态图：
