：
系统准确性需求：
安全性：
需求变更：
在需求被客户签署后，任何的变动都将纳入到需求变更中。需求的变更不但是要记录好变更，还要保证变更的需求，被实现。故在对于变更的评估当中，还要确认影响的其他工作产品。
需求的变更的另一个难点在于费用的确认上，一般客户会很容易的接收变更所提出的技术方案，但是在对于变革造成的损失以及追加的费用方面难于确认。这个首先将取决于需求跟踪表的建立，让客户明确在目前的时间点，需求已经被实现到什么阶段，已经花费的成本。其次取决于合同中规定的变更需求工作量的核算方法。
流程如下：
需求跟踪：
确认：
目标?--------------à业务领域?-------------------à需求
验证：
需求?------------à 设计、编程、用户文档 ?---------------à 运行
需求的跟踪是通过‘需求跟踪矩阵’维护工作产品间的关系， 通过评审制度，检查需求是否被实现。
客户验证：
客户对于需求的验证，包括事前、和事后两个部分。 事前是指对于供应商写的需求进行检查和确认。 事后是指对于产出的产品进行验收。
对于事前需求的检查和确认，一个是通过场景的排演，模拟业务模型的每个工作场景中的工作任务和特殊情况，在需求中都有体现。另一个是同需求编写的质量标准进行检查。
质量标准：
正确；
完整；
无歧意
一致
确定重要性、稳定性等级
可验证
可追溯；
变更被记录；
对于事后的验证，大多通过UAT测试和系统试运行完成。依据是需求，具体的做法将在VAL中讨论。
备注： 客户往往无法确认产品的事件列表和功能列表，但是可以确认业务领域的事件和任务。
项目收尾结算：
这个阶段主要是根据验收的情况，明确需求遗留的问题。以及后期的方案。另外对于因为需求变更引起的实际费用的增加也要和客户进行说明和结算。
当然若是对于产品型的项目，更有一个需求总结和提炼的过程。要重新对于所有需求进行优先级的排序，提炼出行业通用的‘行业软件需求列表’，比如‘服侍门店管理系统需求列表’。同时要评估需求的变更，对于双方误解引起的需求变更要求整理成‘问题调查表’。当下一个同行业软件开发时，就可以根据‘问题调查表’把问题澄清。同时这些总结的资料可以更好的支持销售和售前的咨询。
参考文献：
Soren Lauesen 《软件需求》 电子工业出版社