软件测试员经常抱怨软件需求说明书描述的太模糊而无法测试。你如何确定需求已满足？在编写适用于这种情况的软件需求说明书时要遵循一些规则。

　　需求必须是可测量的、原子的（即专注于一个目标）和明确的，测试人员和开发人员都必须确保他们理解软件需求说明书的内容。

　　当编写者没有意识到测试需求的必要性或者有效测试的特殊要求的重要性时，就会显现出需求的不可测试性。

　　编写软件需求说明书时避免模糊描述的最好方式就是运用积极倾听方法。想做到这一点，就要让测试人员（和开发人员，但是主要还是集中在测试人员上）在认为某种需求是必需时，需要和你进行沟通。这可以是口头表述，但是这意味着有一个可能性,就是在测试前谈论的共享信息会缺失。在这种情况下有效的方法是让测试人员记录下来测试设计。测试的设计体现了测试人员对需要测试内容的理解，就像开发人员要了解所建文档的细节一样。

　　作为需求的设计者，你将回顾测试设计并确认针对需求的每个验收标准都要进行一次测试。无论是哪方的责任，任何没有经过相关测试的验收标准都可能导致沟通失败。在测试设计中可能存在不必要的测试环节。测试人员假设一个验收标准，但是编写者却不赞同，同样也可能导致沟通失败。审查测试设计，需要需求编写者充分并了解所有细微差别、排列和场景，这样在原子需求的情况下就会实施该方案。

　　所谓原子需求就是无论是否完善都要经过测量的需求。例如，告知用户提供身份验证和赋予应用程序访问权限的需求就不是原子的。你将需要两个独立的需求，一个反映用户通过身份验证的需求，另一个向通过身份验证的用户提供访问应用程序的权限。这样既可以独立开发，也可以独立测试。

　　该方法的优点就是，可以使开发人员编写的代码更模块化。更模块化代码的更改和需求的重复利用在未来研发中会更加容易。例如，将研发的软件投入到新市场中，此时安全需求会更加严格，你可以引入未来双重认证的需求。如果用这样一种方式来编写软件：有别于授予通过验证的用户权限的代码，建立一个模块化身份验证，会使身份验证机制的开发和测试修改更加容易。

　　可测量需求的表述有时候是非常直接的。例如，“密码必须至少有8个字符”，这样的表述就十分清楚，然而，“密码必须是安全的”，这样的表述就很模糊，因为“安全”这个词的表述就不清楚。在这样情况下，对需求目标的回顾就非常重要。此时的目标是阻止未授权的访问，所以，反映安全水平的验收标准就要比容易衡量的验收标准更好一些。

　　例如，你可能会说系统不允许未授权的用户在一个小时内以暴力攻击的方式访问应用程序。八字符的“密码”会阻止这样的攻击，因此，八个字节的限制是一个迫切的需求。

　　向开发人员提供灵活性也很重要。例如，他们可能选择已经连续三次身份验证失败的“锁定”帐户。在定义测量时，确定量度的合理范围很重要，此时进行一次需求测试效果会更好。

　　特别是通过建立和审查设计文档而完成任务时，积极倾听方案对发现无法测试的需求是非常有效的。当需求的编写者发现测试设计没有符合验收标准时就会出现歧义。在测试设计分析中会发现其缺乏原子性，将需求分解为多个需求，这种缺乏原子性就会更明显。当测试设计未能准确的解释量度时，测量目标不清楚就会变得很明显，通常，通过结合一个测试集合,接受的测试就会通过而不可接受的测试测试将失败。测试成功或失败之间不存在临界值，这不是编写者的目的，对其误解也会变得明显。

　　作为奖励，测试设计文档可以在开发人员之间共享，提供给他们更加清楚的文档，允许他们在“测试”之前向测试人员提交该测试方案，并作为个人发展历程的一部分。这将导致更加高效的软件开发。

　　一旦需求编写者喜欢上这样的方式，在记录需求和在收集清晰的市场信息时，他们首先在心理上就会接受这样的过程。从积累经验方面考虑，积极倾听方案会节省更多时间，从需求的角度考虑，能够以最少的修改使其更容易测试。