4. SRS结构设计：IEEE 830标准模板、自定义模板设计、章节划分原则

好，咱们今天聊聊SRS的结构设计。说白了，就是你的需求文档长什么样，骨架怎么搭。

我见过太多团队，上来就写需求，写到一半发现漏了关键内容，或者章节之间逻辑混乱。嗯，这其实是可以避免的。只要一开始把结构定好，后面就顺了。

4.1 IEEE 830标准模板：老前辈的智慧

IEEE 830是1998年的标准，但至今仍是SRS结构的黄金参考。我个人习惯，每次写新文档前都会翻一翻这个模板，找找灵感。

它的核心结构是这样的：

章节	内容	我的经验
1. 引言	目的、范围、定义、参考文献、概述	别写太长，交代清楚背景就行
2. 总体描述	产品视角、用户特征、约束、假设	这里最容易漏掉「假设」部分
3. 具体需求	功能需求、接口需求、性能需求、设计约束	核心章节，占文档70%篇幅
4. 附录	术语表、索引、待定问题	别小看附录，能救你命

我在项目中遇到过，有人照着830模板硬套，结果文档又臭又长。为什么？因为没理解模板背后的逻辑。830模板其实是在帮你回答三个问题：

• 我们要做什么？（引言）
• 在什么条件下做？（总体描述）
• 具体做成什么样？（具体需求）

4.2 自定义模板设计：别被模板绑架

说实话，我很少直接用830的原始模板。太死板了。你想想看，一个移动端App的需求文档，跟一个嵌入式系统的需求文档，能一样吗？

我建议你这样做自定义模板：

1. 保留核心骨架：引言、总体描述、具体需求，这三块不能少
2. 砍掉冗余章节：比如你的项目没有外部接口，就别硬写「接口需求」这一章
3. 增加特色章节：比如数据密集型项目，我会加一章「数据字典」
4. 调整章节顺序：有时候把「用户界面需求」提前，能让读者更快理解产品

举个例子，我之前做一个电商后台的SRS，模板长这样：

1. 引言
  1.1 文档目的
  1.2 项目范围
  1.3 术语表

2. 总体描述
  2.1 产品功能概览
  2.2 用户角色
  2.3 假设与依赖

3. 功能需求
  3.1 商品管理
  3.2 订单处理
  3.3 用户管理
  3.4 权限控制

4. 数据需求
  4.1 数据实体
  4.2 数据流图

5. 非功能需求
  5.1 性能要求
  5.2 安全性要求
  5.3 可用性要求

6. 附录
  6.1 待定问题列表
  6.2 变更记录

你看，我把「接口需求」去掉了，因为后台系统主要是内部调用。但加了「数据需求」一章，因为电商系统数据关系复杂。

4.3 章节划分原则：别让读者迷路

章节怎么划？我总结了三个原则，你记一下：

• 单一职责原则：一个章节只讲一件事。别把性能需求和界面需求混在一起写
• 渐进细化原则：从宏观到微观。先讲整体功能，再讲具体细节
• 可追溯原则：每个章节都能对应到某个设计文档或测试用例

具体怎么划？我一般这样操作：

1. 按功能模块划：适合业务逻辑清晰的项目。比如「订单模块」、「支付模块」、「物流模块」
2. 按用户角色划：适合多角色系统。比如「管理员功能」、「普通用户功能」、「审核员功能」
3. 按需求类型划：适合技术性强的项目。比如「功能需求」、「性能需求」、「安全需求」
4. 混合划分：最常用。先按模块分，每个模块里再按类型分

嗯，这里要注意：章节深度控制在3级以内。超过3级，读者就找不到北了。比如：

3. 功能需求（1级）
  3.1 订单管理（2级）
    3.1.1 创建订单（3级）
      3.1.1.1 订单校验规则（4级）← 太深了，建议合并到3.1.1中

我个人习惯，最多到3级。如果某个需求太复杂，我会单独写一个附录或者子文档。

4.4 实战建议：从模板到成品

最后，给你一个实操步骤：

1. 先画目录：用思维导图画出SRS的骨架，给团队评审
2. 再填内容：按目录逐章填充，每章控制在500-1000字
3. 最后调整：写完后通读一遍，看看章节之间有没有逻辑断层

好了，这一章就到这里。下一章咱们聊聊「需求获取技术：访谈、问卷、原型法」，到时候我会分享一些我在客户现场「挖需求」的真实案例。