近年来,信息系统项目的规模越来越大,复杂度越来越高。由于管理上的失误给人们的教训也越来越深刻。需求管理、配置管理、项目范围管理对于信息系统项目管理而言,都具有举足轻重的地位。澄清这些基本概念的含义,分析相互间的联系与区别以加深大家的理解,对规范和促进软件项目管理工作意义不小。
1 需求管理
1.1 需求管理概述
信息系统项目中的需求管理RM(Requirements Management)包括确保所有项目干系人对需求的一致理解;管理和控制需求的变更;从需求到最终产品的双向跟踪。词汇“需求管理”可以理解为对“需求”实施“管理”的活动或过程。
“需求”在IEEE软件工程标准词汇表(1997年)中定义为:
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
(3)一种反映(1)或(2)所描述的条件或权能的文档说明。
与传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性等特点,软件的需求不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件项目最难把握的问题。
软件需求包括业务需求、用户需求和功能需求(含非功能需求)。业务需求(Business Requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。用户需求(UserRequirement)文档描述了用户使用产品必须要完成的任务,这在使用实例(Use Case)文档或方案脚本(scenario)说明中予以说明。功能需求(Functional Requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。
CMM的第二级(可重复级)中将需求管理作为六个关键过程域的一个,因为它实际上是二级引入到开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下,软件开发才能以一种有计划和有序的方式进行。实际上,没有文档化的需求,在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级的其他关键过程域中涉及的原则,都是从一个稳定的基础开始的,那就是文档化的需求基线。
1.2 需求管理、需求分析与需求工程
需求分析RA(Requirements Analysis)指深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统元素的接口细节,定义软件的其他有效性需求。RA的基本任务是准确地回答“系统必须做什么?”这个问题。需求分析的目的是对各种需求信息进行分析并抽象描述,为目标系统建立一个概念模型。区分需求管理和需求分析是很重要的。
需求工程RE(Requirements Engineering)是指应用已被证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征。RE是80年代中期逐步形成的软件工程子领域。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。RE包括所有与需求直接相关的活动,RE的活动可以分为需求开发和需求管理两大类。RE也可以进一步细分为系统需求工程(如果是针对由软硬件共同组成的整个系统)和软件需求工程(如果仅是专门针对纯软件部分)。
从完整意义上讲,RE包括需求获取、需求分析、需求定义、需