这只是在办公室的另一天。与客户讨论数小时后，您刚刚完成了对项目的需求收集。接下来是什么？您是否只是根据这些要求编写软件需求规范（SRS）？
您可能曾经想过：这些要求是否完整？它们与我们已经收集的内容一致吗？最终产品是否仍存在一些歧义？
如果其他人要收集需求，他们会得到一组完全相似的需求，还是最终会得到多于或少于此的东西。他们的要求相关的解决方案会有所不同吗？随着时间的流逝，所有这些问题都会消失，因为我们需要做的工作和需要时限。
不幸的是，没有任何措施可以保证需求的完整性，而公认的事实是需求永远不会完成。幸运的是，可以制定一套准则来确保这些要求尽可能接近完整。
覆盖范围 –收集的需求应充分说明所需的行为/功能。有差距吗？还有其他“为什么”需要回答吗？
清晰度 –是否还有一些含糊不清的地方，需要澄清吗？
原子 –需求应如此详细，以使每个需求都应在原子层次上。是否可以用两种不同的方式解释这些要求中的任何一项？
角色 –每个任务/活动应与一个角色相关联。可能是系统自动执行某些操作，也可能是助手将文档从一个纸盘移到另一个纸盘。最好将它们全部捕获。是否有没有定义角色并且以后可能导致冲突的活动？
一致性 –在第1天，总经理可能会说，一旦零件的可用数量低于再订购水平，系统便应自动创建采购订单。在第17天，采购经理可能会说，一旦零件的可用数量降至再订购水平以下，系统应提醒买方，然后买方将根据该周分配的预算来决定是否进行采购。是否有任何与先前所述相矛盾的要求？
要求永远无法完成，准则也不能做到。但是，如果以上任何一个问题的答案是“是”或什至是“也许”，那么在进行下一步之前，您需要做一些工作。
让我们考虑一个简单的例子来说明这一点。客户说，他/她应该能够看到与供应商/维修代理商有关的每个零件的采购提前期，维修提前期，购买成本和维修成本。
承保范围 -假设我们已经在应用程序中的某个位置捕获了采购和维修的提前期，那么客户是否要查看已捕获的此信息，或者客户是否要根据发送订单的时间和时间查看实际的提前期。零件已收到。
清晰度 –提前期应该是与最新购买/维修有关的时间，或者应该是移动平均数。如果它是移动平均线，应在什么时期内计算该周期，我们在哪里捕获该周期？
原子 –前置时间单位应该是多少？费用应以哪种货币显示为不同的货币？
角色 –谁将使用此信息？做出一些重要决定的可能是买方和经理。因此，最好在客户正在使用的ERP产品的某些现有屏幕（供买方使用）中提供此信息，或者将其作为独立的屏幕提供给所有希望查看此信息的人。
一致性 –假设买家将交货时间计算为定单发送日期与零件接收日期之间的时间。采购经理可能希望将提前期视为从供应商确认日期到航空运单日期之间的时间，以便进行某些分析。那么，我们要显示哪个交货时间？还是两者？
在收集需求和提出解决方案时经常被忽略的方面是体系结构对解决方案的影响。这些天，我们经常听到术语“非功能需求”，它们与功能需求一样重要。
拥有能够自动分析购买方式并使用系统数据来建议应根据数量和需要日期从其处采购零件的供应商的软件产品有什么用，但要花3天的时间才能得出结果？
如果产品是基于一种在一年后就已经过时的特定技术构建的，而我们却没有基础架构或熟练的人力资源，当出现问题时该怎么办呢？
该产品很棒，可以完美地提供结果。但是没人知道如何使用它，因为它需要遵循一系列复杂的步骤。
客户是否有办法测试和验证交付的解决方案是否按要求工作？最终用户是否足够了解最终用户要完成的工作？
当公司扩展并在新位置添加新实体时，是否可以增强产品以为所有实体提供结果？
客户是否有足够的信心确定第三方不会访问系统中输入的数据？
这些要点依次指性能，可维护性，可用性，可测试性，可伸缩性和安全性。
当注意到任何功能需求时，业务分析师最好考虑与功能需求相关的非功能需求。
例如，在决定要由调度程序完成某事之前，应适当考虑所花费的时间以及一段时间内调度程序使用的数据的增长。
在建议用户在系统中做某事之前，我们应该考虑一下该系统对于具有给定技能/知识水平的人是否易于理解和使用。查询客户的短期和长期计划并分析其对需求/提议解决方案的影响始终是一种好的做法。
为业务分析师举办研讨会并向他们进行这些方面的教育是大多数组织公认的成功方法。实际上，作为鑫北斗ERP系统举办的员工培训计划的一部分，我从需求收集和客户处理研讨会中受益匪浅。另外，为了更严格地控制分析人员/顾问提供的解决方案，我们在鑫北斗中以RSPRINT的形式维护了方案和解决方案的存储库。使用RSPRINT，顾问可以检查类似情况下较早给出的解决方案，并且可以重用或增强解决方案并更新数据库，以便它将使其他顾问受益并改善给出的解决方案的一致性。
好的，现在是时候返回并完成SRS了。但是在这样做之前，请先检查一下需求是否完整和一致，以及是否可以从中得出任何非功能性需求。
客服毛燕