需求工程

上一节决定了项目怎样组织迭代。现在，活动组织方提出一个变化：100 个座位报满后，希望学生可以候补，已有报名者取消时按队列递补。开发人员可以立即加一个按钮，但按钮背后的顺序、重复报名、并发争位和通知失败还没有说清。需求工程要把这句话变成各方能理解、能检查、能控制变化的约定。

我们沿用虚构校园报名项目。原需求 R17@1.0 规定“满员拒绝”，已经评审批准，属于需求基线 B1；新提议编号 CR08。读这一节时，可以分别看三个问题：这句话要求什么，谁有权让它改变，怎样知道改动落实到了正确的成果中。教材 5.2 总论以及获取、变更、跟踪三个小节，正好把这条线展开。

一句需求，可以从几个角度判断

组织方想减少空座和人工补录，这是业务需求，回答投入软件要达到什么目标。学生希望加入候补、取消已有报名，这是用户需求，回答使用者要完成什么任务。软件必须登记候补、按顺序分配空位并通知，这是落实任务所需的系统行为。教材把第三层称为功能需求，同时在需求规格说明中补充非功能要求。三层把目标展开成任务，再落到软件要求；不能据这个层次画出“功能包含非功能”的内容分类树。

换到内容角度，“取消后按序递补”规定行为，属于功能要求；“在约定负载和网络环境下，95% 的候补请求两秒内响应”规定运行表现，属于性能要求；“采用校方指定数据库”限制实现选择，属于设计约束。实际规格还需写清负载数量、计时起止、样本窗口和超时计法；图中的“指定负载”只是这些条件的占位。100 座虽然有数字，仍在规定允许报名的人数。分类要看数字限制的对象。功能需求可以只写外部行为，无须先指定数据库锁或编程语言。

性能和数据库只是对照例子。规格还会补充标准规范、外部接口、质量属性，以及设计或过程限制；具体归类仍要读陈述内容。例如安全可以要求质量水平，也可以规定登录失败时锁定账户的行为，不能见到“安全”就只按一个盒子分类。

“候补特性”又是什么？它可以包括入队、退出、递补和通知等逻辑相关的功能需求。特性回答怎样把关联功能组成一个可理解的能力，并没有把需求重新划成业务、用户、功能三个互斥盒子。

Kano 分类是本节的扩展。它观察某项功能或质量的满足程度怎样影响用户满意：基本需求缺失会引起不满，满足后通常只达到预期；期望需求满足得越充分，满意度越高；兴奋需求提供时带来额外满意，缺失时未必引起不满。类别需要涉众反馈和条件，不能仅凭“用户明确要求”判基本，也不能把质量指标排除在模型之外。同一特性的评价还可能随人群和时间变化。这个解释按 ASQ 的 Kano 教程校准，不能用来补全信息不足的旧题。

编号、版本、来源、作者、状态、优先级和稳定性则是需求的管理元信息。它们帮助团队找到“哪条需求、哪个版本、现在到哪一步”，并不替代需求内容。所有需求都标最高优先级，会失去取舍依据。可验证要求有清楚的满足判据；可追溯要求能找到来源和相关成果。两者可以同时具备，也可能只有一种：一条写有明确响应时间却没有来源记录的需求可测试，但追踪仍有缺口。

获取需求，先找信息缺口

CR08 的“按顺序”还不够具体。是每个活动独立排队，还是全校共用一条队列？同一学生重复点按钮会不会重复入队？两个请求同时争一个空位时，怎样保证只分配一次？通知失败后席位是否仍归已递补学生？这些问题需要涉众达成约定，不能留给开发人员凭个人理解决定。

教材给出六步参考过程：开发高层业务模型，定义项目范围与高层需求，识别用户角色和代表，获取具体需求，确定目标业务工作流，整理与总结。在第二步，可以用上下文图或顶层用例模型说明系统边界；第三步除学生和管理员外，还要考虑身份认证应用、通知网关等交互对象。不同项目可以回访前面的工作，发现新的角色后再补范围。六步提供组织线索，并不要求所有项目只走一遍。

获取方法取决于缺什么信息。面谈适合深入询问管理员怎样人工补录；现场观察可以发现“实际会在开场前锁名单”这类口头遗漏。学生要求较长确认期，组织方担心空座时，专题讨论会把冲突放到同一场合协商。问卷适合验证通知方式偏好等已有假设，却难以追问一句模糊回答。界面或报表说不清时，可以让涉众操作原型；新业务没有现成方案时，头脑风暴先发散，再检查价值与可行性。这些方法可以组合，也可以用于同一步骤。

把获取到的信息建立模型，是需求分析；写成清楚的规格说明，是文档化；评审其完整、正确、一致、可行和可测试，是需求确认与验证。比如，一条说“只能有一个有效报名状态”，另一条又允许“已报名者再次入候补”，规格就存在冲突，应在这里澄清。检查 SRS 的质量，与交付时验收运行系统，所检查的对象不同。

这条线也产生不同文档。用户原始需求说明书先记录目标、任务和原始诉求，用于和用户建立约定；经分析、细化和澄清形成的软件需求规格说明书 SRS，描述开发所依据的软件要求。二者有来源联系，不能把原始口头提议直接视作已分析批准的 SRS。

基线、变更、版本，各自解决什么问题

初稿尚未批准，也已经需要编号、版本和来源，否则两位分析人员可能讨论的是不同草案。教材明确：初始需求导出时开始管理规划，初稿形成后就开展管理。基线回答的是“现在批准用哪一组要求作为参照”，版本回答“这份内容是哪次修订”，状态回答“草案、批准、实现、验证中的哪一步”，追踪回答“它和哪些来源、成果有关”。这些管理活动可以同时进行。

B1 已批准“满员拒绝”。CR08 提出变化后，先完整记录问题和预期，再沿联系链分析影响与全部改动成本。候补可能影响数据结构、接口、并发一致性、通知、回归用例、管理员帮助和项目进度。只估算新增按钮的工时，会漏掉后面这些工作。业务提出者说明目标，分析人员澄清，各专业评估受影响范围，项目经理协调资源和计划；角色名称可以因组织而异，责任要有人承担。

教材把需求变更处理概括为描述、影响分析、决策后实现三个步骤。图中将最后一步展开，是为了看清批准和执行的区别。CCB 代表有关权益，在章程授权范围内裁定接受哪些变更；超出权限要升级。它需要影响和成本证据，也需要工程人员提出可行方案，通常不替团队编制作业步骤。工具可以记录状态、限制修改权限，却不能凭“已有一条追踪记录”替人完成这项决定。

如果拒绝，保留原始请求和理由；如果延期，保留待再评的状态。评估过程已经消耗了成本，不能因没有实施就抹去记录。未批准的变更不进入设计实现。敏捷项目也需要控制，可以经相应授权安排到后续迭代；具体责任与规则按项目约定，参见敏捷的响应变化。

决定作出后，要指定人员更新请求状态并及时通知有关人员。重要变更可能要求重新协商范围、人员、进度或质量约定；批准一个请求，还需要让受影响的人使用同一个新计划。

假设 CR08 获准，我们保留需求身份 R17，把修订内容记作 R17@1.1，重新确认并批准相关需求集合为 B2。B2 仍包含没有变化的有效需求；B1、R17@1.0 和原 CR08 留在历史中。旧版本“被当前基准替代”不等于物理删除，也不要求改名成一条新的需求。随后设计、代码、测试和帮助文档协调更新。它们可以分先后完成，必须在受控交付时保持一致。

需求管理关注需求的内容、版本、变化、状态和联系；配置管理控制的制品还包括设计、代码、测试等。需求规格书可以同时是需求管理的对象和配置项。一次批准并不会让所有相关制品立即实现完毕，配置状态记录要能反映这种差别。更完整的配置项、库与审计见5.7 配置管理。

同一张关系网，可以向两个方向检查

从 R17@1.1 出发，检查它有没有对应的设计、实现和测试，是正向跟踪。下面从 T10 出发，查这个并发测试依据哪项要求，是逆向跟踪。两种检查结合，就是双向跟踪。旧题只描述需求到后继成果时，答案应抓住正向这个条件；不能因此把“双向”当作非法术语。

这里一个需求联系多个成果，一个测试也覆盖多个需求。表中的 ID 是教学示例，连线表示“设计、实现、验证或说明这项要求”，与程序调用流不同。CR08 的批准请求也应关联到受控改动，便于解释为什么发生变化。术语资料对不同端点的“横向”用法可能不同，判断时直接说明连接的对象，避免用一个方位词代替关系含义。

追踪矩阵让 CR08 的影响范围可查，但矩阵打勾只证明登记了对应关系。T10 对应 R17，不等于 T10 已执行；执行了也还要检查是否针对当前版本、结果是否通过、相关缺陷是否解决。若矩阵停留在 B1，就可能漏掉候补功能新增的并发条件。版本、状态和真实验证记录共同决定证据是否有效。

逆向检查发现无来源的功能时，应先澄清它的理由：可能是遗漏的质量要求、必要的内部支撑，也可能是未获准增加的业务范围。不能要求每一行工具代码都单独编一条用户任务，更不能把所有无映射功能直接算作合法扩展。可追踪性帮助提出问题，仍需要分析和授权处理。

再看 CR08，问题已经变得具体

候补提议先被拆成目标、任务和软件要求，用适当的获取方法澄清规则；需求确认使这些约定可理解和检查。基线给出批准参照，变更控制决定是否修改它，版本与状态保留演进过程，追踪把影响传到设计、实现、测试和文档。每个名词都对应一个工程困难，同一项目中可以同时使用。

下一节要把 R17 的行为约定变成分析模型和设计方案。需求可以规定“一个空位只能分配一次”；怎样组织对象、选择数据结构和实现并发控制，还要在分析与设计中比较。已经澄清的需求让这些选择有依据，后面的模型与验证证据又能反过来暴露需求缺口。