软件设计都是从需求开始的，需求文档的编写往往就要求调研人员到市场上进行调研，回来后跟开发人员协商讨论而确定的。需求文档旨在详细描述系统使用人员对系统了解的细节，让编程人员认识到代码实现的难易程度，是系统开发人员与用户沟通的桥梁。
【描述哪些内容】
1. 为什么要写需求文档，即编写目的-------介绍编写这篇文档的好处，让大家认识到这篇文章的重要性。
2. 对系统的简要介绍，即编写背景，包含项目名称、提出者等有关项目的信息-----直入主题，让读者明确文章主题。
3. 项目的目标、用户特点和约束条件-------了解需求首先要确定使用人群，调研这些使用人群的特点，才能让自己的产品得到大众喜爱。
4. 功能描述------有了使用人群就该考虑这些人群到底想要实现怎样的功能，这也是需求文档的主要模块。但功能不单单满足了用户的需求就可以，要综合多方面考虑：
功能描述-----最主要的考虑因素。
界面--------如何让使用者感觉更舒服？界面给了用户第一印象。
数据--------什么样的数据既能实现想要的功能，又可占用较少的内存。
性能-------如何让自己的系统满足需求的情况下执行起来更高效。
故障处理能力-------能否让系统运行期间检出错误类型，使管理人员迅速发现并解决它？
这些内容看起来是比较多，但存在着紧密的联系，从需要的功能开始一直到故障处理是一个由外到内的过程：了解了用户想要实现的功能肯定是第一步；然后会考虑用什么样的界面让用户来操作这些功能；实现这样的功能会用到什么样的数据？最后会考虑，功能已经实现了，能不能提高我们系统的性能，出现错误了能让用户自己解决？这样对功能的描述就行云流水般的展现出来了。
5. 环境分析-----系统兼容性，只有了解了系统运行的环境，选择合适的编程接口和控制架构，才能提高系统兼容性，满足用户需求。
总结一下，需求文档的内容是相辅相成，一环扣一环的：编写该文档的目的--->描述的项目简介---->使用人群特点----->描述功能----->运行环境。
【用什么样形式表现】
1. HIPO图：hierarchy plus input-process-output是IBM公司在70年代推出的描述系统结构和模块内部处理功能的技术，包括机构图和IPO图（其功能与名字相衬：输入--处理--输出）两部分。
上图是针对机房收费系统做的H图，对每一个功能模块进行了整理描述。
2. 原型图
使用IPO图，用户就无法真正理解需求文档是否真正满足要求，原型图就很好的帮用户与开发设计人员建立起沟通的桥梁，再通过简单的描述，便能够迅速快捷使用户与编程设计人员达成共识。
借助于axure RP来进行原型图的设计，即方便又美观。
【总结】
作为系统开发人员更应该考虑的是采用何种架构，使用什么样的设计模式，选择什么样的编程语言；但通过本次需求文档编写意识到需求涉及整个软件开发周期，而且对需求的认识越深刻，产品就更容易得到用户的认可。