📚 课程目录第4章需求工程概述

4. 需求工程概述

在网络安全与合规证据工程中，需求工程不是“写一份需求文档”这么简单，而是一条贯穿项目全生命周期的证据链起点。需求一旦含糊、遗漏或不可验证，后续的设计、开发、测试与合规举证都会失去锚点。本节围绕需求获取、分析、规格说明、验证与管理五个环节，梳理标准流程、常用方法与落地要点。

核心结论：需求工程的本质是把“利益相关方的期望”转化为“可验证、可追踪、可变更控制的规格说明”，并让每一条安全与合规需求都能在后续阶段找到对应的设计、实现与证据。

一、核心原理：五阶段闭环与双向追踪

需求工程通常被划分为五个相互衔接的阶段：需求获取（Elicitation）、需求分析（Analysis）、规格说明（Specification）、需求验证（Validation）和需求管理（Management）。它们不是一次性瀑布，而是带反馈的迭代闭环：验证发现的问题会回流到分析与获取，管理则贯穿始终，负责基线、变更与追踪。

在安全合规场景中，双向追踪（Traceability）尤为关键。正向追踪确保每条需求都能落到设计、代码、测试用例和证据；反向追踪确保每个安全控制、每条日志、每份审计证据都能回溯到某条需求或合规条款。没有追踪，合规举证就会变成“事后补材料”，风险极高。

二、方法流程：从获取到管理的操作要点

需求获取阶段，常用方法包括半结构化访谈、问卷调查、现场观察、文档分析、头脑风暴、原型演示和场景走查。安全合规需求往往隐藏在业务流程、监管条款和事故复盘中，因此不能只问“你要什么功能”，还要问“出了事你要能证明什么”。

需求分析阶段，重点做分类、优先级排序、冲突消解和建模。安全需求可按功能安全、数据安全、身份与访问、审计与监控、供应链安全等维度分类；优先级可用 MoSCoW（Must/Should/Could/Won't）或 Kano 模型。冲突消解要识别“业务便利”与“安全控制”之间的张力，例如单点登录与多因素认证的体验冲突。

规格说明阶段，输出软件需求规格说明书（SRS）、用户故事、用例或需求条目。每条安全需求应包含：编号、描述、来源、优先级、验收标准、合规条款映射、验证方法。验收标准建议采用 Given-When-Then 格式，便于后续测试直接引用。

需求验证阶段，通过正式评审、原型确认、检查表和测试用例追溯来确认“需求是否正确、完整、一致、可验证”。安全需求尤其要验证可测试性，例如“系统应安全”不可验证，而“所有管理员登录必须启用 MFA，失败 5 次锁定 30 分钟”可验证。

需求管理阶段，建立需求基线，执行变更控制流程，维护需求追踪矩阵（RTM），并跟踪需求状态（提出、批准、实现、验证、关闭）。变更必须做影响分析：改一条需求会影响哪些设计、代码、测试和合规证据。

三、常用方法对比与适用场景

方法	主要用途	优点	局限
访谈	获取深层期望与隐性合规要求	信息丰富、可追问	耗时、依赖受访者表达
问卷	大范围收集共性需求	成本低、可量化	难以挖掘深层问题
文档分析	提取监管条款与既有制度	来源权威、可追溯	可能过时或不完整
原型	验证界面与流程类需求	直观、反馈快	易被误认为最终方案
追踪矩阵	管理需求与证据的双向关系	支撑合规举证与变更影响分析	维护成本较高

四、案例场景：等保合规需求的一条链路

某金融系统需满足等保三级“身份鉴别”要求。获取阶段，安全团队从监管条款和访谈中提炼出“管理员登录需强身份鉴别”。分析阶段，将其拆分为口令复杂度、MFA、失败锁定、会话超时四条子需求。规格说明阶段，写入 SRS 并映射到等保条款 8.1.4.1。验证阶段，评审确认每条都有验收标准，并生成测试用例 TC-AUTH-01。管理阶段，建立 RTM，把需求、设计、测试、登录日志证据关联起来。后续若监管条款更新，变更影响分析可快速定位受影响的设计与测试。

需求条目示例（SRS 片段）：
REQ-ID: SR-001
描述: 管理员登录必须启用多因素认证（MFA）
来源: 等保三级 8.1.4.1 / 安全团队访谈
优先级: Must
验收标准:
  Given 管理员访问登录页
  When 输入正确口令
  Then 系统必须要求第二因素，且失败 5 次锁定 30 分钟
合规映射: 等保 8.1.4.1
验证方法: 测试用例 TC-AUTH-01 + 登录审计日志

实践建议：把“合规条款”当作需求来源之一，而不是事后检查项。每条安全需求都问三个问题：谁提出？怎么验证？留下什么证据？这三个问题能显著提升需求的可追踪性与可举证性。

五、误区与复盘

误区一：需求获取只找业务方。安全合规需求还需纳入法务、合规、审计、运维和外部监管要求，遗漏一方就可能导致证据链断裂。
误区二：需求描述不可验证。“系统应安全可靠”无法测试，必须转化为可度量、可观察的验收标准。
误区三：规格说明写完就冻结。合规条款和业务会变化，必须建立变更控制与影响分析机制。
误区四：追踪矩阵只在审计前补。RTM 应在需求基线建立时同步维护，否则变更影响分析和证据回溯都会失真。
误区五：验证只做评审。评审之外，还应通过原型、测试用例追溯和需求覆盖率检查来验证完整性与一致性。

复盘要点：需求工程的质量直接决定合规证据工程的上限。若需求阶段缺少可验证标准与追踪关系，后续再完善的测试和日志也难以证明“控制有效”。建议在项目启动时即定义需求模板、追踪矩阵和变更流程，并指定需求负责人。

综上，需求获取、分析、规格说明、验证与管理构成一个持续迭代的闭环。对网络安全与合规证据工程而言，关键不只是“写出需求”，而是让每条需求都具备来源、验收标准、合规映射和证据去向，从而在后续设计、开发、测试与审计中形成完整、可追溯的证据链。