软件需求说明书的主要内容及写作要求

1 、引言
2、 背景说明
3、介绍内容、使用范围
4、参考资料
说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。
312 参考资料
列出有关资料(名称，发表日期，出版单位，作者等)。
313 术语和缩写词
列出本文件中用到的专门术语的定义，及术语缩写词。
32 软件总体概述
321 目标
软件开发的意图、应用目标、作用范围以及需说明背景材料。
322 系统模型
图示说明该软件的所有功能及其相互关系和数据传递情况。
323 假设和约束
说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。33 详细需求
详细描述此软件系统的功能需求和性能需求。
331 功能需求
对系统中每一个功能，要详细描述（图示或文字）。
概述 叙述功能名称，目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
332 性能需求
定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：
3321精度
说明系统的精度要求，如：
数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3322 时间特性
说明系统的时间特性要求，如：
解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3323 灵活性
说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
3324系统容量
包括系统的设计容量和理论（计算）容量。
333 输入和输出
解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
334 数据管理能力
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。
335 故障处理
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
34 环境
描述所开发软件运行所需的环境。
341 设备环境
描述运行软件系统所需的设备能力，如：
处理器的型号和内存容量。
存储媒体的数量。
通信网络（包括说明网络结构，线路速度及通讯协议等）。
342 支持软件环境
列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序， *** 作系统和数据管理系统。
343 接口
说明本软件与其他软件之间的接口、数据通信协议等。
344其他
说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求
关键的问题是一定要编写需求文档我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起系统的分析人员说:"我们想与你谈谈你的需求"客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统"
百事通
而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人
需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等"这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的而下面的定义则从用户需要进一步转移到了系统特性:
需求是指明必须实现什么的规格说明它描述了系统的行为、特性或属性,是在开发过程中对系统的约束
从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识
任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述
2需求分析的任务
开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难
目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题
对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢
然而,即便并非出于商业目的的软件需求也是必须的例如库、组件和工具这些供开发小组内部使用的软件当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生
近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能结果这个小组只好手工抄写源代码文档以供代码检查这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了
相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明而 *** 作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误
事实上,需求文档在开发过程中一直起指导作用

做软件需求分析的方法：

1、确定产品所期望的用户类别。

2、获取每个用户类的需求。

3、了解实际用户任务和目标以及这些任务所支持的业务需求。

4、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

5、将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。

6、了解相关质量属性的重要性。

7、商讨实施优先级的划分。

8、将所收集的用户需求编写成文档和模型。

9、评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。

规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。
2 适用范围
本规范适用于集团开发项目的（软件）《需求说明书》的编写。
3 编写内容提示
1 引言
311 背景说明
说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。
312 参考资料
列出有关资料(名称，发表日期，出版单位，作者等)。
313 术语和缩写词
列出本文件中用到的专门术语的定义，及术语缩写词。
32 软件总体概述
321 目标
软件开发的意图、应用目标、作用范围以及需说明背景材料。
322 系统模型
图示说明该软件的所有功能及其相互关系和数据传递情况。
323 假设和约束
说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。33 详细需求
详细描述此软件系统的功能需求和性能需求。
331 功能需求
对系统中每一个功能，要详细描述（图示或文字）。
概述 叙述功能名称，目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
332 性能需求
定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：
3321精度
说明系统的精度要求，如：
数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3322 时间特性
说明系统的时间特性要求，如：
解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3323 灵活性
说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。
3324系统容量
包括系统的设计容量和理论（计算）容量。
333 输入和输出
解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
334 数据管理能力
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。
335 故障处理
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
34 环境
描述所开发软件运行所需的环境。
341 设备环境
描述运行软件系统所需的设备能力，如：
处理器的型号和内存容量。
存储媒体的数量。
通信网络（包括说明网络结构，线路速度及通讯协议等）。
342 支持软件环境
列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序， *** 作系统和数据管理系统。
343 接口
说明本软件与其他软件之间的接口、数据通信协议等。
344其他
说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1SRS文档(System Requirement Specification); 2DRM 文档；3Acceptance Plan[1]
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。
原因
需求分析就是分析软件用户的需求是什么如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死
 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位大家一定要对需求分析具有足够的重视在一个大型软件系统的开发中,他的作用要远远大于程序设计
任务
简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求
过程
需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审
需求分析
 问题识别
 就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型, *** 作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标
分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型)
 制订规格说明书
 即编制文档,描述需求的文档称为软件需求规格说明书请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交
 评审
对功能的正确性,完整性和清晰性,以及其它需求给予评价评审通过才可进行下一阶段的工作,否则重新进行需求分析。

---