软件项目所面临的最大挑战之一，便是决定由确定需求转为系统设计的过程应该在什么时候开始，且该如何进行。类似以下的问题将不断地冒出来：我什么时候才可以完成使用个案？我需要先将所有的使用个案详细阐明后，再跳到系统设计吗？在设计时，我应该先处理哪些需求？
大多数的人似乎都能理解做对了决定所带来的好处，和做错了决定而带来的麻烦一样地多。起步得太早，项目将面临草率制定需求便进行系统设计的风险；起步得太晚，您所要负担的风险更大，因为项目的生命周期势必将因高风险的架构决策而延宕。此外，在准备由需求转向设计的工作产出时，您还得留心别失去了原始的精神（例如谁负责做决定？在某些需求里有没有特定的关系存在？）
这篇文章将告诉您如何由需求制定顺利地转变至系统设计的阶段，重点会放在一些尤其容易出状况的项目上。首先，我们先来看看项目小组在开始设计之前，应如何利用使用个案。接下来，再检测所谓在架构上定义明确的需求。最后，我将解释如何运用使用个案体现（use-case realizations）作为重要的工作产出，并成为由需求制定转为系统设计的桥梁。
揭露风险是美事一桩
根据过去的经验看来，我们都知道传统的瀑布法（waterfall approach）软件开发方式，并没有办法减低在项目生命周期早期的巨大风险。这是由于一些高风险性的决策，如项目的架构方向等，在开始撰写程序代码之前都没有被好好测试过。它可能导致严重的后果；许多瀑布式项目因此而在相当的投资及关注之后，才又被削减或整个取消掉。
Rational Unified Process (RUP) 因为具有以下两种关键特性，而和上述的方式形成对比：一， RUP具备风险基础（risk-based）；二，RUP具备架构精神。RUP会促使项目团队在早期便确立需求，除了面对可能发生的巨大风险之外，也让他们及早做好计划以便降低这些风险。这些所谓的架构明确（architecturally significant）的需求，基本上在RUP的初始阶段（Inception phase）是显而易见的，它们也将成为规划阶段（Elaboration phase）的第一个开发周期（iteration）中做进一步分析与设计的标的。
面对风险对项目开发来说，其实是美事一桩，因为它会要求项目团队尽快地发展出解决之道。在不断向前迈进的过程中所面临的挑战，是必须设法回答这些重要的问题：项目团队在开始着手进行设计之前，应该如何利用使用个案呢？
在于广而不在深（A Mile Wide and Five Inches Deep）
项目在架构上能明确定义使用个案（见附文）之前，它必须设法充实需求内容，以便针对风险所在做出明智的决策。至于该充实到什么样的程度呢？把握住“在于广而不在深”的关键就对了。
在项目的初始阶段，我对项目团队的标准作业程序是让他们达成以下任务：
1. 经过讨论后，确认项目关系人以及主要的系统产品特性（RUP的愿景产出，Vision artifact）。
2. 经由脑力激荡过程，列出事件清单，先确认行为者（人员、其它系统、硬件装置、以及定时器）有哪些，以及它们将与系统互动出哪些事件。
3. 再次脑力激荡，看看哪些使用个案可以满足这些事件。
4. 针对每一个使用个案，完成一使用个案样版，至少确认出关键路线（key pathways）。这些关键路线可以区分为几种类别：最常见的或是快乐路径（happy path）、快乐路径的其它选择，以及例外路线（exception paths）等等。
5. 时间允许的情况下，把每个使用个案的快乐路径步骤详细列出，或至少列出该项目的中枢使用个案的快乐路径。
6. 确认代表最大风险所在的需求是哪些。
这些任务可以在一个开发周期里完成，如果需要的话，在较大的项目里，还可以在相关的使用个案里循环运用。
就这样的项目观点来看，项目团队其实对整个项目的广度都有所涉猎，但却涉入不深。以该角度说来，我们不能断言所有的功能需求都已被了解。然而，对于那些可能面临最大的架构风险的需求，我们确实有了足够的认知。
行为者和使用个案在做些什么？
多年来专家们始终在努力要构筑出最好的方式来引发，记录，并追踪功能性需求。这些方式从迷你规格书（mini-specifications）－一种以段落的型式将需求诉诸文字－到利用图形展现每个需求的控制流程，包罗万象。
Rational的Ivar Jacobson在Ericsson从事复杂的电子通讯项目时，就成了应用使用个案概念的先躯。这种使用个案的方式首先着重在确立应用软件的行为者（Actors）或使用者为何。行为者基本上以四种型式存在：人员，其它系统，硬件装置，或定时器。系统必须能够满足他们的需求，这个目标乃藉由使用个案来完成。
使用个案代表着主要的功能类别，由应用系统的使用者所定义出来；最终提供可计量化的数据给行为者的，就是使用个案。使用个案图（use-case diagrams）是由每个使用个案的使用个案样版所完成的。图１表示了使用个案和行为者之间的关系。
＜图１＞下订单的使用个案图
如果想知道更多的行为者与使用个案相关信息，请参考以下资源：
参考网站：
http://www.rational.com/uml/index.jsp
http://www.Usecases.org/
http://www.therationaledge.com/admin/archives.jsp (search for Use Cases)
参考书籍:
Alistair Cockburn所著, Writing Effective Use Cases。 由Addison-Wesley出版社于 2002。9年出版。
架构明确的需求
与项目团队一起工作时，我通常把重点放在一些架构明确的涵盖领域（coverage areas，也就是具有高风险的部份，见表１）。表１ 架构明确的涵盖领域
| 涵盖领域 | 风险因子 |
| 1. 组织内还没有在其它专案中应用国的新技术或工作 | 确认组织对于使用新技术是不是还不太在行。 |
| 2.客户因为新技术而产生的全新或修订国的企业流程。 | 面临的风险在于，客户在新技术上的工作流程可能未经过测试。举例来说。如果银行分行把它的帐户资料输入与获取的流程转换到较轻薄的Client端，以Web_Base应用系统处理，那么该应用系统可能不会象以前那种集中的方式那样，在工作流程及使用者界面上皆较具有弹性。 |
| 3.有时效性的流程（Time based processing） | 在帮助有时效性的时间流程上，想找到又耐用、又现成不修改的产品，可以说是少之又少。许多应用软件若不是需要量身定做，要不就是得籍由先前采购的元件加上程式码加以修正。 |
| 4.批次作业流程（Batch processing） | 别以为新一代的技术兴起后，批次导向的作业就不见了。这知识个常见的误会，批次流程可以是架构中一个很精巧的部分。如何在批次与即时作业之间取得平衡是企业逻辑里很微妙的一环。 |
| 5.多重面版式互动（Multi-panel interactions） | 需要整个流程的正式管理法则（工作流程管理）这主要是针对Web_Base的解决方案来的，因为Web的本质就在于它的“非正式性”。软件产商对多页式互动产品的正式管理方式，视其复杂程度与影响曾层面而有所不同。 |
| 6. 安全性、追踪、与记录需求（Security, logging, and archiving demands） | 大多数的客户都渴望他们先前所采购的解决方案，可以具有单一登入(single sign-on, SSO)的功能，并且整合安全性与获取方面的能力。要将之整合进全面性的解决方案之中着实得花不少的工夫。 |
| 7. 正确对应管理（Persistence management） | 如果解决方案是以物件导向技术为基础，那么就必须特别注意在物件对应到关联式存放（relational stores）时不可发生错配的情形。 |
| 8.品质控管（Quality of service） | 效能永远是我们考虑的重点。虽然在规划阶段初期也许不适合进行量化测试（volume testing），但模拟工具仍然可以提供我们一些估测未来产出的有意义的数据。 |
涵盖领域 风险因子 1. 组织内还没有在其它专案中应用国的新技术或工作 确认组织对于使用新技术是不是还不太在行。 2.客户因为新技术而产生的全新或修订国的企业流程。 面临的风险在于，客户在新技术上的工作流程可能未经过测试。举例来说。如果银行分行把它的帐户资料输入与获取的流程转换到较轻薄的Client端，以Web_Base应用系统处理，那么该应用系统可能不会象以前那种集中的方式那样，在工作流程及使用者界面上皆较具有弹性。 3.有时效性的流程（Time based processing） 在帮助有时效性的时间流程上，想找到又耐用、又现成不修改的产品，可以说是少之又少。许多应用软件若不是需要量身定做，要不就是得籍由先前采购的元件加上程式码加以修正。 4.批次作业流程（Batch processing） 别以为新一代的技术兴起后，批次导向的作业就不见了。这知识个常见的误会，批次流程可以是架构中一个很精巧的部分。如何在批次与即时作业之间取得平衡是企业逻辑里很微妙的一环。 5.多重面版式互动（Multi-panel interactions） 需要整个流程的正式管理法则（工作流程管理）这主要是针对Web_Base的解决方案来的，因为Web的本质就在于它的“非正式性”。软件产商对多页式互动产品的正式管理方式，视其复杂程度与影响曾层面而有所不同。 6. 安全性、追踪、与记录需求（Security, logging, and archiving demands） 大多数的客户都渴望他们先前所采购的解决方案，可以具有单一登入(single sign-on, SSO)的功能，并且整合安全性与获取方面的能力。要将之整合进全面性的解决方案之中着实得花不少的工夫。 7. 正确对应管理（Persistence management） 如果解决方案是以物件导向技术为基础，那么就必须特别注意在物件对应到关联式存放（relational stores）时不可发生错配的情形。 8.品质控管（Quality of service） 效能永远是我们考虑的重点。虽然在规划阶段初期也许不适合进行量化测试（volume test ing），但模拟工具仍然可以提供我们一些估测未来产出的有意义的数据。
在评估使用个案的能力时，请记得它至少要能够涵括表１所列出的一种或一种以上的涵盖领域。在项目初期最容易发生的第一个错误步骤，便是确认了一些很容易被建置起来的需求，但它们对减轻架构上的风险却没有什么帮助。
对整个使用个案而言，使用个案的路线（use-case pathways）应该是搜寻架构明确的需求的重心。它们应该由所有的使用个案中描绘出来。在规划阶段的第一个开发周期当中，我试着避免过多的CRUD路线（Creat／Read／Update／Delete，新增／读取／修改／删除）。虽然它们对涵盖领域可能有所助益，但是却容易导致其它更多重要的部份被忽略掉。
最重要的一个开发周期
无庸置疑地，在规划阶段的第一个开发周期，的确是整个项目进行中最重要的一环（参见图１及RUP附文）。在这个开发周期里的输入项，称之为架构原型（Architectural Prototype），便是在初始阶段（Inception phase）结束时所选择出来的架构明确的需求。
项目团队将架构明确的使用个案路线向下延展，也是在规划阶段的第一个开发周期里完成。所有的企业规则与附属品，都在此时完整地填充进来。这时加进项目里来的，不只是更多的功能知识而已，还有进一步的为了健全架构的测试。当规划阶段完成后，就绝对不要再做任何困难的架构决策了。其余的使用个案路线，则应该继续在规划（Elaboration）、建置（Construction）、甚至转变（Transition）等阶段的后续开发周期里做更详细的陈述。
The Rational Unified Process (RUP)
如图２所示，RUP包含了四个阶段和九个工作流程。所谓的开发周期（iteration），指的是在九个工作流程中，垂直地将项目区分开来的部份，它是由每个工作流程里的活动（activities）所描绘出来的。每个开发周期通常都包含了由九个工作流程而来的要件（elements）。其所导致之任务集合，便构成了我们所知的周期计划（iteration plan）。一个阶段里可能有多个开发周期，至于其数量的多寡，通常便成为一个项目的技术复杂度与规模大小的直接因素。在RUP产品里则对这四个阶段都各提供了一个周期计划的样本。
在每个阶段结束时，都会有一个里程碑的标示。RUP四阶段的里程碑分别是：Lifecycle Objective（生命周期目标）, Lifecycle Architecture（生命周期架构）, Initial Operational Capability（初始操作能力）, 与Product Release（产品交付）。
RUP的开发周期模型和传统瀑布式的模型不同，它认可在范围宽广的工作流程（例如需求制定与系统设计等）当中所订定的活动，是可以实际上在项目的生命周期当中同时发生的。
如果想知道更多关于RUP的信息，请参考下列信息来源：
参考网站：
http://www。rational。com/products/rup/index。jsp
http://www。therationaledge。com/admin/archives。jsp (搜寻RUP)
参考书籍：
Philippe Kruchten着，The Rational Unified Process: An Introduction,第二版，由Addison-Wesley出版社于2002年所出版。
Use-Case Realizations：需求制定与系统设计之间的桥梁
由需求制定顺利转变到系统设计的关键核心，在于一个能将这两个工作流程直接绑在一起的工作产出（artifact）。项目团队运用使用个案体现（use-case realization）作为他们的转变产出（transitional artifact）。这个系统设计的活动，是在规划阶段的第一个开发周期里发生的。
所谓的使用个案体现，指的是使用个案的设计观点（Design View）。一开始的时候，使用个案只定义了使用者要的是“什么”。而使用个案体现则是明确指出使用个案要“如何”建置起来的转变组件。然而，使用个案体现事实上是个复合式的工作产出，它还包括了其它的设计模型以表示实际上的体现（realization）。一般在体现里最常使用的模型是UML循序图（sequence diagram）及／或合作图（collaboration diagram）。
项目可以利用Rational Rose (见图３)，以图型化的方式来表示使用个案体现。在Use-Case View里的使用个案与Logical View里建立的使用个案之间，会建立起一典型的依赖关系（dependency）。
＜图３＞在Rational Rose里的Use-Case Realization
这样的关系在实际的使用个案中，并不只是好看而已。还记得在Use-Case View里的使用个案包含了数条路线吗？这些路线是由无数条企业规则结合出一连串的步骤，形成路线的架构，完全根据使用者定义出来。我们现在就是依循这些步骤，在Design里塑模对象讯息之间的集合，以达成行为者的目标。这种讯息传递的过程可以用以下两种图之一来塑模：循序图（Sequence）或合作图（Collaboration）。（注：我发现在实务上进行项目时，比较倾向单一使用循序图或合作图两者之一，而不常混用两者。）
＜图４＞在Use-Case Realizations里的循序图（树状展示）
在图４里的树状观点，展现了在每个使用个案体现里的循序图如何进行扩展。在使用个案中，每一条关键路线里都会建立一份互动图。一开始在规划阶段的第一个开发周期中，这代表着只有这些路线是被选择来充实高风险项目的内容的。
Use-Case Realization：当一个不够用时
在我最近参与的一项项目计划中，出现了在Use-Case View里的每个使用个案需要不只一个使用个案体现的情形。通常这意指该使用个案所需要的是一个多重技术的解决方案。举个例子来说，在下订单的这个使用个案里，你可能会有一个额外的非功能上的需求，希望下订的方式除了在web在线下订之外，也可以经由PDA的无线接口或类似的方式处理。在这种情形下，最好便能有两个使用个案体现，一个处理Web的交易，另一个则处理无线方式的交易（参见图５）。
＜图５＞同一个使用个案的两个体现
技术上而言，需要两个体现的原因，在于它们的解决方案差异很大。在Web这一案上，假设我们使用的是Java，一定会有Servlet classes，和一些其它的support classes，是绝对不会拿来用在无线方式里的。然而，在这两种不同的技术方案中，我们却可以省下一些共通讯息重复传递的工夫。这么说好了，当一切就绪时，由entity classes（例如订单，客户）实际到系统里取得订单的这段企业流程，在这两种方案里其实是完全相同的。
因此在这个例子里，由网络下订单的体现互动图，与无线方式下订单的体现互动图，两者都会指向同一个处理entity classes讯息传递的互动图。
这就是由需求制定转向系统设计的过程当中的使用个案体现。在我举办的座谈上，曾经有个参与者问道，像这样让体现直接指向需求架构，会不会有些危险呢？我的回答是，其实它再自然也不过了。就如同对象导向的观念让我们了解，现实世界中的实体代表着架构与行为两种概念一般，使用个案体现也同样可以代表从自然世界到使用个案中的Design View之间的转变。
物以类聚
在过去的生命周期解决方案里，对于需求搜集到系统设计的活动转变过程，总是充满了一股不可解的神秘气氛。需求制定的过程通常都诉诸文字型式，以段落方式来描述，而可视化的设计文件对这些需求却完全无法进行追踪。这种记录静态需求再将之转成设计产出的过程，在内容上常有所漏失，也常常混淆了使用者原先对系统的期望。
相反地，类似RUP的开发过程，可让您在任何软件开发项目中，了解风险所在而对症制定需求。使用个案体现为那些在初始阶段粗略捕捉到的需求，提供了类似现实世界环境的Design View。而在规划阶段的第一个开发周期里便锁定使用个案路线，了解项目的最大风险所在，更大大地增进了项目团队在未来开发周期里成功的机会。
千万别勉强接受那些无法在各个项目阶段中转移的工作产出。每一个工作产出都应该是可以追踪的，不管是在项目生命中往前或往后追溯。从确认需求到系统设计之间的转变过程，并不是什么神秘事件，没什么大不了的。它应该是个自然的过程，很容易解释，也很容易让所有的项目团队成员都了解才是。
文章来源于领测软件测试网 https://www.ltesting.net/
