事务定义：一个业务流程可能会启动几个更小业务事务的实例，一个业务“流程”将由一个“应用程序”来实施，但它也可能由多个应用程序来实施。对于很多“数量”性的需求，都是需要确定业务量和大小信息，例如：

a、预计在一般时间和在高峰期将各有多少用户使用各个业务流程或应用程序？

B、什么时候是高峰期（根据情况确定每天、每周、每月等的高峰期）？

C、在高峰期和一般时间将各需要以什么速度处理事务？

D、在每个数据组中数据元素和实例的数量以及它们的大小。

如果没有这些约束，很多“非功能性需求”将变得没有意义或不可实现。就像没有严格定义的约束都可以变成聪明和懒惰的程序员的挡箭牌一样。

考虑如下“非功能性需求”：

性能需求：

1、响应时间：对各类/夜间）是否可以接受不同的标准？（请注意关于高峰期以在上面说明），在高峰期和一般时间将各需要以什么速度处理事务？被认为可用的最低性能条件（也就是说，在该点以下，系统将被认为是“不可用”而不是“缓慢”）是什么？孤立的要求：“响应时间不能超过3秒”这样类似的需求，是不恰当的（很模糊）。我们能够明确的事情为什么要搞得很模糊呢？？？还要注意我们对“各种类别”的响应提出的时间要求。这里需要的数字可能也要花费一些时间来得出，绝不是随意的，不恰当的性能需求可能对系统构架产生不可估计的变化。别的响应时间需求，将在哪里对其进行评测，在不同时间（例如非高峰时间

2、可用性：指定适当的可用性需求，以直接反映最终用户为了完成其业务目标而具有的需求；以较小的间隔（例如按照各个流程、用户组、数据组等）来指定可用性需求，而不要指定整个系统的“全局”需求。比如对于：系统必须每天 24 小时为用户提供服务。如果能够改为：“系统必须能够在中国时间7：00到20：00能够对用户的数据执行事务处理”可能对于设计人员而言具有更大的灵活性，他们也许可以在其他时间段执行数据或系统维护或是安排系统完成其他调度性的任务，以使系统能够以更高的性能在工作时间为用户提供事务处理能力。如果未达到特定的可用性目标也不会对用户完成其业务目标的能力产生直接的影响，那么该可用性目标就可能不适合于作为系统的可用性需求。考虑一下：不直接与用户相关的一些流程（例如夜间数据交换、耗时较长的数据分析等）。对服务中断可能产生的影响应该仔细考虑和度量的，比如1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时、一天、多天等的影响有多大？应确定应急过程并考虑这些过程如何能减少中断对业务所造成的实际影响。尽量从财务上量化这种影响（员工或设备生产效率降低的成本、失去当前业务的价值损失、因客户不满意而对未来业务造成的估计损失、利息开支、法规性处罚等）。量化有助于提出更合适的需求。

3、灾难恢复：在项目的范围内，是否需要灾难恢复？如果需要，该恢复的标准是什么？服务必须在多长时间内恢复？恢复时间从什么时候开始计算，是从灾难发生时开始计算，还是从开始进行恢复工作时开始？在远程进行还是在本地进行？数据必须处于怎样的更新状态才能使业务继续进行（必须时刻最新；在发生故障后的几分钟内更新；可接受前一天的数据）？相对于依赖相同计算设备的其他业务应用程序，这组应用程序的远程恢复具有何种优先级？你能简单的说：“必须在2小时以内恢复”吗？直接来源于用户的需求可能是这样的：不能影响业务处理。然而可能是因为系统故障引起的适当处理延迟是可以允许的，因为这种延迟不会影响业务的进行。但如果是超过一天的故障则影响第二天的业务处理等。