企业门户项目需求调研指南2[转载文章]

作者：信创门户专家郑文平

需求用例规约成功运用于门户项目

用例规约指的是使用用例建模技术帮助描述系统模型，它是描述用户功能性需求的一种方法。用例建模技术的定义如图5-16所示。

图5-16　用例建模技术的定义

用例建模技术关注以下几个步骤。
找出系统中所有的参与者，也就是在这套系统上线之后，谁可能会点击鼠标或者按动键盘。示意图如图5-17所示。

图5-17 用例建模技术第1步：必须找出参与者

如果参与者不好发现，那么我们从以下方面进行分析（见图5-18）。

图5-18 确定参与者的秘诀

对所有的参与者进行用例分析，确定每个参与者可能的活动或者需要，对他们的活动场所和可能的活动目标进行定义并分类，每个包含独立目标的活动就是一个用例。我们可以从以下方面进行分析（见图5-19）。

图5-19 找出参与者的用例的方法

对每个用例进行描述和界面原型设计（见图5-20）。

图5-20 如何描述用例

对用户在这个活动中的所有操作进行定义和规约，例如可能的意外活动。举个例子：使用银联卡在ATM上取款的操作，就可以这样描述（见图5-21）。

图5-21 用户使用ATM的用例规约示例

客户身份验证的场景定义，如图5-22所示。

图5-22 定义客户使用ATM的特殊需求

使用该技术，可以保证系统需求调研人员真正掌握用户的需求，开发人员不会遗漏需求，同时为测试人员设计测试用例提供输入。

** 需求调研过程组织**

门户项目涉及的部门、领导、用户之多，也是空前的，没有任何一个项目能像门户一样涉及企业内几乎每一个人。从上一章的讲解中我们知道，企业门户项目实施方法论中非常强调门户系统的整体规划。

图5-23　门户项目方法论

而需求调研是规划来源的根本，所以需求调研是个非常重要的阶段。也正因为如此，企业门户项目需求调研阶段的组织非常考验一个项目组的能力。

需求调研交付的是需求规格说明书（含系统原型），它主要由图5-24所示的几个因素决定。

本节着重介绍如何有序地组织门户项目的需求调研，使项目组快速、有序、保质保量地完成需求调研阶段，准确拿到用户需求，避免后期需求发生变化，降低项目风险，提高门户项目实的施质量。

需求调研，顾名思义，就是调查和研究客户的想法，了解用户需要一个什么样的系统。需求调研非常重要，因为：

（1）需求调研是为需求规格说明书做前期工作，可以说需求规格说明书是从需求调研表中得到或抽取出来的。

（2）需求调研是要了解现实世界中做实际工作的人真正需要什么样的程序的过程，再把这些需求改进细节整理出来由设计部实现。

图5-24　软件需求规格的决定因素

大致来说，以下几项工作是必须按照顺序认真组织的。

确定我们的目标和需求调研的目标（见图5-25）。

图5-25　确定目标

做足充分的准备工作，包括人员的组织、统一思想的培训等（见图5-26）。

确定关键用户，对需要访谈的人制定详细的、确定的访谈计划表（见图5-27）。

图5-26　做足充分的准备工作

图5-27　访谈计划表

初步制定栏目列表明细，并结合简要描述，提前下发给各部门，让他们提前知道要谈话的内容（见图5-28）。

针对每个部门制定一个访谈提纲，以便在谈话过程中查漏补缺（见图5-29）。

图5-28 栏目列表明细

图5-29 访谈提纲

做客户访谈。做客户访谈时要把握以下几个问题。

（1）客户想要什么？

认真倾听客户说话，因为客户在说的时候，他多半同时在想自己要什么东西。客户说完了，轮到我们了，首先复述客户需求，在复述的同时我们就可以发表建议了。此时态度要把握好，要把客户的需求合理化、简单化，说白了就是程序别太复杂，风险能排除就全排除掉，别搞个逻辑既复杂又不实用的东西出来。

（2）客户要这干什么用？

听完客户的所有需求后，提炼出客户所要东西的重点，围绕重点开始研究，复述客户的需求。做事千万别说：“我以为”。别怕麻烦，现在多说几遍大家都还客气，比以后大家对需求有争执强。

（3）他为什么这么想？

需求客户大多不是IT专家，而是行业专家，至少对本公司的行业流程比较清楚，所以我们就需要搞清楚客户的行业流程或者说业务逻辑，看看客户到底想让我们用程序为他们实现什么功能，他们要干什么。

（4）会不会有别的想法？

需求的不少关键问题，通过了解其具体想要干什么就很容易地化解掉了。

客户需求的梳理。注意区分清楚什么是强势客户，什么是强权客户，从而识别出真正的客户。

跟领导沟通的语言技巧。务必明确我们说出的每一句话，目的是使对方明确我们有什么意思，同时也要清楚地使对方明确我们没有什么意思，以避免惹来不必要的麻烦。

坚持“重视领导”的思路。我们知道这么大型的项目离不开领导的支持，领导越重视这个项目，我们就越接近成功。但是，如果领导就是不重视怎么办？绝招是：我们要首先“重视领导”。用“重视领导”换取“领导重视”，正如我们要做一个“用户要用”而不是“领导要用户使用”的系统一样（见图5-30）。

图5-30　坚持“重视领导”的思路
访谈结束后，当天要梳理访谈内容，写成用例规约，并清晰地知道每一个用例（见图5-31）。

图5-31 用例图

汇总成需求用例规约说明书（见图5-32）。

图5-32 需求用例规约说明书

最后，也是最重要的一点：记得把握需求底线（见图5-33）。门户项目很容易做大，而且是大得没边没界。如果需求没有底线，投入将无法计算，而这，不是我们想要的。

图5-33 把握需求底线

附录：需求用例说明书样板

一份完整的需求用例规约说明书包含的内容很多，这里只介绍需求用例相关部分。首先，得有一个功能全景清单，如图5-34所示。

图5-34 功能全景清单

然后，针对每个场景拆分功能用例，对每个用例撰写用例规约。典型的用例规约写法如下。

示例1：统一工作待办用例

示例2：单点登录功能用例

本作品采用《CC 协议》，转载必须注明作者和本文链接