需求并不是关于需求 (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)：确定用户的目的是为了明白他们所做的工作，以及他们以为哪些改进有代价。
在开发消费产物、大市场软件时，应该思量用一个“假想用户”。假想用户是一个虚拟用户，它是大多数用户的原型。
类型/分组的例子如下：
将来笔记本电脑的潜在用户：
大类：
- 商业人士 (Business)
- 媒体专业人士(Media Pro)
- 家庭用户(Home)
细分：
- 主要用户(Lead User)
- 有极高要求者(有挑战的 Demanding)
- 潜在用户(有潜力的 Potential)
- 追求技术完美者 (技术流 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
- 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)
- Robertson, S. Mastering the requirements process. (2006) 2/e
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
