大部分IT项目缺乏支持文档，纵然拥有商业案例（ Business Case ）或其他相关文档，也不能很明确地把项目所需的工作涵盖起来，只能建立项目的周边，对项目的实际工作量缺乏描述，这很容易导致项目过程中所产生的变动。

为解决这个和问题，国际上已于上世纪 80 年代末期开始采用“”（ Statements of Work 或简称 SOW ）来固定范围，同时放弃范围定义（ Scope Definition ）的应用。因为 IT 项目有别于其他基建项目的地方在于基建项目有其他附属文档来支持范围定义，比如在基建项目的项目范围中，一般都有诸如项目的有关设计图则、用料标准等等明文规定，让范围能够非常明确地涵盖基本的工作需求。而 IT 项目的项目范围中往往没有这样的定义。

以商业效益来确认功能需求，再利用功能需求来建立。而在范围确认后，紧跟着必需建立详细的工作需求和，否则项目的工作便像橄榄球内的充气量一般，可以按照客户的要求随意变动。

工作需求和项目计划基本上是利用（ Work Breakdown Structure ）建立。明确的工作陈述（ SOW ）让渠道商或服务商了解本身的服务承诺，有效地建立项目的成本，降低项目过程中所产生的变动。这些应该在销售过程中建立，成为服务合约的内容一部分。万一合约中只有项目范围定义，那么交付小组必须在交付初期建立有关的项目工作陈述，避免交付期间所产生的争议。

项目开发的目标对软件用户来说，目地是项目及时开发完成，达到管理要求，并成功应用于企业管理，为企业创造效益。方案的用途可以让用户在没有使用最终软件的情况下，对未来软件的使用方法和计算原理有足够的认识方案可以正确指导软件开发商进行正确的开发方案可以帮助软件测试工作正常进行方案可以指导用户去使用未来的软件方案可以作为双方认可的项目验收标准。 2100433B

所谓的“项目需求”到底是要明确什么呢，是明确管理的目标，还是管理的方法，这却是企业很难把握的。另外，需求是怎样产生的？或者说需求应该怎样产生，才可以保证最后产生的需求是既完整又合理的？这同样也是很多企业都很难做得好的一件事。

一般来讲，在最初的需求调研阶段，这部分工作大都是由公司的管理部门或从事分析工作的人员来完成，而调研人员考虑问题的出发点往往只是让企业的管理水平有一个飞跃，但是却容易忽略企业的现状，或未能完整深刻地对企业的实际潜在性需求进行调研，这导致在实际应用阶段之时，很多部门觉得不太适用，甚至导致各个部门怨声载道，于是不得不宣告失败或推倒重来。所以处在这个阶段的企业，需要有一种科学的方法来指导自己确定真实准确的需求。

首先，企业要明白一点，现在所需要了解的不单单是企业的需求，而是要制定出企业长期发展的阶段性，并以此为依据，来制定各个阶段的需求和发展计划。特别是对于处在快速成长发展期的企业而言，企业会在较短的时间内经历多个成长的阶段，在不同的阶段会派生许多不同的管理需求。只有企业明白了自己需要管理什么，才可能制定对应的管理方法。这样的战略目标的确定是分阶段的,企业只有根据自己企业的特点或者行业的特点制定出阶段目标，才能够明确自己每个阶段的管理需求。

同时，无论是制造业还是流通行业，都强调和这两个闭环。那么，这两个闭环中的每个环节都存在管理上的需求。在对这些环节进行定义时，不单单是要定义管理的各个环节的管理目标，更重要的是要定义各个环节之间的关系。企业只有按照这样的方法制定阶段性的发展目标，才可以完整地对各个环节进行管理方法的定义。

其次，当企业已经制定了企业各发展阶段的性目标之后，根据各阶段的目标进行管理的规划就比较简单了，因为企业已经明白了自己需要管理什么，剩下的只需要探讨管理的方法就可以了。按照既定的战略性目标制定每个环节的管理方法的时候，一定要本着立足本部门的需求，放眼整个公司的管理目标的原则来制定管理方法，只有这样才能保证本阶段的管理方法的科学性以及合理性。

最后，在对各个环节的管理方法进行定义的时候，不但要考虑管理的目标通过管理方法的实现，而且要注意前后两种管理方法的差异。只有注意了两种管理的方法的差异，才可能保证两种管理方法的平稳过渡。

同时，公司的管理部门或从事分析工作的人员在做各个部门的需求调研的时候，也要在立足企业的管理目标的前提下，充分了解各个环节实际的管理需求。了解他们日常工作实现了哪些目标，对于整个公司的管理目标，他们还缺少哪些，需要补充的是哪些。只有这样才能避免调研开始的时候“没得说”，到了应用的阶段却“说不完”的情况发生。

所以，在初期的选型阶段，企业要明确的需求不可单一理解为明确要管理什么，而是对要管理的目标怎样实现。整个过程强调的是管理的目标和管理的方法之间的关系，只有立足在这个关系的基础上，才可以保证做到真正明确需求。

IT 业内人士多未能把握的实际应用技巧。而有如工作量估算，错误的工作细节将对项目计划不利。

每一个项目都有不同的交付物，而每一件交付物需要经过不同的里程碑才能够产生，同时每一个里程碑也需要经过不同的阶段才能够达到里程的目标。每一个阶段需要经过不同的步骤去完成，而每一个步骤需要进行不同的工作。

每一个步骤需要完成一系列工作才能进行第二步骤，直至同一阶段的步骤完成才开始第二阶段，而直至全部阶段完成后才能到达一个里程碑。有些里程碑内的工作可以同期进行，但有些里程碑内的工作得等另一个里程碑完成后才能够开始。到最终完成全部的里程碑内的工作后才能够交付项目中的某一件交付物。

利用 WBS技巧来建立交付组合架构，为每一件交付物建立本身的工作需求，可以让很明确地说明每一件交付物所包含的工作。这个交付组合架构更可以让在同一时间为项目建立有关的工作计划。

资源的需求是指项目发展过程对于资源的需要程度。资源的需求决定着资源的重要性、价值和关联强度。

资源的需求通常可以分为四种类型：

1、必需型

2、急需型

3、一般型

4、储备型

需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.

问题识别

就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行时所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.

分析与综合

逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).

制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.

评审

对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

项目需求分析过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。狭义上理解：需求分析指需求的分析、定义过程。