企业官网建设流程全解析

第 3 章 需求工程

学习目标

• 区分系统需求与软件需求,掌握需求的分类(功能/非功能/约束)
• 掌握需求获取、分析、规格说明、验证的完整流程
• 熟悉 SRS 的典型结构与质量标准
• 理解非功能需求(NFR)的量化表达方法
• 掌握需求变更管理与追溯性(traceability)
• 建立需求度量体系

3.0 需求工程全景

需求工程(Requirements Engineering, RE)是软件工程中单位时间回报率最高的活动:这里发现一个问题,能省下下游数十倍的修复成本(第 1 章缺陷放大律)。

业务目标 │ ▼ 获取(elicitation) → 分析(analysis) → 规格(specification) 收集原始需求 建模/消解冲突/分类 编写 SRS、编号 │ │ ▼ ▼ 验证(validation/verification) ←──── 需求管理(变更/追溯/版本) 评审、原型、可追溯检查 贯穿始终

四个阶段 + 一个贯穿活动。常见失败不是"某个阶段做错",而是阶段之间工件断裂:获取的原始需求没进分析,分析的用例没进规格,规格里的条目没有 Owner。

3.1 需求的概念与分类

需求(requirement):系统必须满足的约束或义务。分三个层次:

软件需求再分三类:

1. 功能需求(functional):系统提供的行为/服务。例:“用户提交订单后生成订单号,状态为’待支付’”;
2. 非功能需求(non-functional,NFR):对功能的约束或整体属性,通常用形容词开头(“快速”“安全”“可靠”),必须量化才能验收;
3. 约束(constraint):必须遵守的技术/合同/法规限制。例:“必须部署在客户私有云”“支付必须走持牌机构”。

NFR 的九个常见类别(对照 SRS 检查用)

NFR 量化公式:属性 + 指标 + 条件 + 阈值。
反例:“系统要快”。正例:“95% 的订单查询在 ≤300ms 内返回(条件:日均 10 万单、单表 5000 万行)”。
缺任何一个要素的 NFR,在评审时都应被标记为"不可验证"。

3.2 需求获取(Requirements Elicitation)

干系人分析(获取的前置步骤)

先回答"跟谁谈",再决定"用什么谈"。

权力-利益矩阵把干系人分四象限,匹配不同投入:

常见遗漏干系人(OOS 血泪清单):仓库发货员(流程重度用户)、财务对账员(隐性用户,不做就会在对账阶段爆炸)、客服(异常处理视角)、支付网关方(外部接口方)、信息安全部(约束方)、SRE(可运维性约束)。

获取技术

组合策略:OOS 采用"文档分析(旧系统报表)→ 影子跟随(仓库 2 天)→ 访谈(财务/客服)→ JAD(运营+财务对齐改价冲突)→ 原型演示"的五步组合,单用任何一步都会漏。

获取产出物:原始需求记录(逐条、带来源人)、干系人矩阵、开放问题清单(open questions)。注意:原始记录 ≠ 需求,它只是分析阶段的输入。

3.3 需求分析(Analysis)

获取到的原始需求是嘈杂的:重复、冲突、含糊、不可测。分析阶段的任务:

1. 建模:用用例图、活动图、状态机、数据流图等刻画系统行为,使隐性需求显性化;
2. 消解冲突:如运营要求"随时改价",财务要求"价格变更留痕不可篡改"→ 分析出"改价需审批流+审计日志"的调和方案;
3. 分类与优先级:MoSCoW(Must/Should/Could/Won’t)或 Kano 模型;
4. 可行性验证:技术、成本、进度、法务四维。

冲突消解的 OOS 完整案例

冲突:运营:"大促期间价格必须随时可调,一分钟生效。"财务:“改价必须留痕、可审计,且不可追溯篡改。”

分析过程:

1. 追溯冲突到业务目标:运营要的是"促销灵活性",财务要的是"资金可审计"——目标不冲突,手段冲突;
2. 寻找调和:改价走审批流(运营发起 → 系统按金额阈值自动/人工审批 → 生效)+不可变审计日志(只追加,不改不删);
3. 量化约束:单笔改价 <5% 自动审批,≥5% 人工审批,大促期审批 SLA 10 分钟;
4. 产出两条需求(FR-PRICE-003 改价审批流;NFR-AUDIT-001 审计日志不可篡改),各自有 Owner。

经验:冲突几乎总是"手段冲突"而非"目标冲突",分析的价值在于把双方拉回目标层对话。

用例分析要点(OOS 核心用例:提交订单)

• 参与者:顾客、系统内部(库存服务、支付网关)、异常角色(风控);
• 主流程:选商品 → 生成订单(待支付) → 30 分钟未支付自动取消并释放库存;
• 扩展/异常流:库存不足、支付网关超时、重复提交(幂等)、优惠券失效;
• 前置/后置条件:登录态;订单持久化、库存预扣。

用例模板(最小字段集):

用例: UC-05 提交订单 参与者: 顾客 前置条件: 已登录;购物车非空 主流程: 1.选商品 2.确认地址 3.提交 4.系统校验库存并预扣 5.生成订单(待支付) 6.返回订单号与支付入口 异常流: E1 库存不足→提示并移除该商品 E2 重复提交→幂等返回原订单 E3 支付入口超时→订单保留,30 分钟自动取消 后置条件: 订单持久化;库存预扣;支付倒计时启动 优先级: Must 关联需求: FR-ORD-001~007

经验法则:异常路径数量通常数倍于主流程。只写主流程的 SRS 是半成品。

3.4 需求规格说明(SRS)

典型结构(参考 IEEE 830 / ISO 29148 思想)

1. 引言(目的、范围、术语、参考)
2. 总体描述(产品视角、用户特征、约束、假设与依赖)
3. 具体需求
   • 功能需求(按模块/用例组织,每条有唯一编号)
   • 非功能需求(性能、安全、可用、可维护…)
   • 外部接口(用户接口、硬件、软件、通信)
   • 数据需求(关键实体、数据保留与隐私)
4. 附录(用例详述、状态机图、接口契约)

SRS 样例片段(OOS)

#### FR-ORD-001 提交订单 描述: 顾客确认购物车后,系统校验库存并创建订单。 前置: 顾客已登录;所选商品均可售。 行为: 1. 校验库存:任一商品库存不足则拒绝(错误码 ORD-4001); 2. 库存预扣(非最终扣减),30 分钟未支付自动释放; 3. 生成订单,状态=待支付,订单号格式 ORD-YYYYMMDD-######; 4. 幂等:同一顾客 1 秒内重复提交返回同一订单。 验收标准: - 正常:库存充足时 100% 创建成功,状态=待支付; - 边界:库存=1 时两顾客并发,恰一人成功; - 异常:库存不足返回 ORD-4001 且库存不变; - 幂等:重复提交返回原订单号,不产生第二单。 优先级: Must Owner: 开发-张 追溯: BR-01

单条需求的质量标准

需求编号与追溯

为每条需求分配稳定 ID(如FR-ORD-001),建立双向追溯矩阵:

业务需求 BR-03 ──> FR-ORD-001 ──> 设计 DD-07 ──> 测试用例 TC-ORD-112

追溯矩阵的四个用途:

1. 变更影响分析:改一条 NFR,沿矩阵查出波及的功能/设计/测试;
2. 覆盖度分析:哪些需求没有测试用例(缺口即风险);
3. 合规审计:向审计方证明"每条合规要求都有实现与验证";
4. 废弃分析:业务价值消失时,连带识别可删除的实现(防"僵尸功能")。

维护纪律:追溯关系在需求/设计/测试任何一侧新增或变更时同步更新;CI 中加一个"追溯完整性检查"(每条 FR 至少一条 TC)。

3.5 需求验证(Validation)

经典定义:Verification 是"正确地构建了产品"(是否符合规格);Validation 是"构建了正确的产品"(规格是否表达了真实需要)。

验证技术:

• 需求评审:作者不主持;检查完备性、一致性、可测性;产出问题清单并闭环;
• 原型演示/沙盘推演:让客户在真实场景走流程;
• 可追溯性检查:每条需求可上溯到业务价值,每条业务价值至少有一条需求承接;
• 原型性测试:对关键 NFR 做性能基准、对关键算法做 PoC。

需求评审检查单(可直接抄用)

1. 每条需求有唯一 ID、Owner、优先级?
2. 每条 NFR 满足"属性+指标+条件+阈值"?
3. 每条需求可验证(能说出测试方法)?
4. 每个用例有异常流且数量 ≥ 主流程步骤数?
5. 无冲突(对照冲突清单逐条确认已消解)?
6. 每条需求可上溯到 BR,每个 BR 至少一条 FR 承接?
7. 外部依赖(支付/ERP/法规)均有明确契约或引用?
8. 开放问题清单已清零或已记录接受?

评审有效性度量:缺陷发现率(问题数/评审小时)。连续两期为 0 → 评审走过场,触发第 9 章的过程审计。

3.6 需求管理(Management)

需求不是"写完就冻结"的文档,而是受控的活资产:

1. 变更控制流程:提出变更 → 影响分析(进度/成本/受影响需求与测试)→ 决策(变更控制委员会 CCB 或 PO)→ 实施与回归 → 通知相关方;
2. 版本控制:需求文档与代码一样进版本库,变更留痕;
3. 优先级再排期:每次变更后重排,保持待办列表单一事实来源;
4. 度量:变更率、变更周期时间(lead time of change)、需求废弃率——用于判断过程健康度。

变更完整案例(OOS"预售定金")

T+0 提出:双 11 前 3 周,PO 提出"预售定金"功能(先付定金,尾款大促支付)。
T+0 影响分析:

• 触及订单状态机:需新增"定金待付"“定金已付”"尾款待付"三个状态,状态机从 7 态变 10 态;
• 触及支付网关协议:定金/尾款两阶段支付需网关新接口,对方排期 6 周;
• 触及库存逻辑:定金订单是否占库存?业务未定(开放问题);
• 触及测试:状态迁移用例 +20 条,支付契约测试重写;
• 进度:本版本剩余 3 周,最小工作量 4 人周,且网关排期不满足。
  T+1 决策:CCB 判定本版本拒绝,列入下一大版本;同步向 PO 反馈三个前置条件(网关接口、库存策略、售后规则)需先澄清。
  T+1 记录:CR-014(状态:拒绝,理由:外部依赖排期 + 状态机风险),通知业务方与测试组。

此例展示变更控制的完整价值:不是"说否",而是把决策的依据、代价、前置条件显性化。拒绝也是变更控制的产出。

3.7 需求度量

用法:月度回顾看趋势;变更率持续高位 → 检查是"需求真的在变"还是"获取/分析质量差"(后者可通过干系人覆盖度验证)。

3.8 常见反模式

3.9 本章 FAQ

Q1:用户故事能替代 SRS 吗?
小项目可以;资金/合规/外包合同场景不行。故事擅长"行为 + 验收",弱在"NFR 系统量化、接口契约、合规追溯"。OOS 的做法:日常功能用故事,对账与资金链路维护正式 SRS 片段(如 3.4 样例)。

Q2:需求什么时候算"分析完了"?
满足:干系人矩阵 100% 覆盖关键方;冲突清单清零;NFR 全部量化;每条 FR 有 Owner 与追溯;评审检查单(3.5)通过。"分析完了"是可检查的状态,不是感觉。

Q3:如何防止"需求镀金"(加没人要的功能)?
两条:每条 FR 必须上溯到 BR(无 BR 的 FR 默认拒绝);定期做"废弃分析"(3.4 用途 4),删僵尸功能。

Q4:业务方"说不清需求"怎么办?
三个技巧:① 用具体场景代替抽象提问(“客户同一天买了两单,你希望看到什么?“而不是"展示规则是什么?”);② 给选项让对方选(A/B/C 三案带代价对比,比开放式问题收敛快);③ 用原型反问(做出具体效果问"是这个意思吗?”)。三者都失败时,记录为假设(assumption + 有效期 + 确认责任人),不让它悬空——悬空的假设是需求阶段最大的暗雷。

Q5:如何区分"合理变更"与"范围蔓延"?
看三个判据:是否对应业务价值(能上溯 BR?)、代价是否被看见(做了影响分析?)、频率是否异常(单迭代 CR 连续三期超基线 → 检查获取/分析质量,而非一味拒绝)。变更控制管的是"流程",不是"变更的存在"——把变更控制当拒绝工具用,团队会学会绕着它走,更糟。

Q6:用户故事的验收标准写到什么程度算够?
判据是"不用口头解释可测试":测试工程师能据此直接写出用例,开发能据此判断做没做完,且双方对"通过/不通过"没有第二种理解。需要口头解释的地方,就是还不够细的地方。常见不足:只写主路径(缺异常)、只写行为(缺数据边界)、用"等"字收尾(“支持 A、B 等优惠”= 不可验证)。

3.10 小结

• 需求分业务/系统/软件三层,软件需求分功能/NFR/约束三类,NFR 必须量化;
• 获取靠干系人分析(权力-利益矩阵)+ 多种技术组合;分析靠建模与冲突消解;
• 规格靠可验证的原子化条目 + 唯一 ID + 验收标准;
• 验证靠评审(检查单)与演示;validation 与 verification 区分;
• 需求是受控资产:编号、双向追溯、变更控制;
• "构建正确的产品"比"正确地构建产品"更贵,需求阶段是回报率最高的投资。

思考题

1. 把以下需求改写为可验证形式:“系统性能要好,界面要友好,数据要安全。”
2. 为什么"异常路径数量通常数倍于主流程"?用"提交订单"用例列出至少 5 条异常路径。
3. 追溯矩阵在需求变更场景中的具体操作是什么?画出一个三层的追溯关系示例。
4. OOS 中"预售定金"变更被拒绝——如果 PO 坚持,变更控制流程应如何演进?
5. 用权力-利益矩阵分析你所在项目的干系人,指出最容易被遗漏的一个象限及对应的人。
6. 设计你所在系统的一条 NFR,满足"属性+指标+条件+阈值",并写出它的测试方法。
7. 为什么"评审缺陷发现率连续为零"应触发审计而不是庆祝?
8. 故事 + 验收标准 + NFR 表 的组合与完整 SRS 相比,缺什么?在什么项目下这个缺口可接受?