《A++ 敏捷开发》- 18 软件需求

需求并不是关于需求 (Requirements are not really about requirements)

大家去公共图书馆寄存物品，以前都是扫二维码开箱，有些图书馆升级了使用指纹识别。

"是否新方法比以前好？"我问年轻的开发人员。

"当然用指纹识别好。新技术！现在已经很少看到使用条码的系统了。"

"如果取物时指纹识别失败怎么办？以前还有条码纸条作为凭证，找管理员人工开箱处理，但用指纹识别的话，就无法证明自己是寄存那个人，甚至连寄存在哪箱都可能忘记了。而且指纹识别的错误率比条码高，所以虽然是新科技，成本也提升了，但未必带来价值。"

每次培训，我都会用这例子提醒学员需求并非只谈需求，必须为拥有它的人提供最理想的价值。有些产品经理混淆了解决方案与需求本身："寄存需要用指纹识别开箱"，

但如果把需求写成："让寄存者取得凭证，之后用来开箱"

设计师就不一定选择用指纹识别，它只是其中一种方案。

如果希望IT系统给用户带来价值，就需要从整个业务全面分析，有些需要由IT系统支持，有些不需要。

下面会举例说明。

很多团队都未能做好以下3点：

• 需求分析
• 识别关键干系人
• 非功能性需求

需求分析

业务用例，包括产品用例，可以帮助我们分析整个业务流程，确保能为业务产生价值。

使用下面的模型，可以有效地按以下顺序系统地分析与设计业务用例（Business Use Case BUC) 、产品用例 (Product Use Case PUC)。

• 现在业务流程(Now,How)
• 现在业务用例(Now,What)
• 未来增强后的业务用例(Future,What)
• 未来的产品用例(Future,How)

例如：线上在超市购物，产品用例就包括处理买家的结账请求，连接信用卡数据，更新买家的购物历史和等待发货的订单信息。但业务用例就包括系统以外的其他配合工作，包括：超市员工在货架上按订单取货，联系物流公司把货品送到买家地址。

首先描述现在的处理方式（左下角）。

在左上角描述现在业务用例，柜台处理的方式，然后在右上角想象用了系统后，网上选购与下订单的未来业务用例，哪些流程应该在线上做更容易（右下角）。

"刚年底审查了我们某针对医院临床软件系统，发现整年开发的功能中，有86%都未被使用。"

我们从而了解到，把需求分优先级很重要，所以要制定开发什么功能，集中精力这些会被使用的20%功能，而不是浪费时间在开发完都没有用的80%功能。

有人提出，其实可以反过来看，怎么筛选哪些功能不应该做，可能更容易。

但应怎么筛选呢？

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 某家专门做高端安防系统的P公司，为一家大卖场S公司开发一款廉价的安防系统，如下： 签订合同后两个月，开发团队已经开始设计和编程，S公司的代表提出以下新需求："增加了一个需求即能够很精确的定位入室的盗贼的位置；以及他的去向，还可以检测出该盗贼就屋里呆了多久。" 请问你作为产品经理会如何反应？ 我的经验，有百分之八十的学员都会说让我和工程部先内部沟通，再回应是否能实现？费用是否增加？加多少？ 我说："如果你很有经验，你应该立马问客户先生为什么要做这个需求，因为你不用问工程部，已经可以猜出来开发这个功能需要大量的成本和时间，但未必有价值，如果你当成问客户他也提不出对业务的重要性，你应当场拒绝。" --==+++==-- "增加一个缺失的需求去检测损坏的窗口"很多学生会立马问（因为刚刚听完第一条的解读。）："客户为什么要做这个功能？" 客户说："如果系统能够识别出破碎的窗户，便可以报上保险公司申请节省时间。" 但如细心想想，这需求其实是不可能实现，因为系统只能从传感器检测到波动的幅度，但无法判断是否破损（例如：不碎玻璃）。 |

从以上例子看到产品经理不仅仅是传话，要利用业务的知识，了解和过滤需求，拒绝没有价值的需求。

需求人员过滤了不合理的需求后，还是要分析成本和给客户的价值，对价值比成本高的需求分优先级。

|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。 |

以上面储物柜故事举例：

因为指纹识别成本高，但没有提供更多价值，所以不应该做。

用例与场景

用户故事针对"做什么"与"为什么"（"What"，"Why"）； 场景针对"如何做"（"How"），例如普通市民用手机程序搜索下周一央视7台有什么节目。所以它们之间是互补，没有冲突。每个需求都应考虑各类场景，以银行个人用户用银行卡去ATM机取款为例：
正常情况 ：使用个人银行卡取300元
其他可选情况 ：从其他银行卡取款
异常情况：取款后没有及时取回银行卡，导致吞卡

正常场景是基础；但如果没有全面考虑各种场景便会导致最后开发出来的产品不满足客户需求。

实例：护照到期续证

比如我们护照更新，以前是要到柜台手工办理，如果我们把那个过程数字化，让市民可以在线做，不需要亲身到柜台办理。应怎样做呢？

某国家的做法是本来的手工填写模板直接变成系统页面（每个输入与手工表格一一对应），申请人在系统里按本来模板填写并提交，上传个人新照片，也是经过系统，我有一次尝试用系统线上填电子表单申请，但因表单很繁琐，有很多护照原有信息都需要重新填写，光是填那表就花了我接近一个小时，最大问题还不是在我花时间填手工表，而是最后要上传照片，因为照片像素高的话就很大，需要很好的网络才可以传得上，如果照片像素小，便导致模糊不清，不能通过。最后，一个半小时后，我用尽所有方式都还是无法传上照片，我最终放弃了在线上提交申请，直接预约去在柜台做!

之前描述的整个过程只是把原有的手工步骤信息化,和原本的申请手续一样。但线上办理和在柜台现场办理不同，在现场你可以要求对方直接把照片给你，也可以要求对方提供老护照，但在线上办理，应很容易从系统里找到个人护照信息，所以很多本来在柜台要手工填写的老护照信息就不需要再填了。

客户：怎么可以简化整个过程？最困难应是照片的更新？

我：有些国家是这样做法，比如你申请续证，只需要填上老证件的基本信息，系统就立马能识别出本来的证件 你确实有那个"旧"证后，便可立马提交申请。跟在网上购物一样，你确认过内容没问题，就在网上付费，然后打印申请表并在表上亲手签字，然后附上几张符合规格的照片，邮寄到政府机关。他做好新证件以后再邮寄回你。或者你自己到他规定的地点领取也可以。这样就能很简单地利用"低"科技解决方案，解决了刚才上传照片的困难。

从上面例子看到，我们应不仅是把那些本来手工的流程自动化，应该全局看要解决的问题本身，哪些过程自动化，哪些不应该自动化（比如传照片）。

甲方对怎么可以在线上做这个过程也没有概念，他只是知道，本来手工需要填表。

乙方也不知道，他只是做开发，也不知道有什么方面可以不用IT方式，而用其他方式更合理。

必须要一起探讨才可以有最好的解决方法。

以上例子，业务用例是线上续护照。但有些功能不靠系统处理，如上传照片，不归纳为产品用例，用其他方式手工处理。

以上只是考虑了正常业务流程，也要考虑各种异常场景才算全面。（请动脑筋，写出各种异常场景，附件里有以往学员的答案，供参考。）

所以作为业务分析师，你很可能要改变用户思考问题的方式，例如利用业务过程模型，配合场景与页面原型，与利益相关者一起探索问题的本质。软件系统必须为拥有它的人提供最理想的价值，构建软件系统本身（例如只是把现有流程自动化）不一定能解决客户业务问题。

识别利益相关者

和杭州客户领导吃晚饭，领导就跟同桌的项目经理开玩笑说："你们刚刚完成内部项目管理自动化工具，做调研的时候好像没有找过我？ 其实我是其中一位经常要使用这系统的管理者，下面项目的监控、申请都是经过我，但我发现这个系统很不合用，对收集我需要的项目信息没有作用。比如没办法处理一些批准信息。"

从上面对话，可以了解如果没有全面识别项目的利益相关者，可能会影响到项目的成败。例如我接触一些有些具备开发经验的需求人员，但他们通常只注意功能需求的技术细节。

问他们："哪些是你的项目干系人？"

答："甲方有协调员，要访谈哪些人都是由甲方协调员安排，我们听他安排。"所以为了避免未能识别所有干系人的风险，就要主动跟甲方一起策划。我们说沟通计划必须是甲乙方一起合作做出来，而且会牵涉甲乙方各个层次的人。

例如要听甲方出资人的需求，可能就要乙方的总经理出马，乙方的需求人员顶多可以跟甲方对口的项目组人员沟通。（如何可以做好识别干系人，并制订沟通计划，可详见附件。）

非功能性需求

虽然很多项目有性能、易用性等非功能需求部分，但缺乏可衡量的量化指标。

例如，多少用户量、数据量、什么平台与网络环境下的反应时间。

"客户没有提非功能的具体需求。"需求人员可能说。

"但没有明确可衡量的需求不等于没有要求。假如验收时甲方项目经理换了人，项目可能会因为反应时间太慢，甲方说不能接受，但因为非功能需求不明确，你们也无法证明产品满足需求，最终项目可能被拒收。所以建议你们也要写上具体可验证的性能需求，保障自己。如果客户没有具体要求，可以依据以前同类项目性能测试结果，制定容易达到的性能规格，成为需求模板。"

除了性能 (Performance) 外，其他主要非功能需求包括：

• 产品观感（Look and Fell）
  • 产品的外观和感觉越来越受重视，例子：苹果iPAD MacBook 等都让客户觉得产品设计精简但高贵
• 可用性与易用性（Usability and Humanity）
  • 线上网购手机APP，能否容易找到喜欢的菜式、挑选并下单
• 操作环境（Operational and Environmental）
  • 从肩高跌落时，产品仍能存活
  • 产品应在什么温度、湿度等条件下使用
  • 产品应节省电池寿命
• 可维护性和支持（Maintainability and Support）
  • 产品应易于移植到Android和iOS
  • 能简单、快速地从原有的产品导出资料，更新到新一代同类产品
  • 应翻译成各种外文
• 安全（Security）
  • 权限（Access），例如：只允许哪些人使用
  • 隐私（Privacy），例如：防止打印任何个人及机密资料；防止未经授权的人进一步或二手使用
  • 完整性（Integrity），例如：确保传输的数据相对应
  • 审计（Auditing），例如：在法定期间保留所有交易的日记账。
• 文化（Cultural），法律（Legal）

其他最佳实践

用户故事卡

用户故事卡片目的是让用户（业务）与开发沟通的桥梁。

需求卡片除了包括需求描述，理由，验收标准外，还应有以下内容:

• 顾客满意度/顾客不满意度：

用两个数比单纯用优先级能更全面反应客户声音。

（如想多了解为什么要这样分，请看附件里的"客户声音:Kano Diagram"）

• 来源：每项需求都应可追溯到源头.例如需求是哪个人,什么岗位提出.
• 冲突与依赖其他需求：是/否； 确保需求之间的一致性。
• 独立的需求编号:

因为设计、编码、测试用例都应与需求相互对应，有明确编号才能对应。

（用实体卡片,团队难以互动、分享，有些公司采用系统 记录与跟踪需求。电子卡也应包括以上内容。）

做好需求评审

很多团队都有做需求评审，但因为没有主要关注点，起不了质量把关的作用，可以利用以下的检查单提醒需求有没有犯了这些错误，尽早改正。

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 评价和验收的准则可包括: * 是否明确，陈述清晰、恰当 * 唯一识别符合架构方法和质量属性的优先级 * 可实施 * 可测试 * 可追溯到来源 * 可实现与业务价值 (Value) 挂钩（镀金：未带来价值） * 是否由客户确定为优先事项 * 超出范围，与项目目标无关 * 不完整 * 不一致（与其他需求有冲突） * 不正确 * 有二义性 * 属于解决方案（未全面考虑各种可行方案） |

总结

上面简述了3类需求常见问题：

• 需求没有按价值过滤与分析，分优先级；没有全面考虑各种场景
• 没有全面识别利益相关者
• 没有明确描述非功能需求，并可验证

和2条实践：

• 用户故事卡
• 需求评审

都可以与CMMI模型对应：

• 需求分析：RDM 3.5, 3.6, 3.2 ( 场景 )
• 干系人：PLAN 2.4, MC 2.2 ( 沟通的策划与监控 )
• 非功能需求：RDM 2.2 ( 客户需求，包括功能与非功能需求 )
• 需求卡片：RDM 2.2 , 2.4 ( 客户需求与活动或工作产物之间双向可追溯 ）
• 需求评审：RDM 2.3

附件

利益相关者

利益相关者计划检查单 (Stakeholders Plan Checklist):

1） 列出所有潜在的利益相关者(List all potential stakeholders)

1a. 类型/分组 (What are the base Segments)

1b. 可否再细分(Any sub-segments)

2）把她们分为 F（友好）、I（忽略）、U（不友好）

Assign F (Friendly)、I (Ignore)、 U (Unfriendly) to them

3）他们最关注什么？

What is important to them?

4）学习目标 (Learning objectives):

针对某利益相关者，我们需要了解什么？

For each stakeholder, what will we need to learn?

5）怎样沟通 (How)

6）什么时间 (When)

抽样计划 (Sampling plan)

如何招募(How to recruit)

如何能获得承诺(How to get commitment)

[针对以上第1至第3项，参阅以下实例/解读]

实例/解读(Examples / Explanation)

某公司专门设计、开发新一代手提电脑产品。

1. ++全面考虑各类利益相关者（Stakeholders）++
   出资人 (Sponsor)： 出资人为产品的开发付钱
   顾客 (Customer)： 顾客购买产品。必须对他们有足够的了解，理解他们认为什么有价值，所以会购买什么产品。
   用户 (User)： 确定用户的目的是为了理解他们所做的工作，以及他们认为哪些改进有价值。

在开发消费产品、大市场软件时，应该考虑用一个**"假想用户"**。假想用户是一个虚拟用户，它是大多数用户的原型。

++类型/分组的例子如下++ ：
未来笔记本电脑的潜在用户 ：

大类：

1. 商业人士 (Business)
2. 媒体专业人士(Media Pro)
3. 家庭用户(Home)

细分：

1. 主要用户(Lead User)
2. 有极高要求者(有挑战的 Demanding)
3. 潜在用户(有潜力的 Potential)
4. 追求技术完美者 (技术流 Tech-Phobic)

2. ++策划包括哪些用户（User inclusion strategy）++

依据设计人员会怎么对应，把不同识别出来的利益相关者分成 F 、I 、U

例：以针对笔记本电脑创新产品
F(Friendly)友好 ，比如家庭用户、商业用户、媒体专员
I(Ignore)忽略 ，比如忽略残疾人士
U(Unfriendly)不友好，比如黑客、小孩（禁止他下载游戏、玩游戏）

3. ++他们注重什么（主要关注点）++

干系人	角色/概况	质量关注重点
商业用户	长期出差者 -坐长途飞机 -做演示 -保护某些秘密文档	-待机时长 -屏幕清晰度 -安全性
专业媒体	创造性工作；并要协同。 录音和录视频	数字带宽（声音和视频） 电脑速度和内存
家庭用户

• 以上有那些在调研之前已知，其他有那些需要挖掘。

客户声音：Kano Diagram

可以用下图分析用户对需求优先级：

解读上下两个箭头应怎样看：

• 下面的箭头代表理所当然(Take it for granted)，如果缺乏，客户会很不满意，包括觉得是理所当然 (例如满意度：中立1，非常不满5)
• 上面的箭头代表是加分项 (Attractive)，如果包括会非常满意，但如果缺乏不会觉得不满意 (例如满意度：非常满意5 ，不满意度：中立1)

所以"需求卡片"用两个系数：顾客满意度+顾客不满意度，能更好判断某功能属于哪类功能需求。

线上续护照的 异常场景

以下是部分异常场景： 个人信息类

• 信息不符，无法识别
  • 生僻字姓氏，系统无法识别

付款

• 支付失败
  • 直接经银行付款
  • 经渠道支付验证出错

系统类

• 系统间接口兼容性问题，提交失败
• 系统出现故障，无法登录或无法上交
• 浏览器兼容性问题

特殊情况

• 法定假日，不接受申请
• 紧急情况：申请人遇到急病，亲人海外死亡等紧急情况，需加急处理
• 信息错误：申请表信息填写不完整或填写错误，需补正
• 照片不符合规格

特殊人群

• 申请人属于未成年人
• 父母国籍不一致，无法线上判断国籍

参考 References

1. Beck, Kent , with D. West. "User Stories in Agile Software Development" , Ch.13 of Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle edited by F. Alexander(2004)
2. Robertson, S. Mastering the requirements process.(2006) 2/e