对于软件需求的描述，不应仅仅描述要实现的功能或非功能需求，还应对每条需求都要给出一个初验标准。
什么是初验标准
所谓初验标准，就是使用可测度的数据对用户需求进行宣描述，以便在“验收”的时侯，能够用量化的数据确认需求是否实现。这里的初验标准，不是针对软件产品的，而是针对用户需求，针对每一条的用户需求。
这么说来，验收标准原先就是对需求的定量描述。可是用户需求是这么好定量描述的吗？
对于功能需求易用性测试 文档测试，相对来说，还是比较容易的，而这些非功能性需求，比如，性能、安全性、易用性等要定量描述却是往往让人摸不到脑子。其实，这只不过是因为你还没有理解用户的真正意图。
比如这样的一条需求：产品应当用户友好。如何定量描述“用户友好”？这就要求你要去了解“用户友好”的更准确的含意。例如，是指便于学习，或便于使用，或其他涵义？
假定用户的意图是“我希望我的用户能快速学会使用该产品”，这表明测度的尺度是“掌握给定任务所需的时间”。那么，对“用户友好”的初验标准建议是：在新用户第一次使用该产品时，他们将能否在30分钟内完成增、改、删等基本操作。
2. 为什么软件需求一定要有初验标准？
软件需求有初验标准，至少可以带来以下3方面的益处：
当需求用定量数据描述时，存在误会的可能性应特别小了。比如这样的需求描述：在90%的情况下，工程师将在15秒钟内得到软件系统形成的工程计划。这样的描述，无论用户、开发人员、测试人员对需求的理解都不会有误差。
在清除了需求的歧义，达成了需求的一致理解，用户对于需求的确认，就会很容易进行。因为这种需求描述都很清楚，确定其重要性以及排定其优先级，就不算什么难事。
需求实现的验证一般是通过测试来进行的。在编撰测试用例的时侯，需要给出预期的结果，需要给出有效输入数据和无效输入数据的测试用例，这些要求，在每条需求都有初验标准的情况下将很容易满足。
3. 验收标准示例
那么，验收标准应当如何写呢？下面举几个事例：
一项功能性需求是产品必须做的某件事情，是产品必须采取的一项动作，因此初验标准指明了怎样获知产品早已成功地完成该动作。
比如，一项功能需求描述是：产品将记录气象站的读数。 对应的初验标准：记录的气象站读数将与气象站发送的读数相符。
如果功能需求是进行某种估算，那么初验标准将强调，计算的结果必须与权威机构对数据的想法一致。
例如，如果需求是“产品将记录……”，那么初验标准就类似“取得的数据将符合……（数据的最初来源）”。如果需求是“产品将检测……”，那么初验标准将是“被检测的数据将符合……（权威的数据来源）”。
一项性能需求的描述：响应速率足够快，以防止打断用户的思路。
验收标准：在95%的情况下易用性测试 文档测试，响应时间将不超过1.5秒，在其他情况下不超过4秒。
需求描述：只有使用A类登陆的工程师就能更改气象站的数据。 验收标准：在1000次气象数据的更改k全部由A类登陆的工程师完成，没有例外。
需求描述：产品将是直观的和自解释的。 验收标准：在首次使用该产品时，工程师才能在30分钟内得到一份正确的除冰预报。
4. 小结
需求的初验标准/定量描述对于需求管理和需求开发，以及验证和确认来说都是至关重要的。不搞好它，可能会在开发过程中引入大量的潜在缺陷，给软件研发带来巨大的风险。
