需求工程在中小型信息系统开发中的应用与研究
（杨卓群 贵州大学 计算机软件与理论专业 2009020750）
引言
需求工程是随着计算机的发展而发展的。在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与文护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需求工程(Requirement Engineering, RE)。
1. 需求工程
需求工程是系统工程的一个组成部分，之所以把它也称为“工程”，是强调它是一个系统的、协同的和反复的过程，是一个由客户、用户、系统设计、开发、实现和测试人员等众多风险承担人参与的复杂活动，涉及社会人们的认知、表达方式以及企业文化等众多领域的问题。
需求工程有以下三个主要任务：
① 需求工程必须说明软件系统将应用的环境及其目标，说明用来达到这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，也即要同时说明软件需要“做什么”和“为什么”需要做。
② 需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。
③ 由于不断变化的世界，因此需求工毕业论文http://www.youerw.com/ 程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。
需求工程为了完成其任务，需求执行一系列的任务，如下图1-1所示。
图1-1需求工程基本活动
需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求验证、需求分析和需求规格说明4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在需求开发活动之后，保证所确定的需求能够在后继的项目中有效地发挥作用，保证各种活动的开展都符合需求要求。
需求获取的过程就是通过需求调研,获得清晰、准确的需求。是开发者和客户对项目中描述的客户需求的普遍理解。需求调研应尽可能做得全面细致,可以对即将要实现的业务有深刻的了解,帮助我们更好地理解系统功能,清楚新老系统之间的差别,同时,在设计上也可以将系统做得更加灵活,提高系统的可扩充性。
需求分析的过程就是将收集到的调研信息加以处理并理解它们。进行需求分析时，尽量理解用户所表达他们需求的思文过程，充分研究用户执行任务时做出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。为了更好的与用户交流,最初的屏幕构思有助于描述开发人员对需求的理解，这有助于对需求达成共识，为以后的设计工作带来便利。
需求开发的最终成果是形成一份经客户和开发小组对将要开发的产品达成一致的协议，也就是我们所说的需求规格说明书。需求规格说明书综合了业务需求、用户需求和软件功能需求。此文档是从包含用户需求的使用实例派生出来的功能需求文档，同时增加描述产品的非功能性方面的需求，包括质量属性和外部接口需求。
需求验证是需求开发中的最后一个活动。需求规格说明书完成后，并不能说已经完成了需求分析阶段的工作，可以进入设计阶段了，只有以结构化和可读性方式编写完这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的，这个阶段工作才告完成。
需求管理是对需求开发所建立的需求基线的管理，它在需求基线完成之后正式开始，并在需求工程阶段结束之后继续存在，在设计、测试、实现等后继的软件系统开发中保证需求作用的持续、稳定发挥。它的主要工作室跟踪后继阶段中的需求实现与变更情况，确定需求得到了正确的理解并被正确地实现到了软件产品中。
2. 信息系统开发
2.1信息系统需求过程
信息系统开发过程中需求分析阶段的七个关键过程：确定系统目标、明确用户需求、形成用户需求报告、设计系统界面、设计逻辑模型、完成系统需求说明书和形成文档。
需求分析阶段是信息系统开发过程中的重要一步,也是决定性的一步。需求分析的任务是明确系统开发目标,明确用户的信息需求,提出系统的逻辑方案。需求分析阶段应对系统进行全面、系统、详细的调查,明确系统目标,收集数据和对数据的要求,确定用户的需求并把这些要求写成文档,对该文档的内容,用户和系统设计者都能接受。需求分析是对客观系统不断认识和逐步细化描述的过程,细化到可以对软件工作域进行详细定义的程度。
信息系统工程项目需求管理的对象是项目需求，项目需求是“在信息系统开发过程的中
指明必须实现什么的规格说明。它描述了信息系统的行为、特性，是在开发过程中对系统的
约束。”需求定义了信息系统必须具有的能力，一个项目的成功与否往往取决于它是否符合一系列的需求。所以，探讨需求的确切含义，把它们写下来、组织起来、跟踪它们的变更就显得非常有意义了，由此将需求管理定义为:一个为信息系统的需求进行启发、组织、建档的系统方法，一个建立和文护用户和项目团队之间关于变更系统需求所达成的一致性过程。整个信息系统工程项目需求过程包括需求获取、需求分析和需求管理三个部分:
图2-1 需求工程的需求过程
图2-1 信息系统工程项目需求过程的内容
2.2 信息系统需求管理简述
下面对信息系统中需求管理中的一些关键问题做一个简单介绍，具体需求管理的内容和研究方法在下一章重点讨论。需求管理包括在信息系统工程项目进展过程中文持需求约定集成性和精确性的所有活动。典型活动包括:
l)确定需求变更控制过程:确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的需求管理工具都能支持变更控制过程。
2)建立变更控制委员会(Change Control Board，CCB)：组织一个由项目风险承担者共同组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，评估它们，并对此评估做出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序。
3)进行需求变更影响分析:应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。
4)跟踪所有受需求变更影响的工作产品:当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而遗漏的相关联的需求变更问题，识别这种由于相互关联而产生的变更在需求变更的情况下是必须进行的。
5)建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
6)文护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。版本控制是需求管理的重要方面之一，开发组的每一个成员必须能够得到需求的当前版本，必须清楚地将各种需求变更写成标准文档，并能够及时通知相关的人员，为了尽量减少困惑、冲突和误传，应该指定专门的人来更新需求。
7)跟踪每项需求的状态:建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性和状态，这样在任何时候都能得到每个状态类的需求数量。
8)衡量需求稳定性:记录基准需求的数量和每周或每月的变更(添加、修改、删除)数量。过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚、项目范围并未很好地确定下来或是政策变化较大。
9)使用需求管理工具：商业化的需求管理工具能在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它信息系统开发工作产品间建立跟踪能力联系链。1758