概论：
需求首先是客户在项目立项时就有的一个愿景，而后不断的细化。形成实现愿景的具体的活动。 在细化的过程中，方式1：客户通过不断的调查相同的案例，并结合自身的实际情况，形成细化的需求方案（客户自己形成需求规格，而后交给承办方进行开发）。方式2：客户通过和多家承办方接触沟通，根据自身的愿景、约束、业务规则，并结合承办方的建议，现成细化的需求方案。
客户根据需求还会决定，在整个项目的需求中，要承办方具体要做些什么（即承办方的任务， 承办方具体要实现哪些需求）。
形成了彼此认可的需求方案后，一般承办方就可以估计出整个项目的资金、进度、初步的活动规划。并同客户方协商形成合同。 需求规格书讲作为合同的附件。在今后发生合同争议时需求规格书将作为重要的依据。
承办方在明确了需求后，就会开始后期的涉及、开发、测试、部署等工作。在后期的项目实施的过程中，由于承办方（发现某个具体需求无法实现 或于另一个需求矛盾）或客户方（业务规整变化、 想要增加一个功能）的原因，需求都会被变更。需求的变更将引起进度、费用、验收标准的变化。 故需求的变更要被严格的管理，要得到双方的认可。这就是需求的变更管理。
同时为了可以方便的明确后期的需求变更会造成多大的影响（进度、费用），在对于具体的需求项上要跟踪实现需求做了些什么工作、工作产品是什么、已经花费的时间、费用多少。这样当一个需求项被要求变更时，可以正确的估计损失， 以及追加的资源。
需求项的实现被跟踪记录的另一个好处时，当被完整记录后，记录的数据可以作为项目后期评估使用。以及作为历史参考数据，为下一个项目工作量、进度、成本的估计提供数据。
明确需求层次：（重要，且与合同的制定，报价模式的制定密切相关）
项目的不同，客户会提出不同层次的需求。根据不同层次的需求，在需求的获取和管理阶段会有不同的要求。
情况1：客户只是有个目标，希望通过供应商提供一套软件系统可以解决问题。 在这种情况下，其实客户需要的是对于实现目标的解决方案，是个包括业务模型以及相应软件系统的整体方案。 在这种情况下，需求包含两个部分的内容，其一：业务建模； 其二：软件需求；在这种情况下，同用户达成一致的首先是用户的业务模型。其后，编写实现业务模型中软件任务的软件需求。软件需求也会和用户确认，用户验证软件需求是否全部包含了业务模型中的对于软件的任务，以及是否考虑到了用户的约束条件。用户验收时，是根据软件需求说明，验收软件是否完成了软件需求。同时也会求证供应商提出的业务模型是否实现了目标或者是否可以运作。
在没有完成业务模型的确认前，无法了解软件的规模，无法完成报价。合同可以签署为两阶段合同，阶段一：业务建模，采用时间－原料法进行报价； 阶段二：软件开发，采用固定价格法。 另一种情况： 若供应商提供的是产品（价格固定），可以采用固定价格＋额外费用的方法。
情况2：客户有目标，同时也有了业务领域的解决方案。需要软件供应商提供的是一个可以完成业务模型中任务的软件。在这种情况下，客户明确了解要些什么功能，输入、输出、处理。 在此情况下，供应商就是提供软件需求，并同客户就需求达成一致。（其实是对软件做些什么，如何做达成一致）。在需求的确认上会力求细致准确。在项目完成的验收时，验证软件是否完成了软件需求。
在完成了需求的签署后，一般可以估计出工作量，合同可以采取固定报价法。
情况3： 客户有目标，也有了解决方案，并且也告诉供应商关于设计层的要求。要求供应商按要求完成。 这种情况，一般出现在项目的维护阶段， 比如客户要求增加一个报表。 也会出现在Coding外包项目上，客户有详细的界面设