php怎么做直播网站吗,天津建设网站,wordpress图片防下载,网络设计报告3000字二、软件需求管理办法
第1章 总则
第1条 目的。 为使软件产品满足规定的需求而确定软件的体系结构、组成模块划分和接口说明等#xff0c;并将上述结果翻译成代码#xff0c;以实现软件所要求的功能#xff0c;确保软件项目的顺利实施和高质量交付#xff0c;特制定的软件…二、软件需求管理办法
第1章 总则
第1条 目的。 为使软件产品满足规定的需求而确定软件的体系结构、组成模块划分和接口说明等并将上述结果翻译成代码以实现软件所要求的功能确保软件项目的顺利实施和高质量交付特制定的软件需求规格说明SRS管理规定。 拟制该规定的目的是确保各方对需求的一致理解有效管理和控制需求的变更以及从需求理解到最终产品的双向跟踪从而保持产品和活动与软件需求的一致性。需求管理的任务则包括需求调研计划和组织双方对需求进行评审确保需求调研的成功和需求文档中描述的需求是用户需要的、最新的、可度量的、可跟踪的。
第2条 适用范围。 本规定适用于公司所有的软件产品的设计与研发工作。包括所有软件产品的产品研发类、产品开发类、合同开发类以及维护开发类的项目。本规定对软件开发的调查、设计、开发、测试、发布等各项工作中的软件需求的收集、分析、变更、决策进行了指导和规范。
第3条 责任部门。 软件研发团队所在部门负责软件需求管理的各项工作高层主管领导对需求管理活动就跟进及确认必要时行使决策权。
第4条 软件需求的定义。 1用户需求即用户解决问题或达到目标所需的条件和能力。 2系统需求即系统或系统部件要满足合同、标准、规范、政策、习俗或其他正式文档所必须具有的条件和能力。 3反映需求或能力的文档说明即对软件设计研发目的的描述。
第5条 需求管理活动说明。 软件需求管理活动包含计划、调研、编写、变更、验证等各项活动并遵循科学的管理原则以确保项目能够顺利实施和高质量交付。 1.需要根据项目特点确定客户人员、自己人员、需要的资料、设备、规范、进度等。 2.输出需求文档中应准确、完整地描述用户需求包括需求的优先级、一致性、完备性、现实性等内容。同时需求文档需要和用户反复确认和商讨以确保其准确性和完整性。 3.尽量减少需求变更频次需求变更需要经过双方协商并达成一致对变更的需求需要进行详细记录并对其影响进行评估。 4.验证需求确保需求规格说明准确、完整地表达了必要的质量特点。需要进行有效性、一致性、完备性、现实性等方面的审查。
第6条 参考文档
GB8566-2007计算机软件开发规范
GB/T 9385-2008 计算机软件需求规格说明规范
GB/Z 31102-2014 软件工程 软件工程知识体系指南
GB/T 32421-2015 软件工程 软件评审与审核
GB/T 36964-2018 软件工程 软件开发成本度量规范 GB/T 30999-2014 系统和软件工程 生存周期管理 过程描述指南
GB/T 30972-2014 系统与软件工程 软件工程环境服务
GB/T 32424-2015 系统与软件工程 用户文档的设计者和开发者要求
GB/T 16680-2015 系统与软件工程 用户文档的管理者要求
GB/T 25000-2016 系统与软件工程 系统与软件质量要求和评价SquaRE
GB/T 38557-2020 系统与软件工程 接口和数据交换
GB/T 22032-2021 系统与软件工程 系统生存周期过程
GB/T 41866-2022 系统与软件工程 信息技术项目绩效基准度度量框架 GB/T 41865-2022 软件与系统工程 产品线工程与管理参考模型
GB/T 29831-2013 系统与软件功能性
GB/T 29832-2013 系统与软件可靠性
GB/T 29833-2013 系统与软件可移植性
GB/T 29834-2013 系统与软件维护性
GB/T 29835-2013 系统与软件效率
GB/T 29836-2013 系统与软件易用性 GB/T 8566-2007《信息技术 软件生存周期过程》。
GB/T 18491-2010 信息技术 软件测量 功能规模测量
GB/T 30882-2014 信息技术 应用软件系统技术要求
GB/T 38888-2020 数据采集软件的性能及校准方法 第2章 软件需求管理的目标与原则
第7条 需求管理的原则。 1需求需分类管理。 对软件需求进行分类管理一般分为三个层次即基本需求、功能需求和性能需求。不同层次的需求侧重点、描述方式和管理方式也不同需要根据具体情况进行划分和归类。 2需求需分优先级。 在项目开发过程中需要根据需求的紧急程度、重要程度、复杂程度等因素对需求进行优先级排序以确保开发人员能够按照优先级顺序进行开发和实现。 3需求必须文档化。 所有的软件需求都必须进行文档记录该文档必须是正确的、最新的、可管理的、可理解的是经过验证的是在受控的状态下变更的。 4需求一旦变化就必须对需求变更的影响进行评估。 在项目开发过程中需求难免会发生变更因此需要对变更的需求进行评估和审核并按照正式的变更流程进行操作以确保变更的合理性和准确性 5需求管理必须与需求工程的其他活动紧密结合。 需求管理必须与需求工程的其他活动紧密整合包括需求获取、需求分析、需求描述、需求验证等以确保需求在整个项目开发过程中的正确性和一致性。
第8条 需求管理的目标。 1.确保所有相关人员对需求的理解和定义是一致的避免在开发过程中出现理解和实现上的偏差。同时需求管理也需要确保需求的描述和定义是精确的避免出现歧义和误解。 2.需要确定需求变更的管理流程包括变更的申请、审核、批准、实施等环节以确保变更的合理性和准确性。 3.需要建立从需求到最终产品的双向跟踪机制确保产品或系统的功能、性能、质量等方面都能够满足用户的需求和期望。 4.通过需求管理可以更好地了解用户需求和期望为软件开发和测试提供明确的方向和指导减少开发和测试的风险和错误从而提高软件产品的质量和可靠性。 5.避免在开发过程中出现的需求偏差和变更等问题从而降低项目成本和风险。 6.通过需求管理使软件需求受控并建立供软件工程和管理使用的需求基线。使软件计划、产品、活动与软件需求保持一致。
第9条 软件需求的度量要素。 软件需求的度量应包括9个要素即正确性、无歧义、完备性、一致性、分级、可验证、可修改、可追踪、可行性、必要性、可理解。 1正确性需求是否准确描述了软件系统的功能和性能没有错误或模糊不清的地方每一项需求都是软件应满足的需求。 2无歧义需求文档是否清晰明了没有歧义和含糊不清的地方每一项需求只有一种解析。 3完备性需求是否全面和准确没有遗漏或缺失。所有重要需求不论是否与功能、性能、设计约束、软件属性或外部接口有关都应该确认和处理。确保软件对所有可实现的有效、无效输入数据给出响应。 4一致性在不同平台、不同设备、不同环境下软件的功能、界面、行为、性能方面都应该保持内部一致对外与用户目标要求一致。 5划分优先级根据需求的重要性、紧急程度或稳定性对需求进行合理的优先级划分给出每项需求的重要性标识。 6可验证性每项需求是否可以验证是否具备可测试性和可验证性。 7可修改相同需求没有冗余,不在文档多处出现。文档能分别地表述每个需求并不与其他需求混淆。具备连贯、方便使用的结构对任何需求可进行容易、全面、一致的修改支持。 8可追踪每项需求来源是清楚的并有完整的出处记录随着设计、代码文档的修改可以确定地发现影响全部需求集合。 9可行性需求是否具备可实现性不会给软件开发带来无法解决的问题或困难。 8必要性每一项需求是否有必要是否对软件系统的功能和性能有直接的贡献。 10可理解需求文档或其他相关资料的需求描述能够使开发者明确需求并顺利实现以及需求变更时能及时应对。 第3章 需求变更管理
第10条 需求变更的原因。 1.在软件研发早期所有的问题不可能被完全定义软件需求是不完全的这就注定了需求需要变更以便达到完善的程度。 2.随着软件的研发进度软件研发人员对问题的理解发生变化或项目团队之间沟通不畅也可能导致需求变化这些变化需及时反馈到需求变更管理中。 3.可能是由于市场趋势、市场竞争、客户需求或其他因素导致的变更。 4.现有的技术可能无法实现预期的功能或者实现成本过高从而导致需求变更。 5.团队成员的更替和变动也可能导致需求变更。 6.包括资金、设备、材料等资源限制可能影响原有需求的实现需要对需求进行修改。 7.受到法规标准、安全问题、环保要求等外部因素影响满足这些外部要求可能需要对需求进行变更。 8.项目管理不当、进度延误、质量问题等可能导致需求变更以改善项目管理和质量。
第11条 变更管理过程。 1.变更流程规范在项目初期与用户或受托方共同确定并需制定双方认可的需求变更流程按照“变更申请、审批、实施、重新确认”的流程处理需求的变更。 2.变更描述用户或受托方在原有需求的基础上提出需求变更申请并形成需求描述文案。 3.变更分析在需求文档的基础上开发组和用户共同对变更需求进行评审对需求文档进行修改呈报决策主管审批确保需求文档具有书面承诺确认。 4.变更跟踪比较需求文档与后续工作成果之间的对应关系建立和维护“需求跟踪矩阵”包括需求文档、设计文档、测试文档等同步更新以确保产品开发依据需求文档进行。 5.变更实现将需求变更及设计、测试等同步变更内容落实到各开发环节周知相关人员防止需求变更失去控制而导致项目混乱。 6.变更确认项目负责人组织组员跟进及确认变更需求落实情况定期向用户及主管领导进行变更需求进度汇报或变更需求结题。
第12条 变更影响分析。 每一项需求变更都必须进行变更影响分析明确它对研发各阶段和其他需求的影响明确与变更相关的任务并评估完成这些任务需要的工作量 1当发现需求存在偏差时需要进行需求变更需要列出影响范围及名目清单包括但不限于进度、费用、业务架构、技术架构、数据库设计、UI交互、接口服务等。如果变更频繁可能对项目造成较大影响严重时可能直接导致项目的失败。 2在一个复杂的软件系统中需求之间具有一定的联系相关需求可构成需求链。需求变更可能会引起连锁反应导致需求链的某些环节脱节就可能引起一些难以察觉的错误。当需求变更需要及时准确的将关联需求进行联动分析直到可明确切分需求链为止及时修改项目的设计、开发、测试文档防止影响系统质量甚至是系统崩溃。 第4章 软件需求文档管理
第13条 需求文档的作用。 在用户和研发人员之间就将要开发的软件系统需要达成一致的协议清楚描述软件的功能和性能以及系统的运行环境等从而产生正式的需求文档以便为软件的设计、编码、测试、维护等实现提供依据。 需求文档至少应包括功能、外部接口、性能、软件属性、设计约束、系统环境等内容描述。
第14条 编写软件需求文档的注意事项。 1要明确软件需求文档的编写目的具备清晰的结构包括对软件功能、性能、界面等方面的描述。文档需要包含足够的细节信息以便开发人员能够准确地理解软件开发的具体要求。 2采用书面语方式撰写尽量使用图表结合的方式来表达。使用简明扼要的语言来表达避免使用过于专业的术语或者冗长的句子以便读者能够快速地理解文档内容 3具备规范的格式例如字体、排版、颜色等方面都应该保持一致语句和段落应尽量简短表达方式要采用主动语态语句要完整且语法、标点等正确无误。 4使用的术语要与词汇中的定义保持一致避免使用模糊、主观的术语。 5避免使用比较性的词汇尽量给出定量的说明含糊的语句表达将引起需求的不可验证。
第15条 建立软件需求规格说明书。 需求文档采用软件需求规格说明书的形式精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件是对外部行为和系统环境接口间接、完整的描述性文档。见《软件需求文档编写规范》。 第5章 需求验证管理
第16条 需求验证流程。 1审查需求。 1对提出的变更请求进行评估包括变更的性质、范围和影响等。 2对变更请求进行审核确保变更请求的必要性、合理性和可行性。 2需求实施。 1根据审核结果对变更请求进行实施包括修改需求文档、更新系统设计、依据需求编写测试用例等。 2对已实施的变更进行验证确保变更的有效性、正确性和完整性。 3需求结果确认。 1对变更请求进行跟踪和监控确保变更请求得到及时处理和反馈并符合需求。 2对需求变更落实到各关联环节输出新的用户产品手册。
第17条 需求验证的内容。 1有效性检查。确保将用户的需求充分、正确地表达出来。每一项需求都必须准确地陈述用户要开发的功能并让用户代表确定用户需求表达的正确、有效。 2一致性检查确保每项需求与其他软件需求或高层需求不互相冲突。在开发前必须解决所有需求间的不一致部分。验证所获取的需求没有冲突和二义性 3完备性检查验证是否所有可能的状态、状态变化、产品和约束都在需求中描述不能遗漏任何需求信息。 4现实性检查。需求的变更历史必须是可以跟踪的需求变更的原因及其可能的影响来自具体业务驱动或用户依据。 5可检验性检查每个需求都可以通过具体的测试案例或可观测的结果来验证其是否被满足。 6可调节性检查需求可以进行修改、添加或删除等操作并能够记录和跟踪这些变更。 7可读性检查需求必须清晰明确没有歧义或含糊不清的表述以便所有的相关人员都能理解并达成共识。
第6章 需求评审
第18条 需求评审人员。 需求评审人员由软件专业人员、领域专家与客户方的代表共同组成。需求评审人员的要求通常包括以下几点 1.背景和能力评审人员应具备相关的专业知识和技能能够全面评估需求的质量、可行性和完整性。 2.独立性和中立性评审人员需要独立于项目开发过程避免利益和压力的影响以确保评估的公正性和客观性。 3.沟通和协调能力评审人员需要具备优秀的沟通和协调能力与项目团队成员保持良好的沟通和合作关系确保需求评审的顺利进行。 4.记录和分析能力评审人员需要将评审过程中发现的问题、建议和结论记录下来并进行分析和整理为项目团队提供有价值的反馈和建议。 5.责任心和诚信度评审人员需要具备高度的责任心和诚信度认真对待每一次评审以保障项目的质量和进度。
第19条 需求评审注意事项。 1.严格控制每一次评审的文档规模及持续时间。有专人负责组织和主持会议控制会议的节奏确保评审过程顺利进行。 2.提前发送要评审的文档给评审人员以便他们提前了解需求并发现问题。 3评审工作要可分段进行需要明确每个阶段的议题及进度要求。 4对讨论的问题进行控制避免过度发散引入无关议题。 5避免无谓的争吵。鼓励参与者积极发表意见和建议对于发现的需求错误、遗漏和冲突要充分讨论和解决。 第7章 附则补充
第20条 需求拟定需要开发人员与用户达成一致为原则。 用户准确地描述其希望得到什么供方正确地理解用户想要什么。
第21条 需求是软件开发各阶段的驱动入口。 为用户和供方之间建立协议基础为估计成本和进度提供基础为验证和确认内容提供基线减少以后重新设计、重新编码、重新测试的工作量编译进一步增加或迁移支撑。
