详细需求建模阶段
一旦系统的范围和高层需求得到认同，基于该阶段的成果，你就可以开始为你的开发工作制定进度，将这些需求带进一个迭代过程（iteration）。该计划随着你对需求的理解的不断发展而演化，由此你就开始了真正的开发。
迭代过程的开始
在这个过程的开始阶段，这些需求会分发到各个开发者手中。在一个实施XP开发流程的项目组中，开发人员会结成对子，自愿地对给定的用户故事进行处理。每个用户故事都以相同流程得以处理，这个过程不断反复直到处理完所有的用户故事。实施UP的项目组或者以类似的方式运行，或者由项目经理将需求分配给某个开发者或一个小组。无论以何种方式，开发小组/对子都处于实现这些需求的状态。第一步就是要详细了解你的项目甲方想要得到是什么东西，这可能需要进行一些需求建模分析。
在这个迭代过程的开始阶段有两种方式进行建模工作：
集中所有需求在一起进行建模。采用这种方法，整个项目组以及能到的项目甲方会在一起探讨详细的需求，分析这些需求，对已有的系统设计提出修改建议以支持这些需求。假设这整个迭代过程是两个星期，我希望这个会议的持续时间一个小时到半天。如果这个过程更长，假设四到六周，你可能需要花一整天的时间在这上面。这个时间不希望超过一天，因为你不会收到具体的反馈，具体的反馈只有当你用代码验证它时才会得到的。这个方法的优点是可以对所要进行的工作和打算如何去做有一个具体视图，而且可以得到所有项目成员的想法，因此增大了确立一个良好开端的机会。它的缺点就是只适用小项目组，一般少于十个人。而且也比较浪费时间，因为不是与会的每个人以后都要参与各个方面的工作。注意一旦完成了这个初期阶段的工作，每个开发小组仍然需要对它们所负责的部分进行详细的建模。
各个开发小组对它们所负责的需求直接进行建模。有些开发组会在迭代过程的开始阶段放弃以上做法，而简单地就直接让各小组进入到其所负责的部分。这种方式的成功需要有这样的前提：需求间没有联系，或至少联系不是太多；开发人员遵循集体所有制这个做法；基于共有的代码之上。它的优点就是能够使得项目组在迭代过程开始的第一天就进入详细分析建模。但它有几个缺点：第一，当需求映射到设计上有交叉时，可能有两个小组都在处理有关定单计算的问题（比如一个小组负责计算税款，而另一个小组负责折扣的计算），这就会有两个小组工作重叠的风险。但这不算一个严重的问题，因为每个小组都应该知道其它小组正在做什么，当需要时可共同工作。第二，这会经过较长的时间后项目的整个实现视图才会明了。第三，在开始会引起对项目甲方的争夺，因为每个小组工作的开展都需要从他们那里得到输入。
迭代过程中
一旦结束了开始阶段的工作后，项目组很快就进入到持续的迭代过程中，建模、编码、测试、编译，或者进行软件配置。你和项目甲方的大部分需求建模的工作会在这段时期中体现，这个过程的目的就是探究、细化这些需求。实际上，更准确地说这些工作就是一些建模会议，因为你可能会不断地重复着需求、分析和设计。这些会议一般是由一小组人即席召开的，一般包括开发小组成员和由一个或几个项目甲方提供输入。这类会议一般讨论某一类别的问题，如“莎利，你能花几分钟时间讲一下客户是如何搜索一个定单的吗?”。
那么我在SWA Online这个项目中是如何进行详细需求建模的呢？首先，假设我们有两个人结成对子。在这个迭代过程中，我们要实现定单的定义和使用案例中“下定单”（Place Order）这个行为的基本路线（basic course of action）中的定购部分。在这里，我们不去实现查找功能，任何类型错误和异常的处理，税金计算和折扣计算[1]。一个行为的基本路线常称为“愉快路径”（happy path），因为沿着这个基本路线所有操作都是正常的、愉快的。行为的备用路线（alternate course of action）是描述当有不正常的操作时所走的路线，这里比如一个用户向一个缺少存货的产品下定单的情况。我们现在仅关心“愉快路径”，其它的需求会由其它的小组或者我们在以后处理。
我们要做的第一件事是充实这条基本路线的逻辑过程，如图9所示。同时也进行关于这个使用案例的基本用户界面原型的工作，如前面的图2所示。之所以我们要并行地进行这两部分工作，是因为它们从两个不同方面来解决这个问题。使用案例描述的是用户在下一个定单时要做什么，基本用户界面原型则是构造一个支持该行为的用户界面。请注意使用案例“Place Order”利用构造型(stereotype)<<Include>>调用了另一个使用案例“Search for Item(s)”，见图7。虽然这个功能是该使用案例中的一部分，但我们并不在这里实现它，因为它超出了范围。我们会采用另一种方式来替代，有可能就是直接给出一个假设的查询结果的页面。这个查询功能会在稍后恰当的时候实现（记住，我们使用的是增量的方式）。同样现在也没有考虑任何类型的技术问题，我们会在以后的分析中或设计中决定这些问题。现在我们只是想了解这个下定单的基本过程，稍后（可能就几分钟后）我们才关心实施的细节。对那些我们不会在这个迭代过程中实现的逻辑步骤，比如税款和折扣计算，当我们在编码时会留下接口。
这个使用案例从一个用户选择下一个定单开始。
用户通过另一个使用案例“Search for Item(s)?”来搜索物品。
用户选择一个物品并加入到他/她的定单中。
用户指定他们想购买该物品的数量。
系统通过该物品的单价和购买数量计算出总价。
用户重复第2步到第5步继续订购其它物品。
用户结束向他们的定单加入物品。
用户提供送货信息和付款信息，包括他们的名字、电话号码和邮寄地址。
系统计算定单中所有物品的总价。
系统按照“Calculate Taxes for an Order”这条规则计算适用于该定单的税款。
系统按照“Calculate Discount for an Order”这条规则计算适用于该定单的折扣。
系统显示税款和折扣。
系统加上税款和减去折扣，得出最后的总价。
系统显示该定单的汇总表。
用户验证该定单是否正确。
系统为该定单下计划（参见使用案例“Fulfill Order”）
系统给出一张该定单汇总收据。
虽然我们知道该系统使用浏览器进行操作，但我们不会现在就用一个HTML的编辑器进行用户界面的设计，而是仍旧使用粘贴纸。因为在用户界面设计的初期，我们会经常地很频繁地增减控件、改变布局，我们希望用一种工具来支持，而粘贴纸所具有的灵活性和弹性正是我们所需要的。当这个页面的布局稳定下来后，我们会转到HTML编辑器上，因为我们此时想生成一个更加具体的界面可以让甲方进行评估。眼下，我们就简易行事。
在这个阶段，我们遵循了灵巧建模的几个做法。明显的有并行建立多个模型（Create Several Models in Parallel）这一条，因为我们同时进行了使用案例和基本用户界面的工作；有同他人一起建模（Models With Others）这一条，因为包括了两个我们的开发人员和至少一个负责提供需求的甲方；有简单地建模（Depict Models Simply）这一条，通过图2中的这个简单模型我们可以看到这点；有创建简单内容（Create Simple Content）这一条，图9所示就是一个很好的例子，它刚刚好足够详细地描述了使用案例的业务逻辑；有使用恰当Artifact(s)（Apply The Right Artifact(s)）这一条，业务规则不在使用案例中体现而在另外单独的业务规则artifact中，虽然你可能会提出异议“计算定单的总价就是一条简单的业务规则”（此时，对于计算定单的税款和计算定单的折扣这两个业务规则，你可能会在文档或所引卡片这类用于业务规则的artifact中预留下位置）。此外，用户界面的需求使用的也是另外一个artifact，即基本用户界面原型。如果我们还有数据方面的需求的话，它将会使用概念模型；有切换到另外的Artifact( Iterate To Another Artifact)这一条，当我们在用户界面原型上增加了一项时，会发现在使用案例中缺少相应的逻辑，反之亦然，这时我们就会在使用案例和基本用户界面原型间来回修改；最后，也用到了使用最简单工具（Use The Simplest Tool）这一条，用户界面原型用的是纸张，使用案例逻辑写在白板上。
一般我们花费在上面建模的时间是三十至六十分钟。假设我们对建模的结果感到满意，要么就会继续进行分析和设计工作直至编码，要么会先花上几分钟时间用刚才所学到的去更新一下项目组的概念模型。我建议使用尽可能简单的概念模型，就像图3所示的CRC卡片，因为它们易于使用而且非常容易被项目甲方理解。它们不仅用来表示系统中主要的实体，而且可以表示出这些实体的职责（包括数据和行为）。对于概念建模，你下一个最好的选择就是采用UML的类图（class diagram）。它的优点在于能够表示出类或实体间的关系，例如多重性（multiplicity）和角色（roles）。CRC模型中的类合作者就隐含地表示了类之间的关系。问题是对于你的项目甲方来讲，类图不如CRC卡片那么容易理解，即便他们努力地积极参与，但类图还是过于复杂了。传统上数据模型用于概念建模，经实践验证即使当使用结构化的技术进行实现时也是可行的，但UML的类图却难以做到。
尽管我在这里所讲述的建模工作很有可能花不了一个小时，但你可以很容易地组织你的建模工作，更好地进行划分。或许首先集中解决前几层的使用案例及其相应的用户界面，实现这部分的功能，然后再回过头来解决下几层的使用案例。这种方法在两层的时候工作得很好，你应该采用最适合你自己的方法。
认识到在这个迭代过程中需要不断地反复是很重要的，当需要时就要回到需求建模的工作上。当你开始实现下定单这个功能时，有可能会发现你对其工作的细节并不清楚，比如对某类物品可能有购买数量的限制。如果发生这样的情况，你就会有新的功能需要进行评估、要指定优先级和将其带入以后的迭代过程中。有可能你的逻辑顺序颠倒了 – 客户可能应该首先提供送货和支付信息；还有可能应该提供一种能让客户一次性地建立他们送货和支付信息的途径。总而言之，新的需求必须要在新一轮的迭代过程中加以处理。
解决需求建模中的常见难题
为了能以灵巧的方式进行需求建模，需要具备一定的条件。但不幸的是，很多项目组并不具备。需求建模工作常常被你所处的环境所影响和破坏，一般是组织所奉行的文化不利于有效的软件开发或者项目甲方不清楚他们的决定所带来的影响。在这一节中，我列出了一些在需求建模中多数项目组经常碰到的问题，并讨论了可能的解决方案。这些常见的难题如下：
难于接近项目甲方 （Limited access to project stakeholders）
项目甲方分散在各处 （Geographically dispersed project stakeholders）
项目甲方不知道他们想要得到的是什么（Project stakeholders do not know what they want）
项目甲方改变主意（Project stakeholders change their minds）
优先级冲突（Conflicting priorities）
过多的项目甲方想参与进来（Too many project stakeholders want to participate）
项目甲方指定了技术方案（Project stakeholders prescribe technology solutions）
项目甲方墨守成规（Project stakeholders are unable to see beyond the current situation）
项目甲方含糊其词（Project stakeholders are afraid to be pinned down）
项目甲方不懂建模artifacts（Project stakeholders don’t understand modeling artifacts）
开发人员不懂业务（Developers don’t understand the problem domain）
项目甲方过于集中于某一类需求（Project stakeholders are overly focused on one type of requirement）
项目甲方对于需求的确定有许多繁文缛节（Project stakeholders require significant formality regarding requirements）
开发人员不懂需求（Developers don’t understand the requirement）
难题 #1 难于接近项目甲方
这是一个经常发生的问题。由于某些原因，高层管理部门有时愿意投资数百万美金进行一项系统的开发，但却不愿意或不能指派一些合适的人选来告诉你这个系统需要干什么。“为了项目的成功，开发人员需要得到项目甲方的积极支持”，项目甲方常常严重缺乏对这一点的认识，他们不清楚软件是如何开发的；或者他们一直以来都是以这种方式工作（译者：即不委派人员协助开发），而不知道有更好的方法。
要解决这个问题，首先你需要与项目甲方进行沟通，告诉他们你需要同他们紧密地协作，他们必须投入宝贵的时间与你一起工作。有时可能没有可以确认的用户，这种情况通常是当你在开发一个零售产品或一个供你（潜在）客户使用的基于web的新系统时出现，在这种情况下你需要找一些人来代替。一个较好的方法是选择你的市场人员或销售人员，因为他们熟悉客户，他们脑中对你的系统会有一个大致的轮廓。或者直接找一些可能的用户（你可以自己从用户的角度去想这个系统应该提供什么；或者从外面聘请一些人，他们应该是你的产品所面向的用户）。根据我的经验你肯定可以找到能为你的系统提供需求的人，曾经有好几次我都被告之不可能提供人员与我一起工作（但最终都找到了[译注]）。记住你的项目甲方不仅仅是系统的直接使用者，你应该认识到你是在冒风险如果没有任何直接使用者参与到你的软件开发中。
难题 #2 项目甲方分散在各处
对于上一个问题，还有一个原因就是你的项目甲方与你的开发组不在同一个地点，使得你没办法与他们很好协作。这种情况常发生在比较大的组织内，一些项目外包给其他组织；或者在一个由多个组织合作开发的项目也会出现这个问题。解决的办法有几种。一是，想办法将开发小组和项目甲方集中到一个地方。正如我在《交流》一文中所提到的，面对面的交流是最直接有效的方式。如果做不到这一点，下一个最好的做法就是让项目甲方和开发人员在一段时间内在一起，另外的时间通过其它手段进行交流（在《交流》一文中，我提出了几种可选择的方式，如电子邮件，视频会议，和一些支持协作建模的工具）。我曾经参加一个由300人组成的项目组，项目甲方在每三个星期中用一个星期同我们的开发人员一起工作，而其它两个星期通过电子邮件和电话联系，这种方式运行得相当好。如果上两种方法都不适用，那下一种较好的方法就是让开发人员到项目甲方所在的地，与之共同工作。我在好几个项目中成功地使用了这种方法。但要注意这对那些出差的人来说非常艰苦的（我就经常出差，幸运的是我喜欢旅行）。还有一种方式就是让业务分析师先到项目甲方那里去了解他们的需求，然后再让他们回来与开发人员定义需求。当然，你可以根据你的情况组合使用这几种方法。
难题 #3 项目甲方不知道他们想要得到的是什么
这就是你什么要花时间进行建模的原因。通过建模来探寻他们想得到什么以及哪些对他们而言是重要的。现今的商业非常复杂，甲方经常意识到有问题需要解决或存在着改进的机会，但他们不知道如何去做。这是十分正常的。你曾经重新装修过房间，或者重新布置过家具吗？你知道你想有一个更好的居住环境，但却常常措手无策。可能你会去查阅一下杂志上的图片，参观一个家具店，或者去朋友家看看他们是如何摆设的。如果你对构想一个居室的布置感到困难，可想而知，你的项目甲方要确定一个什么样系统是多么的不容易。
这是一个正常的现象，我们从接受这个观点开始。如果你的用户不能确切地告诉你他们想得到的是一个什么样的东西，告诉他们这没有关系。他们现在所需要做的仅是告诉你他们想让你干什么。同重新装修房间类似，可能你现在还没有一个整体的布局构想，但你可以从着重于安装一个书架开始。着眼于他们对系统中有最清楚想法的一个方面，对这个小部分建模，然后实现一个可运作的系统（遵循用代码进行验证这一做法）。他们就可以实地操作，向你提供反馈。如果他们甚至连一小点的需求都提不出来，就好像你完全不确定是否会有书在房间中，那么就从调查他们现在的工作方式开始。通过对现有工作流程的建模，你会进一步了解他们的工作，从中看到他们可能需要的改进以及最差的环节在哪，由此就可以向他们建议。
难题 #4 项目甲方改变主意
项目甲方也是人，是人就会改变主意。你把家具按想象中的位置摆好，但当你回过头来端详一番，可能觉得这样并没有达到想象中的效果。象布置家具这样简单的事你都会改变主意，何况那复杂的系统呢。项目甲方百分之百会改变主意。
要解决这个问题，你首先得接受这个事实，拥抱变化。不管发生了什么变化，都是与建模有关的，因为你会发现要么是他们开始时不清楚他们自己的需求（参见上一个讨论），要么就是你没有弄明白他们所想要的。当你同项目甲方一同讨论时，你应该从他们的角度以他们的语言达成一致的认识，这会确保你没有作出另外的假设，而且会提高谈话的质量。我曾经参加过为一个电子商务系统开发管理系统的项目，在这个项目中我们得出了一个公正而准确的需求。第一个星期，我们提供了两个网页：一个是主页，上面包含了关键功能的菜单项；另一个实现了一个高优先级的功能。我们完全按照他们所要求的来做。当我们想他们演示以后，他们意识到最初的想法不好，然后要求我们重新构造。变化来了。最后，当用户对系统中某一部分的想法发生改变时，你会发现实际上是由于他们没有弄清楚需要解决的问题，这意味着需要同他们开一个关于构想的会议（参见需求建模会议的相关内容）；或者是由于某个有不同构想的甲方的意见没有被正确处理。
难题 #5 优先级冲突
你所建造的系统必须反映多方面的需要，包括直接使用者，高级管理层，你的实施人员，支持人员，以及维护人员。各方面都有不同的优先级要求和目标，即使是同一类中的不同个体也是如此。这就会出现冲突，有冲突就必须进行处理。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
