版权申明：本文的翻译没有获得作者的授权，所以这篇译文仅作为学习使用。禁止任何人转载此文获作为商业用途，如果有任何人认为这篇文章侵犯了你的权利，请来信告诉我们。  我的哲学观认为项目涉众应该参与需求的建模和文档化，不是仅仅停留在提供信息的阶段，而是应该参与到工作中来。是的，这要求开发人员的一些培训、指导、训练，但这并非是不可实现的。我就见过项目涉众的建模和文档做的非常好的，而且这种项目遍布在不同规模的组织中：小型的刚起步的公司、大型企业、政府机构中；跨越多个行业：电信、金融、制造、军事。为什么这一点特别重要呢？因为只有你的项目涉众才是需求的“专家”。他们清除他们想要什么？而且只有你试过，他们是可以学会如何为需求建模和编制文档的。这从敏捷的观点上来看也是有道理的：它把建模的努力、成就分到了更多人的头上。 为了使项目涉众更容易的、更积极的加入到需求建模和需求文档化的活动中来，为了减少商业术语形成的隔阂，你需要进行一项实践：使用简单工具。在表格1中列出的很多需求工件的建模可以使用简单的工具，也可以使用复杂的工具－有一栏列举出了每一个工件的简单工具。图2和图3就向我们展示了两个使用简单工具建立的模型。图2中使用了使用了即时贴和活动挂图来建立需求模型，而图3使用索引卡片来进行概念建模。只要你在需求建模中使用了新的技术－例如使用画图工具来创建用例图的各个版本，或是使用功能多多的CASE工具－你就会在无形中将你的项目涉众排斥在外，因为他们不仅要学习建模技术还要学习建模工具。“保持简单”，这样你就鼓励了大家的参与，也增加了有效合作的机会。   我素来坚信需求是和技术无关的。当听到诸如面向对象需求，结构化需求，甚至是基于组件需求之类的术语的时候，我困惑不已。这些术语，面向对象，结构化，基于组件，都是实现技术的分类。虽然你可以从这些类别中选取一个来实现，这可能也会限制你，但是至少，你必须要关心需求。所以，只有需求。我下面所描述的所有的技术都是用来为这些类别的系统建立需求模型的。 有时候你可能没有办法做到技术无关的需求。例如，大多数的项目来都有一个普遍的限制，就是不论可能与否，都必须利用现有的技术构架。其实，在这个层次上，需求仍是技术无关的，但是如果你要深究下去，开始列出一张现有构架的组件清单的时候―例如，你的your Sybase vX.Y.Z 数据库或是你必须整合一个现有的SAP R/3模块―你就过线了。只要你懂得该做什么和不该做什么就OK了。 始终牢记，“片状思考”。小片的需求－例如功能（features）和素材（user stories）－要比大型的需求－例如用例（use case）－更容易预估。平均每一个用例描述的功能性要比素材多，所以我们认为用例要大型一些。 同样，在你投资建立需求可跟踪矩阵之前你也要考虑清楚。可跟踪性是各方面的项目工件联系在一起的一种能力，而需求可跟踪矩阵就是一种被用来记录这种联系的工件－它开始于你的独立的需求，贯穿了你建立起来的那些分析模型，架构模型、设计模型、源代码和测试用例。我的经验是有跟踪能力文化的组织常常是定期的更新这些工件，而不是当发生时才更新，这样才能保持这些工件（包括矩阵）之间的一致性。拥有这样一个矩阵的好处是但你在需求变化的时候能够较容易做影响分析，因为你知道这项变化会影响到系统的哪些方面。可是，如果你的系统只有几个人熟悉，而你想要提高系统的效率，那么更简单、更廉价的做法就是简单的告诉你的开发人员预估这种变化的成本。以我的经验，建立这么一种需求可跟踪矩阵常常都是得不偿失，即使你有专门的工具来实现，依然无法超过它所付出的代价。让你的项目涉众了解建立这种矩阵的成本和收益，由他们自己决定。毕竟，可跟踪也属于文档，应此是一个业务决定，一个应该由涉众做出的决定。 Types of Requirements 我相信需求可以分为两类：功能性和非功能性。一个功能性（behavioral）需求描述了用户如何和系统交互（用户界面 user interface issues），他们怎样使用系统（用法 usage），系统怎样完成一个系统功能（业务规则 business rules）。一个非功能性（non-behavioral）需求描述了系统中的某个技术特征，特别是那些和可用性、安全性、性能性、交互性、依赖性、可靠性有关的技术特征。有一点需要清楚，功能性和非功能性需求之间的界限有时候并不清楚。一个描述数据存储速度期望值的性能需求看起来似乎很明显是一个实质的技术指标，但是它又可以反映为用户界面的响应时间，这就关系到可用性和潜在用法。访问控制，例如允许谁访问特定信息， 很明显是一个非功能性需求，但是它通常被认为是一个安全性问题而被归入非功能性需求这一类中。不过，对这种问题没有必要死扣，有大致的概念就好了。关键的还是你要鉴别和理解给定的需求，至于你将需求分错了类，哼哼，Who Care？ Potential Requirements Artifacts 由于这里有好几种不同的需求类型，也许其中的一些（或全部）适合你的项目。另外，每一种建模工件都有它的长处和短处，你需要掌握好几种需求建模工件来丰富你脑中的工具箱。表1总结了一些通用的需求建模工件，工件的细节是在另一篇论文－Artifacts for Agile Modeling.中讨论的。你可以使用简单的工具来创建各种不同类型的需求的模型。（关于使用简单公交互的重要性可以参考前面的小节－Some Philosophy）。 记住重要的一点：虽然你可以使用各种各样的工件来收集需求，但是这并不是意味着你在一个项目中要全部用上这些工件。原则“了解你的模型”建议你在合适的时候再去了解如何使用这些工件。关于这个方面，你可以按照实践“运用合适的工件”所说的来。 处于在需求工程下方的过程会影响工件的选择。在我的主页上我建议AM应该和其它的软件过程配合使用，例如XP或是UP，这些都是完整的生命周期。下层的过程通常会偏向于使用某一种需求工件。例如XP的素材和UP的用例。这是你进行需求建模的时候必须要考虑的一个问题。这方面的细节可以参考我的论文AM and XP 和 AM and UP。 A Usage-Centered Approach 究竟你应该怎样用敏捷的办法来建立需求模型呢？让我们来看一个例子，在这个案例中你将通过SWA Online case study.学习如何为需求建模。在我们正式开始之前，有一些问题我们需要先了解。第一，因为这篇文章的焦点集中在需求建模上，所以其它的一些讨论，如涉及到分析模型、架构模型、设计模型之类的都不在我们的讨论之列，这种情况下，我们会适时的结束讨论并回到我们的主题上来，同时会给出相关的文章的导引。敏捷软件开发是以迭代为基础的，结果是需求建模和其它的建模活动间的界限非常模糊。第二，我们采用的方法只是众多敏捷方法中的一种。记住，AM只是一种以实践为基础的方法，而不是那种定义了许多的细枝末节，告诉你这怎么做，那怎么做的方法。所以有许多方法能够实现目的。不用担心，我会给你指出一些备选的方法，但你自己需要保持一颗开放的心。第三，由于SWA Online团队采用的过程主要是根据EUP（Enterprise Unified Process）制定的，所以工件也会以用例为主，在需求建模中会大量使用它。而在XP方法中，素材会反之占有绝对的优势。一样的，对这点你也不用担心，在AM and XP一文中，我们也详细讨论了从XP的观点来看待这种案例的学习。第四，在我写这一节的时候，我发现它看起来是那么的真实，就像是发生在我们周围的一个活生生的例子。不过，事实上，它只是根据我在构建电子商务系统中的经验虚拟出来的。第五，我们最好把需求工程分成两个部分来考虑：初始需求阶段（IRUF initial requirements up front）和细节建模阶段。 The Initial Requirements Up Front (IRUF) Phase 初始需求阶段发生在你的项目的生命周期的开始阶段，即在RUP（Rational Unified Process）（Kruchten, 2000）中被称为先启的阶段，XP中的第一次迭代之前。在IRUF阶段有三个主要的目标：首先是在一个高层的层次上定义系统范围，这样你就可以找出系统的边界其次是为系统定义高阶的需求；最后是在你的涉众和你的开发人员中取得一致意见，保证需求的顺利进行。IRUF阶段可能非常的短，也许只有几个小时，特别是你的涉众和你身处同一场所，而且涉众对系统很快的达成了一致的意见。如果不是这么完美的化，这个阶段也有可能会延展到几天甚至几个星期。特别是你需要召开大型的建模会议，集中讨论IRUF阶段的几个目标。这种需求会议的特点包括： · 很长，一些大型的项目甚至可能会达到几天。 · 需要很多的涉众参与，以保证听到的需求是最大范围的。 · 通常是比较正式的（常常是由于人数较多，或是项目涉众间比较不熟悉的缘故） · 包括一些开发人员，特别是你希望你的团队能够理解你的系统的时候。 系统的范围可以用一句简单的语句来描述，在SWA Online的这个例子中我们就可以简单的描述为“通过因特网向顾客销售产品”或是更复杂一些的语句“把真实的而不是虚拟的产品销售给美国的客户，包括了旧客户和新客户”。系统范围也可以使用一个上下文模型来描述。模型现实你的系统如何适应整体环境，可以使用用例图来描述（如图5），也可以使用DFD图来表示（如图4）（这种的DFD图通常被称为0级DFD图）。了解系统的范围很重要，这样你就不会做一些超出系统范围的无用功。第一个叙述就显得太含糊。我们可以认为比起美国本土的客户，你的精力更多的放在因特网客户身上，同样，我们也可以认为你会销售虚拟产品，例如在线音乐。这就要求你除了物理递送网络之外还需要一个在线的递送网络。你也可能会发现你的范围时刻都在变化，所以你的项目涉众需要做出决定，而且必须要做到拥抱变化。   那什么是描述系统范围的最好的工件呢？陈述语句，DFD图，还是用例图？这取决于你的具体情况。陈述语句非常直接，但是不如图那么清晰。图4的DFD图显示，图的正中是系统，旁边是外部实体，如组织，人，其他系统。这些外部实体虽然不是系统的一部分，但是它们都和系统有关，各实体之间的线段表示它们之间的关系。这种方法的最大好处就是很清楚的显示了系统和外部世界的信息的主要流动的细节。图5的用例图则是体现另一侧面的系统，它同样在正中描述系统，旁边是和系统发生联系的角色（组织。人）。这种方法的主要优势是同时描述；阿外部和内部的，和系统交互的角色。而不是象DFD图那样只能描述系统外部的方面。而它的主要缺点是它不能描述系统和角色的交互的细节。那我们该采用哪种图示呢？既然有优点又有缺点，我们是不是应该两者都采用呢？Hmmmm…这不过是中庸的想法罢了。一个比较好的办法是只画一张图，打破规则，把两张图好的地方拿出来合成一张图，就像我在图6中的那样。注意到了吗，我在属于内部实体的两个实体的左上方做了一个“I”的标记，这是我自己的风格。另外，我还是用数字来标记每个实体。不过，数字标记手工并不好处理，我宁可额外加一个规则，每个实体姓名都是唯一的，这样的化，它就能够起到数字标记的作用了。我也可以很容易的在DFD图中使用用例图的符号。我使用用例图的规则来表示DFD图的数据流。因为我的项目涉众比较偏爱DFD图，所以我也尊重他们的偏好。记住这个原则：“建模要带有目的性”，它建议你了解你的听众，选择一个最适合他们的工件。 不要惧怕打破规则。尽管一般实践告诉我们在0级的DFD图中不要包含内部实体，但是在这个例子中，你开始挖掘细节的时候，你就必需要介绍内部实体。我在图6中这样做，就避免了再画一张图。再说了，没有采用严格的建模策略，地球也不会消失啊。是的，这种观点和我的另一个原则“运用标准的建模准则”相矛盾，但是这样做，我可以同时降低开发和维护的费用。所以标准成为一个大问题的话，我的组织中就要重新考虑这些标准了。  为了能够确定系统的高阶需求，我比较倾向于采用一个“以用法为基础”的方法。你的主要注意力都要集中在你的用户如何使用你的系统工作上。我的经验告诉我，这对于软件开发来说是一个非常有效的方法。想想看，如果你连用户如何使用你的系统工作都不了解，那你声称说你的系统能够改进他们的工作方式，不斥于是天方夜谭。这种方法可以适用于你组织内部使用的商业应用，适用于你组织的客户使用的商业软件，适用于包装销售的软件（如CASE工具和文字处理器），适用于数据仓库的开发，适用于COTS（commercial off the shelf）的系统集成（如SAP的R/3系统、Oracle的金融系统）。在一个数据仓库的案例中，最常犯的一个问题是收集“数据需求”，列出人们需要在数据仓库中存储的data element和data entity。这种方法表面上似乎并没有什么不妥，但是如果你不知道这些数据是用来做什么的，你就很难对你的努力排出优先级，你也无法了解你的项目涉众到底需要些什么。在COTS系统的案例中，你也同样需要这样的需求来评估你需要使用的软件包。表1中列出的那些工件，功能、使用情节、用例、素材，都是非常好的选择。根据实践“使用最合适的工件”，我会选择用例来描述SWA Online系统，因为SWA公司是使用EUP作为软件过程的首要基础，所以我选择用例正好适应于这种状况。如果他们选择XP作为首要基础，那素材就成为最合适的工件。同样，如果首要基础是FDD（Feature Driven Development）(Coad, Lefebvre, DeLuca, 1999) ，功能也会是最佳选择。 图7就是我和我的项目涉众一起创建的高阶用例图，是在白板上画的，然后用数字处理的。这是个基本用例图，因为它和技术无关，这意味着它可以手工实现，也可以自动化实现。是的，用例“登记产品复核”这个名称似乎换成“记载产品符合”更好一些。但是我的项目涉众认为这个词对他们更加贴切。我总是努力的做到需求和技术无关，但是现实是许多的系统都被限制在某一种架构中，如SWA Online就限制在一个基于因特网的解决方案。所以花时间把系统从这种限制中脱离出来抽象为一个真正的技术无关型的系统是没有很大的价值的。记住这个原则“让你的涉众的投资最大化”，把你的需求建模的努力花在能够提供真正价值的工作上。 在IRUF 阶段，用例应该描述的简单一些，只要能够描述出每个用例的逻辑要点就可以了。你不必要在这个时候描述出系统的所有细节，你紧紧需要了解系统应该完成的任务的一个基本认识，以及系统最初始的范围和每个用例和角色的概要描述。如果你的项目涉众允许你不需要在IRUF阶段太过深入，你可能只需要识别出3或4个用例就已经足够了。这就是原则“目的建模”。接下来你就可以结束你的IRUF阶段，将精力集中到细节建模，针对先前的识别的需求讨论如何建模和实现。注意，相较采用UP的项目而言，这种做事的顺序对于一个采用XP的项目会更加自然一些。 在图7中，你可以看到我在需求建模图中应用了UML的版型（stereotype）<<Include>>。然而在The Object Primer 2/e (Ambler, 2001a) 一书中，我推荐说这种版型最好是在分析这个层次上使用，尤其它被引用在系统用例图中的时候。这是因为这种版型通常反映出一种架构或是设计的问题，而这并不是需求阶段的用例图需要关心的。还是那句话，不严格的遵循开发策略，这个世界也不会因此而遭受灭顶之灾。这个用例图的有趣之处就在于我把其中的一些交叉引用的共通部分提取出来。这反映了我同时考虑了需求和分析两方面的问题的事实。 在你的项目涉众中达成一致的意见，这一点知易行难。这方面的具体信息可以参阅我的overcome the common challenges to requirements efforts。每个的项目涉众都有不同的背景，不同的权限级别，不同的选择。要想在不同的人之间达成一致性，每个人都要认识到差异性的事实，交流他们对系统的需要，倾听其他人的意见，准备好共同向一个目标努力。不论何时，我们在团队合作的时候，总是会在一致性上遇到问题。这时候，我们会在白板上写下每一个人的问题，所有人都可以看到这些问题，并讨论这些问题。这样就真实的再现了涉众们的差别，并给他们提供一个集中讨论的平台。有时我会把一个问题从白板上去掉，因为问题的提出者意识到他的问题是不需要或是重要性不能够和其它的问题并列的。我也喜欢在一些对立的问题之间画上直线，这样大家的注意力都会集中到这上面来。使用特别的颜色或标记也能够达到这种效果。 当小组在讨论高阶使用需求的时候，除了考虑系统的技术需求和业务需求，他们还要识别出相关的业务规则和限制。在IRUF阶段，你应该“存放”一些系统规则、限制和技术需求，通常可以把他们记录在白板的活动挂图上，获取足够的信息以供你在探索更多的细节的时候了解需求。目标是尽可能快的结束IRUF阶段，这可以避免花费过多的时间追寻细节。如果你在初始需求阶段就开始讨论细节，你就会陷入分析麻痹的危机之中－你的时间会浪费在分析细节上面。记住这个原则“软件才是你的主要目标”，不要把你的精力都放在建立模型和文档上面，不断的描绘你的软件会是一个什么样子。举个例子，在SWA Online这个项目的初始需求会议中，我的项目涉众也会识别出一些和订货相关的业务规则和限制，如如何打包某种类型的货物，有些货物有它的限定的装柜期限，还有装船的过程要求。不管在什么时候，我听到这些需求就会让人把它记录下来，可以记在白板或索引卡片上，这样大家都可以看到。 这引出了一个很重要的观点：建模会议是交互式的。每个人都要参与。刚开始一个有经验的建模者要做一些工作，解释一些技术，“刺激”人们了解。这种“刺激”可能非常的容易，例如让他们来到白板前解释我们谈论的内容，把业务规则的内容填写进一个索引卡片，或在即时贴上记录一张可能的报表所需要的数据。当人们熟悉了这种建模活动的顺序，在对AM的“涉众积极参与”的实践都有了一致的了解之后，你就会发现你不用需要“刺激”他们了。是啊，任何人一开始都会害羞，需要某种形式的“刺激”，这是人性。 当你的团队在为当前的版本识别需求的时候，他们可能还会识别出未来的版本中的一些需求和一些未来的一些潜在需求。不要放过这些信息，尽管你现在既不希望花过多的时间来探求，也不希望你的软件为了去适应这些潜在需求而变得庞大。然而，这些信息对你的架构是有帮助的－潜在需求有利于在不同的架构中选择有益的架构。变更案例（Change cases，Bennett, 1997; Ambler, 2001a）是用来将潜在需求文档化的简单技术，你可以在图8中见到SWA Online的两个变更案例。你确定范围的一个重点是识别出哪些在范围之内，哪些在范围之外。并且把潜在需求识别为一个变更案例，你就显示的声明了他是属于项目范围之外的。变更案例在架构需求中的有效使用方面的讨论可以参看我的Agile Architecture essay. 变更: 扩张进入北美市场 可能性: 非常可能 预计时间: 12-18 个月 影响: · 运输需要支持加拿大和墨西哥的客户。需要新的托运人关系 · 需要计算相关的税和关税。 · 由于法律问题和当地习俗，在这些市场上的产品销售可能不一样 · 支持多种语言的站点（加拿大的官方语言是英语和法语，墨西哥的官方语言是西班牙语） 变更: 销售虚拟产品（在线音乐，视频，书籍…） 可能性: 非常可能 预计时间: 6-12 个月 影响: · 和物理运输过程不同 · 需要支持一些产品的数字授权 · 个别产品会有限制（有效期限、拷贝数量） 图8. SWA Online的两个变更案例. 那么你准备用多少的文档来记录你了解到的项目范围和项目的高阶需求呢？就像我在Agile Documentation中建议的那样，够用就行了。在SWA Online的案例中，我会建立一个HTML页面，包含了图6中的上下文图，图7中的用例图，以及一个哪些在范围之内，那些在范围之外的列表。对于高阶需求文档，我会把用例描述转录为文字处理器格式，或简单的text文件，因为我们在进行模型细化的时候会继续发展它们。把他们存放为电子文档的形式便于共享和操作。至于我们为了业务规则，限制，技术需求和变更案例创建的索引卡片，我希望它们能够保持这种形式，因为我们在细节建模工作中还会精化它们。如果我们确实需要，我们可以随时将之处理成为我们需要的格式。这样，你的团队就可以迅速的进入细节建模的阶段，然后进入实现。因为他们避免了创建其实并不需要的文档。（特别是有一些业务规则其实是错的，这样在你知道它们的真伪之前把它们写入文档的努力就都白费了。） Detailed Requirements Modeling 一旦IRUF阶段的成果－系统的范围和高阶需求－得到首肯，你就需要为你的需求排出各个迭代周期并安排开发任务。 Starting an Iteration 在迭代开始的时候，所有的需求都需要分配到每个开发人员头上。在一个XP的项目中，开发人员会根据自愿性原则，签署某个素材，并组对开发。这个过程不停的重复，直到本次迭代的所有素材都已经完成。而在一个UP项目中，团队的工作方法可能和XP中的差不多，或是由项目经理把需求指派给个人或子团队。先不考虑分派任务的具体情节，对于子团队/组对开发者而言，他们现在的任务就是需要实现需求。而他们要做的的第一件事情就是了解项目涉众需要的细节，其中有些也需要做需求建模。 这里有两种基本可以适用于如何在迭代开始时建立开发团队： 1. 本次迭代需求群组建模. 采用这种方法，整个团队，包括项目涉众，共同工作探寻需求细节，分析需求，建议需求当前系统以支持这些需求。考虑到你的迭代跨度约为2周，这种建模会议的长度保持在1个小时到半天的长度就可以了。如果你的迭代跨度较长，例如4到6周，你可能需要在一开始投入一整天的时间。不要想用超过一天的时间来做这项工作，那并没有很实际的意义。这种方法的优点就是在本次迭代中给团队竖立起了一个具体的愿景，他们打算如何完成自己的工作，收集了所有团队成员的意见。这样，在初期确定一个良好方法的几率就大大增加了。这种方法的缺点则是它只适用于较小的团队，特别是少于10人的团队，而且它对所有的个体来说实际上是浪费了时间，因为并不是所有人都会参与项目的各个方面。注意，一旦本次迭代的初始建模工作完成，各个子团队仍然需要在适当时间建立和他们有关的细节模型，当然，这也是属于本次迭代中的。 2. 子团队独立需求建模Individual subteams model their requirement(s). 有一些开发团队并不采用上述的群组建模，而是简单让各个子团队来负责实现。这种情况适用于每个需求之间没什么联系，或是联系不大。这时，开发人员遵循“集体所有制”（Collective Ownership）的实践，共同在一个共享代码库上工作。这种方法的优点就是是你的团队能够在迭代一开始就迅速的进入细节问题中。然而，他也有一些缺点。首先，需求可能交迭，也许两个子团队都在做和计算订单总量有关的事情（例如一个团队计算税率，一个团队计算折扣），这样你就可能冒重复工作的风险。这可能并不是一个很严重的问题，因为每个子团队都应该要能够了解其它子团队的工作而根据需要共同工作。其次，你的团队需要比较多的时间来固定实现愿景。再次，你一开始就要决定项目涉众的“所有权”，因为所有的子团队都需要项目涉众的“米”来下锅。 During An Iteration 一旦你结束了迭代一开始的工作，你的团队就开始一连串新的工作，建模、编码、测试、构建和部署。正是在这个阶段，你需要和你的项目涉众做大部分的需求建模的工作，探索这些需求的细节。实际上，这些工作的应该更精确的说是建模会议，在需求、分析、设计中都离开这种会议。这些会议通常是以一种“即兴”的方式举行的，参加的人数也不多，大多由负责这个需求的开发子团队和一个或更多的项目涉众组成。这种“即兴”的会议的开始也往往是由于一些不正式的话，例如，“小强，能不能花一些时间解释一下顾客是怎样搜索订单的？” 那我是怎样在SWA Online项目中做这些细节需求建模的？首先，假设我们两个人组对负责实现本次迭代中的“处理订单”用例，实现订单定义和处理的最基本的动作流程，这是全过程的一部分。目前我们不用实现查找功能、错误和异常处理、税率计算、折扣计算。这个最基本动作流程被我们称为“理想之路”，因为它只是实现了最基本的动作流程。备选流程描述了当动作执行时的非正常流程，例如在这个例子中，“客户要求的货物脱销”就是个备选流程。然而我们本次迭代的目的只是要实现最基本的“理想之路”，其它的需求由其它的子团队实现或是在以后的迭代中实现。 如图9所示，我们做的第一件事情就是要使动作流程逻辑丰满起来。同时我们还要建立和这个用例有关的UI原型（见图2）。我们并行的进行这两项工作，因为它们之间没有关系的，用例描述了用户如何下订单，而UI原型定义了SWA Online系统的用户界面必须包含的行为。注意，用例在第二行调用了“查找商品”用例，这和图7中的<<Include>> 版型的应用是一致的。尽管在我们正在实现的“处理订单”用例中调用了这项功能，但是它并不在我们的范围之内，所以我们不准备实现这项功能。为了不影响结果，我们可以直接使用一份查找的理论值清单。这项功能在项目的迟些时候会实现，但不是现在。（记住，我们是在增量开发。）另外，我们还要注意这个用例也没有涉及任何的技术问题，这些问题我们会在分析和设计阶段考虑。现在我们只是想要了解订货的基本流程，迟些我们才会考虑实现（可能只是几分钟后。）用例还描述另一些本次迭代的逻辑流程，例如税率和折扣的计算。 1. 当客户下定单的时候，用例就开始。 2. 客户查找商品，使用用例“查找商品” 3. 客户选中商品后增加订单项。 4. 客户填写定购物品的数量。 5. 系统自动计算每种商品的小计（单价×数量）。 6. 客户重复2到5步，直到完成订单。 7. 客户完成订单. 8. 客户提供他们的运送和付款信息，包括姓名、电话和地址. 9. 系统加总每列商品小计，得到订单总价。 10. 系统根据计算订单税率的商业规则计算订单的应付税款。 11. 系统根据计算折扣的商业规则计算订单的折扣。 12. 系统显示税款和折扣 13. 系统加上税款，减去折扣，得到订单的总价。 14. 系统显示订单概要 15. 客户检查订单。 16. 系统安排执行订单。（见用例“执行订单”。 ）17. 系统为客户生成一张本次订货的收据。 尽管我们系统UI会在浏览器中实现，我们还是选择了用即时贴和活动挂图来做这项工作，而不是HTML编辑器。因为纸会比较有弹性，而弹性正是我们现在所需要的。当需求刚刚开始的时候，我们需要很随意的添加、移动、移除UI元素，所以我们需要能够支持这种工作特性的工具。稍后，一旦纸上的需求稳定下来，我们就会将之转移到HTML编辑器中，这时候我们就可以做出更具体的UI以供项目涉众评价。这时候，简单就好。 在这个工作中，我们要遵守几条AM的实践。包括“并行创建多个模型”：因为我们同时要进行用例和UI原型的工作；“和他人一起建模”：因为每个团队都有两名开发人员和至少一名的提供需求的项目涉众；“简单描述模型”：我们在图2中就描述了一个“下定单”的简单模型；图9则是描述“建立简单的内容”实践的最好例子：因为它仅提供了描述用例业务逻辑的最少细节。我们还要遵循“应用合适的工件”－业务规则不要用用例来表示，而是应该用单独的业务规则工件来描述。你可能会争辩说“计算订单总价”的逻辑流程就是一个业务规则，但是你可以为诸如“就算订单税款”和“计算订单折扣”建立文档或是索引卡片。阿而且，用户界面的需求也需要用特定的工件－UI原型－记录。另外，如果我们还要进行数据需求建模，那概念模型（下文会详细讨论）也是必须的。我们还遵循了实践“重新修订工件”，在用例和UI原型间来回改动－当我们在UI原型中增加功能的时候，我们意识到用例也要做相应的逻辑调整。最后，我们应用了实践“使用最简单的工具”－用纸张来建立UI原型，用白板来创建用例逻辑。 假设我们已经对我们的建模工作很满意了（这可能只是花了30到60分钟的时间），我们会继续建立分析模型、设计模型，一直到最后的实现。或者我们还会再花一些时间来修正项目团队刚刚达成共识的概念模型。我比较倾向于让概念模型尽可能的简单，可以使用CRC卡片，就如同你在图3中看到的，因为CRC卡片容易制作，也很容易为涉众所接受。他们不仅可以表示你的问题域中的主要实体，还能够表示实体之间的关系，包括数据和行为。你还有另一个建立概念模型的次优选择，使用UML的类图，使用类图的好处是能够捕捉到类/实体之间关系的细节，例如多重性和角色－CRC卡片中实现类之间关系是通过合作来隐式实现的。问题在于类图并不容易象CRC卡片那样为涉众所接受，同时也因为它的复杂性，使得涉众的参与程度降低。传统的数据模型也可以用于概念建模，但是它通常用在结构性技术的环境之中，和UML类图一样，对于涉众，它也不好理解。 虽然我描述的建模工作在短短一个小时之内就可以完成，但你也可以将你的建模工作分成多个小片断：先集中于用例的头几行和相关的UI，实现部分的功能，然后在回过头来解决用例的剩下的部分。这种方法同样蛮好用，如果你觉得可行，也可以采用这种方法。 还有一件事情很重要，你必须了解在一次的迭代中需要不断的交流，并随时根据需要回到需求建模的工作中。当你开始实现“处理订单”的功能时，你要指导你其实对这项功能的具体细节并不是非常了解。例如你具体订货物品的数量限制。如果这属于新的用例，你就需要重新对这项功能估计、排序、安排到未来的某个迭代中执行。也许你的逻辑和订单没什么关系－比如客户需要先行提供他们的帐户和运输信息。这就意味着在未来的迭代中需要处理新的需求。 |