[资料]软件开发管理制度.pdf

软件开发管理制度 第一节总则第一条 为规范中国人寿保险股份有限公司的自有软件研发和管理工作，特制定本制度。第二条 本制度适用于公司总部软件研发与管理，分公司参照执行。第三条 本制度中软件开发指新系统开发和现有系统重大改造。第四条 软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、软件质量保证、合作开发管理和结 项管理。软件工程涉及需求管理、系统设计、系统实现、系统测试、验收测试、试运行、系统验收和系统上线。第五条 除特别指定，本制度中项目组包括业务组、IT组和合作开发商。第六条 总分公司信息技术部内设置项目管理办公室角色（以下简称itPMO,itPMO具体定义请参见多项目管理制度），统一协调管理各信息技术 组。第七条 各软件开发项目组应严格遵循本制度所附流程和模版，如作调整需上报itPMO审批。第二节立项管理第八条 信息技术部参与公司层面立项，主要工作包括：进行技术可行性分析、参与编写立项建议书、进行前期筹备工作。第九条 信息技术部配合业务部门进行可行性分析，出具可行性分析报告,可行性分析报告中须包含：业务可行性分析、技术可行性分析、成本 效益分析。第十条 信息技术部配合业务部门进行立项中请，出具立项建议书，立项建议书中应明确项目的范围和边界。第十一条 牵头业务部门将立项建议书上交公司管理层进行立项审批，以保证系 统项目与公司整体策略相一致。第十二条 立项申请得到公司管理层批准后，成立项目组，公司管理层委派项目经理监督项目的进度和负责项目管理工作，信息技术部委派负责人负 责IT组的管理和工作。项目组人员的选择是通过考虑项目对业务及 技术要求而调配，项目组人员应有足够的业务和IT技术方面的专业 知识来胜任项目各方面的工作。第三节需求管理第十三条 项目组需制定需求开发计划，并提交项目经理对计划可行性进行审批。第十四条 业务组对用户需求进行汇总整理，出具业务需求说明书，并确保业务需求说明书中包含了所有的业务需求。第十五条 IT组在获得业务需求说明书后，提出技术需求和解决方案，并对系统进行定义，出具需求规格说明书和系统测试案例。需求规格说明书需详细列出业务对系统的要求（界面，输入，输出，管理功能，安全需求，运作模式等）。第十六条 业务组制定验收测试案例，作为验收测试的依据。该测试案例对第三方保密。第十七条 项目经理组织相关业务、技术人员对需求规格说明书和测试案例进行评审，出具评审报告。通过评审的需求规格说明书 和测试案例需提交业务部门和信息技术部负责人签字确认。第十八条 项目经理指定专人负责需求跟踪，确保项目各阶段工作成果同需求的一致性。第十九条 业务需求发生变更时，业务组应出具需求变更申请，并报告业务组负责人审批。第二十条 IT组对变更影响进行评估，结果记录在需求变更中请上，并经过IT组负责人审批。若需求变更涉及项目计划变更，执行项目计划变更流程。第二十一条项目组应对需求变更影响到的文档及时更新。第二十二条 对于合作开发的项目，IT组是合作开发商获得需求的唯一渠道。第四节项目计划和监控第二十三条 软件开发采用项目形式进行管理。项目经理负责整个项目的计划、组 织、领导和控制。IT组负责人配合项目经理并负责IT组的管理工作。第二十四条IT组负责人配合项目经理与项目干系人进行有效沟通，在项目目标、项目计划和工作方法上达成一致。第二十五条 需求分析过程中，项目经理组织制定详细的项目计划（包括：综 合管理、范围（需求）管理、时间管理、成本管理、人力资源管理、沟通管理、风险管理、采购（合作开发）管理、质量管理、配置管理）,并提交业务部门和信息技术部负责人审批。第二十六条 在项目的各个阶段，业务组和IT组负责人需配合项目经理制定阶段 性项目计划。第二十七条 业务组和IT组负责人需配合项目经理对项目计划执行情况进行监控,确保项目按计划完成。IT组负责人按照项目计划规定的报告频度定 期填写项目状态周报告，上报项目经理和itPMO。第二十八条 项目进展同项目计划偏差较大时，应申请变更项目计划，项目经理填 写项目计划变更控制报告，并提交业务部门和信息技术部负责人 批准后执行。第二十九条IT组负责人负责软件开发过程中的风险识别与管理,重大风险应及时 上报项目经理和itPMOo第五节系统设计第三十条 系统设计应分为概要设计和详细设计，系统设计要遵循完备性、一致 性、扩展性、可靠性、安全性、可维护性等原则。第三十一条 项目组需制定系统设计计划，并提交项目经理对计划可行性进行 审批。第三十二条 在系统设计阶段中，用户应充分参与，确保系统设计能满足系统需求。第三十三条 项目组进行概要设计，出具概要设计说明书和集成测试案例。itPMO组织相关人员对概要设计和集成测试案例进行评审，出具技 术评审报告。业务组和IT组负责人应参加此评审并对评审意见签字 确认。第三十四条 项目组进行详细设计，出具详细设计说明书和单元测试案例。详细设计说明书中，需要定义系统输入输出说明和接口设计说明（现存的接口定义应根据新程序需求而更新），并根据系统运行情况的 记录，对应用系统进行优化设计。第三十五条itPMO组织相关业务、技术人员对详细设计和单元测试案例进行评审，出具技术评审报告。业务组和IT组负责人应参加此评审并对评审 意见签字确认。第三十六条 概要设计评审和详细设计评审均以需求规格说明书为依据，确保 系统设计满足全部需求。第三十七条 对已确认通过的系统设计进行修改需获得业务部门和信息技术部负 责人的审批后方可进行。第六节系统实现第三十八条系统实现包括程序编码、单元测试和集成测试。第三十九条 项目组需根据详细设计说明书制定系统实现计划，并提交项目经 理对计划可行性进行审批。第四十条 项目组保证开发、测试和生产环境独立，为各环境建立访问权限控制 机制，并明确项目成员的职责分工。对生产环境、测试环境与开发环 境在物理或逻辑方面应该做到隔离；如果环境的分隔是通过逻辑形式 实现的，应由专门人员定期检查网络设置。第四十一条 项目组进行单元测试和集成测试，出具单元测试报告、集成测试 报告和BUG管理表，测试人员签字确认测试结果。第四十二条 项目组完成用户操作手册和安装维护手册，凡涉及应用系统 的变更，应对两手册及时更新。第七节系统测试与验收测试第四十三条 项目组需制定系统测试计划和验收测试计划，并提交项目经 理对计划可行性进行审批。第四十四条 系统测试计划和验收测试计划需定义测试标准，并明确各种 测试的测试步骤和需要的系统设置要求。第四十五条 项目组应向数据拥有部门申请获取测试用业务数据的的使用权限，测 试用数据要足够模拟生产环境中的实际数据。对获取的数据应进行 严格的访问控制，确保只有相关项目人员才能访问及使川。对已评定 为敏感信息的数据（如客户的银行信息）进行敏感性处理和保护第四十六条IT组或合作开发商建立测试环境进行系统测试，出具系统测试报 告，测试人员签字确认测试结果。第四十七条 系统测试通过后，IT组配合业务组建立验收测试环境，业务组根据验 收测试用例进行验收测试，出具验收测试报告。业务部门和信息 技术部负责人应在验收测试报告中签字确认。第四十八条 验收测试通过后，项目组应组织完善用户操作手册和安装维护 手册的编写，并分别提交业务部门和信息技术部相关人员评审。第八节试运行第四十九条项目组需制定试运行计划，上报公司管理层审批。第五十条 项目组联合试运行单位进行相关部署工作。项目组准备培训资料，根 据试运行计划对相关用户和信息技术人员进行培训。用户培训的 完成度应为实施后评估的指标之一。第五十一条 项目组应确保试运行计划中包含问题应对机制，明确问题沟通渠 道和职责分工，并对可能发生的重大问题制定应急预案。第五十二条 项目组根据试运行计划进行系统转换和数据转换。系统转换前，需对各受影响的系统环境做检查，确保运行环境能满足新应用系统的 需要。系统转换时要求对原系统中的重要参数、设置等系统运行需要 的信息作详细记录，此记录作为新系统上线的要求。系统参数、设置 的转换工作作为系统上线的验收的评估指标之一。项目组需对数据转 换的完整性和准确性作出检查，出具数据转换记录。系统转换和 数据转换由试运行单位业务部门和信息技术部共同监督并进行验收。第五十三条 系统转换和数据转换验收通过后，正式启动试运行。在试运行过程中，试运行单位信息技术部应对系统运行情况（系统资源使用，反应速度 等）作记录。必要时，项目组应根据系统运行情况对应用系统进行优 化。第五十四条 试运行达到试运行计划规定的终止条件时，项目组编写试运行 报告。此报告应由项目组和试运行单位签字确认，并提交公司管理 层审阅。第五十五条 公司管理层审阅试运行结果，决定试运行结束或延期。第五十六条项目组应根据测试标准和试运行结果，制定实施后评估标准。第九节系统验收第五十七条 系统验收分为功能验收和软件验收，分别由业务组和IT组负责。第五十八条 项目组应根据验收情况整理生成系统验收报告提交业务部门和信 息技术部负责人审阅，业务部门和信息技术部负责人根据系统测试、试运行的综合情况签署验收意见，项目组根据验收意见决定是否开展 上线工作。第十节系统上线第五十九条 系统上线应遵循稳妥、可控、安全的原则。第六十条 项目组制定总体上线计划，总体上线计划应综合考虑资源及系 统现状等情况，同时还应充分考虑上线可能给当前系统带来的影响，并取得系统运行部门的意见。总体上线计划经业务部门及信息技 术部管理层进行审批后，报公司管理层进行审批并下发各上线单位。各上线单位根据总体上线计划制定各自的上线计划，该计划 得到上线单位管理层审批后，提交项目组备案。第六十一条项目组制定实施后评估计划（包括评估标准、时间安排等）并下发各上 线单位。第六十二条 项目组根据总体上线计划做好相关部署、培训工作，并建立总体 的问题应对机制。各上线单位根据各自的上线计划建立同项目组 有效衔接的问题应对机制，制定详细上线应急预案，并做好各自的部 署、培训、系统转换、数据转换等工作。具体规定参见试运行一节。第六十三条 上线单位在上线初期须加强日常运行状态监控，出现问题时应及时处 理，对重大问题应启动紧急预案。第六十四条 上线单位管理层可根据上线情况对上线计划进行调整。调整后的上线 计划以及时提交项目组备案。第六十五条 各上线单位在上线完成后，编写系统上线报告，经上线单位管理 层审批通过后，上报项目组。第六十六条 项目组及时汇总各上线单位上线报告，报公司管理层审批。第六十七条 系统上线完成后，各上线单位根据实施后评估计划对系统进行评 估，并作详细的评估记录。各单位编写实施后评估报告，上报 总部IT运行部门，由其整理后上报公司管理层作为项目整体实施后 评估的依据。第十一节结项管理第六十八条 系统上线完成后，项目组提出结项申请，出具项目总结报告，上 报公司管理层审批。第六十九条 公司管理层批准结项后，业务组和IT组分别整理项目管理文档和工 作成果，并提交各自部门统一管理。第七十条 系统结项后，由项目组交由相关运行部门进行维护支持工作。第十二节配置管理第七十一条 信息技术部制定统一的配置管理规范，各项目组共同遵循。第七十二条 软件开发过程中各项目管理文档和工作成果均作为配置项进行管理，其中包括：需求文档、设计文档、代码、测试用例、测试数据、数据 转换记录以及项目相关文档。第七十三条 项目经理指定项目组成员担当配置管理员，负责配置管理工作。第七十四条 配置管理员成根据配置管理规范制定配置管理计划，并提交项目 经理审批。第七十五条 配置管理员负责配置库管理、维护，做好配置库的备份工作。第七十六条 项目组应严格执行配置基线的变更流程，评估变更风险及影响，撰写 配置项变更控制报告。第七十七条 配置管理员按照配置管理计划规定的审计频度进行配置审计，撰 写配置审计报告。第十三节软件质量保证第七十八条 软件质量保证遵循全员负责、以用户需求为导向、持续改进的原则。第七十九条itPMO指定项目组成员担当软件质量保证员，负责质量保证工作。软 件质量保证员向itPMO负责。第八十条 软件质量保证员制定详细的质量保证计划并提交项目经理审批。第八十一条 对于项目中的质量问题，软件质量保证员应及时提交IT组负责人。IT组负责人在质量保证计划中约定的时间未处理时，软件质量 保证员应上报itPMOo第八十二条 软件质量保证员根据质量保证计划规定的报告频度撰写质量管 理报告提交IT组负责人、项目经理和itPMO审阅。第八十三条 第八十四条第八十五条第八十六条 第八十七条第八十八条第八十九条第九十条第九1 一条第十四节合作开发管理合作开发应本着公开、公正、公平的原则。合作开发商招标参见采购制度。合作商资质认定参见第三方管理制 度。IT组应同合作开发商明确项目变更的范围和处理方式，重点关注需 求和设计变更。合作开发商应遵循我方软件开发管理制度。IT组负责监控合作开发商的项目管理及软件开发活动。合作开发商 应按计划定期向我方IT组报告进展状态，并提交阶段性成果文档。发生重大问题时，合作开发商需及时向IT组汇报。IT组负责人派专人监控合作开发商的质量保证过程。IT组负责人要求合作开发商做好技术转移工作，保证我方人员掌握 核心技术。项目组同合作开发商商定验收的标准和方法。以上各要求需要在开发合同中明确。第十五节附则第九十二条 本制度由公司总部信息技术部负责解释和修订。第九十三条 本制度自发布之日起开始执行。o中国人寿信息技术管理制度附件一软件开发总流程彳软”开发总弦程”C?中B人 一中国人寿信息技术管理制度附件二立项管理流程软件开发（立项管理）流程立项审批可行性 分析报告立项申请书立项申请成立项目组 I业务组释止进行 后继工作可行性分析ss中国人寿信息技术管理制度附件三需求开发流程软件开发（需求开发）流程D始 加C(累除以)匚弗飞辕刎定细化的 需未开发计划汇总生理 功能需求验政测在案例睛耳试矣例部门员育人 维手确认(果L)脂“W巡理刈定细化的 需求开发计划进行 蒿求余所格耳刊试案例部门负责人 筌宇嘀认芯求票募文档宕求开发计划 审枇中国人寿信息技术管理制度附件四需求变更流程软件开发（需求变更）流程(寻求手)一就务建走出 需求变更业务组负费人审批二一、E 二距&WFWS变更影响评彷填写拒绝意见 rr组负责人审批是一填笃接受意见 IT组负责人审批需求文档变更 相关文档变更项目计划变更 必要时1按照变更后的需求 进行开发C?中B人 一中国人寿信息技术管理制度附件五项目计划流程_ _ I软件开发（项目计划）流程制定项目计划执行项目计划YteRSS项目计划审批项目计划审批YKM 济长坦理eC?中B人 一中国人寿信息技术管理制度附件六项目计划变更流程软件开发（项目计划变更）流程项目计划 变更控制报告32魏口涔提出项目计划 变更申请更新项目计划 开始执行新计划维持项目计划 继续执行原计划是提山审批意见审批项目计划 变更申请提山审批意见申批项目计划 变更申请C?中B人 一中国人寿信息技术管理制度附件七项目监控流程软件开发（项目监控）流程项目执行编可项目报告项目状态报告 审阅。工 dl一项目状态报告 审阅C?中B人 一中国人寿信息技术管理制度附件八系统设计流程软件开发（系统设计）流程业务组负员人 IT31负山人 签字确认系统没计计划 审批C?中B人 一中国人寿信息技术管理制度附件九系统实现流程软件开发（系统实现）流程af曲口目系统实现计划 审批五二 W搭建开发 溜试环境进行编码编写手册测试人员 签字确认 单元测试报告测试人员 签字确认 集成测试报告C?中B人 一中国人寿信息技术管理制度附件十测试流程软件开发（测试）流程建立系统濡试环境 验收洌试环境Y鹏0Y相娱 进*型R.庄签字确认 睑收测试报告系统测试讨划 脸收测试计划审批中国人寿信息技术管理制度附件1试运行流程软件开发（试运行）流程相关用户 技术人员 培训执行区运行制定实施后 评估标漉完成成运行执行区运行俄运行单位 警字确认结束试运行计划 审批审阅试运行报告 决定结束或延期C?中B人 一中国人寿信息技术管理制度附件十二系统验收流程软件开发（系统验收）流程皿 俘提交审阅确定系统上线结束YteRSS签署 验收意见Y躯5签署 验收意见C?中B人 一中国人寿信息技术管理制度附件十三系统上线流程.软件开发（系统I:线）流程罩.上郛q 3W上线计划 管理层审批 项目假备案郃膏培训 毫统H帙 数搦H换汇总 系统上线报告总体上线报告 审批 I-汇总实施后评估报告总体评估报告 审批中国人寿信息技术管理制度附件十四结项管理流程软件开发（结项管理）流程项目总结报告结项申请上线完成管理文档T作成果 提交部门统一管理批准结项中国人寿信息技术管理制度附件十五 立项建议书（项目名称 立项建议书文件状态：文件标识：ProjectName-V草稿当前版本：X.Y正式发布作 者：正在修改完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.文档介绍1.1.文档目的提示:说明写作该文档的目的。例如:该文档将作为公文签报的底稿。1.2.文档范围1.3.参考文献提示:列出本文档的所有参考文献（可以是非正式出版物）,也可以是本项目的其他 文档。格式如下:标识符作者,文献名称,出版单位（或归属单位）,日期例如:AAA作者,立项调查报告,机构名称,日期BBB作者,立项可行性分析报告,机构名称,日期1.4.术语与缩写解释缩写、术语解释中国人寿信息技术管理制度2.项目介绍2.1.项目目的提示:用简练的语言说明本项目“是什么”,“实现什么目的”。描述简练且清晰。2.2.项目背景提示:阐述项目背景,重点说明“为什么”会产生本项目。（1）公司的短期、长期发展战略;（2）业务需求及发展趋势;（3）技术状况及发展趋势;（4）特殊的业务需求等。2.3.项目主要内容和特色提示:（1）给出本项目待开发系统的主要功能列表（概要）;（2）简要说明客户对系统要求;（3）简要说明本系统的特色。2.4.项目范围提示:根据对现有需求的了解来确定项目基本范围,说明本系统“应当包含的内容”和“不包含的内容”。3.项目风险提示:从各个角度分析项目的风险,包含技术、人员、管理等等方面的内容。4.项目计划4.1.项目团队提示:说明项目团队的角色、知识技能要求、建议人选、人数、工作时间,如下表所角色知识技能要求建议人选、人数工作时间项目经理需求开发人员系统设计人员编程人员测试人员中国人寿信息技术管理制度4.2.软件硬件资源估计质量保证人员配置管理人员服务与维护人员提示:（1）估计项目所需的软件和硬件资源,说明主要配置。（2）说明以何种方式获得,如“已经存在”、“可以借用”或“需要购买”等。（3）资源的级别为“关键”、“普通”两种,如果关键资源不能及时到位,可能危害项目。资源名称级别详细配置获取方式费用关键关键普通普通4.3.成本估计4.4.进度表内容成本（人民币）备注人力资源软硬件资源差旅费会议费接待费提示:制定项目开发的进度表（建议给出项目里程碑计划）。例如:编号里程碑名称预计结束时间备注需求调研完成项目计划完成需求分析完成概要设计完成详细设计完成中国人寿信息技术管理制度实现完成集成测试完成系统测试完成用户验收测试完成试运行结束项目验收5.总结提示:给出清晰的建议结论,便于上级领导决策。附件：可行性分析报告中国人寿信息技术管理制度附件十六可行性分析报告（项目名称 可行性分析报告文件状态：文件标识：ProjectName-V草稿当前版本：X.Y正式发布作 者：:正在修改完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.项目介绍提示:简要介绍项目目的、项目内容等内容。2.可行性分析2.1.政策分析提示:分析有无政策“支持”或者“限制”2.2.技术可行性分析提示:对核心业务需求的技术解决方案,如,硬件、软件、开发技术或策略、以及设 计和实施方案的选择及理由。该部分内容一般由售前咨询技术顾问给出。2.3.时间资源可行性分析提示:结合项目的限制条件,如工期、成本或其它客观限制条件来分析可行性。2.4.成本效益可行性分析提示:结合公司近远期战略目标、优势、不足、机遇、威胁等,对项目进行收益测量 分析。该部分内容一般由业务部门和口部门共同给出。2.5.总结提示:给出清晰的结论（可行、不可行或在什么条件下可行）,便于上级领导决策。中国人寿信息技术管理制度附件十七 技术评审报告（项目名称 XXX技术评审报告文件状态：V草稿正式发布正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.基本信息提示:由评审主持人或评审员填写此表格。待评审的工作成果工作成果名称，标识符，版本，作者，时间技术评审方式（正式技术评审）FTR或者（非正式技术评审）ITR评审时间评审地点参加技术评审的人员类别名字工作单位职称、职务：主持人评审小组成员记录员2.缺陷识别提示:由评审主持人或评审员填写此表格。中国人寿信息技术管理制度3.评审结论与意见已识别的缺陷建议缺陷解决方案提示:由主持人或评审员填写此表格。4.缺陷修正、跟踪与审核提示:由审核人员填写此表格。如果使用缺陷跟踪软件,则无需填写此表。评审结论工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。V工作成果基本合格，需要作少量的修改，之后通过审核即可。工作成果不合格，需要作比较大的修改，之后必须重新对其评审。意见负责人 签字签字：日期：中国人寿信息技术管理制度缺陷跟踪缺陷名称何人何时如何解决审核人意见、签字审核修正后的工作成果修正后的 工作成果工作成果名称，标识符，版本，作者，时间审核 结论修正后的工作成果合格。V修正后的工作成果仍然不合格，需重新修改。审核人员 签字签字：日期：5.附录.技术评审问答记录提示:(1)由记录员填写此表格。(2)主要记录评审过程中的“疑问”、“答复”、“争论”、“处理意见”等。记录1中国人寿信息技术管理制度记录2记录3t己录员 签字签字：日期：中国人寿信息技术管理制度附件十八 需求变更申请需求变更申请申请变更的 需求文档输入名称，版本，日期等信息变更的内容 及其理由申请人签字变更申请的审批意见评估需求变更将对 项目造成的影响任务与进度说明需增加或减少的数值工作成果同上费用同上人力资源同上软硬件资源同上项目经理签字审批意见：签字，日期更改需求文档变更后的输入名称，版本，完成日期等信息中国人寿信息技术管理制度需求文档更改人签字变更结束项目经理签字签字日期：中国人寿信息技术管理制度附件十九 用户需求说明书（项目名称用户需求说明书文件状态：文件标识：ProjectName-V草稿当前版本：X.Y正式发布作 者：:正在修改完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注目录1.文档介绍1.1 文档目的1.2 文档范围1.3读者对象1.4参考文档1.5术语与缩写解释2.产品介绍3.用户需求调查记录A.1需求标题1A.n需求标题N4.需求建模与分析报告B.1需求模型1B.n需求模型N中国人寿信息技术管理制度1.文档介绍1.1 文档目的1.2 文档范围1.3读者对象1.4 参考文档提示：列出本文档的所有参考文献(可以是非正式出版物)，格式如下:标识符作者，文献名称，出版单位(或归属单位)，日期例如：SPP-PROC-PP SEPG,需求开发规范，机构名称，日期1.5术语与缩写解释缩写、术语解释2.系统介绍提示：(1)说明系统是什么，什么用途。(2)介绍系统的开发背景。3.用户需求调查记录常见需求调查方式有：与用户交谈，向用户提问题。参观用户的工作流程，观察用户的操作。向用户群体发调查问卷。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。中国人寿信息技术管理制度从Internet上搜查相关资料。A.1需求标题1需求标题1调查方式调查人调查对象时间、地点需求信息记录A.n需求标题N4.需求建模与分析报告B.1需求模型1B.n需求模型N需求标题N调查方式调查人调查对象时间、地点需求信息记录中国人寿信息技术管理制度附件二十 需求规格说明书（项目名称需求规格说明书文件状态：文件标识：ProjectName-V草稿当前版本：X.Y正式发布作 者：正在修改完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注文件状态：V草稿：正式发布：正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.引言本节仅仅是对需求规格说明书SRS文档的概述，而不涉及软件系统的构建。引言提出 了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。1.1.目的描述软件需求说明书（SRS）的目的。1.2.预期读者列举软件需求说明书所针对的不同读者，例如客户、用户、市场人员、销售人员、项 上 中国人寿信息技术管理制度目经理、开发人员、测试人员、维护人员或文档编写人员。1.3.范围提供指定软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略 相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。定义软件产品名称(如Host DBMS,Report Generator等)；说明软件产品将做什么，如有必要，还要说明不做什么；描述该软件的应用，包括相关的利益，对象和目标；如果高层规范(如业务说明书)中有类似说明，在本文中的对应部分要保持一致1.4.定义和缩写解释理解SRS所需的术语、缩写的定义(Acronyms,Abbreviations,Definitions),本节也可以引用SRS的附录或其它文档。1.5.格式和排版约定本节详细描述了本文所遵循的符号约定，至少需要提到本文所画图中的注释语言，以 及任何与标准概念不同的符号或风格1.6.参考文献列举编写软件需求规格说明时所参考的资料或资源，包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。在这里应该 给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读 者查阅。例如：内容和组织SRS的内容综述；SRS的组织结构。可选：提出最适合于每一类型读者阅读文档的建议。2.系统/产品概述要构建的产品或系统的概述.概述正在定义的产品以及它所运行的环境、使用产品的 用户和已知的限制、假设和依赖。2.1.系统/产品综述本节从与其他产品关系的角度来看待本软件产品。如果本产品是一个独立的、完全自 包含的产品，就需要在这里进行说明。如果本产品象通常那样，是大系统中的一个组件，这节就需要描述大系统对本产品的功能需求，并且标识出大系统本产品的接口。用块图来显示大系统中的主要组件、组件的相互关系，以及它们的外部接口，通常是 种比较好的方法。所谓产品角度，就是系统的环境。特别地，描述了与系统交互的软件或硬件组件。详 上 中国人寿信息技术管理制度细的描述则没有必要，因为后面还有接口规范。这里只需给出与其他组件接口的概述。本 节用上下文图来描述比较合适。2.2.系统/产品功能本节汇总了软件需实现的主要功能。如一个记账程序的SRS在这里描述客户账户的维 护，客户声明，发票准备等，而无需提及这些功能大量的具体细节。有时，这里汇总的功能可以直接取自高层规格说明书（如果存在的话），高层规格说 明书中分配了该软件产品特定的功能。这样做是为了描述清楚：功能的组织应该达到这种效果：客户或者其他任何第一次读本文的人，都能理解这些 功能列表。文本或图形方法也能用来显示不同的功能以及它们的关系。该图并不是想显示一个产品的设计，而仅仅用来显示变量之间的逻辑关系这里只给出系统主要功能的概述。功能的具体描述在本文后面进行。本节仅从用例名 称上对功能进行汇总。2.3.用户特征本节说明系统或产品最终用户所需具备的一般特征：受教育水平，经验积累，技术技 能等。这里不涉及具体的需求，但决定了 SRS第三章所描述的某些需求的原因，如系统可 能为初级和高级用户设计不同的界面。2.4.运行环境描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与 其共存的应用程序。2.5.限制本节列出了用来限制开发者选择的其他条款的简要描述。包括：调整策略硬件限制（如，信号定时需求）与其他应用的接口并行操作核查功能控制功能高层语言需求信号握手协议（如XON-XOFF,ACK-NACK）可靠性需求应用的危险程度安全和保密考虑上 中国人寿信息技术管理制度2.1 节到2.3节描述了对需求可能的限制的来源。2.1节描述了已经存在的组件，它 们可能会限制需求；2.2节描述了希望的功能，它们必然影响了本文描述的需求；2.3节描 述了用户背景，这可能影响到可用性问题。本节则描述了其他限制的来源。你需要考虑是否有其他限制需求或设计的因素。2.6.假设和依赖条件本节列出了影响SRS所声明的需求的各个因素。这些因素并不对软件的设计进行约束,但这些因素的变化会影响SRS中的需求。比如，假定为软件产品设计的硬件上运行的是一 个特定的操作系统，而实际上这种操作系统却不可用，那么SRS就不得不进行相应地改动。关于输入、环境的假定和依赖。如，许多系统对环境做了很多的假定。只有这些来自 环境的输入满足这些假定的时候，这些系统才会正常工作。如，物理定理如，铁道交叉口控制器假定当栏杆下落时，行人会避开交叉口。你需要考虑以下环境条件：可能导致你的软件系统失效的环境环境的改变将导致你修改软件需求3.外部接口需求本节详细描述了软件系统的输入和输出。它包含的内容和格式如下：条目名称目的描述输入来源或输出的目的地有效范围、精确度，以及/或者容限测量单元定时与其他输入输出的关系屏幕格式/组织窗口格式/组织数据格式命令格式结束消息3.1.操作员接口用户接口不仅难以描述，而且我们也难以阅读和理解。作者必须知道隐藏在用户接口 中国人寿信息技术管理制度下面的大量功能。在屏幕上点击、绘制窗口窗口上各个UI部件（按钮、菜单选项等）的目的与各个窗口相联系的输入/输出事件列表输出事件在窗口显示中的效果（用一两行进行描述）如何在窗口间切换我们并不是在写小说。一两行语句足以描述一个目的或效果。信息浏览可能已经在目 的描述中被描述了（如，菜单选项）3.2.用户接口3.3.硬件接口你仍然需要写明在HWIF和系统所收到的软件事件间的转换列出和每一硬件设备相关的输入输出事件对硬件设备产生影响的输出事件3.4.软件接口通常情况下，你需要给目标参数如数据字典一样详细的描述，你也需要描述在SWIF 中没提到目标信息列出和每一信息相关的输入输出事件对软件组件产生影响的输出事件3.5.通信接口4.详细需求4.1.功能性需求分类提示：将功能性需求先粗分再细分，下表中的Feature A,Function A.1等符号应当 被替换成有含义的名称。功能类别功能名称、标识符描述Feature AFunction A.1Feature BFunction B.1Feature CFunction C.1中国人寿信息技术管理制度4.m Feature M提示：此处写一些承上启下的文字。4.m.n Function M.N名称、标识符功能描述优先级输入操作序列输出补充说明5.非功能需求5.1.性能需求此小节将详细说明关于软件或人和软件间作为一个整体进行交互的动、静态数字化需 求。静态的数字化需求可能包括以下几下：支持的终端用户数支持的并发用户数处理的信息数和类型静态数字化需求有时候另辟一节叫性能来详细描述动态数字化需求可能包括在给定时间周期内，包括通常情况和高峰期，所能处理的数 据量、交易数和任务量.所有这些需求都应该用可测术语描述例如：在一秒钟内，95%的交易应该得到处理胜于，某个操作员不能有等待交易完成的感觉注意：应用特定功能的数字化限制作为对应功能的处理描述的子段的一部分描述可靠性：此处规定了软件系统发布时需要建立的可靠性所要求的因素。有效性：此处规定了用以保证整个系统所定义的有效性的因素，诸如检查点、恢复和 重启动。安全性：此处规定了保护软件不受意外或恶意访问、使用、修改、破坏或揭露而采用 的因素。本节规定的特殊需求包括:上 中国人寿信息技术管理制度(1)使用特定的加密技术(2)保存特定的日志或历史数据(3)将特定的功能指定到不同的模块(4)限制程序的部分区域进行通信(5)对敏感变量进行数据完整性检查可维护性：规定软件自身易于维护的特点。这些涉及对一定模块、接口、复杂性等的 需求。需求不应放在这里，因为它们属于好的设计实践。可移植性：规定了软件易于移植到其他主机和/或操作系统上的特性。它可能包括以 下一些特征：(1)用依赖主机代码编写的组件的百分比(2)依赖主机的代码的百分比(3)使用证实的可移植的语言(4)使用特定的编译器或语言子集(5)使用特定的操作系统。5.2.可扩展性5.3.可靠性5.4.安全性5.5.可用性6.术语表7.其它(可选)这部分并不总是也可能没必要是真正的SRS的一部分。它们可能包括：输入/输出格式样例，费用分析研究描述，或用户调查结果帮助SRS读者理解的支持或背景知识软件所要解决的问题的描述特别的代码包装指令和媒体，以符合安全性、出口、初始加载或其他需求。如果包含有附录，SRS需要明确说明附录是否应被认为是需求的一部分。附录：需求确认中国人寿信息技术管理制度需求确认需求文档输入名称，标识符，版本，作者，完成日期业务部门确认签字，日期项目经理确认签字，日期中国人寿信息技术管理制度附件二十一项目计划书（项目名称项目计划书文件状态：文件标识：ProjectName-V草稿当前版本：X.Y正式发布作 者：:正在修改完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.文档介绍1.1 文档目的1.2 文档范围1.3 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下:标识符作者，文献名称，出版单位（或归属单位），日期例如：AAA作者，立项建议书，机构名称，日期1.4术语与缩写解释缩写、术语解释中国人寿信息技术管理制度2.项目介绍3.1 项目范围提示：（1）用简练的语言说明本项目“是什么”，“说明用途”。（2）说明本项目“应当包含的内容”和“不包含的内容”。2.2 项目目标提示：给出“清晰的”、“可实现”、“可验证”的目标。2.3 客户与最终用户介绍提示：请说明本项目的客户、用户及其相关责任人是谁，描述最终用户的特征。2.4 约束提示：（1）请说明在项目开发过程中应当遵循的标准或规范（2）请说明相关项目可能对本项目造成的影响。（3）说明一些假设和依赖。3.项目过程定义3.1过程模型提示：简要描述、绘制本项目的过程模型，3.2方法与工具提示：说明在过程中将采用的方法与工具。例如采用Rational Rose进行面向对象分 析与设计，采用Visual SourceSafe进行配置管理，采用Microsoft Office 2000制作文 档。4.人力资源计划方法与工具用途Visual SourceSafe配置管理中国人寿信息技术管理制度提示：制定本项目的角色职责表，并为已知的项目成员分配角色（一个人可以兼多个 角色）。5.软硬件资源计划角色职责人员姓名工作说明高层领导项目经理IT组负责人业务组负责人需求分析员系统设计员程序员测试员质量保证员配置管理员 提示：分析项目开发、测试、运行所需的软硬件资源和关键计算机资源（会影响软件 产品的性能的CPU、内存、带宽等内容），主要内容包括：资源级别（分为“关键”、“普通”两种）详细配置获取方式（如“已经存在”、“可以借用”或“需要购买”等）与获取时间使用说明（如“谁”在“什么”时候使用）6.成本计戈！软硬件资源名称级别详细配置获取方式与时间使用说明关键关键关键普通普通内容成本（人民币）备注人力资源软硬件资源中国人寿信息技术管理制度7.任务与进度提示：分配任务制定进度表，建议采用Microsoft Project制作Gantt图(插入此处差旅费会议费接待费协作费总计或作为附件)。任务名称起止时间工作人员工作量预期工作成果8.风险管理计划提示：以下是各个