5.1 软件工程定义
软件工程由方法、工具和过程3个部分组成。
方法： 完成软件项目的技术手段，支持整个软件生命周期
工具： 是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成
过程： 贯穿于软件开发的各个环节
5.2 软件需求
5.2.1 需求的层次
需求是多层次 的，包括业务需求，用户需求，系统需求
| 需求名称 | 描述 |
|---|---|
| 业务需求 | 指反映组织机构或用户对系统、产品高层次的目标要求 |
| 用户需求 | 描述的是用户的具体目标 |
| 系统需求 | 从系统的角度 来说明软件的需求，包括功能需求、非功能需求和约束等 |
5.2.2 质量功能部署
质量功能部署(Quality Function Deployment,QFD)，即通过多种角度对产品的特点进行描述，从而反映产品功能，是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标。
QFD将软件需求分为3类,分别是常规需求、期望需求和意外需求
| 需求名称 | 描述 |
|---|---|
| 常规需求 | 用户认为系统应该做到的功能或性能,实现得越多，用户会越满意 |
| 期望需求 | 用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意 |
| 意外需求 | 也称为兴奋需求 ，是用户要求范围外 的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)，实现这些需求用户会更高兴，但不实现也不影响其购买的决策 |
5.2.3 需求获取
常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等
5.2.4 需求分析
在需求获取阶段获得的需求是杂乱的 。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。需求分析的关键在于对问题域的研究与理解。
1.结构化分析
其建立模型的核心是数据字典。围绕这个核心，有三个层次的模型：
使用实体关系图（E-R图）表示数据模型
用数据流图（DFD）表示功能模型
用状态转换图（STD）表示行为模型
DFD需求建模方法
DFD需求建模方法也称为过程建模和功能建模方法。 DFD建模方法的核心是数据流，从应用系统的数据流着手，以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。
DFD方法由以下4种基本元素（模型对象）组成：数据流，处理/加工，数据存储和外部项
建立DFD图的目的是描述系统的功能需求。
数据字典的应用
数据字典(Data Dictionary)是一种用户可以访问的记录数据库和应用程序元数据的目录。
数据字典最重要的作用是作为分析阶段的工具。
任何字典最重要的用途都是供人查询，在结构化分析中，数据字典的作用是给数据流图上的每个元素加以定义和说明。
数据字典主要包括数据项、数据结构、数据流、数据存储、处理过程等几个部分。
2.面向对象分析
针对oo方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。
OOA模型由 5个层次（主题层、对象类层、结构层、属性层和服务层) 和 5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。
在这种方法中定义了两种对象类之间的结构，分别是分类结构和组装结构。
OOA的基本原则：
| 基本原则 | 描述 |
|---|---|
| 抽象 | 抽取共同的，本质性的特征 |
| 封装 | 尽可能隐蔽对象的内部细节 |
| 继承 | 特殊类的对象拥有其对应的一般类的全部属性与服务 |
| 分类 | 把具有相同属性和服务的对象划分为一类 |
| 聚合 | 把一个复杂的事物看成若干比较简单事物的组装体 |
| 关联 | 通过一个事物联想到另外的事物 |
| 消息通信 | 对象之间只能通过消息进行通信 |
| 粒度控制 | 注意其大的组成部分，暂时不考虑具体的细节 |
| 行为分析 | 各种行为往往相互依赖，相互交织 |
OOA的基本步骤: 大致遵循如下5个基本步骤:
1.确定对象和类
2.确定结构
3.确定主题
4.确定属性
5.确定方法
5.2.5 需求规格说明书
软件需求规格说明书(Software Requirement Specification, SRS)是在需求分析阶段需要完成的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。
SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。
SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。
一般通过需求评审和需求测试工作来对需求进行验证。
5.2.6 需求变更
1) 变更控制过程
一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。
需求变更控制过程： 问题分析和变更描述，变更分析和成本计算，变更实现
2) 变更策略
常见的需求变更策略主要包括:
·所有需求变更必须遵循变更控制过程
·对于未获得批准的变更，不应该做设计和实现工作
·应该由项目变更控制委员会决定实现哪些变更
·项目风险承担者应该能够了解变更的内容
·绝不能从项目配置库中删除或者修改变更请求的原始文档
·每一个集成的需求变更必须能跟踪到一个经核准的变更请求
3) 变更控制委员会
变更控制委员会（Change Control Board, CCB）是项目所有者权益代表，负责裁定接受哪些变更。
CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。
CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
过程及操作步骤主要包括制定决策、交流情况和重新协商约定等。
5.2.7 需求跟踪
需求跟踪有正向跟踪和逆向跟踪两种方式。
不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（表格)。
PS: 更多关于 系统集成项目管理工程师笔记 点击专栏订阅(持续更新~~~)