Java建模:需求收集工作的恰当过程

Java建模:需求收集工作的恰当过程2011-12-29 IBM developerworks网站软件不可见性问题

新软件应用程序概念化的难点因项目的不同而不同。虽然某些项目的需求很直观 ― 或许就像把一项新技术应用于一个著名的领域 ― 但其它项目需求可能更复杂。当我们不断的将软件技术用于未知领域，为软件系统创建需求的行为成为一种概念上的革新。这种革新不只是一种个体的复杂的脑力劳动，其难处还在于与更大的开发团体进行交流。

Frederick Brooks 把那些难以概念化和描述的新软件应用程序的属性称为软件不可见性。虽然其它如硬件之类的领域存在物质表现形式，但软件领域没有。我们可以看得见或者评测出软件应用程序的效果，不过其系统表现形式本质上却是思维的。这就是我们创建并依赖于软件模型的许多原因之一。模型赋予软件物理维度使我们得以更好的了解和表达它的方向。

任何软件建模工作的中心是需求收集。实现需求收集过程的选择依赖于开发项目更大的环境。这个环境可以在需求收集过程自身中找到，也可以在另一个受到好评的模型中找到。在某些情况下，这个环境甚至可以在可交付使用的过程中找到。通过对我们探讨的不同需求可能性的地方进行考察，我们总能够辨别出系统的需求环境驻留在什么地方。需求环境是我们与软件不可见性对抗的领域。

恰当工作过程的选择

为实现所选择的需求收集过程极大的影响着软件开发项目的成功。因为需求收集是开发周期的基础，一个无效或选择欠妥的需求分析过程极大的增加了项目失败的可能性。这种可能性导致我们死守着已知的过程，通常与一个单独的、受偏爱的软件开发方法有关。

这里将探讨的需求收集过程抽象自三个一流的软件开发方法：“Rational 统一过程”（ Rational Unified Process（RUP）），“功能驱动开发”（Feature-Driven Development（FDD））和“极端编程”（ Extreme Programming（XP））。每种方法都提供大量极好的工具以协助需求收集工作。为符合子整体开发方法，我们将更多的着眼于必要的部分 ― 与每种方法相关的需求收集过程 ― 而不是整个方法自身。除此之外，我们还会看看是否能够组织起一个更动态更可变的需求收集过程。

四种最常见的需求收集过程是传统的软件收集规范（software requirements specification，SRS）、用例（use cases）、功能特性（features）和用户情景（user stories）。在随后的几个小节，我们将考虑每个过程，请特别注意需求环境 ― 就是说，每个过程提供的用于将价值最大化的恰当情况和每个过程给开发项目带来的独特动力。