最近研读了软件需求工程，编写有效用例和系统化思维导论等书籍，对软件开发的关键节点做了一些记录和思考，具体如下，供参考。在软件开发生命周期中（SDLC），需求分析、系统原型和系统设计三者的互依赖关系及其成果支撑链路。需求分析、编写用例、系统原型和系统设计是紧密关联的核心环，用例和原型是精化需求分析的手段，而高质量的需求分析则是成功的系统设计与项目规划的前提。
1. 核心定义与角色
- 需求分析 (Requirement Analysis, RA)：定义"做什么"。通过捕获业务需求、用户需求和功能需求，构建系统行为的契约（如用例），定义了整个项目的范围和目标。
- 用例编写 (Use-Cases)：在需求分析过程中，将抽象的目标具体化为可操作的用户任务。
- 系统原型 (System Prototyping, SP)：通过构建低/高保真模型来"可视化"需求。用于需求澄清、用户确认和技术验证。
- 系统设计 (System Design, SD)：定义"怎么做"。将需求转化为可实现的架构、模块划分和详细技术方案。
2. 三者相互依赖关系
2.1 需求分析 系统原型 (双向迭代)
- RA SP (驱动方向) ：
- 需求分析定义了原型的范围 和目标，软件项目中 40% 至 60% 的问题源于需求分析阶段，有效分析能弥补用户期望与实际开发之间的"期望差异"。
- 编写的用例 (Use Cases) 为原型的交互流程提供了脚本，决定了原型需要展示哪些路径（主成功场景与扩展路径），用例通过描述执行者（Actor）与系统之间的交互序列来展现用户任务，包括基本路径（普通过程）、可选路径和例外情况，用例是从业务需求通向功能需求的桥梁，分析人员能够从用户任务中总结出特定的功能需求。
- SP RA (反馈方向) ：系统原型是所建议新产品的部分实现，用于解决需求获取过程中的不确定性，原型能使概念直观化，它是验证用例、功能需求和分析模型的重要手段。
- 澄清需求：原型通过可视化消除文本需求的歧义，帮助分析师发现遗漏的需求（如遗漏的异常场景）。
- 需求验证：用户通过操作原型确认需求是否符合预期，从而修正 (需求规格说明书)。
- 降低风险：通过抛弃型原型快速验证想法，避免在错误的需求方向上进行深入设计。
2.2 需求分析 系统设计 (单向引导 闭环反馈)
- RA SD (支撑方向) ：
- 功能驱动 ：功能需求 功能分解 模块划分 系统架构。需求（包括用例和质量属性）是设计的基础。设计必须确保满足所有功能需求，且不应包含不必要的功能。
- 质量属性驱动：非功能需求（性能、可用性、安全性） 架构风格 技术选型。
- 数据驱动：数据需求/ER图 数据模型 存储设计 数据架构。
- SD RA (反馈方向) ：
- 可行性反馈：在设计阶段发现的技术瓶颈或成本过高，会强制要求回溯并修改需求（需求变更控制）。
- 转化过程：开发者利用面向对象的方法将用例转化为对象模型（类图）、功能模块和接口定义。
2.3 系统原型 系统设计 (蓝图支撑)
- SP SD (指引方向) ：
- UI/UX 基准：电子原型/高保真原型直接支撑界面设计和用户交互设计。
- 技术验证 ：垂直原型 (Vertical Prototype) 验证关键技术路径，为系统架构设计提供实证支持，降低设计风险。系统设计接收经过验证的需求和用例，将其转化为技术蓝图（如类、模块、数据库结构），为后续的编码和测试提供依据。
3. 成果支撑链路
下表描述了各阶段产出物如何作为后续阶段的输入支撑其完成：
| 来源阶段 | 支撑成果 (Artifact) | 支撑目标阶段 | 如何支撑 (Support Role) |
|---|---|---|---|
| 需求分析 | (需求规格说明书) | 系统设计 | 提供完整的功能清单、约束条件和验收标准，作为设计的唯一真理来源。 |
| 需求分析 | 有效用例 (Use Cases) | 系统原型 | 为原型的页面流转和交互逻辑提供"脚本"，定义原型需覆盖的场景。 |
| 需求分析 | ER图 / 数据流图 (DFD) | 系统设计 | 为数据库设计、接口定义和数据架构提供底层逻辑支撑。 |
| 系统原型 | 水平原型 (Horizontal) | 需求分析 | 作为需求验证工具，通过用户反馈更新 和用例。 |
| 系统原型 | 垂直原型 (Vertical) | 系统设计 | 验证核心技术可行性，支撑架构决策（如选择某种缓存机制）。 |
| 系统原型 | 高保真 UI 原型 | 系统设计 | 转化为前端详细设计文档和组件库定义。 |
| 系统设计 | 架构设计文档 / 类图 | 需求分析 | 通过 RTM (需求跟踪矩阵) 反向验证所有需求点是否在设计中得到覆盖。 |
4.什么是好的需求分析
好的需求分析能够跨越用户期望与开发者理解之间的"期望差异"，确保开发出真正满足业务目标的产品，需求是分层次的，分为业务需求 （关注高层目标）、用户需求 （关注用户任务）和功能需求 （关注系统行为），具有完整性、无二义性、具体可验证性、建设的必要性和优先级等特点。
示例：
- 不好的分析："系统必须在固定的时间间隔内提供状态消息"。由于未定义什么是状态消息、何时提供以及"固定间隔"的具体数值，该需求是模糊且不可验证的。
- 好的分析："在后台任务进程启动后，系统必须每隔60（±10）秒在用户界面指定区域更新并显示已完成的百分比"。该描述具体、可测量且明确了行为。
5.什么是有效用例
用例（Use Case）是描述系统行为的契约，它展现了执行者（Actor）与系统之间的交互序列以实现某个目标。有效的用例具备如下特点：
- 以任务为中心：关注用户利用系统要"做什么"，而不是系统有哪些"功能"。
- 易于阅读的文本形式：虽然可以用图表表示，但简单的文本通常是编写用例的首选，便于非专业人员理解。
- 包含核心要素 ：必须明确范围 （讨论的系统）、主执行者 （谁要实现目标）、前置条件 （执行前必须满足的条件）和成功保证（执行后达到的状态）。
- 覆盖完整路径 ：不仅描述主成功场景 （一切顺利的情况），还要详细记录扩展（可能出现的例外或失败情况）。
典型用例
用例1：油井递减曲线分析
- 用例名称：油井递减曲线分析。
- 主执行者：油藏工程师。
- 主成功场景 ：
- 工程师选择特定油井并加载历史月度产油量数据 。
- 系统生成产量-时间双对数坐标图 。
- 工程师选择递减类型（指数、双曲或谐波）并调整拟合区间 。
- 系统根据拟合参数自动计算经济极限产量下的累产 。
- 优点： 描述了"做什么"而不是界面如何设计，强调了工程师与系统间的业务逻辑交互 。
用例2(不好的示例)：开展油藏产量预测处理
实现让工程师非常方便地查看油井的产油量，并利用人工智能或高级数学公式准确地预测未来的产量，从而生成的报告让领导满意。
- 用例名称：开展油藏产量预测处理。
- 主执行者：油藏工程师。
- 主成功场景 ：
- 工程师点击"产量分析"按钮。
- 系统弹出一个界面，显示了密密麻麻的生产数据。
- 工程师要求系统画一张漂亮的递减曲线图。
- 系统利用 Arps 公式或其他复杂算法进行计算。如果数据太乱，系统会自动把不好的点删掉。
- 系统算出一个结果，显示出剩余可采储量（EUR）。
- 工程师点击保存，系统把数据存进后台数据库里（使用 SQL Server 存储过程）。
- 缺点： 目标模糊、混淆界面设计与业务逻辑、缺乏关键业务参数、职责错位（如系统会自动把不好的点删掉）、包含太多技术实现细节（关注做什么不是怎么做） 。
6. 总结：闭环协同模型
三者的关系并非简单的线性流水线，而是一个协同迭代的闭环：
需求分析定义范围，系统原型验证澄清需求分析，确定的需求经过系统设计进行技术反馈需求。
- 需求分析是核心，决定了项目的方向。
- 系统原型是催化剂，通过快速反馈降低需求风险。
- 系统设计是落地，将验证后的需求转化为工程实现。