互联网事业部业务管理办法

1、互联网事业部业务管理办法智慧民生业务管理办法软件保密管理办法软件研发管理办法软件升级级管理办办法工业品招招商管理理办法农产品招招商管理理办法加盟商加加盟管理理办法县级运营营中心管管理办法法乡镇物流流配送中中心加盟盟管理办办法村级信息息服务站站加盟管管理办法法平台商户户结算管管理办法法（事业业部与财财务部共共同编制制）加盟商分分成结算算管理办办法（事事业部与与财务部部共同编编制）平台与子子公司分分成结算算管理办办法（事事业部与与财务部部共同编编制）村级信息息服务站站分成结结算管理理办法（事业部部与财务务部共同同编制）版本页标 题：研发部部保密管管理制度度文档编号号：版本说明明：版本号版本日期期作

2、者备注V1.0020166.4.10吴训波创建V1.00审批第一章总则第一条凡研发发部的内内部资料料和信息息均属研研发部秘秘密，所所有成员员均负有有保密的的责任和和义务。为维护护公司利利益，特特制定本本制度。第二条本制度度适合研研发部全全体员工工，包括括在编、社会招招聘和实实习期人人员。第二章保密内内容第三条 研发部部秘密分分为两类类：技术术秘密、内部管管理秘密密。第四条技术秘秘密（一）研研发部为为开发项项目购买买的各种种设计方方案、技技术资料料等文档档。（二）研研发部的的发展战战略、前前景规划划和实施施步骤等等涉及研研发部技技术走向向类文档档。（三）研研发部各各种产品品的开发发计划、需求分分

3、析、调调研报告告、立项项报告等等开发前前期类文文档。（四）研研发部各各种系统统的方案案设计、功能说说明书、数据结结构、系系统参数数说明、接口规规范、程程序设计计规范、系统其其它各种种规范和和清单、测试方方案、测测试报告告等开发发测试期期间形成成的各类类文档。（五）研研发部各各种系统统的集成成方案、移植方方案、上上点试运运行方案案、版本本维护方方案、操操作和排排错手册册、培训训教材等等开发后后期类文文档。（六）合合作单位位提供的的各种技技术资料料。（七）其其它内部部技术资资料。第五条研发部部内部管管理秘密密（一）研研发部办办公会议议纪要。（二）技技术讨论论会议纪纪要。第六条以上保保密内容容，既指

4、指以文件件、报表表、图纸纸、协议议及各种种资料等等形式存存在的纸纸质文档档，又包包括以磁磁盘（硬硬盘和UU盘）、光盘等等介质形形式保存存的电子子文档。第三章保密原原则第七条研发部部员工不不得采用用各种手手段了解解或获取取不属自自己工作作范围内内或未经经研发部部许可接接触的秘秘密。未未经研发发部书面面允许，不得擅擅自向研研发部其其他员工工和研发发部外其其他人员员透露、提供、拷贝自自己所掌掌握的研研发部机机密资料料。第八条未经研研发部书书面同意意，任何何员工不不得以方方便使用用或其它它任何理理由自行行复制、拷贝自自己所掌掌握的研研发部机机密材料料。第九条在开发发过程中中形成的的正式文文档、图图纸、

5、程程序、各各种资料料、合同同协议及及各种成成果均要要及时上上交相关关管理部部门，并并要上交交原件。第十条因工作作需要使使用属于于研发部部机密的的有关资资料时，要通过过文档管管理部门门领取，并严格格履行登登记手续续，任何何人不得得擅自拷拷贝或向向其他员员工索取取。第十一条条研发部部员工所所掌握的的所有涉涉及秘密密的资料料，在到到达规定定使用期期限或因因辞职、辞退离离开研发发部时必必须向有有关文档档管理部部门办理理续借或或退还手手续，并并负有继继续保密密的责任任。第十二条条拥有研研发部机机密资料料的员工工，必须须认真保保管使用用资料，不得遗遗失、转转借，不不经允许许，不得得带出研研发部。版 本 页

6、标 题：研发部部软硬件件研发管理理制度文档编号号：版本说明明：版本号版本日期期作者备注V1.0020166.4.10吴训波创建V1.00审批第一章总则第一条为规范范软硬件研发发的管理理工作，特制定定本制度度。本制制度适用用于公司司软件及及硬件的的研发与与管理。第二条软软硬件开发发遵循项项目管理理和软硬硬件工程程的基本本原则。项目管管理涉及及立项管管理、项项目计划划和监控控、配置置管理、开发管管理和结结项管理理。软硬硬件工程程涉及需需求管理理、系统统设计、系统实实现、系系统测试试、用户户接受测测试、试试运行、系统验验收、系系统上线线和数据据迁移。第二章 立项管管理第三条提提出项目目需求的的部门参

7、参与公司司层面立立项，进进行立项项的技术术可行性性分析，编写立项分分析报告告（附附件一），开展展前期筹筹备工作作。立立项分析析报告应明确确项目的的范围和和边界。第四条 需求提提出部门门将立立项分析析报告提交相关关部门会会签后，上交公公司总经经理与董董事长进进行立项项审批，以保证证系统项项目与公公司整体体策略相相一致。第五条立项分分析报告告得到到批准后后，成立立项目组组，项目目组应包包括业务务组（由由公司需需求管理理组和相相关业务务部门组组成）和和开发组组。公司司研发部部委派一一名PMM负责监监督项目目的进度度，进行行项目管管理工作作，确保保开发能能及时完完成并能能满足业业务需要要。项目目组人员

8、员的选择择应满足足项目对对业务及及技术要要求，项项目组人人员应有有足够的的业务和和 ITT 技术术方面的的专业知知识来胜胜任项目目各方面面的工作作。第三章 需求分分析第六条立立项后业业务组对对用户需需求进行行汇总整整理，出出具业业务需求求说明书书（附附件二），并确确保业业务需求求说明书书中包包含了所所有的业业务需求求。经系系统使用用部门审审批确认认，作为为业务需需求基线线。第七条业业务组在在获得业务需需求说明明书后后，提出出技术需需求和解解决方案案，并对对系统进进行定义义，出具具系统统需求规规格说明明书（附件三三）。系统需需求规格格说明书书需详详细列出出业务对对系统的的要求（界面、输入、输出、

9、管理功功能、安安全需求求、运作作模式、关键指指标(KKPI)等），最好是是采用原原型方式式表达。系统统需求规规格说明明书需需要由业业务组提提交给相相关业务务部门负负责人确确认。第八条项项目组应应对需求求变更影影响到的的文档及及时更新新。第四章 项目目计划和和监控第九条软软硬件开开发采用用项目形形式进行行管理。项目经经理负责责整个项项目的计计划、组组织、领领导和控控制。第十条需需求分析析过程中中，项目目经理组组织制定定详细的的项目目计划书书（附附件四），包括括具体任任务描述述和项目目进度表表等。第十一条条在项目目的各个个阶段，业务组组组长和和开发组组组长需需配合项项目经理理制定阶阶段性项项目计划

10、划。业务务组组长长和开发发组组长长需配合合项目经经理对项项目计划划执行情情况进行行监控，确保项项目按计计划完成成。第十二条条项目计计划需要要变更时时，项目目经理填填写项项目计划划变更说说明（附件五五），并并提交事事业部领领导审批批，通过过审批后后，交给给业务组组组长和和开发组组组长执执行。第五章 系统设设计第十三条条系统设设计应分分为概要要设计和和详细设设计，系系统设计计要遵循循完备性性、一致致性、扩扩展性、可靠性性、安全全性、可可维护性性等原则则。第十四条条 在系系统设计计阶段中中，用户户或使用用部门应应充分参参与，确确保系统统设计能能满足系系统需求求。第十五条条项目组组进行设设计，出出具设

11、设计说明明书（附件六六）和单元测测试用例例（附附件七）。设计说说明书中需要要定义系系统输入入输出说说明和接接口设计计说明。公司主主管领导导组织相相关人员员对概要要设计进进行评审审，出具具设计计评审报报告（附件八八）。业业务组组组长和开开发组组组长应参参加此评评审并对对评审意意见签字字确认第十六条条设计评评审均以以业务务需求说说明书和系系统需求求规格说说明书为依据据，确保保系统设设计满足足全部需需。第十七条条对已确确认通过过的系统统设计进进行修改改需获得得项目经经理、业业务组组组长和开开发组组组长的审审批后方方可进行行。第十八条条对系统统设计的的修改的的文档须须由文档档管理人人员进行行归档管管理

12、。第六章 系统统实现第十九条条开发组组根据设计说说明书制定系系统实现现计划，并提交交项目经经理对计计划可行行性进行行审批。第二十条条系统实实现包括括程序编编码、单单元测试试。第二十一一条开发发组保证证开发、测试和和生产环环境独立立，为各各环境建建立访问问权限控控制机制制，并明明确项目目成员的的职责分分工。对对开发环环境、测测试环境境与生产产环境在在物理或或逻辑方方面应该该做到隔隔离；如如果环境境的分隔隔是通过过逻辑形形式实现现的，应应定期检检查网络络设置。项目组组对已授授权访问问生产环环境的人人员进行行详细记记录，并并对该记记录进行行定期检检查，确确保只有有经授权权的人员员才能访访问到生生产环

13、境境。第七章 系统统测试和和用户测测试第二十二二条测试试组制定定系统统测试计计划（附件九九），并并提交项项目经理理对计划划可行性性进行审审批。第二十三三条系系统测试试计划必须定定义测试试标准，并明确确各种测测试的测测试步骤骤和需要要的系统统设置要要求。第二十四四条开发发组向数数据拥有有部门申申请获取取测试用用业务数数据的使使用权，对获取取的数据据进行严严格的访访问控制制，确保保只有相相关项目目人员才才能访问问及使用用。第二十五五条 开开发组负负责测试试数据准准备，测测试用数数据要足足够模拟拟使用环环境中的的实际数数据。对对已评定定为敏感感信息的的数据进进行敏感感性处理理和保护护。第二十六六条开

14、发发组或合合作开发发商协助助技术研研发部测测试组建建立测试试环境进进行系统统测试。在系统统测试中中对新系系统内部部各模块块之间的的接口和和与其他他系统的的接口进进行充分分测试。技术研研发部测测试组出出具系系统测试试报告（附件件十），测试人人员签字字确认测测试结果果。第二十七七条 系系统测试试通过后后，开发发组配合合业务组组建立用用户测试试环境，业务组组根据用用户测试试用例进进行用户户测试，出具用户测测试报告告（附附件十），业务务组组长长和开发发组组长长应在用用户测试试报告中中签字确确认。第二十八八条项目目组完成成系统帮帮助文档档（其中中包括用户操操作手册册和安装维维护手册册）。凡涉及及应用系系

15、统的变变更，应应对系统统帮助文文档及时时更新。第八章 试运运行第二十九九条系统统主要使使用部门门根据项项目规模模及影响响决定试试运行策策略。第三十条条项目组组制定试运行行计划（附件件十一），并制制定试运运行验收收指标，上报公公司主管管领导审审批。试运行行计划中应包包含问题题应对机机制，明明确问题题沟通渠渠道和职职责分工工。第三十一一条项目目组联合合试运行行单位或或部门进进行相关关系统部部署工作作，准备备培训资资料，对对相关用用户和信信息技术术人员进进行培训训。用户户培训的的完成度度应为实实施后评评估的指指标之一一。第三十二二条项目目组根据据试运运行计划划进行行系统转转换和数数据迁移移。系统统转

16、换前前，检查查系统环环境，确确保运行行环境能能满足新新应用系系统的需需要。系系统转换换时必须须详细记记录原系系统中的的重要参参数、设设置等系系统信息息，并填填写试运运行报告告相关内内容。系系统参数数、设置置的转换换工作作作为系统统上线的的验收的的评估指指标之一一。第三十三三条数据据迁移前前，应制制定详细细的数数据迁移移计划（附件件十二），数数据迁移移计划中应包包含迁移移方案、测试方方案、数数据定义义，新旧旧数据对对照表、迁移时时间、回回退计划划等信息息。数据据迁移计计划需经经项目经经理和主主管领导导签字审审批。第三十四四条数据据迁移后后，项目目组对数数据迁移移的完整整性和准准确性做做出检查查，

17、出具具数据据迁移报报告（附件十十三），其中包包括数据据来源、转换前前状态、转换后后状态，数据迁迁移负责责人、对对完整性性检查情情况、对对准确性性检查情情况等内内容。各各相关部部门验收收转换结结果后在在该报告告上签字字确认。第三十五五条系统统转换和和数据迁迁移由试试运行单单位业务务部门和和公司主主管领导导共同监监督并进进行验收收。第三十六六条系统统转换和和数据迁迁移验收收通过后后，正式式启动试试运行。在试运运行过程程中，试试运行单单位把系系统运行行情况（系统资资源使用用，反应应速度及及其他量量化指标标等）记记录到系系统试运运行报告告中。必必要时，项目组组应根据据系统运运行情况况对应用用系统进进行

18、优化化。第三十七七条试运运行达到到试运行行计划规规定的终终止条件件时，项项目组编编写试试运行报报告（附件十十四）。此报告告应由项项目组和和试运行行单位签签字确认认，并提提交公司司主管领领导审阅阅。公司司主管领领导审阅阅试运行行结果，决定试试运行结结束或延延期。第九章 系统统验收 第三十八八条 系系统主要要使用部部门及技技术研发发部联合合组成独独立系统统验收小小组，也也可授权权原项目目组作为为验收小小组。验验收小组组从功能能需求及及技术需需求层面面对系统统进行综综合评估估。 第三十九九条验收收小组应应根据验验收情况况整理形形成系系统验收收报告（附件件十五）提交系系统主要要使用部部门和技技术研发发

19、部审阅阅。 第四十条条 系统统主要使使用部门门和信息息技术部部门负责责人根据据系统测测试、试试运行情情况签署署验收意意见。第十节 系统统上线第四十一一条系统上上线应遵遵循稳妥妥、可控控、安全全的原则则。第四十二二条 通常常情况下下，系统统上线包包含数据据迁移工工作。第四十三三条项目组组制定系统上上线计划划（附附件十六六），上上报公司司主管领领导审批批。在上上线计划划得到批批准后才才能开始始部署上上线工作作。第四十四四条系统统上线计计划内内容应包包括但不不限于： 1、部署署方式和和资源分分配（包包括人力力资源及及服务器器资源）； 2、上线线工作时时间表； 3、上线线操作步步骤以及及问题处处理步骤

20、骤； 4、项目目阶段性性里程碑碑和成果果汇报（项目执执行状态态的审阅阅、进度度安排等等）； 5、数据据迁移的的需求和和实施计计划；6、完整整可行的的应急预预案和“回退”计划； 7、用户户培训计计划（包包括：培培训计划划、培训训手册、培训考考核等）； 8、公司司下发的的系统标标准参数数配置。第四十五五条上线单单位在上上线初期期需加强强日常运运行状态态监控，出现问问题时应应及时处处理，对对重大问问题应启启动紧急急预案。第四十六六条在完成成上线后后要填写写系统统验收评评估报告告（附附件十七七）。系统验验收评估估报告内容包包括：数数据准确确性、系系统性能能及稳定定性、接接口问题题、权限限问题、业务操操

21、作影响响度、问问题处理理情况、备份、批处理理等。第四十七七条上线单单位管理理层要对对系统统验收评评估报告告进行行审批签签字。第四十八八条公司主主管领导导批准结结项后，业务组组和开发发组将整整理的文文档提交交各自部部门统一一管理。第十二章章 系系统交付付 第四十九九条在系统统验收通通过后，项目组组对运营营部门或或使用单单位进行行系统维维护培训训。 第五十条条项目组组提交全全部经审审批的交交付资料料给 PPMO(项目管管理办公公室) 存档档。 第五十一一条 项目目组填写写系统统交付申申请（附件十十八），提交公公司技术术总监审审批后，交付运运营部门门或使用用单位。第十三章章 软件件版本命命名规范范第

22、五十二二条版本本命名规规范软件版本本号有四四部分组组成，第第一部分分为主版版本号，第二部部分为次次版本号号，第三三部分为为修订版版本号，第四部部分为日日期版本本号加希希腊字母母版本号号，希腊腊字母版版本号共共有五种种，分别别为baase、alppha、betta、RC、rreleeasee。如：2.1.11.20016004100_beetaBasee：此版版本表示示该软件件仅仅是是一个假假页面链链接，通通常包括括所有的的功能和和页面布布局，但但是页面面中的功功能都没没有做完完整的实实现，只只是作为为整体网网站的一一个基础础架构。Alphha： 软件件的初级级版本，表示该该软件在在此阶段段以实

23、现现软件功功能为主主，通常常只在软软件开发发者内部部交流，一般而而言，该该版本软软件的BBug较较多，需需要继续续修改，是测试试版本。测试人人员提交交Bugg经开发发人员修修改确认认之后，发布到到测试网网址让测测试人员员测试，此时可可将软件件版本标标注为aalphha版。Betaa：该该版本相相对于AAlphha版版已经有有了很大大的进步步，消除除了严重重错误，但还需需要经过过多次测测试来进进一步消消除，此此版本主主要的修修改对象象是软件件的UII。修改改的的BBug经测试试人员测测试确认认后可发发布到外外网上，此时可可将软件件版本标标注为betta版。RC：该版本本已经相相当成熟熟了，基基本

24、上不不存在导导致错误误的Buug，与与即将发发行的正正式版本本相差无无几。Releeasee：该版版本意味味“最终终版本”，在前前面版本本的一系系列测试试版之后后，终归归会有一一个正式式的版本本，是最最终交付付用户使使用的一一个版本本。该版版本有时时也称标标准版。第五十三三条版本本号修改改规则1、主版版本号：当功能能模块有有较大的的变动，比如增增加模块块或是整整体架构构发生变变化。此此版本号号由项目目研发部部经理决决定是否否修改。2、次版版本号：相对于于主版本本号而言言，次版版本号的的升级对对应的只只是局部部的变动动，但该该局部的的变动造造成程序序和以前前版本不不能兼容容，或者者对该程程序以前

25、前的协作作关系产产生了破破坏，或或者 是是功能上上有大的的改进或或增强。此版本本号由项项目经理理决定是是否修改改。3、修订订版本号号：一般般是Buug的的修复或或是一些些小的变变动或是是一些功功能的扩扩充，要要经常发发布修订订版，修修复一个个严重BBug即即可发布布一个修修订版。此版本本号由项项目经理理决定是是否修改改。4、日期期版本号号：用于于记录修修改项目目的当前前日期，每天对对项目的的修改都都需要更更改日期期版本号号。此版版本号由由开发人人员决定定是否修修改。5、希腊腊字母版版本号：此版本本号用于于标注当当前版本本的软件件处于哪哪个开发发阶段，当软件件进入到到另一个个阶段时时需要修修改此

26、版版本号。此版本本号由项项目经理理决定是是否修改改。6、主版版本号、次版本本号及修修订版本本号中，上一级级版本有有变动时时，下级级要归零零。第五十四四条版本本发布周周期1、非紧紧急情况况：首先先由测试试人员测测试并提提交Buug，其其次开发发人员会会尽量在在当天修修复Buug并在在第二天天发布该该版本的的alppha版版，然后后由测试试人员测测试验证证关闭BBug之之后在第第三天会会发布该该版本的的beeta版。2、紧急急情况：如果BBug比比较紧急急可跳过过一般流流程，由由开发人人员尽快快修复BBug，测试确确认之后后直接发发布该版版本的betta版，日期期为发布布版本当当天的日日期。第五十

27、五五条 升升级发布布流程。按照升升级的版版本号，由开发发人员、测试人人员、项项目经理理及研发发部经理理填写软件升升级提交交表（附件十十九）。附件一 立项项分析报报告文件状态态： 草稿 正在在修改 正式式发布文件标识识：ProjjecttNamme当前版本本：X.Y作 者：完成日期期：Yearr-Moonthh-Daay版本历史史版本/状状态作 者者参与者起止日期期备注1. 项项目介绍绍 1.1. 项目目目的 提示：用用简练的的语言说说明本项项目“是什么么”，“实现什什么目的的”。描述述简练且且清晰。1.2. 项目目背景 提示：阐阐述项目目背景，重点说说明“为什么么”会产生生本项目目。 （ 1

28、）公司司的短期期、长期期发展战战略； （ 2 ）业务务需求及及发展趋趋势； （ 3 ）技术术状况及及发展趋趋势； （ 4 ）特殊殊的业务务需求等等。 1.3. 项目目范围 提示：根根据对现现有需求求的了解解来确定定项目基基本范围围，说明明本系统统“应当包包含的内内容”和“不包含含的内容容”。 2. 项项目计划划 2.1. 项目目团队 提示：说说明项目目团队的的角色、知识技技能要求求、建议议人选、人数、工作时时间，如如下表所所示。角色知识技能能要求建议人选选、人数数工作时间间项目经理理需求开发发人员系统设计计人员研发人员员测试人员员质量保证证人员配置管理理人员服务与维维护人员员2.2. 成本本估

29、计内容成本（人人民币 万元）备注人力资源源软硬件资资源差旅费会议费接待费2.3. 进度度表编号进度名称称预计结束束时间备注需求调研研项目计划划需求分析析概要设计计详细设计计研发及单单元测试试系统测试试用户验收收测试试运行项目验收收3. 总总结 提示：给给出清晰晰的建议议结论，便于上上级领导导决策附件二 业务务需求说说明书文件状态态： 草稿 正在在修改 正式式发布文件标识识：ProjjecttNamme当前版本本：X.Y作 者：完成日期期：Yearr-Moonthh-Daay版本历史史版本/状状态作 者者参与者起止日期期备注1 概述述 1.1 业务调调研人员员名单 1.2 业务范范围 此处描写写

30、总体业业务的概概要分类类。 1.3 业务目目标 从高层或或商务利利益的角角度提出出本业务务系统的的期望目目标，以以及评价价标准。 1.4 相关文文档 说明：列列出本文文档的所所有参考考文献（可以是是非正式式出版物物），包包括现有有规范、标准、批文、引用到到的文件件、资料料等。 1.5 业务词词汇表 说明：列列出本文文档的所所引用的的专属领领域词汇汇、术语语等，以以便于业业务需求求的提供供者和接接收者是是建立在在一致的的业务理理解基础础之上的的。 2 组织织结构及及业务 2.1 业务相相关组织织结构、人员组组织结构构 说明：如如果客户户岗位设设置复杂杂可分别别设置，业务组组织结构构和人员员组织结

31、结构2.2 组组织机构构描述 2.3 角色职职责 说明：将将业务涉涉及的具具体人员员进行一一定程度度的分类类和抽象象，描述述该抽象象角色的的操作职职责。 2.4 管理综综述【可可选】 说明：主主要描述述该业务务的管理理特点和和管理模模式。 2.5 现有业业务流程程清单 【可选选】 说明：现现有业务务流程需需要考虑虑，很多多新的业业务是在在已有业业务流程程基础上上进行重重组的。 流程编号号流程名称称责任部门门辅助部门门3 业务务流程及及业务处处理描述述 针对每一一项具体体的目标标业务，描述具具体的业业务流程程，以及及相关业业务的具具体描述述。 3.1 具体业业务流程程（系统统名称+编号） 对于具

32、体体业务流流程的命命名有规规范，对对具体流流程进行行编号，便于形形成需求求矩阵，同时形形成需求求的管理理和跟踪踪。 3.1.1 业业务流程程 3.1.2 业业务描述述 说明：描描述具体体的业务务流程。 3.1.3 相相关业务务对象 说明：业业务对象象：业务务流程中中涉及的的单据、报表等等。 业务对象象使用部门门对应电子子档案编编号3.1.4 业业务规则则及关键键算法 说明：描描述业务务环节关关键算法法体系。 4 假定定和约束束 说明：列列出进行行本软件件开发工工作的假假定和约约束，例例如开发发期限等等。 4.1 运行环环境约束束4.2 设计约约束 【可选】 说明：开开发过程程中必须须使用的的软

33、件语语言、软软件进程程需求、主要开开发工具具、核心心技术、第三方产品等等。 4.3 产品应应当遵循循的标准准或规范范 【可可选】 说明：阐阐述本产产品应当当遵循什什么标准准、规范范或业务务规则，违反标标准、规规范或业业务规则则的产品品通常不不太可能能被接受受。 5 其他他 5.1 目前核核心问题题和困难难 5.2 业务对对项目实实施的需需求和期期望 【可选】 5.3 其他未未尽事宜宜附件三 系统统需求规规格说明明书文件状态态： 草稿 正在在修改 正式式发布文件标识识：ProjjecttNamme当前版本本：X.Y作 者：完成日期期：Yearr-Moonthh-Daay版本历史史版本/状状态作

34、者者参与者起止日期期备注1 引言言 1.1 目的 例如：规规定系统统的边界界和目标标，描述述系统的的功能性性需求和和非功能能性需求求。 1.2 读者对对象及阅阅读建议议 说明：指指明本文文档面向向的读者者群，及及相应的的阅读意意见。 1.3 文档范范围 【可选】 说明：对对本文的的范围做做阐述，本文档档改动时时，受到到影响的的范围，例如，本文引引用到的的用例模模型，系系统原型型，系统统测试用用例等文文档。 1.4 参考文文档 说明：列列出本文文档的所所有参考考文献（可以是是非正式式出版物物），包包括计划划任务书书、合同同、批文文、引用用到的文文件、资资料及软软件开发发标准等等。 1.5 术语与

35、与缩写解解释 说明：列列出本文文件中用用到的专专门术语语的定义义和缩写写词的原原词组，并给予予解释，以便于于所有读读者达成成共识。 2 综合合描述 2.1 系统背背景 【可选】 说明：介介绍系统统的预期期效果、历史原原因。2.2 问题说说明 【可选】 提供一段段说明，总结项项目需要要解决的的问题。可以采采用以下下格式：问题是对问题题进行说说明影响问题影影响的干干系人问题的后后果该问题题会导致致什么后后果成功的解解决方案案应列出出成功解解决方案案的一些些主要优优点2.3 系统范范围 说明：阐阐述本项项目“适用的的业务领领域”和“不适用用的业务务领域”，本产产品“应当包包含的内内容”和“不包含含的

36、内容容”。说清清楚系统统范围的的好处是是：（11）有助助于判断断什么是是需求，什么不不是需求求；（22）可以以将开发发精力集集中在产产品范围围之内；（3）有助于于控制需需求的变变更。 完整整而准确确的定义义本产品品的干系系人； 明确确本产品品所影响响到的部部门和业业务； 用图图表或者者文字描描述产品品的范围围，概要要的定义义产品的的功能。2.4 干系人与与用户说说明 【可选】 2.4.1 用用户环境境 【可可选】 详细说明明目标用用户的工工作环境境。以下下是几项项建议： 该任务由由多少人人来完成成？是否否总在变变化？ 一个任务务周期需需要多长长时间？执行每每项活动动要用多多长时间间？是否否总在

37、变变化？ 是否有特特殊的环环境约束束：移动动、户外外、乘机机旅行等等？ 目前使用用的是哪哪些系统统平台？以后会会使用哪哪些平台台？ 还在使用用哪些应应用程序序？您的的应用程程序是否否需要和和这些应应用程序序集成？ 在此处可可以从业业务模型型中摘录录一些内内容来概概述所涉涉及的任任务和角角色等等等。 2.4.2 干干系人简简要情况况 【可可选】 通过在下下表中填填写各干干系人的的相关信信息来说说明系统统中的各各个干系系人，详详尽的简简要情况况应包括括各种干干系人在在以下方方面的信信息：代表谁是此此产品的的干系人人代表？（如在在他处已已作记录录，则此此处为可可选。）此处只只需填写写姓名。说明对干系

38、系人类型型的简要要说明。类型介绍干干系人的的技能特特长、技技术背景景和熟练练程度（即权威威用户、业务用用户、专专家用户户、初级级用户等等）职责列出干干系人对对所开发发的系统统负有的的关键职职责，即即他们作作为干系系人的利利益。使用频率率该干系系人使用用系统的的频率意见/问问题在此处处列出会会阻碍成成功的问问题以及及任何其其他相关关信息。2.4.3 关关键的干干系人/用户需需要 列出干系系人认为为现有解解决方案案存在的的关键问问题。对对于列出出的每个个问题，需澄清清以下要要点： 为什什么会出出现这一一问题？ 目前前如何解解决该问问题？ 干系系人需要要什么样样的解决决方案？ 务必要了了解干系系人或

39、用用户对解解决各个个问题的的相对重重视程度度。分级级和累积积投票方方法表明明，必须须解决的的问题与与干系人人或用户户希望解解决的问问题大有有不同。 2.5 目标业业务模型型 【可可选】 说明：新新系统业业务模型型描述，如有相相应业务务模型材材料了，可作为为需求规规格说明明书的输输入参考考资料。 2.6 功能摘摘要 总结该产产品将提提供的主主要优点点和特性性，而不不必涉及及每个功功能的细细节。对对功能加加以组织织，使客客户或初初次阅读读该文档档的其他他人能够够理解此此功能列列表。 2.7 功能清清单及重重要程度度说明 说明：功功能名称称、功能能描述、重要程程度。 重要程度度，以 ABCC 三类类

40、来表示示：A：核心功功能；BB：辅助助功能；C：外外围功能能； 级别，按按照继承承关系分分为：一一级，二二级，三三级； 编号级别重要程度度功能名称称功能描述述备注2.8 功能与与业务对对照关系系表 说明：业业务组为为主编写写业务需需求，业业务需求求提交至至开发组组后，由由开发组组建立目目标系统统业务模模型并与与业务组组进行确确认（本本操作可可选，也也可由开开发组与与外协单单位合作作建立），目标标业务模模型作为为系统需需求的输输入，由由开发组组与外协协单位合合作撰写写和评审审系统统需求规规格书明明书。业务需求求目标系统统业务活活动（可可选）功能名称称2.9 假定和和约束 说明：列列出进行行本软件

41、件开发工工作的假假定和约约束，例例如：开开发语言言、开发发期限等等。 格式限制制说明：本项将将指定由由现有的的标准或或规则派派生的要要求。例例如： 报表格式式；数据据命名；财务处处理；审审计追踪踪，等等等。 硬件限制制说明：本项包包括在各各种硬件件约束下下运行的的软件要要求，例例如，应应该包括括： 硬件配置置的特点点（接口口数，指指令系统统等）；内存储储器和辅辅助存储储器的容容量。 2.9.1 运运行环境境约束 说明：硬硬件设备备、支持持软件、接口、控制等等方面的的约束 名称详细要求求2.9.2 设设计约束束 【可可选】 说明：开开发过程程中必须须使用的的软件语语言、软软件进程程需求、主要开开

42、发工具具、核心心技术、第三方方产品等等。 2.9.3 产产品应当当遵循的的标准或或规范 说明：阐阐述本产产品应当当遵循什什么标准准、规范范或业务务规则，违反标标准、规规范或业业务规则则的产品品通常不不太可能能被接受受。 3 具体体需求 3.1 功能需需求 3.1.1 具具体功能能 3.1.1.11 内容容 说明：对对于每一一类功能能或者有有时对于于每一个个功能，需要具具体描述述其输入入、加工工和输出出的需求求。3.2 非功能能需求 3.2.1 外外部接口口 3.2.1.11 用户户接口 说明：提提供用户户使用软软件产品品时的接接口需求求。例如如，如果果系统的的用户通通过显示示终端进进行操作作，

43、就必必须指定定如下要要求： a 对屏屏幕格式式的要求求 说明：对对界面上上的各对对象、类类型、宽宽度、取取值范围围、数据据来源、能否为为空等属属性进行行描述。 b 报表表或菜单单的页面面打印格格式和内内容 c 输入入输出的的需求 说明：解解释各输输入输出出数据类类型，并并逐项说说明其媒媒体、格格式、数数值范围围、精度度等。对对软件的的数据输输出及必必须标明明的控制制输出量量进行解解释并举举例，包包括对硬硬拷贝报报告（正正常结果果输出、状态输输出及异异常输出出）以及及图形或或显示报报告的描描述。 d 程序序功能键键的可用用性 说明：快快捷键定定义等。 3.2.1.22 硬件件接口 【可选选】 说

44、明：要要指出软软件产品品和系统统硬部件件之间每每一个接接口的逻逻辑特点点。还可可能包括括如下事事宜：支撑什么么样的设设备，如如何支撑撑这些设设备，有有何约定定。 3.2.1.33 软件件接口 【可选选】 说明：在在此要指指定需使使用的其其他软件件产品（例如，数据管管理系统统、操作作系统或或其他软软件包），以及及同其他他应用系系统之间间的接口口。对每每一个所所需的软软件产品品，要提提供如下下内容：名字、助记符符、规格格说明号号、版本本号、来来源。 对于每一一个接口口，这部部分应说说明与软软件产品品相关的的接口软软件的目目的，并并根据信信息的内内容和格格式定义义接口，但不必必详细描描述任何何已有完

45、完整文件件的接口口，只要要引用定定义该接接口的文文件即可可。 【接口定定义】 下表是对对一些接接口的具具体描述述:接口名称称接口描述述填写接口口完成的的任务接口类型型填写是输输入接口口（innbouund）还是输输出接口口（ouutbooundd）源系统填写接口口输入方方系统或或部件目标系统统填写接口口输出方方系统或或部件厂商提供供/客户户化开发发文件类型型填写文件件类型；若通过过数据库库表来交交互，请请指明数数据库及及表名文件数量量峰值数据据量频度填写数据据处理的的频度复杂度批处理/人工填写接口口数据的的驱动模模式是人人工（mmanuual）还是自自动(aautoomattic)，还是是都支

46、持持接口类型型填写是实实时接口口还是批批量接口口等【其他系系统详细细信息】 说明：列列出所有有与接口口交互的的外围系系统的详详细信息息。包括括输入、输出系系统等系统填写与接接口交互互的系统统名称 系统类型型填写是接接口的数数据源系系统(ssourrce)还是目目标系统统(obbjecct) 数据库填写交互互系统使使用的数数据库及及版本软件填写交互互系统的的软件名名称 架构类型型交互系统统的架构构类型是是 B/S 还还是 CC/S。 位置填写该软软件在交交互软件件体系中中所出的的位置 技术支持持填写交互互系统的的开发商商和支持持商 功能支持持填写具体体的支持持商或技技术团队队 数据归属属【接口隶

47、隶属系统统的详细细信息可选 】系统填写接口口隶属系系统的名名称 模块隶属于具具体的模模块名称称 数据库隶属系统统的数据据库及版版本 负责人控制报告告【接口配配置】 （1）接接口基础础信息配配置 说明：接接口基础础信息的的配置项项目，描描述配置置的方式式。 （2）接接口运行行参数配配置 说明：接接口运行行参数的的配置方方式和步步骤。 【其他配配置可可选 】 说明：外外围系统统或相关关模块的的配置。 3.2.1.44 通信信接口【可选】 说明：指指定各种种通信接接口。例例如，局局部网络络的协议议等等。 3.2.2 其其他非功功能性需需求 说明：下下表中的的各种需需求，可可根据实实际情况况进行选选择

48、其中中的一种种或者几几种进行行描述，在表的的后面是是各种需需求的详详细解释释名称 详细要求求静态数值值需求 动态数值值需求 精度 时间特性性要求 可用性 可靠性 可维护性性 安全性 可移植性性 可扩展性性 兼容性 3.2.2.11 静态态数值需需求 说明：支支持的终终端数；支持并并行操作作的用户户数。 3.2.2.22 动态态数值需需求说明：欲欲处理的的事务和和任务的的数量，以及在在正常情情况下和和峰值工工作条件件下一定定时间周周期中处处理的数数据总量量。 3.2.2.33 精度度 说明:对对该软件件的输入入、输出出数据精精度的要要求，可可能包括括传输过过程中的的精度。 3.2.2.44 时间

49、间特性要要求 说明：对对于该软软件的时时间特性性要求，如对： a响应时时间； b更新处处理时间间； c数据据的转换换和传送送时间；d解题题时间等等要求。 3.2.2.55 数据据管理要要求 【可选】 说明：需需要管理理的文卷卷和记录录的个数数、表和和文卷的的大小规规模，要要按可预预见的增增长对数数据及其其分量的的存储要要求做出出估算。 3.2.2.66 可用用性 指出普通通用户和和高级用用户要高高效地执执行特定定操作所所需的培培训时间间，指出出典型任任务的可可评测任任务次数数或根据据用户已已知或喜喜欢的其其他系统统确定新新系统的的可用性性需求性性能 3.2.2.77 可靠靠性 指出可用用时间百

50、百分比 ( xxx.xxx%)、使用用小时数数、维护护访问权权、降级级模式操操作等。平均故故障间隔隔时间 (MTTBF)。平均均修复时时间 (MTTTR)系统在在发生故故障后可可以暂停停运行的的时间。指出系系统输出出要求具具备的精精密度（分辨率率）和精精确度（按照某某一已知知的标准准）。 3.2.3 文文档需求求 说明：主主要是在在线用户户手册与与帮助系系统，也也包括其其他的文文档 3.2.4 第第三方产产品 【可选】 说明：使使用到的的第三方方产品相相关的 使用许许可、使使用限制制、接口口标准。 3.3 数据字字典 说明：把把相关的的数据抽抽取出来来统一维维护，在在其他章章节如有有类似信信息

51、描述述，则关关联到数数据字典典的相关关部分并并加辅助助说明，如：引引用到的的字段等等。 4 补充充资料 【可选选】4.1 待确定定的问题题列表【可选】 需求标题题1 调查方式式 调查人 调查对象象 时间、地地点 需求信息息记录附件四 项目目计划书书文件状态态： 草稿 正在在修改 正式式发布文件标识识：ProjjecttNamme当前版本本：X.Y作 者：完成日期期：Yearr-Moonthh-Daay版本历史史版本/状状态作 者者参与者起止日期期备注1 文档档介绍 1.1 文档目目的 1.2 文档范范围 1.3 参考文文献 提示： 列出本本文档的的所有参参考文献献（可以以是非正正式出版版物），

52、格式如如下： 标识符符 作作者，文文献名称称，出版版单位（或归属属单位），日期期 例如： AAAA 作作者，立项建建议书，机构构名称，日期 1.5 术语与与缩写解解释缩写、术术语解 释 2 项目目介绍 2.1 项目范范围 提示： （1）用用简练的的语言说说明本项项目“是什么么”，“说明用用途”。（2）说说明本项项目“应当包包含的内内容”和“不包含含的内容容”。2.2 项目目目标 提示：给给出“清晰的的”、“可实现现”、“可验证证”的目标标。 2.3 客户与与最终用用户介绍绍 提示：请请说明本本项目的的客户、用户及及其相关关责任人人是谁，描述最最终用户户的特征征。 2.4 约束 提示： （1）请

53、请说明在在项目开开发过程程中应当当遵循的的标准或或规范 （2）请请说明相相关项目目可能对对本项目目造成的的影响。 （3）说说明一些些假设和和依赖。 3 项目目过程定定义 3.1 软件生生命周期期模型 提示：简简要描述述、绘制制本项目目的软件件生命周周期模型型。 3.2 项目规规范 提示：描描述项目目需遵循循的规范范，例如如：编码码规范。此处可可以表现现为编码码规范的的链接。 3.3 方法与与工具 提示：说说明在过过程中将将采用的的方法与与工具。例如采采用 RRatiionaal RRosee 进行行面向对对象分析析与设计计，采用用 Viisuaal SSourrceSSafee 进行行配置管管

54、理，采采用 MMicrrosooft Offficee 制作作文档。方法与工工具用途 Visuual SouurceeSaffe配置管理理 4 里程程碑计划划 序号里程碑名名称开始日期期结束日期期工作成果果备注 5 资源源计划 5.1 人力资资源计划划 提示：制制定本项项目的角角色职责责表，并并为已知知的项目目成员分分配角色色（一个个人可以以兼多个个角色）。角色职责人员姓名名工作说明明高层领导导 项目经理理 需求分析析员 系统设计计员 程序员 测试员 5.2 软硬件件资源计计划 提示：分分析项目目开发、测试、运行所所需的软软硬件资资源和关关键计算算机资源源（会影影响软件件产品的的性能的的 CP

55、PU、内内存、带带宽等内内容），主要内内容包括括：资源级别别（分为为“关键”、“普通”两种）详细配置置获取方式式（如“已经存存在”、“可以借借用”或“需要购购买”等）与与获取时时间使用说明明（如“谁”在“什么”时候使使用）软硬件资资源名称称级别详细配置置获取方式式与时间间使用说明明 关键 关键 普通 6 文档档交付列列表序号交付文档档名称交付日期期备注7 风险险管理计计划 提示：以以下是各各个列标标题的解解释。 约定在项项目中的的风险管管理方案案，例如如：风险险识别频频度、风风险跟踪踪频度等等。 风险级别别：确定定风险的的严重性性、可能能性、风风险系数数 风险描述述：缓解解方案或或者应急急计划

56、风险编号号风险级别别风险描述述缓解方案案应急计划划严重性(1-55)可能性(%)风险系数数 (严重性性*可能能性)8 沟通通计划甲方代表表乙方代表表沟通方式式沟通频率率/时间间期望结果果9 附件件 项目目进度计计划附件五 项目目计划变变更说明明项目名称称申请日期期项目计划划变更申申请申请变更更的项项目计划划输入名称称，版本本，完成成日期等等信息 变更的内内容及其其理由 评估计划划变更将将对项目目造成的的影响 项目负责责人签字字变更申请请的审批批意见产品经理理审批审批意见见： 签字日期期研发部经经理审批批审批意见见： 签字日期期使用部门门意见审批意见见： 签字日期期更改项目目计划变更后的的项目目

57、计划输入名称称，版本本，完成成日期等等信息项目负责责人签字字附件六 设计计说明书书文件状态态： 草稿 正在在修改 正式式发布文件标识识：ProjjecttNamme当前版本本：X.Y作 者：完成日期期：Yearr-Moonthh-Daay版本历史史版本/状状态作 者者参与者起止日期期备注1 引言言 1.1 编写目目的 说明编写写这份详详细设计计说明书书的目的的，指出出预期的的读者。 1.2 背景 说明： 待开发软软件系统统的名称称； 本项目的的任务提提出者、开发者者、用户户和运行行该程序序系统的的应用环环境。 1.3 定义 列出本文文件中用用到专门门术语的的定义和和外文首首字母组组词的原原词组

58、。 1.4 参考资资料 列出有关关的参考考资料，如： 本项目的的经核准准的计划划任务书书或合同同、上级级机关的的批文； 属于本项项目的其其他已发发表的文文件； 本文件中中各处引引用到的的文件资资料，包包括所要要用到的的软件开开发标准准。列出出这些文文件的标标题、文文件编号号、发表表日期和和出版单单位，说说明能够够取得这这些文件件的来源源。 2 程序序系统的的结构 用一系列列图表列列出本程程序系统统内的每每个程序序（包括括每个模模块和子子程序）的名称称、标识识符和它它们之间间 的层层次结构构关系。 3 程序序 1（标识符符）设计计说明 从本章开开始，逐逐个地给给出各个个层次中中的每个个程序的的设

59、计考考虑。以以下给出出的提纲纲是针对对一般情情况的。对于一一个具体体的模块块，尤其其是层次次比较低低的模块块或子程程序，其其很多条条目的内内容往往往与它所所隶属的的上一层层 模块块的对应应条目的的内容相相同，在在这种情情况下，只要简简单地说说明这一一点即可可。 3.1 程序描描述 给出对该该程序的的简要描描述，主主要说明明安排设设计本程程序的目目的意义义，并且且说明本本程序的的特点（如 是是常驻内内存还是是非常驻驻？是否否子程序序？是可可重入的的还是不不可重入入的？有有无覆盖盖要求？是顺序序处理还还是并发发处理等等）。 3.2 功能 说明该程程序应具具有的功功能，可可采用 IPOO 图（即输入

60、入处理理输出出图）的的形式。 3.3 性能 说明对该该程序的的全部性性能要求求，包括括对精度度、灵活活性和时时间特性性的要求求。3.4 输入项 给出对每每一个输输入项的的特性，包括名名称、标标识、数数据的类类型和格格式、数数据值的的有效范范围、输输入的方方式。数数量和频频度、输输入媒体体、输入入数据的的来源和和安全保保密条件件等等。 3.5 输出项项 给出对每每一个输输出项的的特性，包括名名称、标标识、数数据的类类型和格格式，数数据值的的有效范范围，输输出的形形式、数数量和频频度，输输出媒体体、对输输出图形形及符号号的说明明、安全全保密条条件等等等。 3.6 算法 详细说明明本程序序所选用用的