需求分析 涉众利益-上的研究.pdfVIP

从涉众利益着手改善需求质量（上） 潘加宇 需求之难 在一次交流会上，笔者被要求向开发团队展示如何在开发团队当前项目中使用用例方法。在对项目基 本没有了解的情况下，笔者通过和在场开发人员的对话，一步步地引导，最后推敲出了一份用例文档。沉 默了一会之后，开发团队的负责人对笔者说，“其实您找出的这些需求现在我们已经知道了，所不同的是， 您是在设计之前知道的，我们是碰了很多壁、修改了许多代码之后才知道，如果我们当初能掌握您刚才展 示的技能，就可以少做许多无用功…” 图 1 需求问题的代价 Barry Boehm 曾经用这样一张图来描述需求问题的代价。如果需求出了问题，在后面的工作流可能需 要几百倍的成本来修正它。这还意味着，越沿着错误的需求往下走，在错误的方向上浪费的人力物力只会 越来越多。所以需求是软件公司最值得改进的环节。这个道理大多数软件组织是懂的（当然，也不排除有 的组织不懂，不过碰壁之后很快就会意识到）。但真正的问题是：你想改进就能改进吗？很多时候团队也 匀了时间来做需求，但开发人员没有掌握需求的相关技能，一拨人到了客户那里，也不知道具体该怎么做， 随便看看，问一些问题，开个会，就不知如何往下走了。这个时候开发人员可能会开始觉得：算了，还是 编码比较有意思，不如把这个时间拿去编码吧！（后面多付出几百倍的成本又怎么样，反正我又不是老板！） 从哪里开始改进？笔者这些年一直致力于帮助开发团队应用用例驱动的面向对象方法，在开始的一段 时间里，在需求过程中，笔者主要强调用例的好处是帮助发现价值，怎样寻找用例，怎样写用例文档，怎 样正确使用扩展包含……但经过一段时间的积累后，发现开发人员往往在实施过程中过多地注重形式，甚 至陷入玩弄技巧的泥潭。现在，笔者认为，需求之所以难以改进，是因为它涉及到了人－人交互的环节， 这些环节仅仅通过开发人员坐在电脑前面练习画图、写文档是无法改进的，必须先引入“人”味，让开发 人员先把屁股坐到涉众那一边去，再来考虑用例等其他问题。所以，涉众利益是改善需求质量的最佳入口 点。 需求背后的涉众利益【2 】 假设我要去商场买东西，需要 500 元现金。好，现在我的目标是：获得 500 元现金。我有两种方法可 以获得：1. 拉开家里的抽屉，里面有超过 500 元的现金，我就从中拿 500 元；2. 如果抽屉里没有钱或者 钱不够，我就拿上银行卡，到楼下取款机去取 500 元。问题来了：为什么家里的抽屉拉开就可以拿，而楼 下的取款机却找我要卡要密码？ 图2 目标一样，但路径和步骤大不相同 背后的原因就是：虽然目标相同，但涉众利益不同。家里的抽屉，只涉及到我和我家人的利益，如果 利益没有什么冲突，直接拉开抽屉就可以拿（从另一面说，如果我和我家人的利益冲突得非常厉害，那么 可能需要买一种长得很象取款机的抽屉才符合我的需求），而对于银行取款机来说，就不是这样了：用户 在取钱时，涉及到了这样一些涉众的利益： 用户—希望操作方便；希望 24 小时服务；担心被多扣了钱。 银行—希望安全；希望节约运营成本。 法律—保护财产。 正是在这些涉众利益的交锋之下，目前我们日常生活中所看到的取款机的用例大概如下【1】： 基本路径 1. 用户插入银行卡 2. 系统提示输入密码 3. 用户输入密码 4. 系统验证密码合法、正确 5. 系统提示输入取款金额 6. 用户输入取款金额 7. 系统验证取款金额合法 8. 系统从用户账户扣除取款金额 9. 系统吐钞 10. 系统提示交易结束，退卡 扩展（略） 业务规则 4. 密码为 6 位数字 7. 取款金额应为 100 元的倍数；一次取款金额不能超过 3000 元；当日取款金额不得超过 5000 元； 我们从上往下看： [1. 用户插入银行卡] 。为什么不是[用户输入 16 位的账号] ？为什么银行要做那么多卡来免费给我们用 （当然，那是以前，现在收费了）？这是为了照顾用户[方便]的涉众利益。 [2. 系统提示输入密码]到[4. 系统验证密码合法、