二、软件需求管理办法
第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条 需求是软件开发各阶段的驱动入口。
为用户和供方之间建立协议基础，为估计成本和进度提供基础，为验证和确认内容提供基线，减少以后重新设计、重新编码、重新测试的工作量，编译进一步增加或迁移支撑。
