来自于 Rational Edge：业务需求、软件需求、业务规则、非功能需求、约束以及用例，这些都是需求工程学中普遍使用的术语。尽管每一种需求所涉及到的内容都是不相同的，但是在一个复杂的需求陈述中它们却往往被混为一谈。本文将提供一种把复杂的需求陈述分割开来，逐个剖析的方法，从而使得业务需求和软件需求更加清晰分明的呈现出来。

下面这种启发用户说出需求的场景您是否感觉很熟悉呢？

他说：“我希望系统会很快。”
　您说：“当然。”
　他说：“而且使用起来很方便。”
　您说：“我明白。”
　他说：“所有的文档应该被集中存放在一起，就好像我们在地下室中的档案文件。”
　您说：“好的。”
　他说：“我们要求每一位员工在登录和注销时都签署一张卡片。但同时我们也必须遵守最近颁布的某某指导原则。”
　您说：“可以。”（记录下来）

尽管为捕获需求所付出的努力比起记录这些需求的方式要重要的多，但是一位业务信息分析师或者需求工程师仍然要记录、归纳和总结关于这个项目的各种需求。在先启阶段通常以某种迭代的方式进行，在这期间，新的需求呈现出来，已经存在的需求则转化为某种我们所期望的类型和结构。在与涉众进行有关需求的谈判期间，我们经常会发现先前捕获的需求信息并不重要甚至已经不复存在，而一些新的需求则在这个过程中显现出来。

在上面这个简短的场景中，你如何判断哪些需求与商业需要相关，哪些需求还与软件功能相关？这是一个非常重要的问题，因为把各个需求彼此分割开来将导致各自独立的需求陈述，这对于不同需求各自的优先权（时刻表）、风险和花费的分派是至关重要的。在工程的后期阶段重新来做这项工作将是非常耗费时间的，同时也是产生含糊和错误的一个可能原因。特别是在测试阶段，未被分离的需求将给整个工程带来额外的负担，因为此时对需求进行精确的确认和查证是一件非常麻烦的事情。

一旦分离开来，经过分割的需求类型将会节省工程的时间和开销。需求管理计划是一件合适的工具，它将表明您会以何种方式记录和处理工程中遇到的各种需求。

本文在如下三个与需求工程相关的领域提出建议：

如何弄清需求类型的词汇

如何与涉众讨论需求类型中的相互依赖性

记录混杂在一起的不同需求的实例和指导方针
　一个商业或者软件系统可以通过逐一记录下需求陈述来备案，这些陈述也可以通过运用用例设计的原则得到极大的扩展。在讨论用例之前，让我们先来考虑一些关于业务需求、软件需求和业务规则的传统需求分析的原则。

业务需求与软件需求

业务需求是关于业务行为的陈述，与此不同，软件需求（也称功能需求）关注的是“系统应该……（做什么）。”软件需求通常描述已经存在的或是未来的软件系统，并且应该与业务需求同步。显然，一个计划好的软件系统应该帮助企业更加有效地完成工作。

让我们退回来再看看这样一些情节，它们将展示业务需求和软件需求之间的不同之处。

• 办公自动化：计算机能够快速的完成大多数工作，在很多情况下，它们比起人工操作更加高效和可靠。更不用说它们可以不停歇的一直工作，以及在危险恶劣的环境中工作了。因此，我们试图将尽可能多的日常工作委派给计算机及其系统来完成。例如，我们当中的许多人都使用一种时间管理系统来记录我们的工作时间。在得到时间之后，我们进入一个自动化的许可进程。即使整个进程都是电子化的，我们仍然使用“时间表单”或“工作表单”这样的称谓。通过互联网访问这个文档要远远快于在某组织某部门中寻找到那张纸制的时间表单。在这个例子中，业务需求（记录和批准时间表单）已经转换为软件需求，纸张处理过程已经被电子处理过程所取代。
• 手工办公的需求：对于一家人寿保险公司来说，评估赔偿风险可能完全基于保险商的主观经验。并不是所有的业务需求都已被数字化了，手工处理可能会与计算机技术共同存在。在这个例子中，计算机系统将得到风险估价的结果，而不是真正进行风险估价的操作，保险商将会继续操作这些业务需求（评估风险），而系统只是记录保险商的决定。
• 提高办公能力：不仅计算机系统可以取代一些活动，信息技术也可以为组织机构提供一些管理业务的新方法。例如，出纳员将产品的价格输入终端机和后台系统的方法就是一种由于条形码和扫描仪的发明而带来的新方法。在交易的最后合计价格，这种对于夫妻店仍然行之有效的业务需求，现在可以通过与扫描仪和条形码技术相关的软件需求来执行。
  在上面的场景中，软件需求清晰地与业务需求区分开来，两者都受到过程改进机会和自动控制的影响。

一个更深层次的区别：业务规则

业务规则描述和规定了组织机构的政策方针。这些规则因为组织易变这一天性所以通常是灵活能变的，而且经常是由一些非常细小的步骤组成，就像决策表同业务需求相关联一样。随后，业务规则经常受频繁的变化支配。有的业务规则以电子的形式实现，有的则不是。一些业务规则还需要符合法律规范和调整的需求，比如一些由美国通信委员会、美国食品及药物管理局、联邦航空局1等等制定的规范。

顺便提一下，我使用的术语业务需求表示组织机构发挥作用的特定工业范围内的标准实践；例如，“保险应用软件必须由申请者签字。”我应用的术语业务规则表示一个特定组织的某个细节规定；例如，“对于65岁以上的新申请者，必须有三个保险商批准申请。”

这些例子清楚的表明业务规则更具动态性，也更加关注某个特定的组织。与此不同，业务需求更加稳定，与产业发展也更趋一致。因此，得出好的业务规则需要那些富有经验的雇员们的知识，他们熟悉所在组织的实际工作，也具备相应的专业知识。如果这个领域（比如酒店业）为需求工程师所了解，那么首要的工作要点就是软件需求和业务规则。因此，我在下面的例子中使用术语业务规则来描述软件和业务之间的关系。

下面的例子将证明为什么业务规则和其他需求应该被区别对待。

假定我们开发一个自动取款机系统，我们看到两种不同的软件需求，SR1和SR2：

SR1：系统根据指定数额从账户中提取现金，但是一天内最多只能取1000美元。
　SR2：系统根据指定数额从账户中提取现金，但是一天内最多只能取三次。

在上面这个例子中，我们面对两种需求结合在一起的挑战。在SR1中，“系统根据指定数额从账户中提取现金”是一种软件需求，但是最高金额为1000美元使这种陈述复杂化了。在SR2中，同样的软件需求又一次被另一个规则复杂化了。如果我们的业务需要附加某个新的政策时我们应当如何做呢？举例来说：

SR3：系统根据指定数额从账户中提取现金，但是取款后不能导致余额为负数。

按照规定测试这些需求不能精确的返回“成功”或者“失败”，因为每一项复杂的陈述都需要一张判断表。当政策变化时，不仅需求陈述的数量会显著的增加，而且每一个新政策的复杂度也会增长，这会使得在测试阶段检验需求更加困难。

相反，下面这个例子将会展示业务规则如何从需求陈述中分离出来。

SR1：系统根据指定数额从账户中提取现金。

BRULE1：一天内最多只能取1000美元（24小时营业）。
　BRULE2：一天内最多只能取三次（24小时营业）。
　BRULE3：账户余额必须大于零

像上面这样的业务规则更容易管理和测试。例如，一个测试工程师可以在对各个政策测试进行前单独检验SR1。

将业务规则从软件需求中剥离出来是对于描述、分析和确认需求都很有好处的一项技术。但是，从那些混杂在一起的陈述中分离出来的需求，需要被联结到软件需求中来建立上下文关系。图一、图二和图三显示了如何完成这些工作。

图一：软件需求和业务规则之间的关系
　
　图二：IBM Rational RequisitePro允许在需求分析阶段获得业务规则
　
　图三：使用IBM Rational RequisitePro描述软件需求到业务规则

沟通业务规则只是事情的一部分，另一部分就是“对策”，它是指一旦初始的业务规则遭到破坏（假定的情节）所需要强制采取的措施。例如，如果有人试图在24小时内第四次取款，系统应该作出何种反应？如果某种业务规则由于另外一套业务规则而遭到破坏，交易又该如何反应呢？如果交易需要将这条业务规则整合到软件之中，就必须作出规定，例如：

BR4：在多于三次从24小时服务窗口取款之后，账户将被冻结。

图四描述了在RequisitePro中这种假定的情节如何被捕获。

图四：在假定情节下，用RequisitePro描述需求到业务规则

由于业务规则是动态的而且受制于调整和结构性改变所带来的变化（新的产品、服务、绑定、合并、让产易股等等），所以它们能够在组织机构宽度的“规则驱动”中执行，这为软件工程师提供了很多机会。这种规则驱动可以担当组织机构中警察的角色，并且监控组织机构中现有策略的变化。例如，正如图五所描述的，银行决定提高取款的限制。通过与软件需求的联结，产生了一个疑点，它清晰的向软件工程师指出哪一个软件需求受到了影响。

在面向对象的软件设计中，由于业务规则被分派给对象，所以这种想法可以很好的得到实现。图五展示了这是如何在RequisitePro中呈现的。

图五：描述业务规则到软件需求中的改变

非功能需求

非功能需求（NFRs）往往以“系统应该是……”这样的短语开始，紧接着使用“快速”、“易于使用”、“直观好学”等形容词，它们经常同其他需求类型混在一起。传统意义上，非功能需求适用于整个系统，例如“系统应该是用128位加密码保障安全性的”或者“系统应当提供两秒钟的反应时间”等等。但是，情况并非总是如此。

许多用户通过“系统”体验人机交互界面。图形用户界面因此成为一项颇受非技术涉众欢迎的条款。例如：

应该可以轻易地看到保险政策的历史。

在这个陈述中有两个问题使得需求变得复杂：

功能性（历史）同非功能性（易于使用）混杂在一起。

　“易于”是一个主观的概念，是无法详细描述的。
　非功能性需求的陈述经常是没有被明确定义的，这使得它们很难被估量和测试。在这个特定的例子中，我要通过问清楚“易于”这个词来确定这个需求是对于整个系统都有效，还是仅仅同例子中政策的历史这一功能结合在一起。

细节中的可用性需求表现了个人的风格和品位；并不是所有的需求都会吸引所有的涉众。细心筛选那些适用于大多数用户以及你的赞助商的需求。有时，可看可感的标准和规范可以避免关于颜色、字体以及导航等问题的长时间的争论。你是如何看待下面这份需求陈述的呢？它是用于控制一台核能设备还是一种单人纸牌游戏呢？

系统应该是可靠的。

在系统中将功能性和非功能性分离是很重要的，同样，像下面这个例子中那样给予非功能性适当的范围也很重要。

SR1：系统应当捕获所有政策变化的历史信息。

NFR1: 政策的历史应当很容易被找回。品质（鼠标点击数）：

　容易 - 0次
　可以 - 1次
　不容易 - 2次或者更多

约束

当非功能性需求的陈述包含词语“必须”时，通常是表明一个或更多的约束适用于整个系统；例如，遵守指导方针、法律或者行业规范。约束应当被从其他需求类型中分离出来，同其他类型的非功能需求一样被来区别对待。例如：

C1： 系统必须遵守某某管理法令。
　C2： 系统必须能够容忍故障发生。
　（品质：系统崩溃次数/星期）
　非常好：0-1
　可以接受：2-5
　不可接受：>5

　用例设计

关于用例的书已经出了不少，它们论述了用例的风格、深度以及细节。我不打算再介绍这些题目，而是要阐明如何将业务用例同系统用例分开记录。

我们来考虑一个实际的例子。假设我们要为旅馆搭建一个前台终端设备。这家旅馆起初都是通过手工流程操作。钥匙、日历本、擦除器和钢笔都是前台需要用到的工具。在我们开始规划未来的前台应用程序之前，首先来看一看当前已经存在的用例，也被称作当前场景。这个业务用例的程序“顾客登记”是这样的：

用例：“顾客登记”

当顾客进入大厅时用例开始。

前台服务员询问顾客想要的房间类型。

顾客告知前台服务员想要的房间类型。

前台核对记录后为顾客提供一间房间。

顾客决定住进这间房间。

前台服务员请顾客出示驾照并询问其付款方式。

顾客出示驾照并用信用卡付款。

前台服务员将顾客信息记录到日历本上，并批准该信用卡在信用卡终端设备上使用。

信用卡终端设备允许该信用卡的使用。

前台服务员得到房间钥匙。

前台服务员将证件、信用卡以及房间钥匙一并还给顾客。

顾客获得房间的相关信息并拿着钥匙离开。
　在记录下旅馆前台的业务情景（当前情景）之后，涉众将决定哪一步使用前台终端系统自动管理，以及开发一个未来情景来描述系统展开后的流程。首先，需要绘制一张描绘系统边界轮廓以及用例发展的用例表草图（如图六所示）。其次，需要更多的粒状系统用例来描述使用者和系统之间的相互作用。一旦具体化，这些用例就会包含软件需求。

图六：用Rational Rose绘出的部分用例表

此表提供了关于所规划系统的范围的重要信息。例如，系统没有搭建一个信用卡处理器（外部已存在的系统），但会同其建立一个接口。同样，我们会看到前台服务员通过这个未来的系统都能够完成哪些事情（顾客登记等）。

现在我们来看一看这个用例的一个更加细粒度的描述，在图七中，它更加周密的考虑到了系统边界问题，并且显示了进一步分离需求的可能。

图七：用例描述（未来情景）：“顾客登记”使用两栏格式

尽管用例为实际的系统交互提供了更大的余地，但是系统栏仍然提供了一幅在右侧栏里所指示的系统职责的清晰画面。我们再看一看上面例子中的第11步：“在顾客入住期间系统冻结这所房间，并且将顾客同该房间联系起来。”

正如我们前面的例子那样，一旦我们将软件需求同与其相关的业务规则之间的需求陈述分割开来，我们就能在用例描述中分离各个步骤，并将它们标记为系统中的各自独立的需求。这种新的流程如下所示：

11. 系统在顾客入住期间将该房间标记为已被占用。

12. 系统将顾客同该房间联系起来。

将用例的一个步骤切分为这样两个步骤可以使两种需求彼此独立开来。它们可以被分别的验证和确认，并且能够被更容易的追踪完成。在初始的“顾客登记”描述中所显示的用户同系统之间的交互作用，现在作为应用软件的一部分（自己完成登记），因此实现了办公的自动化。

图七中所描述的登记程序遵循旅馆行业的标准流程。同有关软件需求及与其关联的业务规则的讨论类似，业务规则也可以同特定的用例步骤相联系。例如，图七中的第五步，我们从未阐明可提供的这个词语的确切含义。这个特定的旅馆可能有这样的业务规则，那就是可提供的就是特指同一档价位的房间，可连续居住（不用中途换房），或者在请求期间的所有类型的房间。这种指明了可提供性的选定的业务规则就可以同用例流程中的某一步骤联系起来，并为软件工程师在设计房间可提供性时提供了一个精确的答案。

深入的发现

当我们看到纯手工的操作例如家务管理时，就更容易发现自动控制和业务流程的改进机会。在新房间被租用之前（见图七中的第四步），房间的可用性需要被通知给前台。报告这一情况可以有不同的方式。例如，清扫人员可以1）拿一张清单，并在他们轮班之后将其交到前台，或者 2）他们可以在房间清扫干净之后打电话给前台。交清单方式的缺点是速度缓慢，前台将无法在第一时间得到相关信息。而第二种方法的缺点是增加了前台的工作量，影响到前台与顾客的面对面交流。

还有第三种解决方案，它不再把房间信息的更新工作委派给前台服务员和清扫人员，一种新的“确认房间占用”业务用例的步骤C。

用例：“确认房间占用”

清扫人员从房间中呼叫电话系统。

清扫人员输入一段代码通知系统该房间已被清扫完毕。

　电话系统将更新的信息传送给前台信息系统。
　这个例子表明了前台服务员如何从动态消息传递活动中解放出来，以及房间信息如何实时更新。要求清扫人员在房间可以提供时通知前台的这种业务需求仍然存在，但是在记录和将业务关注点从软件需求中分割出来的过程之中，一种新的软件需求又被发现了。在所建议的解决方案中，旅馆电话系统需要同前台信息系统建立接口。下面的用例表描述了边界和用户之间的不同；我们注意到用户“清扫人员”并不是直接同真正的前台信息系统交互，而是要通过电话系统。这个额外的系统需要同我们的旅馆前台终端设备建立接口，从而有一个新的软件需求给予这项技术而呈现出来。

图八：部分用例表，包括“确认房间占用”

用例颇受涉众的欢迎，因为它们撒了一个关于其所在业务和系统的谎。业务相对系统用例的清晰分割以及内部相对外部的清晰区分使得工程师可以从一个特定的角度来观察相应的流程，然后决定哪些地方需要改进和革新。通过仔细观察业务用例中使用者的活动以及确定哪一种活动能够被信息技术所取代，新的软件需求就会呈现出来。随之而来的一个正面影响就是随着平稳的融合进商业社会中，信息系统也来越有希望达到甚至超出客户的期望。

总结

在此介绍的技术，将需求分割的技术，是关注混杂在一起的需求以及它们之间相互依赖性的一种方法。此项技术使得业务分析师能够对已经存在的需求范围作出鉴别和核对，也提供了一种协商弥合需求隔阂的方法。

另外，我发现这项技术在分割用例所记录的功能性需求时很有用，同样，对于附加需求规范（SRS）中记录的非功能性需求也很有用。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号