概论：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

需求导出：

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

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

Setp1： 组建需求团队

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

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

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

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

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

中间工作成果：

• 业务领域的当前工作说明；
• 业务领域的当前问题；
• 目标、关键问题；
• 未来系统的构想；
• 后果和风险；
• 相关人员认可； 相关人员冲突协议；
• 需求优先级；
• 最终需求；
• 需求是否完备和必要；

工作方式：

• 访谈： 用于高层了解目标、未来构想；
• 任务示范：了解业务领域的当前工作说明；业务领域的当前问题；
• 专题讨论会：相关人员冲突协议；需求优先级；关键问题；后果和风险；BPR的决定；最终需求；需求是否完备和必要；
• 问卷调查： 分析人员无法到场情况下可采用，了解初步需求。

需求编写：

数据需求： 描述进出系统的数据。

• E/R 图： 优点：直接转化成数据库设计； 缺点：太专业，用户无法确认
• 数据字典： 优点：客户捕获大量细节，用户易理解； 缺点：编写工作量大；
• 虚拟界面： 优点：可直接从手工表单获得，用户易理解，完成部分界面的设计和确认； 缺点：容易过于的细化为界面设计。

功能需求：记录用户如何进入系统对功能模块进行操作，输入、处理、输出。

• 总的用例图： 说明系统的范围，外部的接口，相关人员
• 用例的事件说明： 说明具体功能模块的人、机职责划分。

备注： 由于用例的事件流的说明中已经包含了设计层的需求， 故作为验证是否实现了业务领域的任务是很好的，同时也可以作为后期操作手册和测试用例的基础资料使用。但是过于的细化，不宜作为产品的介绍、给予客户验收的需求规格使用。 给予客户的需求规格可以使用细化些的总用例图（用例包＋功能列表）

功能细节：复杂功能的描述； 有特别算法；出错纠正；业务规则；报表；

特性需求：客户业务处理中非常规的情况。 以及处理方式。

是集成测试和验收测试的一个重点。 同时，特性需求容易在一开始的需求导出时遗漏。 特性需求往往会产生一个新功能分支或特别的设计。故越早发现越好。

屏幕显示和原型：可以先期进行可用性测试。故对于可用性非常关注的新开发系统，可用采用原型方法。在采用商业成品时，在需求时定义界面就为时过早。

任务说明：描述业务领域的需求，适用于成品项目的介绍。体现为用例的概要描述（用例做什么的，由哪些任务组成）

任务及支持：描述业务领域的需求，以及产品的解决方案。 适用于成品项目的介绍（售前）。同时也适用于成品项目二次开发前期同客户进行确认需求时的成品介绍。

补充需求：

质量：

性能：

维护：

平台需求：

产品集成：

系统准确性需求：

安全性：

需求变更：

在需求被客户签署后，任何的变动都将纳入到需求变更中。需求的变更不但是要记录好变更，还要保证变更的需求，被实现。故在对于变更的评估当中，还要确认影响的其他工作产品。

需求的变更的另一个难点在于费用的确认上，一般客户会很容易的接收变更所提出的技术方案，但是在对于变革造成的损失以及追加的费用方面难于确认。这个首先将取决于需求跟踪表的建立，让客户明确在目前的时间点，需求已经被实现到什么阶段，已经花费的成本。其次取决于合同中规定的变更需求工作量的核算方法。

流程如下：

需求跟踪：

确认：

目标ß--------------à业务领域ß-------------------à需求

验证：

需求ß------------à 设计、编程、用户文档 ß---------------à 运行

需求的跟踪是通过‘需求跟踪矩阵’维护工作产品间的关系， 通过评审制度，检查需求是否被实现。

客户验证：

客户对于需求的验证，包括事前、和事后两个部分。 事前是指对于供应商写的需求进行检查和确认。 事后是指对于产出的产品进行验收。

对于事前需求的检查和确认，一个是通过场景的排演，模拟业务模型的每个工作场景中的工作任务和特殊情况，在需求中都有体现。另一个是同需求编写的质量标准进行检查。

质量标准：

• 正确；
• 完整；
• 无歧意
• 一致
• 确定重要性、稳定性等级
• 可验证
• 可追溯；
• 变更被记录；

对于事后的验证，大多通过UAT测试和系统试运行完成。依据是需求，具体的做法将在VAL中讨论。

备注： 客户往往无法确认产品的事件列表和功能列表，但是可以确认业务领域的事件和任务。

项目收尾结算：

这个阶段主要是根据验收的情况，明确需求遗留的问题。以及后期的方案。另外对于因为需求变更引起的实际费用的增加也要和客户进行说明和结算。

当然若是对于产品型的项目，更有一个需求总结和提炼的过程。要重新对于所有需求进行优先级的排序，提炼出行业通用的‘行业软件需求列表’，比如‘服侍门店管理系统需求列表’。同时要评估需求的变更，对于双方误解引起的需求变更要求整理成‘问题调查表’。当下一个同行业软件开发时，就可以根据‘问题调查表’把问题澄清。同时这些总结的资料可以更好的支持销售和售前的咨询。

参考文献：

Soren Lauesen 《软件需求》 电子工业出版社