| p; |
|
1 |
|
1 |
|
|
| 需求 |
收益 |
代价 |
价值 |
价值% |
成本 |
成本% |
风险 |
风险% |
优先级 |
| <需求> |
<1-9> |
<1-9> |
<> |
<> |
<1-9> |
<> |
<1-9> |
<> |
<> |
其中各权值按实际情况而定，不能确定按1取值。
收益：实现此需求对用户的益处；
代价：未实现此需求对用户的损害；
价值=收益*收益权值+代价*代价权值
价值%=价值/（总价值）*100%
成本：实现此需求所需的各种成本；
成本%=成本/（总成本）*100%
风险：实现此需求所承担的风险，特别是技术上的；
风险%=风险/（总风险）*100%
优先级=价值%/（成本%*成本权值+风险%*风险权值）
最后按需求优先级排序，优先实现高优先级的需求。
风险的控制和避免：
对需求将可能面临的风险要有充分的估计并尽量避免风险的发生及其所造成的损失。建立风险跟踪，保持对危害最大的几项风险的控制，并在开发过程中周期性地更新风险跟踪项目。
需求的问题，是一个管理的问题
需求取得：市场销售部门、技术支持或客户服务所得到的需求，或者开发人员内部通过对业务的分析归纳得出的一些要改进的功能。
对需求进行管理的环节应该尽可能精简。最好直接由系统分析来做。经过很多环节的筛选，需求可能已经走样了。纸面上只有一两句话的需求，背后有你看不到的真正想法存在。 所以应该主动走出去寻找需求，应该选择最典型的客户进行访问。领会他们的管理思路和改革方向。
需求决策：对于相互矛盾的需求，在同类用户中由产品代表决策；对于不同类用户要根据重要性作适当折衷；对于用户的特别喜好要根据用户的重要性决定；用户中领导的需求要服从最终实际使用的用户需求；当开发者想象中的产品通常要服从用户的需求，但并不表示用户总是对的。
需求分析：分析需求的各个特性，制作出需求分析规格说明书。
需求评审：由相关人员共同对需求进行评审。
需求变更：如果遇到需求的变更，需要及时作出调整，即使与开发部门联系，提出变更的建议，并分析可能产生的影响，如对产品稳定性的影响。变更的需求需要严格的测试。
版本控制：确定需求文档版本，确定单个需求文档的版本；
需求跟踪：需求的跟踪记录需求的状态，包括未定义、放弃、需完善、已定义、实现中、待测试、测试中、完成、放弃实现等
需求管理工具：曾经看到过的工具有Rational Requsite Pro 4.5版。需要用Word 97支持。但对中文的支持不够好。
笔者对Requsite Pro4.5的功能进行了整理。请在本站点的ROSE工具栏目中寻找该文。
笔者也制作了一个IE版的需求管理工具，使用了ASP/Access2000。特点是和客户管理联系在一起。提供了对需求各属性的描述，也提供了对每一条需求的讨论和跟踪。这是一个1.0 Beta版的，刚开始使用的东西。
以上标题的结构，有些象一首歌的主题，其实还真有这么一首歌，叫做《三儿的问题》，不想被我改编了一下，遂成为：
需求的问题，是简单的问题，
需求的问题，是复杂的问题，
需求的问题，是技术的问题，
需求的问题，是管理的问题，
需求的问题，是你们的，我们的，
他们的，大家的问题。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
