文档介绍：需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求。关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起。系统的分析人员说:“我们想与你谈谈你的需求。”客户的第一反应便是:“我已经将我的要求都告诉你们前任了, 现在我要的就是给我编一个系统”。而实际上, 需求并未编写成文档, 因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话, 你就确信你已明白用户的需求, 那完全是自欺欺人。需求的另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。有些需求分析专家拓展了这个概念:“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的, 而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性: 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性, 是在开发过程中对系统的约束。从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的“需求”术语存在, 真正的“需求”实际上在人们的脑海中, 这个人们主要是指客户, 但一般情况下, 用户并不能描述自己的需要, 只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述。 2 .需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求, 这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错, 将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难。目前, 国内产品的庞杂, 一家企业可能有几个系统并立运行, 它们之间接口是系统开发人员最头痛的问题。对于商业最终用户应用程序, 企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说, 并没有编写出客户认可的需求文档, 我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的, 那我们又如何能使客户感到满意呢? 然而, 即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致, 但更常见的是出现重复返工这种不可避免的后果, 而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生。近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是, 当他们开发完这个工具后, 发现这个工具不能打印出源代码文件, 使用者当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了。相反的情况, 我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误。事实上,需求文档在开发过程中一直起指导作用。 3 .需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图 4-1 所示:图 4-1 需求工程域的层次分解示意图需求开发可进一步分为: 问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面: 确定产品所期望的用户类别。获取每个用户类的需求。了解实际用户任务和目标以及这些任务所支持的业务需求。分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件。了解相关质量属性的重要性。商讨实施优先级的划分。将所收集的用户需求编写成文档和模型。评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚。需求管理需要“建立并维护在软件工程中同客户达成的合同”。这种合同都包含在编写的需求文档与模型中。客户的接受仅是需求成功的一半, 开发人员也必须能够接受他们, 并真正把需求应用到产品中。通常的需求管理活动包括: 定义需求基线(迅速制定需求文档的主体)。评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。使当前的项目计划与需求一致。估计变更需求所产生影响并在此基础上协商新的承诺,