软件需求分析报告文档模板11详解.docx
- 文档编号:24645899
- 上传时间:2023-05-29
- 格式:DOCX
- 页数:15
- 大小:143.62KB
软件需求分析报告文档模板11详解.docx
《软件需求分析报告文档模板11详解.docx》由会员分享,可在线阅读,更多相关《软件需求分析报告文档模板11详解.docx(15页珍藏版)》请在冰豆网上搜索。
软件需求分析报告文档模板11详解
软件需求分析报告文档模板
姓名
日期
1.引言11
1.1编写目的11
1.2项目风险11
1.3文档约定11
1.4预期读者和阅读建议11
1.5产品范围12
1.6参考文献12
2.综合描述12
2.1产品的状况12
2.2产品的功能13
2.3用户类和特性13
2.4运行环境13
2.5设计和实现上的限制13
2.6假设和约束(依赖)14
3.外部接口需求14
3.1硬件接口15
3.2软件接口15
3.3通讯接口16
4.系统功能需求16
4.1说明和优先级16
4.2激励/响应序列17
4.3输入/输出数据17
5.其它非功能需求17
5.1性能需求17
5.2安全措施需求18
5.3安全性需求18
5.4软件质量属性18
5.5业务规则18
5.6用户文档18
6.词汇表19
7.数据定义19
8.分析模型20
1.引言
引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。
1.1编写目的
说明这份软件产品需求分析报告是为哪个软件产品编写的,开发这个软件产品意义、作用、以及最终要达到的意图。
通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格,包括修正和(或)发行版本号,从而对该软件产品进行准确的定义。
如果这份软件产品需求分析报告只与整个系统的某一部分有关系,那么只定义软件产品需求分析报告中说明的那个部分或子系统。
1.2项目风险
具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括:
●任务提出者;
●软件开发者;
●产品使用者。
1.3文档约定
描述编写文档时所采用的标准(如果有标准的话),或者各种排版约定。
排版约定应该包括:
●正文风格;
●提示方式;
●重要符号;
也应该说明高层次需求是否可以被其所有细化的需求所继承,或者每个需求陈述是否都有其自己的优先级。
1.4预期读者和阅读建议
列举本软件产品需求分析报告所针对的各种不同的预期读者,例如,可能包括:
●用户;
●开发人员;
●项目经理;
●营销人员;
●测试人员;
●文档编写入员。
并且描述了文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。
1.5产品范围
说明该软件产品及其开发目的的简短描述,包括利益和目标。
把软件产品开发与企业目标,或者业务策略相联系。
描述产品范围时需注意,可以参考项目视图和范围文档,但是不能将其内容复制到这里。
1.6参考文献
列举编写软件产品需求分析报告时所用到的参考文献及资料,可能包括:
●本项目的合同书;
●上级机关有关本项目的批文;
●本项目已经批准的计划任务书;
●用户界面风格指导;
●开发本项目时所要用到的标淮;
●系统规格需求说明;
●使用实例文档;
●属于本项目的其它己发表文件;
●本软件产品需求分析报告中所引用的文件、资料;
●相关软件产品需求分析报告;
为了方便读者查阅,所有参考资料应该按一定顺序排列。
如果可能,每份资料都应该给出:
●标题名称;
●作者或者合同签约者;
●文件编号或者版本号;
●发表日期或者签约日期;
●出版单位或者资料来源。
2.综合描述
这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。
2.1产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。
说明了该软件产品是否属于下列情况:
●是否是产品系列中的下一成员;
●是否是成熟产品所改进的下一代产品;
●是否是现有应用软件的替代品(升级产品);
●是否是一个新型的、自主型的产品。
如果该软件产品需求分析报告定义的软件系统是:
●大系统的一个组成部分;
●与其它系统和其它机构之间存在基本的相互关系。
那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个大系统相关联的,或者(同时)说明相互关系的存在形式,并且要定义出两者之间的全部接口。
2.2产品的功能
因为将在需求分析报告的第4部分中详细描述软件产品的功能,所以在此只需要概略地总结。
仅从业务层面陈述本软件产品所应具有的主要功能,在描述功能时应该针对每一项需求准确地描述其各项规格说明。
如果存在引起误解的可能,在陈述本软件产品主要功能的作用领域时,也需要对应陈述本软件产品的非作用领域,以利读者理解本软件产品。
为了很好地组织产品功能,使每个读者都容易理解,可以采用列表的方法给出。
也可以采用图形方式,将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示,这种表示方法是很有用的。
参考用户当前管理组织构架,了解各个机构的主要职能,将有助于陈述软件产品的主要功能。
2.3用户类和特性
确定有可能使用该软件产品的不同用户类,并且描述它们相关的特征。
往往有一些软件需求,只与特定的用户类有关。
描述时,应该将该软件产品的重要用户类与非重要用户类区分开。
用户不一定是软件产品的直接使用者,通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。
所以,应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。
2.4运行环境
描述了本软件的运行环境,一般包括:
●硬件平台;
●操作系统和版本;
●支撑环境(例如:
数据库等)和版本;
●其它与该软件有关的软件组件;
●与该软件共存的应用程序。
2.5设计和实现上的限制
确定影响开发人员自由选择的问题,并且说明这些问题为什么成为一种限制。
可能的限制包括下列内容:
●必须使用的特定技术、工具、编程语言和数据库;
●避免使用的特定技术、工具、编程语言和数据库;
●要求遵循的开发规范和标准
例如,如果由客户的公司或者第三方公司负责软件维护,就必须定义转包者所使用的设计符号表示和编码标准;
●企业策略的限制;
●政府法规的限制;
●工业标准的限制;
●硬件的限制
例如,定时需求或存储器限制;
●数据转换格式标淮的限制。
2.6假设和约束(依赖)
列举出对软件产品需求分析报告中,影响需求陈述的假设因素(与己知因素相对立)。
如果这些假设因素不正确、不一致或者被修改,就会使软件产品开发项目受到影响。
这些假设的因素可能包括:
●计划使用的商业组件,或者其它软件中的某个部件;
●假定产品中某个用户界面将符合一个特殊的设计约定;
●有关本软件用户的若干假定(例如:
假定用户会熟练使用SQL语言。
);
●有关本软件开发工作的若干假定(例如:
用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。
);
●有关本软件运行环境的一些问题;
此外,确定本软件开发项目对外部约束因素所存在的依赖。
有关的约束可能包括:
●工期约束;
●经费约束;
●人员约束;
●设备约束;
●地理位置约束;
●其它有关项目约束;
3.外部接口需求
通过本节描述可以确定,保证软件产品能和外部组件正确连接的需求。
关联图仅能表示高层抽象的外部接口,必须对接口数据和外部组件进行详细描述,并且写入数据定义中。
如果产品的不同部分有不同的外部接口,那么应该把这些外部接口的全部详细需求并入到这一部分实例中。
注意:
必须将附加用户类的特征与外部接口需求加以区分,附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求;而外部接口需求描述的是接口本身的需求。
3.1硬件接口
描述待开发的软件产品与系统硬件接口的特征,若有多个硬件接口,则必须全都描述。
接口特征的描述内容可能包括:
●支持的硬件类型;
●软、硬件之间交流的数据;
●控制信息的性质;
●使用的通讯协议;
3.2软件接口
描述该软件产品与其它外部组件的连接,这些外部组件必须明确它们的名称和版本号以资识别,可能的外部组件包括:
●操作系统;
●数据库;
●工具;
●函数库;
●集成的商业组件
说明:
这里所说的“集成的商业组件”,是指与系统集成的商业组件,而不是与软件产品集成的商业组件。
例如:
中间件、消息服务,等等。
描述并且明确软件产品与软件组件之间交换数据或者消息的目的。
描述所需要的服务,以及与内部组件通讯的性质。
确定软件产品将与组件之间共享的数据。
如果必须使用一种特殊的方法来实现数据共享机制,例如:
在多用户系统中的一个全局数据区,那么就必须把它定义为一种实现上的限制。
3.3通讯接口
描述与软件产品所使用的通讯功能相关的需求,包括:
●电子邮件;
●WEB浏览器;
●网络通讯标准或者协议;
●数据交互用电子表格;
必须定义相关的:
●消息格式;
●通讯安全或加密问题;
●数据传输速率;
●同步和异步通讯机制;
4.系统功能需求
需要进行详细的需求记录,详细列出与该系统功能相关的详细功能需求,并且,唯一地标识每一项需求。
这是必须提交给用户的软件功能,使得用户可以使用所提供的功能执行服务或者使用所指定的使用实例执行任务。
描述软件产品如何响应己知的出错条件、非法输入、非法动作。
如果每一项功能需求都能用一项,也只需要用一项测试用例就能进行验证,那么就可以认为功能需求已经适当地进行描述了。
如果某项功能需求找不到合适的测试用例,或者必须使用多项测试用例才能验证,那么该项功能需求的描述必然存在某些问题。
功能需求是根据系统功能,即软件产品所提供的主要服务来组织的。
可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容,也可以便用这些元素的组合。
总而言之,必须选择一种是读者容易理解预期产品的组织方案。
用简短的语句说明功能的名称,例如:
“4.1系统参数管理”。
按照服务组织的顺序,逐条阐述系统功能。
无论说明的是何种功能,都应该针对该系统功能重复叙述4.1~4.3这三个部分。
可以通过各种方式来组织这一部分内容,例如采用:
使用实例、运行模式、用户类、对象类、功能等级等,也可以采用它们的组合。
其最终目的是,让读者容易理解即将开发的软件产品。
一般来说,每个使用实例都对应一个系统功能,因而按照使用实例来组织内容比较容易让用户理解。
对应一些被共享的独立使用实例,可以定义一些公用系统功能。
必须特别注意的是,在2.2节“产品的功能”中描述的全部需求,以及它们的规格说明;必须在某个系统功能描述中有所反映,而且不应重复。
4.1说明和优先级
对该系统功能进行简短的说明,并且指出该系统功能的优先级是:
高、中、还是低。
需要的话,还可以包括对特定优先级部分的评价,例如:
利益、损失、费用和风险,其相对优先等级可以从1(低)到9(高)。
4.2激励/响应序列
列出输入激励(用户动作、来自外部设备的信号或者其它触发)并且定义针对这——功能行为的系统响应序列,这些序列将与使用实例中相关的对话元素相对应。
描述激励/响应序列时,不仅需要描述基本过程,而且应该描述可选(扩充)过程,包括例外(引起任务不能顺序完成的情况称为例外)。
疏忽了可选过程,有可能影响软件产品的功能;如果遗漏例外过程,则有可能会引发系统崩溃。
如果采用流程图来描述激励/响应序列,比较容易让用户理解。
4.3输入/输出数据
列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法,以及相应地输出数据,描述对应区别:
输入数据和输出数据。
当有大量数据需要描述时,也可以分类描述数据,并且注明各项数据的输入、输出属性。
对于每一项数据,均需要描述:
●数据名称;
●实际含义;
●数据类型;
●数据格式;
●数据约束;
对于复杂的处理方法,仅仅给出算法原理是不够的,必须描述详细的计算过程,并且列出每一步具体使用的实际算式;如果计算过程中涉及查表、判断、迭代等处理方法,应该给出处理依据和相关数据。
如果计算方法很简单,也可以将其从略,不加描述。
5.其它非功能需求
在这里列举出所有非功能需求,主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
5.1性能需求
为了满足用户的要求,以更好的体验来进行移动端应用操作,可以在平板电脑以及手机上进行操作,前提是平台系统是安卓2.2~4.4,应用暂时不提供其他系统平台。
1、接口要求
只需下载安装应用即可,无需其他接口要求。
2、输入要求
在应用下载里面准确输入关键字进行下载。
3、输出要求
要求能快速准确输出地图上位置信息。
基本的数据流程和处理流程。
4、启动要快,响应要及时。
通过最优化代码,减少反应时间。
5、内存占用率低。
5.2安全需求
个人信息安全。
进行实名注册,保障用户的信息真实有效。
传输涉及个人信息的文件时,使用加密技术。
在计算机通讯中,采用密码技术将信息隐蔽起来,再将隐蔽后的信息传输出去,使信息在传输过程中即使被窃取或截获,窃取者也不能了解信息的内容,发送方使用加密密钥,通过加密设备或算法,将信息加密后发送出去。
接收方在收到密文后,使用解密密钥将密文解密,恢复为明文。
如果传输中有人窃取,他也只能得到无法理解的密文,从而保证信息传输的安全。
购买健身器材支付安全。
使用第三方软件支付宝进行支付。
对于买家:
请买家一定要在自己收到货且没有异议后去点击确认收到货,如在未收到货或者收到的货物与卖家的描述不符的情况下,就先点击确认收到货,将因此承担不必要的损失。
在付款后请经常查看支付宝提示的“完成本次交易”的剩余时间,如果长时间没有收到货物,请及时向支付宝提出退款申请;在个人提出退款申请后,该申请将在用户收到货物或者争议解决后撤销。
对于卖家:
请卖家一定要在确认买家付款以后,再发货。
如买家还没有付款的情况下,用户就先发货了,没有按照支付宝流程操作,造成的损失由用户本人承担。
如果个人有关于支付宝风险的情况需要向支付宝反馈或举报时,包括不明网站或接收、点击不明来历的邮件、图片、链接、压缩包等。
5.3软件质量属性
应具备快捷性,易学性,可移植行和有效性。
5.4业务规则
注册:
需实名认证,电话验证,提交注册信息需填写验证码。
交易:
需诚信交易,单笔交易额大于1000元,需附加管理员诚信认证。
5.5用户文档
1、安装指南
纸质文档,16开本;
2、用户手册
纸质文档,16开本;
3、在线帮助
对于用户的问题设置专门的人员进行回答解疑。
4、电子文档,与软件产品一同分发、配置;
5、使用教程电子文档,与软件产品一同分发、配置。
6.词汇表
"Process":
进程
进程是一个动态的概念,包括从进程的创建申请,PCB(Process Control Block进程控制块,一般操作系统实现为一个表格(struct))的创建,地址空间的内存分配,模块代码载入并执行,执行完以后进行撤销,整个过程被称为"进程"。
在Win32下,一个进程有4G的逻辑空间。
但我们也常把它作为静态概念来使用,在Win32下,一个EXE的执行就是一个进程(如果它内部又开了新进程,另当别论)。
"Thread":
线程
一个进程拥有至少一个线程。
我们在实现多任务并发的时候通常是建立一个新线程(建立线程的系统开销要小于进程),线程以我们自己的一个函数作为入口,函数执行完毕自动撤销(当然你也可以在执行过程中强制结束该线程)。
数据定义
数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档,其中对每个数据元素和结构都准确描述:
含义、类型、数据大小、格式、计量单位、精度以及取值范围。
数据定义的维护独立于软件需求规格说明,并且在软件产品开发和维护的任何阶段,均向风险承担者开放。
如果为软件开发项目创建一个独立的数据定义,而不是为每一项特性描述有关的数据项,有利于避免冗余和不一致性。
但是却不利于多人协同编写需求分析报告,容易遗漏数据,也不方便阅读。
因此还是建议为每个特性描述有关的数据项,汇总数据项创建数据定义,再根据数据定义复核全部数据,使得它们的名称和含义完全一致。
必须注意的是,为了避免二义性,在汇总数据项时应该根据数据项所代表的实际意义汇总,而不是根据数据项的名称汇总。
在数据定义中,每个数据项除了有一个中文名称外,还应该为它取一个简短的英文名称,该英文名称应该符合命名规范,因为在软件开发时将沿用该英文名称。
可以使用等号表示数据项,名称写在左边,定义写在右边。
常见数据项的描述方式如下:
原数据元素
一个原数据元素是不可分解的,可以将一个数量值赋给它。
定义原数据元素必须确定其
含义、类型、数据大小、格式、计量单位、精度以及取值范围。
采用以星号为界的一行
注释文本,描述原数据元素的定义。
7.分析模型
这是一个可选部分,包括或涉及到相关的分析模型,例如:
●数据流程图;
●类图;
●状态转换图;
●实体-关系图。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 分析 报告 文档 模板 11 详解