需求的问题，是一个简单的问题
需求决定了软件做什么，要提供什么功能。
软件工程初期的一般过程是，软件开发的计划，确定要实现的目标和进度等，然后就是需求规格说明书，该说明书要得到用户的认可。用户往往提供了一份要求的说明，开发人员在这个基础上进行了加工和整理。此后的开发过程，都是围绕着需求规格说明书进行进一步地细化，直至开发出产品。当然，测试计划中也要针对需求进行验证，看看是否满足了用户的要求。
一般来说，用例视图可以很好地表现需求。用例图中，若干角色actor与系统提供的用例（功能）之间的连接关系。
以下是参考《IEEE推荐的软件需求规格说明的方法（IEEE 830-1998）》的一个系统规格说明书SRS模板：
一、引言
（一） 目的
（二） 文档约定
（三） 预期的读者和阅读建议
（四） 产品的范围
（五） 参考文献
二、综合描述
（一） 产品的前景
（二） 产品的功能
（三） 用户类型和特征
（四） 运行环境
（五） 设计和实现上的限制
（六） 假设和依赖
三、外部接口需求
（一） 用户界面
（二） 硬件接口
（三） 软件接口
（四） 通信接口
四、系统特性
（一） 说明和优先级
（二） 激励/响应序列
（三） 功能需求
五、其它非功能需求
（一） 性能需求
（二） 安全设施需求
（三） 安全性需求
（四） 软件质量属性
（五） 业务规则
（六） 用户文档
六、其它需求
附录A：词汇表
附录B：分析模型
附录C：待确定问题的列表
|
另外，《GB9385-88 计算机软件需求说明编制指南》也为软件需求实践提供了规范化的方法。
需求的问题，是一个复杂的问题
有些时候，需求的问题会变得很复杂的。尤其是在做行业软件或者ERP的时候，你遇到不同的客户，每个客户都有他的想法或要求，而且有些客户没有明确的思路，有些则有他们很固执的思路，一时间仿佛需求是没完没了的。或许你的软件已经是一个产品，那么究竟对什么功能进行取舍，对什么功能要增加进软件的核心，对什么功能采用二次开发，都是需要仔细判断的事情。
1 需求的重复和变更
对于比较大的系统，客户不可能一次性地把需求完全提清楚。这是必须容忍的。只要你不断沟通和了解，用户需求就会不断增加。有些公司采用的方法是在需求规格说明书上让客户签字，然后严格按照该说明书来实现。如果以后客户有新的要求，则要另外考虑。但在另一方面，客户永远是上帝，一个软件的成功，应该是用户用得非常流畅和满意。
2 有些需求无法实现
和客户的沟通也很重要。什么是必须满足的需求，而另外一些需求可能暂时不能提供实现，这也需要解释清楚。
3 实现的功能和客户原来提出的需求会有所差别。
很多软件的问题最后总结下来是因为需求没有明确。开发人员没有认准客户究竟需要什么。这时候只能修改软件。
需求的问题，是一个技术的问题
每个需求的特性可体现在很多方面：如优先级、有效性，效率，灵活性，完整性，互操作性，可靠性，健壮性，可用性；可维护性，可移植性，可重用性，可测试性等。
确定需求优先级：可以粗略地分为三级：
| 高 |
一个关键任务的需求，必须在此版本实现；只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现 |
| 中 |
支持必要的系统操作，最终所要求的，但如果有必要，可以延迟到下一版本；实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的；需要付出努力，但不必做得太完美 |
| 低 |
功能或质量上的增强，如果资源允许的话，实现这些需求会使产品更完美；实现或不实现均可；可以包含缺陷 |
更精确的优先级设定如下表：
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
