文档介绍：如何进行软件需求分析51CMM作者:曹伟1概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)來阐述需求。关键的问题是-•定要编写需求文档。我曾经II睹过-•个项II中途更换了所有的开发者,衣户被迫与新的需求分析者坐到-•起。系统的分析人员说:“我们想与你谈谈你的需求。‘'客户的第-•反应便是「我已经将我的耍求都告诉你们前任了,现在我耍的就是给我编一个系统二而实际上,需求并未编写成文档,因此新的分析人员不得不从头做起。所以如果只冇一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人。需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明二有些需求分析专家拓展了这个概念:“从系统外部能发现系统所具冇的满足于用八的特点、功能及属性等这些定义强调的是产品是什么样的,。而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性,是在开发过程屮对系统的约束。从上而这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的篁需求''术语存在,真正的“需求''实际上在人们的脑海中,这个人们主耍是指客户,但一般情况下,用户并不能描述H己的需要,只就需要系统分析人员根据用八的H己语言的描述整理出相关的需要再进一步和客八核对。系统分析员和客户需要确保所冇项H风险承担者在描述需求的那些名词的理解I••务必达成共识。任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,i种描述。需求分析的任务开发软件系统最为闲难的部分就是准确说明开发什么。最为闲难的概念性工作便是编写出详细技术需求•这包括所有面向用户、而向机器和其它软件系统的接口。,并且以后再对它进行修改也极为闲难。H前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员故头痛的问题。对于商业最终用户应用程序,金业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员來说,并没有编写出客户认町的需求文档,我们如何知道项H于何时结朿?而如果我们不知道什么对客户来说是重要的,那我们乂如何能使客户感到满憑呢?然而,即便并非出于商业H的的软件需求也是必须的。例如库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一•致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生。近來,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件。,。结果这个小组只好手工抄写源代码文档以供代码检査。这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望H标也只能是咎山自取了。"中的简单界面写了-•页需求说明。而操作系统系统管理员在为处理脚木时发现简单的-•张需求涓单竟是如此有川。他们依据需求对系统进行测试时,此系统不仅非常淸晰地实现了所有必需功能,而且未发现任何错误。事实上,需求文档在开