软件需求分析报告（精选2篇）

软件需求分析报告 篇1

1引言

“万事开头难”，就软件开发而言，首要任务是确定软件需求。据统计，软件项目中40%～60%的问题源自软件需求阶段，因为需求模糊或错漏都会造成软件开发者与用户对软件的理解产生差异。所以对软件需求要有准确的把握，这样才能在后续的开发中减少错误的发生。

软件需求主要指一个软件系统必须遵循的条件或具备的能力，一般包括三个不同的.层次:业务需求，用户需求和功能需求。需求分析主要指软件开发的第一项活动，而该项活动的目的主要是为待开发的软件系统进行需求定义与分析，并建立一个需求模型。软件需求分析一般包括如下4个步骤:需求获取、需求建模、需求描述和需求验证。我们这次主要进行需求建模，下面将会进行具体介绍。

2功能需求

软件需求主要指一个软件系统必须遵循的条件或具备的能力，一般包括三个不同的层次:业务需求、用户需求和功能需求。在此主要介绍功能需求。

在线购物系统大体可以分为两个部分，即面向用户和面向管理员的两个部分。

面向用户的前台功能如下:

(1)商品信息查询功能。用户浏览网上商城，可以在网上商城首页、专柜首页、产品小类、专卖店首页等查看产品详细信息，可以按照价格，销量等元素排序。

(2)购物车功能。顾客选择完商品后可进入购物车页面，查看自己要购买的商品，可修改某一商品数量、取消购买某商品和清空整个购物车。

(3)网上结算功能。顾客在订单被销售方确认后，要选择付款方式，并付款给销售方，然后完成结算。

(4)订单管理功能。顾客确定购物车中的商品后提交订单，如顾客已填写收货人信息，则页面显示该信息并由顾客确认。如尚未填写则显示相应表单请其填写，系统记录顾客提交的收货人信息以便其下次购物时使用。顾客提交订单后可在网上商城查询该订单，并可对尚未处理的订单进行取消、修改等操作。

面向管理员的后台功能如下:

(1)用户管理功能。可以对用户的注册信息进行管理，冻结不合法账号等。(2)商品管理功能。管理员可以管理所有商品的发布，制定价格，确定商品信息，增删广告。(3)管理商品功能。管理员可以添加、修改、删除商品。(4)物流发货功能。对成功的订单，查询用户地址信息，发货给用户。

3参考文献

[1]《软件工程理论与实践》，张燕，南京金陵科技学院，20xx[2]《数据库系统概论》(第3版)，萨师煊，高等教育出版社，20xx

[3]《数据库原理及应用课程设计指导书》，丁勇，南京理工大学泰州科技学院，20xx

软件需求分析报告 篇2

需求分析报告

版本：1.0.0

编者年月日审核年月日批准年月日

xxxx年五月

一、引言

1.1编写目的对产品或项目进行定义，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么只定义文档中要说明的部分或子系统。

1.2背景说明

说明项目或模块开发背景。

1.3预期读者和阅读建议

列举软件需求规格说明书所针对的不同读者，如用户、设计人员、编程人员、测试人员、项目经理、市场人员等。指出最适合于每一类型读者阅读文档的建议。

1.4术语定义

解释需求说明书中的术语、名词、简称及缩写等等。

1.5 参考文献

列出所有参考资料、参照的软件名称，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。

二、任务概述

2.1目标

描述项目或业务模块要达到的目标。

2.2用户特点

描述主要的用户及其特点（教育水平、经验、计算机水平等）。确定可能使用该产品的不同用户类别并描述它们的特征。有些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。

2.3假定和约束

一般约束、假设及对用户的要求。

三、业务功能概要描述

3.1现有系统分析

对现有系统（包括自动或人工的）进行简要分析。

3.2业务描述

描述实际业务的过程和特点，即业务建模。

3.3系统角色

画出系统中的角色，并用文字进行说明。

3.4主题描述（或：系统用例视图）

画出主题图，描述主题内的业务和主题间的业务。

或用uml语言描绘系统总的用例视图。

3.5业务流程图

用uml的活动图描绘系统总的业务流程。

3.6业务接口

3.6.1外部业务接口

描述与其它项目或业务模块的功能接口。例如：工资模块与考勤、考核、任免、职称等模块的功能接口描述。

3.6.2内部业务接口

描述各个主题之间的业务接口。

四、业务功能详细描述

用语言和图对每个子系统、主题或业务模块要完成的功能进行完整详细的描述。即功能建模。

4.1子系统（模块一）

4.1.1业务功能描述

用文字语言描述子系统、主题或业务模块要完成的功能。

4.1.2业务流程图

用uml的活动图描绘子系统或业务模块的业务流程，在活动图中标注用到的或输入输出的表格、资料。注意，这里的活动图描述的是该子模块的业务流程。

4.1.3主题描述及用例视图

若主题下面还含有子主题，则画出主题图，描述主题内的业务和主题间的业务；并且接着画出子系统或业务模块的详细用例视图。

若主题下面不含子主题，则直接画出子系统或业务模块的详细用例视图。

4.1.4用例描述

对全部用例或主要的用例用文字进行详细描述。

4.1.4.1用例名称一

【用例功能说明】

用文字详细描述该用例的目的`、功能。

【操作描述】

用文字描述子系统或业务模块中主要用例的操作流程和要求。

【活动图、顺序图或协同图】（可选内容）用uml的顺序图或协同图描述该用例的操作流程。

【界面原型】（可选内容）

描绘用户所希望的图形用户界面标准或风格，包括大致的屏幕布局、功能菜单、标准按钮、快捷键、出错信息显示标准等。

4.1.4.2用例名称二

【用例功能说明】

用文字详细描述该用例的目的、功能。

【操作描述】

用文字描述子系统或业务模块中主要用例的操作流程和要求。

【活动图、顺序图或协同图】（可选内容）用uml的顺序图或协同图描述该用例的操作流程。

【界面原型】（可选内容）

描绘用户所希望的图形用户界面标准或风格，包括大致的屏幕布局、功能菜单、标准按钮、快捷键、出错信息显示标准等。

4.1.4.3用例名称三

.。 。.。4.1.5信息项描述

采集子系统或业务模块中用到的信息项，对于非国标、部标的指标项要给予具体解释和规范建议。

推荐描述形式如下：

信息集名称：

4.2子系统（模块二）

4.3子系统（模块三）

五、性能要求

5.1用户数要求

5.2业务方面的并发要求

5.3正常和极端情况下的时间要求

5.4容错要求

5.5权限要求

5.6灵活性要求

当需求发生变化时的适应能力要求。

5.7使用频度要求

日常使用或定期使用等的描述。

六、其它需求

详细描述本产品/项目必需满足的法令法规、行业规范、合同/标书中的其它要求、以往类似设计中的适用信息以及本公司对此项目附加的其它需求等。

七、附录

对本需求有说明意义的资料：文档、数据、表格、样张等等。

附注：

用例视图、活动图（业务流程图）、主题图、对象图、状态图采用uml标准符号绘制。推荐使用case工具如：ritional rose画好后再粘贴到word文档中。

如果时间充裕的话，应在辅助工具中进行业务建模，将非功能需求以及资料部分做为单独文档连接到模型中。