项目调研经验谈-UML软件工程组织-火龙果软件

UML软件工程组织

项目调研经验谈

作者：不详　　来源：网络　

调研概要情况：X项目需求调研开始于2006-3-23结束于2006-6-15，内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干，编写需求规格说明书字数95.4万。

　1.把二期项目当作一个新项目来做调研，避免需求细节遗漏。在调研的初期我们曾经有过疑虑，这是一个二期的项目，那么调研的内容是否只针对二期的新需求，对需求内容二期和一期一致的部分就不必调研了?

经过讨论我们还是决定把二期项目当作一个新项目来做调研，即使二期和一期需求内容一致，我们也在调研会上讨论，并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时，发现有不少地方原来以为是二期不必修改的，经过讨论后发现还是需要修改。（往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”）

　2.调研团队参加所有子系统的调研会议，可以相互补充避免需求遗漏。这个项目规模比较大，根据业务的类型不同，分成了6个子系统，各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求，但是在调研时，只要可能，我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是，对于子系统之间的业务关系，调研团队都可以有全面的了解，对业务的理解比较透彻全面，并且还可以相互补充遗漏。

　3.多人调研，在会议后应该立刻回顾整理统一的会议笔记，消除歧义，避免遗漏。在开调研会时，全体与会人员都各自记自己的会议笔记，会后没有强调当天整理会议笔记（会议进度很紧，每天开会到晚上8、9点钟）。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容，或者同一份需求在几个笔记上记录的内容细节上有差异，事后难以追溯正确的信息。给编写需求文档带来了一些困难，需要再次讨论需求。

　4.需求文档编写完成后，在开发阶段也应该做检查和更新，避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后，在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误，导致需要重新修改。

建议：

　1、如果在编写需求文档后，开发阶段应该做一边阅读需求文档，一边做需求文档的检查，对于保证需求质量效果会更好。

2、应该指定人负责需求追踪和更新，在开发阶段、测试阶段要保持和用户的需求沟通，这不是一个可有可无的简单工作，很重要，并且会占用责任人50%的工作时间。

　5.企业业务管理信息系统的需求调研方法：我认为对调研的组织安排是非常重要的，好的调研安排虽然未必产生质量高的需求，但是一个不遵循调研规律的调研活动，必然是低效的。下面是H项目调研组采取的调研流程，供参考：

1、第一步不是立刻和用户当面讨论需求细节，而是要业务关键用户编写初步的需求报告，提供给开发团队阅读分析。需求报告的内容是，对业务流程的描述，对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系，经常在没有面对面沟通时，关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础，一定要做，有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通，让用户编写。

　2、和业务关键用户用开会的方式讨论业务流程细节，并绘制业务流程图。当关键用户和项目团队通过对需求报告的编写、阅读和讨论后，就可以开始对业务流程的细节讨论。这个讨论内容是涉及到每一个细小的业务流程环节，环节之间的关系，和业务流程流转相关的输入输出信息，例如在审核出库单时，出库数量和可用库存数量就是和流程相关的信息。（这时应避免偏离重心，过多讨论系统界面、和流程无关的软件操作方式）。业务流程图是一份正式的文档，需要让用户签字确认，和需求规格说明书一起作为以后的需求文档。占总调研时间的15%

3、打通业务流程图后，根据业务流程每个环节，讨论在每个环节上的详细输入输出项和操作。这里的讨论会增加更多的信息项，这些信息项可能和业务流程流转没有必然关系，但对于业务用户方便地获取各种业务信息是必要的描述。这里的讨论也有可能会部分更改前期描绘的业务流程图。我个人认为，此时也不建议过多在操作方便性上做讨论，原因在概要设计里讲。占总调研时间的35%。

4、编写需求规格说明书，编写过程中会对不少需求细节再讨论，再确认。千万别埋头编写，不和用户做沟通讨论！占总调研时间的50%。最后要让用户签字确认需求规格说明书。

5、需求规格说明书写的要有多细？其实这个问题没有唯一准确的答案，各个项目未必一样。文档的目的是在整个项目周期中，让项目团队及关键用户所有人对相关需求的理解都是足够细致，没有歧义的，并且可以依据其内容准确工作。系统越大越复杂，信息量就越大，项目周期一般较长，那么对需求文档的质量要求应该更高；对于小系统或简单系统，如果你决定在较短的时间内完成需求规格说明书，那么也一定要和关键用户、项目团队做充分细致的需求沟通（这种需求沟通往往占项目经理一半以上的时间），要做需求变更记录，对容易引起歧义的部分需求要描述详细，并且做好心理准备和时间准备，在软件和用户见面后，会有较多的修改。