赛孚希软件工程 · 需求管理系列 03
上一篇，我们介绍了 LiveDocs 的一个核心特点：按文档阅读，按条目管理。
但你可能还会问：
从一个问题开始
给需求加个编号，再填几个字段，
到底能带来多大变化？
我们用一个项目中的常见场景，把一条需求从提出、评审到变更和验证的过程走一遍。
以下为演示案例，编号、人员和数据均用于说明管理过程。
PART 01
一句话，如何成为可管理的对象？
假设我们正在开发一套设备监控系统，需求规格说明书中有这样一句话：
系统收到超温事件后，应在 2 秒内在监控界面显示报警。
在 LiveDocs 中，可以将它作为一条需求工作项管理：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
正文依然位于“报警功能”章节，读者可以结合上下文理解它。同时，这条需求有了独立身份，可以被分配、评审、查询和关联。
优势 01 · 管理粒度更细
从管理“一份文档”，
细化到管理“这一条需求”。
PART 02
评审意见，直接落到这条需求上
评审时，测试工程师提出：
“2 秒从什么时候开始计算？是设备检测到超温，还是监控系统收到事件？”
开发工程师补充：“报警显示，是出现文字就算完成，还是必须同时显示设备编号和发生时间？”
这些问题如果只留在会议纪要或聊天记录里，过几天就容易与原需求脱节。
在 Polarion 中，团队可以围绕这条工作项记录讨论和审批意见，再据此完善需求：
自监控系统接收到超温事件起，2 秒内在监控界面显示报警。报警信息应包含设备编号、事件类型和发生时间。
配合项目配置的审批与工作流，这条需求可以从草稿进入评审，再进入已批准状态。
后来接手的人，可以沿着这条需求查看讨论与记录，理解它为什么写成现在这样。
优势 02 · 决策过程有依据
需求正文保存结论，
相关记录帮助理解结论的来由。
PART 03
需求一改，知道该检查谁了
项目进行到一半，客户提出：“报警响应还要更快，改成 1 秒。”
DEMO-101 · 需求变更
2 秒 →1 秒
把正文中的“2”改成“1”，只需要几秒。真正的工作才刚开始：接收处理是否需要优化？界面刷新机制能否满足？哪些测试用例要修改？
假设团队已为 BBB-214 建立关联：
• 软件需求：报警事件处理
• 软件需求：报警界面刷新
• 测试用例：报警显示时限验证
工程师可以从这条需求出发，沿关联逐项检查影响；结合历史记录，查看修改前后的差异。
优势 03 · 变更检查有路径
变更讨论有了具体的检查清单，
减少对个人记忆的依赖。
系统只能帮助检查已建立的关系。关联是否完整、哪些地方需要修改，仍然需要工程人员判断。
PART 04
测试通过，证明了哪一版需求？
原先的测试已经执行，实测报警显示耗时为 1.6 秒。对于“2 秒内显示”的要求，这个结果是通过的。
但需求改成“1 秒内显示”之后，同一个结果就无法证明新要求已满足。
同样是 1.6 秒：
原要求 ≤ 2 秒：满足。
新要求 ≤ 1 秒：不满足。
如果需求和测试结果分散在不同文件里，一句“之前已经测过了”，很容易让人误判进度。
通过关联需求、测试用例与测试执行记录，团队可以进一步核对：测试条件有没有更新？执行依据是哪一版需求？当前结果能否支撑交付？
在这个案例中，团队需要更新测试判定条件，完成必要修改后重新执行，并记录新的结果。
优势 04 · 验证结论有证据
关联了测试，
不等于当前版本已经验证通过。
PART 05
需求多了，直接找出待处理条目
单条需求的信息完整之后，项目管理也能更具体。例如，项目经理希望了解：
“报警模块里，哪些高优先级需求还没有批准？”
团队可以根据实际配置的字段，在工作项列表中组合筛选条件，查看符合条件的需求、负责人和状态。
负责人打开其中一条，可以继续查看正文、讨论和关联对象；回到 LiveDocs，又能结合章节理解其背景。
这些视角围绕的是同一批工作项，减少了另外整理一份状态台账的工作。
优势 05 · 一次维护，多处使用
同时服务于文档阅读、
个人处理和项目跟踪。
PART 06
一条需求的价值，体现在整个过程中
回头看 BBB-214：从一句描述开始，明确责任；通过评审澄清边界；发生变更时检查下游；最后用对应版本的测试结果证明是否满足要求。
编号、字段、状态和关联，把这些工作连接在了一起。
工作项管理的真正价值
面对一条需求，能继续回答：
谁负责、谁确认、改过什么、
影响哪里，以及凭什么证明已满足。
需求数量越多、参与人员越多、变更越频繁，这种管理方式的作用就越明显。
赛孚希软件工程
需求管理系列 · Polarion 工作项