● CMM4实践（第一章）---需求管理2发信人: detian (呵呵), 信区: SoftEng
标 题: CMM4实践（第一章）---需求管理2
发信站: BBS 水木清华站 (Sat May 3 01:38:54 2003)
1.2需求变更管理
对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是
不可避免的。这主要有以下几种原因：
1）软件所应用的外部环境发生变化；
2）随着用户对软件的熟悉和应用，又提出新的需求；
3）用户在开始时不能很全面的知道所需软件的功能。
因此，为了因应需求变化，必须做好准备和计划，当需求发生变化时，使项目仍然能够在
控制之下。一个有效的需求变更管理过程一般应包括以下几个步骤：
1）需求变更请求；
2）需求变更的影响分析；
3）项目计划调整；
4）需求变更确认。
实际的变更需求的执行跟踪常常由后面将要讲述的配置管理过程来实现。
在项目计划重新调整后，变更的需求从需求分析和规格化开始，重复到变更发生时已经
经过的过程，直到所有需求的实现可以同步进行。虽然一个有效的需求变更管理过程能够
有效的控制和实施某个需求变更，但是，多个变更过程作用于一个项目，一般都会产生不
容忽视的累积效应。比方说，在100个产品中的每个产品上发现了一个问题，我们可以说这
些产品有100个问题，但是如果在一个产品上发现了100个问题，却往往意味着该产品可能
隐含着更大的问题。对一个软件项目来说，也是一样的道理，过多的需求变更常常导致软
件结构凌乱、逻辑复杂。
1.3需求跟踪管理
对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被
实现。因此，一个比较好的方法就是建立一种跟踪机制来确认所有需求在每个阶段都被实
现，这就是所谓的“需求跟踪”。进行需求跟踪的一个简单的方法是建立一个映射，从需
求到设计，从设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。这
个映射常常可以用需求跟踪矩阵来实现。
我们把在项目启动前分配给该项目的需求称为“分配需求”（这些需求通常就是前面所
说的用户的原始需求），把经过需求分析并规格化之后的需求称为“软件需求规格”，于
是就可以建立一个分配需求到软件需求规格之间的映射，该映射反映了分配需求都被分解
到了哪些软件需求规格之中。具体可以采用（分配需求ID，软件需求规格ID）的形式。由
于通常是一个分配需求被分解成多个软件需求规格，因此，实际中我们常常会得到形如下
面的映射：
分配需求ID 软件需求规格ID
r1 srs1
r1 srs2
r2 srs3
… …
也就是说，一个分配需求被映射到多个软件需求规格上。当然，根据需要也有多个分配需
求被映射到一个软件需求规格上的情况，但是，考虑到软件需求规格的简明性原则，应该
尽量避免这种情况。
当软件项目开始设计后，重点都全部集中在了软件需求规格上，接下来的工作就是来实
现所有的软件需求规格。我们以V模型（更加强调测试的瀑布模型）为例来说明在设计、编
码和测试过程中对软件需求规格的跟踪。典型的V模型结构包括这样几个阶段：需求规格阶
段，概要设计阶段，详细设计阶段，编码阶段，单元测试阶段，集成测试阶段，和系统测
试阶段。对应于需求规格要进行的测试活动是系统测试，系统测试的工作是来验证需求规
格中所有的功能和性能都按照特征要求被正确实现，于是可以建立一个软件需求规格到系
统测试用例的映射来反映哪些需求规格在那些系统测试用例里面测试。概要设计通常是根
据功能“独立分解”和“类似集中”的原则把大的系统进行模块分解，于是就可以建立一
个软件需求规格到各模块的映射来反映那些需求规格在那些模块里实现。对应于概要设计
要进行的测试活动是集成测试，集成测试的工作是要验证数据能够在各模块间能够正常的
流动，于是也可以建立软件需求规格到集成测试用例的映射来反映哪些需求规格在那些集
成测试用例里面测试。详细设计是设计最小的功能单元来实现各模块的功能，这些功能单
元通常一个个的函数或过程，于是可以建立一个软件需求规格到功能单元的映射来反映哪
些需求规格在那些功能单元里实现。对应于详细设计要进行的测试活动是单元测试，单元测
试的工作是来验证每个功能单元的逻辑都是正确的，于是也可以建立一个软件需求规格到单
元测试用例的映射来反映哪些需求规格在那些单元测试用例里面测试。编码就是把详细设计
中的每个功能单元用代码实现。于是，我们可以用格式（分配需求，软件需求规格,系统测
试用例，概要设计，集成测试用例，详细设计，单元测试用例，代码）来形成最终的需求跟
踪矩阵。下表是一个典型的需求跟踪矩阵样例。下表是一个典型的需求跟踪矩阵样例。
分配需求 软件需求规格 系统测试例 概要设计 集成测试例 详细设计 单元测试例 代码
R1 Srs1 Stc1 Mod1 Itc1 Unt1 Utc1 Cod1
Utc2
Stc2 Itc2 Unt2 Utc3 Cod2
Stc3 Unt3 Utc4 Cod3
Utc5
R1 Srs2 Stc4 Mod1 Itc3 Unt4 Utc6 Cod4
Utc7
Stc5 Unt5 Utc8 Cod5
R2 Srs3 Stc6 Mod1 Itc4 Unt6 Utc9 Cod6
Stc7 Itc5 Utc10
Itc6
R3 Sts4 Stc8 Mod2 Itc7 Unt7 Utc11 Cod7
Unt8 Utc12 Cod8
… … … … … … … …
，Srs3在模块Mod1中实现并且被集成测试用例Itc4、Itc5和Itc6测试，Srs3在功能单元Un
t6种实现并且被单元测试用例Utc9和Utc10测试，最后Srs3在代码Cod6种实现。因此，可以
看出，采用这样一个表格可以很方便跟踪哪些需求有没有实现以及在哪里实现。
到这里为止，我们已经把需求管理的工作都阐述完了。
--
※ 修改:·detian 於 May 3 01:43:51 2003 修改本文·[FROM: 211.149.96.200]
1.2需求变更管理
索引页面|上一篇|下一篇
[返回] 计算机科学论坛 →
计算机技术与应用 → 『 软件工程论坛 』 → CMM4实践（第一章）---需求管理2
(订阅本版)
2004/9/23 1:22:00
新浪微博
CMM4实践（第一章）---需求管理2
