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

由于企业门户技术对大多数企业或用户来说是陌生的，所以企业门户项目的需求调研采用的工作方法有别于传统的项目。在实际的实施中通常采用两种方法。

第一，原型建模方法。即：构建一个HTML版本的界面与操作原型，引导用户尝试操作，在操作中发现问题，然后不断完善。注意：在执行该方法的过程中，很多项目组偷懒了，采用JPG静态图片的方法来代替操作原型，这是很不可取的。门户技术对用户来说本来就陌生，单纯使用静态的几个图片根本引导不出用户的真实想法。等到项目开发差不多了，用户试用时才会发现问题，所以很多项目组抱怨：门户项目难做，因为用户需求多变。实际上并不是用户需求多变，而是一开始就没有把用户需求引导出来。本文会详细介绍门户系统的原型建模方法。

第二，需求用例。通常，人们认为撰写需求用例是个比较复杂的工作，所以这种需求调研方法应该只用于大型项目。错了！门户中的功能点本来就繁琐，如果不用用例规约定义清楚，用户根本没法理解你的需求描述。毫无疑问，不采用用例规约，你压根就不会拿到用户的真实需求。本文会详细介绍如何使用需求用例规约方法来撰写门户项目的用户需求描述。

另外，门户项目涉及的部门、领导、用户之多，也是空前的，没有任何一个项目能像门户一样涉及企业内几乎每一个人，所以企业门户项目需求调研阶段的组织非常考验一个项目组的能力。本文会着重介绍如何有序地组织门户项目的需求调研，使项目组快速、有序、保质保量地完成需求调研阶段，准确地拿到用户需求，避免后期需求发生变化，降低项目风险，提高门户项目的实施质量。

众所周知，很多软件项目尤其是大型的集成类项目，由于涉及的部门很多，涉及的应用系统很多、数据库很多，需求多种多样，故而需求调研和确认非常重要，甚至直接决定整个项目的成败。

为了透彻了解需求，确认用户的需要，我们经过多年的积累，总结出一二三，如图1-1所示。

企业门户项目需求调研指南

图1-1　项目需求调研阶段坚持的核心理念与思想

一个核心

一个核心思想指的是我们考虑需求的时候，除了把自己当做用户来亲自使用这套系统外，还要抛开其他的利益冲突，例如，任何人都不要担心引导并扩展了用户需求后，是不是增加了自己的工作量。我认为，用户的利益才是第一位的，需求的扩展带来的技术变更始终不是问题。我们现在多一点点的付出，可以给用户将来的使用增加无穷的乐趣。

两项基本原则

第一项基本原则是重点关注最关键用户的关注点。如果不是用户关心和需要我们解决的问题，即使投入再多的精力其结果也是事倍功半，我们的效率与用户的成本息息相关。我们把精力聚焦于用户最关心的问题、用户最头疼的事情、用户最需要我们解决的问题，是在节省我们的成本，更是在节省用户的成本。一个讲求效率和成本的项目组，相信是所有用户都需要的。

第二项基本原则是变用户“我想要的”为“我需要的”。在一些需求复杂的项目尤其是大型的门户集成项目中，用户往往表达不清楚自己的软件需求，他们只能从自己的业务角度讲想要什么，但是他们想要的东西离真正的软件需求与设计还有很大的距离。我们需要借助大量的项目经验，循循善诱，将用户想要的东西表达清楚，然后转换成软件需求，并制作系统原型，给用户确认。在用户使用了系统原型并提出意见后，我们来修正需求理解和系统模型，并对需求描述进行迭代。经过多轮、多层次的需求迭代，让每个用户都满意后，基本上可以达到最大程度地理解和掌握用户的真正需求，保证软件下阶段的设计工作接近用户的实际需要，从而保证整个项目的成功。
三个基础方法

第一个基础方法是原型建模迭代技术。

第二个基础方法是基于用例规约的需求调研方法。

第三个方法是足够多的用户参与、培训。

对于以上三个方法，下面将分别进行详细描述。

门户的原型建模方法

系统需求建模的意思是根据用例规约生成的各种场景，汇总成一个一体化的综合需求描述，并由用户交互接口设计师（美工）制作翔实的HTML版本的系统模拟，然后请用户尝试使用。这种原型建模要高于传统的界面设计，更高于效果图，它在最大程度上接近于用户最终使用的系统，有助于用户理解和了解将来的系统功能，及时提出不符合要求的操作点。

本节介绍如何使用Portal建模工具开发一个需求引导与功能确认模型。这个模型的目的是用于启发用户思维，引导用户需求，经过多轮的修正与优化后，再用于用户确认功能需求。

这需要在Eclipse中安装一个插件，安装完成后，启动Eclipse，执行以下步骤。

①创建一个工程，如图1-2所示。

企业门户项目需求调研指南
图1-2　创建工程
②选择工程类型为：Portal模型工程，如图1-3所示。