关闭

关闭

关闭

封号提示

内容

首页 软件开发文档模板.doc

软件开发文档模板.doc

软件开发文档模板.doc

上传者: 西北风 2012-09-05 评分 0 0 0 0 0 0 暂无简介 简介 举报

简介:本文档为《软件开发文档模板doc》,可适用于IT/计算机领域,主题内容包含软件开发文档模板目录范围总体要求总体功能要求软件开发平台要求软件项目的开发实施过程管理要求软件项目实施过程总体要求软件项目实施变更要求软件项目实施里符等。

软件开发文档模板目录范围总体要求总体功能要求软件开发平台要求软件项目的开发实施过程管理要求软件项目实施过程总体要求软件项目实施变更要求软件项目实施里程碑控制软件开发软件的需求分析需求分析需求分析报告的编制者需求报告评审需求报告格式软件的概要设计概要设计编写概要设计的要求概要设计报告的编写者概要设计和需求分析、详细设计之间的关系和区别概要设计的评审概要设计格式软件的详细设计详细设计特例详细设计的要求数据库设计详细设计的评审详细设计格式软件的编码软件编码软件编码的要求编码的评审编程规范及要求软件的测试软件测试测试计划软件的交付准备交付清单软件的鉴定验收软件的鉴定验收验收人员验收具体内容软件验收测试大纲培训系统应用培训系统管理的培训(可选)附录A软件需求分析报告文档模板附录B软件概要设计报告文档模板附录C软件详细设计报告文档模板附录D软件数据库设计报告文档模板附录E软件测试(验收)大纲范围本指南用于指导软件开发者为南京市交通局开发软件项目的过程通过规范软件项目承担单位的开发过程达到提高软件质量降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考在进行具体软件开发时开发者可根据实际情况采编写但必须提供双方约定的文档文档中约定的内容必须描述清楚。总体要求总体功能要求网络应用环境以InternetIntranet技术为核心。开发者应在充分分析需求的基础上选择采用BS结构或者CS结构。软件系统的数据库应依照《南京市交通局信息化数据库建设规范》进行设计和建设。本指南中没有规定开发者采用何种具体的软件工程开发方法开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法但建议开发商使用面向对象软件工程的方法如:采用目前被广泛使用的RUP(RationalUnifiedProcess)方法来进行分析、设计和开发。软件开发平台要求开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运行。目前软件平台为:数据库管理系统:Oraclei以上版本中间件(应用服务器)系统:IBMWebSphereOA系统:LotusDominoNotes网络架构:完全支持TCPIP协议开发工具或技术体系:为保证软件的上下兼容性开发者应选择比较通用的开发工具的较新版本进行开发如MicrosoftVisualStudioNetBorlandDelphiCBuilder,或JEE(JavaPatformEnterpriseEdition)等。软件项目的开发实施过程管理要求软件项目实施过程总体要求(一)开发者提交软件开发工作大纲交通局组织专家组对工作大纲进行评审并提出整改意见。(二)通过评审后开发者根据整改意见完善工作大纲经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行在开发过程中开发者需分阶段提交相关文档。(三)在软件开发工作完成后开发者应向交通局提交完整的软件文档交通局组织验收组对软件进行验收审查。软件项目实施变更要求在开发过程中需求或设计不可避免地需要发生变更相关变更必须经过交通局书面同意方可进行。在需求或设计发生变更时需要对原有文档进行修改并提供完整的变更记录以使变更处于可控制的状态。变更单如下表所示:表变更单需求变更申请申请变更的需求文档输入名称版本日期等信息变更的内客及其理由评估需求变更将对项目造成的影响申请人签字变更申请的审批意见项目经理签字审批意见:签字日期客户签字(合同项目)审批意见:签字日期更改需求文档变更后的需求文档输入名称版本完成日期等信息更改人签字重新评审需求文档需求评审小组签字评审意见:签字日期变更结束项目经理签字签字日期软件项目实施里程碑控制交通局将分四个阶段进行把关召开专家审查会。(一)需求分析(结合原型进行审查)确认(二)概要设计数据库设计(三)预验收(试运行后)(四)正式验收(推广使用后)。软件开发合同签订以后项目承担单位即可组织项目组进行软件开发工作。软件开发必须严格按照软件工程的要求进行。开发过程包括开发者的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。软件的需求分析需求分析首先开发者和交通局应共同对交通局的应用需求作充分的调研提交完整的需求分析报告。在需求分析报告中必须描述的基本问题是:功能、性能、强加于实现的设计限制、属性、外部接口。应当避免把设计或项目需求写入需求分析报告中。它必须说明由软件获得的结果而不是获得这些结果的手段。软件需求可以用若干种方法来表达如通过输入、输出说明使用代表性的例子用规范化的模型。开发者应尽可能地使用模型的方式因为这是表达复杂需求的精确和有效的方法。比如用统一建模语言(UML)来描述需求。编写需求分析报告的要求a.无歧义性对最终产品的每一个特性用某一术语描述若某一术语在某一特殊的行文中使用时具有多种含义那么应对该术语的每种含义做出解释并指出其适用场合。b.完整性需求分析报告应该包括全部有意义的需求无论是关系到功能的、性能的、设计约束的、还是关系到外部接口方面的需求对所有可能出现的输入数据的响应予以定义要对合法和非合法的输入值的响应做出规定填写全部插图、表、图示标记等定义全部术语和度量单位。c.可验证性需求分析报告描述的每一个需求应是可以验证的。可以通过一个有限处理过程来检查软件产品是否满足需求。d.一致性在需求分析报告中的各个需求的描述不能互相矛盾。e.可修改性需求分析报告应具有一个有条不紊、易于使用的内容组织没有冗余即同一需求不能在需求分析报告中出现多次。f.可追踪性每一个需求的源流必须清晰在进一步产生和改变文件编制时可以方便地引证每一个需求。g.运行和维护阶段的可使用性需求分析报告必须满足运行和维护阶段的需要。在需求分析报告要写明功能的来源和目的。需求分析报告的编制者需求分析报告应由交通局和开发者双方共同完成。其中:交通局负责根据实际需要提出希望软件实现的功能软件开发者根据交通局提出的性能需求结合软件开发编写需求分析。需求报告评审在软件需求分析工作完成后软件开发者应向交通局提交《软件需求分析报告》。交通局组织有关人员对需求进行评审以决定软件需求是否完善和恰当。评审完成后就可以进入软件的设计阶段。需求报告格式《软件需求分析报告》需按一定的格式进行编写具体的《软件需求分析报告》文档编写模板请见附录A。软件的概要设计概要设计在交通局和开发者双方认可的《需求分析报告》基础上开发者进行下步的工作。首先开发者需要对软件系统进行概要设计即系统设计。概要设计需要对软件系统的设计进行考虑包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等为软件的详细设计提供基础。编写概要设计的要求a.一致性概要设计的要求应该与需求分析报告所描述的需求一致。同时概要设计的各项要求之间也应该一致。b.合理性概要设计所提出的设计方法和标准应该是合理的、恰当的。c.可追踪性对概要设计所提出的各项要求应该可以得到它的清晰的源流即在需求分析报告客户有明确的需求描述。d.可行性根据概要设计进行详细设计、操作和维护应该是可行的。概要设计报告的编写者概要设计报告由开发者根据需求分析报告的要求进行编写。概要设计和需求分析、详细设计之间的关系和区别需求分析不涉及具体的技术实现而概要设计注重于从宏观上和框架上来描述采用何种技术手段、方法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计是编码的依据。概要设计是指导详细设计的依据。概要设计的评审在软件概要设计工作完成后软件开发者应向交通提交《软件系统概要设计报告》。在交通局对《概要设计报告》评审通过后即可进入详细设计阶段。概要设计格式《软件系统概要设计报告》需按一定的格式进行编写具体的《软件系统概要设计报告》文档编写模板请见附录B。软件的详细设计详细设计在概要设计的基础上开发者需要进行软件系统的详细设计。在详细设计中描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细能够根据详细设计报告进行编码。特例如果软件系统比较简单层次较少可以不必进行专门的详细设计而和概要设计结合起来。详细设计的要求a.一致性详细设计的要求应该与需求分析报告所描述的需求、与概要设计一致。同时详细设计的各项要求之间也应该是一致的。b.合理性详细设计所提出的设计方法和标准应该是合理的、恰当的。c.可追踪性对详细设计所提出的各项要求应该可以得到它的清晰的源流即可在需求分析报告、概要设计报告中有明确的需求描述。d.可行性根据详细设计进行编码、测试、操作和维护应该是可行的。数据库设计如果软件产品需要使用到数据库软件的详细设计应包括对数据库的设计。数据库设计应在软件的需求分析、概要设计完成之后、详细设计的其它工作之前进行。在进行数据库设计时应当按照交通局制定的《南京市交通局信息化数据库建设规范》要求进行。详细设计的评审在软件详细设计完成后软件开发者应向交通局提交《软件系统数据库设计报告》和《软件系统详细设计报告》。在交通局对《软件系统数据库设计报告》、《软件系统详细设计报告》评审通过后即可进入软件编码阶段。详细设计格式《软件系统详细设计报告》、《软件系统数据库设计报告》需按一定的格式进行编写具体的《软件系统详细设计报告》文档编写模板和《软件系统数据库设计报告》文档编写模板请见附录C、附录D。软件的编码软件编码在软件编码阶段开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求开始具体的编写程序工作分别实现各模块的功能从而实现对目标系统的功能、性能、接口、界面等方面的要求。软件编码的要求a.模块化编码b.代码可读性c.可维护性d.模块接口标准化e.界面风格统一e.注释的应用编码的评审为了尽早发现软件中的障碍提高软件产品的质量开发者在编码的过程中应该强调代码评审工作。将代码评审报告作为文档的一部分提交给交通局。编程规范及要求为了提高编程实现的质量软件的程序设计必须遵照国家颁布的相关编程规范。主要内容包括:规范化的程序内部文档、数据结构的详细说明、清晰的语句结构、编码规范。编码规范的内容包括命名规范、界面规范、提示及帮助信息规范、热键定义等。其中数据库部分应遵守《南京市交通局信息化数据库建设规范》的要求。在软件编码的同时应进行单元测试。软件的测试软件测试为了尽早发现软件产品中的错误从而达到提高软件质量、降低软件维护的费用开发者应在编码过程中对各个模块的程序代码进行单元测试系统集成时进行集成测试系统集成完成后对整个软件进行系统测试。单元测试是在软件开发过程中针对程序模块进行正确性检验。集成测试是在单元测试的基础上将所有模块按照设计要求组装成系统或子系统对模块组装过程和模块接口进行正确性检验。软件系统测试不仅是检测软件的整体行为表现从另一个侧面看也是对软件开发设计的再确认。进行软件系统测试工作时。测试主要包括界面测试、可用性测试、功能测试、稳定性(强度)测试、性能测试、强壮性(恢复)测试、逻辑性测试、破坏性测试、安全性测试等。开发者针对单元测试集成测试系统测试分别制定《测试计划》。集成测试需要根据需求分析报告和概要设计制作测试用例并须经过评审。软件测试按照《测试计划》、《需求分析报告》的要求进行最后形成《软件测试报告》。测试计划在软件编码开始之前开发者应向交通局提交《测试计划》在软件交付时开发者应向交通局提交《软件测试报告》以确保开发者的软件得到了充分的测试。开发的软件必须经过充分的测试证明其符合设计要求、运行稳定、安全可用方可交付交通局。软件的交付准备交付清单在软件测试证明软件达到要求后软件开发者应向交通局提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容在需要时还应举例说明。软件的鉴定验收软件的鉴定验收在软件开发完成后为了确保软件是按照需求分析的要求进行开发的保证软件产品的质量需要对软件产品进行鉴定验收。在开发者如期交付软件后由交通局负责确定具体的鉴定验收日期。验收人员由交通局聘请具有一定的分析、设计、编程和软件测试经验的验收组长和其他专业人员组成。验收组设组长一名(可设有副组长)负责整个验收的计划、组织工作。验收具体内容验收内容应该包括:合法性检查、文档检查、软件一致性检查、软件系统测试与测试结果评审等几项工作。合法性检查检查软件开发工具是否合法、使用的函数库、控件、组件是否有合法的发布许可。文档检查检查开发者提交的文档必须齐全质量是否过关。需要开发者提供的文档包括:项目实施计划详细技术方案软件需求规格说明书(STP)(含数据字典)概要设计说明书(PDD)详细设计说明书(DDD)(含数据库设计说明书)软件测试计划(STP)(含测试用例)软件测试报告(STR)用户手册(SUM)(含操作、使用、维护、应急处理手册)源程序(SCL)(不可修改的电子文档)项目实施计划(PIP)项目开发总结(PDS)软件质量保证计划(SQAP)此外验收组可以根据需要对其它文档(如软件配置计划、项目进展报表、阶段评审报表等)进行检查。文档的质量根据完备性、正确性、简明性、可追踪性、自说明性、规范件等方面进行踪合评定。验收需要对软件代码进行检查以确保其符合规范并检查其一致性。软件验收测试大纲在软件进行鉴定验收前开发者需按照一定的格式编写《软件验收测试大纲》具体的格式请见附录E。培训系统应用培训主要培训内容包括:系统操作使用、业务管理流程。培训对象:应用操作人员。系统管理的培训(可选)主要培训内容包括:系统安装、调试、维护系统管理。培训对象:系统管理人员。开发者应详细列出培训计划包括培训内容、教材、时间和人员等。附录A软件需求分析报告文档模板引言编写目的项目风险文档约定预期读者和阅读建议产品范围参考文献综合描述产品的状况产品的功能用户类和特性运行环境设计和实现上的限制假设和约束(依赖)外部接口需求用户界面硬件接口软件接口通讯接口系统功能需求说明和优先级激励/响应序列输入/输出数据其它非功能需求性能需求安全措施需求安全性需求软件质量属性业务规则用户文档词汇表数据定义分析模型待定问题列表引言引言是对这份软件产品需求分析报告的概览是为了帮助阅读者了解这份文档是如何编写的并且应该如何阅读、理解和解释这份文档。编写目的说明这份软件产品需求分析报告是为哪个软件产品编写的开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格包括修正和(或)发行版本号从而对该软件产品进行准确的定义。如果这份软件产品需求分析报告只与整个系统的某一部分有关系那么只定义软件产品需求分析报告中说明的那个部分或子系统。项目风险具体说明本软件开发项目的全部风险承担者以及各自在本阶段所需要承担的主要风险首要风险承担者包括:任务提出者软件开发者产品使用者。文档约定描述编写文档时所采用的标准(如果有标准的话)或者各种排版约定。排版约定应该包括:正文风格提示方式重要符号也应该说明高层次需求是否可以被其所有细化的需求所继承或者每个需求陈述是否都有其自己的优先级。预期读者和阅读建议列举本软件产品需求分析报告所针对的各种不同的预期读者例如可能包括:用户开发人员项目经理营销人员测试人员文档编写入员。并且描述了文档中其余部分的内容及其组织结构并且针对每一类读者提出最适合的文档阅读建议。产品范围说明该软件产品及其开发目的的简短描述包括利益和目标。把软件产品开发与企业目标或者业务策略相联系。描述产品范围时需注意可以参考项目视图和范围文档但是不能将其内容复制到这里。参考文献列举编写软件产品需求分析报告时所用到的参考文献及资料可能包括:本项目的合同书上级机关有关本项目的批文本项目已经批准的计划任务书用户界面风格指导开发本项目时所要用到的标淮系统规格需求说明使用实例文档属于本项目的其它己发表文件本软件产品需求分析报告中所引用的文件、资料相关软件产品需求分析报告为了方便读者查阅所有参考资料应该按一定顺序排列。如果可能每份资料都应该给出:标题名称作者或者合同签约者文件编号或者版本号发表日期或者签约日期出版单位或者资料来源。综合描述这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。产品的状况描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况:是否是产品系列中的下一成员是否是成熟产品所改进的下一代产品是否是现有应用软件的替代品(升级产品)是否是一个新型的、自主型的产品。如果该软件产品需求分析报告定义的软件系统是:大系统的一个组成部分与其它系统和其它机构之间存在基本的相互关系。那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个大系统相关联的或者(同时)说明相互关系的存在形式并且要定义出两者之间的全部接口。产品的功能因为将在需求分析报告的第部分中详细描述软件产品的功能所以在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能在描述功能时应该针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能在陈述本软件产品主要功能的作用领域时也需要对应陈述本软件产品的非作用领域以利读者理解本软件产品。为了很好地组织产品功能使每个读者都容易理解可以采用列表的方法给出。也可以采用图形方式将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示这种表示方法是很有用的。参考用户当前管理组织构架了解各个机构的主要职能将有助于陈述软件产品的主要功能。用户类和特性确定有可能使用该软件产品的不同用户类并且描述它们相关的特征。往往有一些软件需求只与特定的用户类有关。描述时应该将该软件产品的重要用户类与非重要用户类区分开。用户不一定是软件产品的直接使用者通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。所以应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。运行环境描述了本软件的运行环境一般包括:硬件平台操作系统和版本支撑环境(例如:数据库等)和版本其它与该软件有关的软件组件与该软件共存的应用程序。设计和实现上的限制确定影响开发人员自由选择的问题并且说明这些问题为什么成为一种限制。可能的限制包括下列内容:必须使用的特定技术、工具、编程语言和数据库避免使用的特定技术、工具、编程语言和数据库要求遵循的开发规范和标准例如如果由客户的公司或者第三方公司负责软件维护就必须定义转包者所使用的设计符号表示和编码标准企业策略的限制政府法规的限制工业标准的限制硬件的限制例如定时需求或存储器限制数据转换格式标淮的限制。假设和约束(依赖)列举出对软件产品需求分析报告中影响需求陈述的假设因素(与己知因素相对立)。如果这些假设因素不正确、不一致或者被修改就会使软件产品开发项目受到影响。这些假设的因素可能包括:计划使用的商业组件或者其它软件中的某个部件假定产品中某个用户界面将符合一个特殊的设计约定有关本软件用户的若干假定(例如:假定用户会熟练使用SQL语言。)有关本软件开发工作的若干假定(例如:用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。)有关本软件运行环境的一些问题此外确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括:工期约束经费约束人员约束设备约束地理位置约束其它有关项目约束外部接口需求通过本节描述可以确定保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口必须对接口数据和外部组件进行详细描述并且写入数据定义中。如果产品的不同部分有不同的外部接口那么应该把这些外部接口的全部详细需求并入到这一部分实例中。注意:必须将附加用户类的特征与外部接口需求加以区分附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求而外部接口需求描述的是接口本身的需求。用户界面陈述需要使用在用户界面上的软件组件描述每一个用户界面的逻辑特征。必须注意这里需要描述的是用户界面的逻辑特征而不是用户界面。以下是可能包括的一些特征:将要采用的图形用户界面(GUl)标准或者产品系列的风格有关屏幕布局或者解决方案的限制将要使用在每一个屏幕(图形用户界面)上的软件组件可能包括:n选单n标准按钮n导航链接n各种功能组件n消息栏快捷键各种显示格式的规定可能包括:n不同情况下文字的对齐方式n不同情况下数字的表现格式与对齐方式n日期的表现方法与格式n计时方法与时间格式n等等。错误信息显示标准对于用户界面的细节例如:一个特定对话框的布局应该写入具体的用户界面设计说明中而不能写入软件需求规格说明中。如果采用现成的、合适的用户界面设计规范(标准)或者另文描述可以在这里直接说明并且将其加入参考文献。硬件接口描述待开发的软件产品与系统硬件接口的特征若有多个硬件接口则必须全都描述。接口特征的描述内容可能包括:支持的硬件类型软、硬件之间交流的数据控制信息的性质使用的通讯协议软件接口描述该软件产品与其它外部组件的连接这些外部组件必须明确它们的名称和版本号以资识别可能的外部组件包括:操作系统数据库工具函数库集成的商业组件说明:这里所说的“集成的商业组件”是指与系统集成的商业组件而不是与软件产品集成的商业组件。例如:中间件、消息服务等等。描述并且明确软件产品与软件组件之间交换数据或者消息的目的。描述所需要的服务以及与内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必须使用一种特殊的方法来实现数据共享机制例如:在多用户系统中的一个全局数据区那么就必须把它定义为一种实现上的限制。通讯接口描述与软件产品所使用的通讯功能相关的需求包括:电子邮件WEB浏览器网络通讯标准或者协议数据交互用电子表格必须定义相关的:消息格式通讯安全或加密问题数据传输速率同步和异步通讯机制系统功能需求需要进行详细的需求记录详细列出与该系统功能相关的详细功能需求并且唯一地标识每一项需求。这是必须提交给用户的软件功能使得用户可以使用所提供的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。如果每一项功能需求都能用一项也只需要用一项测试用例就能进行验证那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例或者必须使用多项测试用例才能验证那么该项功能需求的描述必然存在某些问题。功能需求是根据系统功能即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容也可以便用这些元素的组合。总而言之必须选择一种是读者容易理解预期产品的组织方案。用简短的语句说明功能的名称例如:“系统参数管理”。按照服务组织的顺序逐条阐述系统功能。无论说明的是何种功能都应该针对该系统功能重复叙述~这三个部分。可以通过各种方式来组织这一部分内容例如采用:使用实例、运行模式、用户类、对象类、功能等级等也可以采用它们的组合。其最终目的是让读者容易理解即将开发的软件产品。一般来说每个使用实例都对应一个系统功能因而按照使用实例来组织内容比较容易让用户理解。对应一些被共享的独立使用实例可以定义一些公用系统功能。必须特别注意的是在节“产品的功能”中描述的全部需求以及它们的规格说明必须在某个系统功能描述中有所反映而且不应重复。说明和优先级对该系统功能进行简短的说明并且指出该系统功能的优先级是:高、中、还是低。需要的话还可以包括对特定优先级部分的评价例如:利益、损失、费用和风险其相对优先等级可以从(低)到(高)。激励/响应序列列出输入激励(用户动作、来自外部设备的信号或者其它触发)并且定义针对这功能行为的系统响应序列这些序列将与使用实例中相关的对话元素相对应。描述激励/响应序列时不仅需要描述基本过程而且应该描述可选(扩充)过程包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程有可能影响软件产品的功能如果遗漏例外过程则有可能会引发系统崩溃。如果采用流程图来描述激励/响应序列比较容易让用户理解。输入/输出数据列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法以及相应地输出数据描述对应区别:输入数据和输出数据。当有大量数据需要描述时也可以分类描述数据并且注明各项数据的输入、输出属性。对于每一项数据均需要描述:数据名称实际含义数据类型数据格式数据约束对于复杂的处理方法仅仅给出算法原理是不够的必须描述详细的计算过程并且列出每一步具体使用的实际算式如果计算过程中涉及查表、判断、迭代等处理方法应该给出处理依据和相关数据。如果计算方法很简单也可以将其从略不加描述。其它非功能需求在这里列举出所有非功能需求主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。性能需求阐述不同应用领域对软件产品性能的需求并且说明提出需求的原理或者依据以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求如果需要可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定:相互合作的用户数量系统支持的并发操作数量响应时间与实时系统的时间关系:容量需求n存储器n磁盘空间n数据库中表的最大行数。安全措施需求详尽陈述与软件产品使用过程中可能发生的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。安全性需求详尽陈述与系统安全性、完整性问题相关的需求或者与个人隐私问题相关的需求。这些问题将会影响到软件产品的使用和软件产品所创建或者使用的数据的保护。定义用户身份认证或备授权需求。明确软件产品必须满足的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。一个典型的软件系统安全需求范例如下:“每个用户在第一次登录后必须更改他的系统预置登录密码系统预置的登录密码不能重用。”软件质量属性详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点例如:易用性优于易学性或者可移植性优于有效性。业务规则列举出有关软件产品的所有操作规则例如:那些人在特定环境下可以进行何种操作。这些本身不是功能需求但是他们可以暗示某些功能需求执行这些规则。一个业务规则的范例如下:“进行达到或者超过元人民币的储蓄业务时必须通过附加的管理员认证。”列举业务规则时可以根据规则的数量选取合适的编目方式。用户文档列举出将与软件产品一同交付的用户文档并且明确所有己知用户文档的交付格式或标准例如:安装指南纸质文档开本用户手册纸质文档开本在线帮助电子文档与软件产品一同分发、配置使用教程电子文档与软件产品一同分发、配置。词汇表列出本文件中用到的专业术语的定义以及有关缩写的定义(如有可能列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析报告要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语是指业务层面上的专业术语而不是软件专业或者计算机专业的术语。但是对于无法回避的软件专业或者计算机专业术语也应该列入词汇表并且加以准确定义。数据定义数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档其中对每个数据元素和结构都准确描述:含义、类型、数据大小、格式、计量单位、精度以及取值范围。数据定义的维护独立于软件需求规格说明并且在软件产品开发和维护的任何阶段均向风险承担者开放。如果为软件开发项目创建一个独立的数据定义而不是为每一项特性描述有关的数据项有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告容易遗漏数据也不方便阅读。因此还是建议为每个特性描述有关的数据项汇总数据项创建数据定义再根据数据定义复核全部数据使得它们的名称和含义完全一致。必须注意的是为了避免二义性在汇总数据项时应该根据数据项所代表的实际意义汇总而不是根据数据项的名称汇总。在数据定义中每个数据项除了有一个中文名称外还应该为它取一个简短的英文名称该英文名称应该符合命名规范因为在软件开发时将沿用该英文名称。可以使用等号表示数据项名称写在左边定义写在右边。常见数据项的描述方式如下:原数据元素一个原数据元素是不可分解的可以将一个数量值赋给它。定义原数据元素必须确定其含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行注释文本描述原数据元素的定义。选择项选择项是一种只可以取有限离散值的特殊原数据元素描述时一一枚举这些值并用方括号括起来写在原数据元素的定义前。在两项离散值之间使用管道符分隔。组合项组合项是一个数据结构或者记录其中包含了多个数据项。这些数据项可以是原数据元素也可以是组合数据项各数据项之间用加号连接。其中每个数据项都必须是数据定义中定义过的结构中也可以包括其它结构但是绝对不允许递归。如果数据结构中有可选项使用圆括号把该项括起来。重复项重复项是组合项的一种特例其中有一项将有多个实例出现在数据结构中使用花括号把该项括起来。如果知道该项可能允许的范围就按“最小值:最大值”的形式写在花括号前。分析模型这是一个可选部分包括或涉及到相关的分析模型例如:数据流程图类图状态转换图实体关系图。待定问题列表编辑一张在软件产品需求分析报告中待确定问题时的列表把每一个表项都编上号以便跟踪调查。附录B软件概要设计报告文档模板引言编写目的项目风险预期读者和阅读建议参考资料设计概述限制和约束设计原则和设计要求系统逻辑设计系统组织设计系统结构设计系统特性表系统特性结构图系统接口设计系统接口表系统接口传输协议说明系统完整性设计系统出错处理设计系统出错处理表维护处理过程表技术设计系统开发技术说明表开发技术应用说明数据库设计词汇表进度计划引言引言是对这份软件系统概要设计报告的概览是为了帮助阅读者了解这份文档是如何编写的并且应该如何阅读、理解和解释这份文档。编写目的说明这份软件系统概要设计报告是基于哪份软件产品需求规格说明书编写的开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统概要设计报告详尽说明了该软件产品的软件结构包括数据库结构和出错处理从而对该软件产品的结构的描述。如果这份软件系统概要设计报告只与整个系统的某一部分有关系那么只定义软件系统概要设计报告中说明的那个部分或子系统。项目风险具体说明本软件开发项目的全部风险承担者以及各自在本阶段所需要承担的主要风险首要风险承担者包括:任务提出者软件开发者产品使用者。预期读者和阅读建议列举本软件系统概要设计报告所针对的各种不同的预期读者例如可能的读者包括:用户开发人员项目经理营销人员测试人员文档编写人员等等。描述文档中其余部分的内容及其组织结构并且针对每一类读者提出最适合的文档阅读建议。参考资料列举编写软件产品概要设计报告时所用到的参考文献及资料可能包括:本项目的合同书上级机关有关本项目的批文本项目已经批准的计划任务书用户界面风格指导开发本项目时所要用到的标准系统规格需求说明使用实例文档属于本项目的其它已发表文件本软件系统概要设计报告中所引用的文件、资料:相关软件系统概要设计报告:等等。为了方便读者查阅所有参考资料应该按一定顺排列。如果可能每份资料都应该给出:标题名称作者或者合同签约者文件编号或者版本号发表日期或者签约日期出版单位或者资料来源。设计概述本节描述现有开发条件和需要实现的目标说明进行概要设计时应该遵循的设计原则和必须采用的设计方法。限制和约束简要描述起到限制和约束作用的各种可能存在的条件例如:技术条件资金状况开发环境(包括:工具和平台)时间限制等等。并且说明在上述条件下应该实现的系统目标设计原则和设计要求描述对本软件系统进行概要设计的原则通常可以考虑以下几方面的内容:命名规则模块独立性原则:边界设计原则数据库设计规则必须的安全措施安全性和保密原则系统灵活性要求系统易操作性要求系统可维护性要求等等。系统逻辑设计本节内容主要根据软件产品需求规格说明书和软件产品数据字典建立系统的逻辑模型。此种模型暂时与系统的物理因素(例如:计算机、数据库管理系统)无关。它是系统需求与物理实现的中间结构它的主要结果是建立:系统结构图、系统界面结构图、系统出错处理、以及系统开发技术说明。说明:如果进行系统设计时尚未编写软件数据字典:应首先参照附录B说明编写软件数据字典。在完成软件数据字典后再进行系统设计。系统组织设计系统组织设计通过系统组织表描述本系统由哪些子系统(模块)组成这些子系统与业务职能之间的关系以及各个子系统的安装地点。系统组织表的格式如下:子系统编号英文名称中文名称业务职能安装地点备注其中:子系统编号给出本系统中指定子系统的顺序编号。如果本系统末划分为多个子系统仅由一个运行模块组成则本项内容仍需要描述但是本表内容只有一行。说明:在一个系统中有可能安装若干个相同的子系统在这种情况下应该视为一个子系统并且对多个安装地点分别进行描述。如果相同的子系统通过系统设置实现的业务职能具有明显差异时应该采用多行进行分别描述并且在备注中说明其差异所在。子系统英文名称给出本子系统的英文名称该名称是在应用软件中实际使用的可执行文件名称必须能够说明该子系统的特点。若本系统中只有一个子系统则本项内容仍需要描述但是本表内容只有一行。子系统中文名称给出本子系统的中文名称该名称必须能够说明该子系统的特点。若本系统中只有一个子系统则本项内容仍需要描述但是本表内容只有一行。业务职能描述该子系统完成的核心业务。安装地点描述该子系统实际安装的部门、或者某个具体地点。备注针对该子系统需要说明的其它有关问题。系统结构设计本节将对系统特性作较为详细的描述并给出系统特性结构图。系统特性表系统特性是系统中完成某项具体操作的基本单元它由入口参数出口参数以及处理过程三部分组成。系统特性可以具有操作界面也可以没有操作界面可以被其它操作界面、或者系统特性调用也可以调用其它操作界面、非操作界面、或者系统特性但是不允许递归调用(调用自己)包括间接递归调用。当系统由多个子系统(模块)组成时每个子系统分别使用一张系统特性表进行描述。系统特性表的格式如下:子系统编号:子系统英文名称:子系统中文名称:特性编号系统特征英文名称系统特征中文名称操作功能调用对象被调用对象备注说明:其中子系统编号含义同上。子系统英文名称含义同上。子系统中文名称含义同上。特性编号整个系统所有特性的统一编号。系统特性英文名称系统特性的英文正式名称将来用于软件开发中必须符合命名规范。系统特性中文名称系统特性的中文正式名称来源于需求规格说明书中系统特性一节中的有关描述。操作功能是指该特性实际完成的操作说明。调用对象是指调用该系统特性的系统对象这里的系统对象可以是系统特性、也可以是操作界面。被调用对象是指被该系统特性调用的系统对象这里的系统对象可以是系统特性、也可以是操作界面。说明:某些较低层的系统特性可能不存在被调用对象。备注描述与该系统特性有关的其它注意事项。说明描述与该系统特性表有关的其它注意事项。系统特性结构图系统特性结构图给出系统特性在逻辑层面上相互之间的关系其主要依据来源于需求规格说明书中系统特性一节中的有关描述。如果系统划分为多个子系统应分别给出系统与子系统、以及各个子系统与系统特性的结构图。绘制系统与子系统结构图时一般不需要描绘出系统特性如果确有必要尽可能只画出第一层系统特性。绘制子系统与系统特性结构图时通常也不需要描绘出第二层系统特性如果确有必要可以画出但是尽可能不要画出第三层系统特性。系统接口设计系统接口是一种非可视的系统界面在多数情况下它对用户是透明的。本节将对系统接口作较为详细的描述并给出接口说明清单。系统接口表接口作为系统的一种输入/输出形式分为网络接口、数据库接口、RS串行通讯接口、IEEE串行总线接口、并行IO接口等等多种类型。对于一些为可视界面服务的接口例如:打印机接口、显示器接口等因为这类接口对应用软件是透明的所以不在本节描述范围内。当系统由多个子系统(模块)组成时每个子系统分别使用一张系统接口表进行描述。系统接口表的格式如下:子系统编号子系统英文名称子系统中文名称接口编号接口名称接口类型接口性质接口速率接口协议备注说明:其中:子系统编号含义同上。子系统英文名称含义同上。子系统中文名称含义同上。接口编号整个系统所有接口的统一编号。接口名称系统接口的正式名称必须符合通常习惯。接口类型指出该接口所传输的数据在该模块中起到的作用。接口性质指出该接口在通讯中起到的作用这里的作用可以是:n输入n输出n双向。接口速率指出该接口的传输速率。如果该接口依赖于其它通讯方式那么传输速率将不高于它所依赖的其它通讯方式的速率。接口协议给出该接口实际使用的通讯协议。相关对象给出直接使

用户评论(0)

0/200

精彩专题

上传我的资料

每篇奖励 +2积分

资料评价:

/95
0下载券 下载 加入VIP, 送下载券

意见
反馈

立即扫码关注

爱问共享资料微信公众号

返回
顶部