第五章 理解需求
5.1需求工程
1.需求工程是（1）一个软件工程动作，开始于沟通活动并持续到建模活动（2）在设计和构建之间建立起联系的桥梁（3）是了解过程、项目、产品和人员的必须（4）是导致软件失败的关键问题。
2.需求工程的七个活动：起始、导出、精化、协商、规格说明、确认和管理。
5.2建立根基
1.确定利益相关者
2.识别多重观点
3.协同合作
4.首次提问
5.3导出需求
1.导出需求（又称为需求收集）是与问题求解、精化、协商和规格说明等方面的元素结合在一起的。
2.协作收集需求
3.导出工作产品
质量功能部署QFD
质量功能部署是一种将客户要求转化为软件技术需求的质量管理技术。
1.三种需求：（1）正常需求（2）期望需求（3）令人兴奋的需求
2.职能部署：确定系统所需的每个功能的“价值”（由客户感知）
3.价值分析：确定需求的相对优先级
5.4 开发用例
5.5 构建需求模型
1.分析模型：基于场景（活动图）、基于类（类图）、基于行为（状态图）、面向数据流（数据流图）
2.分析模式
5.6 协商需求
1.找到关键的利益相关者
2.确定每个利益相关者“win”的条件
3.协商，以便与所有涉及人双赢。
5.7 确认需求
需求管理
作用：identify,control,and track requirments and changes to requirements at any times.
可追溯性表
第六章 需求建模
6.1 需求分析
1.需求分析产生软件工作特征的规格说明，指明软件和其他系统元素的接口，规定软件必须满足的约束。
2.域分析：定义要调查的域；收集域中代表性的应用程序示例；分析示例中的每个应用程序；为对象开发分析模型
3.需求建模方法：结构化分析、面向对象的分析。分析模型结合两种分析方法
6.2 数据建模
客户级的抽象
1.数据对象：描述了数据对象及其所有属性
2.数据属性：定义了数据对象的性质
3.关系：数据对象可以以多种不同的方式与另一个数据对象连接。
4.ERD实体—关系图，表示数据对象及其关系。
5.DFD 控制流图
基于场景建模
1.描述一个使用线程的场景
2.用例/迭代/主要参与者/情景目标/前提条件/起动/场景/异常/视图快照/优先级/何时可用/使用频率/使用方法/次要参与者/次要参与者的使用方式/未解决的问题
开发活动图、泳道图
6.3基于类的建模
1.基于类的分析模型的元素包括类和对象、属性、操作、类的职责协作者（CRC）模型、协作图和包
2.通过检查问题语句来定义分析类
3.使用“语法解析”来隔离潜在类
4.标识每个类的属性
5.标识操作
6.实体类，也称作模型或业务类，是从问题说明中直接提取出来的。这些类一般代表保存在数据库中和贯穿应用程序的事物。
7.边界类用于创建用户可见的和在使用软件时交互的接口。设计边界类的职责是管理实体对象对用户的表示方式。
8.控制类自始至终管理”工作单元“。设计控制类可以管理（1）实体类的创建或更新（2）当边界类从实体对象获取信息后的实例化（3）对象集合间的复杂通信（4）对象间或用户和应用系统间交换数据的确认。
CRC建模
1.类—职责—协作者建模可以识别和组织与系统或产品需求相关的类。
2.事实上，CRC模型可以使用真的或虚拟的索引卡，意图是开发有组织表示的类。职责是和类相关的属性和操作。协作者是提供完成某个职责所需要信息的类。通常，协作意味着信息请求或某个动作请求。
3.职责：（1）智能系统应分布在所有类中以求最佳地满足问题的需求（2）每个职责的说明应尽可能具有普遍性（3）信息和与之相关的行为应放在同一个类中（4）某个事物的信息应局限于一个类中而不要分布在多个类中（5）适合时，职责应由相关类共享。
4.协作：类实现其职责：（1）类可以使用其自身的操作控制各自的属性，从而实现特定的职责；或者（2）一个类可以和其他类的协作。
5.类之间的泛型关系：（1）is-part-of关系，聚合（2）has-knowledge-of关系，关联，表示多样性（3）depends-upon关系，依赖
6.分析包：将分析模型的各种元素以一种方式分类，分组打包后称其为分析包，并取一个有代表性的名。（+、-、#）