需求的问题

需求的问题，是一个简单的问题 

需求决定了软件做什么，要提供什么功能。 

软件工程初期的一般过程是，软件开发的计划，确定要实现的目标和进度等，然后就是需求规格说明书，该说明书要得到用户的认可。用户往往提供了一份要求的说明，开发人员在这个基础上进行了加工和整理。此后的开发过程，都是围绕着需求规格说明书进行进一步地细化，直至开发出产品。当然，测试计划中也要针对需求进行验证，看看是否满足了用户的要求。 

一般来说，用例视图可以很好地表现需求。用例图中，若干角色actor与系统提供的用例（功能）之间的连接关系。 

以下是参考《IEEE推荐的软件需求规格说明的方法（IEEE 830-1998）》的一个系统规格说明书SRS模板： 
  

一、引言

（一） 目的
（二） 文档约定
（三） 预期的读者和阅读建议
（四） 产品的范围
（五） 参考文献

二、综合描述

（一） 产品的前景
（二） 产品的功能
（三） 用户类型和特征
（四） 运行环境
（五） 设计和实现上的限制
（六） 假设和依赖

三、外部接口需求

（一） 用户界面
（二） 硬件接口
（三） 软件接口
（四） 通信接口

四、系统特性

（一） 说明和优先级
（二） 激励/响应序列
（三） 功能需求

五、其它非功能需求

（一） 性能需求
（二） 安全设施需求
（三） 安全性需求
（四） 软件质量属性
（五） 业务规则
（六） 用户文档

六、其它需求

附录A：词汇表
附录B：分析模型
附录C：待确定问题的列表 
  
另外，《GB9385-88 计算机软件需求说明编制指南》也为软件需求实践提供了规范化的方法。

需求的问题，是一个复杂的问题 

有些时候，需求的问题会变得很复杂的。尤其是在做行业软件或者ERP的时候，你遇到不同的客户，每个客户都有他的想法或要求，而且有些客户没有明确的思路，有些则有他们很固执的思路，一时间仿佛需求是没完没了的。或许你的软件已经是一个产品，那么究竟对什么功能进行取舍，对什么功能要增加进软件的核心，对什么功能采用二次开发，都是需要仔细判断的事情。  
  

1 需求的重复和变更 

对于比较大的系统，客户不可能一次性地把需求完全提清楚。这是必须容忍的。只要你不断沟通和了解，用户需求就会不断增加。有些公司采用的方法是在需求规格说明书上让客户签字，然后严格按照该说明书来实现。如果以后客户有新的要求，则要另外考虑。但在另一方面，客户永远是上帝，一个软件的成功，应该是用户用得非常流畅和满意。  

  
2 有些需求无法实现 

和客户的沟通也很重要。什么是必须满足的需求，而另外一些需求可能暂时不能提供实现，这也需要解释清楚。  

  
3 实现的功能和客户原来提出的需求会有所差别。 

很多软件的问题最后总结下来是因为需求没有明确。开发人员没有认准客户究竟需要什么。这时候只能修改软件。 

需求的问题，是一个技术的问题 

每个需求的特性可体现在很多方面：如优先级、有效性，效率，灵活性，完整性，互操作性，可靠性，健壮性，可用性；可维护性，可移植性，可重用性，可测试性等。

确定需求优先级：可以粗略地分为三级：

高	一个关键任务的需求，必须在此版本实现；只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现
中	支持必要的系统操作，最终所要求的，但如果有必要，可以延迟到下一版本；实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的；需要付出努力，但不必做得太完美
低	功能或质量上的增强，如果资源允许的话，实现这些需求会使产品更完美；实现或不实现均可；可以包含缺陷

更精确的优先级设定如下表：

权值	1	1			1		1
MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">需求	收益	代价	价值	价值%	成本	成本%	风险	风险%	优先级
<需求>	<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/Aclearcase/" target="_blank" >ccess2000。特点是和客户管理联系在一起。提供了对需求各属性的描述，也提供了对每一条需求的讨论和跟踪。这是一个1.0 Beta版的，刚开始使用的东西。 

看详细说明并下载，请在本站点的系统分析栏目中寻找该文。 

　

/*

跋：

以上标题的结构，有些象一首歌的主题，其实还真有这么一首歌，叫做《三儿的问题》，不想被我改编了一下，遂成为：

　

需求的问题，是简单的问题，

需求的问题，是复杂的问题，

需求的问题，是技术的问题，

需求的问题，是管理的问题，

需求的问题，是你们的，我们的，

他们的，大家的问题。


*/ 

原文转自：http://www.ltesting.net