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

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

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 需求规定

2. 软件工程需求分析说明书论文怎么写

1引言 2
 1.1编写目的 2
 1.2背景 2
 1.3定义 2
 1.4参考资料 2
 2任务概述 2
 2.1目标 2
 2.2用户的特点 3
 2.3假定和约束 3
 3需求规定 3
 3.1对功能的规定 3
 3.2对性能的规定 3
 3.2.1精度 3
 3.2.2时间特性要求 3
 3.2.3灵活性 4
 3.3输人输出要求 4
 3.4数据管理能力要求 4
 3.5故障处理要求 4
 3.6其他专门要求 5
 4运行环境规定 5
 4.1设备 5
 4.2支持软件 5
 4.3接口 5
 4.4控制 5
  
 软件需求说明书的编写提示
 1引言
 1.1编写目的
 说明编写这份软件需求说明书的目的，指出预期的读者。
 1.2背景
 说明：
 a． 待开发的软件系统的名称；
 b． 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
 c． 该软件系统同其他系统或其他机构的基本的相互来往关系。
  1.3定义
 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
 1.4参考资料
 列出用得着的参考资料，如：
 a． 本项目的经核准的计划任务书或合同、上级机关的批文；
 b． 属于本项目的其他已发表的文件；
 c． 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
 2任务概述
 2.1目标
 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
 2.2用户的特点
 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
 2.3假定和约束
 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
 3需求规定
  3.1对功能的规定
 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
 3.2对性能的规定
 3.2.1精度
 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
 3.2.2时间特性要求
 说明对于该软件的时间特性要求，如对：
 a． 响应时间；
 b． 更新处理时间；
 c． 数据的转换和传送时间；
 d． 解题时间；等的要求。
 3.2.3灵活性
 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
 a． 操作方式上的变化；
 b． 运行环境的变化；
 c． 同其他软件的接口的变化；
 d． 精度和有效时限的变化；
 e． 计划的变化或改进。
 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
 3.3输人输出要求
 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
 3.4数据管理能力要求
 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
 3.5故障处理要求
 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
 3.6其他专门要求
 如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
 4运行环境规定
 4.1设备
 列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
 a． 处理器型号及内存容量；
 b． 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
 c． 输入及输出设备的型号和数量，联机或脱机；
 d． 数据通信设备的型号和数量；
 e． 功能键及其他专用硬件
 4.2支持软件
 列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
 4.3接口
 说明该软件同其他软件之间的接口、数据通信协议等。
 4.4控制
 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

3. 在软件工程中什么是需求分析？

4. 软件工程 需求分析有哪三种方法

软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。
在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。
软件开发，能否获得成功，最重要的是需求分析的工作。因此，软件需求分析能力和水平，对软件项目至关重要。

一般的分析方法和步骤如下：
⑴首先调查组织机构情况 　　包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。 
⑵然后调查各部门的业务活动情况 　　包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。 　　
⑶协助用户明确对新系统的各种要求 　　包括信息要求、处理要求、完全性与完整性要求。 　　
⑷确定新系统的边界 　　确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 　　

常用的调查方法有： 　　
⑴跟班作业 　　通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。 　　
⑵开调查会 　　通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
⑶请专人介绍。 　　
⑷询问 　　对某些调查中的问题，可以找专人询问。 　　
⑸设计调查表请用户填写 　　如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。 　　
⑹查阅记录 　　即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 　　通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

5. 软件的需求分析怎么写啊？

软件需求分析免费下载    
链接:https://pan.baidu.com/s/1qNBwqvbRS5ziBSIeanLQAQ
 提取码:qoyw    
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

6. 软件工程中常用的需求分析的方法有哪些?

一、过滤需求的方法
做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。

这不是一个贬义词，反而是体现后端产品价值判断的基础。

过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。

1. 用户场景模拟法
后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。

如果不能帮助用户，那么这个需求就可能是伪需求。

以下面的案例说明：

背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。

需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。

分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。

因此，该需求是个伪需求，应该被过滤掉。

2. 功能归属分析
专门的系统做专职功能，有助于合理的产品体系建设。

因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。

如果不属于该系统范畴，那么直接说服需求方更换方案。以

下面的案例说明：

背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。

需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。

分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。

所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。

之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；

其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。

结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。

否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。

二、拆分和聚合的方法
1. 拆分需求法
业务用户提出一个需求，很可能只是短短的一段话。

但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：

先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。

每个需求点再当做一个子需求进行调研，最后再聚合在一起。

以下面的案例说明：

背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。

需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。

该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：

自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。

这里不一一展开。

2. 聚合需求法
拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：

由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。

然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。

三、利用辅助功能调研需求
调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。

比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。

最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：

背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。

需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。

分析：需求是很明白的，也有它的意义，但有风险。

因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。

因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。

于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。

测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。

四、“拔萝卜带出泥”的方式调研需求
调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。

举例说明：

背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。

需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。

分析：

第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……

第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……

通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。

罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。

7. 软件工程的软件需求

软件需求包括 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行业其他职位而言，软件测试的入行更加容易。

8. 怎样做软件的需求分析

做软件需求分析的方法：1、确定产品所期望的用户类别。2、获取每个用户类的需求。3、了解实际用户任务和目标以及这些任务所支持的业务需求。4、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。5、将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。6、了解相关质量属性的重要性。7、商讨实施优先级的划分。8、将所收集的用户需求编写成文档和模型。9、评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。