来自于 Rational Edge：业务需求、软件需求、业务规则、非功能需求、约束以及用例，这些都是 需求工程学中普遍使用的术语。尽管每一种需求所涉及到的内容都是不相同的，但是在一个复杂的需求陈述中它们却往往被混为一谈。本文将提供一种把复杂的需求陈述分割开来，逐个剖析的方法，从而使得业务需求和软件需求更加清晰分明的呈现出来。
下面这种启发用户说出需求的场景您是否感觉很熟悉呢？
他说：“我希望系统会很快。”
您说：“当然。”
他说：“而且使用起来很方便。”
您说：“我明白。”
他说：“所有的文档应该被集中存放在一起，就好像我们在地下室中的档案文件。”
您说：“好的。”
他说：“我们要求每一位员工在登录和注销时都签署一张卡片。但同时我们也必须遵守最近颁布的某某指导原则。”
您说：“可以。”（记录下来）
尽管为捕获需求所付出的努力比起记录这些需求的方式要重要的多，但是一位业务信息分析师或者需求工程师仍然要记录、归纳和总结关于这个项目的各种需求。在先启阶段通常以某种迭代的方式进行，在这期间，新的需求呈现出来，已经存在的需求则转化为某种我们所期望的类型和结构。在与涉众进行有关需求的谈判期间，我们经常会发现先前捕获的需求信息并不重要甚至已经不复存在，而一些新的需求则在这个过程中显现出来。
在上面这个简短的场景中，你如何判断哪些需求与商业需要相关，哪些需求还与软件功能相关？这是一个非常重要的问题，因为把各个需求彼此分割开来将导致各自独立的需求陈述，这对于不同需求各自的优先权（时刻表）、 风险和花费的分派是至关重要的。在工程的后期阶段重新来做这项工作将是非常耗费时间的，同时也是产生含糊和错误的一个可能原因。特别是在测试阶段，未被分离的需求将给整个工程带来额外的负担，因为此时对需求进行精确的确认和查证是一件非常麻烦的事情。
一旦分离开来，经过分割的需求类型将会节省工程的时间和开销。需求管理计划是一件合适的工具，它将表明您会以何种方式记录和处理工程中遇到的各种需求。
本文在如下三个与需求工程相关的领域提出建议：
如何弄清需求类型的词汇
如何与涉众讨论需求类型中的相互依赖性
记录混杂在一起的不同需求的实例和指导方针
一个商业或者软件系统可以通过逐一记录下需求陈述来备案，这些陈述也可以通过运用用例设计的原则得到极大的扩展。在讨论用例之前，让我们先来考虑一些关于业务需求、软件需求和业务规则的传统需求分析的原则。
业务需求与软件需求
业务需求是关于业务行为的陈述，与此不同，软件需求（也称功能需求）关注的是“系统应该……（做什么）。”软件需求通常描述已经存在的或是未来的软件系统，并且应该与业务需求同步。显然，一个计划好的软件系统应该帮助企业更加有效地完成工作。
让我们退回来再看看这样一些情节，它们将展示业务需求和软件需求之间的不同之处。
办公自动化：计算机能够快速的完成大多数工作，在很多情况下，它们比起人工操作更加高效和可靠。更不用说它们可以不停歇的一直工作，以及在危险恶劣的环境中工作了。因此，我们试图将尽可能多的日常工作委派给计算机及其系统来完成。例如，我们当中的许多人都使用一种时间管理系统来记录我们的工作时间。在得到时间之后，我们进入一个自动化的许可进程。即使整个进程都是电子化的，我们仍然使用“时间表单”或“工作表单”这样的称谓。通过 互联网访问这个文档要远远快于在某组织某部门中寻找到那张纸制的时间表单。在这个例子中，业务需求（记录和批准时间表单）已经转换为软件需求，纸张处理过程已经被电子处理过程所取代。
手工办公的需求：对于一家人寿保险公司来说，评估赔偿风险可能完全基于保险商的主观经验。并不是所有的业务需求都已被数字化了，手工处理可能会与计算机技术共同存在。在这个例子中，计算机系统将得到风险估价的结果，而不是真正进行风险估价的操作，保险商将会继续操作这些业务需求（评估风险），而系统只是记录保险商的决定。
提高办公能力：不仅计算机系统可以取代一些活动，信息技术也可以为组织机构提供一些管理业务的新方法。例如，出纳员将产品的价格输入终端机和后台系统的方法就是一种由于条形码和扫描仪的发明而带来的新方法。在交易的最后合计价格，这种对于夫妻店仍然行之有效的业务需求，现在可以通过与扫描仪和条形码技术相关的软件需求来执行。
在上面的场景中，软件需求清晰地与业务需求区分开来，两者都受到 过程改进机会和自动控制的影响。
文章来源于领测软件测试网 https://www.ltesting.net/
