1、开发过程缺乏统一的、规范化的方法论的指导；文档资料不齐全或不准确；忽视与用户之间、开发组员之间的交流；忽视测试的重要性;不重视维护或由于上述原因造成维护工作的困难。关键词需求分析 软件工程 数据库 计算机软件 系统正文一、软件需求的概况软件需求的定义软件行业存在这样一个问题,用于描述需求工作的术语没有统一的定义.对同一项需求，不同的人会有不同的描述,称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。定义的多样性导致了令人迷惑和沮丧的沟通问题。需求必须被记
2、录成文档，这一点很重要。公凭一堆电子邮件、便条、会议记录，以及对走廊中几次交谈的模糊印象就自称掌握了需求，那纯属自欺欺人。咨询专家Brian Lawrence提出，需求是“任何促成设计决策的因素”.很多信息都属于这一范围。IEEE的软件工作标准术语表（1990）则将需求定义为：用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。上述第一项或第二项中定义的条件和能力的文档表达。这一定义既体现了用户对需求的看法（系统的外部行为）,也代表了开发人员的观点（一些深层的特性）。术语用户隶属于涉众,因为并非所有涉众都是
3、用户。我对需求的理解是：产品为向涉众提供价值而必须具备的特性。下面这条定义则确认了需求类型的多样性（Sommervill和Sawyer 1997）：需求是对应该实现什么功能的说明可以是对系统运行方式或系统特征与属性的描述;还可能是对系统开发过程的约束。很显然，对于需求是什么没有一个统一的定义。为便于交流，我们需要协商决定一组限定词来修饰“需求”这个内涵丰富的术语，并认识到用可通用的形式记录需求的重要性。不要一厢情愿地认为项目涉众对需求的理解是一致的。应该事先给出定义，才能保证大家谈论的是同一个问题。二、软件需求的发展需求工程是指应用已验证的有效的技术、工具、方法进行需求分析，确定客户要求,帮助
4、分析人员理解问题,并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档,并对用户不断变化的需求演进给予支持。需求工程的概念最初来自于计算机软件系统工程，主要用于解决计算机软件系统开发过程中的需求问题。随着需求工程的发展,人们认识到需求工程研究的对象不仅局限于计算机软件系统，也适用于一般的系统和组织。近几年,需求工程与组织管理的联系得到了来自流程再造、组织变更、设计理论等领域研究人员和业内人士的关注，需求工程现在已经发展到了与系统和组织等方面相关的更广阔的视角。2。1需求工程的国内外发展现状需求工程是随着计算机的发展而发展的，在计
5、算机发展的初期，软件规模不大，软件开发所关注的是代码编写,需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期.80年代中期，形成了软件工程的子领域-需求工程（requirement engineering，RE）。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会（ISRE），自1994年起每两年举办一次需求工程国际会议（ICRE），在1
6、996年Springer-Verlag发行了一新的刊物-Requirements Engineering。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR（Requirements Engineering Network of International Cooperating Research Groups）,并开始开展工作。在我国，需求工程的研究始于20世纪80年代末、90年代初，主要有下列科研院所开展这方面的研究，并取得研究成果，如:中国科学院软件所、南京大学软件所、北京大学计算机系、北京航空航天大学软件工程研究所、武汉大学软件工程研究所、还有华中理工大学、国防科技大学、复旦大
7、学等。2需求工程的内容需求工程是一个不断反复的需求定义、记录和演进的过程，并在最终达到需求的冻结。我们可以把需求工程的活动划分为五个阶段：（1）需求获取：积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合问题解决领域的用户需求。用户的需求分为俩类：功能性需求与非功能性需求。功能性需求主要说明了系统各功能部件与环境之间的相互作用的本质，即拟开发软件在职能上实际应做到什么。它是用户最主要的需求，通常包括系统的输入、系统能完成的功能、系统的输出以及其它反应。非功能性需求有人简单称为“约束”,它主要从各个角度对所考虑的可能的解决方案起约束和限制作用。在对用户进行需求分析时不只是定义功能
8、性需求，还应定义非功能性需求。（2）需求建模:根据需求分析，对已获取的需求进行抽象描述，为目标系统建立一个概念模型。需求模型的表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种.自然语言形式具有表达能力强的特点，但它不利于捕获模型的语义，一般只用于需求抽取或代写硕士论文标记模型。半形式化表示可以捕获结构和一定的语义，也可以实施一定的推理和一致性检查。形式化表示具有精确的语义和推理能力，但要构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解.（3）需求规格说明：对需求模型进行精确地、形式化的描述,为计算机系统的实现提供基础。软件需求规格说明是开发者和用户之间的一
9、个协约.SRS是对外部行为和系统环境（软件、硬件、通信端口和人）接口的简洁完整的描述性文档。SRS基本内容包括行为需求和非行为需求。行为需求定义系统需要“做什么,描述系统输入输出的映射及其关联信息,刻画系统功能.非行为需求定义系统的属性，描述与行为无关的目标系统特性，如性能、可靠性、安全性、易维护性、可用性、顺应性等.（4）需求验证:以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性.IEEE这样定义验证”：”它是用来评价某一系统或某一组件的过程，来判断给定阶段的产品是否满足该阶段开始时施加的条件。换句话说，验证活动在很大程度上是一种普通的测试
10、活动,要求您验证每个开发阶段（例如软件某项需求或多项需求的实现）是否符合先前阶段定义的需求。（5）需求管理：跟踪和管理需求变化，支持系统的需求演进。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估，对项目风险承担者进行协商，对软件开发各阶段应跟踪每项需求的状态。2.3需求工程实施中存在的问题（1）需求不正确：需求的正确性是分析模型最基本的要求之一，它一般是指在模型中的对于待开发系统的功能、行为、性能的表述必须与用户对目标系统的期望相吻合，即分析模型中所描述的每一项需求都代表了对于待开发系统的真实要求。然而大多数情况下，需求分析只是将UML作为描述系统的业务流程方法，但并没有将建模
11、图型作为用户与分析人员交流的介质,单向的需求分析造成需求的不准确。此外，需求也未被作为需求目标分解的依据.（2）需求不一致：需求的一致性是指在系统的各子集中不存在显式的或隐含的矛盾.需求分析往往按照系统利益相关者的不同角色进行划分,但这些需求往往会因为系统资源限制不能完全得到满足，或因认识角度的不同而相互矛盾，因此这样的需求不能直接反映系统的需求。（3）需求存在二义性：要求分析模型中所描述的任何事情有且只有一种解释。如果其中某一部分给不同的人理解，解释超过一种，那么该分析模型就存在二义性.（4）需求不精确：现有的系统需求主要通过文本和图形的方式表示，这种需求分析方法只能对需求进行定性分析，而在
12、有些情况下，需求需要更加精确的描述，如定量描述.（5）需求不完整：需求的完整性是指分析模型中包含了目标系统所要求做的全部工作的描述。具体地说，就是要将待开发系统的所有功能、行为、性能约束以及它在所有可能情况下的预期行为,对于所有可能出现的输入数据的定义以及对合法和非法输入值的响应等，都要包含在分析模型中。（6）需求不灵活：现有的需求是根据特定的系统环境分析得出的，但当系统环境变化时，需求不能随之快速变化。对于具有弹性的系统环境,现有的需求分析也不能得出在特定的系统环境变化范围内的系统需求。三、软件需求的现状1. 需求工程的方法学需求工程的方法学发展很快，对需求工程方法学不同侧面的研究和一些经典
13、论述为需求工程的发展奠定了基础。其中典型的有： Lano提出的操作概念规格，于需求产生前由开发人员写成，它既满足精确的规格说明要求,同时易读、易理解，便于用户了解是否真正体现了其要求。* Sutcliffe、Maiden等人提出从领域知识的角度定义在需求工程环境中通用的领域语义模型和组合模型。* Alford 提出任务分割的概念，大大减低了需求分析的问题复杂度. Chou 和Eckert 讨论了面向对象的需求工程方法学的概念和模型。* Drake提出用于确定系统需求边界的限定过程。 Gotel 对需求跟踪性问题进行了研究。还有其他许多人对需求工程方法学的其他方面进行了研究和论述。综合看来，需求
14、工程方法大致分为四类：面向过程、面向数据、面向控制、面向对象。* 面向过程的分析方法主要研究系统输入输出的转化方式，对数据本身及控制方面并不很重视。传统的结构分析方法SA（structure analysis）、SADT（structure analysis and design technique）和可执行/可操作模型PAISley、Descartes以及形式方法VDM（vienna design method）、Z等都属于这一类. 面向数据的方法强调以数据结构的方式描述和分析系统状态,JSD和关系实体（ER）模型都属此类.* 面向控制的方法强调同步、死锁、互斥、并发以及进程激活和挂起,数据
15、流图就是典型的面向控制的方法，SADT是以面向控制的方法为辅的.* 面向对象的方法把分析建立在系统对象以及对象间交互的基础上，通过对象的属性、分类结构和集合结构定义和沟通需求。从对象模型、动态模型和功能模型三个方面对问题进行描述.面向对象的方法正在成为需求分析中的一个热点,并展现出良好的应用前景.Yourdan和Coad的OOA方法、Booch的方法、Jacobson 的OOSE、Rumbaugh的OMT方法等，都是这一方法的典型流派。2. 面向对象的需求工程方法目前，作为解决软件危机的一个最佳对策，是采用面向对象（OO）的技术。面向对象的开发方法强调从问题域的概念到软件程序和界面的直接映射.
16、事实上，把客观世界看成许多对象更接近人类的自然思维方式,而且对象相对稳定。软件需求的变动往往是功能的变动,而功能的执行者对象一般不会有大的变化。这便是OO技术产生与发展的根源。另外，OO技术支持信息隐蔽、数据抽象与封装，使得软件的开发、修改和维护易于进行。面向对象的方法已应用到软件生命周期的各个阶段，而且OO技术自然地支持快速原型法和快速应用开发.对需求工程而言，由于人类自然地趋向于用“对象的观点或方法来认识问题和描述问题,所以用基于对象的概念模型来建立问题域模型成为需求分析员和用户交流的有效手段.面向对象的需求分析的基本步骤如下：（1）与用户广泛接触,收集和查看相关资料，对问题域有一个大致的
17、了解。在此基础上,提炼和标识对象。（2） 描述对象（类）的属性.（3）描述对象之间的关系，如整体关系和从属关系等。（4）描述问题域的“剧情”,即描述问题域中完成每个任务需要的对象间的协作关系。以上四个步骤不是孤立进行，而是相互联系的。通过这四个步骤的反复执行，就可以建立一个基于对象的问题域模型.Booch是面向方法最早的倡导者之一,他提出了面向对象的软件工程的概念。1991年,他将以前面向Ada的工作扩展到整个面向对象的设计领域，Booch的方法比较适合于系统的设计和构造。Rumbaugh等人提出了面向对象的建模技术（OMT），采用面向对象的概念，引入各种独立于语言的表示符.这种方法用对象模型
18、、动态模型、功能模型和实例模型共同完成对系统的建模。所定义的概念和符号可用于软件开发的分析、设计和实现的全过程。开发人员无须在开发过程的不同阶段进行概念和符号的转换.特别适用于分析和描述以数据为中心的信息系统。Coad和Yourdon采用5个步骤来确定一个多层的OO模型，5个步骤分别对应模型的5个层次。即:（1）找出类和对象-类和对象层；（2）定义属性-属性层（3）识别结构与关系结构层;（4）确定主题主题层;（5）定义服务-服务层。它是最早的面向对象的分析与设计方法之一,该方法简单易学，适合于面向对象的初学者使用，但由于该方法在处理能力方面的局限，目前已很少使用。3。 面向对象的建模面向对象的
19、建模是一种新的设计思想，一种关于计算和信息结构化的新思维.面向对象的建模，把系统看作是相互协作的对象,这些对象是结构和行为的封装，都属于某个类，那些类具有某种层次化的结构。系统的所有功能通过对象之间相互发送消息来获得。面向对象的建模可以视为是一个包含以下元素的概念框架:抽象、封装、模块化、层次、分类、并行、稳定、可重用和可扩展.面向对象的建模思想的出现是面向过程和严格数据驱动的软件开发方法的渐进演变结果。（1）UML-Unified Modeling Languge面向对象的分析与设计方法，在80年代末至90年代中发展到一个高潮.但是，诸多流派在思想和术语上有很多不同的提法,在术语、概念上的运
20、用也各不相同，统一是继续发展的必然趋势。需要一种统一的符号来描述面向对象的分析和设计活动，UML应运而生。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且有进一步的发展，最终成为大众所共同接受的标准建模语言。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它融入了软件工程领域的新思想、新方法和新技术.不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发全过程。UML是面向对象技术发展的重要成果。获得科技界、工业界和应用界的广泛支持,截止1996年底的统计，已有700多家公司表示支持采用UML作为建模语言，稳占面向对象技术市场的85，成为可视化建模
21、语言事实上的工业标准。1997年,OMG采纳UML1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值.（2）可视化的建模工具ROSEROSE是Rational 公司开发的一种CASE工具.它用UML语言支持软件开发的大部分过程的建模。在ROSE中，只要你用UML描述了软件的各个部分，也就是为软件建立了一个面向对象的模型， ROSE就可以自动生成应用系统需要的大部分源代码.而且,基于此整个系统具有OO的诸多优点-如模型稳定性、重用性等等，降低了软件维护和升级的成本。（3）UML对用户驱动需求工程的支持OO
22、思想曾经遭受一些人的批评.理由是用户关心和理解的只是系统的功能,他不可能去学习OO模型，所以虽然OO建模缩小了分析设计和编码的鸿沟，但却拉大了和用户的距离。幸运的是,Use Case的出现,使这一情况得到了大大的改观。在UML中，用OO建模的第一步是Use Case 的分析，Use Case体现了系统的功能单元.系统的外部人员或其它系统通过和Use Case 交换消息来了解和使用系统的功能，弥补了OO建模和用户之间的距离。UML以对象图描述任何类型的系统，具有很宽的应用领域,可以对任何具有静态结构和动态行为的领域建模。UML还适用于从需求规格说明到系统测试的不同阶段.在需求分析阶段，用Use
23、Case捕捉用户需求并建模,描述与系统有关的外部角色及其对系统的功能要求。分析阶段主要关心问题域中的主要概念和机制，并用UML类图来描述对象和类,用UML动态模型描述类之间的协作关系。所以，UML适用于以面向对象的技术来描述任何类型的系统。而且适用于系统开发的不同阶段.UML也可以应用于任何领域，其实现机制又极大地缩短了用户的距离,易于被用户掌握和接受。UML使用户不仅可以有效地参与需求定义，还能在建模过程中参与部分的设计、实现和测试,从而有效地进行需求验证。使用户在需求的定义、决策、验证和管理,乃至整个软件开发过程中，充分发挥其主导作用.四、结语 需求工程的发展，使人们认识到，只有最终用户的
24、直接参与并发挥主导作用,才能真正解决问题空间与求解空间的一致性问题，消除计算机领域和应用领域之间的鸿沟，并自动适应系统需求的不断变化。针对传统分析方式的弊端，一种新的被称为“用户主导、面向领域的需求分析方法”被提了出来。需求工程研究现状中一个明显的不足是研究理论与实践的脱节,理论解决方案通常是在对实际问题简化的基础上得到的。要获得需求突破，改善需求工程的开发质量和效率，需要探索一条有效的解决途径,缩小理论与应用之间的距离，使开发出来的系统和模型切实满足应用领域的需要。目前我们正在尝试研制一种有实用价值的面向某一行业领域的用户主导式的应用软件辅助开发工具及原型系统，建立面向领域的用户框架，继续完善用户驱动的需求分析理论和方法，推动用户工程理论的形成参考文献1、软件工程导论（第三版） 张海潘 清华大学出版社 19982、实用软件工程郑人杰殷人昆,陶永雷 清华大学出版社 19973、软件需求 Karl E. Wiegers 机械工业出版社 20004、可视化面向对象建模技术标准建模语言UML教程刘超，张莉 北京航空航天大学出版社 19995、软件工程应用实践教程 吴洁明，袁山龙 清华大学出版社 20036、实用软件工程郑人杰 清华大学出版社 2000
