软件开发管理制度范本33239138897.docx

软件开发管理制度第一节 总 则第一条 为规范自有有软件研发发以及外包包软件的管管理工作，特特制定本制制度。本制制度适用于于公司总公公司软件研研发与管理理，分公司司参照执行行。第二条 本制度中软软件开发指指新系统开开发和现有有系统重大大改造。第三条 本制度中自自行开发是是指主要依依赖公司自自身的管理理、业务和和技术力量量进行系统统设计、软软件开发、集集成和相关关的技术支支持工作，一一般仅向外外购置有关关的硬件设设备和支撑撑软件平台台；合作开开发是公司司与专业IIT公司（合合作商）共共同协作完完成IT应应用的项目目实施和技技术支持工工作，一般般形式是公公司负责提提供业务框框架，合作作商提供技技术框架，双双方组成开开发团队进进行项目实实施，ITT系统的日日常支持由由研发部和合合作商共同同承担，研研发负责内内部支持，合合作商负责责外部支持持；外包开开发是指将将IT应用用项目的设设计、开发发、集成、培培训等任务务承包给某某家专业公公司（可以以是专业的的IT公司司或咨询公公司等），由由该公司（承承包商）负负责应用项项目的实施施。第四条 软件开发遵遵循项目管管理和软件件工程的基基本原则。项项目管理涉涉及立项管管理、项目目计划和监监控、配置置管理、合合作开发管管理和结项项管理。软软件工程涉涉及需求管管理、系统统设计、系系统实现、系系统测试、用用户接受测测试、试运运行、系统统验收、系系统上线和和数据迁移移。第五条 除特别指定定，本制度度中项目组组包括业务务组（营销销部、运维维部）、IIT组（研研发部和合合作开发商商）。第二节 立项管理理第六条 提出开发需需求的营销销部、运维维部等业务务部门参与公公司层面立立项，研发发部进行立立项的技术术可行性分分析，共同同编写立项分析析报告（附件一一），开展展前期筹备备工作。立项分分析报告应应明确项目目的范围和和边界。第七条 应用系统主主要使用部部门将立项分析析报告上交公司进进行立项审审批，以保保证系统项项目与公司司整体策略略相一致。第八条 立项分析析报告得到批准准后，成立立项目组（如如果是外包包开发，则则成立外包包商项目组组；如果是是合作开发发，则与外外包商共同同成立合作作开发项目目组，以下下统称“项目组”），项目目组应包括括业务组（由由公司相关关业务部门门组成）和和IT组（自自行开发为为研发部；外外包开发为为外包商成成员；合作作开发为研研发部和外外包商成员员）。公司司委派一名名员工负责责监督项目目的进度，进进行项目管管理工作，确确保开发能能及时完成成并能满足足业务需要要。项目组组人员的选选择应满足足项目对业业务及技术术要求，项项目组人员员应有足够够的业务和和IT技术术方面的专专业知识来来胜任项目目各方面的的工作。第三节 需求分析析第九条 立项后业务务组对用户户需求进行行汇总整理理，出具业务需求求说明书（附件二二），并确确保业务需求求说明书中包含了了所有的业业务需求。业务需求说明书经系统使用单位（用户）确认，作为业务需求基线。第十条 IT组在获获得业务需求求说明书后，提出出技术需求求和解决方方案，并对对系统进行行定义，出出具系统统需求规格格说明书（附件三三）。系统需求求规格说明明书需详细列列出业务对对系统的要要求（界面面、输入、输输出、管理理功能、安安全需求、运运作模式、关关键指标等等）。系统需求规规格说明书书需要由业业务组提交交给用户相关业业务流程负负责人确认认。第十一条 当业务需求求发生变更更时，业务务组应提交交需求变更更申请（附件四四），ITT组组长审审批后交给给业务组与与用户确认认方可实施施。第十二条 项目组应对对需求变更更影响到的的文档及时时更新。第四节 项目计划划和监控第十三条 软件开发采采用项目形形式进行管管理。项目目经理（监监理）负责责整个项目目的计划、组组织、领导导和控制。第十四条 需求分析过过程中，项项目经理（监监理）组织织制定详细细的项目计划划书（附件五五），包括括具体任务务描述和项项目进度表表等。第十五条 在项目的各各个阶段，业业务组组长长和IT组组组长需配配合项目经经理（监理理）制定阶阶段性项目目计划。业业务组组长长和IT组组组长需配配合项目经经理（监理理）对项目目计划执行行情况进行行监控，确确保项目按按计划完成成。第十六条 项目计划需需要变更时时，项目经经理（监理理）填写项目计划划变更说明明（附件六六），并提提交公司主主管领导审审批，通过过审批后，交交给业务组组组长和IIT组组长长执行。第五节 系统设计计第十七条 系统设计应应分为概要要设计和详详细设计，系系统设计要要遵循完备备性、一致致性、扩展展性、可靠靠性、安全全性、可维维护性等原原则。第十八条 在系统设计计阶段中，用用户应充分分参与，确确保系统设设计能满足足系统需求求。第十九条 项目组进行行详细设计计，出具设计说明书（附件七）和单元测试用例（附件八）。设计说明书中需要定义系统输入输出说明和接口设计说明。公司主管领导组织相关人员对概要设计进行评审，出具设计评审报告（附件九）。业务组组长和IT组组长应参加此评审并对评审意见签字确认。第二十条 设计评审均均以业务务需求说明明书和系系统需求规规格说明书书为依据据，确保系系统设计满满足全部需需求。第二十一条 对已确认通通过的系统统设计进行行修改需获获得管理部部门、业务务组组长和和IT组组组长的审批批后方可进进行。第二十二条 对系统设计计的修改的的文档须由由文档管理理人员进行行归档管理理。第六节 系统实现现第二十三条 项目组根据据设计说明明书制定系统统实现计划划，并提交交项目经理理（监理）对对计划可行行性进行审审批。第二十四条 系统实现包包括程序编编码、单元元测试和集集成测试。第二十五条 项目组保证证开发、测测试和访问问环境独立立，为各环环境建立访访问权限控控制机制，并并明确项目目成员的职职责分工。对对开发环境境、测试环环境与访问问环境在物物理或逻辑辑方面应该该做到隔离离；如果环环境的分隔隔是通过逻逻辑形式实实现的，应应定期检查查网络设置置。项目组组对已授权权访问环境境的人员进进行详细记记录，并对对该记录进进行定期检检查，确保保只有经授授权的人员员才能访问问。第二十六条 项目组进行行单元测试试和集成测测试，测试试人员签字字确认测试试结果。第七节 系统测试试和用户测测试第二十七条 项目组制定定系统/用户户测试计划划（附件十十），并提提交项目经经理（监理理）对计划划可行性进进行审批。第二十八条 系统/用用户测试计计划必须定义义测试标准准，并明确确各种测试试的测试步步骤和需要要的系统设设置要求。第二十九条 项目组向数数据拥有部部门申请获获取测试用用业务数据据的使用权权，对获取取的数据进进行严格的的访问控制制，确保只只有相关项项目人员才才能访问及及使用。第三十条 项目组负责责测试数据据准备，测测试用数据据要足够模模拟使用环境中中的实际数数据。对已已评定为敏敏感信息的的数据进行行敏感性处处理和保护护。第三十一条 IT组或合合作开发商商建立测试试环境进行行系统测试试。在系统统测试中对对新系统内内部各模块块之间的接接口和与其其他系统的的接口进行行充分测试试。出具系统测试试报告（附件十十一），测测试人员签签字确认测测试结果。第三十二条 系统测试通通过后，IIT组配合合业务组建建立用户测测试环境，业业务组根据据用户测试试用例进行行用户测试试，出具用户测试试报告（附件十十一），业业务组组长长和IT组组组长应在在用户测试试报告中签签字确认。第三十三条 项目组完成成系统帮助助文档（其其中包括用用户操作手手册和安安装维护手手册）。凡凡涉及应用用系统的变变更，应对对系统帮助助文档及时时更新。第八节 试运行第三十四条 系统主要使使用部门根根据项目规规模及影响响决定试运运行策略。第三十五条 项目组制定定试运行计计划（附件十十二），并并制定试运运行验收指指标，上报报公司主管管领导审批批。试运运行计划中中应包含问问题应对机机制，明确确问题沟通通渠道和职职责分工。第三十六条 项目组联合合试运行单单位进行相相关系统部部署工作，准准备培训资资料，对相相关用户和和信息技术术人员进行行培训。用用户培训的的完成度应应为实施后后评估的指指标之一。第三十七条 项目组根据据试运行计计划进行系统统转换和数数据迁移。系系统转换前前，检查系系统环境，确确保运行环环境能满足足新应用系系统的需要要。系统转转换时必须须详细记录录原系统中中的重要参参数、设置置等系统信信息，并填填写试运行行报告相关关内容。系系统参数、设设置的转换换工作作为为系统上线线的验收的的评估指标标之一。第三十八条 数据迁移前前，应制定定详细的数据迁移移计划（附件十十三），数据迁移移计划中应包含含迁移方案案、测试方方案、数据据定义，新新旧数据对对照表、迁迁移时间、回回退计划等等信息。数数据迁移计计划需经项项目经理（监监理）和主主管领导签签字审批。第三十九条 数据迁移后后，项目组组对数据迁迁移的完整整性和准确确性作出检检查，出具具数据迁迁移报告（附附件十四），其中包括数据来源、转换前状态、转换后状态，数据迁移负责人、对完整性检查情况、对准确性检查情况等内容。各相关部门验收转换结果后在该报告上签字确认。第四十条 系统转换和和数据迁移移由试运行行单位业务务部门和公公司主管领领导共同监监督并进行行验收。第四十一条 系统转换和和数据迁移移验收通过过后，正式式启动试运运行。在试试运行过程程中，试运运行单位办办公室把系系统运行情情况（系统统资源使用用，反应速速度等）记记录到试运运行报告中中。必要时时，项目组组应根据系系统运行情情况对应用用系统进行行优化。第四十二条 试运行达到到试运行计计划规定的的终止条件件时，项目目组编写试运行报报告（附件十十五）。此报告应应由项目组组和试运行行单位签字字确认，并并提交公司司主管领导导审阅。公公司主管领领导审阅试试运行结果果，决定试试运行结束束或延期。第九节 系统验收收第四十三条 系统主要用用户单位及及公司项目目组联合组组成独立系系统验收小小组，也可可授权原项项目组作为为验收小组组。验收小小组从功能能需求及技技术需求层层面对系统统进行综合合评估。 第四十四条 验收小组应应根据验收收情况整理理形成系系统验收报报告（附附件十六）提交系统主要使用部门和公司审阅。第四十五条 系统主要使使用部门和和研发部负责责人根据系系统测试、试试运行情况况签署验收收意见。 第十节 系统上线线第四十六条 系统上线应应遵循稳妥妥、可控、安安全的原则则。第四十七条 通常情况下下，系统上上线包含数数据迁移工工作。第四十八条 项目组制定定系统上线线计划（附件十十七），上上报公司主主管领导审审批。在上上线计划得得到批准后后才能开始始部署上线线工作。第四十九条 系统上线线计划内内容应包括括但不限于于：1、部署方方式和资源源分配（包包括人力资资源及服务务器资源）；2、上线工工作时间表表；3、上线操操作步骤以以及问题处处理步骤；4、项目阶阶段性里程程碑和成果果汇报（项项目执行状状态的审阅阅、进度安安排等）；5、数据迁迁移的需求求和实施计计划；6、完整可可行的应急急预案和“回退”计划；7、用户培培训计划（包包括：培训训计划、培培训手册、培培训考核等等）；8、总公司司下发的系系统标准参参数配置。第五十条 上线单位在在上线初期期需加强日日常运行状状态监控，出出现问题时时应及时处处理，对重重大问题应应启动紧急急预案。第五十一条 在完成上线线后要填写写系统验验收评估报报告（附附件十八），上报总公司项目组汇总整理。系统验收评估报告内容包括：数据准确性、系统性能及稳定性、接口问题、权限问题、业务操作影响度、问题处理情况、备份、批处理等。第五十二条 上线单位管管理层要对对系统验验收评估报报告进行行审批签字字。第五十三条 公司主管领领导批准结结项后，业业务组和IIT组将整整理的文档档提交各自自部门统一一管理。第十一节 合作开开发管理第五十四条 合作开发商商的选择应应遵循公司司相关规定定，合作商商资质认定定参见第三三方管理制制度。第五十五条 合作开发商商必须遵循循公司软软件开发管管理制度。第五十六条 项目经理同同合作开发发商明确规规定项目变变更的范围围和处理方方式，重点点关注需求求和设计变变更。第五十七条 项目经理负负责监控合合作开发商商的项目管管理及软件件开发活动动。合作开开发商应按按计划定期期向项目经经理报告进进展状态，并并提交阶段段性成果文文档。发生生重大问题题时，合作作开发商需需及时向项项目经理汇汇报。第五十八条 IT组组长长派专人监监控合作开开发商的质质量保证过过程。第五十九条 项目组同合合作开发商商商定验收收的标准和和方法。第六十条 以上各要求求需要在开开发合同中中明确。第十二节 外包开开发管理第六十一条 立项申请得得到公司主主管领导的的审批后，选选定开发商商，签订外外包开发合合同。第六十二条 项目经理负负责监控外外包开发商商的项目管管理及软件件开发活动动。外包开开发商应按按计划定期期向项目经经理报告进进展状态，并并提交阶段段性成果文文档。发生生重大问题题时，外包包开发商需需及时向项项目经理汇汇报。第六十三条 项目经理监监控外包开开发商的质质量保证过过程。第六十四条 项目组同外外包开发商商商定验收收的标准和和方法。第六十五条 以上各要求求需要在开开发合同中中明确。第十三节 角色与与职责表第六十六条 主要角色及及其职责如如下表所示。企企业在应用用时，可以以将各个角角色映射到到企业原有有的岗位上上，也可以以依据角色色建立新的的岗位。一一个人可以以被赋予多多个角色，视视具体情况况而定。常设角色职责简述机构过程改改进角色软件工程过过程组（SEPGG）（1）制定定适合于本本机构的过过程规范。（2）在机机构范围内内推广该规规范（如培培训、考核核），评估估机构过程程能力等。质量保证小小组（QAG）（1）监督督规范的实实施，确保保所有项目目以及相关关部门准照照规范开展展工作。（2）分析析并解决机机构内存在在的共性质质量问题，协协组SEPPG完善规规范。项目管理过程角色机构领导（1）是机机构内所有有项目的主主管，对立立项管理和和结项管理理有最终决决策权。（2）监督督项目经理理的工作，审审批项目经经理的各种种申请。项目经理（1）向机机构领导汇汇报工作。（2）是项项目规划、项项目监控、风风险管理和和需求管理理过程域的的负责人。（3）监督督项目成员员的工作，审审批项目成成员的各种种申请。项目研发过程角色需求分析员员调查、分析析并定义需需求，撰写写相应的需需求文档，尽尽最大努力力使需求文文档能够正正确无误地地反映用户户的真实意意愿。系统设计师师根据需求文文档设计软软件系统的的体系结构构、用户界界面、数据据库、模块块等，并撰撰写相应的的设计文档档。程序员（1）根据据系统设计计文档，编编写软件系系统的代码码。（2）随时时测试和检检查自己的的代码，及及时消除代代码中的缺缺陷。测试员从事单元测测试、集成成测试和系系统测试，主主要工作包包括制定测测试计划、设设计测试用用例、执行行测试和撰撰写测试报报告。机构支撑过程角色配置管理员员（1）为项项目制定配配置管理计计划。（2）创建建并维护配配置库，如如分配权限限、清除垃垃圾文件、备备份配置库库等。质量保证员员（即QAGG成员）（1）为项项目制定质质量保证计计划。（2）周期期性的开展展“过程与产产品质量检检查”。（3）跟踪踪质量问题题，给出质质量改进措措施。外包管理员员（1）挑选选最合适的的承包商，签签订外包开开发合同。（2）监控控外包开发发过程，验验收外包开开发成果。采购管理员员（1）挑选选最合适的的供应商，签签订采购合合同。（2）验收收采购物品品。培训管理员员制定机构（或或项目）的的培训计计划，监监督该计划划的实施，撰撰写培训训评估报告告。客户服务人人员为客户提供供与产品相相关的服务务（如技术术咨询），快快速响应客客户的要求求，给客户户一个满意意的解答。产品维护人人员（1）纠错错性维护：及时解决决用户遇到到的技术故故障和消除除产品中的的缺陷。（2）完善善性维护：在资源允允许的情况况下，不断断改善产品品功能与质质量。临时角色职责说明立项建议小小组（1）开展展立项调查查、产品构构思和可行行性分析，撰撰写相应文文档。（2）申请请立项，并并在立项评评审会议上上答辩。立项评审委委员会由机构领导导、各级经经理、市场场人员、技技术专家、财财务人员等等组成，委委员会按少少数服从多多数原则投投票决定是是否同意立立项。结项评审委委员会对项目的有有形资产和和无形资产产进行清算算，对项目目进行综合合评估，总总结经验教教训等。结结项委员会会的人员组组成与立项项评审委员员会的类似似。技术评审委委员会对工作成果果进行正式式技术评审审，尽早地地发现工作作成果中的的缺陷，并并帮助开发发人员及时时消除缺陷陷。该委员员会由项目目内外的技技术专家组组成。配置控制委委员会对配置管理理各项活动动拥有决策策权（例如如审批计划划，审批变变更请求等等）。第十四节附附则第六十七条 本制度由公公司研发部负责责解释和修修订。第六十八条 本制度自发发布之日起起开始执行行。 附件一 立项分析报报告文件状态： 草草稿 正式发布布 正在修改改文件标识：当前版本：作 者：完成日期：版 本 历历 史版本/状态态作者参与者起止日期备注1. 项目介绍1.1. 项目目的提示：用简简练的语言言说明本项项目“是什么”，“实现什么么目的”。描述简简练且清晰晰。1.2. 项目背景提示：阐述述项目背景景，重点说说明“为什么”会产生本本项目。（1）公司司的短期、长长期发展战战略；（2）业务务需求及发发展趋势；（3）技术术状况及发发展趋势；（4）特殊殊的业务需需求等。1.3. 项目范围提示：根据据对现有需需求的了解解来确定项项目基本范范围，说明明本系统“应当包含含的内容”和“不包含的的内容”。2. 项目计划2.1. 项目团队提示：说明明项目团队队的角色、知知识技能要要求、建议议人选、人人数、工作作时间，如如下表所示示。角色知识技能要要求建议人选、人人数工作时间项目经理需求开发人人员 系统设计人人员 编程人员 测试人员质量保证人人员配置管理人人员服务与维护护人员2.2. 成本估计内容成本（人民民币）备注人力资源软硬件资源源差旅费会议费接待费2.3. 项目时限：根据用户户要求和公公司研发能能力设定计计划研发完完成时间3. 总结提示：给出出清晰的建建议结论，便便于上级领领导决策。附件二 业务需求说说明书（业业务组编制制）文件状态： 草草稿 正式发布布 正在修改改文件标识：当前版本：作 者：完成日期：版 本 历历 史版本/状态态作者参与者起止日期备注1概述1.1 业业务调研人人员名单【可选】序号职能部门姓名主管联系电话备注1.2业务务范围此处描写总总体业务的的概要分类类。1.3 业业务目标从高层或商商务利益的的角度提出出本业务系系统的期望望目标，以以及评价标标准。1.4 相相关文档说明：列出出本文档的的所有参考考文献（可可以是非正正式出版物物），包括括现有规范范、标准、批批文、引用用到的文件件、资料等等。1.5 业业务词汇表表说明：列出出本文档的的所引用的的专属领域域词汇、术术语等，以以便于业务务需求的提提供者和接接收者是建建立在一致致的业务理理解基础之之上的。2 组织结结构及业务务2.1 业业务相关组组织结构、人人员组织结结构说明：如果果客户岗位位设置复杂杂可分别设设置，业务务组织结构构和人员组组织结构2.2 组组织机构描描述2.3 角角色职责说明：将业业务涉及的的具体人员员进行一定定程度的分分类和抽象象，描述该该抽象角色色的操作职职责。2.4 管管理综述【可选】说明：主要要描述该业业务的管理理特点和管管理模式。例例如：2.5 现现有业务流流程清单【可选】说明：现有有业务流程程需要考虑虑，很多新新的业务是是在已有业业务流程基基础上进行行重组的。流程编号流程名称责任部门辅助部门3 业务流流程及业务务处理描述述说明：针对对每一项具具体的目标标业务，描描述具体的的业务流程程，以及相相关业务的的具体描述述。3.1 具具体业务流流程（系统统名称+编编号）对于具体业业务流程的的命名有规规范，对具具体流程进进行编号，便便于形成需需求矩阵，同同时形成需需求的管理理和跟踪。3.1.11业务流程程3.1.22业务描述述说明：描述述具体的业业务流程。3.1.33相关业务务对象说明：业务务对象：业业务流程中中涉及的单单据、报表表等。业务对象使用部门对应电子档档案编号3.1.44业务规则则及关键算算法说明：描述述业务环节节关键算法法体系。4 假定和和约束说明：列出出进行本软软件开发工工作的假定定和约束，例例如开发期期限等。4.1 运运行环境约约束4.2 设设计约束【可选】说明：开发发过程中必必须使用的的软件语言言、软件进进程需求、主主要开发工工具、核心心技术、第第三方产品品等。4.3 产产品应当遵遵循的标准准或规范【可选】说明：阐述述本产品应应当遵循什什么标准、规规范或业务务规则，违违反标准、规规范或业务务规则的产产品通常不不太可能被被接受。5 其他5.1 目目前核心问问题和困难难5.2 业业务对项目目实施的需需求和期望望【可选】5.3 其其他未尽事事宜附件三 系统需求规规格说明书书（IT组组编制）文件状态： 草草稿 正式发布布 正在修改改文件标识：当前版本：作 者：完成日期：版 本 历历 史版本/状态态作者参与者起止日期备注1 引言1.1 目目的例如：规定定系统的边边界和目标标，描述系系统的功能能性需求和和非功能性性需求。1.2读者者对象及阅阅读建议说明：指明明本文档面面向的读者者群，及相相应的阅读读意见。1.3文档档范围【可选】说明：对本本文的范围围做阐述，本本文档改动动时，受到到影响的范范围，例如如，本文引引用到的用用例模型，系系统原型，系系统测试用用例等文档档。1.4 参参考文档说明：列出出本文档的的所有参考考文献（可可以是非正正式出版物物），包括括计划任务务书、合同同、批文、引引用到的文文件、资料料及软件开开发标准等等。1.5 术术语与缩写写解释说明：列出出本文件中中用到的专专门术语的的定义和缩缩写词的原原词组，并并给予解释释，以便于于所有读者者达成共识识。2 综合描描述2.1 系系统背景【可选】说明：介绍绍系统的预预期效果、历历史原因。2.2 问问题说明【可选】提供一段说说明，总结结此项目需需要解决的的问题。可可以采用以以下格式：问题是对问题进进行说明影响问题影响响的干系人人问题的后果果该问题会会导致什么么后果成功的解决决方案应列出成成功解决方方案的一些些主要优点点2.3系统统范围说明：阐述述本项目“适用的业业务领域”和“不适用的的业务领域域”，本产品品“应当包含含的内容”和“不包含的的内容”。说清楚楚系统范围围的好处是是：（1）有有助于判断断什么是需需求，什么么不是需求求；（2）可可以将开发发精力集中中在产品范范围之内；（3）有有助于控制制需求的变变更。l 完整而准确确的定义本本产品的干干系人；l 明确本产品品所影响到到的部门和和业务；l 用图表或者者文字描述述产品的范范围，概要要的定义产产品的功能能。2.4 干干系人与用用户说明【可选】2.4.11用户环境境【可选】详细说明目目标用户的的工作环境境。以下是是几项建议议：该任务由多多少人来完完成？是否否总在变化化？一个任务周周期需要多多长时间？执行每项项活动要用用多长时间间？是否总总在变化？是否有特殊殊的环境约约束：移动动、户外、乘乘机旅行等等？目前使用的的是哪些系系统平台？以后会使使用哪些平平台？还在使用哪哪些应用程程序？您的的应用程序序是否需要要和这些应应用程序集集成？在此处可以以从业务模模型中摘录录一些内容容来概述所所涉及的任任务和角色色等等。2.4.22 干系人人简档【可选】通过在下表表中填写各各干系人的的相关信息息来说明系系统中的各各个干系人人，详尽的的简档应包包括各种干干系人在以以下方面的的信息：代表谁是此产产品的干系系人代表？（如在他他处已作记记录，则此此处为可选选。）此处处只需填写写姓名。说明对干系人人类型的简简要说明。类型介绍干系系人的技能能特长、技技术背景和和熟练程度度（即权威威用户、业业务用户、专专家用户、初初级用户等等）职责列出干系系人对所开开发的系统统负有的关关键职责，即即他们作为为干系人的的利益。使用频率该干系人人使用系统统的频率意见/问题题在此处列列出会阻碍碍成功的问问题以及任任何其他相相关信息。2.4.33关键的干干系人/用用户需要列出干系人人认为现有有解决方案案存在的关关键问题。对对于列出的的每个问题题，需澄清清以下要点点：为什么么会出现这这一问题？目前如如何解决该该问题？干系人人需要什么么样的解决决方案？务必要了解解干系人或或用户对解解决各个问问题的相对对重视程度度。分级和和累积投票票方法表明明，必须解决的的问题与干干系人或用用户希望解解决的问题题大有不同同。2.5 目目标业务模模型【可选】说明：新系系统业务模模型描述，如如有相应业业务模型材材料了，可可作为需求求规格说明明书的输入入参考资料料。2.6 功功能摘要总结该产品品将提供的的主要优点点和特性，而而不必涉及及每个功能能的细节。对对功能加以以组织，使使客户或初初次阅读该该文档的其其他人能够够理解此功功能列表。2.7 功功能清单及及重要程度度说明说明：功能能名称、功功能描述、重重要程度。重要程度，以以ABC三三类来表示示：A：核核心功能；B：辅助助功能；CC：外围功功能；级别，按照照继承关系系分为：一一级，二级级，三级；编号级别重要程度功能名称功能描述备注2.8 功功能与业务务对照关系系表说明：业务务组为主编编写业务需需求，业务务需求提交交至信息技技术组后，由由信息技术术组建立目目标系统业业务模型并并与业务组组进行确认认（本操作作可选，也也可由信息息技术组与与开发商合合作建立），目目标业务模模型作为系系统需求的的输入，由由信息技术术组与开发发商合作撰撰写和评审审系统需需求规格书书明书。业务需求目标系统业业务活动（可可选）功能名称2.9 假假定和约束束说明：列出出进行本软软件开发工工作的假定定和约束，例例如：开发发语言、开开发期限等等。格式限制说说明：本项项将指定由由现有的标标准或规则则派生的要要求。例如如：报表格式；数据命名名；财务处处理；审计计追踪，等等等。硬件限制说说明：本项项包括在各各种硬件约约束下运行行的软件要要求，例如如，应该包包括：硬件配置的的特点（接接口数，指指令系统等等）；内存存储器和辅辅助存储器器的容量。2.9.11运行环境境约束说明：硬件件设备、支支持软件、接接口、控制制等方面的的约束名称详细要求2.9.22设计约束束【可选】说明：开发发过程中必必须使用的的软件语言言、软件进进程需求、主主要开发工工具、核心心技术、第第三方产品品等。2.9.33产品应当当遵循的标标准或规范范说明：阐述述本产品应应当遵循什什么标准、规规范或业务务规则，违违反标准、规规范或业务务规则的产产品通常不不太可能被被接受。3 具体需需求3.1功能能需求3.1.11具体功能能3.1.11.1内容容说明：对于于每一类功功能或者有有时对于每每一个功能能，需要具具体描述其其输入、加加工和输出出的需求。3.2 非非功能需求求3.2.11 外部接接口3.2.11.1用户户接口说明：提供供用户使用用软件产品品时的接口口需求。例例如，如果果系统的用用户通过显显示终端进进行操作，就就必须指定定如下要求求：a对屏幕幕格式的要要求说明：对界界面上的各各对象、类类型、宽度度、取值范范围、数据据来源、能能否为空等等属性进行行描述。b报表或或菜单的页页面打印格格式和内容容c输入输输出的需求求说明：解释释各输入输输出数据类类型，并逐逐项说明其其媒体、格格式、数值值范围、精精度等。对对软件的数数据输出及及必须标明明的控制输输出量进行行解释并举举例，包括括对硬拷贝贝报告（正正常结果输输出、状态态输出及异异常输出）以以及图形或或显示报告告的描述。d程序功功能键的可可用性说明：快捷捷键定义等等。3.2.11.2 硬硬件接口【可选】说明：要指指出软件产产品和系统统硬部件之之间每一个个接口的逻逻辑特点。还还可能包括括如下事宜宜：支撑什什么样的设设备，如何何支撑这些些设备，有有何约定。3.2.11.3软件件接口【可选】说明：在此此要指定需需使用的其其他软件产产品（例如如，数据管管理系统、操操作系统或或数学软件件包），以以及同其他他应用系统统之间的接接口。对每每一个所需需的软件产产品，要提提供如下内内容：名字字、助记符符、规格说说明号、版版本号、来来源。对于每一个个接口，这这部分应说说明与软件件产品相关关的接口软软件的目的的，并根据据信息的内内容和格式式定义接口口，但不必必详细描述述任何已有有完整文件件的接口，只只要引用定定义该接口口的文件即即可。【接口定义义】下表是对一一些接口的的具体描述述:接口名称接口描述填写接口完完成的任务务接口类型填写是输入入接口（iinbouund）还还是输出接接口（ouutbouund）源系统填写接口输输入方系统统或部件目标系统填写接口输输出方系统统或部件厂商提供/客户化开开发文件类型填写文件类类型；若通通过数据库库表来交互互，请指明明数据库及及表名文件数量峰值数据量量频度填写数据处处理的频度度复杂度批处理 /人工填写接口数数据的驱动动模式是人人工（maanuall）还是自自动(auutomaatic)，还是都都支持接口类型填写是实时时接口还是是批量接口口等【其他系统统详细信息息】说明：列出出所有与接接口交互的的外围系统统的详细信信息。包括括输入、输输出系统等等系统填写与接口口交互的系系统名称系统类型填写是接口口的数据源源系统(ssourcce)还是是目标系统统(objject)数据库填写交互系系统使用的的数据库及及版本软件填写交互系系统的软件件名称架构类型交互系统的的架构类型型是B/SS 还是CC/S。位置填写该软件件在交互软软件体系中中所出的位位置技术支持填写交互系系统的开发发商和支持持商功能支持填写具体的的支持商或或技术团队队数据归属【接口隶属属系统的详详细信息可选 】系统填写接口隶隶属系统的的名称模块隶属于具体体的模块名名称数据库隶属系统的的数据库及及版本负责人控制报告【接口配置置】（1）接口口基础信息息配置说明：接口口基础信息息的配置项项目，描述述配置的方方式。（2）接口口运行参数数配置说明：接口口运行参数数的配置方方式和步骤骤。【其他配置置可选 】说明：外围围系统或相相关模块的的配置。3.2.11.4通信信接口【可选】说明：指定定各种通信信接口。例例如，局部部网络的协协议等等。3.2.22 其他非非功能性需需求说明：下表表中的各种种需求，可可根据实际际情况进行行选择其中中的一种或或者几种进进行描述，在在表的后面面是各种需需求的详细细解释。名称详细要求静态数值需需求动态数值需需求精度时间特性要要求可用性可靠性可维护性安全性可移植性可扩展性兼容性3.2.22.1 静静态数值需需求说明：支持持的终端数数；支持并并行操作的的用户数。3.2.22.2 动动态数值需需求说明：欲处处理的事务务和任务的的数量，以以及在正常常情况下和和峰值工作作条件下一一定时间周周期中处理理的数据总总量。3.2.22.3 精精度 说明:对该该软件的输输入、输出出数据精度度的要求，可可能包括传传输过程中中的精度。3.2.22.4时间间特性要求求 说明：对于于该软件的的时间特性性要求，如如对：a响响应时间；b更更新处理时时间；c数数据的转换换和传送时时间；d解题时时间等要求求。3.2.22.5 数数据管理要要求【可选】说明：需要要管理的文文卷和记录录的个数、表表和文卷的的大小规模模，要按可可预见的增增长对数据据及其分量量的存储要要求做出估估算。3.2.22.6 可可用性指出普通用用户和高级级用户要高高效地执行行特定操作作所需的培培训时间，指指出典型任任务的可评评测任务次次数或根据据用户已知知或喜欢的的其他系统统确定新系系统的可用用性需求性能3.2.22.7可靠靠性指出可用时时间百分比比 ( xxx.xxx%)、使使用小时数数、维护访