需求规格说明书

一、引言
1.1 编写目的
为了更好的确定和明确需求，减少以后可能重复的设计和编码，最好的满足客户需求，也作为设计文档、测试文档的依据。
1.2 项目背景
简单描述遗留系统、要做的新系统，以及和其他系统的关系。
1.3 参考资料
参考的资料，可包括政府、地区的相关规定和行业的相关标准，遗留系统的相关文档等等。
1.4 变更历史

版本	修改日期	变更申请人	变更内容描述	备注
v 1.0	2007-02-05		初始版本

二、业务需求（商业需求）
反应组织机构或客户对系统及产品高层次的目标要求。一般从企业的技术部门得到。

三、用户需求
描述了用户使用产品必须要完成的任务。必须从真正使用系统的用户那里得到。用户需求也是对用户的具体需求进行调研才能得到。

四、功能需求
定义了软件开发人员必须实现的功能。是从用户需求转化而来的。
总结出具体功能设计的方法：根据高层次的需求总结设计出完整的使用方案，所谓的使用方案设计就是，将用户会怎样使用你的软件为解决某个具体问题的整个过程给想象和设计出来，而且是一个完整的从头到尾的使用过程。有了这个过程的总结，再从它的基础上进一步确定每个功能的具体需求。
4.1 功能模块1
4.1.1 子功能1
4.1.1 子功能2
4.2 功能模块2
4.2.1 子功能1
4.2.2 子功能1
4.3 功能模块3
4.3.1 子功能1
4.3.2 子功能1

五、非功能需求
系统应该达到的效率要求、可扩展性、可维护性要求、对外接口等等。

六、性能需求
系统应该达到的可靠性、压力等等。

七、质量需求
系统应该达到的质量、稳定性等等。

八、系统需求
定义系统运行的硬件平台、操作系统、网络环境、软件环境，运行的支撑系统，以及系统是否24*7运行等等。
8.1 硬件平台
8.2 操作系统
8.3 网络环境
8.4 软件环境
8.5 运行支撑系统

九、开发局限
因为技术原因不能满足的需求或者不能实现的地方。

附录一：可能出现的泥潭
1、只有业务需求，没有功能需求
需要对需求进行分类，界定每种需求的范围，其实需求分析的过程也是逐步细化的过程。
2、需求描述含有二义性
用简洁、无歧义的语言来描述需求，避免描述性的词语，尽量对描述性词语进行量化，并且给出具体值或范围。
3、需求细化程度不够
需求都是一个从概括性需求刀低层次需求的过程，一般都是知道高层次概括性较强的需求。需要将需求细化，直到消除所有不确定因素为止。需求是越详细越好，但是也不能过于详细。需要做到的是，将一个需求分割成不同的小需求，每个需求都能想出测试用例来测试这个需求。细化到这个程度也就可以了。
4、需求过程缺乏沟通
需求评审是一个非常重要的沟通方式。并且沟通应该贯穿在整个需求过程中，整个需求过程也是系统分析人员（职责是做需求分析）和设计人员（职责是做设计）不断反复沟通的过程。