软件分析与设计笔记 16：从 persona 到 URS：一份交付物的完整骨架

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。前面十几篇的产出，这一篇把它们装订成一份能交出去的东西。

0 每一环都会做，拼起来还是乱

前面十几篇把每个环节都讲过一遍了。真到要交东西的时候，新的问题出现了：

• 该交几份文档？哪些内容放哪一份？
• 活动图和派单台线框算「需求」还是「设计」？
• 小林的画像前面画过了，报告里要不要重画？

这一篇讲怎么把这些产出装订成一份交付物（deliverable）。它同时也是整个系列前半部分的收口。

1 URS 的九个部分

1.1 九个部分与各自的确认方

用户需求规格说明书（User Requirement Specification, URS）是按这个骨架组织的：

1.2 为什么「谁来确认」这一列最重要

这张表最值得注意的是第三列。每一章都有明确的确认方，这不是形式 —— 如果某章找不到该确认它的人，那一章大概本来就不该出现在文档里。

本例里最容易出问题的是第 6 章（活动图 + 屏幕设计）。团队一开始打算把这一章的确认方写成「开发」，理由是「线框图是给开发看的」。后来改成「业务方 + 开发」——因为派单台那个界面，只有小林能判断对不对。开发只会告诉你「这做得到」，不会告诉你「这不是我想要的」。

第 3 章（画像与旅程）本来就没有确认方 —— 它是内部工具，不是给业务方签字的东西。这一章放进去的理由是「它能让第 4 章说得通」，而不是「有人要确认它」。这个例外值得记下来：不是每一章都必须有外部确认方，但每一章都要有存在理由。

2 为什么是这个顺序

这个顺序不是编辑习惯，而是依赖关系：

• 第 2 章（范围）决定了后面所有内容的边界；
• 第 3 章（用户画像与旅程）是第 4 章（用户故事）的来源 —— 每条故事都能指回画像的某一栏；
• 第 4 章的故事汇成第 5 章的用例，第 6 章再把用例展开成流程与界面；
• 第 7 章的非功能需求作用于第 5、6 章里所有的操作；
• 第 8 章的测试用例从第 4 章的验收标准推导。

如果某一章写不出来，通常不是文笔问题，而是对应的那一环没做到位。比如写不出第 4 章，往往是因为第 3 章的画像只有人口统计信息，没有行为和痛点。

本例里这条判断救过一次：第 8 章（测试用例）一开始写得很空，只有「派单成功」一条。回去检查才发现第 4 章的验收标准只写了正常路径，没有任何边界或负面场景。改完验收标准，第 8 章自然就填满了。

这个链条是单向的：下游写不出来，问题一定在上游。

3 提案：面向决策者讲什么

3.1 要讲清的三件事

URS 之外，通常还要做一次提案演示（presentation）。它的目标不是展示工作量，而是让对方相信三件事：

1. 现状的痛点。 现在的系统/流程具体在哪些地方付出代价（返工、差错、客户流失）；
2. 技术如何解决它。 引入什么、解决哪一条痛点 —— 一一对应，不要泛泛谈「数字化」；
3. 你理解了用户。 挑一个关键用户，讲他的画像与旅程图，以及你打算在哪一步改善他的体验。

第三点是很多提案的短板。前两点讲的是「我们懂技术」，第三点讲的是「我们懂你的业务」——决策者真正在判断的往往是第三点。

本例的提案可以严格按这三条组织，而且每条都有具体数字：

注意第二行每一条都对应第一行的一条。这就是「一一对应」的意思 —— 如果某条技术没对应任何痛点，那它就该被砍掉。

3.2 不确定的技术点怎么办

如果方案里有不确定的技术点，提案里通常还要给出可行性（feasibility）说明：先靠一个小规模的概念验证（proof of concept）跑通关键假设，再谈全面铺开。

本例里有两个这样的点，而且它们的处理方式不一样：

第一个点值得特别注意：主动说出「我们做不到」比硬做更能赢得信任。因为它显示你真的看过数据，而不是随便承诺。

4 三条自查规则

在交出去之前，用这三条过一遍：

① 每一章都能指出它的上游产出。 写不出上游，说明这一章是拍脑袋来的。

② 每条需求都能追溯到一个人或一份数据。 「这条需求是谁提的？还是我们自己想的？」—— 可追溯性（traceability）是需求文档的基本功。

③ 每条需求都能写出验收标准（acceptance criteria），也就是能定义验收（acceptance）怎么做。写不出来的，要么需求本身不清楚，要么它其实是设计方案。

第二条在本例里有个诚实的例子：「工单优先级（红黄绿）」这条需求，追不到任何用户 —— 它是团队自己加的。这不算错，但要在文档里标出来「这是我们的推断，待验证」。装成是用户提的，才是最坏的做法。

5 常见的四个问题

• 把方案写进需求。 「用消息队列异步处理」是实现方案；需求只该说「提交后 2 秒内给出结果」；
• 范围和版本混在一起。 本期做什么、下期做什么要分开写，否则验收时一定吵架；
• 只有正常流程。 例外流程和负面场景往往才是工作量的大头；
• 缺少「不做」的清单。 out of scope 比 in scope 更能节省后期的沟通成本。

本例里第三条的具体代价：如果第 4 章的验收标准只写「正常派单」，那 10 篇讨论出的「缺料 → 待件挂起 → 通知改约」这条主线上的例外就不会被实现 —— 而它是整个流程最复杂的部分。

本节自测

1. URS 的九个部分里，哪些是「需求」，哪些已经接近「设计」？边界怎么划？
2. 如果写不出用户故事那一章，最可能的原因是什么？
3. 面向决策者的提案，为什么要专门讲一个用户的画像与旅程？
4. 什么是需求的可追溯性？它解决什么实际问题？
5. 为什么 out of scope 清单往往比 in scope 更有价值？
6. 本例里第 6 章（活动图 + 屏幕设计）的确认方，为什么从「开发」改成「业务方 + 开发」？
7. 「第 8 章写得很空」这个现象，应该往上游查到哪一章？为什么？
8. 提案里主动说「这一版做不到预测」，为什么反而更能赢得信任？

参考答案

1. 第 1–5 章是需求（概述、范围、画像、故事、用例），第 6 章开始接近设计（活动图与屏幕设计已经涉及「怎么做」），第 7–8 章是质量与验证。边界在于：是否开始约束具体做法（§1.1）。
2. 最可能是第 3 章的画像只有人口统计、没有行为和痛点 —— 故事是从画像的某一栏推出来的（§2）。
3. 因为前两点讲「我们懂技术」，第三点讲「我们懂你的业务」—— 决策者真正在判断的往往是第三点（§3.1）。
4. 每条需求都能追到一个人或一份数据（谁提的、依据什么）。它解决的实际问题是：防止团队自己编的需求混进文档，以及在变更时能说清这条需求的来历（§4）。
5. 因为它直接消掉后期一半的争执（「这个当初是不是说了要做」），而且它逼你说出「做不到的事用户怎么办」（§5）。
6. 因为派单台那个界面只有小林能判断对不对。开发只能告诉你「这做得到」，不能告诉你「这不是我想要的」（§1.2）。
7. 要查到第 4 章的验收标准。因为测试用例是从验收标准推导的 —— 第 8 章空，说明第 4 章只写了正常路径，没写边界与负面场景（§2）。
8. 因为它显示你真的看过数据（06 篇：只有 8 个月数据、没有季节性记录），而不是随便承诺。硬做预测反而会在上线后露馅（§3.2）。

术语表