需求工程概述

张友生

　　软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。　　需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。　　需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需求工程(requirementengineering,RE)。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，并开始开展工作。　　需求工程基本内容需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。　　需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。80年代，HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。近来，MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证。　　综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：　　（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；　　（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；　　（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；　　（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；　　（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。

文档的管理和维护

我有话说……

　　在整个软件生存期中，各种文档作为半成品或是最终成品， 会不断地生成、修改或补充。为了最终得到高质量的产品，达到上 节提出的质量要求，必须加强对文档的管理。以下几个方面是应注意做到的： 　　①软件开发小组应设一位文档保管人员，负责集中保管本 项目已有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续，办理借阅。 ②软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。这些一般都应是主文本的复制件，并注意和主文本保持一致，在作必要的修改时，也应先修改主文本。　　③开发人员个人只保存着主文本中与他工作相关的部分文档。 　　④在新文档取代了旧文档时，管理人员应及时注销旧文档。 在文档内容有更动时，管理人员应随时修订主文本，使其及时反映更新了的内容。 　　⑤项目开发结束时，文档管理人员应收回开发人员的个人文档。发现个人文档与主文本有差别时，应立即着手解决。这常常是未及时修订主文本造成的。 　　⑥在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文本的修改必须特别谨慎。修改以前要充分估计修改可能带来的影响，并且要按照：提议、评议、审核、批准和实施等步骤加以严格的控制。

软件质量评价标准

我有话说……

　　我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的三种不同倾向或观点。这三种倾向是：产品运行、产品修改和产品转移。信息系统作为一个产品，也可以参照这三种倾向来定义。

我们可以采取以下步骤实施全面质量控制： 1．实行工程化开发 　　“信息系统开发方法”一词的广义理解是“探索复杂系统开发过程的秩序”；狭义理解是“一组为信息系统开发起工具作用的规程”，按这些规程工作，可以较合理地达到目标。规程由一系列活动组成，形成方法体系。信息系统是一项系统工程，必须建立严格的工程控制方法，要求开发组的每一个人都要遵守工程规范。 2．实行阶段性冻结与改动控制 　　信息系统具有生命周期，这就为我们划分项目阶段提供了参考。一个大项目可分成若干阶段，每个阶段有自已的任务和成果。这样一方面便于管理和控制工程进度，另一方面可以增强开发人员和用户的信心。 　　在每个阶段末要“冻结”部分成果，作为下一阶段开发的基础。冻结之后不是不能修改，而是其修改要经过一定的审批程序，并且涉及到项目计划的调整。 3．实行里程碑式的审查与版本控制 　　里程碑式审查就是在信息系统生命周期每个阶段结束之前，都正式使用结束标准对该阶段的冻结成果进行严格的技术审查，如果发现问题，就可以及时在阶段内解决。 　　版本控制是保证项目小组顺利工作的重要技术。版本控制的含义是通过给文档和程序文件编上版本号，记录每次的修改信息，使项目组的所有成员都了解文档和程序的修改过程。广义的版本控制技术称为软件配制管理，并已有功能完善的软件工具支持，如PVCS和Microsoft Visual SourceSafe。 4．实行面向用户参与的原型演化 　　在每个阶段的后期，快速建立反映该阶段成果的原型系统，通过原型系统与用户交互，及时得到反馈信息，验证该阶段的成果并及时纠正错误，这一技术被称为“原型演化”。原型演化技术需要先进的CASE工具的支持。 5． 尽量采用面向对象和基于构件的方法 　　面向对象的方法强调类、封装和继承，能提高软件的可重用性，将错误和缺憾局部化，同时还有利于用户的参与，这些对提高信息系统的质量都大有好处。 　　基于构件的开发又被称为“即插即用编程”方法，是从计算机硬件设计中吸收过来的优秀方法。这种编程方法是将编制好的“构件”插入已做好的框架中，从而形成一个大型软件。构件是可重用的软件部分，构件既可以自己开发，也可以使用其他项目的开发成果，或者直接向软件供应商购买。当我们发现某个构件不符合要求时，可对其进行修改而不会影响其他构件，也不会影响系统功能的实现和测试，就好像整修一座大楼中的某个房间，不会影响其他房间的使用。 6．全面测试 　　要采用适当的手段，对系统调查、系统分析、系统设计、实现和文档进行全面测试。 7．引入外部监理与审计 　　要重视信息系统的项目管理，特别是项目人力资源的管理，因为项目成员的素质和能力以及积极性是项目成败的关键。同时还要重视第三方的监理和审计的引入，通过第三方的审查和监督来确保项目质量。