活动:
|
目的
|
|
角色: 系统分析人员 | |
频率:按照要求,一般对于先启和精化中的每个迭代至少访问一次,如果需要的话可以在后续阶段再访问。 | |
步骤 | |
更多信息: |
输入工件: | 结果工件: |
工具向导: |
工作流程明细: |
目的 | 识别将在您的“扩展的项目团队”中充当涉众的个人。 确定需求的来源并划分其优先级。 |
对于现有的系统,该活动中的第一个输入集将是延期的扩展请求的集合,这些请求已经作为正式的变更请求管理流程的一部分在产品的整个生命周期进行了收集。这将提供一个有价值的起点,从该处开始可以收集数据并进一步优化您的涉众请求集。
收集了这些初始信息后,请寻找可以代表您的涉众的合作伙伴、用户、客户、领域专家和行业分析人员。确定您要与哪些个人合作收集信息,要考虑他们的知识、交流技能、有没有可能与您合作以及他们的“重要性”。 这些个人将充当您的项目的涉众 - 实际上是“扩展的项目团队”。 一般情况下,最好有一小组人(2 到 5 个)能够在项目的整个阶段陪在您的身边。而且,扩展团队中的成员越多,就要花越多时间来管理他们并确保您能有效利用他们的时间。这些人不是全职在这个项目中工作的 - 他们一般在先启和精化阶段参加一次或几次需求收集研讨会,再参加后来的复审会议。
找一个方法,看看其他人是怎么做您想做的事情的。如果您正在开发软件产品,这就意味着收集竞争信息。如果您正在开发新版本的内部信息系统,您就需要安排实地访问,看看人们是怎样使用当前的系统的,并找出可以作出哪些改善。
一个重要的来源是要使用系统的组织的现有说明。这些说明可以是如业务建模规程中所述的生成的业务模型,或者是任何其它形式的业务说明。
目的 | 确定哪些问题需要回答。 收集和记载信息。 |
收集信息的一个最有用的方法是与选择的一些关键涉众进行面谈。一些可能要用到的问题和方法样本可以在指南:面谈中找到。有关开展有效的面谈的脚本样本,请参阅为工件:涉众请求提供的模板。
这是个广泛使用的方法。在开展了数次面谈后,您可能会认识到同样的信息一再重复出现。这类信息可以收集为一组问题,并附带可以从中选择的典型回答,然后发给更多的涉众。用这个方法,可以更好地收集为所列问题给出的答案的正式统计值。但是关键是形成问题的方法可以让这些统计值真实地反映您的涉众的真正需要。
涉众也许能够通过因特网回答问题并将结果发回给您。这样您所涉及的人的范围就比直接面谈大得多,但是对结果的控制却没有直接面谈那么好了。因为您不能当面直接与回答问题的人交流,不能说清问题,也不能澄清误解。问卷可能是非常强大的工具,但是它们不能代替直接面谈。同时还有这样的假设:有关的问题可能提前就确定了,您的措辞可能会让读者按照您意图的方式理解这些问题。
目的: | 让项目团队与项目的涉众见面。 从项目的涉众处收集综合的“愿望列表”。 根据参加研讨会的涉众,划分收集的需求的优先级。 |
指南: |
目的 | 比较不同需求研讨会的结果。 确保您收集了正确的信息。 |
特别是如果您开展了多个需求研讨会,项目团队就最好能养成通览结果的好习惯,并且:
需求研讨会的结果需要在复审或后续会议中展示给选择的客户或用户小组。在这个会议中,您将识别是否有什么需要澄清的问题,这接着就意味着您将识别要完成的任务,并将这些任务分配给人员。
Rational Unified Process
|