软件需求的验证工作的目的是保证需求分析成果的完整性和正确性，保证软件开发后的软件产品是用户所需要的。软件需求验证的工作的重要性是在于发现修复需求分析中存在的问题。软件需求验证的主要工作是自我验证，用户验证，系统验证，技术验证，专家验证，主要是以评审会方式来展开，收集各方意见来进行修正。需求验证存在的问题是还处于人工检测阶段，对验证工作重视程度不够。而目前在验证的方法上存在的问题，大量的还依赖于人工检测，这对于当前的大数据量服务还远远不够，操作性也不太高。我们想说这种情况下，还有没有其他办法？我认为还是有的，即在验证内容上提出要求。一是在验证内容上的结果验证，然后则是对系统的验证，必须要在业务研究成果验证基础上展开，二是在需求分析上应对业务和系统功能进行量化分析，例如像业务的发生频度、每笔业务的输入/输出数据流、系统的通信能力、请求相应能力。
形式逻辑中的假设方法某种程度上是应对变化的一种方法，根据预期的变化和自己的看法做出相应的假设和逻辑上的调整，在开发的初期阶段可以多做些方案，进行群组讨论进而确定相应的变化，做出逻辑上的假设来减少相应的错误。编程软件要无二义性，逻辑上的判断会对预期进行猜测，从而避免软件的二义性。强调了软件需求的完整性，就像是只有认识世界，才能改造世界一样，不能认识谈何改造？将业务和软件结合到一起，业务系统是由物理世界人与人，人与物的交互行为构成的总体，软件系统是由信息世界的代码和物理世界的设备载体与人的信息交互构成的总体，体现出业务研究的重要性，首要性。
“软件需求的验证是软件需求风险控制的一个手段，要慎用基于工程经验的验证方式。”软件的需求分析成果除了人工验证外，我认为还应该展开分析成果的测试，验证如果是全局的
，那么测试则应该是有重点、有针对性的依据已知成果作为参照物进行检测。检测是检验真理的标准之一，也是验证成果好坏的评判依据。人工方式通过编写系统功能测试试用例，用
测试用例对照需求分析成果进行检查，以便发现需求分析中存在的问题，这种测试只能做出功能正确性的测试。而机器测试是一种类似搭建原型的方式，但和人工方式不同的是，机器
测试是在仿真系统上模拟一个运行环境来进行测试，不仅能测系统功能的逻辑正确性，而且还可以给出系统性能的有关参数。
软件需求是在现实可见业务的抽象的基础上面向未来软件系统的在抽象，而软件系统只是将未来软件系统的再抽象在信息世界进行具体化的成果。这段话刚开始看确实有些晦涩，不容
易被人所理解，但是仔细想想确实如此，业务不过是抽象在物理世界的具象，软件系统也不过是抽象在信息世界的具象，因此业务与软件系统也有相当大的共性。书中经常提到的一个
例子：哥白尼提出“日心说”之前人们都现在“地心说”这一圈子里，而软件需求既然是千夫所指，那就大胆点让软件需求成为整个开发活动的圆心。有好多软件项目失败，而且失败的原因又大多归咎为需求。需求可谓是千夫所指，有人认为这是不好，但笔者认为千夫所指是好事，说明它重要。事后千夫所指是无所谓的，事中千夫所指是有益的。笔者依据圆心和
圆点的关系模式做一个大胆的类推，将千夫所指的需求分析作为软件开发圆环上的圆心，那么软件开发活动的关系模型也会像预期那样。
从“轻业务、重系统”转变到“重业务、重系统”正是新一代软件需求工程的重要理念。因为在相对传统的需求分析工作中总是不可避免地出现“轻业务、重系统”的现象，尤其做工
具类、框架类的软件项目尤甚，而在管理系统的软件开发活动中还相对重视一些业务。尽管这样从事需求分析工作的人员还是普遍存在业务需求主要是客户方的工作职责的观念，而需求分析人员的主要工作职责是将用户描述的业务转化成用户需求和系统需求。