需求必须是具体的、可测量的、可控的、可现实的以及限时的。这比看起来更有挑战性。可是，通过寻问以下的问题就能够很容易地完成：
为什么要用这种方式来处理?
您将获得什么样的结果，或者如果这个问题被解决您将能够做什么?
明确地说，什么过程将会受到这个障碍的影响?
通过补偿这个过程将会得到什么利益(尽可能是可计算的)?
做什么来改变事情?
这通常很难回答，涉众们往往回到问题的陈述上来。需求工程可以以一些如果……怎么样的建议来获取一些可能性。尽管如此，还是要在涉众们回到正轨时立即撤回。
关于时间框架，对于背景和业务环境什么时候可以完成?
这并不是特意为项目交付而设的点，而是推理业务背景的起点。例如，一个上网卡的商人想要以节日为目标开张他的新 Web 站点。
确定并阐明范围
什么是进什么是出? 什么被执行了或者被交付了，什么时间?
确定“主语”和“谓语”
这是经常最容易被忽略的，也是范围频繁变化的主要原因。如果这不仅仅是一个动词，可以将它规定为独特的需求。这提高了明确性并促进涉众们之间更好的理解。
关注需求本身，而不是如何实现
业务需求通常陈述完成了什么，并且应该避免任何关于怎样完成的提示。例如，一个企业想要主观的、综合的观点融合到他们的业务数据中。重点应该是他们想要做什么，而不是他们需要得到什么(例如，数据库)。
需求样例
ESC 有几个基于 Web 的应用软件。因为每个应用软件都是独立开发的，消费者面临着像需要分别在每个应用软件上注册以及对于每个业务功能需要不同的窗口的问题，引起了他们的抱怨。为了解决这些抱怨，ESC 业务小组制定了下面的需求：
BR264： 消费者应该能够通过一个兼容的界面访问所有的 ESC 应用软件，并且只需要注册一次。ESCWeb(主要的商业 Web 网站)对于所有的消费者应该有相同的外观和感觉。这将减少用户差错并提高用户的体验。ESCWeb 最终也将支持移动的和远程的客户。
很显然，这个需求能够被改善。通过运用这些原则，我们能够对它进行如下的重述。
BR264：在 ESC5.0 版本中，消费者想要注册一次就可以应用所有的 ESC应用软件，包括 ESCWeb、 ESCOrderStatus、 ESCVendor 以及 ESCSupport。
BR265：在 ESC5.0 版本中，所有的 ESC 应用软件将执行 ESC Web Standard 273-1 和 273-2，这将再减少10%的用户差错。
技术1. 确定 RequisitePro 中的业务需求
在这个记录将需求记录在 RequisitePro 的技术中，关键是保持获取和澄清这个需求的原则。这个技术包括三个步骤：
确定一个业务需求的Requirement Type。所有的业务需求都将分配这个类型。BUS是一个习惯性的前缀。
当规定一个 Requirement Type 时，利用Requirement Must Contain选项来指定一个分隔符(比如 \"|\")。这个主语和谓语可被安置在分隔符的任何一边。这并不是强制性的要求，RequisitePro 手册有更多的细节。方法是在识别主谓成为需求的过程中使用逐渐导出的原则。
在最高层次为业务需求创建一个包。您可以立即看到它是如何帮助跟踪的。
技术1现在已经完成。您已经获取了一个清晰而且简洁的业务需求，并准备好转向下一个阶段。图 2显示了这个技术。
图 2. 利用技术1获取业务需求
用例
技术2 (将用例与需求连接起来)覆盖了这个项目的下一个阶段。只要业务需要被确定，这个业务构架师或者分析师就会开发用例来对它们进行说明。尤其对于大的或者复杂的项目，业务分析师经常会遇到这样两个问题：
需求存在于文档中(除非您使用技术1)，用例位于模型中，比如 Rational Rose® Enterprise (Rose)。
由于需求(和用例)的数量逐渐增长，拆分也变得越来越难于管理。
业务需求与用例是如何连接起来的?用例捕获用户的视角，他们说明了用户的行为和系统的回应。但是业务需求远远超越了作为一个服务于用例的数据源。当规定了属性或者限制时，它们就变成了用例的属性(或者备用信息流)。我们应该能够记录业务需求和一个用例之间正常的连接，并用它做一些有意义的事情，比如跟踪或者分析。
建模用例时需要大量的资料。在资源部分中的文章都是很好的起点。查看这些案例属于这篇文章以外的范围，但是我们将介绍一个应用于这个技术实现的命名习惯。
文章来源于领测软件测试网 https://www.ltesting.net/
