理想情况下，带实例的需求说明应该从业务角度出发清晰地定义所需的功能，而不是去定义系统应该如何实现细节。这样，开发团队可以自由地找出符合需求的最佳方案。要达到这样的目的，需求说明应该具备以下条件：1、精确、可测。2、是真正的需求说明，而不是脚本。3、是关于业务功能的，而不是关于软件设计的。换言之，需求说明应该是：1、不言而喻的。2、专注的。3、使用领域语言编写的。如何提炼出好的需求说明：1、实例要精确可测：需求说明必须基于精确的、实际的例子。2、脚本不是需求说明。3、不要使用流程式的描述。4、需求说明应当关注业务功能，而不是软件设计： （1）、应该让开发人员在当下找出最佳的解决方案。 （2）、让开发人员在未来改善他们的设计。5、避免编写与代码紧密耦合的需求说明：这样的需求说明会让测试异常脆弱，并带来额外的维护成本。可执行的需求说明会指引我们交付正确的业务功能。技术性测试可以确保我们去关注系统低层次的技术质量方面。两者我们都需要，但是不应该混合在一起。技术性测试的自动化工具比我们自动化可执行需求说明的工具更适合技术性测试。6、在处理遗留系统时，不要在需求守门中引入技术难点的临时解决方案：技术难题应该放到自动化层去处理，不要试图在测试说明中解决。7、在WEB项目中，不要陷入到用户界面的细节里：考虑用户在站点上的操作过程会更加有用。8、需求说明应该是不言自明的。9、使用叙述性标题并使用短篇幅阐释目标：标题应总结出需求说明的意图。10、展示给别人看病保持沉默：使用更有意义的名字或者加一些注解让是实例更容易让人理解。11、不要过度定义实例：过度定义实例会使得原来的关键实例所带来的价值被显著淡化，无法突出重点。需求说明中应该只列出关键的具有代表性的实例。这将有助于需求说明保持简短易懂。关键实例通常具备以下特点： （1）、它是一个具有代表性的实例，描述了业务功能的每一个重要方面，通常商业用户、分析师或客户会对其进行定义。 （2）、他会描述每一个重要技术的边缘情况，比如技术上的边界条件。通常当开发人员担心功能分歧或者不一致性时，他们会举出这样的例子。商业用户、分析师或者客户则会对其定义正确的预期行为。 （3）、他会描述预期实现的每一个棘手之处，比如以前导致缺陷的情况，或者在以前的实例中没有描述清楚的边界条件。通常测试人员会列举出这种例子，而商业用户、分析师或者用户则会定义它的正确行为。12、当需要使用许多参数组合描述业务规则的情况下，从简单的例子入手，然后逐步展开。13、需求说明要专注：一个需求说明应该单独描述一件事情：一条业务规则、一个功能、或者过程的一个步骤。专注的需求说明比较简短，并且易于维护。14、在需求说明中使用“Given-When-Then”语言：（1）、假定（Given）一个前提。（2）、当（When）某个行为发生时。（3）、那么（Then）后置条件就会得到满足。需求说明可以定义几个前置条件和后置条件（Given和Then部分定义多个条款），前提是它们与测试定义的功能有直接的关系。15、当处理复杂的依赖（或引用的完整性）时，不要在需求说明中明确建立所有依赖：这些问题可以在自动化层而不是从需求说明中得到很好的解决。把所有的跟需求说明的目标不相干的依赖全部移到自动化层中，并保持需求说明只专注于重要的属性和对象。16、在自动化层中应用缺省值：自动化层使用合理的缺省值预先填充对象，并建立起相关依赖，这样我们就不必显示地对他们进行说明。这使得我们在编写需求说明的时候只关注与重要的属性，以让需求说明更容易理解和维护。这样的缺省值可以在自动化层中设定，也可以在全局的配置文件中提供，具体去决定于商业用户是否可以对他们进行修改。17、当有许多属性的对象时，不要总是依赖缺省值：在编程语言中消除重复通常是一种很好的做法，但对需求说明而言却不见得如此，应该避免多度使用这种方式。18、需求说明应使用领域语言：功能新需求说明对用户、业务分析师、测试人员、开发人员以及任何想要了解系统的人都十分重要，所以必须使用每个人都能理解的语言来编写。铭记：1、不要直接使用最初的实例，要对它们进行提炼，以得出需求说明。2、为了充分利用实例，最终的需求说明应该是精确的、可测的、不言自明的、专注的、并以领域语言编写，同业务功能相关。3、在需求说明中要避免使用脚本，避免谈及软件设计。4、不要试图覆盖所有用例。需求说明不是用来替代组合回归测试的。5、所有重要的用例集，都要先从一个例子开始着手，并增加值得程序员和测试人员特别关心的例子。6、在需求说明、软件设计以及测试中定义并使用统一语言。