夜雨聆风一、软件工程定义（了解）
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。
软件工程由三部分组成：
组成 | 描述 |
|---|---|
方法 | 完成软件项目的技术手段，支持整个软件生命周期 |
工具 | 人们在开发软件活动中智力和体力的扩展与延伸，自动或半自动支持软件开发和管理，支持各种软件文档生成 |
过程 | 贯穿于软件开发的各个环节，指为获得软件产品，在软件工具支持下由软件工程师完成的一系列软件工程活动。管理人员要对软件开发的质量、进度、成本进行评估、管理和控制 |
二、软件需求（掌握）
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。根据IEEE标准，软件需求是用户解决问题或达到目标所需的条件或能力，以及反映这些条件或能力的文档说明。
1. 需求的三个层次（掌握）
层次 | 描述 |
|---|---|
业务需求 | 反映组织机构或用户对系统、产品高层次的目标要求，从总体上描述为什么要达到某种效应，组织希望达到什么目标。通常来自项目投资人、客户管理人员、市场营销部门等 |
用户需求 | 描述用户的具体目标，或用户要求系统必须能完成的任务和想要达到的结果，构成用户原始需求文档的内容 |
系统需求 | 从系统角度说明软件需求，包括功能需求、非功能需求和约束 |
2. 质量功能部署QFD（掌握）
QFD是将用户要求转化成软件需求的技术，目的是最大限度提升用户满意度。将软件需求分为3类：
需求类型 | 描述 |
|---|---|
常规需求 | 用户认为系统应该做到的功能或性能，实现越多用户越满意 |
期望需求 | 用户想当然认为系统应具备的功能或性能，但并不能正确描述。若未实现，用户会不满意 |
意外需求（兴奋需求） | 用户要求范围外的功能或性能，实现后用户更高兴，但不实现也不影响购买决策 |
3. 需求获取（掌握）
常见需求获取方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
4. 需求分析（掌握）
一个好的需求应具有：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。
（1）结构化分析（SA）
核心是数据字典，围绕它有3个层次的模型：
图形 | 表示模型 | 说明 |
|---|---|---|
实体关系图（E-R图） | 数据模型 | 描述实体、属性及实体之间的关系 |
数据流图（DFD） | 功能模型 | 从数据传递和加工角度，逐层细分描述系统功能 |
状态转换图（STD） | 行为模型 | 描述系统状态及引起状态转换的事件 |
数据流图DFD示例图
结构化分析步骤：
分析业务情况，做出当前物理模型的DFD
推导出等价的逻辑模型的DFD
设计新的逻辑系统，生成数据字典和基元描述
建立人机接口，提出目标系统物理模型的DFD
确定各种方案的成本和风险等级
选择一种方案
建立完整的需求规约
数据字典：对数据流图上每个元素加以定义和说明，包括数据项、数据结构、数据流、数据存储、处理过程。
数据字典示例表
（2）面向对象分析（OOA）
OOA模型由5个层次（主题层、对象类层、结构层、属性层、服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。
OOA基本原则（9个）：
序号 | 原则 | 描述 |
|---|---|---|
(1) | 抽象 | 舍弃个别、非本质特征，抽取共同、本质特征 |
(2) | 封装 | 把对象的属性和服务结合为不可分的系统单位，隐藏内部细节 |
(3) | 继承 | 特殊类的对象拥有一般类的全部属性与服务 |
(4) | 分类 | 把具有相同属性和服务的对象划分为一类 |
(5) | 聚合（组装） | 把复杂事物看成若干简单事物的组装体 |
(6) | 关联 | 通过一个事物联想到另外的事物 |
(7) | 消息通信 | 对象之间只能通过消息进行通信 |
(8) | 粒度控制 | 考虑全局时忽略细节，考虑细节时撇开其余部分 |
(9) | 行为分析 | 处理复杂行为相互依赖、相互交织的问题 |
📌 记忆口诀：抽封继分聚，关消粒行（抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析）
OOA基本步骤：
确定对象和类
确定结构
确定主题
确定属性
确定方法
5. 需求规格说明书SRS（掌握）
SRS是需求分析阶段完成的文档，是软件需求分析的最终结果。应包括：范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。通过需求评审和需求测试进行验证。
6. 需求变更（掌握）
变更控制过程：问题分析和变更描述 → 变更分析和成本计算 → 变更实现。
变更策略：
所有需求变更必须遵循变更控制过程
未获批准不应做设计和实现
由项目变更控制委员会（CCB）决定实现哪些变更
项目风险承担者应了解变更内容
绝不能从配置库中删除或修改变更请求原始文档
每个集成的需求变更必须能跟踪到一个经核准的变更请求
变更控制委员会CCB：项目所有者权益代表，负责裁定接受哪些变更，是决策机构不是作业机构。成员可包括产品/计划管理、项目管理、开发、测试、市场、用户文档、技术支持、配置管理等代表。
制定决策、交流情况、重新协商约定。
7. 需求跟踪（掌握）
需求跟踪建立与维护“需求—设计—编程—测试”之间的一致性。
跟踪方式 | 描述 |
|---|---|
正向跟踪 | 检查SRS中每个需求是否都能在后继工作成果中找到对应 |
逆向跟踪 | 检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处 |
两者合称双向跟踪。通过需求跟踪矩阵（表格）保存对应关系。
三、本章真题小测
Q1：（）不是软件需求的常用层次。
A. 业务需求 B. 数据需求 C. 用户需求 D. 系统需求
Q2：（）不属于软件需求规格说明书的内容。
A. 业务功能 B. 应用系统性能 C. 交互界面 D. 算法的详细过程
Q3：以下软件需求变更策略中，不正确的是：（）。
A. 所有需求变更必须遵循变更控制过程
B. 对于未获得批准的变更，不应该做设计和实现工作
C. 应该由项目经理决定实现哪些变更
D. 项目风险承担者应该能够了解变更的内容
📩 答案：
Q1答案：B 解析：
软件需求经典三层划分是业务需求、用户需求、系统需求，数据需求属于系统需求下的细分内容，不属于独立的需求层次。
Q2答案：D 解析：
软件需求规格说明书侧重描述要实现的业务功能、性能指标、界面交互等对外需求；算法详细过程属于底层设计阶段的内容，不写入需求规格说明书。
Q3答案：C 解析：
需求变更不能由项目经理单独决定，需要走完整变更评审流程，由变更控制委员会（CCB）审批裁定是否采纳变更，其余 A、B、D 均是规范的变更管控原则。
✅汇总答案
Q1：B；Q2：D；Q3：C