2.4 完成文档：需求说明书与检查¶

把前面的分析整理成一份开发依据¶

需求说明书不是把前面内容复制一遍

立项书回答“项目值不值得做、能不能做”；需求分析说明书回答“系统具体要做什么、怎样才算完成”。

后续画原型、设计数据库、编写接口、让 AI 修改代码和测试系统时，都应该以这份文档为依据。只要核心内容清楚、一致、可测试，就已经是一份合格的课程需求文档。

本节学习目标

整理前面完成的选题、立项和需求内容，形成一份 5—8 页 的《需求分析说明书》，并使用 Trae 和教师提供的 Skill/Agent 完成检查与修改。

返回上一节：梳理项目需求返回第二篇导读

🎯 第二篇最终提交什么¶

完成第二篇后，通常只需要提交以下两份文档：

文档	作用	建议篇幅
《项目选题立项书》	说明项目问题、目标、范围和计划	2—4 页
《需求分析说明书》	说明用户、功能、规则和验收条件	5—8 页

本节只完成第二份：

《需求分析说明书》

内容少但必须一致

不要求额外提交复杂的需求追踪表、正式评审记录或大量 UML 图。先确保两份核心文档内容真实、彼此一致，并能指导下一阶段的原型和开发。

📦 第一步：准备已有材料¶

需求说明书不是从空白开始写。先准备前面已经完成的内容：

已有材料	在需求说明书中的用途
选题卡	项目名称、一句话介绍、核心闭环和范围边界
项目选题立项书	背景、目标用户、调研依据、项目目标和本期不做内容
需求梳理草稿	用户角色、场景、功能、流程、规则和验收条件
AI 对话记录	仅作为查漏和修改的参考，不直接当作真实需求来源

整理前，先检查一个基本原则：

立项书中承诺做什么，需求说明书就写什么；需求说明书中新增的必做功能，必须回头确认是否超出了立项范围。

例如，立项书只计划完成“活动发布、报名、签到和评价”，需求文档就不应突然把“在线支付、直播、跨校活动联盟”写成必做功能。

📝 第二步：按最小结构完成需求说明书¶

基础项目可以直接按下面的结构编写。每个章节保持简洁，用表格、流程图和编号帮助读者快速理解。

# 项目名称——需求分析说明书

## 1. 项目概述
- 项目背景
- 项目目标
- 本期范围与不做内容

## 2. 用户角色与权限

## 3. 核心使用场景

## 4. 功能需求
- FR-模块-序号

## 5. 核心业务流程与状态说明

## 6. 业务规则与异常情况
- BR-模块-序号

## 7. 验收条件

## 8. 需求变更记录（如有）

1. 项目概述：从立项书提取，不要重写空话¶

用一小段文字说明项目背景、目标和范围即可：

1
2
3

本项目面向住校学生、宿舍管理员和维修人员，解决报修依赖群消息、
处理进度不透明的问题。系统支持学生提交报修、管理员派单、维修人员更新进度
和学生确认结果。本期不包含在线支付、智能硬件接入和跨校区调度。

2. 用户角色与权限：写清能做与不能做¶

角色	主要操作	权限限制
学生	提交报修、查看本人记录、确认处理结果	不能查看他人报修单，不能派单
宿舍管理员	查看待处理记录、派单、查看进度	不能以学生身份提交报修
维修人员	查看分配任务、更新进度和处理结果	不能查看未分配给自己的任务

3. 场景、功能、流程和规则：保持对应关系¶

这些内容必须能彼此对应：

如果文档中有……	就要能找到……
用户场景	对应的功能需求
功能需求	对应的角色、前置条件和结果
业务流程	流程中每一步对应的功能或规则
状态变化	哪个角色可以在什么条件下改变状态
业务规则	对应的异常场景和验收条件

最常见的问题是前后矛盾

例如，流程图写“学生确认完成”，但功能清单里没有确认功能；规则写“只有管理员能派单”，但角色表又允许维修人员派单。发现这类矛盾后，应统一修改，而不是只改其中一处。

🔢 第三步：给核心功能和规则编号¶

编号不需要复杂，但能帮助后续开发和测试对照。

功能需求编号¶

推荐格式：FR-模块-序号。

编号	功能名称	简要说明	优先级
FR-REPAIR-01	提交报修	学生提交故障信息，系统创建待受理记录	必做
FR-REPAIR-02	查看我的报修	学生查看本人报修单及处理状态	必做
FR-REPAIR-03	受理并派单	管理员为待受理报修单分配维修人员	必做
FR-REPAIR-04	更新维修进度	维修人员更新自己任务的处理状态	必做
FR-REPAIR-05	确认处理结果	学生确认报修已解决，报修单完成	必做

业务规则编号¶

推荐格式：BR-模块-序号。

编号	业务规则	对应功能
BR-REPAIR-01	未登录用户不能提交报修或查看个人报修记录	提交、查询
BR-REPAIR-02	学生只能查看和确认本人提交的报修单	查询、确认
BR-REPAIR-03	只有管理员可以受理和派单	受理派单
BR-REPAIR-04	只有被分配的维修人员可以更新任务进度	更新进度
BR-REPAIR-05	已完成报修单不能再次派单、更新或确认	全部操作

编号是为了查找，不是为了凑格式

后面写原型、接口和测试用例时，可以直接标注“对应 FR-REPAIR-03”或“验证 BR-REPAIR-05”，避免大家说“那个派单功能”却不知道具体指哪一项。

✅ 第四步：把验收条件写成可以操作的检查¶

需求不是“页面好看”“系统稳定”这类难以判断的话，而是应当能通过页面、接口或数据变化验证。

推荐使用“给定—当—那么”：

给定：学生已经登录，填写了有效的报修信息；
当：学生提交报修；
那么：系统创建一条状态为“待受理”的报修记录，
并提示提交成功。

最小验收表¶

对应编号	验收场景	操作	通过条件
FR-REPAIR-01	正常提交报修	已登录学生填写完整信息后提交	创建待受理记录，页面显示成功提示
FR-REPAIR-01	缺少必填项	不填写地点直接提交	系统拒绝提交并指出缺失字段
BR-REPAIR-02	查看他人记录	学生请求其他学生的报修单	后端拒绝，数据不返回
BR-REPAIR-05	重复确认	对已完成记录再次确认	操作被拒绝，状态保持不变

别忘了最基本的质量要求¶

不必制定复杂的性能指标，但至少在文档中写明：

未登录用户不能访问受保护功能；
普通用户不能访问管理功能；
必填项为空或格式错误时有明确提示；
重复操作不会产生重复记录或错误状态；
操作失败时显示可理解的原因；
在 Chrome 或 Edge 中能完成核心流程；
密码、密钥等敏感信息不写入代码仓库。

没有验收条件，后面无法证明完成

如果功能只写“支持预约”“支持审核”，测试时就不知道该测什么。每个必做功能至少写一个正常场景和一个异常或边界场景。

🔍 第五步：用“三张表”完成一致性检查¶

在提交前，不需要复杂的评审会议。用下面三张表进行一次自查即可。

表一：范围检查¶

检查问题	通过标准
是否超出立项书？	所有必做功能都能在立项书中找到依据
是否范围过大？	只保留 1～2 条核心流程和 4～6 个核心模块
是否有本期不做内容？	已明确排除高风险或非核心功能

表二：闭环检查¶

检查问题	通过标准
业务流程是否有开始和结束？	从用户操作开始，到用户获得结果结束
流程中的操作都有功能吗？	每一步都能找到对应功能需求
状态变化是否明确？	每个状态知道谁能改、能改成什么
异常情况是否考虑？	至少包含输入、权限、数据和重复操作问题

表三：测试检查¶

检查问题	通过标准
必做功能能测试吗？	每项都有操作和可观察的通过条件
权限能测试吗？	包含未登录和越权访问场景
数据变化能验证吗？	新增、修改、状态更新等结果明确
文案是否具体？	没有“合理处理”“视情况而定”等模糊词

🤖 第六步：让 AI 协助审查，但由你决定修改¶

教师可以提供需求审查 Skill 或 Agent。把立项书和需求说明书一起交给 Trae，并使用下面的提示词：

请使用教师提供的需求审查 Skill 检查我的《项目选题立项书》和《需求分析说明书》。

请先阅读两份文档，不要虚构用户调研、数据或需求，也不要擅自增加功能。

重点检查：
1. 两份文档中的用户、问题、目标和范围是否一致；
2. 每条核心业务流程是否能够形成闭环；
3. 功能、流程、状态和业务规则之间是否矛盾；
4. 是否遗漏登录、权限、输入校验、重复操作等关键场景；
5. 每个必做功能是否有可测试的验收条件；
6. 是否存在超过课程周期的复杂功能。

请按“位置—问题—影响—修改建议”输出，
并区分“必须修改”和“可选优化”。

收到结果后，按优先级处理：

必须修改：范围过大、核心流程断裂、权限错误、状态混乱、无法测试；
建议修改：表述不清、缺少一个常见异常、编号不统一；
可选优化：复杂的统计、推荐、动画、AI 增强等非核心内容。

不要为了满足 AI 建议不断加功能

AI 可能建议增加消息通知、复杂统计、更多角色或外部平台集成。只要这些内容不影响核心闭环，就可以写入“选做”或“本期不做”，而不是立刻加入需求范围。

📋 第七步：完成最终检查并提交¶

提交前，完成以下操作：

确认文档标题、项目名称与立项书一致；
检查表格、流程图和编号是否能正常阅读；
阅读一遍，删除空话、重复内容和未确认的 AI 生成结论；
请同学或教师用 3 分钟阅读文档，并回答：他是否能说出用户、主流程和必做功能；
根据反馈修改后，保存最终版本；
将文档与修改说明提交到 Git 仓库。

最终自查清单¶

🎁 完成第二篇后，你将拥有¶

一份范围清楚、能够指导后续工作的《项目选题立项书》；
一份说明用户、功能、流程、规则和验收条件的《需求分析说明书》；
一条可用于后续原型、数据库、接口和测试的核心业务闭环；
一套使用 Trae Skill/Agent 辅助选题、需求分析和文档检查的方法；
对自己项目“做什么、不做什么、怎样证明完成”的清楚认识。

先把需求说清楚，再让 AI 和代码开始工作；先把范围定下来，再逐步增加特色。

📝 本节小结¶

需求说明书是后续开发基线：原型、设计、代码和测试都应以它为依据；
文档要简洁但一致：立项书和需求说明书不能互相矛盾；
编号和验收让需求可执行：知道做哪项功能，也知道怎样证明完成；
三张表完成基础检查：检查范围、闭环和测试条件；
AI 负责查漏，人负责决策：不盲目采纳复杂功能，始终守住项目边界。

返回上一节：梳理项目需求返回项目选题库返回课程首页