软件需求分析

软件需求分析课是一门非常好玩和实践性很强的课程，其核心就是最后的软件需求分析与规格说明书。具体的步骤老师上课会教给大家的～这里的话就简单写一个小流程 and 写规格说明书当中容易遗漏的点。

这里非常非常感谢我两位给力的组员，小号（人品责任心 max、美术能力 max、科研能力 max、沟通能力max） 和 宇航（人品责任心 max、竞赛能力 max、学科实力 max、沟通能力max） 真的审美在线、实力在线、性格还超级好～我们就这样以最少的人数拿下了最难的任务。

还有非常非常感谢所有老师，特别是一直陪伴我们上课的海研的老师们。非常耐心、温和，始终给予我们帮助和肯定，是特别特别美好的回忆。

如果不是老师、朋友们，maybe 我也不会这么喜欢这门课了。

一、如何建立一个完整的需求过程？

需求并不是客户“点菜”我们“上菜”那么简单，真正的需求建立是一个启发、分析、建模、验证的螺旋上升过程。完整的生命周期包含以下四个核心步骤：

1. 需求获取

• 做法：不要只听客户说“我要一个系统”，要问“你现在的工作痛点是什么？”采用访谈、问卷、文档分析（如分析他们现有的 Excel 表格和审批流）等方法。
• 关键点：识别所有涉众。
• 产出：访谈记录（如原始的调研语录整理）、原始用例图、场景流程图。

2. 需求分析与建模 —— 让业务逻辑结构化

• 做法：将收集到的庞杂信息进行分类、过滤和重组。区分出哪些是核心需求，哪些是伪需求。
• 工具：
  • 数据流图（DFD）：从上下文顶层图开始，一层层向下拆解，弄清楚数据从哪来、经过什么处理、到哪去。
  • 实体关系图（ERD）：找出系统中的核心名词（如项目、任务、用户、评价），梳理它们之间是一对多还是多对多的关系。
  • 用例描述：清晰定义触发条件、正常流程和异常分支。

3. 需求规格化 —— 撰写 SRS

• 做法：将分析和建模的结果，用清晰、无歧义、可验证的语言和规范的格式落实到文档中。这就是我们常说的《软件需求规格说明书》。它是开发、测试和验收的唯一权威基线。

4. 需求验证与确认—— 达成共识

• 做法：组织评审会，与客户和开发团队逐条过需求。确认“这真的是你们想要的吗？”（Validation）以及“这份文档写得符合标准吗？”（Verification）。

---

二、撰写《软件需求规格说明书》

以下是撰写 SRS 时必须严格遵守的注意事项：

1.需求的三维分层

需求绝对不能混为一谈，必须严格分级，这决定了文档的逻辑主线：

1. 业务需求：站位最高。通常描述企业为什么要做这个软件（动机），以及成功的衡量标准（如：降低 50% 延期率，提升资源利用率）。
2. 用户需求：站在角色视角。描述不同涉众需要软件帮他们完成什么工作（特性描述、用例列表）。
3. 系统级需求：最底层、最详尽。是开发和测试的直接依据。必须拆解到具体的功能点（输入、输出、处理逻辑、涉及的数据库表等）。

2.图表排版规范

表上图下：

• 表格：
  • 表头：表名必须写在表格的正上方。
  • 编号：必须采用章节分级编号（如 表 4.2.1-1 调研用例描述表）。
  • 内容：要有明确的列头（如：功能编号、需求描述、输入、输出、需求追溯）。
• 图片：
  • 图题：图的名称必须写在图片的正下方。
  • 编号：同样采用分级编号（如 图 3.1.2-1 项目管理系统上下文数据流图）。
  • 清晰度：所有的 DFD、ERD 连线必须清晰，箭头方向不能错，实体和处理模块必须有唯一的标识或命名。

3.编码与需求可追溯性

• 统一编码：每一个需求都必须有一个独一无二的身份证号。
  • 比如业务特性编码为 C-01，用户需求编码为 R-01-01，系统详细功能编码为 S-01-01。
• 追溯矩阵：在系统需求描述表中，必须有一列叫**“需求追溯”**，明确标出这个系统功能是为了满足哪一个阶段的用户需求。这样当用户需求变更时，我们能顺藤摸瓜知道要改哪些代码。

4.SRS 必不可少的核心板块

1. 重要术语与缩写说明：统一沟通语言（例如，大家说的“打卡”在系统里叫“工时记录”还是“进度汇报”？必须在开头定义清楚）。
2. 项目范围与边界：不仅要写“系统包含什么”，更要花大篇幅写“系统明确不包含什么”。这是防止项目后期“需求蔓延”的手段（例如：明确声明不涉及财务系统深层对接）。
3. 假设与依赖：列出项目成立的外部条件。比如“依赖钉钉的 API 稳定”、“假设客户愿意提供近一年的历史数据”。
4. 非功能性需求：
   • 性能：页面响应时长 ≤ 2s。
   • 可用性：系统故障恢复时间 ≤ 30 min。
   • 软硬件环境：支持的浏览器版本、服务器配置、内网外网要求等。

三、完整软件需求规格说明书