《计算机理论论文浅谈需求工程的定义及其内容、现状.doc》由会员分享，可在线阅读，更多相关《计算机理论论文浅谈需求工程的定义及其内容、现状.doc（2页珍藏版）》请在三一文库上搜索。
1、浅谈需求工程的定义及其内容、现状 2.1需求工程概述2.1.1需求工程的概念需求工程是指应用已验证的有效的技术、工具、方法进行需求分析，确定客户要求，帮助分析人员理解问题，并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。需求工程的概念最初来自于计算机软件系统工程，主要用于解决计算机软件系统开发过程中的需求问题。随着需求工程的发展，人们认识到需求工程研究的对象不仅局限于计算机软件系统，也适用于一般的系统和组织。近几年，需求工程与组织管理的联系得到了来自流程再造、组织变更、设计理论等领域研究
2、人员和业内人士的关注，需求工程现在已经发展到了与系统和组织等方面相关的更广阔的视角。2.1.2需求工程的国内外发展现状需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域需求工程(requirement engineering,RE)。进入90年代
3、以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物Requirements Engineering。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups)，并开始开展工作。在我国，需求工程的研究始于20世纪80年代末、90年代初，主要有下列科研院所开展这方面的研究，并取得研究成
4、果，如:中国科学院软件所、南京大学软件所、北京大学计算机系、北京航空航天大学软件工程研究所、武汉大学软件工程研究所、还有华中理工大学、国防科技大学、复旦大学等。2.1.3需求工程的内容需求工程是一个不断反复的需求定义、记录和演进的过程，并在最终达到需求的冻结。我们可以把需求工程的活动划分为五个阶段：（1）需求获取：积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合问题解决领域的用户需求。用户的需求分为俩类:功能性需求与非功能性需求。功能性需求主要说明了系统各功能部件与环境之间的相互作用的本质，即拟开发软件在职能上实际应做到什么。它是用户最主要的需求，通常包括系统的输入、系统能完
5、成的功能、系统的输出以及其它反应。非功能性需求有人简单称为“约束”，它主要从各个角度对所考虑的可能的解决方案起约束和限制作用。在对用户进行需求分析时不只是定义功能性需求，还应定义非功能性需求。（2）需求建模：根据需求分析，对已获取的需求进行抽象描述，为目标系统建立一个概念模型。需求模型的表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的特点，但它不利于捕获模型的语义，一般只用于需求抽取或代写硕士论文标记模型。半形式化表示可以捕获结构和一定的语义，也可以实施一定的推理和一致性检查。形式化表示具有精确的语义和推理能力，但要构造一个完整的形式化模型
6、，需要较长时间和对问题领域的深层次理解。（3）需求规格说明：对需求模型进行精确地、形式化的描述，为计算机系统的实现提供基础。软件需求规格说明是开发者和用户之间的一个协约。SRS是对外部行为和系统环境(软件、硬件、通信端口和人)接口的简洁完整的描述性文档。SRS基本内容包括行为需求和非行为需求。行为需求定义系统需要“做什么”，描述系统输入输出的映射及其关联信息，刻画系统功能。非行为需求定义系统的属性，描述与行为无关的目标系统特性，如性能、可靠性、安全性、易维护性、可用性、顺应性等。（4）需求验证：以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性
7、。IEEE这样定义”验证”：”它是用来评价某一系统或某一组件的过程，来判断给定阶段的产品是否满足该阶段开始时施加的条件。换句话说，验证活动在很大程度上是一种普通的测试活动，要求您验证每个开发阶段（例如软件某项需求或多项需求的实现）是否符合先前阶段定义的需求。（5）需求管理：跟踪和管理需求变化，支持系统的需求演进。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估，对项目风险承担者进行协商，对软件开发各阶段应跟踪每项需求的状态。2.1.4需求工程实施中存在的问题（1）需求不正确：需求的正确性是分析模型最基本的要求之一，它一般是指在模型中的对于待开发系统的功能、行为、性能的表述必须与用
8、户对目标系统的期望相吻合，即分析模型中所描述的每一项需求都代表了对于待开发系统的真实要求。然而大多数情况下，需求分析只是将UML作为描述系统的业务流程方法，但并没有将建模图型作为用户与分析人员交流的介质，单向的需求分析造成需求的不准确。此外，需求也未被作为需求目标分解的依据。（2）需求不一致：需求的一致性是指在系统的各子集中不存在显式的或隐含的矛盾。需求分析往往按照系统利益相关者的不同角色进行划分，但这些需求往往会因为系统资源限制不能完全得到满足，或因认识角度的不同而相互矛盾，因此这样的需求不能直接反映系统的需求。（3）需求存在二义性：要求分析模型中所描述的任何事情有且只有一种解释。如果其中某
9、一部分给不同的人理解，解释超过一种，那么该分析模型就存在二义性。（4）需求不精确：现有的系统需求主要通过文本和图形的方式表示，这种需求分析方法只能对需求进行定性分析，而在有些情况下，需求需要更加精确的描述，如定量描述。（5）需求不完整：需求的完整性是指分析模型中包含了目标系统所要求做的全部工作的描述。具体地说，就是要将待开发系统的所有功能、行为、性能约束以及它在所有可能情况下的预期行为，对于所有可能出现的输入数据的定义以及对合法和非法输入值的响应等，都要包含在分析模型中。（6）需求不灵活：现有的需求是根据特定的系统环境分析得出的，但当系统环境变化时，需求不能随之快速变化。对于具有弹性的系统环境，现有的需求分析也不能得出在特定的系统环境变化范围内的系统需求。