如何获取IT项目需求

为了可以明确后期的需求变更会造成多大的影响（进度、费用），在对于具体的需求项上要跟踪实现需求做了些什么工作、工作产品是什么、已经花费的时间、费用多少。这样当一个需求项被要求变更时，可以正确的估计损失， 以及追加的资源。

概论：

需求首先是客户在项目立项时就有的一个愿景，而后不断的细化。形成实现愿景的具体的活动。 在细化的过程中，方式1：客户通过不断的调查相同的案例，并结合自身的实际情况，形成细化的需求方案（客户自己形成需求规格，而后交给承办方进行开发）。方式2：客户通过和多家承办方接触沟通，根据自身的愿景、约束、业务规则，并结合承办方的建议，现成细化的需求方案。

客户根据需求还会决定，在整个项目的需求中，要承办方具体要做些什么（即承办方的任务， 承办方具体要实现哪些需求）。

形成了彼此认可的需求方案后，一般承办方就可以估计出整个项目的资金、进度、初步的活动规划。并同客户方协商形成合同。 需求规格书讲作为合同的附件。在今后发生合同争议时需求规格书将作为重要的依据。

承办方在明确了需求后，就会开始后期的涉及、开发、测试、部署等工作。在后期的项目实施的过程中，由于承办方（发现某个具体需求无法实现 或于另一个需求矛盾）或客户方（业务规整变化、 想要增加一个功能）的原因，需求都会被变更。需求的变更将引起进度、费用、验收标准的变化。 故需求的变更要被严格的管理，要得到双方的认可。这就是需求的变更管理。

同时为了可以方便的明确后期的需求变更会造成多大的影响（进度、费用），在对于具体的需求项上要跟踪实现需求做了些什么工作、工作产品是什么、已经花费的时间、费用多少。这样当一个需求项被要求变更时，可以正确的估计损失， 以及追加的资源。

需求项的实现被跟踪记录的另一个好处时，当被完整记录后，记录的数据可以作为项目后期评估使用。以及作为历史参考数据，为下一个项目工作量、进度、成本的估计提供数据。

明确需求层次：（重要，且与合同的制定，报价模式的制定密切相关）

项目的不同，客户会提出不同层次的需求。根据不同层次的需求，在需求的获取和管理阶段会有不同的要求。

情况1：客户只是有个目标，希望通过供应商提供一套软件系统可以解决问题。 在这种情况下，其实客户需要的是对于实现目标的解决方案，是个包括业务模型以及相应软件系统的整体方案。 在这种情况下，需求包含两个部分的内容，其一：业务建模； 其二：软件需求；在这种情况下，同用户达成一致的首先是用户的业务模型。其后，编写实现业务模型中软件任务的软件需求。软件需求也会和用户确认，用户验证软件需求是否全部包含了业务模型中的对于软件的任务，以及是否考虑到了用户的约束条件。用户验收时，是根据软件需求说明，验收软件是否完成了软件需求。同时也会求证供应商提出的业务模型是否实现了目标或者是否可以运作。

在没有完成业务模型的确认前，无法了解软件的规模，无法完成报价。合同可以签署为两阶段合同，阶段一：业务建模，采用时间－原料法进行报价； 阶段二：软件开发，采用固定价格法。 另一种情况： 若供应商提供的是产品（价格固定），可以采用固定价格＋额外费用的方法。

情况2：客户有目标，同时也有了业务领域的解决方案。需要软件供应商提供的是一个可以完成业务模型中任务的软件。在这种情况下，客户明确了解要些什么功能，输入、输出、处理。 在此情况下，供应商就是提供软件需求，并同客户就需求达成一致。（其实是对软件做些什么，如何做达成一致）。在需求的确认上会力求细致准确。在项目完成的验收时，验证软件是否完成了软件需求。

在完成了需求的签署后，一般可以估计出工作量，合同可以采取固定报价法。

情况3： 客户有目标，也有了解决方案，并且也告诉供应商关于设计层的要求。要求供应商按要求完成。 这种情况，一般出现在项目的维护阶段， 比如客户要求增加一个报表。 也会出现在Coding外包项目上，客户有详细的界面设计、中间的处理过程，供应商完成实现。这时需求更多的是，验证客户提出的需求是否可以实现，把客户的需求更细化，补充完整，同时需求中要包含客户对于设计的要求。 客户和供应商直接对软件需求达成一致。在项目完成的验收时，验证软件是否完成了软件需求。

由于对工作量可以比较精确的估计，合同可以采用固定报价法。

需求导出：

当项目开始时，往往客户的IT部门会作为最初的沟通者和供应商沟通，并传达客户方的需求。在系统开发、实施、维护的很长时间内也会作为一个客户方需求的提出窗口于供应商联系。但真正的需求并不在IT部门手里。而且最后的验收，也是由最终用户确定。

因此，需求的导出一定要抓住关键人物（决定需求的人）。

Setp1： 组建需求团队

客户方的需求团队：项目业务领域的高层；项目经理；业务领域相关人代表；

供应商需求团队： 项目经理；系统分析人员； 开发及测试技术骨干；

在这个团队中要解决需求的获取， 需求的确认， 需求变更的决策（是否接收变更， 变更的影响的认可），业务流程重组的决定和方案， 系统根据需求的验收。

Step2： 通过各种导出技术获得需求

一个完整详细的需求，是通过一系列的中间产品推断出来的。

中间工作成果：

业务领域的当前工作说明；

业务领域的当前问题；

目标、关键问题；

未来系统的构想；

后果和风险；

相关人员认可； 相关人员冲突协议；

需求优先级；

最终需求；

需求是否完备和必要；

工作方式：

访谈： 用于高层了解目标、未来构想；

任务示范：了解业务领域的当前工作说明；业务领域的当前问题；

专题讨论会：相关人员冲突协议；需求优先级；关键问题；后果和风险；BPR的决定；最终需求；需求是否完备和必要；

问卷调查： 分析人员无法到场情况下可采用，了解初步需求。