计、中间的处理过程，供应商完成实现。这时需求更多的是，验证客户提出的需求是否可以实现，把客户的需求更细化，补充完整，同时需求中要包含客户对于设计的要求。 客户和供应商直接对软件需求达成一致。在项目完成的验收时，验证软件是否完成了软件需求。
由于对工作量可以比较精确的估计，合同可以采用固定报价法。
需求导出：
当项目开始时，往往客户的IT部门会作为最初的沟通者和供应商沟通，并传达客户方的需求。在系统开发、实施、维护的很长时间内也会作为一个客户方需求的提出窗口于供应商联系。但真正的需求并不在IT部门手里。而且最后的验收，也是由最终用户确定。
因此，需求的导出一定要抓住关键人物（决定需求的人）。
Setp1： 组建需求团队
客户方的需求团队：项目业务领域的高层；项目经理；业务领域相关人代表；
供应商需求团队： 项目经理；系统分析人员； 开发及测试技术骨干；
在这个团队中要解决需求的获取， 需求的确认， 需求变更的决策（是否接收变更， 变更的影响的认可），业务流程重组的决定和方案， 系统根据需求的验收。
Step2： 通过各种导出技术获得需求
一个完整详细的需求，是通过一系列的中间产品推断出来的。
中间工作成果：
业务领域的当前工作说明；
业务领域的当前问题；
目标、关键问题；
未来系统的构想；
后果和风险；
相关人员认可； 相关人员冲突协议；
需求优先级；
最终需求；
需求是否完备和必要；
工作方式：
访谈： 用于高层了解目标、未来构想；
任务示范：了解业务领域的当前工作说明；业务领域的当前问题；
专题讨论会：相关人员冲突协议；需求优先级；关键问题；后果和风险；BPR的决定；最终需求；需求是否完备和必要；
问卷调查： 分析人员无法到场情况下可采用，了解初步需求。
需求编写：
数据需求： 描述进出系统的数据。
E/R 图： 优点：直接转化成数据库设计； 缺点：太专业，用户无法确认
数据字典： 优点：客户捕获大量细节，用户易理解； 缺点：编写工作量大；
虚拟界面： 优点：可直接从手工表单获得，用户易理解，完成部分界面的设计和确认； 缺点：容易过于的细化为界面设计。
功能需求：记录用户如何进入系统对功能模块进行操作，输入、处理、输出。
总的用例图： 说明系统的范围，外部的接口，相关人员
用例的事件说明： 说明具体功能模块的人、机职责划分。
备注： 由于用例的事件流的说明中已经包含了设计层的需求， 故作为验证是否实现了业务领域的任务是很好的，同时也可以作为后期操作手册和测试用例的基础资料使用。但是过于的细化，不宜作为产品的介绍、给予客户验收的需求规格使用。 给予客户的需求规格可以使用细化些的总用例图（用例包＋功能列表）
功能细节：复杂功能的描述； 有特别算法；出错纠正；业务规则；报表；
特性需求：客户业务处理中非常规的情况。 以及处理方式。
是集成测试和验收测试的一个重点。 同时，特性需求容易在一开始的需求导出时遗漏。 特性需求往往会产生一个新功能分支或特别的设计。故越早发现越好。
屏幕显示和原型：可以先期进行可用性测试。故对于可用性非常关注的新开发系统，可用采用原型方法。在采用商业成品时，在需求时定义界面就为时过早。
任务说明：描述业务领域的需求，适用于成品项目的介绍。体现为用例的概要描述（用例做什么的，由哪些任务组成）
任务及支持：描述业务领域的需求，以及产品的解决方案。 适用于成品项目的介绍（售前）。同时也适用于成品项目二次开发前期同客户进行确认需求时的成品介绍。
补充需求：
质量：
性能：
维护：
平台需求：
产品集成