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

大型软件工程中的需求管理及控制目录

摘要2前言2

1.术语解释3.需求过程参与人员角色及职责4

2.善于抓核心，抓主流程5.需求真伪的判断5

3.需求全景图5.软件开发中的需求分析与需求管理6

3.1.需求分析的过程6

6.2.需求的层次7

7.3.需求开发阶段的重点7

8.4.需求分析的任务8

9.5.注解：SRS格式87.需求开发与管理流程9

7.1.前述9

7.2.需求获取9

1.2.1.前述9

7.2.2.调查问卷9

7.2.3.访谈9

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

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

7.2.6.文档追溯（文档考古）10

7.2.7.需求讨论会10

7.2.8.原型法10

7.3.需求获取资料的保管10

7.4.编写用户需求规格说明书11

7.5.需求分析11

7.5.1.前述11

7.5.2.结构化分析方法11第1页共15页

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

对于一些较为复杂的流程和操作，是比拟难以用语言和文字进行表达的，可

以有针对性的采用到系统预期使用者及管理者的工作现场，一边观察，一边听其

讲解，从而更直观的了解其需求。

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

这种方法要求需求分析师有一定的行业从业经验及法律法规知识，能够了解

行业的开展动向，可以聘请业务专家、相关法律专家和业务骨干对需求分析师进

行集中培训和讲解，使之缩短提取需求时间，提高需求获取的准确性和效率。

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

需求获取人员通过对甲方业务和工作中已经归档的历史文档进行研究，其主

要的工作是对已经归档的携带了大量真实数据的文件、表单、报告和电子文档进

行分析，获取需要调研的信息。

7.2.7.需求讨论会

需求讨论会作为需求获取阶段的重要手段，一直都是在需求的中期后期来进

行，需要在获取到一定量的系统需求后，在召集甲方的关键业务人员和开发方的

需求分析人员、工程开发人员来进行需求讨论，并最终确定。

7.2.8.原型法

需要在很短的时间内完成的中小型软件系统，针对实际情况经常采用的是原

型法(prototype),即把系统主要功能、流程和数据项通过快速开发制作形成可视的

操作页面展示给系统预期使用者，并征求预期使用者意见，通过可视化的界面和

数据项快速确实定工程的实际需求。

7.3.需求获取资料的保管

根据所采用的需求获取方法，在需求获取过程中将产生不同的记录和原始资

料，工程组应将这些记录纳入开发库进行配置管理。需求获取的记录与资料包括

但不限于：用户编写的原始需求文档、用户填写的需求调查表、用户访谈的访谈

纪要、需求研讨会的会议纪要、相关的政策法规文件，业务规则文件以及行业标

准文件、需求原型。

第10页共15页4.编写用户需求规格说明书

需求获取人员在通过需求获取的各种方法获取的工程需求进行整理、分析和

记录，结合实际情况编写《用户需求规格说明书》，《用户需求规格说明书》作为

开发方与甲方的沟通性文档，需要具有以下特性：编写语言必须采用通俗易懂的

语言；术语性字眼必须加以解释；结构清晰，条理清楚，主次分明；需进行广泛的

意见征集。

主要内容应该包括但不局限于：系统总体介绍（背景、用途、用户群和系统特

征）；系统应遵循的业务规范和行业标准；业务流程；产品的功能性需求；产品的

非功能性需求。

建议针对工作量小于5人月的小型工程、使用了原型法获取需求的工程、没

有明确的目标使用者的工程、直接引用预期使用者提供的需求说明书的项目，可

以不用编制《用户需求规格说明书》。

7.5.需求分析5.1.前述

在需求获取后，对获取到的业务资料、访谈记录、意见汇总表和各讨论会会

议纪要进行整理和分析，并由甲乙双方的骨干人员进行需求分析工作，对其分散

获取的各项具体建立逻辑关系，明确软件类的需求，并对其进行分类，确定其需求

的优先级和重要程度等“

主耍的需求分析方法如下：

1052.结构化分析方法

结构化分析方法的主要特点是〃自顶向下、逐层分解〃，利用图形、表格等描

述方式表达需求，对需求问题进行分析，具体采用的工具有：DataFlowDiagram>Data

Dictionary〉E-R图、判定表和判定树、结构化语言。

结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法,

在具体的工程中，结构化分析方法的具体操作方式如下：

1）建立系统的物理模型；

2）建立系统的逻辑模型；

3）划清人机界限第11页共15页

7.5.3.基于用例的分析方法

基于用例的分析方法，主要是成熟度高，规模大和分工明确的开发公司进行

采用，针对大型的软件工程，开发方会根据获取的需求来形成可视化的程序实例，

模拟出系统的各项功能、使用流程和数据项，建立可.供需求分析的用例模型C

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

1）界定系统使用者；

2）分析整理需求形成用例；

3）形成用例图：

4）对用例进行详细描述。

7.6.需求定义

需求获取、分析完成后，工程组需要做的就是进行需求定义，需求定义主要是

根据需求获取和分析的结果，定义软件需求，形成《软件需求规格说明书》。

7.6.1.定义需求优先级

需求定义首先需要确认的是定义需求的优先级，在需求分析完成后，需要对

需求的优先级进行分析和定义，并预先制定优先级评价标准，在作者参与的工程

中，需求优先级的评价标准如下：

未取的m足

”下任,一戏手达鱼雷*在R3

i>K统。霞或现於.真功交爱H双中翕

C无法完火正彦s日常工佐红售处收收入贯支实收

：>sr«rf&<£«<£«.■我的

»・死己球打定力才邕

洞足以下任・一条tb0果项目芟*中也现

1）畲IMr■农.W正ITlkMEW不太n・♦力Err

中

J）变过这鱼雷束杵”■不蜿岸突rt.«ruHie«

3）臬皖4L悔阳要宏第下一质*

41足以下任・一条“，安理氏不实现均讦

彼PMMttlWfti

2）侵桑微里北••9千・上多瓦，

需求分析师在组织甲乙双方的工程骨干人员进行需求分析过程后形成《软件

需求规格说明书》

（其中包含《产品功能列表》）0编写需求规格说明书应遵循以下规则，确保需

求的完整性、确保需求的一致性、确保需求的正确性、确保第12页共15页

需求无二义性、确保需求易十追溯、确保需求的可测试性、确保需求的可行性。

7.7.需求确认

《软件需求规格说明书》编写完成后，需要工程的甲乙双方的工程骨干人员

及外部的业务专家共同进行需求确认，对《软件需求规格说明书》进行评审。需求

确认是需求阶段最重要的一个环节，但是往往又被工程的建设方所忽视，做好需

求确实认工作对整个工程的后续开发和顺利进行都觉有非常重人的意义，需求确

认的主要工作如下：

7.7.1.需求评审

需求评审即对前面产生的《用户需求规格说明书和》、《软件需求规格说明

书》进行评审，召开技术评审会议，组建评审小组，召集工程干系人、业务专家和

外部技术专家进行讨论，并对评审意见和结果进行记录，把评审意见和结果性的

东西合并到文档中，需指定严格的评审规范和流程。

大型的软件工程也可采用分段评审的方式来进行需求评审，即针对性的邀请

专家、业务骨干和系统预期使用者参加进行小规模的评审，降低需求返工的风险，

缩短需求评审的周期和事件，提高需求评审质量。

7.7.2.需求承诺

需求承诺作为需求确认的手段，开发方工程经理把评审通过的《软件需求规

格说明书》提交给甲方进行确认，主要包含以下确认方式：

1）直接签字：由甲方在《软件需求确认书》上直接签字或盖章确认，附件为

《软件需求规格说明书》。

2）邮件方式：由工程经理将《软件需求规格说明书》与评审报告通过邮件

发送给接收方，并明确确认通过的准则。

3）发送会议纪要函：如果甲方参加了评审会议并在会上达成了共识，那么可

以通过编制会议纪要，在纪要中写明参加评审的人员、评审的结论等，并让甲方签

字盖章确认。

不过作者根据多年的工程管理经验，强烈建议采用直接签字的方法进行需求

承诺确认。

第13页共15页7.7.3.建立需求基线

工程的《软件需求规格说明书》经过评审与确认后，应建立需求基线，并上传

到配置管理服务器保存版本以便后续需求变更后法行跟踪。

7.8.需求变更

一个大型的软件工程，具有周期长、功能复杂的特性，无论前期开发方和建设

方的需求多么明确，实际开发过程中的需求变更也是不可防止的。需求变更产生

的主要原因，作者分析如下：

1）系统开发过程中甲方的工作及业务流程发生变化;

2）前期需求获取时发生了偏差及错误；

3）使用者提出新的需求；

4）被调研者无法准确描述其所需要的系统功能；

5）法律法规或行业标准发生变化；

6）使用范围变化，对性能的要求重新进行界定。

需求变更在工程中的标准流程如下：

1）变更提出，变更申请人填写《需求变更申清单》；

2）工程经理召集工程相关人员进行讨论，决定是否接受变更；

3）通过变更管理规范来实施变更；

4）发布新的需求基线：

5）通知相关的人员。

8.9.需求跟踪

在大型的软件工程中必须建立一种需求跟踪机制，这种机制必须是双向的，

可追溯的。目前作者所接触到的根据需求的最有效和最普遍的需求跟踪方法是通

过映射的方法建立需求跟踪矩阵来实现。当需求通过评审并确认下来之后，工程

开发方需根据具体的系统需求编制《需求跟踪矩阵》，并指定需求负责人对需求跟

踪矩阵核查，保证需求跟踪矩阵的正确性、完整性。随着软件开发的进行，工程组

应专门指定专人维护需求跟踪矩阵，对已经变更了的需求进行及时更新，修改需

求跟踪矩阵各模块的对应关系，保证其完整性，正确性和一致性。

参考文献：

第14页共15页［1］邱苑华.现代工程管理导论［M］.北

京：机械工业出版社，2002.

⑵巴迪鲁.工程管理原理［M］.北京：清华大学出版社，2003.

⑶［美］罗伯特.K.威索基拉德.麦加里.有效的工程管理［M］.费琳，李盛萍，

等.译.北京：电子工业出版社，2004.

［4］张家浩,软件工程管理［M］.北京：机械工业出版社，2005.

［5］施瓦尔贝.IT项日管理［M］.北京：机械工业出版社，2004.

［6］罗运模，谢志敏.CMMI软件过程改进与评估［M］.北京：电子工业出版社，

2004.

［7］］美］DennisM.Ahem,AaronClouse,RichardTurner.CMMI精粹一集成化过

程改进实用导论［M］.北京：清华大学出版社，2005.

［8］吴明珠，徐俊.基于CMMI的需求工程实施方法研究［几软件导刊，2009⑴.

［9］李世蓉，黄福珠.浅议工程建设工程中的采购信息管理口］.重庆工学院学报:

自然科学版,2006(9).

第15页共15页

7.5.3.基于用例的分析方法12

7.6.需求定义12

1.6.1.定义需求优先级12

7.6.2.编写《软件需求规格说明书》12

7.7.需求确认13

7.7.1.需求评审13

7.7.2.需求承诺13

7.7.3.建立需求基线14

7.8.需求变更14

7.9.需求跟踪14参考文献：14

摘要

根据作者所在单位软件系统开发过程中，针对需求管理及控制中遇到的一些

问题进行了较深入的研究和论述，形成了比拟系统的软件工程需求管理及控制的

基本流程和方法，借鉴及整理了目前国际上比拟成熟和先进的需求开发及管理经

3佥和成果。

关键词：大型软件工程；需求获取；需求分析；确认；变更；跟踪；整体管理

-i-Zl-

刖百

本文通过作者多年从事大型软件工程管理的经验，从甲方的角度定义和论述

大型软件在需求过程中的一些过程及规范，并通过规范需求过程的步骤及方法来

到达缩短开发周期、降低软件开发本钱和提高软件质量的目的，并且通过需求分

析工作，定义分析方法把《用户需求》转化为《软件需求》，同时利用科学的方法

评审需求的正确性，防止需求的随意性，在工程初期即获得需求双方的承诺；控制

需求的变更，并确保软件系统工程工作产品与需求的一致性。

在一个大型软件系统的开发中，需求分析之所以重要，就因为它具有决策性，

方向性，策略性的作用。它在软件开发的过程中具有举足轻重的地位，它的作用要

远远大于程序设计。它是剖析业务场景、流程，挖掘用户痛点，直面现状问题，提

供解决方案，实现业务价值。今天我们就来谈谈需求分析。

第2页共15页

1.术语解释

软件需求：在IEEE软件工程标准词汇表（1997年）中定义软件需求为：

1）用户解决问题或到达目标所需的条件或能力。

2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的

条件或能力。

3）一种反映上面1）或2）所描述的条件或权能的文档说明。通俗地讲，“需

求〃就是用户的需要，它包括用户要解决的问题、到达的目标以及实现这些目标所

需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

用例：是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的

价值结果，一个用例定义了一组用例实例。

需求分析：是指在需求开发过程中，对所获取的需求信息进行分析，及时排

除错误和弥补缺乏，确保需求文档正确地反映用户的真实意图。需求分析的关键

就是对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推荐的

做法就是对问题域进行抽象，将其分解为假设干基本元素，然后对元素之间的关

系进行建模。

百度百科对需求分析的定义：需求分析称为软件需求分析、系统需求分析或

需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和工程

的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定

义，从而确定系统必须做什么的过程。

需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节,

该阶段是分析系统在功能上需要“实现什么〃，而不是考虑如何去“实现〃。需

求分析的目标是把用户对待开发软件提出的〃要求〃或〃需要”进行分析与整理，

确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些

工作。此外，软件的一些非功能性需求（如软件性能、可靠性、响应时间、可扩展

性等），软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目

标。

第3页共15页

需

求

分

肝

亦嫁

工斐然

、b编

与综合

题分析

、问

调研

业务

段：

个阶

为四

以分

作，可

的工

阶段

分析

需求

经过

求是

些需

么，这

是什

需求

户的

解用

要了

先是需

分析首

。需求

评审

说明、

利规格

功能

与非

能性

足功

应满

发中

件开

，在软

到的

组得

行重

再进

析，

研、分

的调

场景

业务

：

程是

个流

析。这

行分

程进

业流

个专

过一

以通

，可

设计

产品

求到

挖掘需

求，从

性