产品设计与开发全套资料.doc

+-1 規劃階段| 新品規劃評審.doc| 會議記錄.doc| 産品型號申請單.doc| 用戶需求分析評審.doc| 立項申請單.doc| 總體設計方案.doc| 需求規格說明書.doc| 項目可行性分析報告.doc| 項目小組及分工.doc| 項目計劃書.doc| 項目進度計劃表.doc| 項目需求建議書.doc| +-2 設計階段| 代碼評審附表.doc| 元器件材料清單.doc| 印製板圖檢查表.doc| 原理圖檢查表.doc| 工程安裝調試說明書.doc| 數據庫設計說明書.doc| 施工規範.doc| 會議記錄.doc| 概要設計評審.doc| 概要設計說明書.doc| 用戶手册.doc| 系統設備清單.doc| 系統說明書.doc| 編碼評審.doc| 詳細設計評審.doc| 詳細設計說明書.doc| 部件材料清單.doc| 零件承認書.doc| +-3 樣品試制階段| BUG list.doc| 會議記錄.doc| 樣品調試方案.doc| 樣品調試與測試報告.doc| 測試分析報告.doc| 測試計劃.doc| 系統測試分析報告.doc| 系統測試計劃.doc| +-4 試用階段| 技術轉移清單.doc| 會議記錄.doc| 生産工藝文件.doc| 用戶反饋單.doc| 項目評審.doc| 項目開發總結報告.doc| 項目驗收評審.doc| -5 產品發佈階段 工程安裝調試說明書.doc 技術轉移清單.doc 施工規範.doc 會議記錄.doc 版本管理清單.doc 産品版本變更明細表.doc 用戶操作手册.doc 系統技術方案.doc 系統說明書.doc 項目開發總結報告.doc产品名称申请人产品规格描述：（可以附产品规格说明书）型号：研发经理核准版本管理人员 编号：日期时间地点主席列席记录参加人员缺席人员会议主题项次报 告 及 决 议 事 项报告人/责任者预计完成日期追踪结果12345678910会 签审 核受文单位董事长总经理行政管理中心财务部商务部营销中心工程中心研究院产品研发中心检察科技集成中心备注：编号原则：部门别+月+日+流水码（2码），例：RD072601 立 项 申 请 单项目名称项目型号项目类别 电子警察 卡口 海关科技 其它：申请日期需求日期项目负责人一. 简述产品主要规格（详见需求规格说明书）二. 简述市场和技术可行性分析（详见可行性分析报告）三. 简述总体设计方案（详见总体设计方案）四. 人员与项目进度安排：主要列出各阶段的开始和结束时间，主要工作的人员配置。（详见设计计划进度表）五. 费用预算：（列出费用的大致构成。）董事长/总经理研发中心经理申请人 ROP01082901项目计划书 1、 引言项目背景及编写目的2、 项目概述2.1 工作内容 简要说明项目的各项主要工作，介绍所开发系统的功能、性能等 2.2 条件与限制 阐明为完成项目所应具备的条件、开发单位已具备的条件以及尚需创造的条件。还应包括用户及分合同承包者需承担的工作、完成期限及其他条件与限制 2.3 产品 2.3.1 实物 列出应交付的硬件、软件等产品名称、软件应包括使用的语言及存储形式 2.3.2 文档 列出应交付的文档 2.4 运行环境 应包括硬件、软件环境 2.5 服务 阐明开发单位可向用户提供的服务。如人员培训、安装、保修、维护和其他运行支持 2.6 验收标准3、 实施计划3.1 任务分解 任务的划分及各项任务的负责人、简单描述。详见（项目小组及分工）3.2 进展 按阶段完成的项目，用图表说明开始时间、完成时间。详见（项目进展计划表）3.3 预算3.4 关键问题 说明可能影响项目的关键问题，如设备条件、技术难点或其他风险因素，并说明对策 4、 专题计划要点 如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等 项 目 进 度 计 划 表项目名称： 项目型号： 项目版本：项目负责人： 制表： 日期: 项目负责人员输出文件计划开始时间计划结束时间实际结束时间 规 划 阶 段设 计 阶 段样品试作阶 段 用 户 试 用 阶 段 产 品 发 布 阶 段核准审核制定项 目 可 行 性 分 析 报 告项目名称：拟 制：审 核：批 准：文件版本： 年 月 日 项目可行性分析报告1 引言 1.1 编写目的 可行性分析报告的编写目的是：说明该开发项目的实现在技术、经济和社会条件方面的可行性,评述为了合理地达到开发目标而可能选择的各种方案,说明并论证所选定的方案。说明编写本可行性分析报告的目的，指出预期的读者。1.2 背景 说明： a所建议开发的项目名称； b本项目的任务提出者、开发者、用户； C该项目同其他系统或其他机构的基本的相互来往关系。1.3 定义 列出本文档中用到的专门术语的定义和外文缩写词的原文。1.4 参考资料 列出用到的参考资料，如： a本项目的经核准的计划任务书或合同、上级机关的批文； b属于本项目的其他已发表的文件； C本文档中各处引用的文件、资料，包括所需用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2 可行性研究的前提说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。2.1 要求说明对所建议的开发项目的基本要求，如：a. 功能；b. 性能； c. 输出如报告、文件或数据，对每项输出要说明其特征，如用途、分发对象； d输入说明系统的输入，包括数据的来源、类型、数量、数据的组织以及提供的频度；e处理流程和数据流程用图表的方式表示出最基本的数据流程和处理流程，并辅之以叙述；f在安全与保密方面的要求；g同本系统相连接的其他系统的要求；h完成期限。2.2 目标 说明所建议系统的主要开发目标，如：a人力与设备费用的减少；b处理速度的提高；C控制精度或生产能力的提高；d管理信息服务的改进；e自动决策系统的改进；f人员利用率的改进。 2.3 条件、假定和限制说明对这项开发中给出的条件、假定和所受到的限制，如：a所建议系统的运行寿命的最小值；b进行系统方案选择比较的时间； c经费、投资方面的来源和限制； d法律和政策方面的限制；e硬件、软件、运行环境和开发环境方面的条件和限制；f可利用的信息和资源；g系统投入使用的最晚时间。2.4 进行可行性研究的方法 说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的。简要说明所使用的基本方法和策略，如调查、确定模型、建立基准点或仿真等。2.5 评价尺度说明对系统进行评价时所使用的主要尺度，如费用的多少、各项功能的优先次序、开发时间 的长短及使用中的难易程度。3 对现有系统的分析这里的现有系统是指当前实际使用的系统。分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。 3.1 处理流程和数据流程说明现有系统的基本的处理流程和数据流程。此流程可用流程图的形式表示，并加以叙述。3.2 工作负荷 列出现有系统所承担的工作及工作量。3.3 费用开支列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、材料等项开支以及开支总额。3.4 人员 列出为了现有系统的运行和维护所需要的人员数量。3.5 设备 列出现有系统所使用的各种设备。3.6 局限性列出现有系统的主要的局限性，例如处理时间赶不上需要，响应不及时，数据存储能力不足， 处理功能不够等。4 所建议的系统本章将用来说明所建议系统的目标和要求将如何被满足。4.1 对所建议系统的说明概括地说明所建议系统，并说明所建议系统的基本要求将如何得到满足，说明所使用的基本方法及理论根据。 4.2 处理流程和数据流程给出所建议系统的处理流程和数据流程。4.3 改进之处 按所建议系统的主要开发目标，逐项说明所建议系统相对于现存系统具有的改进。4.4 影响说明在建立所建议系统时，预期将带来的影响，包括：4.4.1 对设备的影响 说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。4.4.2 对软件的影响 说明为了使现存系统的应用软件和支持软件能够同所建议系统相适应。而需要对这些软件 所进行的修改和补充。4.4.3 对用户单位机构的影响 说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。4.4.4 对系统运行过程的影响 说明所建议系统对运行过程的影响，如： a用户的操作规程； b源数据的处理； c数据进入系统的过程； d对数据保存的要求，对数据存储、恢复的处理； e输出报告的处理过程、存储媒体； f系统失效的后果及恢复的处理办法。 4.4.5 对开发的影响 说明对开发的影响，如： a为了支持所建议系统的开发，用户需进行的工作； b为了开发和测试所建议系统而需要的计算机资源； c所涉及的保密与安全问题。4.4.6 对地点和设施的影响 说明对环境设施的要求。4.4.7 对经费开支的影响 扼要说明为了所建议系统的开发、设计和维护运行而需要的各项经费开支。4.5 局限性 说明所建议系统尚存在的局限性问题以及这些问题未能消除的原因。4.6 技术条件方面的可行性 说明技术条件方面的可行性，如：a在当前的限制条件下，所建议系统的功能目标能否达到；b利用现有的技术，所建议系统的功能能否实现；c对开发人员的数量和技术的要求并说明这些要求能否满足；d在规定的期限内，所建议系统的开发能否完成。5 可选择的其他方案 扼要说明曾考虑过的每一种可选择的方案。 5.1 可选择的方案1 参照第4章的提纲，说明可选择的方案1，并说明它未被选中的理由。5.2 可选择的方案2 按类似5.1款的方式说明第2个乃至第N个可选择的方案。 . . . . . .6 投资及效益分析 6.1 支出对于所选择的方案，说明所需的费用。如果已有一个现存系统，则包括该系统继续运行期间所需的费用。 6.1.1 基本建设投资 列出所建议系统安装软件、硬件设备、采购和开发等基本建设投资所需的费用。6.1.2 其他一次性支出 列出所建议系统的一次性支出。6.1.3 经常性支出 列出在所建议系统生命期内按月或按季或按年支出的用于运行和维护的费用。6.2 收益 对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避免、 差错的减少、灵活性的增加、处理速度的提高和管理计划方面的改进等，包括：6.2.1 一次性收益 说明所建议系统能够获得的一次性收益。6.2.2 经常性收益 说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的所获得的收益，包括开支的减少和避免。 6.2.3 不可定量的收益 逐项列出无法直接用货币（如人民币）表示的收益，如：服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进等。有些不可捉摸的收益只能大概估计或进行极值估计（按最好和最差情况估计）。 6.3 收益投资比 求出整个系统生命期的收益投资比值。 6.4 投资回收周期 求出工程累计经济效益等于最初投资所需要的时间。7 社会因素方面的可行性 本章用来说明对社会因素方面的可行性分析的结果，包括：7.1 法律方面的可行性 法律方面的可行性问题很多，如：合同责任、侵犯专利权、侵犯版权等方面的陷井，软件人 员通常是不熟悉的，有可能陷入，务必要注意研究。7.2 使用方面的可行性 例如从用户单位的行政管理、工作制度等方面来看，是否能够使用所建议系统；从用户单位 的工作人员的素质来看，是否能满足使用所建议系统的要求等等，都是要考虑的。8 结论在进行可行性研究报告的编制时，必须有一个研究的结论。结论可以是：a可以立即开始进行；b需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行；c需要对开发目标进行某些修改之后才能开始进行；d不能进行或不必进行（例如因技术不成熟、经济上不合算等）。项目小组及分工产品名称: 客户:项目负责: 日期:部门人员姓名资格负责工作备注核准审核制表项 目 需 求 建 议 书项目名称提出单位提出日期完成日期六. 提出原因七. 产品主要规格八. 竞争对手与技术状况九. 市场行情分析十. 成本与效益分析研究院主管单位主管申请人 RFP01082901项目总结和新品规划评审项目组： 报告人：新品名称评审人员评审日期1对项目总结是否有补充意见2新品规划的技术可行性方面的意见3新品规划的市场可行性方面的意见4新品规划的经济可行性方面的意见5有无另外的新品构想6新、老产品的延续性、继承性如何？7对新品的需求分析有无补充意见8对技术方案是否有补充意见9是否符合公司产业化的方向 需 求 规 格 说 明 书项目名称：项目版本：拟 制：审 核：批 准：文件版本： 年 月 日 需求规格说明书1 编写目的阐明编写需求规格说明书的目的，指明读者对象.2. 项目描述2.1 描述本项目的适用场合及处理业务.2.2 项目名称：本项目的名称，包括项目的全名、简称、代号、版本号.2.3 名词定义：对重要的或是具有特殊意义的名词进行定义.3. 用户情况描述3.1 用户业务描述：描述本项目的用户（或潜在用户）使用本项目处理的业务.3.2 用户情况：介绍本项目的用户（或潜在用户）的情况，包括3.2.1 用户的工作流程；3.2.2 用户的相关部门及职责；3.2.3 用户的技术水平；3.3 用户原有系统的情况：介绍用户现在使用的系统的主要情况，包括主要的不足.4. 任务概述4.1 目标阐明本项目所需达到的目标.4.2 运行环境4.2.1 硬件环境：详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备.4.2.2 软件环境：如操作系统、网络软件、数据库系统以及其它特殊软件要求.4.3 条件与限制说明本产品在实现时所必须满足的条件和所受的限制，以及相应的原因.必须满足的条件包括输入数据的范围以及格式，所受的限制包括软件环境、硬件环境等方面的内容.4.4 主要特点说明本产品与同类产品相比的特点（Feature），即：卖点.5. 功能需求5.1 功能划分从用户的角度将产品按功能划分成不同的部分，但应注意此处划分成的部分并不对应于最终程序实现时的不同功能模块.5.2 功能描述描述由功能划分所生成的各部分的内容，应包括下列内容：a. 必须完成的功能以及对此功能的详细描述：逐条列出本软件所能完成的各项功能以及对此功能的详细描述.b. 不支持的功能以及相应的原因：列出本软件所不支持的各项功能以及相应的原因.此部分内容务必详细准确、无二义性，以作为将来验收和测试的标准.6. 数据描述6.1 输入/输出数据说明输入输出数据的类型及格式.6.2 数据流图(对于结构化分析)从数据传递和加工的角度描述的数据流图，此数据流图不包含任何有关实现的内容，只是从最上层对有关内容加以描述.数据流图的表述形式参见软件工程中的有关规定.6.3 数据库描述(可选)根据系统的总目标和范围，定义数据库的逻辑特性和物理特性.说明数据管理能力的需求:说明要管理的文件或记录的个数,表和文件的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算.6.4 数据词典(对于结构化分析)对于数据流图中出现所有被命名的图形元素在数据词典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释.6.5 建立需求分析模型(对于面向对象分析)6.5.1 需求分析模型是依据产品构想,通过项目组人员充分讨论,对产品要实现的主要功能和使用环境进行分析.6.5.2 需求分析模型分析产品的使用环境,包括最终用户,需配合的外部环境.需求分析模型 应能体现出各主要功能点之间的关系.6.5.3 需求分析模型可采用Rational Rose或Rose RealTime生成,需求分析模型应包括如 下内容:6.5.3.1 Use Case(使用案例) View6.5.3.2 Business Use-Case Model6.5.3.3 Use-Case Model 各主要用户使用功能点之间的关系,用相关UML符号在Use Case Diagram中表 示.7. 性能需求7.1 数据精确度根据实际情况，确定产品最终输出数据(包括传输中)的数据精确度.7.2 适应性 a. 复用性：说明本产品是否可以复用哪个已有软件或者最终本产品是否可被其它产品复用.b. 灵活性：说明在运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力.7.3 时间特性要求 说明产品(尤其是交互式产品)在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性.7.4 系统支持并行操作的用户7.5 系统存储容量7.6 系统计算及运行时间8. 运行需求8.1 用户界面 说明本产品的人机界面风格.8.2 硬件接口说明本产品与硬件之间各接口的逻辑特点及运行该软件的硬件设备特征.8.3 软件接口说明本产品与其它软件之间接口，对于每个需要的软件产品，应提供:a. 接口名称b. 规格说明c. 版本号8.4 故障处理说明本产品在健壮性方面所需达到的目标，健壮性是指即使前提条件不符合规格也能继续合理运行的程度.9. 硬件9.1 功能需求 9.2 性能需求10. 结构10.1 功能需求 10.2 性能需求11. 不确定的问题说明本项目目前尚未确定的问题.12. 风险分析说明本项目面临的主要风险，包括时间、技术复杂度、人力资源等.13. 其它需求说明本项目的其它需求，如可维护性、可靠性、可使用性、安全保密性、可移植性等方面的需求.14. 编写人员及编写日期列出参与编写用户需求规格说明书的人员名字，并标明负责人.15. 参考资料：列出需求规格说明书所参考引用的资料的名称.用户需求分析评审项目名称： 项目负责人：评审负责人： 评审时间： 一：评审流程1、 由公司高层领导、用户、营销部、技术部、工程部及研发部的相关人员组成一个评审小组，开会讨论、评审项目的需求建议书、可行性分析报告、需求规格说明书、总体设计方案等资料， 2、 该项目的系统分析员从项目的需求提出、对问题的识别、系统的需求、总体设计方案等分别进行介绍。在此过程中，小组成员可以提出问题，展开讨论，审查是否有错误存在。3、 在讨论结束后，由系统分析员将评审和修改通过后的资料存档并且转给相关部门。.二： 评审人员公司高层研究院研发中心用户其它部门三：评审记录（评审的具体结果可以参见评审会议记录）序号 记录事项 意见1系统定义的目标是否与用户的要求一致？2系统需求分析阶段提供的文档资料是否齐全？3文档中的所有描述是否完整、清晰，准确反映用户要求？4与系统其他所有成分的重要接口是否都已经描述清楚？5所开发软件的数据流与数据结构是否足够、确定？6所有图表是否清楚，在不补充的情况下能否理解？7设计的约束条件或限制条件是否符合实际情况？8开发的技术风险是什么？9市场上有无成熟、稳定的解决方案可以参考？10是否考虑过其他的解决方案？11是否将来可能会提出的系统需求，有相应的解决方案？12系统的兼容性如何（本公司产品及市售产品）？13是否制定了详细的检验标准，它们能否对系统定义进行成功确认？14其它意见：核准审核制定总 体 设 计 方 案项目名称：项目版本：拟 制：审 核：批 准：文件版本： 年 月 日 目 录1、 前言 .2、 任务概述 3、 方案选择 4、 系统设计 .4、1 产品的整体设计 4、2产品硬件各个模块设计. . .4、3产品软件各模块设计. .4、4产品外形、结构设计. .5、开发工具 6、运行环境 7、技术风险 8、 相关技术简介 （注：本文档是在设计规划阶段，作为公司研究院和研发中心的接口文档。 本文主要的阅读对象是公司内部参与系统和模块的设计和测试人员）1、 前言简明扼要的说明本产品方案的任务来源、市场背景、技术背景，设计目的和产品的使用场合等。2、任务概述2、1设计目标简述系统的设计目标内容（主要是系统的概述、功能、用途）2、2 条件和限制简述系统设计应具备的条件（如设计人员的技能、数量，设计工具和设备，测试设备等），目前缺少的条件（如人员不足，技能不足，设备不齐全等）。3、方案选择3、1提供合理的选择方案提供高、中、低成本的可行方案，每个方案应包括系统流程图、组成系统的物理元素清单、成本/效益分析、实现这个系统的进度计划。3、2推荐最佳方案根据实际情况，从以上方案中推荐最佳方案，并说明理由。4、系统架构设计4、1产品的整体设计可以用文字、图形介绍系统的总体架构、设计意图。4、2产品硬件各个模块设计介绍系统硬件部分的功能模块分解，各个模块之间相互的连接和信号传输和控制。模块名称， 说明模块的功能，实现方法或原理。模块所用的关键设备的技术指标。(可以另外撰写更详细的硬件设计方案替代)4、3产品软件各个模块设计软件的功能分解，确定软件由哪些模块组成，以及模块之间的关系（用层次图或结构图描述）。介绍软件模块名称，说明模块的功能，各个模块之间的动态调用关系。对于需要数据库的系统，应设计数据库，确定物理数据库结构，用户使用的数据视图，进行数据库的完整性和安全性设计。软件模块的开发环境和应用环境软件的界面图（如果有必要的话）(可以用概要设计说明书替代此节内容。)4、4产品外形、结构设计包括产品的设备布置图，外形图、结构图，可以用图片、文字描述。确定产品的外观（如指示灯、文字标记等）、安装方式、防护要求、安装连接图等，也可以包括产品的包装图。5、开发工具1、硬件设计的开发工具（如原理图，PCB图等设计软件）。2、软件设计的开发工具（系统分析工具、编码软件等。）3、结构设计的开发工具（如二维图、三维图、结构分析等设计软件）。6、运行环境指明系统的操作系统、网络环境、通信系统、数据库环境，系统的硬件系统配置要求 ，系统将来运行的周围环境要求等。7、技术分险主要分析系统的主要技术难点、关键技术存在的风险。然后提出解决的方法或提供设计思路。8、相关技术简介简单介绍系统所用到的技术的现行状况和和各自的优缺点，阐述选择使用哪种技术及其原因。编码评审项目名称： 项目负责人：主审人： 评审时间： 一：评审流程1、 由主审人、评审专家、项目负责人、若干程序员和软件测试人员组成一个评审小组，通过阅读和讨论程序，对程序进行静态分析。2、 项目负责人提前把设计说明书、控制流程图、程序文本及有关要求、规范等文档分发给评审小组成员，作为评审依据，小组成员在充分阅读这些材料之后，进入下一步。3、 召开程序编码审查会。在会上，首先由程序员讲解其程序的逻辑，在此过程中，小组成员可以提出问题，展开讨论，审查错误是否存在。4、 在讨论结束后，由项目负责人整理出一份编码评审报告，交给相关程序员。5、 若发现错误较多，或发现重大错误，则在改正之后，再次组织编码评审。二：评审人员主审人评审专家项目负责人程序员软件测试人员三：编码错误清单序号模块名错误语句错误描述解决方法负责人主审人的总结意见和签字：核准审核制定部件材料清单产品名称： 型号： 版本： 日期：序号部件名称型号/规格数量备注生产商123456789101112131415161718192021222324252627282930批准：审核：拟制：序号模块名模块代码行数错误语句错误描述解决方法负责人概要设计评审项目名称： 项目负责人：主审人： 评审时间：一：评审流程1、 由公司领导、各部门相关人员、主审人、评审专家、项目负责人、软件测试人员组成一个评审小组，通过阅读和讨论概要设计的内容，对概要设计进行评审。2、 项目负责人提前把需求规格说明书、概要设计说明书、数据库设计说明书、初步用户手册和初步测试计划等文档分发给评审小组成员，作为评审依据。小组成员在充分阅读这些材料之后，进入下一步。3、 召开概要设计审查会。在会上，由该项目的系统分析员就其设计思想进行详细介绍，主要包括有：系统目标、总体设计、数据设计、处理方式设计、接口设计、运行设计、出错设计等。在此过程中，小组成员可以提出问题，展开讨论，审查是否有错误存在。4、 在讨论结束后，由项目负责人整理出一份概要设计评审报告。5、 若发现错误较多，或发现重大错误，则在改正之后，再次组织概要设计评审。二： 评审人员公司高层营销中心技术中心工程中心研发中心主审人评审专家项目负责人软件测试人员三：评审内容（评审的具体结果可以参见评审会议记录）序号评审事项评审结果备注1可追溯性分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求。软件每一成份是否可追溯到某一项需求。2接口分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。3风险确认该软件设计在现有技术条件和预算范围内是否能按时实现4可维护性从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。可维护性包含了可读性、可修改性、可测试性等含义。5选择方案是否考虑过其他方案，比较各种选择方案的标准是什么。6其他对于文档、设计过程.等等进行评估。主审人的总结意见和签字：核准审核制定概 要 设 计 说 明 书项目名称：项目版本：拟 制：审 核：批 准：文件版本： 年 月 日 概要设计说明书1 引言1.1编写目的 阐明编写概要设计说明书的目的，指明读者对象。1.2项目背景 应包括:a待开发软件系统的名称b列出此项目的任务提出者、开发者以及用户c该软件系统与其他系统的关系1.3 定义列出本文档中所用到的专门术语的定义和外文缩写词的原文。1.4 参考资料 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，这些资料可包括： a.项目经核准的计划任务书、合同或上级机关的批文； b.项目开发计划； c.需求规格说明书； d.测试计划（初稿）； e.用户操作手册（初稿）； f.文档所引用的资料、采用的标准或规范。2 任务概述2.1 目标阐明本项目所需达到的目标。2.2 运行环境简要地说明对本产品的运行环境（包括硬件环境和支持环境）的规定。2.3 需求概述概述本产品的功能需求、性能需求等。2.4 条件与限制说明本产品在实现时所必须满足的条件和所受的限制，以及相应的原因。必须满足的条件包括输入数据的范围以及格式，所受的限制包括软件环境、硬件环境等方面的内容。3 总体设计3.1 处理流程说明本系统的基本设计概念和处理流程，尽量使用图表的形式（如流程图）。3.2 总体结构和模块外部设计用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。3.3 软件体系结构【用图来表示软件系统的总体结构框架,并对其进行描述。】3.3.1 子系统划分 3.3.1.1 子系统清单 3.3.1.2 各子系统功能描述3.3.2 程序模块划分和功能分配3.3.2.1 程序模块清单3.3.2.2 各程序模块功能描述3.3.2.3 功能-程序模块对照表用一张如下的矩阵图说明各项功能需求的实现同各程序模块的分配关系：3.3.2.4 模块-数据实体对照表3.3.3 人工处理过程【描述不能完全自动处理而需人工处理的过程。】 4 接口设计 4.1 用户接口说明向用户提供的命令和它们的语法结构，以及软件的应答信息。4.2外部接口说明本系统同外界的所有接口的安排，包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。4.3 内部接口 说明本系统之内的各个系统元素之间的接口的安排。5 数据结构设计5.1 逻辑结构设计给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录和文卷的标识、定义、长度及它们之间的层次的或表格的相互关系。5.2 物理结构设计给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。5.3 数据结构与程序的关系说明各个数据结构与访问这些数据结构的形式:6 运行设计6.1 运行模块的组合说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明