软件需求分析模板

目 录
1. 引言 1
1.1. 背景 1
1.2. 参考资料 1
1.3. 假定和约束 1
1.4. 用户的特点 1
2. 功能需求 1
2.1. 系统范围 1
2.2. 系统体系结构(二层架构的系统可剪裁本小节) 1
2.3. 系统总体流程 2
2.4. 需求分析 2
2.4.1. XXXXXXX(功能需求名称) 2
2.4.1.1. 功能描述 2
2.4.1.2. 业务建模 2
2.4.1.3. 用例描述 3
2.4.1.4. 用户界面 5
2.4.2. XXXXXXX(功能需求名称) 5
3. 非功能需求 5
3.1. 性能要求 5
3.1.1. 精度 5
3.1.2. 时间特性要求 6
3.1.3. 输人输出要求 6
3.2. 数据管理能力要求 6
3.3. 安全保密性要求 6
3.4. 灵活性要求 6
3.5. 其他专门要求 6
4. 运行环境规定 6
4.1. 设备 6
4.2. 支持软件 7
4.3. 接口 7
4.4. 控制 7
5. 需求跟踪 7
6. 签批单 7 
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)。

6. 签批单
我已阅读上述软件需求规格说明书,我将严格遵守说明书中的条款,并保证全力支持该规格说明书的实施。
执行主管: 
日期
技术主管: 
日期
项目组长: 
日期
用户代表: 
日期
开发人员代表: 
日期
小组成员: 
日期
小组成员: 
日期

时间: 2024-10-27 12:31:28

软件需求分析模板的相关文章

项目管理理论与实践(2)——软件需求分析

一.需求分析的目的 1. 马斯洛的需求层次理论 具体可以参考:(http://baike.baidu.com/view/295140.htm) 2. 需求分析的目的 1)与相关干系人在工作内容方面达成并保持一致 2)使设计.开发.测试人员能够更清楚地了解需求 3)定义系统边界,形成需求基线 4)为估算系统的规模.工作量.成本和进度提供基础 5)为开发计划的形成提供范围(SOW)基础 二.需求工程概述 1. 什么是需求工程?用一张图可以形象的表示 需求也属于一门工程学,需求工程包括需求开发.需求管

需求分析模板

1. 引言       引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读.理解和解释这份文档.1.1 编写目的       说明这份软件产品需求分析报告是为哪个软件产品编写的,开发这个软件产品意义.作用.以及最终要达到的意图.通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格,包括修正和(或)发行版本号,从而对该软件产品进行准确的定义.       如果这份软件产品需求分析报告只与整个系统的某一部分有关系,那么只定义软件产品需求分析报告中

【转】软件需求分析方法

软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的.可验证的一个基本依据. 软件需求分析是一个项目的开端,也是项目实施最重要的关键点.据有关的机构分析结果表明,我们设计的软件产品存在不完整性.不正确性等问题80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出.因此,一个项目的成功软件需求分析是关键的一步. 一. 软件需求分析理论 如果我们用数学方法来

软件需求分析

功能需求 1.用例分析是要求每一个子功能点都要有一个用例 例如:线路增加,线路删除,线路修改,线路查询.每一个功能描述一个用例 线路删除用例: 2.(后置条件是指:执行基本流程获得成功以后所达到的状态(条件).体现的是执行该用例的最终目的.)   管理员用户登陆 在注册完成后,以管理员账户登陆进入管理员界面,管理员用户登陆功能需求如下表所示: 表2.1“管理员用户登陆”功能需求分析用例 功能点编号 X3L101 功能点名称 管理员用户登陆 角色 管理员 功能说明 管理员用户能通过本功能点完成登陆

软件需求分析之猫咪记单词

软件需求分析之猫咪记单词 一.软件设计目标 目前,所有学生都面临学习英语的问题.在大学生中学生对于手机的应用十分频繁,所以我们设置单词解屏,可以使学生拿起手机就学习英语,提高学习效率,应用零散时间. 二.面向用户 本单词解屏面向的对象为所有会学习到英语的学生:四级.六级.托福.雅思等.主要是要考四六级的大学生,或者要出国学习的学生,或者在生活中热爱英语的人. 三.功能实现 我们主要有词库选择,词数设置,已学词量三个功能.词库选择:对词汇的类型进行选择,如四六级.托福.雅思等. 词数设置:对解屏的

软件需求分析方法

软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的.可验证的一个基本依据. 软件需求分析是一个项目的开端,也是项目实施最重要的关键点.据有关的机构分析结果表明,我们设计的软件产品存在不完整性.不正确性等问题80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出.因此,一个项目的成功软件需求分析是关键的一步. 一. 软件需求分析理论 如果我们用数学方法来

软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二 管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用. 客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集需求有着不可替代的必要性,所以导致项目最终失败的两个原因,一个是缺乏用户参与,另一个是不完整的需求规格说明. 在进行需求分析时,只有系统的实际使用者才能清楚的描述他们要用此系统

软件需求分析教程阅读笔记一

软件需求分析教程阅读笔记一 许多工程项目不能按时完成或者最后导致失败的一个很大的原因就是弄不清需求是什么,不能准确理解客户的需求意图,所以前期做好需求调研是一件非常重要的工作,是一件与系统代码开发占有同等比重的工作. 读这本书的同时,要注意实践过程,不必非得要从一个新项目开始应用,可以找一个以前的或者是现在正在进行的项目,根据书中所讲,着手开始实践. 软件需求就是需要知道是什么和为什么. 在软件开发当中遇到的许多问题,都是由于收集,编写,协商,修改产品需求过程中的手续和做法失误所带来的.需求分析

你会做软件需求分析吗?

有经验的测试人员告诉我们,探求用户需求是测试工作的第一前提.这是因为,只有明确需求,才可以针对测试工作进行计划和实施,才能开始后续的步骤. 但是实际工作中,明确的需求并不在多数,往往需要测试人员开启脑补能力,针对各种原始需求不停地挖掘,才能知道用户到底要干什么? 借助精神分析学派的潜意识理论,我们大致可以将用户需求分为显性需求和隐性需求. 显性需求一般是用户可以明确感受到并且可以表达出来的,可以进行针对性满足的需求,通俗的说吧,就是你饿了,我请你吃饭,馒头加咸菜,保证你吃饱:如果我不给你,你就会