需求规格说明、验证与管理

发表于 2025-12-25 Waline：阅读次数：本文字数： 2.9k 阅读时长 ≈ 10 分钟

需求规格说明

需求工程包含三个递进阶段：需求获取收集用户原始需求信息，需求分析深入理解并界定解决方案准则，需求规格说明则将需求及其解决方案准确地文档化。

规格说明文档的作用

需求规格说明文档（SRS）是连接需求开发与后续工作的核心桥梁：

作为合同协议的重要组成部分，明确各方责任
拓展人类记忆能力，避免需求信息遗失
作为设计、实现、测试等开发活动的基准依据
通过早期发现需求错误，减少返工和项目成本
形成可复用的智力资产，支持新人培训、客户服务及后续项目

写好规格说明文档的两个关键

模板裁剪：选择合适的标准模板并根据项目特点定制
写作技巧：运用清晰、准确的表达方式。

模板的选择与裁剪

优秀文档的产生遵循一个层次化的过程：

flowchart LR
    A["📄 标准模板<br>（IEEE 830）"] 
    B["🏢 组织模板<br>（内部规范）"]
    C["🚀 项目模板<br>（具体场景）"]
    D["✅ 项目 SRS 文档<br>（最终交付）"]
    
    A -- "裁剪定制" --> B
    B -- "裁剪定制" --> C
    C -- "内容写作" --> D
    
    style A fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
    style B fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style C fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px
    style D fill:#fff3e0,stroke:#ef6c00,stroke-width:3px

IEEE 830 标准提供了一个经典的 SRS 模板框架：

章节	主要内容
1. 引言	目的、范围、术语定义、参考文献、文档组织
2. 总体描述	产品前景、产品功能、用户特征、约束、假设和依赖
3. 详细需求	对外接口、功能需求、性能需求、约束、质量属性

详细需求部分的组织方式可根据项目特点灵活选择：

按系统特性：适用于功能模块清晰的系统
按操作模式：适用于有明显工作状态切换的系统
按用户类：适用于不同用户角色需求差异大的系统
按刺激因素（状态图）：适用于事件驱动的嵌入式或实时系统
按类/对象（OO）：适用于面向对象设计的系统
按数据流（结构化 DFD）：适用于数据处理密集型系统

文档写作技巧

结构组织原则

内容位置得当：借鉴标准模板，确保读者能快速定位信息
引用而非重复：相同内容只在一处详述，其他位置通过引用指向；必要时可用「强化」而非「复制」来提醒读者关键信息

表达方式选择

根据内容特点选择合适的表达形式：

使用相同的语句格式描述同类需求，保持一致性
使用列表或表格组织并列、独立的信息项
使用编号表达顺序、嵌套或层次关系
复杂逻辑可借助流程图、状态图等可视化手段

细节描述要点

定义术语表或数据字典：消除术语不一致、「方言」问题和错误/冗余术语。

避免干扰文本：删除「这一段的意思是…」「众所周知…」等无实质内容的表述。

避免歧义词汇：

歧义词汇	改进方法
可接受的、足够的	具体定义可接受的标准，说明系统如何判断
大概可行的	标记为 TBD 问题并注明解决日期
至少、最多、不超过	明确指定可接受的最大值和最小值
在…之间	明确端点是否包含在范围内
快的、迅速的	明确时间或速度的可接受最小值
灵活的	描述系统响应变化的具体变更方式
包括、等等、诸如	列举所有可能性，否则无法设计和测试
用户友好的、简单的	描述具体的系统特性来体现这些期望

优秀 SRS 文档的特性

四大核心特性

完备性、一致性、可修改性、可跟踪性

完备性要求：

描述所有有意义的需求（功能、性能、约束、质量属性、接口）
定义系统对所有输入（有效和无效）的响应
为所有图表、术语提供完整引用
明确标识 TBD（待确定）问题及解决日期

一致性要求：

细节需求不与高层需求冲突
同层次需求之间不互相矛盾
建立需求优先级，便于冲突时决策

可修改性要求：

条理分明的组织方式（目录、索引、交叉引用）
无重复冗余
每个需求独立表达

可跟踪性要求：

前向跟踪：能找到需求的来源（业务需求、用户需求）
后向跟踪：能找到需求对应的设计、代码和测试用例
每个需求有唯一标识符

需求验证

验证的概念与时机

验证活动贯穿需求工程全过程，但需求验证特指在需求规格说明文档完成后，对其进行的专门验证活动。

验证关注的核心问题：

文档是否组织良好、书写正确？
需求是否充分、正确地反映了涉众意图？
文档能否作为后续开发工作的可靠基础？

flowchart LR
    A[📄 软件需求规格说明文档] --> B{🔍 执行验证}
    B --> C{❓ 发现问题?}
    C -->|✅ 是| D[🛠️ 问题修正]
    D --> E[📝 修改后的文档]
    E --> B
    C -->|❌ 否| F[🎉 验证通过]

    style A fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    style B fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    style C fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#e65100
    style D fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px,color:#1b5e20
    style E fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    style F fill:#fce4ec,stroke:#880e4f,stroke-width:2px,color:#880e4f

需求验证方法

评审（Review）

评审是由作者之外的人员检查产品问题的主要静态分析手段，原则上每条需求都应经过评审。

评审过程：规划 → 总体部署 → 准备 → 审查会议 → 返工 → 跟踪

评审人员构成：组长、作者、用户代表、领域专家、技术人员、记录人员、观察员

检查方法：

方法	描述
自由方法	无系统化引导
检查清单	以通用清单引导检查
缺陷方法	根据缺陷分类组织检查场景
视角方法	按不同涉众视角组织检查
场景方法	用问题序列引导检查（缺陷、功能点、视角都是其特例）

评审类型（按正式程度递减）：审查 → 小组评审 → 走查 → 轮查 → 同级桌查 → 临时评审

原型与模拟

适用于涉及复杂动态行为的需求验证，成本较高。

过程：规划 → 建立原型 → 定义验证场景 → 执行场景 → 记录问题 → 迭代改进

开发测试用例

核心思想：如果无法为某条需求定义完备的测试用例，该需求可能存在模糊、遗漏或错误。

例外情况：

排斥性需求：要求特定行为绝不发生（如「系统故障不能导致数据库崩溃」）
全局性非功能需求：如可靠性、可用性，需大数据集测试

用户手册编制

通过编写用户手册来验证：

功能需求（功能描述）
项目范围（未实现功能说明）
异常流程需求（问题解决指南）
环境与约束需求（安装启动说明）

利用跟踪关系

前向验证：检查每个业务需求和用户需求是否都有对应的系统需求支持（发现不完备）
后向验证：检查每个系统需求是否都能追溯到用户需求和业务需求（发现非必要需求）

自动化分析

利用形式化方法或工具（如大模型生成测试断言）对需求进行自动检查。

问题修正

问题类型	修正方法
需求澄清（理解偏差、分析遗漏、表达不当）	重新分析或重新表达
缺失需求	重新执行需求获取等工作
需求冲突	协商解决
不切实际的期望	项目调整与需求协商

需求管理

需求管理的意图与作用

需求的影响力贯穿整个产品生命周期，而非仅限于需求开发阶段。需求管理的目标是在需求开发之后保证需求作用的有效发挥。

需求管理的价值：

增强对复杂需求细节和依赖关系的理解
增进涉众之间的交流，减少误解
有效处理变更，减少返工，提高生产力
准确反映项目状态，支持更好的决策
建立重视需求的项目文化

需求管理的核心任务

flowchart TB
    subgraph 需求管理
        A[维护需求基线]
        B[实现需求跟踪]
        C[控制变更]
    end

    A --> D[交流涉众需要]
    A --> E[驱动设计实现]
    B --> F[测试验证产品]
    B --> G[辅助项目管理]
    C --> H[控制迭代开发中的变化]

    %% 样式定义
    classDef core fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b,font-weight:bold
    classDef task fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    classDef arrow stroke:#ff9800,stroke-width:2px

    %% 应用样式
    class A,B,C core
    class D,E,F,G,H task
    linkStyle 0,1,2,3,4 stroke:#ff9800,stroke-width:2px

需求基线

需求基线是已通过正式评审和批准的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合。只有通过正式的变更控制过程才能修改它。

需求基线将「不同的需求看法」和「总是处于变化中」的状态，转变为「共同的需求理解」和「纳入配置管理的文档」。

基线描述内容：

属性	作用
标识符（ID）	提供共同的交流参照
版本号	确保工作基于最新一致的需求
源头	支持需求回溯
理由	提供背景知识
优先级	指导工作安排
状态	交流项目工作状况
成本/工作量/风险/可变性	驱动设计实现

基线维护活动：

配置管理：

标识配置项（递增数值、层次式编码、层次式命名）
版本控制（单条需求和文档都需要）
变更控制
访问审计
状态报告

状态维护：

状态	定义
已提议	需求已被提出
已批准	需求已分析、评估影响、分配到基线、获得承诺
已实现	设计和实现已完成
已验证	功能实现正确性已确认
已删除	已批准的需求被取消（需说明原因）
已否决	需求被提议但不在下一版本实现（需说明原因）

需求跟踪

需求跟踪的目的是避免开发或演化过程中与需求基线不一致或偏离。

flowchart LR
    A[涉众需要/目标]
    B[软件需求<br/>SRS]
    C[后续开发物件<br/>设计 / 代码 / 测试]

    A <-->|前向跟踪<br/><font size=2>（需求定义之前）| B
    B <-->|后向跟踪<br/><font size=2>（需求定义之后）| C

    style A fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    style B fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    style C fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px,color:#1b5e20
    linkStyle 0,1 stroke:#78909c,stroke-width:2px

前向跟踪（需求定义之前）：

向前跟踪到需求：涉众需要产生了哪些软件需求
从需求向后回溯：软件需求来源于哪些涉众需要

后向跟踪（需求定义之后）：

从需求向前跟踪：软件需求如何被设计、代码、测试支持
回溯到需求：开发物件因什么需求而产生

实现方法：跟踪矩阵、实体关系模型、交叉引用

需求变更控制

需求变化是正当且不可避免的，原因包括：问题或环境变化、基线存在缺陷、用户变动、用户认识变化、相关产品出现等。

变更控制过程：

flowchart LR
    A[提请者<br/>提请变更] --> B[接收者<br/>接受请求]
    B --> C[评估者<br/>变更评估]
    C --> D{CCB<br/>变更决策}
    D -->|批准| E[修改者<br/>执行变更]
    D -->|拒绝| F(结束)
    E --> G[验证者<br/>验证变更]

    style A fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#e65100
    style B fill:#fce4ec,stroke:#880e4f,stroke-width:2px,color:#880e4f
    style C fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px,color:#1b5e20
    style D fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    style E fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    style G fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#e65100
    style F fill:#f5f5f5,stroke:#9e9e9e,stroke-width:2px,color:#616161

    linkStyle default stroke:#78909c,stroke-width:2px

变更控制委员会（CCB）：评价需求变更，做出批准或拒绝决定，确保已批准变化的实现。成员可能来自：项目管理、产品管理/需求分析、开发、测试/QA、市场/客户代表、文档、技术支持、配置管理等部门。

变更控制注意事项：

认识变更必要性并制定计划
- 定义明确的变更控制过程
- 所有变更请求都要仔细评估
- 变更决定由 CCB 统一做出
- 变更结果必须验证
- 变化情况及时通知受影响的涉众
维护需求基线，审计变更记录
管理范围蔓延：根据业务目标、产品前景和项目范围评估每项新增需求
灵活应对变更请求：
- 推迟交付时间
- 增派人手（有限情况下有效）
- 适度加班
- 推迟或去除低优先级需求
- 降低质量（尽量不用）
使用辅助工具：支持变更请求定义、协作、基线维护、通知和报告生成