软件开发管理制度【非常经典打灯笼都找不到的好资料】.doc

《软件开发管理制度【非常经典打灯笼都找不到的好资料】.doc》由会员分享，可在线阅读，更多相关《软件开发管理制度【非常经典打灯笼都找不到的好资料】.doc（138页珍藏版）》请在三一办公上搜索。

1、软件开发管理制度第一节 总则第一条 为规范中国人寿保险股份有限公司的自有软件研发和管理工作，特制定本制度。第二条 本制度适用于公司总部软件研发与管理，分公司参照执行。第三条 本制度中软件开发指新系统开发和现有系统重大改造。第四条 软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、软件质量保证、合作开发管理和结项管理。软件工程涉及需求管理、系统设计、系统实现、系统测试、验收测试、试运行、系统验收和系统上线。第五条 除特别指定，本制度中项目组包括业务组、IT组和合作开发商。第六条 总分公司信息技术部内设置项目管理办公室角色(以下简称itPMO，itPMO具体

2、定义请参见多项目管理制度)，统一协调管理各信息技术组。第七条 各软件开发项目组应严格遵循本制度所附流程和模版，如作调整需上报itPMO审批。第二节 立项管理第八条 信息技术部参与公司层面立项，主要工作包括：进行技术可行性分析、参与编写立项建议书、进行前期筹备工作。第九条 信息技术部配合业务部门进行可行性分析，出具可行性分析报告，可行性分析报告中须包含：业务可行性分析、技术可行性分析、成本效益分析。第十条 信息技术部配合业务部门进行立项申请，出具立项建议书，立项建议书中应明确项目的范围和边界。第十一条 牵头业务部门将立项建议书上交公司管理层进行立项审批，以保证系统项目与公司整体策略相一致。第十二

3、条 立项申请得到公司管理层批准后，成立项目组，公司管理层委派项目经理监督项目的进度和负责项目管理工作，信息技术部委派负责人负责IT组的管理和工作。项目组人员的选择是通过考虑项目对业务及技术要求而调配，项目组人员应有足够的业务和IT技术方面的专业知识来胜任项目各方面的工作。 第三节 需求管理第十三条 项目组需制定需求开发计划，并提交项目经理对计划可行性进行审批。第十四条 业务组对用户需求进行汇总整理，出具业务需求说明书，并确保业务需求说明书中包含了所有的业务需求。第十五条 IT组在获得业务需求说明书后，提出技术需求和解决方案，并对系统进行定义，出具需求规格说明书和系统测试案例。需求规格说明书需详

4、细列出业务对系统的要求（界面，输入，输出，管理功能，安全需求，运作模式等）。 第十六条 业务组制定验收测试案例，作为验收测试的依据。该测试案例对第三方保密。第十七条 项目经理组织相关业务、技术人员对需求规格说明书和测试案例进行评审，出具评审报告。通过评审的需求规格说明书和测试案例需提交业务部门和信息技术部负责人签字确认。第十八条 项目经理指定专人负责需求跟踪，确保项目各阶段工作成果同需求的一致性。第十九条 业务需求发生变更时，业务组应出具需求变更申请，并报告业务组负责人审批。第二十条 IT组对变更影响进行评估，结果记录在需求变更申请上，并经过IT组负责人审批。若需求变更涉及项目计划变更，执行项

5、目计划变更流程。第二十一条 项目组应对需求变更影响到的文档及时更新。第二十二条 对于合作开发的项目，IT组是合作开发商获得需求的唯一渠道。第四节 项目计划和监控第二十三条 软件开发采用项目形式进行管理。项目经理负责整个项目的计划、组织、领导和控制。IT组负责人配合项目经理并负责IT组的管理工作。第二十四条 IT组负责人配合项目经理与项目干系人进行有效沟通，在项目目标、项目计划和工作方法上达成一致。第二十五条 需求分析过程中，项目经理组织制定详细的项目计划(包括：综合管理、范围（需求）管理、时间管理、成本管理、人力资源管理、沟通管理、风险管理、采购（合作开发）管理、质量管理、配置管理)，并提交业

6、务部门和信息技术部负责人审批。第二十六条 在项目的各个阶段，业务组和IT组负责人需配合项目经理制定阶段性项目计划。第二十七条 业务组和IT组负责人需配合项目经理对项目计划执行情况进行监控，确保项目按计划完成。IT组负责人按照项目计划规定的报告频度定期填写项目状态周报告，上报项目经理和itPMO。第二十八条 项目进展同项目计划偏差较大时，应申请变更项目计划，项目经理填写项目计划变更控制报告，并提交业务部门和信息技术部负责人批准后执行。第二十九条 IT组负责人负责软件开发过程中的风险识别与管理，重大风险应及时上报项目经理和itPMO。第五节 系统设计第三十条 系统设计应分为概要设计和详细设计，系统

7、设计要遵循完备性、一致性、扩展性、可靠性、安全性、可维护性等原则。第三十一条 项目组需制定系统设计计划，并提交项目经理对计划可行性进行审批。第三十二条 在系统设计阶段中，用户应充分参与，确保系统设计能满足系统需求。第三十三条 项目组进行概要设计，出具概要设计说明书和集成测试案例。itPMO组织相关人员对概要设计和集成测试案例进行评审，出具技术评审报告。业务组和IT组负责人应参加此评审并对评审意见签字确认。第三十四条 项目组进行详细设计，出具详细设计说明书和单元测试案例。详细设计说明书中，需要定义系统输入输出说明和接口设计说明(现存的接口定义应根据新程序需求而更新)，并根据系统运行情况的记录，对

8、应用系统进行优化设计。第三十五条 itPMO组织相关业务、技术人员对详细设计和单元测试案例进行评审，出具技术评审报告。业务组和IT组负责人应参加此评审并对评审意见签字确认。第三十六条 概要设计评审和详细设计评审均以需求规格说明书为依据，确保系统设计满足全部需求。第三十七条 对已确认通过的系统设计进行修改需获得业务部门和信息技术部负责人的审批后方可进行。第六节 系统实现第三十八条 系统实现包括程序编码、单元测试和集成测试。第三十九条 项目组需根据详细设计说明书制定系统实现计划，并提交项目经理对计划可行性进行审批。第四十条 项目组保证开发、测试和生产环境独立，为各环境建立访问权限控制机制，并明确项

9、目成员的职责分工。对生产环境、测试环境与开发环境在物理或逻辑方面应该做到隔离；如果环境的分隔是通过逻辑形式实现的，应由专门人员定期检查网络设置。第四十一条 项目组进行单元测试和集成测试，出具单元测试报告、集成测试报告和BUG管理表，测试人员签字确认测试结果。第四十二条 项目组完成用户操作手册和安装维护手册，凡涉及应用系统的变更，应对两手册及时更新。第七节 系统测试与验收测试第四十三条 项目组需制定系统测试计划和验收测试计划，并提交项目经理对计划可行性进行审批。第四十四条 系统测试计划和验收测试计划需定义测试标准，并明确各种测试的测试步骤和需要的系统设置要求。第四十五条 项目组应向数据拥有部门申

10、请获取测试用业务数据的的使用权限，测试用数据要足够模拟生产环境中的实际数据。对获取的数据应进行 严格的访问控制，确保只有相关项目人员才能访问及使用。对已评定为敏感信息的数据（如客户的银行信息）进行敏感性处理和保护第四十六条 IT组或合作开发商建立测试环境进行系统测试，出具系统测试报告，测试人员签字确认测试结果。第四十七条 系统测试通过后，IT组配合业务组建立验收测试环境，业务组根据验收测试用例进行验收测试，出具验收测试报告。业务部门和信息技术部负责人应在验收测试报告中签字确认。第四十八条 验收测试通过后，项目组应组织完善用户操作手册和安装维护手册的编写，并分别提交业务部门和信息技术部相关人员评

11、审。第八节 试运行第四十九条 项目组需制定试运行计划，上报公司管理层审批。第五十条 项目组联合试运行单位进行相关部署工作。项目组准备培训资料，根据试运行计划对相关用户和信息技术人员进行培训。用户培训的完成度应为实施后评估的指标之一。第五十一条 项目组应确保试运行计划中包含问题应对机制，明确问题沟通渠道和职责分工，并对可能发生的重大问题制定应急预案。第五十二条 项目组根据试运行计划进行系统转换和数据转换。系统转换前，需对各受影响的系统环境做检查，确保运行环境能满足新应用系统的需要。系统转换时要求对原系统中的重要参数、设置等系统运行需要的信息作详细记录，此记录作为新系统上线的要求。系统参数、设置的

12、转换工作作为系统上线的验收的评估指标之一。项目组需对数据转换的完整性和准确性作出检查，出具数据转换记录。系统转换和数据转换由试运行单位业务部门和信息技术部共同监督并进行验收。第五十三条 系统转换和数据转换验收通过后，正式启动试运行。在试运行过程中，试运行单位信息技术部应对系统运行情况（系统资源使用，反应速度等）作记录。必要时，项目组应根据系统运行情况对应用系统进行优化。第五十四条 试运行达到试运行计划规定的终止条件时，项目组编写试运行报告。此报告应由项目组和试运行单位签字确认，并提交公司管理层审阅。第五十五条 公司管理层审阅试运行结果，决定试运行结束或延期。第五十六条 项目组应根据测试标准和试

13、运行结果，制定实施后评估标准。第九节 系统验收第五十七条 系统验收分为功能验收和软件验收，分别由业务组和IT组负责。第五十八条 项目组应根据验收情况整理生成系统验收报告提交业务部门和信息技术部负责人审阅，业务部门和信息技术部负责人根据系统测试、试运行的综合情况签署验收意见，项目组根据验收意见决定是否开展上线工作。 第十节 系统上线第五十九条 系统上线应遵循稳妥、可控、安全的原则。第六十条 项目组制定总体上线计划，总体上线计划应综合考虑资源及系统现状等情况，同时还应充分考虑上线可能给当前系统带来的影响，并取得系统运行部门的意见。总体上线计划经业务部门及信息技术部管理层进行审批后，报公司管理层进行

14、审批并下发各上线单位。各上线单位根据总体上线计划制定各自的上线计划，该计划得到上线单位管理层审批后，提交项目组备案。第六十一条 项目组制定实施后评估计划(包括评估标准、时间安排等)并下发各上线单位。 第六十二条 项目组根据总体上线计划做好相关部署、培训工作，并建立总体的问题应对机制。各上线单位根据各自的上线计划建立同项目组有效衔接的问题应对机制，制定详细上线应急预案，并做好各自的部署、培训、系统转换、数据转换等工作。具体规定参见试运行一节。第六十三条 上线单位在上线初期须加强日常运行状态监控，出现问题时应及时处理，对重大问题应启动紧急预案。第六十四条 上线单位管理层可根据上线情况对上线计划进行

15、调整。调整后的上线计划应及时提交项目组备案。第六十五条 各上线单位在上线完成后，编写系统上线报告，经上线单位管理层审批通过后，上报项目组。第六十六条 项目组及时汇总各上线单位上线报告，报公司管理层审批。 第六十七条 系统上线完成后，各上线单位根据实施后评估计划对系统进行评估，并作详细的评估记录。各单位编写实施后评估报告，上报总部IT运行部门，由其整理后上报公司管理层作为项目整体实施后评估的依据。第十一节 结项管理第六十八条 系统上线完成后，项目组提出结项申请，出具项目总结报告，上报公司管理层审批。 第六十九条 公司管理层批准结项后，业务组和IT组分别整理项目管理文档和工作成果，并提交各自部门统

16、一管理。第七十条 系统结项后，由项目组交由相关运行部门进行维护支持工作。第十二节 配置管理第七十一条 信息技术部制定统一的配置管理规范，各项目组共同遵循。第七十二条 软件开发过程中各项目管理文档和工作成果均作为配置项进行管理，其中包括：需求文档、设计文档、代码、测试用例、测试数据、数据转换记录以及项目相关文档。第七十三条 项目经理指定项目组成员担当配置管理员，负责配置管理工作。第七十四条 配置管理员应根据配置管理规范制定配置管理计划，并提交项目经理审批。第七十五条 配置管理员负责配置库管理、维护，做好配置库的备份工作。第七十六条 项目组应严格执行配置基线的变更流程，评估变更风险及影响，撰写配置

17、项变更控制报告。第七十七条 配置管理员按照配置管理计划规定的审计频度进行配置审计，撰写配置审计报告。第十三节 软件质量保证第七十八条 软件质量保证遵循全员负责、以用户需求为导向、持续改进的原则。第七十九条 itPMO指定项目组成员担当软件质量保证员，负责质量保证工作。软件质量保证员向itPMO负责。第八十条 软件质量保证员制定详细的质量保证计划并提交项目经理审批。第八十一条 对于项目中的质量问题，软件质量保证员应及时提交IT组负责人。IT组负责人在质量保证计划中约定的时间未处理时，软件质量保证员应上报itPMO。第八十二条 软件质量保证员根据质量保证计划规定的报告频度撰写质量管理报告提交IT组

18、负责人、项目经理和itPMO审阅。第十四节 合作开发管理第八十三条 合作开发应本着公开、公正、公平的原则。第八十四条 合作开发商招标参见采购制度。合作商资质认定参见第三方管理制度。第八十五条 IT组应同合作开发商明确项目变更的范围和处理方式，重点关注需求和设计变更。第八十六条 合作开发商应遵循我方软件开发管理制度。第八十七条 IT组负责监控合作开发商的项目管理及软件开发活动。合作开发商应按计划定期向我方IT组报告进展状态，并提交阶段性成果文档。发生重大问题时，合作开发商需及时向IT组汇报。第八十八条 IT组负责人派专人监控合作开发商的质量保证过程。第八十九条 IT组负责人要求合作开发商做好技术

19、转移工作，保证我方人员掌握核心技术。第九十条 项目组同合作开发商商定验收的标准和方法。第九十一条 以上各要求需要在开发合同中明确。第十五节 附则第九十二条 本制度由公司总部信息技术部负责解释和修订。第九十三条 本制度自发布之日起开始执行。附件一 软件开发总流程附件二 立项管理流程附件三 需求开发流程附件四 需求变更流程附件五 项目计划流程附件六 项目计划变更流程附件七 项目监控流程附件八 系统设计流程附件九 系统实现流程附件十 测试流程附件十一 试运行流程附件十二 系统验收流程附件十三 系统上线流程附件十四 结项管理流程附件十五 立项建议书 项目名称 立项建议书文件状态： 草稿 正式发布 正在

20、修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 文档介绍1.1. 文档目的提示：说明写作该文档的目的。例如：该文档将作为公文签报的底稿。1.2. 文档范围1.3. 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），也可以是本项目的其他文档。格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：AAA 作者，立项调查报告，机构名称，日期BBB 作者，立项可行性分析报告，机构名称，日期1.4. 术语与缩写解释缩写、术语解 释2. 项目介绍2.1. 项目目的提示：用简练的

21、语言说明本项目“是什么”，“实现什么目的”。描述简练且清晰。2.2. 项目背景提示：阐述项目背景，重点说明“为什么”会产生本项目。（1）公司的短期、长期发展战略；（2）业务需求及发展趋势；（3）技术状况及发展趋势；（4）特殊的业务需求等。2.3. 项目主要内容和特色提示：（1）给出本项目待开发系统的主要功能列表（概要）；（2）简要说明客户对系统要求；（3）简要说明本系统的特色。2.4. 项目范围提示：根据对现有需求的了解来确定项目基本范围，说明本系统“应当包含的内容”和“不包含的内容”。3. 项目风险提示：从各个角度分析项目的风险，包含技术、人员、管理等等方面的内容。 4. 项目计划4.1.

22、项目团队提示：说明项目团队的角色、知识技能要求、建议人选、人数、工作时间，如下表所示。角色知识技能要求建议人选、人数工作时间项目经理需求开发人员 系统设计人员 编程人员 测试人员质量保证人员配置管理人员服务与维护人员4.2. 软件硬件资源估计提示：（1）估计项目所需的软件和硬件资源，说明主要配置。（2）说明以何种方式获得，如“已经存在”、“可以借用”或“需要购买”等。（3）资源的级别为“关键”、“普通”两种，如果关键资源不能及时到位，可能危害项目。资源名称级别详细配置获取方式费用关键关键普通普通4.3. 成本估计内容成本（人民币）备注人力资源软硬件资源差旅费会议费接待费4.4. 进度表提示：制

23、定项目开发的进度表（建议给出项目里程碑计划）。例如：编号里程碑名称预计结束时间备注需求调研完成项目计划完成需求分析完成概要设计完成详细设计完成实现完成集成测试完成系统测试完成用户验收测试完成试运行结束项目验收5. 总结提示：给出清晰的建议结论，便于上级领导决策。附件：可行性分析报告附件十六 可行性分析报告 项目名称 可行性分析报告文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 项目介绍提示：简要介绍项目目的、项目内容等内容。2. 可行性分析2.1. 政策分析提

24、示：分析有无政策“支持”或者“限制”2.2. 技术可行性分析提示：对核心业务需求的技术解决方案，如，硬件、软件、开发技术或策略、以及设计和实施方案的选择及理由。该部分内容一般由售前咨询技术顾问给出。2.3. 时间资源可行性分析提示：结合项目的限制条件，如工期、成本或其它客观限制条件来分析可行性。2.4. 成本效益可行性分析提示：结合公司近远期战略目标、优势、不足、机遇、威胁等，对项目进行收益测量分析。该部分内容一般由业务部门和IT部门共同给出。2.5. 总结提示：给出清晰的结论（可行、不可行或在什么条件下可行），便于上级领导决策。附件十七 技术评审报告 项目名称 XXX技术评审报告文件状态：

25、草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 基本信息提示：由评审主持人或评审员填写此表格。待评审的工作成果工作成果名称，标识符，版本，作者，时间技术评审方式（正式技术评审）FTR或者(非正式技术评审)ITR评审时间评审地点参加技术评审的人员类别名字工作单位职称、职务：主持人评审小组成员记录员2. 缺陷识别提示：由评审主持人或评审员填写此表格。已识别的缺陷建议缺陷解决方案3. 评审结论与意见提示：由主持人或评审员填写此表格。评审结论 工作成果合格，“无需修改”或者“需要

26、轻微修改但不必再审核”。 工作成果基本合格，需要作少量的修改，之后通过审核即可。 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。意见负责人签字签字：日期：4. 缺陷修正、跟踪与审核提示：由审核人员填写此表格。如果使用缺陷跟踪软件，则无需填写此表。缺陷跟踪缺陷名称何人何时如何解决审核人意见、签字审核修正后的工作成果修正后的工作成果工作成果名称，标识符，版本，作者，时间审核结论 修正后的工作成果合格。 修正后的工作成果仍然不合格，需重新修改。审核人员签字签字：日期：5. 附录. 技术评审问答记录提示：（1）由记录员填写此表格。（2）主要记录评审过程中的“疑问”、“答复”、“争论”、“处

27、理意见”等。记录1记录2记录3记录员签字签字：日期：附件十八 需求变更申请需求变更申请申请变更的需求文档输入名称，版本，日期等信息变更的内容及其理由申请人签字变更申请的审批意见评估需求变更将对项目造成的影响任务与进度说明需增加或减少的数值工作成果同上费用同上人力资源同上软硬件资源同上项目经理签字审批意见：签字，日期更改需求文档变更后的需求文档输入名称，版本，完成日期等信息更改人签字变更结束项目经理签字签字日期： 附件十九 用户需求说明书 项目名称 用户需求说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版

28、 本 历 史版本/状态作者参与者起止日期备注 目 录 1. 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文档1.5 术语与缩写解释2. 产品介绍3用户需求调查记录A.1 需求标题1A.n 需求标题N4需求建模与分析报告B.1 需求模型1B.n 需求模型N1. 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文档提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：SPP-PROC-PP SEPG，需求开发规范，机构名称，日期1.5 术语与缩写解释缩写、术语解 释2. 系统介绍提示：（

29、1）说明系统是什么，什么用途。（2）介绍系统的开发背景。3用户需求调查记录 常见需求调查方式有：与用户交谈，向用户提问题。参观用户的工作流程，观察用户的操作。向用户群体发调查问卷。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。从Internet上搜查相关资料。A.1 需求标题1需求标题1调查方式调查人调查对象时间、地点需求信息记录A.n 需求标题N需求标题N调查方式调查人调查对象时间、地点需求信息记录4需求建模与分析报告B.1 需求模型1B.n 需求模型N附件二十 需求规格说明书 项目名称 需求规格说明书文件状态： 草稿 正式发布 正在修改

30、文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 引言本节仅仅是对需求规格说明书SRS文档的概述，而不涉及软件系统的构建。引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。1.1. 目的描述软件需求说明书（SRS）的目的。1.2. 预期读者列举软件需求说明书所针对的不同读者，例如客户、用户

31、、市场人员、销售人员、项目经理、开发人员、测试人员、维护人员或文档编写人员。1.3. 范围提供指定软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。 定义软件产品名称（如 Host DBMS, Report Generator等）;说明软件产品将做什么，如有必要，还要说明不做什么;描述该软件的应用，包括相关的利益，对象和目标;如果高层规范（如业务说明书）中有类似说明，在本文中的对应部分要保持一致 1.4. 定义和缩写解释理解SRS所需的术语、缩写的定义（Acronyms, Abbreviations, Definiti

32、ons)，本节也可以引用SRS的附录或其它文档。1.5. 格式和排版约定本节详细描述了本文所遵循的符号约定，至少需要提到本文所画图中的注释语言，以及任何与标准概念不同的符号或风格1.6. 参考文献列举编写软件需求规格说明时所参考的资料或资源，包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。在这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅。例如:内容和组织SRS的内容综述；SRS的组织结构。可选: 提出最适合于每一类型读者阅读文档的建议。2. 系统/产品概述要构建的产品或系统的概述. 概述正在定义的产品

33、以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。2.1. 系统/产品综述本节从与其他产品关系的角度来看待本软件产品。如果本产品是一个独立的、完全自包含的产品，就需要在这里进行说明。如果本产品象通常那样，是大系统中的一个组件，这节就需要描述大系统对本产品的功能需求，并且标识出大系统本产品的接口。用块图来显示大系统中的主要组件、组件的相互关系，以及它们的外部接口，通常是种比较好的方法。所谓产品角度，就是系统的环境。特别地，描述了与系统交互的软件或硬件组件。详细的描述则没有必要，因为后面还有接口规范。这里只需给出与其他组件接口的概述。本节用上下文图来描述比较合适。2.2. 系统/产品功能

34、本节汇总了软件需实现的主要功能。如一个记账程序的SRS在这里描述客户账户的维护，客户声明，发票准备等，而无需提及这些功能大量的具体细节。有时，这里汇总的功能可以直接取自高层规格说明书（如果存在的话），高层规格说明书中分配了该软件产品特定的功能。这样做是为了描述清楚：功能的组织应该达到这种效果：客户或者其他任何第一次读本文的人，都能理解这些功能列表。文本或图形方法也能用来显示不同的功能以及它们的关系。该图并不是想显示一个产品的设计，而仅仅用来显示变量之间的逻辑关系这里只给出系统主要功能的概述。功能的具体描述在本文后面进行。本节仅从用例名称上对功能进行汇总。2.3. 用户特征本节说明系统或产品最终

35、用户所需具备的一般特征：受教育水平，经验积累，技术技能等。这里不涉及具体的需求，但决定了SRS第三章所描述的某些需求的原因，如系统可能为初级和高级用户设计不同的界面。2.4. 运行环境描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。2.5. 限制本节列出了用来限制开发者选择的其他条款的简要描述。包括：调整策略硬件限制（如，信号定时需求）与其他应用的接口并行操作核查功能控制功能高层语言需求信号握手协议（如XON-XOFF, ACK-NACK）可靠性需求应用的危险程度安全和保密考虑2.1节到2.3节描述了对需求可能的限制的来源。2.1节描述了已经存在的组

36、件，它们可能会限制需求；2.2节描述了希望的功能，它们必然影响了本文描述的需求；2.3节描述了用户背景，这可能影响到可用性问题。本节则描述了其他限制的来源。你需要考虑是否有其他限制需求或设计的因素。2.6. 假设和依赖条件本节列出了影响SRS所声明的需求的各个因素。这些因素并不对软件的设计进行约束，但这些因素的变化会影响SRS中的需求。比如，假定为软件产品设计的硬件上运行的是一个特定的操作系统，而实际上这种操作系统却不可用，那么SRS就不得不进行相应地改动。关于输入、环境的假定和依赖。如，许多系统对环境做了很多的假定。只有这些来自环境的输入满足这些假定的时候，这些系统才会正常工作。如，物理定理

37、如，铁道交叉口控制器假定当栏杆下落时，行人会避开交叉口。你需要考虑以下环境条件：可能导致你的软件系统失效的环境环境的改变将导致你修改软件需求3. 外部接口需求本节详细描述了软件系统的输入和输出。它包含的内容和格式如下：条目名称目的描述输入来源或输出的目的地有效范围、精确度，以及/或者容限测量单元定时与其他输入输出的关系屏幕格式/组织窗口格式/组织数据格式命令格式结束消息3.1. 操作员接口用户接口不仅难以描述，而且我们也难以阅读和理解。作者必须知道隐藏在用户接口下面的大量功能。在屏幕上点击、绘制窗口窗口上各个UI部件（按钮、菜单选项等）的目的与各个窗口相联系的输入/输出事件列表输出事件在窗口显

38、示中的效果（用一两行进行描述）如何在窗口间切换我们并不是在写小说。一两行语句足以描述一个目的或效果。信息浏览可能已经在目的描述中被描述了（如，菜单选项）3.2. 用户接口3.3. 硬件接口你仍然需要写明在HWIF和系统所收到的软件事件间的转换列出和每一硬件设备相关的输入输出事件对硬件设备产生影响的输出事件3.4. 软件接口 通常情况下，你需要给目标参数如数据字典一样详细的描述，你也需要描述在SWIF中没提到目标信息列出和每一信息相关的输入输出事件对软件组件产生影响的输出事件3.5. 通信接口4. 详细需求 4.1. 功能性需求分类提示：将功能性需求先粗分再细分，下表中的 Feature A,

39、Function A.1等符号应当被替换成有含义的名称。功能类别功能名称、标识符描述Feature AFunction A.1Feature BFunction B.1Feature CFunction C.14.m Feature M提示：此处写一些承上启下的文字。4.m.n Function M.N名称、标识符功能描述优先级输入操作序列输出补充说明5. 非功能需求5.1. 性能需求此小节将详细说明关于软件或人和软件间作为一个整体进行交互的动、静态数字化需求。静态的数字化需求可能包括以下几下：支持的终端用户数支持的并发用户数处理的信息数和类型静态数字化需求有时候另辟一节叫性能来详细描述动态数

40、字化需求可能包括在给定时间周期内，包括通常情况和高峰期，所能处理的数据量、交易数和任务量.所有这些需求都应该用可测术语描述例如：在一秒钟内，95的交易应该得到处理胜于，某个操作员不能有等待交易完成的感觉注意：应用特定功能的数字化限制作为对应功能的处理描述的子段的一部分描述可靠性：此处规定了软件系统发布时需要建立的可靠性所要求的因素。有效性：此处规定了用以保证整个系统所定义的有效性的因素，诸如检查点、恢复和重启动。安全性：此处规定了保护软件不受意外或恶意访问、使用、修改、破坏或揭露而采用的因素。本节规定的特殊需求包括：(1)使用特定的加密技术(2)保存特定的日志或历史数据(3)将特定的功能指定到

41、不同的模块(4)限制程序的部分区域进行通信(5)对敏感变量进行数据完整性检查可维护性：规定软件自身易于维护的特点。这些涉及对一定模块、接口、复杂性等的需求。需求不应放在这里，因为它们属于好的设计实践。可移植性： 规定了软件易于移植到其他主机和/或操作系统上的特性。它可能包括以下一些特征：(1)用依赖主机代码编写的组件的百分比(2)依赖主机的代码的百分比(3)使用证实的可移植的语言(4)使用特定的编译器或语言子集(5)使用特定的操作系统。5.2. 可扩展性5.3. 可靠性5.4. 安全性5.5. 可用性6. 术语表7. 其它 (可选)这部分并不总是也可能没必要是真正的SRS的一部分。它们可能包括:输入/输出格式样例，费用分析研究描述，或用户调查结果帮助SRS读者理解的支持或背景知识软件所要解决的问题的描述特别的代码包装指令和媒体，以符合安全性、出口、初始加载或其他需求。如果包含有附录，SRS需要明确说明附录是否应被认为是需求的一部分。附录：需求确认需求确认需求文档输入名称