项目调研经验谈[2]

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

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

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

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

原文转自：http://www.ltesting.net