文档介绍：. -
- -可修编-
1．概念 需求的定义包括从用户角度〔系统的外部行为〕，以及从开发者角度〔一些内部特性〕来阐述需求。 关键的问题是一定要编写需求文档。我曾经目睹过一个工程中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起。系统的分析人员说：“我们想与你谈谈你的需求。〞客户的第一反响便是：“我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统〞。而实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。 需求的另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明〞。有些需求分析专家拓展了这个概念：“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等〞。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义那么从用户需要进一步转移到了系统特性： 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求〞术语存在，真正的“需求〞实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有工程风险承当者在描述需求的那些名词的理解上务必达成共识。 任何文档形式的需求〔例如如下将要描述的需求规格说明书〕仅是一个模型，一种描述。2．需求分析的任务 开发软件系统最为困难的局部就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的局部，并且以后再对它进展修改也极为困难。 目前，国内产品的庞杂，一家企业可能有几个系统并立运行，它们之间接口是系统开发人员最头痛的问题。 对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一局部的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道工程于何时完毕？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？ 然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可防止的后果，而重新编制代码的代价远远超过重写一份需求文档的代价，这些血的教训正在国内的软件开发者身上发生。 近来，我遇到一个开发