一、需求工程 00:03
1. 软件需求 00:45
- 定义：用户对系统在功能、行为、性能、设计约束等方面的期望，是解决问题或达到目标所需的条件或能力。
- 两大过程：
- 需求开发：包括获取→分析→定义（需求规格说明书）→验证
- 需求管理：包括基线→变更控制→版本控制→需求跟踪→状态跟踪
1）需求的分类 04:36
- 业务需求 04:52
- 特征：反映企业/客户高层次目标要求，由非技术人员（投资人/市场部门等）提出
- 示例：在线教育网站需要题库功能
- 抽象层次：最高，不涉及具体实现
- 用户需求 06:33
- 特征：描述用户具体目标或任务，通过访谈/问卷获取
- 示例：用户需要在手机和电脑上刷题
- 抽象层次：中等，比业务需求更具体
- 系统需求 07:03
- 功能需求 07:22
- 特征：开发人员必须实现的具体功能
- 示例：财务系统每月15号自动发工资
- 判断技巧：一句话描述功能
- 非功能需求 07:47
- 特征：系统必须具备的属性，包括：
- 性能需求（带数字，如响应时间≤1秒）
- 质量属性（可维护性、可靠性等）
- 记忆点：非功能=非具体功能描述
- 特征：系统必须具备的属性，包括：
- 设计约束 09:01
- 特征：外部强制规定的限制条件
- 示例：必须使用国产数据库、金钱精度保留2位小数
- 判断技巧：人为规定且与系统特性无关
- 功能需求 07:22
2）应用案例 09:51
- 例题:软件需求开发定义阶段
- 题目解析
- 关键对应关系：获取情况=需求获取，编写文档=需求定义（规格说明书）
- 排除法：B/C/D属于需求管理阶段
- 答案：A.制订规格说明
- 题目解析
- 例题:需求分类判断 11:17
- 解题技巧：
- 排除性能需求（无数字指标）
- 三问答案必不同（业务/用户/功能维度）
- 抽象层次分析：
- "用户能纠正错误"→业务需求（最高层）
- "找出错误并提供替换"→用户需求（中层）
- "显示替换对话框"→功能需求（最具体）
- 答案：C→C→B
- 解题技巧：
2. 需求获取 16:42
1）需求获取定义 16:58
- 本质：确定和理解项目干系人的需求和约束
- 重要性：直接影响后续开发质量
2）需求获取法 17:07
- 用户访谈：
- 形式：1对1至1对3
- 优点：深度精准
- 缺点：需领域知识，记录困难
- 问卷调查：
- 适用：用户量大时
- 缺点：信息杂乱
- 采样：
- 原理：数理统计（公式：样本量=0.25*(可信度因子/错误率)^2）
- 情节串联板：
- 形式：系列图片讲故事
- 缺点：耗时
- 联合需求计划(JRP)：
- 本质：多方参与的正式会议
- 需求记录技术：
- 工具：任务卡片、用户故事等
3）应用案例 21:50
- 例题:需求获取方法
- 题目解析：
- 第一空特征：灵活但记录困难→用户访谈(A)
- 第二空关键词：数理统计→采样(D)
- 第三空描述：群体会议→JRP©
- 答案：A→D→C
二、需求分析 23:17
1. 需求特性 23:50
- 无二义性：需求描述必须明确，避免歧义（如"快速响应"需量化成"响应时间≤2秒"）
- 完整性：需覆盖所有功能和非功能需求（包括异常场景）
- 可测试性：需求应可验证（如"系统支持1000并发用户"可通过压力测试验证）
2. 分析任务 24:12
- 上下文范围图：界定系统边界（如ATM机的"取款"功能不包含钞票印刷）
- 原型设计：低保真原型验证核心流程（如电商平台的结账流程原型）
- 可行性分析：技术可行性（如刷脸支付需评估摄像头精度）、经济可行性（开发预算≤50万）
3. 结构化分析 25:18
1）三大模型 25:59
- 功能模型：数据流图DFD（描述"订单处理"从创建到完成的流转）
- 行为模型：状态转换图STD（如订单状态：待支付→已支付→已发货）
- 数据模型：E-R图（客户与订单的1:N关系）
2）数据流图 26:42
- 基本元素 26:54
- 加工：圆角矩形表示（如"计算运费"加工）
- 数据存储：双杠或开口矩形（如"用户数据库"）
- 黑洞错误：只有输入无输出（如系统接收请求但无响应）
- 奇迹错误：无输入却有输出（如凭空生成报表）
3）分层DFD 32:30
- 顶层图：系统与外部实体的交互（如考生提交报名单）
- 平衡原则：父图与子图的输入/输出必须一致（顶层输入"报名单"→0层也必须包含）
4）数据字典 35:36
- 组成符号：
- +：顺序连接（如姓名=姓+名）
-
\|\]：选择（如支付方式=\[现金\|信用卡\|微信\]）
4. 需求定义 38:58
- 严格定义：适用于需求明确场景（如银行利息计算公式）
- 原型法：适用于模糊需求（通过低保真原型逐步确认UI布局）
5. 需求验证 40:41
- 需求评审：交叉检查SRS文档（如验证"搜索响应时间≤1秒"是否写入）
- 需求基线：签字确认后的需求变更需走正式流程（如新增需求需评估工期影响）
注：所有图形符号均按最新ISO/IEC 24744标准规范绘制，数据流图中加工编号采用"子系统.模块.功能"三级编号法（如3.1.2表示第3子系统第1模块的第2功能）
三、需求管理 42:12
1. 定义需求基线 42:20
- 基线概念：通过评审的需求说明书即成为需求基线，此时需求进入受控状态
- 变更要求：基线确立后如需变更，必须严格按照变更流程执行
- 状态图示：展示需求从提出到交付的全生命周期状态变化
2. 需求变更流程 43:26
- 完整流程：
- 提出变更请求
- PM和团队评估影响（成本/进度等）
- 通知相关干系人评估结果
- 提交CCB（变更控制委员会）审批
- 执行变更
- 验证变更结果
- 流程特点：
- 步骤可简化但顺序不可逆
- CCB由具有决策权的相关人员组成（项目经理/客户代表等）
- 变更风险：
- 用户参与不足
- 需求分类遗漏
- 需求范围蔓延
- 需求描述模糊
3. 需求跟踪 47:46
- 正向跟踪：
- 检查用户原始需求是否完整转化为需求文档
- 验证需求文档内容是否全部实现
- 发现"需求遗漏"问题
- 反向跟踪：
- 确认产品功能是否严格对应需求
- 检查是否存在"多余实现"
- 采用需求跟踪矩阵进行验证
- 矩阵应用：
- 行无对勾：需求未实现（正向问题）
- 列无对勾：存在多余功能（反向问题）
四、应用案例 50:59
1. 例题：需求管理说法
- 题目解析：
- A选项：CMM二级实际包含6个关键过程域
- B选项：稳定性是重要需求属性
- C选项：正确顺序应为变更描述→影响分析→实现
- D选项：CCB确实拥有基线变更决策权
- 正确答案：D
2. 例题：数据流图应用 53:42
- 题目解析：
- 数据流图本质描述功能模型（B正确）
- 图书馆系统中"读者"是典型外部实体（A正确）
- 易错点：容易混淆数据流图与ER图的功能区别
五、知识小结
| 知识点 | 核心内容 | 考试重点/易混淆点 | 难度系数 |
|---|---|---|---|
| 需求工程概念 | 需求获取→需求分析→需求定义→需求验证的完整流程 | 需求基线形成时机（需求验证后）混淆点：需求验证≠需求评审 | ★★★ |
| 需求分类体系 | 业务需求（战略层）→用户需求（场景层）→系统需求（技术层）系统需求细分为：功能/非功能/设计约束 | 易错题："纠正拼写错误"属于用户需求"显示替换对话框"属于功能需求 | ★★★★ |
| 结构化分析方法 | 数据流图（功能模型）状态转换图（行为模型）ER图（数据模型） | 关键考点：数据流必须经过加工黑洞/奇迹/灰洞错误判断 | ★★★★★ |
| 需求获取技术 | 用户访谈（深度精准）问卷调查（广度覆盖）联合需求计划（多方协同） | 对比记忆：采样方法=数理统计应用情节串联板=可视化故事呈现 | ★★★ |
| 需求变更控制 | 变更请求→影响分析→CCB审批→执行变更→验证结果 | 典型错误：跳过影响分析直接审批未经验证即交付 | ★★★★ |
| 需求跟踪矩阵 | 正向跟踪（需求覆盖率）反向跟踪（功能必要性） | 特殊规则：外部实体不进入数据字典 | ★★★ |
| 需求文档标准 | 需求规格说明书必须包含：功能/非功能/设计约束说明 | 致命缺陷：需求条目无唯一标识符 | ★★ |