5.2 软件需求

一句话讲明白

需求就是"把用户脑子里那团模糊的愿望，翻译成开发团队能照着干、验收时能对照查的书面约定"。

生活类比

装修房子时，三种话对应三种需求：

• 业主说"我要住得舒服、房子要保值" → 业务需求（老板视角，为什么要做）
• 业主说"厨房要能两个人同时备餐、早上不抢厕所" → 用户需求（用户视角，能用它干什么）
• 设计师写成"厨房净面积 ≥8㎡、插座 12 个（含 4 个五孔带开关）、防水上翻 1.8 米、必须用某品牌水管" → 系统需求（功能 + 非功能 + 约束）

至于业主没说但一看到就惊喜的"中岛下面藏个洗碗机" → 意外（兴奋）需求。

正经定义

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。按 IEEE 标准：需求是用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所具有的条件或能力，以及反映这些条件或能力的文档说明。

拆解与流程

一、需求的三个层次（从目标到细节）

系统需求 = 功能需求（也称行为需求）+ 非功能需求 + 约束：

• 功能需求：开发人员必须在系统中实现的软件功能，常通过"特性"（一组逻辑上相关的功能需求）描述。
• 非功能需求：系统必须具备的属性或品质，可细分为软件质量属性（易用性、可维护性、效率等）和其他非功能需求。
• 约束：对设计和构造上的限制，如设计约束、过程约束（"必须用自主知识产权数据库""必须运行在开源操作系统之上"）。

二、质量功能部署 QFD（三类需求）

QFD 是一种将用户要求转化成软件需求的技术，目的是最大限度提升用户满意度。

意外需求控制在开发人员手中：可以做更多意外需求换高满意度和高忠诚度，也可以出于成本/周期考虑一个都不做。

三、需求获取

需求获取是确定和理解不同项目干系人对系统的需求和约束的过程，"看着简单、做起来很难"——用户往往给不出完整正确的原始需求。

常见方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划（JRP）。

四、需求分析

获取到的需求是杂乱、有重复、有矛盾的，不能直接做设计依据。好的需求应具备：无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性。

1）结构化分析 SA：核心是数据字典，围绕它有三层模型：

DFD 四种基本元素：数据流（箭头）、处理/加工（矩形框）、数据存储、外部项（数据源/数据终点，圆角框或平行四边形）。建模步骤：明确目标确定范围 → 建立顶层 DFD → 构建第一层分解图 → 开发 DFD 层次结构图 → 检查确认（父图出现的数据流必须在子图中出现；一个处理至少有一个输入流和一个输出流；一个存储必定有流入和流出的数据流；一个数据流至少有一端是处理端）。

数据字典：对数据项、数据结构、数据流、数据存储、处理逻辑进行定义和描述，是分析阶段的工具，最主要作用是给 DFD 上每个元素加以定义和说明。

2）面向对象分析 OOA：模型由 5 个层次（主题层、对象类层、结构层、属性层、服务层）和 5 个活动（标识对象类、标识结构、定义主题、定义属性、定义服务）组成。基本原则：抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析。两种对象类结构：分类结构（一般与特殊）、组装结构（整体与部分）。

建模语言 UML 的图与视图是画图工具，详见 5.3 软件设计。

五、需求规格说明书 SRS

SRS 是需求分析阶段的最终结果，是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应缺少。按 GB/T 8567，SRS 包括 8 部分：范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解、附录（另 GB/T 9385 给出详细写作大纲）。

需求验证（需求确认）：通过需求评审和需求测试验证 SRS 正确性——系统分析阶段发现并修复错误最省钱。

六、需求变更

变更已成常态（获取不完整、理解有误差、业务变化），但无控制的变更会让项目陷入混乱。一旦确定需求基线，所有建议的变更都必须遵循变更控制过程：

• 变更策略：所有变更必须遵循变更控制过程；未获批准的变更不得做设计和实现；由变更控制委员会（CCB）决定实现哪些变更（教材明确：不是项目经理）；风险承担者应了解变更内容；绝不能删除或修改变更请求的原始文档；每个集成的需求变更必须能跟踪到一个经核准的变更请求。
• CCB：项目所有者权益代表，由多方成员共同组成（产品/计划管理、项目管理、开发、测试或质量保证、市场或客户代表、用户文档、技术支持、用户服务支持、配置管理等），是决策机构不是作业机构——只裁定接不接受，不提变更方案。

七、需求跟踪

目的是建立与维护"需求—设计—编程—测试"之间的一致性。

• 正向跟踪：检查 SRS 中每个需求是否都能在后继工作成果中找到对应点。
• 逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在 SRS 中找到出处。
• 两者合称双向跟踪；载体是需求跟踪矩阵（RTM），保存需求与后继工作成果的对应关系。

考试怎么考

• 题型：选择题高频；案例题常问"该项目在需求管理上存在哪些问题 / 应如何改进"。
• 教材原题：
• 哪项不是软件需求的常用层次 → 数据需求（选 B，正确层次是业务/用户/系统需求）
• 哪项不属于 SRS 的内容 → 算法的详细过程（选 D，那是设计阶段的事）
• 哪项变更策略不正确 → "应该由项目经理决定实现哪些变更"（选 C，应为 CCB）
• 陷阱词：把"期望需求"说成"用户明确提出的需求"（错，是用户想当然却描述不清的）；把"意外需求"说成"不做用户会不满意"（错，不做也不影响购买决策）；把 CCB 说成"提出变更方案的机构"（错，CCB 只裁定）。
• 必背：SA 三模型对应图、DFD 四元素、QFD 三类、SRS 八部分、跟踪矩阵。

易混辨析

一秒记忆

"业务说为什么，用户说做什么，系统说怎么定；常规该有、期望不说也有、意外是彩蛋。SRS 八块砖，变更找 CCB，跟踪双向加矩阵。"

相关

• 5.3 软件设计
• 5.1 软件工程定义
• 11.3 收集需求
• 15.3 变更管理
• 05-软件工程