MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">每个需求的特性可体现在很多方面：如优先级、有效性，效率，灵活性，完整性，互操作性，可靠性，健壮性，可用性；可维护性，可移植性，可重用性，可测试性等。
确定需求优先级：可以粗略地分为三级：
| 高 | 一个关键任务的需求，必须在此版本实现；只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现 |
| 中 | 支持必要的系统操作，最终所要求的，但如果有必要，可以延迟到下一版本；实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的；需要付出努力，但不必做得太完美 |
| 低 | 功能或质量上的增强，如果资源允许的话，实现这些需求会使产品更完美；实现或不实现均可；可以包含缺陷 |
更精确的优先级设定如下表：
| 权值 | 1 | 1 | 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版的，刚开始使用的东西。
看详细说明并下载，请在本站点的系统分析栏目中寻找该文。
/*
跋：
以上标题的结构，有些象一首歌的主题，其实还真有这么一首歌，叫做《三儿的问题》，不想被我改编了一下，遂成为：
需求的问题，是简单的问题，
需求的问题，是复杂的问题，
需求的问题，是技术的问题，
需求的问题，是管理的问题，
需求的问题，是你们的，我们的，
他们的，大家的问题。
文章来源于领测软件测试网 https://www.ltesting.net/
