会员登录
会员注册
2、应该指定人负责需求追踪和更新，在开发阶段、测试阶段要保持和用户的需求沟通，这不是一个可有可无的简单工作，很重要，并且会占用责任人50%的工作时间。
5。企业业务管理信息系统的需求调研方法：我认为对调研的组织安排是非常重要的，好的调研安排虽然未必产生质量高的需求，但是一个不遵循调研规律的调研活动，必然是低效的。下面是H项目调研组采取的调研流程，供参考：
1、第一步不是立刻和用户当面讨论需求细节，而是要业务关键用户编写初步的需求报告，提供给开发团队阅读分析。需求报告的内容是，对业务流程的描述，对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系，经常在没有面对面沟通时，关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础，一定要做，有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通，让用户编写。
2、和业务关键用户用开会的方式讨论业务流程细节，并绘制业务流程图。当关键用户和项目团队通过对需求报告的编写、阅读和讨论后，就可以开始对业务流程的细节讨论。这个讨论内容是涉及到每一个细小的业务流程环节，环节之间的关系，和业务流程流转相关的输入输出信息，例如在审核出库单时，出库数量和可用库存数量就是和流程相关的信息。（这时应避免偏离重心，过多讨论系统界面、和流程无关的软件操作方式）。业务流程图是一份正式的文档，需要让用户签字确认，和需求规格说明书一起作为以后的需求文档。占总调研时间的15%
3、打通业务流程图后，根据业务流程每个环节，讨论在每个环节上的详细输入输出项和操作。这里的讨论会增加更多的信息项，这些信息项可能和业务流程流转没有必然关系，但对于业务用户方便地获取各种业务信息是必要的描述。这里的讨论也有可能会部分更改前期描绘的业务流程图。我个人认为，此时也不建议过多在操作方便性上做讨论，原因在概要设计里讲。占总调研时间的35%。
4、编写需求规格说明书，编写过程中会对不少需求细节再讨论，再确认。千万别埋头编写，不和用户做沟通讨论！占总调研时间的50%。最后要让用户签字确认需求规格说明书。
5、需求规格说明书写的要有多细？其实这个问题没有唯一准确的答案，各个项目未必一样。文档的目的是在整个项目周期中，让项目团队及关键用户所有人对相关需求的理解都是足够细致，没有歧义的，并且可以依据其内容准确工作。系统越大越复杂，信息量就越大，项目周期一般较长，那么对需求文档的质量要求应该更高；对于小系统或简单系统，如果你决定在较短的时间内完成需求规格说明书，那么也一定要和关键用户、项目团队做充分细致的需求沟通（这种需求沟通往往占项目经理一半以上的时间），要做需求变更记录，对容易引起歧义的部分需求要描述详细，并且做好心理准备和时间准备，在软件和用户见面后，会有较多的修改。