需求规格说明书示例通常包含文档标识与版本、范围与目标、角色与场景、功能需求条目、非功能需求、数据与字段定义、接口与依赖、验收标准、假设与约束、变更记录十个部分。本文给出一份虚构的“会议室预约”需求规格说明书完整样例，逐项说明每个字段写什么、为什么这样写，并整理换业务场景时的调整规律与使用边界。
要点总览（TL;DR）
- 需求规格说明书示例通常包含文档标识与版本、范围与目标、角色与场景、功能需求条目、非功能需求、数据与字段定义、接口与依赖、验收标准、假设与约束、变更记录十个部分。
- 本文给出一份虚构的“会议室预约”完整样例，功能条目带编号与优先级，非功能指标写明测量口径，验收标准与需求条目一一对应。
- 关键字段的写法有共同理由：编号用于稳定引用，功能描述写到开发能设计、测试能写用例的颗粒度，待确认问题单独成节避免被误当结论。
- 迁移到其他业务时保留文档骨架，替换角色与场景，按业务风险取舍非功能需求，验收标准始终从需求描述派生。
- 示例为虚构演示情景，不能直接当作组织规范或行业标准；受监管行业的合规要求、团队规模带来的详略差异需另行确认。
示例目标：这份需求规格说明书要解决什么问题
这份示例演示的是一份需求规格说明书从文档头到变更记录的完整结构，重点在于让读者看到“填好之后长什么样”。读者对象包括需要撰写需求文档的产品或业务人员、依据文档开展设计与开发的工程师，以及据此设计测试用例的测试人员。三类读者关注点不同：业务方看范围与目标是否准确，开发看功能条目与接口依赖是否可执行，测试看验收标准是否可验证，因此示例在每个部分都尽量写到可被这三类角色直接使用的程度。
需要明确的是，本文的“会议室预约”是一个虚构演示情景，不指向任何真实企业、客户或上线项目，其中的角色名称、功能条目、性能指标和验收取值均为演示设定。示例覆盖的需求类型包括：面向终端用户的功能需求、支撑系统运行的非功能需求、数据字段与状态定义、外部接口与依赖，以及验收标准与待确认问题。它不覆盖需求变更审批流程、评审会议机制和文档权限设计，这些内容属于组织流程与工具配置范畴。
完整示例：会议室预约需求规格说明书
以下为一份完整填写的示例文档。为便于对照，各部分按实际文档顺序排列，表格中的取值均为演示数据。
1. 文档标识与修订记录
| 字段 | 填写内容 |
|---|---|
| 文档名称 | 会议室预约系统需求规格说明书 |
| 文档编号 | SRS-MEETING-001 |
| 当前版本 | V1.2 |
| 文档状态 | 评审中 |
| 编写人 / 评审人 | 产品负责人 / 研发负责人、测试负责人、行政负责人 |
| 更新日期 | 示例日期 |
| 版本 | 变更内容 | 变更人 | 日期 |
|---|---|---|---|
| V1.0 | 初稿，覆盖预约、取消、查询三项核心功能 | 产品负责人 | 示例日期 |
| V1.1 | 补充冲突校验规则与候补机制 | 产品负责人 | 示例日期 |
| V1.2 | 补充非功能指标与验收标准，明确待确认问题 | 产品负责人 | 示例日期 |
2. 背景、目标与范围边界
背景：员工目前通过群聊和表格登记会议室，存在重复占用、信息分散、临时调整无法同步的问题。目标：提供一个统一的会议室查询与预约入口，使员工能自助完成预约、取消与冲突处理，行政人员能维护会议室资源。范围边界：本期包含会议室资源维护、预约与取消、冲突校验、候补排队、预约记录查询；不包含门禁硬件联动、访客管理、跨园区资源调度，这些列入后续版本候选。
3. 角色与典型使用场景
| 角色 | 典型场景 | 主要诉求 |
|---|---|---|
| 普通员工 | 临时需要一个 6 人会议室开一小时会 | 快速查到空闲房间并完成预约 |
| 会议组织者 | 提前一周预定大会议室并邀请参会人 | 锁定资源、通知参会人、便于改期 |
| 行政管理员 | 新增会议室、设置开放时段、处理异常占用 | 维护资源信息、处理冲突 |
4. 功能需求条目
| 编号 | 需求描述 | 优先级 |
|---|---|---|
| FR-01 | 员工可按日期、时间段、容纳人数筛选可用会议室，结果展示房间名称、位置、容量与空闲状态 | 高 |
| FR-02 | 员工选择会议室与时间段后提交预约，系统校验时间冲突，冲突时给出提示并推荐相邻可用时段 | 高 |
| FR-03 | 预约成功后生成预约记录，包含预约人、参会人、主题、起止时间，并向参会人发送通知 | 高 |
| FR-04 | 预约人可在开始时间前取消预约，取消后释放时段并通知参会人 | 高 |
| FR-05 | 目标时段已被占用时，员工可加入候补队列，前序预约取消后按加入顺序通知候补人 | 中 |
| FR-06 | 行政管理员可新增、停用会议室，设置开放时段与单次预约时长上限 | 中 |
| FR-07 | 员工可查询本人历史预约记录，按时间范围筛选 | 低 |
5. 非功能需求
| 类别 | 指标（演示取值） | 说明 |
|---|---|---|
| 性能 | 会议室查询响应在常规负载下不超过 2 秒 | 以内部办公网络为测量环境 |
| 并发 | 支持同一时段 200 人同时查询与提交预约 | 按单园区规模设定，需按实际人数调整 |
| 安全 | 预约与取消操作需登录后执行，操作记录保留可追溯信息 | 具体认证方式沿用组织统一账号体系 |
| 可用性 | 工作时段内服务可用，异常时给出明确提示而非静默失败 | 可用性目标按组织运维标准确定 |
6. 数据字段与状态定义
| 对象 | 关键字段 |
|---|---|
| 会议室 | 房间编号、名称、位置、容纳人数、开放时段、状态（可用 / 停用） |
| 预约记录 | 预约编号、会议室编号、预约人、参会人列表、主题、开始时间、结束时间、状态 |
预约状态流转：待开始 → 进行中 → 已结束；待开始时可由预约人取消，转为已取消；候补记录状态为排队中、已通知、已失效。
7. 接口与外部依赖
依赖组织统一账号体系完成登录与身份识别；依赖消息通知服务向参会人发送预约成功、变更与取消通知；会议室基础信息由行政管理员在系统内维护，本期不接入外部楼宇系统。接口调用失败时，预约主流程应保留记录并提示用户稍后重试。
8. 验收标准
| 对应需求 | 验收标准 |
|---|---|
| FR-01 | 按日期、时间段、人数组合筛选，返回结果与会议室实际空闲状态一致 |
| FR-02 | 提交与已有预约冲突的时段时，系统拒绝并给出冲突提示与可用时段建议 |
| FR-03 | 预约成功后记录字段完整，参会人收到通知 |
| FR-04 | 取消后该时段可被他人预约，参会人收到取消通知 |
| FR-05 | 前序预约取消后，候补队列首位收到通知，其余候补顺序不变 |
9. 假设、约束与待确认问题
假设：员工使用组织统一账号登录；会议室数量与位置由行政方提供准确清单。约束：本期仅支持单园区；单次预约时长上限由管理员配置。待确认问题：候补通知的等待时限如何设定；跨天预约是否需要支持；取消是否设置时间下限（如开始前 15 分钟内不可取消）。以上问题在评审中确认后回填本文档并更新版本。
逐项解释：每个字段为什么这样写
需求编号与优先级的作用是建立可追踪的锚点。编号让功能条目在评审、开发、测试和变更记录中被稳定引用，避免用“那个预约功能”这类模糊指代；优先级则帮助团队在资源紧张时决定取舍，高优先级条目构成首版必须交付的范围。编号一经发布不宜复用或重排，新增需求追加编号即可。
功能描述的颗粒度以“开发能据此设计、测试能据此写用例”为准。以 FR-02 为例，它写清了触发动作（选择会议室与时间段后提交）、系统行为（校验冲突）、异常处理（提示并推荐相邻时段），但没有规定具体交互控件和页面布局，这些留给设计环节。颗粒度过粗会导致理解分歧，过细则会锁死实现方式，示例选择的是行为可验证、实现留空间的写法。
验收标准与需求条目一一对应，是从需求描述中派生出的可观察结果，而非另起一套要求。FR-04 的验收标准直接检查“取消后时段可被他人预约”和“参会人收到通知”两个可观察事实，测试人员据此设计用例，评审时也能快速判断需求是否写清楚。非功能需求的量化要给出测量口径，例如响应时间需说明测量环境和负载条件，否则“响应快”无法验收。
待确认问题单独成节记录，是为了把尚未达成一致的内容显性化，避免在正文中写成确定结论后被误当作已确认需求。每条待确认问题应写明待定内容和确认方式，评审确认后回填正文并更新版本。版本与变更记录的意义在于让读者知道当前文档处于什么状态、相比上一版改了什么，评审和开发依据的应是同一版本。
当需求条目数量增多、参与角色变多时，文档的维护动作会从单人写作转为多人协作。以 ONES 为例，ONES Wiki 支持使用模板库一键创建文档，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，可随时查看与回滚，适合承载本文示例中的条目表与变更记录。文档支持富文本、Markdown 和代码块，成员可在线添加注释与评论，评审意见可以直接落在对应段落旁；文档中还可嵌入任务进度与报表，让验收标准的推进情况与需求条目放在同一处查看。这些能力服务于文档的协作与版本管理，文档内容本身仍需按上文方法填写。
可迁移规律：换一个业务怎么改这份示例
文档骨架可以保持不变。文档标识与版本、范围与目标、角色与场景、功能条目、非功能需求、数据定义、接口依赖、验收标准、假设与约束、变更记录这十个部分，适用于大多数内部业务系统的需求描述，迁移时无需重新设计章节顺序。
需要按业务替换的是角色与场景。示例中的普通员工、会议组织者、行政管理员对应的是“资源使用方、资源协调方、资源维护方”三类职责，换成报销、设备借用或工单派发时，应重新识别本业务中谁发起、谁审批、谁维护，再据此写场景。功能条目的拆分粒度遵循同一原则：一条需求对应一个可独立验收的行为，包含触发条件、系统响应和异常处理；跨多个角色的复杂流程拆成多条并标明依赖关系。
非功能需求按业务风险取舍。会议室预约的核心风险是时段冲突和查询等待，因此重点写并发与响应；换成涉及个人信息的业务，安全与操作留痕的权重会上升。验收标准始终从需求描述派生，每条功能需求至少对应一条可观察的验收结果，避免出现无法验证的表述。迁移时可对照以下清单逐项检查：角色是否覆盖全部使用方、每条功能是否有编号与优先级、非功能指标是否写明测量口径、待确认问题是否单独列出、变更记录是否随版本更新。
适用边界：示例不能直接当规范用的地方
这份示例是虚构演示情景，其中的角色、条目和指标用于说明写法，不代表任何真实项目的需求结论，也不能作为行业标准引用。不同行业对需求文档的合规要求差异较大，涉及医疗、金融、航空等受监管领域时，文档的评审记录、签署要求和留存期限需按所在行业的规范另行确认，本文不涉及这些内容。
团队规模与流程成熟度会影响文档详略。小团队可以合并部分章节、精简非功能指标；流程较成熟的团队通常需要更完整的评审记录与变更追溯。示例给出的是较完整的一种写法，读者应按自身情况裁剪，而非全盘照搬。此外，本文不覆盖需求变更流程与评审机制的具体设计，也不涉及文档协同、权限管理与 AI 生成文档等工具侧配置，这些需要在组织流程和工具使用中单独确定。
常见问题
示例里的功能条目编号和优先级，在需求变更后怎么处理？
编号一经发布不宜复用或重排，新增需求追加新编号，被取消的需求保留编号并标注状态，这样评审记录、测试用例和变更日志中的引用始终指向同一条需求。优先级可以随版本调整，但调整应记入变更记录，说明调整原因和影响范围，避免开发与测试依据不同版本的优先级安排工作。
非功能需求写成“响应快”“稳定可靠”可以吗？
这类表述无法验收。非功能需求应给出可测量的指标和测量口径，例如响应时间要说明测量环境与负载条件，并发要说明按什么规模设定，可用性要说明目标依据哪份运维标准。示例中的取值是演示数据，迁移时应按自身业务的实际规模和风险重新设定，并注明数据来源或测算方式。
待确认问题在评审前应该写进正文还是单独列出？
建议单独成节列出，写明待定内容和确认方式。写进正文容易被后续读者当作已确认需求执行，导致开发按未定方案开工。评审确认后再回填正文对应条目，并更新版本号与变更记录，使文档状态与团队共识保持一致。
团队规模较小，这份示例的章节可以合并吗？
可以按实际情况裁剪。小团队可将接口与依赖并入功能条目说明，将假设与约束并入范围边界，保留文档标识、功能条目、验收标准和变更记录这几项核心内容。合并的前提是每条功能需求仍可被独立验收，变更仍可追溯；流程较成熟的团队通常需要更完整的评审记录与版本追溯。
示例中的需求条目和验收标准，在工具里怎么承载？
示例本身是文档写法，落到工具中时，需求条目可作为工作项管理，验收标准随条目一起维护，变更通过版本记录追溯。以 ONES 为例，ONES Wiki 支持使用模板库一键创建文档，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，可随时查看与回滚，适合承载示例中的条目表与变更记录。文档还支持富文本、Markdown 和代码块，成员可在线添加注释与评论，评审意见可直接落在对应段落旁。
