软件工程非功能需求分析报告

A. 求软件工程需求分析报告范文,谢谢!!!!

3.1 引言
3.1.1 编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
3.1.2 背景
说明
a.待开发的软件系统的名称，
b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络
c.该软件系统同其他系统或其他机构的基本的相互来往关系。
3.1.3 定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
3.1.4 参考资料
列出用得着的参考资料，如:
a.本项目的经核准的计划任务书或合同、上级机关的批文;
b.属于本项目的其他已发表的文件，
c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
3.2 任务概述
3.2.1 目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的乒品是卢个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
3.2.2 用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
3.2.3 假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3.3 需求规定

B. 需求开发中的非功能需求包括哪些

非功能性需求

4-1、系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

4-2、业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

4-3、功能需求记录在软件需求规格说明（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。

4-4、质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

4-5、约束（constraint）限制了开发人员设计和构建系统时的选择范围，如局限于软件工程学科。 注：分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求对软件的开发有着重大的指导意义，绝不可以以偏概全，错误地去揣摩用户的心思；对于开发者而言，所有软件功能的开发我们都应该一一征求用户的意见，对需求有了清晰的认识后再进行实质性的开发工作。

C. 软件需求分析报告模板(完整版)

软件需求分析报告文档;
软件概要设计报告文档;
软件详细设计报告文档;
软件数据库设计报告文档;
软件测试（验收）大纲hi.gta123如有帮助，别忘了采纳哟！goto365testing,测评网,

D. 软件工程需求分析的模板

需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的
基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细
节。
1)采用软件需求规格说明模版:
采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注
意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准
830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。

1
2
3
4
5
6

A引言
目的
文档约定
预期的读者和阅读建议
产品的范围
参考文献

B综合描述
产品的前景
产品的功能
用户类和特征
运行环境
设计和实现上的限制
假设和依赖附录

C外部接口需求附录
用户界面附录
硬件接口
软件接口
通信接口

D系统特性
说明和优先级
激励/响应序列
功能需求

E 其它非功能需求
性能需求
安全设施需求
安全性需求
软件质量属性
业务规则
用户文档

F其它需求

G附件
词汇表
分析模型
待确定问题的列表


表2 需求规格说明模板

a. 引言

引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。

a . 1 目的

对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。

a.2 文档约定

描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。

a.3 预期的读者和阅读建议

列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。

a.4 产品的范围

提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。

E. 软件工程中的功能需求和非功能需求的区别是什么

软件工程中的功能需求和非功能需求的区别为：性质不同、约束不同、关联不同。

一、性质不同

1、功能需求：功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

2、非功能需求：非功能需求描述了系统展现给用户的行为和执行的操作等。

二、约束不同

1、功能需求：功能需求定义了对系统提供的服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。

2、非功能需求：非功能需求源于用户的限制，包括预算的约束、机构政策、与其他软硬件系统间的互操作，以及如安全规章、隐私权保护的立法等外部因素。

三、关联不同

1、功能需求：功能需求与软件系统本身有关。

2、非功能需求：非功能需求不仅与软件系统本身有关，还与系统的开发过程有关。

F. 软件工程中需求分析的任务是什么（具体点）

软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。

除此之外，每个系统还有各种非功能需求。

业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。

使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。

用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。

业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。

然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

功能需求记录在软件需求说明书（ SRS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；

或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。

除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。

质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

约束（constraint）限制了开发人员设计和构建系统时的选择范围。

行业需求：企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质，而对学历、年龄、性别、工作经验等的要求较低，相对于IT行业其他职位而言，软件测试的入行更加容易。

(6)软件工程非功能需求分析报告扩展阅读：

工程与科学：

软件的开发到底是一门科学还是一门工程，这是一个被争论了很久的问题。实际上，软件开发兼有两者的特点。但是这并不意味着它们可以被互相混淆。很多人认为软件工程基于计算机科学和信息科学就如传统意义上的工程学之于物理和化学一样。

在美国，大约40%的软件工程师具有计算机科学的学位。在世界其他地方，这个比例也差不多。他们并不一定会每天使用计算机科学方面的知识，但是他们每天都会使用软件工程方面的知识。

G. 请问软件工程中的需求分析都包括那些内容

需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段包括：
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
还有一个网页去看看吧，也许对你可能有帮助。

http://hi..com/shiqyn/blog/item/77ef1c1bfa31351c8718bf00.html

还有在软件工程的书籍上说的更清楚。