如何在一个商业应用中以灵巧的方式为需求建模呢？让我们来看下面的例子。在这个例子中，我们要为一个SWA Online的系统建立需求模型。在开始之前，读者必须认识到几个问题。第一，因为本文主要集中在需求建模的讨论上，如涉及到其它类型的建模，如分析建模、构架建模或设计建模，我会就此打住并给出我所著的相关文章的连接。灵巧方式的软件开发是高度反复的过程，由此实际上需求建模与其它类型建模的界线不是很明确的。第二，这里所讲的只是许多可用方式的一种，其它的方式也可能是灵巧的。记住，AM是一套基于实践的方法，它没有定义特定的，规范的一种做法，因此可采取的方式是多样的。不用担心，我会在过程中给出我可能会采用的另外的方式，但这也不是所有的 -- 保持你开放的思维。第三，由于SWA Online的开发小组采用的是Enterprise Unified Process(EUP)(Ambler,2001b)开发流程，那么使用案例就会起主要的作用。反之，如果采用的是eXtreme Programming(XP)(Beck,2000)的话，用户故事就会占主导地位。我在AM and XP一文中从XP的角度重新讨论了这个例子。第四，这个例子虽然是基于我的实际经历所虚构的，但我想这会使我们的讨论更加形象而简单。第五，最好将需求建模化分为两个不同的阶段：需求初始阶段（initial requirement up front(IRUF)）和详细需求建模阶段。
需求初始阶段(IRUF)
需求初始阶段(IRUF)发生在整个项目生命周期的开始，对应于Rational Unified Process(RUP)(Kruchten,2000)中的Inception phase和XP中的第一个迭代之前。它有三个主要的目的：第一，至少从高层次上确定系统的范围，以明确你所要做的工作的范围；第二，定义系统的高层需求；第三，对于需求的含义，在甲方和开发项目组间取得一致。如果你和项目甲方在同一个地点，而且他们能就该系统应该做什么达成比较一致的意见，这个阶段可能只需要几个小时；否则的话，有可能会延长至几天或数周（参见“解决需求分析建模中的常见难题”一节）。你可能需要召开一个大的建模会议，主要是实现需求初始阶段的这三个目的。这些会议有如下特点：
§ 时间长。对一个大的项目可能需要几天。
§ 有许多项目甲方参加，以便广泛地听取他们的需求。
§ 趋向于比较正式的形式（主要由于参加会议的人数众多，而且项目甲方对哪些灵巧的方式并不熟悉）。
§ 包括一些开发人员。尤其是当你开始想让项目组理解该系统是完成什么样的功能时。
系统范围的定义可能用一句话就够了，对SWA Online就可以简而言之为“通过互联网向客户出售产品”或者详细一点的如“在美国本土向新老客户出售有形的而非虚拟的产品”。系统范围同样可使用环境模型（context model）来定义，该模型表示你的系统如何适应所有的环境。它经常使用使用案例图进行表示，参见图5；或用数据流图（DFD），参见图4（常叫做level-0 DFD）。搞清楚系统的范围非常重要，只有这样才能限定你的开发工作。上面的第一句话过于笼统，它可能意味着面向的是国际上的客户，明显这比仅针对美国本土客户的工作量大很多。同样，出售虚拟产品如在线音乐需要另外一套在线交付系统的支持。随着时间的推移，这个范围有可能由于甲方的决定的改变而变化，所以时刻准备好迎接变化。
那么哪一个最适合描述系统范围呢？一句话，DFD，还是使用案例图？根据你的情况而定。语句直接了当，但不如图形的内涵丰富。图4的DFD以所要建造的系统为中心，表述了其与其它外部实体（组织、人或其它系统）的关系，这些外部实体超出了你的系统的控制范围但与你的系统有相互作用。这种方式的主要优点是它以合理的细节描绘了你的系统与外界间的主要信息流动。图5的使用案例图同样以所要建造的系统为中心，以及与该系统有交互的参与者（组织或人）。它的主要优点是描绘出与系统有交互的外部的和内部的参与者，而DFD仅有外部的。主要的缺点就是它没有给出任何一点系统与参与者交互的细节。你应该使用哪一个呢？他们都有各自的优缺点，你可能会考虑都使用。嗯… …？这对我而言不是很灵巧。一个较好的解决办法就是稍稍违反一下规则，结合这两种方式优点仅生成一个图，就象我在图6中所作的。注意一下我的风格：在两个实体的左上角用“I”表示出这是内部实体；移去了DFD中的数字标识符（数字标识符难于人工维护），我宁愿遵循一定的规则以使实体的名称唯一，在需要时这个唯一的名称可以起到标识符的作用。虽然我选择了显示数据流而不得不打破一些使用案例图的规则，但我仍然能够轻易地使用使用案例图的符号。幸运的是我的项目甲方喜欢DFD，我也就投其所好了。记住有目的地建模这条原则就是要你了解你的听众，选取最适合他们的artifact。
不要害怕打破规则。一般经验告诉我们不要在level-0 DFD中包含内部实体，引入内部实体意味着你开始挖掘细节。但我之所以在这里却选择了这样做，是因为它能让我不用再画第二张图。我不会因此而死到临头，也不会招致建模警察的控诉。是的，我违反了应用建模标准这一条做法，但这样做我减少了开发和维护的费用。当这对于某些人成为一个很大的问题时，我想我的组织可以重新考虑一下标准。
为了确定系统的高层需求，我推荐采取基于使用的方法， 即注意力集中在用户如何利用该系统工作这一点上。根据我的经验，这是一个对绝大多数的软件开发都有效的方法。如果你对用户如何使用系统没有一点概念，很难想象你所生产的软件能够支持他们的工作和改善他们的工作方式。我会将这个方法用在建立组织内部使用的商业应用，由客户所使用的商业软件，包装出售的软件（如CASE工具或文字处理软件），数据仓库的开发，甚至于集成现有的商业系统（COTS）如SAP R/3或Oracle Financials。在数据仓库系统的开发中，存在着一个普遍的错误，那就是首先收集“数据需求”。罗列出用户想存储在数据仓库中的数据元素或数据实体。乍看上去，这是个好主意，但如果你不知道用户如何使用这些数据，那么你很难定出优先级或者你根本就不清楚你所做的是否就是甲方所想得到的。对于COTS系统，你需要根据需求来选择使用何种建模方式。如表1所列出的有特性（Feature）、使用情景（Usage Scenarios）、使用案例（Use Case）和用户故事（User Stories），这都是比较好的方式。根据使用恰当artifact这一条，我会选择使用案例，因为SWA采用EUP作为软件开发的主要流程，而使用案例是最适合于这个流程的。如果他们选择的是XP，则用用户故事为佳。如果为Feature Driven Development(FDD)(Coad,Lefebvre,Deluca,1999)，那特性就是我的选择。
图7是一个高层的使用案例图，它是一张数字照片，来自于我和我的项目甲方讨论时在白板上所画的图。这是一个基本使用案例图（Constantine & Lockwood, 1999; Ambler, 2001a），因为它以技术无关的观点来显示系统。基于这张图，你既可以全手工的方式来实现这个系统，也可以建造一个全自动的系统。其中的一个使用案例“Post Product Review”可以改名为“Write Product Review”以使之更趋于一般化，但我的项目甲方更偏爱前者。我一直在为尽可能地使需求无关于特定的技术而努力，但事实上许多系统已经局限于某个领域内。例如，SWA Online被限定为基于互联网的解决方案之上，此时如花费精力去尝试将其抽象出来，只会得不偿失。记住保证甲方的投资获得最大利益这条原则，将你的精力集中在能带来效益的那些需求模型上。
使用案例应力求简单，在初始阶段(IRUF)对每个案例有一点提纲挈领式的逻辑描述就足够了。你不必在此时进行细化，你仅需要对该系统的用途有个基本了解，确定初始的范围，再对每个使用案例和参与者加一点提纲挈领式的描述。如果得到项目甲方的认可，你就不用花费更多的精力在初始阶段。可能三到四个使用案例就足够了。然后遵循有目的地建模这条原则，我们就可以终止初始阶段的工作，进入到详细建模阶段去建立详细的模型和实现你所确定的这些需求。注意这种方法更多地是运用在实行XP的项目中，而非实行UP的项目中。
你们可以看见在图7所示的需求图中我使用了UML的构造型（stereotype ）<<Include>>，然而在《The Object Primer 2/e》(Ambler, 2001a)一书中我曾建议在分析层次的使用案例图中使用构造型（stereotype），典型的如系统使用案例图，因为它们经常反映了架构和设计方面的问题，而需求层次的使用案例图却并非如此。同样，我也不会因为如此而受到建模警察的控诉。这个图是有意义的，因为它显示出它对处于流程中不同阶段的模型是公共的，在这里它表示我要考虑的包含需求和分析两方面的问题。
要在项目甲方之间达成一致的意见，这说起来容易，作起来难，尽管你有了“解决需求建模中的常见难题”这几招。每个甲方的背景、优先权和喜好都各不相同。为了达成一致意见，每个人都必须认识到这点，相互交流他们需要从该系统中得到什么，倾听他人的意见，准备为了达到一个共同的目标而努力。在我所工作的组中，只要发生意见分歧，我们都会在屋内所有人都能看见的一块白板前写下每人的问题，再进行讨论。这种方式将这些意见的不同之处可视化，可以集中讨论的焦点。在某个问题的提出者认为它不再需要或至少相对于其它问题不那么重要后，我们会将它擦去。虽然有时它是一个较好的意见，但也简单地将之擦去，因为通常我希望记录的是最后的决定。对于两个相互对立的问题，我喜欢在它们之间画一条其它颜色的连线，以突出它们需要进行讨论。
由于我们集中在高层次的使用需求上，相关的业务规则和约束常常也会被同时确定下来。同样，一些技术需求和将来可能或不可能被实现的需求也会确定。在初始阶段（IRUF）你应该将业务规则、约束和技术需求排列出来，常用的方法是将它们写在粘贴纸上或白板上，找出你是否已具备了足够的信息以进行后一阶段的工作。尽快地结束初始阶段的目的是防止你在这个阶段就投入时间探究细节。当你在初始阶段需求讨论会上就进行细节的讨论时，你就给你的项目带来了风险，因为此时你不会收到对你工作的具体反馈，从而陷入分析的泥潭。记住这条原则你的主要目的是软件，而不是那些设想你的软件如何运作的模型和文档。例如在SWA Online的初始需求建模会上，项目甲方提出了一些业务规则和执行顺序的约束，象如何打包某类的货物，某些产品具有一定的上架时间限制，以及分捡流程。当我听到诸如此类的需求时，我就会叫某个人将其写在白板上或索引卡片上，稍后再将这些索引卡片放在每人都能看到的公用桌上。
这里有一个重要的观点：建模会议是交互的，每人都参与其中的。会议的开始需要一个有经验的模型设计者来段开场白，解释一些技术，推动与会者进入状态。这可能就是简单地叫某人走上台来，解释一下正在谈论的内容，演示一下通过填写一张索引卡来总结一条业务规则，或者为一个可能需要的报表在粘贴纸上记录下数据的要求。当与会者熟悉了这种建模方式后，依照灵巧建模的甲方的积极参与这一做法，你会发现不用花太多的精力去鼓励他们的参与。是的，有些人比较开始害羞而需要更多的鼓动，但那毕竟是人的本性（如果我能选择的话，我更喜欢选择那些外向甲方的加入，而非那些内向不愿开口讲出他们意见的人）。
当你的开发组在确定目前版本的需求时，常常伴随着一些后续版本的需求或一些你可能在某时需要实现的潜在需求。虽然此时你不想过多地深究，而且你也不想实现过多的功能去满足这些潜在的需求，但你并不想就此丢弃它们。它们也是有价值的。这些潜在的需求可能会影响到你对系统架构的选择。变化案例（change case）（Bennett, 1997; Ambler, 2001a）是一项用于记录潜在需求的简单技术，图8是SWA Online中的两个变化案例。在定义项目范围时一项重要的工作就是指出哪些需求是现在应该实现的，哪些是超出范围的。变换案例中的需求就是超出当前项目范围的。如何有效地使用变化案例的详细内容可参见Agile Architecture一文。
变化：扩展至北美地区
可能性：非常可能
期限：12-18个月
影响：
§ 必须支持向加拿大和墨西哥的用户交货。与新托运商的关系需要建立。
§ 需要计算相关的税收和关税。
§ 由于法律和当地风俗习惯，在这些市场出售的产品有可能会有所不同。
§ 多语言支持（英语和法语是加拿大的官方语言，墨西哥是西班牙语）。
变化：销售虚拟产品（在线音乐、录像、书籍… …）
可能性：非常可能
期限：6-12个月
影响：
§ 不能与实际产品的运输流程混在一起。
§ 我们可能需要对某些产品支持数字许可。
§ 个别产品的销售可能有某种限制（有效时间、拷贝数量）
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
