软件不可见性成果
新软件应用程序概念化的难点因项目的不同而不同。虽然某些项目的需求很直观 ― 或许就像把一项新技术应用于一个著名的领域 ― 但其它项目需求能够更复杂。当我们不时的将软件技术用于未知领域，为软件系统创立需求的行为成为一种概念上的改造。这种改造不只是一种个体的复杂的脑力劳动，其难处还在于与更大的开发集团进行交流。
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，用例更适宜已被很好了解的领域。用例可以经受一定水平的更改，但其它进程更能适应更改。
