技术研发文档模版0.10
第一部分 总纲 一﹑目 的： 1. 规范公司内部技术研发工作的文档管理； 2. 保持技术研发工作的完整性与连续性； 3. 防止技术流失，减少风险； 4. 使技术文档成为技术研发工作中的重要组成部分。 二﹑适用范围：本公司内部一切与技术研发有关的部门及个人，包括 1. 总经理； 2. 技术部门经理或负责人； 3. 研发工程师； 4. 测试工程师； 5. 技术支持工程师。 三﹑目 标： 通过切实可行的文档管理规范，使得研发工作透明，明确，有章可循，合作无障碍， 衔接环节畅通；使得所有的研发产品从开始研发——研发进程——测试——修改——阶段性结束 ——产品转化——升级维护过程中的所有环节都得以在相应的文档中体现。 四﹑版 本：E2003V0.10（简称V0.10）。 五﹑制定原则： 1. 实用：鉴于公司目前的状况，通用性的开发模板（如国标）在很大程度上对于本公司 并不实用，所以本规范将不会完全照搬此类模板，而是根据公司的具体情况制定公 司内部的标准； 2. 可行：可行性是该标准的起码要求，没有可行性的标准不能成为真正的“标准”； 3. 高效：如果将国标中的所有规范内容都纳入本标准，一定可以达到目的，实现目标。 但是，同时必将为相关人员增添大量的工作量，而且很多工作对于本公司来说是冗 余，从而造成相关人员的抵触情绪，使标准难于贯彻。所以，本标准应力求在尽量 少的模板中体现尽量多的内容； 4. 科学：本标准的制定虽然不完全照搬其他通用性的标准，但将大量参照通用标准，特 别是国标中的某些部分内容，不是抛弃国标，而是以国标为原则，以保证科学性； 5. 建立在广泛意见基础上：本标准并非公司某一个人单方面的意愿，而是从公司利益出 发，全体相关人员共同参与，集体的结晶。 六﹑实行过程及生效日期： 1. V0.10版的规范为规范草稿，草稿制订完成后，将在相关部门和相关人员中进行传阅 和广泛征求意见。经过三次全体相关人员参与讨论和修改，由总经理审批签字后的 规范版本为0.40。 2. V0.40为试用版本，在V0.40的试用过程中，将要求并给予相关人员以合理的时间尽量 按照V0.40版的要求规范修改，补充和完善V0.40版以前（包括V0.10以前欠缺的文 档）的有价值文档。在此期间，如有新的研发工作开始启动，将要求相关人员按照 V0.40版的规范要求进行文档的相关操作。在此过程中，如果发现规范中需要修改 和补充之处，每经过一次大幅度的修改，版本即升级到V0.5i（i=1,2,3,…n,），每 经过一次小的修改或补充，版本将升级为V0.4j（j=1,2,3,…,n）。 3. V1.00为正式版本。此时的版本已经经过讨论，试用，修改，补充和不断完善，并且 V1.00以前欠缺的文档与V0.40试用过程中的文档都已经按照V0.40版本的要求整理 完毕，此时的V0.40版已经成熟，可以整体升级到V1.00版。V1.00版本的文档规范 将作为公司内部与技术研发工作相关的所有人员在今后相当一段时间内共同遵守的 规范，并且将文档的撰写工作作为技术研发的一个重要组成部分正式纳入到技术研 发工作中。 4. V1.00规范将具有强制性和高约束力。 （注：Vi.00，i=0,1,2,…表示i版本系列；Vi.mn，i，m，n=0，1，2，…表示i版本系列下 的改动或升级） 第二部分 目录索引 一﹑版本控制规则 二﹑立项 1﹑说明 2﹑模板 三﹑需求分析 1﹑说明 2﹑模板 四﹑可行性分析 1﹑说明 2﹑模板 五﹑功能定义 1﹑说明 2. 模板 六﹑概要设计 1﹑硬件部分 1. 说明 2. 模板 2﹑软件部分 1. 说明 2. 模板 七﹑详细设计 1﹑硬件部分 1. 说明 2. 模板 2﹑软件部分 1. 说明 2. 模板 八﹑测试 1﹑测试流程 2﹑测试要求 1. 硬件部分 2. 软件部分 3﹑测试模板 1. 硬件部分 2. 软件部分 九﹑从研发到产品的过渡 1. 要求 2. 模板 十﹑技术支持 1. 要求 2. 模板 十一﹑文档工作的评估与审核 1. 评估标准 2. 审核要点 第三部分 内容 一﹑版本控制规则 1. 版本状态：Beta/测试版，Release/正式版，Changing/变更 2. 版本号：版本号以三位数字表示，格式为i.jk（i=0，1，2，…，n；jk=01，…，9 9） a. Beta版，i=0 b. 第一次正式发布的Release版，1.00 c. 用Changing来表示Beta或Release版本的修改或升级 d. 小的改动或升级i，j保持不变，只增加k值即可，k的升值幅度为修改或升级处的数 目，当k值达到或增加至9时，j=j+1，k=0 e. 比较大的改动如，一次修改或升级处的数目>10，功能性的增加或改变，则i保持不 变，增加j值。如果是功能性的修改或变动，每有一项j+1；如果是>10的非功能 性的修改，每10处修改，j+1，个数部分用k来表示 f. 重大变动，i值增加 g. 累计功能变动超过百次，i+1，jk=00 二﹑立项 立项管理（Project Initialization Management，PIM）的目的是采纳符合公司最大利益的立项建议，通过立项管理使该建议 成为正式的项目（合法化）。杜绝不符合公司最大利益的立项建议被采纳，避免公司人 力资源的，资金，时间的浪费。 立项管理是决策行为，目标是“做正确的事情”（do right things）。而立项之后的研发管理活动是保证项目团队“正确地做事情”(do things right)。“正确的决策”+“正确地执行”才有可能产生好的产品。 1﹑说明： 1. 立项：任何一次研发工作的启动，包括全新的项目和在以往的项目基础上进行升级或 改版的项目，都需要进行立项的工作。 2. 项目分级：为了明晰立项的工作，使之有条理，可操作，所以将项目区分为一级项目 和二级项目两个不同的等级 a﹑一级项目：包括全新的项目的启动，原有项目的重大改版和升级 b﹑二级项目：在以往项目的基础上进行的非重大的版本修改和完善 3. 项目审批： a﹑ 所有一级项目必须由项目负责人提交项目申请计划书，并就项目的相关情况向总经 理和技术总监书面陈述或面对面沟通，得到总经理和技术总监的审批签字后方能 启动； b﹑ 一级项目必须附加需求分析与可行性分析 c﹑ 二级项目可以由部门经理指定或由项目负责人申请得到部门经理审批签字后即可执 行，不必交由总经理和技术总监审批签字； d﹑对于二级项目，必须将项目计划申请书（纸介质）交由技术文档负责人归档，总 经理及技术总监对二级项目的进展情况具有知情权，而项目负责人具有向总经理 和技术总监汇报（主动或被动）项目相关情况的义务； e﹑项目申请计划书一式两份：纸介质文档与电子文档。纸介质文档作为技术档案由 专门负责人员备份归档。电子文档按规范要求存储在公司指定的文档服务器上。 4. 权利，责任与义务 a﹑ 总经理，技术总监，部门经理对其所具有审批权限的项目申请计划书具有否决的权利； b﹑ 项目申请人有权要求否决人说明被否决的理由，而且否决人必须在被否决的项目申 请计划书中陈述否决理由； c﹑ 具有审批权限的人对于项目的合理性，需求性，可行性等判断负有全权责任； 2﹑项目申请计划书 |项目申请计划书/立项建议书 | |项目编号 |EPF2003NOX-01 |级 别 |一级项目 □二级项目 | |类 别 |□指定项目 申请项目 |版本说明 |V0.10 | |申 请 人 |Su |申请日期 |2003-8-18 | |负责人 |Su |组 成 员 |Su,Zhang,Yu | |项目名称 |基于GPRS的图像传输 |产品名称 |G-BIU（Hardware，GPRS-Based | | | | |Image | | | | |Unit），G-BIUST(Software，G-BI| | | | |U Support Toolkit) | |理由陈述 | |资源配置需求| | | | |成本简要核算|（暂时可不添此项） | |目 标 |近 期 |中 长 期 |远 期 | | |（年月日~ 年月日） |（年月日~ 年月日） |（年月日~ 年月日） | | | | | | |问题与解决|问 题 |（在此陈述进行该项目可能遇到和需要解决的问题，除了技术层面外 | | | |，还包括设备， | | | |人员配备等方方面面的主要问题） | | |解决方法 |针对以上的问题，提出解决建议 | |备注说明 | | |审批结果 |□通过 □否决 |审批日期 | |审批人签字| | |审批意见 | | 三﹑需求分析： 如果说立项管理是为了解决do right things和do things right的问题，那么需求分析就是要解决do what things的问题。需求产生目标，目标引领方向。好的需求分析不仅要解决“需要做什么” ，同时明确“什么不需要做”。最好的，可能产生最大利益的产品是“恰如其分”的产品。 所谓“恰如其分”就是：产品的功能恰好满足那些特定的需求，产品功能不多也不少。一 般的情况下，总结出“需好做什么”比区分“什么不需要做”要来的容易，但“什么不需要做 ”的界定往往会影响到成本投入和利益产出的比例。 1﹑说明： 1. 需求分析工作的安排：进行一项产品的开发工作的一般流程应该是：市场调查—需求 分析—可行性研究—立项审核—概要设计（总体设计）—详细设计—单元测试—集成测试 —修改完善—项目评估，审核—批量生产—投放市场—技术支持与售后服务。 2. 需求的种类：需求的本质上都来源于市场，但是在具体表现上又有所不同。有的需求 直接由用户提出，目标明确；而有些需求则是我们从市场的零星反馈中总结出来的 ，带有预见性和自主性。 3. 需求分析的主要目的：从市场的反馈或对市场的观察与预见中总结出市场的需求，并 用理性的思维对这些需求进行分析和总结，将需求明确，为后面的工作奠定基础。 4. 需求分析的作用：需求分析是市场与技术的转换点。经过需求分析后，工作的重心即 由市场转移到技术，明确的需求分析是真正进行研发工作的起点，是进行产品开发 一系列后序工作的基础。 5. 需求在进行研发的过程中如果发生变更，需要填写“需求变更说明书” 2﹑模板1 |需求分析说明书/报告 | |配置编号 |EPF2003NOX-02 |作者 | |提交时间 |2003-8-18| |目标用户 |陈述产品的目标用户 | |需求陈述 | |内容 |级别 | | |1 | |□A □B □C | | |2 | | | | | | | | |解决方法 |简单描述针对需求的初步解决意向 | |附加说明 | | |讨论意见 | | |项目评审委| | |员会结论 | | A需求：紧急，重要 B需求：重要，不紧急 C需求：非A,B类需求 模板2 |需求/功能变更 说明书 | |配置编号 |EPF2003NOX-02-01 |历史版本 |V2.00 |改后版本 |V2.17 | |产品名称 |G-BIU(GPRS-Based Image |负责人 | |时间 |2003-8-19 | | |Unit) | | | | | |...
技术研发文档模版0.10