怎么写需求分析报告（怎么写需求分析）

关于怎么写需求分析报告，怎么写需求分析这个问题很多朋友还不知道，今天小六来为大家解答以上的问题，现在让我们一起来看看吧！

1、需求分析格式1 引言1.1 编写目的【说明】目标：对用户的需求进行收集、整理与分析，弄清楚系统究竟要 “干什么”及“由谁干”，并用合乎规范的文字及图表予以描述。

2、不需要说明“怎么干”，因为那是设计阶段的事情。

3、有关文字与图表应尽量让用户便于理解。

4、    预期读者：用户方的相关业务人员、双方的开发人员和系统维护人员。

5、    作用：实现开发方与用户方的双向沟通，是把业务需求计算机化的关键步骤。

6、    为下一阶段的概要设计工作提供依据。

7、当用户的需求发生变更时，应添写补充说        明；如变动过大可形成新版本。

8、软件需求说明（Software Requirements Specification）的主要作用为： 为用户方与开发方建立共同协议奠定基础。

9、 提高开发效率、强化进度控制。

10、 为项目的的评测与验收提供依据。

11、 便于移植。

12、 作为系统不断提高的基础。

13、1.2 编写背景1.2.1 系统名称及版本号【说明】形如“网银三期***系统V3.0.0”。

14、其中，版本号的格式为“XX.XX.XX”，X为阿拉伯数字，左“0”可省略。

15、1.2.2 使用者【说明】适应对象和范围。

16、主要指预期读者，也供有关领导审阅。

17、1.2.3 与其它系统的关系【说明】在用户现有的及预期的整个应用系统中，给本系统准确定位。

18、用示意图及相应的文字予以说明。

19、2 用户的基本情况2.1 系统建设背景【说明】项目背景与依据、现有基础、项目规模、预期目标等。

20、可繁可简，格式自定。

21、2.2 组织机构与职能【说明】用层次示意图及相应文字表示(如果需要开发的系统与部门没有直接依赖关系此节可省略,本章随后的小节数将顺次减1)，加注：组织机构的层次数、数目、各个机构的职能简述。

22、2.3 用户特点【说明】所在行业特征、操作人员与系统维护人员的数量、学历与水平、数据量大小、使用频度等。

23、2.4 用户业务分析【说明】在本部分，希望系统分析人员能够对用户业务现状进行分析、对用户对本系统的未来发展方向作出一定的预测等。

24、以便设计人员对业务及其发展有所了解，增强系统设计的前瞻性。

25、2.5 计算机应用现状【说明】可繁可简，格式自定。

26、3 业务需求3.1 项目概述【说明】第一、 指明项目的开发意图、应用目标（总目标、分期目标）、作用范围、预期效益等。

27、第二、 指明在输入信息转变为输出信息的过程中，为了满足用户的业务需求，应用软件必须完成的基本功能(采用自然语言叙述)。

28、但此时不要求对基本功能进行分解。

29、第三、 如果本系统与其他系统相关联，则应确定本系统的基本功能边界（可采用图示+文字说明的形式，用蓝色标示出本系统的功能，用绿色标示出相关系统的功能）。

30、3.2 约束条件3.2.1 费用约束【说明】 预计投资金额概算、其中软硬件费用的比例、资金分期到位计划。

31、3.2.2 进度约束【说明】预计完成日期、分步实施期限。

32、3.2.3 其它约束【说明】场地面积限制、通信设施基础、其它干扰因素。

33、    注意：任何计算机系统都不是包罗万象的；用户自身的能力也是有限的。

34、轻诺必寡信。

35、故应特别指出：由于哪些条件的约束，本系统不能满足哪些业务需求与系统需求。

36、本章主要介绍项目的总体业务功能,要求站在客户的角度把握系统需求.3.3 性能需求【说明】依据ISO9000标准及我们的理解，下面列出了软件的6组性能，共涵盖21个子特性。

37、这些性能/子特性的相对重要性并不是等同的。

38、编写时，可以基于具体项目的实际需求，对下述标题或内容进行取舍/侧重。

39、事实上不可能做到面面俱到，往往要作出某些折中。

40、本节说明系统在性能方面的预期目标，不要求提供实现上述目标的具体实施方案。

41、3.3.1 功能性【说明】指与软件实现的各项功能及其指定性质有关的一组属性。

42、这些功能都是满足规定需求和潜在需求所必需的。

43、它包括5个子特性：适用性：与指定业务所需各项功能的实现及其适合程度有关的一些软件属性。

44、准确性：与保证正确（或符合要求的）结果（或效果）有关的一些软件属性。

45、互操作性：与软件同一些指定系统交互作用能力有关的一些软件属性。

46、复合性：使软件遵守相关的标准、约定/法律或类似规定有关的一些软件属性。

47、保密安全性：与针对蓄意（或无意）而非法存取程序和数据的预防能力有关的一些软件属性。

48、这里主要指的是保护软件的要素，旨在防止各种非法访问、修改、破坏、泄密及感染计算机病毒等。

49、3.3.2 可靠性【说明】指在规定的条件和期限内，与软件保持其性能水平有关的一组软件属性。

50、成熟性：与软件故障引起的失误频率有关的一些软件属性。

51、容错性：在软件故障发生或其规定界面被破坏的情况下，与软件仍能保持规定性                能水平的能力有关的一些软件属性。

52、可恢复性：在失效的情况下、在限定的期限和强度范围内，与软件重建性能水平                并恢复直接受影响的数据的能力有关的一些软件属性。

53、3.3.3 易使用性【说明】指与规定用户（或潜在用户）使用软件所需的努力程度、对这种使用所做的评估有关的一组软件属性。

54、它包括3个子特性：易理解性：与用户为理解其逻辑概念及适用范围需做的努力有关的一些软件属性。

55、易学习性：与用户学习其应用（例如操作控制、输入、输出）需做的努力有关的一些软件属性。

56、易操作性：与用户操作及运行控制需做的努力有关的一些软件属性。

57、3.3.4 高效性【说明】指在特定的运行环境中，描写软件性能水平与所用的资源量之间关系的一组软件属性。

58、它包括两个子特性：时间特性：在完成软件功能时，与响应时间、处理时间、吞吐率有关的一些软件属性。

59、资源特性：在完成软件功能时，与所用资源量及占用时间有关的一些软件属性。

60、3.3.5 可维护性【说明】与对软件进行指定的修改所需的工作量有关的一组软件属性。

61、它包括4个子特性：易分析性：与诊断故障、确定失败原因、在需要修改的部位进行标识等所做努力有关的一些软件属性。

62、易修改性：与实施修改、排除故障、环境改变所做努力有关的一些软件属性。

63、稳定性：与修改的意外影响带来的风险有关的一些软件属性。

64、易测试性：与对经过修改的软件进行检验/确认做努力有关的一些软件属性。

65、3.3.6 可移植性【说明】指软件从一个环境转移的另一个环境时，与其适应能力有关的一组软件属性。

66、它包括4个子特性：适应性：除已有手段外，无须采用其它措施或手段，软件便应能适应指定的环境。

67、与这种能力有关的一些软件属性称为适应性。

68、易安装性：在指定环境内，与安装软件所需努力有关的一些软件属性。

69、一致性：软件从一个环境转移的另一个环境时，应符合一定的标准和约定。

70、与这种符合程度有关的一些软件属性，称为一致性。

71、易替换性：有时会出现这种需求：在某个其它软件的运行环境下，要用本软件来置换那个软件。

72、与这种可能性及所需努力有关的一些软件属性。

73、4 用户需求【说明】本章下面介绍的是一般规模软件系统的书写格式。

74、在书写过程中可能要以业务名称划分小节(例如:5.1 代收电话费)。

75、每个业务小节包含两个部分：第一部分是对此业务中角色和功能的定义；第二部分是此业务的图形分析方法。

76、 在本章开始未分节的部分，应当绘制一个总体结构图，依据这个总体结构图进行一个总体描述，使得阅读者对下面分节描述的各个功能形成一个整体印象。

77、这个总体结构图不一定是指在ROSE工具中绘制的用例总图， 而是根据需要可以选择包括“用例总图”、“适当级别的数据流图”、“IDFF图”、“数据流程图”或其他专业图形分析图示等。

78、 每个小节中的第二部分采用rational公司的rose2000作为工具绘制用例（use case）图和顺序（sequence）图。

79、在这里采用rose工具是作为绘图分析工具使用，对需求的描述和分析并不代表我们的设计采用UML标准和面向对象的设计，具体分析人员应当根据实际的用户需求描述绘制顺序图，而并不着重考虑对象的分析限制。

80、需求变更的处理原则：获得批准的需求变更，需要在《需求分析》中有所体现。

81、增加的需求，需直接从本章尾部顺序添加，相应的小节编号也需要依次增加。

82、例如：本章小节为5.1—5.5，增加的需求小节编号则为5.6。

83、删除的需求，不需要将相应需求直接从《需求分析》中删除，而只需在相应需求小节上注明删除，并标出《需求变更单》编号。

84、修改的需求，可在相应的需求小节直接修改。

85、所有对《需求分析》内容的修改必须在修改历史中留有记录。

86、4.1 业务名称14.1.1 角色/功能定义【说明】根据会议纪要、小组讨论，确定系统中的角色（角色可以为外部系统或系统用户），和功能，并给出相应的定义或解释。

87、4.1.2 图形分析【说明】本节主要描述相应业务的用例图和顺序图的内容    统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。

88、它记录了对必须构造的系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息控制。

89、UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模方法。

90、在本需求模板中我们选取的是UML视图来辅助进行图形需求分析，选用Rational公司的ROSE工具完成。

91、在需求分析过程需要完成结构分类中的用例分析，绘制用例图；对用例的动态行为进行交互分析，描述执行系统功能的各个角色之间相互传递消息的顺序关系，绘制顺序图。

92、在这里请作者将制作的用例图和顺序图拷贝到本文档中。

93、基本成分：用例（use case）、用例视图（use case view）、角色（role、actor）、顺序图（sequence diagram）、协作图（collaboration diagram）。

94、模板和命名：为更好地使用ROSE图形分析工具，我们设定一个基本的分析模板，文件名为lansoftmdl.mdl。

95、该文档涉及项目开发的需求、概设和详设3个阶段，在需求阶段主要完成模板中用例视图（use case view）规定完成的部分。

96、在项目中使用该模板后生成的mdl文件纳入文档的配置管理，具体命名参照SEMP体系的命名规定。

97、修改历史记入文档开始部分的“mdl文档修改历史表”中。

98、【ROSE使用要求】 要求使用ROSE工具时必须完成模板和使用要求中规定完成的内容，在完成基本内容的基础上，可以根据需要增加部分内容。

99、2、 在公司没有购买确定版本的ROSE以前，使用的ROSE版本应在项目开始前在项目组规定好，并由配置管理员负责配置。

100、3、 在用例视图（use case view）中建立一个名称为main的主用例图（use case diagram），具体内容应当包括所有用例图的全部内容，具体应用时还可以根据情况建立多个用例图（use case diagram）。

101、4、 在用例视图中请采用中文对所有的角色（actorole）进行命名。

102、其中角色必须在双击该对象图后，详细填写该角色的描述（documentation）和该角色代表的角色数量（detail-multiplic）。

103、5、 在用例视图中请采用中文对所有的用例（use case）进行命名。

104、命名中在一般的中文概括前应增加代表本节编号的部分，如“1.用户认证”，顺序编号。

105、其中用例必须在双击该对象图后，详细填写该用例的描述（documentation）。

106、6、 在每个用例下必须组织建立相应的顺序图（sequence diagram），对于一个用例可以包含多个顺序图（sequence diagram），各个顺序图（sequence diagram）的命名需在一般的中文概括前增加代表本节编号的部分，如“1.1用户认证”，顺序编号，其中第一个1代表所属的用例，第二个1代表顺序图（sequence diagram）的编号。

107、产生顺序图的数量根据说明需求的具体要求设定。

108、其中顺序图中的各个对象消息（object message）必须在双击该对象图后，详细填写该对象消息（object message）的描述（documentation）。

109、4.1.3 数据存储需求【说明】根据会议纪要、小组讨论，对于在需求调研中有关的数据实体对象或数据实体信息，应当根据需要提出可能数据类型和数据长度以及单位量纲的记录或建议。

110、5 运行环境【说明】本章只提出运行环境的逻辑结构，物理结构将在《概要设计说明书》中给出。

111、        容许提出几种可选方案。

112、5.1 硬件平台【说明】指出本应用软件适用的主机/服务器与终端/工作站的技术指标、基本配置、接口特点、特殊约定等。

113、应尽可能地说明上述设备在各级用户机构预计的分布状态。

114、5.2 网络平台【说明】选型标准、网络类型、基本部件、接口情况、对综合布线的要求、限制条件等。

115、应画出网络（广域网、局域网）的拓扑结构图，说明后者对前者的接入方式。

116、5.3 软件平台【说明】操作系统的名称、生产厂家、版本号等。

117、        数据库的名称、生产厂家、版本号等。

118、        数据库设计工具的名称、生产厂家、版本号等。

119、        网络通信协议的名称、生产厂家、版本号等。

120、        前端开发工具的名称、生产厂家、版本号等。

121、        测试开发工具的名称、生产厂家、版本号等。

122、        现场运行时需要的工具软件的名称、生产厂家、版本号等。

123、        配置管理工具软件的名称、生产厂家、版本号等。

124、6 附录【说明】列出基础素材中的文件、报表、单据等的样张，再附上必要的注释。

125、如果条件成熟，可以把数据字典（data dictionary）作为附件列于后。

126、6.1 电子文档编写方式与使用工具【说明】编写要求、工具名、版本号、操作系统平台。

127、使用多种工具时，应分别说明。

128、形如：        Microsoft Word 97 for Windows 95/98        Power Designer 6.0 for Windows 95/98        Rational Rose 98 for Wintel        Visio或Power Point 97 for Windows 95/986.2 定义说明与符号【说明】包括对专用术语及缩略语的解释、所用到的图（如use case、sequence图）之图符的表示与解释等。

129、6.3 参考资料【说明】格式：作者，[版本号，]资料来源，日期 [，起止页号] 。

130、其中，《质量保证计划》是必选的参考资料。

131、6.4 有关表格清单【说明】列出用户提供的素材，加上我们积累的有关文件，作为系统分析的基础。

132、在这里除系统内部没有用户参与的需求分析工作外，必须包括一个以上的用户访谈纪要、用户确认签名文件以及用户访谈计划等文件的列表。

133、在列表中的文件应当作为附件与需求文档共同纳入配置管理。

本文分享完毕，希望对大家有所帮助。

标签：