● CMM4实践（第一章）---需求管理1发信人: detian (呵呵), 信区: SoftEng
标 题: CMM4实践（第一章）---需求管理1
发信站: BBS 水木清华站 (Fri May 2 02:27:46 2003)
第一章 需求管理
需求管理的目的是要在客户和软件项目之间建立一个对将要实现的需求的共同理解，它
主要是建立和维护一个与客户一致的对软件需求理解的协议。这个协议的内容就是我们经
常所说的分配给软件项目的系统需求，也称为“分配需求”。它包括了技术需求和非技术
需求（例如，交付日期等），而且在整个软件生命周期中是该项目估计、计划、运行和跟
踪项目活动的基础。对于一个软件项目来说，这里所说的客户可以是公司内部的系统工程
组、市场部，或者内部的其他组织，当然，外面的用户自然也是一个重要的客户。
要很好的完成一个软件项目，在项目开始之前，需要对系统需求进行仔细的分析以明确
化；当分配需求发生变更后，必须对变更可能带来的影响进行仔细评估，并根据需要重新
调整计划；在项目进行过程中，要对需求进行跟踪以保证所有需求都已实现。因此，与需
求管理相关的活动主要是：需求分析和规格化，需求变更管理，以及需求跟踪管理。
1.1需求分析和规格化
对一个软件项目来说，明确的需求是项目成功的基础。从项目开发的角度来说，只有需
求明确了，才能够确定该软件到底要实现什么功能，然后在软件设计时才能充分考虑到如
何进行软件结构设计。从项目管理的角度来说，明确的需求是做好项目计划的依据。做项
目计划时，需要根据要实现的需求来估计软件的规模和工作量，然后参照一定的标准来估
计项目的预算、进度和质量目标等。如果需求不明确，必然导致不合理的项目计划，那么
就无法保证该项目能够按照计划完成。
我们的开发人员常常犯这样一个错误：当用户提出一个需求时，不是去全面地分析用户
到底要求我们做什么，而是不停地讨论该怎么做；等讨论清楚了，时间也过了不少了，然
后开始设计编码，这时又会发现原来还有很多东西没有确定下来（例如，特殊情况如何处
理，错误或异常如何处理，以及可能引起异常的逻辑如何处理，等等）；然后再回头跟用
户讨论，如果讨论结果导致修改太多还常常埋怨用户开始时没有把需求说清楚，如果找不
到用户或者讨论未果，就可能凭自己的感觉了。这样做的最终结果，不是软件修修补补、
进度一拖再拖、BUG到处都是，就是发现费了很大功夫做出来的东西根本不是用户想要的。
因此，对一个软件项目来说，首要的任务就是在项目开发初期把用户的需求明确下来。
把用户的需求明确化，就是需求分析的任务。明确化的目标是，针对每一个用户需求，
充分挖掘可能存在的潜在需求，最终做到不模糊、没有遗漏。
最初，用户提出的需求，或者是我们从用户那里收集来的需求，常常只是些整体上的功
能需求。比如说，对一个计费系统，用户可能提出要实现认证功能，或者不实现认证功能
，也可能要求系统允许配置是否支持认证功能，但是不管怎样，用户只是要我们实现认证
功能，而没有要求我们实现什么样的认证功能（比如，是否加密认证等）。再比如，用户
要求一个计费系统实现计费打折功能，同样是没有说明到底如何打折（比如，是否可以打
0折，或者-1折等）。这些需求都是不明确的。但是这些原始需求的不明确性也是不可避免
的。这主要是由以下几个原因造成的：
1）用户最初的需求只是一种愿望的表现，希望能够实现某种功能，至于这种功能到底是什
么样的，用户自己可能都不清楚；
2）用户不清楚所要求的功能的详细信息，因此在提出需求时没有对某些细节作出明确的约
定；
3）用户不清楚各需求之间的互相关系，因此无法提供各需求之间逻辑上的约束。
面对这些不明确的原始需求，如何才能把它明确化呢？我们可以采取很多种方法，比如说
，参考类似项目，和用户交流，与有相关经验的人员讨论等。但是，如果没有一个连贯而
严密的思路，想到哪儿问到哪儿，常常会丢东落西，而且得到的需求也难免缺乏逻辑性。
用这样的需求去指导一个项目的开发，那就只能说该项目充满不可预见性。既然如此，怎
样才能比较有条理的分析用户的原始需求呢？根据我们的项目经验，得出了一个十分有效
的需求分析方法：
1）用户提出需求，是要求我们为用户“做什么”。例如，前面所说的用户要求实现打折功
能，要求我们做的事情就是：实现打折功能。
2）我们实现用户需求，要问用户“要我们实现的功能到底是什么样的？”。例如，我们应
该问用户“这个打折功能到底是什么样的？”。比如说，打折有没有时间限制？如果有时
间限制，用户的使用跨了打折区间该如何处理（比如，9:00-10:00打5折，用户9:30上网，
10:20下网，10点以后的20分钟是否也打折等）？是否允许打15（或者-1折，0折）？等等
。按照这种方式，我们还可以提出很多问题，而且这些问题无不对以后的实现有着重大的
影响。
3）分析各需求之间应该有一个什么样的关系。用户的很多需求常常是有一定的关系的。例
如，认证与计费两种功能，有些是先认证后计费，也就是说认证成功后才开始计费；而有
些不需要认证，直接开始计费过程；尤其是涉及到流程处理的需求，有些有时间上的先后
，有些有逻辑上的选择。诸如此类，都要求我们把这些关系分析明确，否则后面在软件设
计时就不知所措。
当然，要按照上面的思路把用户的需求明确化，就要求我们针对某个需求能够提出问题
，因此，如何提问题就显得比较重要了。东一点西一点的问，得到的只是些零散的东西，
一般情况下要对一个需求有个全面系统的理解，可以采用一些常用的思路，例如，由点到
面，逐步深入等。同时，要能够提出问题还要求我们对该需求可能包含的一些细节已经有
了一些了解，否则我们也提不出问题来。可以想象一下，如果要求一直从事农业劳动的人
实现一个热核反应的监控功能，他在明确化需求时能够向我们提出什么问题！因此，对一
个软件项目组来说，用户的需求可以作如下的分类：
1）用户不熟悉，但是软件项目组熟悉的；
2）用户熟悉，但是软件项目组不熟悉的；
3）用户熟悉，软件项目组也熟悉的；
4）用户和软件项目组都不熟悉的。
对于第一种需求，项目组成员可以依据自己的经验，按照上面的思路分析起来可以说是驾
轻就熟，因为项目组成员很清楚某个需求的哪些细节需要明确，所以给用户提问题也就是
很容易的事。对于第二种需求，项目组可以设法让用户把需求描述的尽可能的清楚，同时
项目组及时与有相关经验的人员加强交流，以提高自己对该需求的认识和分析能力；如果
实在没有别的办法，可以采用逆向思维的方式，多问用户“为什么要这样？”、“如果不
这样会怎么样？”之类的问题，这样在用户说明了很多问题之后，该需求自然也就明确了
。对于第三种需求，自然就不必多说了。对于第四种需求，可以从两个方面来分析：1）首
先，它可能是个创新性的应用，否则按照当前技术与应用发展的规律，不会出现这种跳跃
性的需求；对这种创新性的应用，是需要进行一定预研的，否则贸然分配给一个项目组去
实现它，是很不明智的；在经过预研之后，项目组对该需求有了初步的理解，再按照上面
的方法与用户一起来分析可能的细节，然后将其明确下来；2）其次，如果它不是什么创新
性的应用，那一定是把任务分配错了，可能是把该张三做的工作交给李四了。
通常情况下，用户的需求除了上面说过的功能需求外，还包括性能需求。所谓性能需求
，常常是要求系统在一定的条件下达到某种性能指标。例如，“对于一个中小型计费系统
，运行在CPU主频1.4G内存1G的PC服务器上，总用户量50万、在线用户数量2万的情况下，
要求每秒钟能处理200个请求包”，就是一个典型的性能需求。一般情况下，用户提出的性
能需求都是比较明确的。当然，如果有不明确的，也可以按照上面介绍的方法进行分析，
而且这类需求一般都比较简单明了。
可以说，上述方法对大多数的需求分析都是适用的，并且能够使项目组得到比较明确的
需求。但是，也有一类用户需求需要做些特别的处理。这类需求，对项目组来说常常是没
法提出问题，或者提出的问题不易描述。比如说，与用户交互的界面。这种需求，无论是
用户还是项目组都是用语言描述不清楚的。因此，常常采用先做原型的方式来逐步明确。
比如说，要完成某项配置，用户可能使用多个操作界面，在确定操作界面的内容和风格之
前，可以先做一个界面原型来征求用户的意见，然后再把它确定下来。这种做原型的方式
，在很多地方都可能用到，大家可以在实际开发中注意学习。
经过需求分析之后，我们对用户的需求已经比较明确了，接下来就把这些需求进行规格
化并写在文档里，这个文档通常称为“软件需求规格说明书”。对于什么是规格化，我们
可以举一个常用的例子。大家对电灯泡都比较熟悉，每个电灯泡上都有一个明确的描述来
说明该灯泡的使用特征，也常称之为灯泡的“额定规格”。例如“220V 60W”，它说明了
该灯泡在220付的交流电压下的发热功率为60瓦，它也同时说明只有在这个使用环境下才能
达到正常的效果。同样，对于一个软件需求来说，我们也应该对之进行一个明确的特征描
述，用来说明该需求应用在什么样的环境下以及有什么具体的特征要求。比如前面所说的
打折需求，我们应该描述它应用在什么情况下，以及具体怎么个打折法（对谁打折？可以
打0折，-1折，15吗？等等）。一个完整的“软件需求规格说明书”会包括很多方面的内容
，这里只说明与用户需求规格化有关的部分。对于一个用户需求，一般可以按照下面的格
式进行规格化：
1）介绍：详细描述该需求应用环境和特征要求；
2）输入：描述该需求的输入；
3）处理：描述该需求对按照要求对输入的处理；
4）输出：描述该需求的输入处理后产生的可能输出。
例如，前面用户要求的打折功能，用这个格式可以这样描述（不同的应用会有所不同）：
1）介绍：在计费过程中，打折功能指的是对用户的费用按照某种要求进行折扣计算，最后
得到一个打折后的费用。打折的计算公式为：打折后的费用=打折前的费用 * 折扣系数，
其中，0<=折扣系数<10，保留一位小数。打折有时间限制，只能在生效的时间范围内对用
户的费用进行打折计算，并且要保留打折前用户的费用。对于一次跨过打折有效时间范围
的使用，按照各时段进行分段处理。例如，每天的9:00-12:00打5折，如果用户使用时间为
8:30-13:00，则在计算用户费用时分成3段计算：8:30-9:00不打折，9:00-12:00打5折，1
2:00-13:00不打折。如果计算打折前的费用出现错误，把打折前和打折后的费用都置为-1
；如果只是打折后的费用出现错误（例如，折扣系数非法），则保留打折前的费用，把打
折后的费用置为-1。
2）输入：
a)正常运行的软件，配置好的用户信息和包含打折的计费方法；
b)一次用户的使用；
3）处理：
a)根据介绍的对用户本次的使用费用进行打折计算；
4）输出：
a)计费成功，输出“打折前的费用”和“打折后的费用”；
b)如果计算打折前的费用出现错误，都输出-1；
c)如果计算打折前的费用成功，而计算打折后的费用出现错误，输出“打折前的费用
”和-1。
通常情况下，在写作需求规格说明书的时候，用户的需求已经很明确了，尤其是那些项
目组已经有过相关开发经验的需求，甚至连如何实现都很清楚了。于是，规格化的时候如
何来描述用户需求的特征要求就成了一个值得讨论的话题了。我们始终应该明确一点，需
求规格是从软件外部来具体地描述该软件的特征，例如对一个需求点，我们要描述该需求
都有哪些输入，以及按照用户要求应该产生哪些输出，而不是描述软件处理输入数据的方
法和过程。首先，通常情况下，在需求阶段我们只知道用户要求什么而不知道用什么方法
来实现这些要求；其次，如果把一个不确切地实现方法写在了需求规格里，这既限制了以
后的具体实现（如果用户真的就要求按照需求规格里描述的方式实现，而该方式后来又被
证明是不正确的，那真是软件项目组自己给自己找麻烦！），事实上用户也根本不关心怎
么实现。因此，就像一个电灯泡的额定规格的描述一样，我们在写作需求规格的时候也只
描述经过需求分析得到的某个需求点的特征要求。（具体的例子就不举了）
在规格化完了之后，我们已经得到了完整明确的需求，但是，还有一点需要我们注意的
是：需求的可行性分析。虽然我们得到了明确的需求，但是这些需求是否都可行呢，在某
种特定的系统或语言环境下是否能够实现呢？比如说，用户要求我们在Linux下执行一个W
indows应用程序，我们可以把这个需求分析得很清楚（例如，要求的Linux的版本、执行的
方式、应用程序的功能和界面等等），但是最后却会发现该需求是不可实现的。因此，需
求分析还有一个很重要的任务就是可行性分析。
可行性分析的很多工作是考虑在某种条件下能否实现某个需求，这看起来好像与前面所
一个尺度：只从原理上分析是否可行，而不关注怎么实现。然而，要严格的区分有时候也
是比较困难的，因为为了证明该需求是否可行，可能不得不做很多工作来验证它，而这些
工作往往就是具体的实现。例如，我们的项目中有过这样的一个需求：用户要求从网页上
登录，登陆完成以后把IE窗口最小化到任务栏的右下角（有时也成为“托盘”）。因为我
们以前没有过这方面的经验，也从来没有注意到过IE窗口是否可以这样最小化，所以在需
求分析的时候，我们参阅了一些书籍，参考过类似项目，与有过这方面开发经验的人员交
流过，也编写过简单的代码进行试验。所有这些工作都与实现有关系，但是如果不进行这
些工作就确定不了该需求能否实现，如果把一个不能实现的需求写在了“软件需求规格说
明书”里，势必会严重影响项目的开发，而且到头来也没有满足用户的要求，这将是一件
非常糟糕的事情。因此，对于需求的可行性分析，针对不同的项目特点，还需要我们灵活
处理。
※ 修改:·detian 於 May 2 02:37:31 2003 修改本文·[FROM: 211.149.97.194]
需求管理的目的是要在客户和软件项目之间建立一个对将要实现的需求的共同理解，它
索引页面|上一篇|下一篇
[返回] 计算机科学论坛 →
计算机技术与应用 → 『 软件工程论坛 』 → CMM4实践（第一章）---需求管理1
(订阅本版)
2004/9/23 1:22:00
新浪微博
CMM4实践（第一章）---需求管理1
