完整版需求分析模板_软件需求分析报告模板 _生活经验

软件工程需求分析的模板需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基?。彩撬凶酉盗邢钅抗婊⑸杓坪捅嗦氲?br />基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细
节。
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 产品的范围
提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。
谁有软件需求分析报告模板或者例子跟我相吻合1. 引言
1.1. 背景
说明：
a．待开发的软件系统的名称；
b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C．该软件系统同其他系统或其他机构的基本的相互来往关系。
1.2. 参考资料
列出本说明书中引用和参考的资料，如：
a．本项目的经核准的计划任务书或合同、上级机关的批文；
b．属于本项目的其他已发表的文件；
c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.3. 假定和约束[可选]
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。
1.4. 用户的特点[可选]
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
2. 功能需求
2.1. 系统范围
明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。
如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选]
以图+文本结合的方式描述系统的总体架构。
以下应提供系统总体架构图：
以下对系统总体架构进行描述：
2.3. 系统总体流程
以图+文本结合的方式说明系统的总体流程。
图一是计划合同管理系统的总体流程图。
图一
2.4. 需求分析
需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？
· 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系
· 描述用例：角色与系统如何交互的规格说明。
2.4.1. XXXXXXX(功能需求名称)
2.4.1.1. 功能描述
功能编号：
功能需求：从用户业务的角度描述功能需求。
2.4.1.2. 业务建模
从可视化的角度--用例图--描述功能需求
图二是综合计划管理系统合同编辑业务的功能需求用例图。
图二
2.4.1.3. 用例描述
以文本的方式描述每一个用例中角色与系统相互交互的规格说明。
1、 XXXXXX(用例名称)
描述对象描述内容
标识符用例的唯一标识符
说明对用例的概要说明
参与者与该用例相关的参与者列表，以及参与者的特点
频度参与者访问此用例的频率
状态通常分为：进行中、等待审查、通过审查或未通过审查
前置条件一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足
后置条件一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足
被扩展的用例此用例所扩展的用例（如果存在）
被包含的用例此用例所包含的用例（如果存在）
基本操作流程参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式
可选操作流程在变更工作方式、出现异常或发生错误的情况下所遵循的路径
修改历史记录修改人：修改日期：修改原因：
问题如果存在，则为与此用例的开发相关的问题或操作项目的列表
以下是综合计划管理系统中的合同编辑功能需求中的合同增加用例描述：
描述对象描述内容
标识符 IPMS0101
说明增加一条合同记录
参与者合同编辑人员--熟悉合同管理业务
频度
状态通过审查
前置条件 1. 参与者具有合同增加的权限2. 参与者已选取对应的计划记录3. 当前计划总投资≥SUM(该计划下已签合同价)
后置条件 1. 数据库中更加一条合同纪律2. 可执行合同原件扫描用例3. 可执行合同付款增加用例4. 可执行合同修改和合同删除用例
被扩展的用例无
被包含的用例无
基本操作流程请参见图三的合同增加流程
可选操作流程当用户确认合同增加时发现异常时，系统提示合同增加无效的提示
修改历史记录修改人：修改日期：修改原因：
问题 1. 合同编码的具体约定2. 合同类型、资金来源、合同受委托方字典表的具体设计
图三合同增加活动流程
2、XXXXX(用例名称)
……
2.4.1.4. 用户界面
概要描述功能对应的用户界面风格，采用原型生命周期的项目也可以提供原型界面拷贝。
2.4.2. XXXXXXX(功能需求名称)
……
3. 非功能需求
3.1. 性能要求
3.1.1. 精度[可选]
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.1.2. 时间特性要求
说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和界面更新传送时间等的要求。
3.1.3. 输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.2. 数据管理能力要求[可选]
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。
3.3. 安全保密性要求
用户对系统所应具备的故障处理能力、处理方式及故障后的系统恢复、数据恢复等要求，对系统防止机密数据被非法侵入、修改及丢失的要求。
3.4. 灵活性要求[可选]
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．操作方式上的变化；
b．运行环境的变化；
c．同其他软件的接口的变化；
d．精度和有效时限的变化；
e．计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.5. 其他专门要求[可选]
如用户单位对使用方便的要求，对可维护性、可补充性、易读性、可靠性、异常处理要求、运行环境可转换性的特殊要求等。
4. 运行环境规定
4.1. 设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．处理器型号及内存容量；
b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．输入及输出设备的型号和数量，联机或脱机；
d．数据通信设备的型号和数量；
e．功能键及其他专用硬件
4.2. 支持软件
列出支持软件,包括网络和硬件设备平台、操作系统平台、数据库系统平台以及编译（或汇编）程序和测试支持软件等。
4.3. 接口[可选]
说明该软件同其他软件之间的接口、数据通信协议等。
4.4. 控制[可选]
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
5. 需求跟踪
需求跟踪的主要目的是保证所有的需求都得到分析，以承诺需求-分析需求对应表（PRS_SRS表）的方式描述已分析需求对已承诺需求的覆盖情况。PRS_SRS表的格式请参见软件需求管理过程规范（SUPL-MANU-SRS-001）。
谁帮忙作一个网上聊天系统的需求分析，模板也许需求分析文档
修改时间：修改人：改后版本：备注：
2004-10-22 董飞 1.0 初版
2004-10-26 董飞、陈景乐 2.0 增加站内信箱功能
2004-11-3 张莫迪 3.0 更改立项原因及特别说明
1. 引言： 2
1.1立项背景： 2
1.2立项原因概述： 2
1.3文档依据： 2
2. 项目概述： 2
2.1面向的用户人群： 2
2.2实现目标： 2
2.3项目开发要求： 3
2.4 开发工具： 3
3. 具体分析： 3
3.1 实现概述： 3
3.2 学生会及学工部老师： 3
3.3 需人单位或需家教家庭： 4
3.4 广大同学： 4
4. 界面设计: 4
5. 特别说明： 5
5.1 网站的安全性： 5
5.2 网站可维护性： 5
5.3 网站的灵活性： 5
5.4 硬件需求：（首先考虑学校现有硬件条件） 5
5.5 用户界面： 5
5.6 数据管理能力要求： 6
5.7 故障处理： 6
1. 引言：
1.1立项背景：
（1）项目提出者：南开大学学生工作部；
（2）提出原因：目前学校勤工助学管理不合理，给同学带来多种不便；
（3）项目创立者： Rock小组；
（4）项目开发者： Rock小组；
（5）项目名称：南开大学勤工助学系统；
1.2立项原因概述：
目前学校的勤工助学管理存在种种弊端：
（1）大多数同学需要找中介，信誉不能得到担保并且还可能缴纳许多无谓的中介费；
（2）学生会及学工部的老师工作大多靠手工，工作量大、效率不高、信息发布零散不系统，负担过重；
（3）目前的管理系统不能有效获取单位的兼职信息及同学们的申请信息，信息发布、更新不及时，交互性差；
1.3文档依据：
需求分析文档根据可行性调查报告编写，为今后的系统设计及数据库设计提供依据。
2. 项目概述：
2.1面向的用户人群：
（1）学生会及学工部老师：作为该系统的使用、管理者和维护者；
（2）需人单位和需家教家庭：作为兼职工作的提供者；
（3）广大同学们：作为兼职工作的申请者；
2.2实现目标：
（1）建立一个拥有良好交互性、操作简单易用的勤工助学服务性网站。
（2）网站运行要高效，费用尽量低，注重实用性。
（3）该网站提供一种更加方便、高效的勤工助学工作方式。
（4）网站实现及时获取工作提供者的信息和工作申请者的信息，后台自动
地快速、准确地将两者进行匹配，得到最优匹配并及时反馈信息。
（5）对于一段时间未找到匹配的同学，系统自动向其发信提供建议。
（6）支持站内信箱、在线信件交流以及手动匹配。
（7）最终为更多的同学找到比较满意的兼职，解决旧方式的弊端。
本系统最终实现后各部分的关系如下图所示：

2.3项目开发要求：
（1）项目开发规范统一：模块划分，代码编写均遵照小组命名规范文档；
（2）程序优化、安全并要有良好的可扩展性；
（3）用户界面简洁明了、操作简单实用；
（4）与用户保持良好的沟通，及时根据用户新的需求改善系统功能；
2.4 开发工具：
Microsoft Visual Studio.NET 2003
SQL server 2000
3. 具体分析：
3.1 实现概述：
后台程序自动处理工作提供者和工作申请者的信息进行最优匹配并将匹配
信息及时反馈给双方。对于一段时间内未实现自动匹配的用户，系统将自动发
送站内信件提出合理性建议。与此同时向管理员发送请求帮助信息，由管理员
手动匹配或者由用户自己手动匹配。
3.2 学生会及学工部老师：
（1）职能：勤工助学系统的管理者和维护者
（2）具体工作：接受并处理工作提供者提供的工作；
接受并处理工作申请者的请求；
维护网站系统及硬件设施；
将工作中对系统的新要求反馈给开发小组（Rock）；
（3）该用户需要的功能：
 登录：用户名、密码
 管理员的管理动作自动记录在该管理员的管理日志中，该日志对同级别或更高级别管理员公开但只能由最高权限管理员更改、删除；
 添加管理员：由具有更高权限的管理员添加新管理员名称、密码、权限
 删除管理员：由具有更高权限的人删除，彻底清除该管理员的信息
 权限：1. 最高权限：管理整个网站（包括手动删除信息，管理其它管理者，
手动匹配工作提供者与工作申请者，整理所有管理员的管理日志，搜索所有注册者的信息）；
2. 次级权限：分管理工作提供者的管理员、管理工作申请者的管理员。分别
管理各自管辖对象的信息，整理信息。
 搜索注册用户的信息：包括：用户的请求信息（提供工作，申请工作）、用户的真
实姓名、年龄、性别、身份证号、地址（住址或单位）、联系电话（e-mail）、用户身份（学生或工作提供者）；
 察看并处理72小时内未找到匹配的学生的信息
 站内实时信件交流，信件处理
 注销登录，离站
3.3 需人单位或需家教家庭：
（1）描述：作为工作提供者
（2）该用户需要的功能：
 注册：用户名、密码、真实姓名或者具体单位名、身份证号、联系地址、联系电话、
提供的工作类型（选择家教、学校兼职、校外单位等）、工作描述、对应征者的要求（可选年龄段、性别、专业等）——多选有助于更好的自动匹配；
 登录：用用户名和密码登录，登陆后对外显示为在线
 更改注册信息、提供工作的信息、处理信件
 手动查询申请相关工作的同学的信息并选择匹配
 察看并处理自动匹配者的申请者信息，选择申请者后申请者方会有特别提示符表示
已被录用，还可站内回信
 可向管理员发信请求帮助
 注销登录，离站
3.4 广大同学：
（1）描述：作为兼职工作的需求者
（2）该用户需要的功能：
 注册：用户名、密码、真实姓名、年龄、身份证号、联系地址、联系电话或邮件、
院系、申请的工作类型（包括家教、校内兼职、校外兼职等）、个人描述
——填得越细越有助于自动匹配更合适工作
 登录：通过用户名和密码登录，登陆后对外显示为在线
 更改注册信息、想申请的工作信息、个人描述、处理信件
 手动查询提供相关工作类型的用户，选择后进行匹配
 察看并处理自动匹配的工作信息，选择合适者选择，选择后同样会在工作提供方的自动匹配栏里显示，还可站内回信
 可向管理员发信请求帮助
 注销登录，离站
4. 界面设计:
主界面初步设计如下：

5. 特别说明：
5.1 网站的安全性：
保证管理者和注册用户的密码安全，分权限管理，数据库访问控制；
管理员应具有一定网络安全及防黑知识；
5.2 网站可维护性：
网站管理者须懂得一定的服务器应用、SQL数据库应用、硬件维护、IIS配置等方面的技能，必要时由我们对其进行培训
5.3 网站的灵活性：
系统应该具有良好的功能可扩充性，以应对未来用户的更高的要求；
5.4 硬件需求：（首先考虑学校现有硬件条件）
管理员端：Windows 2000 server或以上（学校条件满足）
客户端：建议IE5.0或以上（目前学校内的机房完全满足）
服务器：存储各种数据，处理相应终端请求
中转器：数据传输中转站，减小服务器压力
5.5 用户界面：
人性化、交互性强的网页形式，简单易用，充分合理安排用户功能
各种数据表格格式直观易操作
5.6 数据管理能力要求：
本系统使用SQL server ，可利用其自带的各种功能进行管理。
对不同用户信息和其它信息分类存储，使用索引查找。
目前南开大学在校生大约1万5000人，数据库需能承载至少8千人的
相关信息和其它信息（根据实际情况，暂定为8千人，以后还可拓展）
5.7 故障处理：
系统运行中难免出现一些故障，对此我们提出以下建议和要求：
（1）对用户提交的重要资料及时备份。（如：当用户修改注册资料时要及时更新系统资料备份，以便于系统崩溃后资料的正确恢复。）
（2）当系统数据库发生故障时，及时向用户返回相关故障原因。
（3）公开管理员电子邮箱，联系电话等，以便用户和管理员可以及时联系。
（4）做好数据库和服务器的日常维护工作，出现故障时可与我们联系由我们帮助解决。
好像有图上不来，你自己好好分析分析吧这东西是很不好弄我也头疼
微信小程序的开发需求分析怎么写【完整版需求分析模板_软件需求分析报告模板】 。。
软件需求分析报告模板(完整版)上面已经回答了一份商业计划书模板的具体要素，大象创服作为专业的商业计划书模板服务商，从另外一个角度，给分享一下计划书的注意事项。
其实，投资人每天看的商业计划书数以百计，很多项目是没有办法当面讲给投资人听的。那么，在同等条件下，一个充满诚意的、符合“好”的定义的商业计划书就会相对更有优势一些。

文章插图

完整版 需求分析模板_软件需求分析报告模板

完整版需求分析模板_软件需求分析报告模板