Granville Miller（[email protected]）
顾问和开发者，TogetherSoft
2001 年 10 月
在上一个专栏中，我开始讨论子整体软件开发，它是一种注重对过程进行革新的开发方法。 这是我的信仰，正如我在上个月的宣言中所述，子整体软件开发有潜力让开发者取得非凡的成就。但是，这并不意味着我鼓吹完全排除过程。我看待过程的哲学可以总结如下：
过程太少，非凡的人能做平凡的事；
过程太多，即使是非凡的人也不能做非凡的事。
这个月，我将讨论子整体软件开发和过程的应用。尤其是，我们将谈到需求收集 — 任何软件开发周期的基础，还将谈到子整体方法 — 一种在开发周期中动态实现大量过程和方法的手段 — 如何能够增强您的需求收集过程。
软件不可见性问题
新软件应用程序概念化的难点因项目的不同而不同。虽然某些项目的需求很直观 — 或许就像把一项新技术应用于一个著名的领域 — 但其它项目需求可能更复杂。当我们不断的将软件技术用于未知领域，为软件系统创建需求的行为成为一种概念上的革新。这种革新不只是一种个体的复杂的脑力劳动，其难处还在于与更大的开发团体进行交流。
Frederick Brooks 把那些难以概念化和描述的新软件应用程序的属性称为软件不可见性。虽然其它如硬件之类的领域存在物质表现形式，但软件领域没有。我们可以看得见或者评测出软件应用程序的效果，不过其系统表现形式本质上却是思维的。这就是我们创建并依赖于软件模型的许多原因之一。模型赋予软件物理维度使我们得以更好的了解和表达它的方向。
任何软件建模工作的中心是需求收集。实现需求收集过程的选择依赖于开发项目更大的环境。 这个环境可以在需求收集过程自身中找到，也可以在另一个受到好评的模型中找到。在某些情况下，这个环境甚至可以在可交付使用的过程中找到。通过对我们探讨的不同需求可能性的地方进行考察，我们总能够辨别出系统的需求环境驻留在什么地方。需求环境是我们与软件不可见性对抗的领域。
恰当工作过程的选择
为实现所选择的需求收集过程极大的影响着软件开发项目的成功。因为需求收集是开发周期的基础，一个无效或选择欠妥的需求分析过程极大的增加了项目失败的可能性。这种可能性导致我们死守着已知的过程，通常与一个单独的、受偏爱的软件开发方法有关。
这里将探讨的需求收集过程抽象自三个一流的软件开发方法：“Rational 统一过程”（ Rational Unified Process（RUP）），“功能驱动开发”（Feature-Driven Development（FDD））和“极端编程”（ Extreme Programming（XP））。每种方法都提供大量极好的工具以协助需求收集工作。为符合子整体开发方法，我们将更多的着眼于必要的部分 — 与每种方法相关的需求收集过程 — 而不是整个方法自身。 除此之外，我们还会看看是否能够组织起一个更动态更可变的需求收集过程。继续讨论前，请用一些时间阅读这篇补充文章“子整体软件开发的十项准则”，看看子整体方法在理论上如何包含我们已知的东西。
四种最常见的需求收集过程是传统的软件收集规范（software requirements specification，SRS）、用例（use cases）、功能特性（features）和用户情景（user stories）。在随后的几个小节，我们将考虑每个过程，请特别注意需求环境 — 就是说，每个过程提供的用于将价值最大化的恰当情况和每个过程给开发项目带来的独特动力。有关以下概括的每个过程的应用的详细信息，请参阅参考资料。
软件需求规范
软件需求规范（SRS）是最古老的需求收集过程之一。其非正式的名称是“应该陈述”（shall statements），传统的 SRS 有多种形态，而且，今天众多领域的承包工程仍然需要用到它。SRS 许多年来一直是处于支配地位的需求收集方法。
SRS 背后的思想是创建一个解决方案空间 — 也就是这样一个空间，其中开发小组已经设定了目标，但是，实现这些目标的行动的秩序和本质可以非常自由。因此，SRS 通常不试图指定单个解决方案，而是指定一系列可行的解决方案。然后，开发小组有足够的灵活性对解决正被创建系统问题的有效方法进行革新。
灵活性对于 SRS 来说，是缺点，也是优点。如果一个软件开发小组精通他们为之创建系统的这个领域，这个小组就可以轻松使用 SRS 最大限度的对这个领域进行革新。但是，在开发小组在他们不熟悉的领域进行日常工作的时代，传统的 SRS 作为需求收集过程可能有所欠缺。典型用户试图处理给定领域中的正常情况时，他们采取的步骤很可能是小组成员不了解的。因此，小组成员确定并创建的系统对于用户社区来说，可能不是最优的。
传统的 SRS 最适用于已被充分了解的领域和非常了解自己所处工作领域的开发小组 — 或者领域之外的专业知识能够很轻松就理解的开发环境。SRS 允许几乎不需任何技术就可以调整解决方案空间以管理系统中的更改。
用例
与传统 SRS 支持的解决方案空间方法相比，用例描述了用户与系统交互时执行的动作序列。从某种意义上说，用例基于路线或目的。它传达一系列用户在使用系统以解决问题时必须启动的动作。例如，在一个“录像带出租”用例中，我们对用户与录像带出租系统交互时会出现的情况进行了描述。
用例反应我们试图使用软件系统以达到目的时可能出现的所有事件。因为大部分软件系统支持多个目的，大部分用例模型由多个用例组成。例如，“支付逾期费”（Pay Late Fee）用例描述了录像带出租系统的用户遇到要支付逾期费这种情况时会发生的事。
用例中信息正确的水平是成功建立应用程序的必要条件。它根据环境不同而不同。如果领域的专家参与开发过程，用例就可以只勾画系统的路线。如果领域专家不参与项目，用例就有必要提供更多信息。用例是交流需求的最佳过程。但是，就像传统的 SRS，用例更适合已被很好了解的领域。用例可以经受一定程度的更改，但其它过程更能适应更改。
录像带出租用例用例名称：出租录像带
唯一的用例 ID：VS-01
主要参与者：客户
次要参与者：N/A
简要描述：这个用例描述了当客户基于 Web 租借录像带时发生的交互行为。
触发事件：客户从片名目录中选择片名。
前提条件：
客户必须有一个活动帐户。 客户满足片名目录附带的录像带分级的年龄要求。 片名目录随片名提供。事件流：
客户浏览片名目录并选择一个片名。后续条件：
为这个帐户创建一个新的订单。 修改库存以反应已出租的录像带。 系统已将帐户记入借方（系统），并按录像带租金把交易记入贷方（客户）。可选的事件流和异常：
片名不存在：客户必须作出另外的选择。 因未支付逾期费造成帐户无效：请参阅“支付逾期费”用例。 因无效信用卡造成帐户无效：系统提示用户输入有效的信用卡帐户。功能特性
功能特性是系统期望功能的简要表述。功能特性的格式为：
<action> the <result> <by|for|of|to> a(n) <object>
一个示例功能特性可以是：
Forecast the total of quarterly sales.
在每个功能特性保持在最小状态时，基于功能特性的方法效果最好。一个小组能在两星期或更少时间内实现的功能特性就是理想的功能特性。
用名为功能集（feature set)的组将功能特性组织起来。功能集包含描述给定目的或领域的功能特性。功能集和它的功能特性仅对需求进行了概述。作为描述需求的机制，功能特性必需和额外的环境相结合。
在“功能驱动开发”方法中，环境被精心设计成介于功能集和一个被称为“领域中立组件”（domain neutral component）的色彩标记类图表之间。 领域中立组件是个描述跨领域公共关系的语义模板。领域中立组件由瞬间间隔（moment-interval）、角色（role)、主题（subject）（当事人（party）、地点或事务）以及描述（description）组成。瞬间间隔是那些领域的短时间要素，如处于订货执行系统的一个订单。角色是个用户，系统和他交互并必须能识别出他。主题是形成领域的要素。描述是一种抽象，它集合了这些对象的元信息。图 1 是个录像带出租的领域中立组件。
图 1. 录像带出租方案的领域中立组件
作为一种需求收集过程，“功能驱动开发”非常灵活，它有助于在开发周期中更改管理。这一过程让您在项目进行过程中轻松检查并记录新的、更改的和已除去功能特性的数目。因为一般来说功能特性小， 更改现存功能特性或添加新功能特性不大可能要求在项目级上大量的返工。功能特性还有助于挑战软件不可见性，因为作为跟踪领域中立组件中的系统实体间交互结果的新功能特性可能被揭示。
功能特性可以用于熟悉给定领域的个体间的需求交流。以这种方式使用，基于功能特性的方法很可能是最节约的需求收集过程。但是，这些功能特性可能太依赖领域专业知识了，这是许多开发小组都没有的奢侈品。
用户情景
用户情景是写在索引卡上的简短描述，如图 2 所示。
图 2. 销售用户情景的要点
用户情景包含的信息往往比功能特性包含的信息多，尽管这不是必要条件。“极端编程”方法中，用户情景要求一个现场的客户提供部分环境。现场客户向开发小组描述理想的系统。然后，这个小组一点一点建立系统，给客户充分的机会定期查看结果。客户“监督着”这个可交付使用过程，并且在新用户情景中提出对系统的修改建议。整个环境由现场客户的反馈和递增的过程及交付相结合。
用户情景对于处理软件不可见性风险最高的项目来说，是最佳的方法。像功能特性一样，它们都足够小，能被轻松更改。 因为它们的环境基于运作的系统和客户，一经实现或不再有效都会被丢弃。但是，并不是每个项目都可以引入现场客户，因此用户情景并不适用于每个项目。这种方法因其缺少客户交互而丧失了它的优势。
结论
本文讨论的每种需求收集过程在恰当的环境中都有其优势所在。但是，正如这篇讨论所示，对于每种环境来说，不是每种需求收集过程都是理想的，它们自身甚至还不是必要的完整。子整体软件开发的中心在于认识到单个过程或活动本质上的不完整，并且尽可能扩大这些用于减少这种不完整的解决方案的范围。
补充文章“子整体软件开发的十项最佳准则”讨论了模块性。模块性允许两种目的相同的活动可以互相代替。当用一种需求收集活动代替另一种时，重要的是把需求环境考虑在内。开发周期中途更改活动很可能会引入一组新的动力到项目。如果没有考虑到环境，这种行动可能会成为灾难。但是，仔细的计划和执行后，引入新活动就能帮助创建新的动力，从而促进了项目的成功。
下个月，我们来谈 Web 服务基础架构的建模。随着我们调查这个软件开发中新兴的领域，我将提供更多具体的技术示例和上两个专栏一直在讨论的最佳准则，所以，请别离开！
参考资料
请参与本文的讨论论坛。
要了解更多有关用例的知识，请参阅由 Frank Armour 和 Granville Miller 撰稿和维护的高级用例建模主页。
Jeff De Luca 在他的文章“FDD 过程起源”（The original FDD processes）中提供了一个 FDD 起源的最佳介绍。
XP 新手可能需要先通读 Roy Miller 和 Chris Collins 撰写的“XP 精粹”（developerWorks，2001 年 3 月）。
Extreme Programming.org，XP 狂热者大量参考资料的宝库，其中对 XP 开发过程的用户情景角色稍作展开介绍。
以用户为中心的设计（user-centered design（UCD））是个很像需求收集和反馈过程的用户情景，但范围更广。找出如何使用便宜、低开销的“Fly on the wall”方法（developerWorks，2001 年 8 月）以了解用户需要什么。
在 IBM Ease of Use 主页，您会找到适合以用户为中心设计的更多参考资料。
请阅读 “Java 建模”归档文件的所有 “Java 建模”专栏（包括上个月的子整体软件开发宣言）。
请在 developerWorks Java 技术专区查找更多 Java 参考资料。
本文地址：http://com.8s8s.com/it/it13226.htm