谈需求分析工作

在项目管理过程中，需求范围是整个软件工程的基础。需求范围定义的好坏，影响到整个项目的目标，进度，成本等项目因素。只有在前期理解业务人员的业务需求下，通过自身信息化专业知识去转化这些业务需求的合理性，必要性及重用性，进而分析出业务需求的整个实施方案。在理解项目需求的过程中，有几个误区，值得大家参考。

1，  业务规划：业务需求是业务人员的事，技术可以不用参与。如果单纯孤立看待项目的每个过程，业务需求的提炼仅仅是从业务层面上，好像还未进入技术层面。但是，如果没有技术参与，会陷入2个极端误区。

A， 沿用目前的业务操作，仅用信息化手段来单纯实现原来手工的业务操作。手工业务流程与信息化系统流程存在很大的不同，手工业务流程可以轻易更改业务单据数据，可以通过非正式解释弥补单据的缺陷。无法达到使用人员的便利，最终会让系统成为摆设，加重业务人员负担。

B， 引用先进的理论知识，在业务需求过程中，业务人员会学习一些最新的理论研究结果，打造成系统无所不能，真正高大上的强大系统。这些先进理论缺乏了实践支撑，最终会迫使系统成为空中楼阁，无法落地的现实的业务过程中。系统不是越强大越好，而是最合适企业的才可以发挥最大的效能。

2，  业务引导：业务需求过程，技术人员重视的是业务需求落地的可能性。重点考虑的是每个业务需求在整个系统的连贯。在业务形成系统思维前，可以逐步引导业务思维与技术实现吻合，让业务可以有合理的预期。如果这个过程有技术和业务都熟悉的系统分析人员参与，业务需求过程会更加完善。

3，  分期建设：针对大型业务需求的系统，避免业务需求大规模一致上线，需区分重要程度划分，针对新建系统，可以分几期操作。第一期重点打造整个项目的基础框架和流程。先可以让目前的业务平滑的转化，提高业务人员的满意度，避免业务变化太大。后面几期可以考虑对整个业务的创新。分期建设，也可以尽快检验业务人员对系统的直观和满意度，减少系统需求不一致情况。

4，  需求范围要明确：需要明确哪些业务需求可以做，哪些不能做。针对纳入需求范围管理范畴的，技术人员一定要理解业务需求，针对业务需求的疑问点要在确定前提出。

5，  需求范围中需求连贯性：大部分需求的提出都是有连贯性的，技术人员在分析需求过程中，要挖掘业务提出这个需求的目的，保证每个需求有相互可以印证的地方。比如前端业务单据单的输入，后端肯定会有个数据查询功能等。这在业务人员可能会孤立的看待，而对技术人员就应该整体考虑。

6，  需求实现：充分利用信息化思想与业务流程创新整合，在功能需求确定前，技术人员需要规划和引导未来业务人员操作方式，如果该功能导致业务人员无法后续操作，就需要考虑该业务功能的变更。技术人员需要考虑业务操作。

7，  需求方法：需求可以多使用头脑风暴法，对业务需求及实现的核心人员讨论。在会议中演示需求过程中，各人员可以对这个需求进行扩展性宽度和深度的讨论。挖掘业务需求。

8，  需求的项目管理：需求范围与成本，工期的考虑。需求范围直接影响到成本与工期。需求范围一旦确定，相应的成本和工期就基本确定。要尽量减少过程中的需求范围变更，任何需求范围变更都需做相应的变更影响分析。

 

只有做好需求范围管理，项目管理的目标才有可衡量性，当前很多项目返工，项目成本不断上升，周期延长，与需求范围管理有很大关系。只有在需求确定之前，项目核心人员可以尽早参与，才可以让需求范围更加合理，后续项目管理有更好的可操作性。