需求复审是非常重要的检查点。请确保你正确的使用它。需求复审需要领域专家和技术专家、以及管理者的参与。需求复审是保证需求完整性和正确性的最后一道防线。在很多的文章（包括我的需求的实践一文）、过程都对需求复审进行了论述，我们这里就不赘述了。在实践过程中，我们发现，需求复审还有一个好的方式，为了能够通过需求复审，需求分析人员（包括领域专家和技术专家）会非常努力的找出需求中的问题。所以，在你的过程中加入这个检查点是非常有必要的。
好的，如果这一切都进行顺利的话，最后的需求规格书应该是比较完美的，而技术专家也已经从领域专家那里了解到了足够的信息，可以开始下一阶段的开发了。这里，我们再花一些笔墨来讨论迭代过程中，我们如何处理需求。实践中，我们认为迭代次数并不是越多越好，应该根据项目规模和团队特点进行区分，每一次的迭代都可能有自己的目标。例如首次迭代的周期可能比较短，其主要的目标定为提供软件原型、验证主要设计思路等。第二次的迭代的周期可以长一些，目标可以定位为实现主要功能。如果软件规模比较大，也可以为每次迭代设定需求范围（或主要场景），这样就能够防止需求扩散的情况。这已经超出了本文的范围，因此我们这里只是简单的提一下。
分析阶段是发生职责转换的重要阶段。该阶段的成败对软件开发至关重要。对于面向对象开发而言，这个过程最主要的任务是对领域进行建模。比较好的方式是使用UML来描述领域知识，例如，我比较经常使用类图来建立分析模型，使用顺序图来描述动态流程。请确保技术团队中最出色的分析建模人员参与这个初始分析建模的过程。他的职责包括指导建模和对模型进行审查。如果在一个迭代过程中，这个模型是不断演进的，这可以减少一些风险。在这个过程中，建模人员可以吸收领域知识，这对于后续阶段中指导其他开发人员是很重要的，对公司的长远目标也具有重要意义（参见 短期利益和长期利益的权衡模式）。如果建模人员缺少面向对象开发的经验，他会很容易把对象变成一个数据容器。这种方式并不是不好，但它把数据和行为区分开来，无法站在一个抽象的高度上对领域进行分析。
很难严格的区分分析阶段和设计阶段，至少我是这么觉得的。他们的差别仅仅是在分析的详细程度上（有点类似于以往的概要设计和详细设计）。在实践中，我们发现，并没有必要严格的区分它们，但是你需要保证模型已经完整的描述了需求。这里可以设置检查点来验证，也可以在设计模型出来之后再进行检查，这取决于具体的项目。因此，我们在分析阶段和设计阶段结束之前需要进行设计复审。
从Martin Fowler提出分析模式的概念之后（现在他的第二本分析模式正在写作中），它就成为分析建模的有利助手之一－－对领域概念进行分析和建模，并描述它们之间的关系（我在点空间上的一篇读书笔记反应了需求和分析之间的关系）。但是请千万注意，不要误用和滥用分析模式。因为任何分析模式的提出，都是基于某个上下文环境中的需求的，如果上下文环境不同，那么模式就需要改进或改造。因此，分析模式是一个好的开始，但需要你针对实际需求具体分析。在应用模式方面，Frank Buschmann的Applying Patterns是一篇不错的参考文章，其中文版发布在点空间上。
请按照逐步精化（迭代）的方式来完善、改进你的分析模型。优秀的设计一定不会过于复杂。如果你的分析模型出现过于复杂的情况，到处充斥着复杂的关系网。那么，你需要对你的设计进行结构上的改进。例如，采用分层（参见 敏捷架构设计一文中的分层模式）、组件技术、或是使用单向联系。坚持这一过程，你会发现最后的设计是简洁的、完美的。
在设计阶段，要注意的事项和分析阶段相差不多，例如不要误用和滥用设计模式。但是有一点是需要额外强调的。当分析模型已经能够完整、正确的描述需求之后，我们就需要在设计模型中添加设计资料。例如对包、组件、类、方法的描述。这时候，需求的信息已经被打散到软件的各个部分中了。而设计模型在被实现时，设计模型中的信息又将进入到代码中。因此，保持这些信息的一致性就显得非常的关键。而由于设计模型处在中间地带，它的重要性又是不言而喻的。基本的处理思路分为两步：在需求发生改变时，请同步更改设计模型以及设计模型中的信息。再由设计模型驱动代码的修改。第一个步骤是需要手动实现的，但是第二个步骤可以由计算机辅助实现，即保持设计模型和代码信息的一致性（将在 一致性的思考模式中讨论）。目前有很多的建模工具都可以做到这一点，甚至能够实现产生最终的API文档。善用这项功能，它能令你事半功倍。
在软件过程中设立反馈活动，可以有效的减少项目的偏差。就像我们骑自行车，很少能够走一条直线，一般我们是根据对目标的偏差进行忽左忽右的调整。这就是反馈的机理。原型法是一种不错的反馈机制，根据我们的经验，视觉刺激对用户是最为关键的，因此不论你的需求文档做的如何的优秀，仍然比不上一个能够看得见的软件原型有效。这一实践很多的软件工程资料中都有叙述，我们就不深入了解了。另一种反馈机制是渐进交付。把软件产品分为多个迭代周期，每个周期交付一个可运行的软件，在获得用户的反馈意见之后，在下一个迭代周期进行改进，最后一个迭代周期交付的就是完整的软件了。
对可重用框架的改进
在找到了适合软件企业自身的知识接力方法之后，应当将其作为规范或指导意见，加入到现有的软件过程中。例如，在需求分析完成之后强制要求进行需求评审。加入到过程中的方法，小心不要流于形式。这样，既付出了成本，又收不到应用的效果。使用工具也是保持知识顺利交接的重要方法。例如，采用自动产生源代码的工具，模型设计工具、帮助产生工具、对象-关系映射工具等等。如果这些工具对你的过程起到了润滑的作用，请规范和普及工具的使用。
小结
请确保领域专家和技术专家之间的顺畅沟通。
完整、准确的描述需求。
进行需求复审和设计复审。
保证分析模型（设计模型）能够完整的描述需求。
保持需求信息到设计信息到代码注释的一致。
使用反馈机制。
文章来源于领测软件测试网 https://www.ltesting.net/
