大型软件项目中的需求管理及控制

徐 龙

(重庆市公安局交通管理局科研所，重庆 400074)

1 论文概述

本文通过作者多年从事大型软件项目管理的经验，从甲方的角度定义和论述大型软件在需求过程中的一些过程及规范，并通过规范需求过程的步骤及方法来达到缩短开发周期、降低软件开发成本和提高软件质量的目的，并且通过需求分析工作，定义分析方法把《用户需求》转化为《软件需求》，同时利用科学的方法评审需求的正确性，避免需求的随意性，在项目初期即获得需求双方的承诺；控制需求的变更，并确保软件系统项目工作产品与需求的一致性.

2 术语解释

软件需求:在IEEE软件工程标准词汇表(1997年)中定义软件需求为:(1)用户解决问题或达到目标所需的条件或能力.(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力.(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明.通俗地讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式.

用例:是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的价值结果，一个用例定义了一组用例实例.

需求分析:是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图.需求分析的关键就是对问题域的研究与理解.为了便于理解问题域，现代软件工程方法所推荐的做法就是对问题域进行抽象，将其分解为若干基本元素，然后对元素之间的关系进行建模.

3 需求过程参与人员角色及职责

在大型软件项目中的需求过程中，明确角色及职责，界定在需求过程中各角色人员的具体工作和范围是非常重要的，根据作者本人所在单位的软件建设过程和系统特点，在软件需求过程中按照单位的职责划分分为如下角色及职责:

项目总负责人:负责项目的需求评审及确认，并担任需求评审小组的组长；

项目经理:负责组织单位各部门配合项目进行需求调研，并对项目进行需求分析和管理工作；

需求分析师:负责需求的获取，分析以及定义

评审小组:接受需求评审申请，组织进行需求的评审CM工程师:负责需求基线变更的维护.

4 需求开发与管理流程

大型软件项目的需求管理阶段的主要活动包括:需求确认，需求变更和需求跟踪控制三大部分，下面作者结合本单位软件项目需求管理及控制阶段，详细的论述需求获取、变更和控制这三大部分理论与实际的结合应用.

图1 需求开发与管理过程活动示意图

4.1 需求获取

作为甲方的项目管理人员必须做好需求获取前的计划审核及协调工作，良好的开端是项目成功的基础，编制需求计划具有以下几个要素.

1)明确需要获取的信息是什么(What)

2)明确需要获取信息来自于什么地方(Where)

3)明确获取需求的方法(How)

需求获取的方法主要有以下几种，各有利弊.

A.调查问卷

需求获取方根据对甲方业务学习情况和具体工作情况的学习结合实际情况设计需求问题形成调查问卷，然后下发到具体的被调研人员手中，填写答案来进行需求获取.

B.访谈

访谈分为两种形式，问题列表访谈，即有提前准备好访谈的问题，有问有答式的进行访谈，并记录好访谈结果，形成访谈问答式的访谈记录.提纲开放式访谈，即准备一个大致的访谈提纲和粗略的方向，根据被访谈人的具体情况进行调整.但是在实际的情况中，往往是这两种访谈模式相结合才能更加灵活、有效地进行需求的有效访谈.

C.现场观摩工作流程，观察实际操作

对于一些较为复杂的流程和操作，是比较难以用语言和文字进行表达的，可以有针对性的采用到系统预期使用者及管理者的工作现场，一边观察，一边听其讲解，从而更直观的了解其需求.

D.从法律法规、行业标准、业务规则中提取需求

这种方法要求需求分析师有一定的行业从业经验及法律法规知识，能够了解行业的发展动向，可以聘请业务专家、相关法律专家和业务骨干对需求分析师进行集中培训和讲解，使之缩短提取需求时间，提高需求获取的准确性和效率.

E.文档追溯(文档考古)

需求获取人员通过对甲方业务和工作中已经归档的历史文档进行研究，其主要的工作是对已经归档的携带了大量真实数据的文件、表单、报告和电子文档进行分析，获取需要调研的信息.

F.需求讨论会

需求讨论会作为需求获取阶段的重要手段，一直都是在需求的中期后期来进行，需要在获取到一定量的系统需求后，在召集甲方的关键业务人员和开发方的需求分析人员、项目开发人员来进行需求讨论，并最终确定.

G.原型法

需要在很短的时间内完成的中小型软件系统，针对实际情况经常采用的是原型法(prototype)，即把系统主要功能、流程和数据项通过快速开发制作形成可视的操作页面展示给系统预期使用者，并征求预期使用者意见，通过可视化的界面和数据项快速的确定项目的实际需求.

4)需求获取资料的保管

根据所采用的需求获取方法，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理.需求获取的记录与资料包括但不限于:用户编写的原始需求文档、用户填写的需求调查表、用户访谈的访谈纪要、需求研讨会的会议纪要、相关的政策法规文件，业务规则文件以及行业标准文件、需求原型.

4.2 编写用户需求规格说明书

需求获取人员在通过需求获取的各种方法获取的项目需求进行整理、分析和记录，结合实际情况编写《用户需求规格说明书》，《用户需求规格说明书》作为开发方与甲方的沟通性文档，需要具有以下特性:编写语言必须采用通俗易懂的语言；术语性字眼必须加以解释；结构清晰，条理清楚，主次分明；需进行广泛的意见征集.

主要内容应该包括但不局限于:系统总体介绍(背景、用途、用户群和系统特征)；系统应遵循的业务规范和行业标准；业务流程；产品的功能性需求；产品的非功能性需求.

建议针对工作量小于5人月的小型项目、使用了原型法获取需求的项目、没有明确的目标使用者的项目、直接引用预期使用者提供的需求说明书的项目，可以不用编制《用户需求规格说明书》.

4.3 需求分析

在需求获取后，对获取到的业务资料、访谈记录、意见汇总表和各讨论会会议纪要进行整理和分析，并由甲乙双方的骨干人员进行需求分析工作，对其分散获取的各项具体建立逻辑关系，明确软件类的需求，并对其进行分类，确定其需求的优先级和重要程度等.

主要的需求分析方法如下:

1)结构化分析方法

结构化分析方法的主要特点是“自顶向下、逐层分解”，利用图形、表格等描述方式表达需求，对需求问题进行分析，具体采用的工具有:Data Flow Diagram、Data Dictionary、E-R图、判定表和判定树、结构化语言.

结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法，在具体的项目中，结构化分析方法的具体操作方式如下:

A.建立系统的物理模型；B.建立系统的逻辑模型；C.划清人机界限

2)基于用例的分析方法

基于用例的分析方法，主要是成熟度高，规模大和分工明确的开发公司进行采用，针对大型的软件项目，开发方会根据获取的需求来形成可视化的程序实例，模拟出系统的各项功能、使用流程和数据项，建立可供需求分析的用例模型.

使用用例分析方法时可遵循以下步骤:

A.界定系统使用者；B.分析整理需求形成用例；C.形成用例图；D.对用例进行详细描述.

4.4 需求定义

需求获取、分析完成后，项目组需要做的就是进行需求定义，需求定义主要是根据需求获取和分析的结果，定义软件需求，形成《软件需求规格说明书》.

1)定义需求优先级

需求定义首先需要确认的是定义需求的优先级，在需求分析完成后，需要对需求的优先级进行分析和定义，并预先制定优先级评价标准，在作者参与的项目中，需求优先级的评价标准如下:

2)编写《软件需求规格说明书》

需求分析师在组织甲乙双方的项目骨干人员进行需求分析过程后形成《软件需求规格说明书》(其中包含《产品功能列表》).编写需求规格说明书应遵循以下规则，确保需求的完整性、确保需求的一致性、确保需求的正确性、确保需求无二义性、确保需求易于追溯、确保需求的可测试性、确保需求的可行性.

4.5 需求确认

《软件需求规格说明书》编写完成后，需要项目的甲乙双方的项目骨干人员及外部的业务专家共同进行需求确认，对《软件需求规格说明书》进行评审.需求确认是需求阶段最重要的一个环节，但是往往又被项目的建设方所忽视，做好需求的确认工作对整个项目的后续开发和顺利进行都觉有非常重大的意义，需求确认的主要工作如下:

1)需求评审

需求评审即对前面产生的《用户需求规格说明书和》、《软件需求规格说明书》进行评审，召开技术评审会议，组建评审小组，召集项目干系人、业务专家和外部技术专家进行讨论，并对评审意见和结果进行记录，把评审意见和结果性的东西合并到文档中，需指定严格的评审规范和流程.

大型的软件项目也可采用分段评审的方式来进行需求评审，即针对性的邀请专家、业务骨干和系统预期使用者参加进行小规模的评审，降低需求返工的风险，缩短需求评审的周期和事件，提高需求评审质量.

2)需求承诺

需求承诺作为需求确认的手段，开发方项目经理把评审通过的《软件需求规格说明书》提交给甲方进行确认，主要包含以下确认方式:

直接签字:由甲方在《软件需求确认书》上直接签字或盖章确认，附件为《软件需求规格说明书》.

邮件方式:由项目经理将《软件需求规格说明书》与评审报告通过邮件发送给接收方，并明确确认通过的准则.

发送会议纪要函:如果甲方参加了评审会议并在会上达成了共识，则可以通过编制会议纪要，在纪要中写明参加评审的人员、评审的结论等，并让甲方签字盖章确认.

不过作者根据多年的项目管理经验，强烈建议采用直接签字的方法进行需求承诺确认.

3)建立需求基线

项目的《软件需求规格说明书》经过评审与确认后，应建立需求基线，并上传到配置管理服务器保留版本以便后续需求变更后进行跟踪.

4.6 需求变更

一个大型的软件项目，具有周期长、功能复杂的特性，无论前期开发方和建设方的需求多么明确，实际开发过程中的需求变更也是不可避免的.需求变更产生的主要原因，作者分析如下:

(1)系统开发过程中甲方的工作及业务流程发生变化；(2)前期需求获取时发生了偏差及错误；(3)使用者提出新的需求；(4)被调研者无法准确描述其所需要的系统功能；(5)法律法规或行业标准发生变化；(6)使用范围变化，对性能的要求重新进行界定.

需求变更在项目中的标准流程如下:

(1)变更提出，变更申请人填写《需求变更申请单》；(2)项目经理召集项目相关人员进行讨论，决定是否接受变更；(3)通过变更管理规范来实施变更；(4)发布新的需求基线；(5)通知相关的人员.

4.7 需求跟踪

在大型的软件项目中必须建立一种需求跟踪机制，这种机制必须是双向的，可追溯的.目前作者所接触到的根据需求的最有效和最普遍的需求跟踪方法是通过映射的方法建立需求跟踪矩阵来实现。当需求通过评审并确认下来之后，项目开发方需根据具体的系统需求编制《需求跟踪矩阵》，并指定需求负责人对需求跟踪矩阵核查，保证需求跟踪矩阵的正确性、完整性.随着软件开发的进行，项目组应专门指定专人维护需求跟踪矩阵，对已经变更了的需求进行及时更新，修改需求跟踪矩阵各模块的对应关系，保证其完整性，正确性和一致性.

[1]邱苑华.现代项目管理导论[M].北京:机械工业出版社，2002.

[2]巴迪鲁.项目管理原理[M].北京:清华大学出版社，2003.

[3][美]罗伯特.K.威索基拉德.麦加里.有效的项目管理[M].费琳，李盛萍，等.译.北京:电子工业出版社，2004.

[4]张家浩.软件项目管理[M].北京:机械工业出版社，2005.

[7]施瓦尔贝.IT项日管理[M].北京:机械工业出版社，2004.

[5]罗运模，谢志敏.CMMI软件过程改进与评估[M].北京:电子工业出版社，2004.

[6][美]Dennis M.Ahern，Aaron Clouse，Richard Turner.CMMI精粹—集成化过程改进实用导论[M].北京:清华大学出版社，2005.

[7]吴明珠，徐俊.基于CMMI的需求工程实施方法研究[J].软件导刊，2009(1).

[8]李世蓉，黄福珠.浅议工程建设项目中的采购信息管理[J].重庆工学院学报:自然科学版，2006(9).