需求工程小论文--需求工程五阶段的研究

1、需求工程五阶段的研究摘要：本文主要对需求工程五个阶段，即需求获取、需求建模、需求规格说明、需求验证、需求管理，进行了更深层次的阐述，详细介绍了各个阶段存在的问题以及相应的解决措施，力争充分了解并认识需求，为软件后期的设计、开发等工作奠定基石，避免因需求问题而造成不可挽回的局面。关键词：需求工程;需求建模；需求验证；需求管理Five stages of requirements engineering researchAbstract: This paper focuses on the needs of the project in five phases, namely requiremen

2、ts elicitation, requirements modeling, requirements specification, requirements validation, requirements management, conducted a deeper exposition detailing the various stages of the problems and corresponding solutions, strive to fully understand and appreciate the needs, to lay the cornerstone for

3、 the software late design, development, etc., to avoid problems caused irreparable demand situation.Keywords: Requirements engineering；Requirements modeling；Requirements validation；Requirements Management软件产品的生产可以看成是一个映射，将客户最初的非形式想法映射成最终解决此问题的软件产品，需求工程则是这一巨大飞跃中起决定性作用的第一步。需求工程作为软件工程生命周期的起点，是软件开发后继阶段的

4、基础。需求工程过程的质量直接影响着软件开发的速度和成本。实践表明，需求分析活动不应仅限于软件开发的最初阶段，而应贯穿于系统开发的整个生命周期中。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。需求工程可划分成为以下5个独立的阶段，现就每个阶段的任务，存在的问题和解决方法作出解释。1. 需求获取需求获取的主要目的是在开发之前更好地理解要解决的问题。分析员在某种(或几种)需求获取方法的指导下,系统地从非形式需求陈述中提取出客户的实际需求，以某种需求描述机制记录下来，形成客户问题的需求规格说明，并尽可能地消除其非形式的特征(如：二义性、不一致性、矛盾性)。通

5、过与用户的交流、对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。在需求获取期间，也存在一些问题。首先，用户和开发人员所处背景不同，立场不同，这就造成了对于同一个问题，彼此有着不同的理解，给软件的开发带来困难。其次，普通用户缺乏概括性、综合性表达能力，对于自己的需求表述不清，或者不清楚自己的需求到底是什么，更有甚者，用户会提出一些不合理的要求，认为开发人员无所不能，这些都为获得正确的需求带来了障碍。有的软件从一开始就忙于开发，完全没弄清或不知道用户需求是什么，最后只能无果而终，开发出一个没有任何意义的废品，这也正说明了需求获取的重要性。针对这些情况，我们应该采取积极主动的方法来

6、获取需求，比如，用户访谈、用户调查、原型法、民族志等。用户调查方法的主要优点在于调查面比较宽，用户反馈多。这恰好能够成为用户访谈的有效补充，能够克服用户访谈的片面性。其缺点是大家认识到的往往不深入，而这恰好是用户访谈所能避免的。所以说，用户调查是用户访谈的有效、有益的补充。就原型法来说，我们可以通过快速原型法，先实现一部分软件，展现需求提出方的要求，这样往往会减少软件供需双方对需求理解上的差异，而且会提高需求提出方交流需求的积极性。民族志作为人类学的主要研究方法，在设计的运用中以研究人们的日常生活为基础，以探索用户需求为目的，以实地调查为主要方式，以用户行为为研究中心，重点在于对真实生活方式的

7、研究、对日常生活的观察，通过探访合适的“需求携带者”，观察、交谈、记录，最终解释用户未被满足及隐含的需求。在实际获取需求时，我们可以采取适当的方法，来正确理解用户需求。2. 需求建模为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。主要包括结构化建模和面向对象建模。其中，结构化建模包括过程建模和数据建模，过程建模是结构化建模的核心方法。软件过程建模的主要目的是建立软件过程的抽象模型，通过对该抽象模型的分析增加对过程本身的理解和认识，从而可以更好地实施软件开发活动。其描述工具主要包括数据流图、数据字典、模块结构图。数据建模指的是对现实世界各类数据的抽象

8、组织，确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。建立数据模型的过程被称为数据建模。通过建立概念数据模型、逻辑数据模型、物理数据模型，从而生成数据库。面向对象建模，是一种用于辨识系统环境中的对象及这些对象之间关系的技术。通过UML建模工具，建立对象模型、用例模型和行为模型。通过需求建模，进一步将需求细化，既能正确的理解需求，又能为后期的工作奠定坚实的基础。3. 需求规格说明需求工程的各项活动以需求为中心,紧紧围绕着需求规格说明展开:问题分析奠定了获取和解释需求模型的知识背景；需求验证确保所得到的需求规格说明反映了客户的真实意图。需求规格说明应包含两方面内容:一是功能需求,即

9、待开发系统的输入/输出及相互依赖关系的描述；二是非功能需求,主要包括一些内外部环境的限制,如国家、行业的政策、法令、法规以及经济限制、开发过程要求、运行环境要求、性能要求、安全性要求、用户操作要求等。需求规格说明的目标是定义用户需求，准确描述需求及其解决方案。其作用是更好的传递软件系统的需求信息和解决方案给所有的开发者；拓展人们的知识记忆能力；作为合同协议的重要部分；作为项目开发活动的一个重要依据；发现和减少可能的需求错误，减少项目的返工，降低项目的工作量；作为有效的智力资产。 需求工程研究的核心是关于需求规格说明技术的研究，应致力于寻求：广泛地适用于对各类应用领域中的客户问题进行理解与描述，

10、从而提取客户需求规格说明的机制；需求规格说明的表示、获取、维护、文档制作及品质保证机制；需求规格说明的演示验证机制。鉴于需求规格说明的重要性，需求规格说明应有自己的品质保证体系。所谓品质保证即是给出一系列质量评判标准与改进手段。多数有关需求分析的文献大多罗列一系列属性来描述什么是良好的需求规格说明，这些属性往往相互重叠和矛盾，并且目标和性质相互混杂。需求规格说明是分析员根据他对客户需求陈述的理解而构造的关于客户问题的一种模型。这一模型作为系统开发各方达成的共识是对系统进行设计、实现、测试、验收的基本依据。通常使用下面的三种方法来编写软件需求规格说明：（1）用好的结构化和自然语言编写文本型文档。

11、（2）建立图形化模型，这些模型可以描绘转换过程、系统状态和他们之间的变化、数据关系、逻辑流或对象类和它们的关系。（3）编写形式化规格说明，通过使用数学上精确的形式化逻辑语言来定义需求。编写优秀的需求文档没有现成固定的方法，最好是根据经验进行，过去所遇到的问题将为以后编写需求文档提供丰富的指导。然而，在编写软件需求文档时，仍然需要注意以下几点：（1）保持语句和段落的简短。（2）采用主动语态的表达方式。（3）编写具有正确的语法、拼写和标点的完整句子。（4）需求陈述应该具有一致的样式。（5）为了减少不确定性，必须避免模糊的、主观的术语。例如：容易，迅速等。（6）避免使用比较性的词。例如：提高、最大化

12、和最佳化等。正确的说明应该是定量的说明所需要提高的程度。为了保证软件需求规格说明书的质量，除了需要在编写需求文档时注意之外，还应该加强对需求文档的审核。进行文档审核的主要方法如下：（1）从软件需求规格说明中取出一页功能需求说明，检查每个语句，看它是否与好的需求特性相符，重写那些不符合的需求。（2）如果公司对需求文档没有提供标准的格式，那么，就召集一个小的工作组讨论并采纳一个标准的软件需求规格说明模板，改编这个模板，使其更好地适合开发的项目和产品。（3）召集一个由37个项目的风险承担者组成的小组来正式评审项目中的软件需求规格说明，确保每个需求规格说明都是清晰的、可行的、可验证的及无二义性的等。4

13、. 需求验证以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动。需求验证的方法主要包括评审法、原型与模拟法、开发测试用例、编制用户手册、利用跟踪关系、自动化分析等方法。其中，评审法是由作者之外的其他人来检查产品问题的方法，是主要的静态分析手段 ，在原则上，每一条需求都应该进行评审。需要经过规划总体部署准备审查会议返工跟踪这一系列过程，采用自由方法、检查清单、缺陷功能点、视角、场景、逐步提升的检查方法来验证需求。当涉及到复杂的动态行为时，可以采取原型与模拟的方法来验证需求，但是成本往往较高

14、。通过用户手册的编制，可以验证功能需求、项目范围、异常流程需求、环境与约束需求。利用跟踪关系，通过判断正向流程“业务需求用户需求系统需求”和反向流程“系统需求用户需求业务需求”，在正向流程中，如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。在反向流程中，如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。这样就可判断需求规格说明文档是否存在不完备的缺陷以及哪些需求属于非必要的需求。5. 需求管理软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不

15、确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：需求的描述问题；需求的完备程度问题；需求开发的工期问题；需求的细致程度问题；需求的变化问题；软件需求的复用问题。基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用。需求管理的主要工作包括维护需求基线、实现需求跟踪、控制变更三个部分。维护需求基线时，要充分了解涉众需要什么，完成驱动设计和实现工作，并测试和验证最终产品，辅助项目管理。在实现需求跟踪时，要

16、将需求应用到解决方案，并将需求分配到子系统，避免在开发过程或者演化过程中与需求基线不一致或者偏离的风险。在控制变更时，要控制迭代式开发中的变化。控制需求变更要注意以下几点：（1）需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一点，需求变，软件开发的投入也要变。（2）小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，人为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。（3）精确的需求与范围定义

17、并不会阻止需求的变更。并非对需求定义的越细，就越能避免需求的变更，这是两个层面的问题。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。（4）注意沟通技巧。实际情况是用户、开发者都认识到了上面几点问题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。6.小结 需求在软件产品的整个生存期中占有重要位置，它是软件工程项目的依据和出发点，无论是软件的开发还是软件的维护都是以满足需求作为最终目标的。所以，要特别提升需求获取、需求建模、需求规格说明、需求验证、需求管理的重要性，使得经过这几个阶段的工作，能对软件的需求把握的更清晰、更准确，使开发出的软件更好地满足客户的要求。参考文献1周之英.现代软件工程M.北京：科学出版社,20002Soren Lauesen著.刘晓辉译.软件需求M.北京：电子工业出版社,20023卢梅,李明树.软件需求工程方法及工具评述J.