需求管理规范V
需求管理规范
需求管理规范一、引言需求管理是软件开辟过程中至关重要的一环。
良好的需求管理可以确保软件开辟项目的顺利进行，减少项目风险，提高开辟效率和质量。
本文旨在规范需求管理的流程和方法，以确保需求的准确性、完整性和一致性。
二、需求管理流程1. 需求采集需求采集是需求管理的起点，通过与项目相关的各方沟通和交流，采集和整理项目需求。
可以采用面对面会议、问卷调查、访谈等方式进行需求采集，确保获取到准确、全面的需求信息。
2. 需求分析需求分析是对采集到的需求进行细致的分析和梳理的过程。
通过对需求的分类、排序和优先级划分，明确需求的重要性和紧急程度。
同时，需求分析还包括对需求的可行性评估和风险分析，以确保项目可行性和风险可控。
3. 需求确认需求确认是与项目相关方共同确认需求的过程。
在需求确认阶段，需求管理团队与项目相关方进行深入的讨论和沟通，确保需求的准确性和一致性。
通过会议记要和需求文档的编写，将需求明确记录下来，为后续的开辟工作提供基础。
4. 需求变更管理需求变更是不可避免的，在项目开辟过程中，可能会浮现需求的变更和调整。
需求变更管理是对需求变更进行评估、审批和控制的过程。
通过建立变更管理流程和机制，确保需求变更的合理性和可控性，避免对项目进度和质量造成不良影响。
5. 需求跟踪和验证需求跟踪和验证是确保需求实现的过程。
通过建立需求跟踪矩阵和需求验证计划，对需求的实现情况进行监控和验证。
及时发现和解决需求实现过程中的问题和风险，确保需求的准确性和一致性。
三、需求管理方法1. 需求文档化将采集到的需求进行文档化，包括需求描述、需求优先级、需求关联性等信息。
需求文档应具备清晰、简洁、易读的特点，并且要与项目相关方进行共享和确认。
2. 需求跟踪工具借助需求跟踪工具，对需求的变更、实现和验证进行跟踪和管理。
需求跟踪工具可以匡助需求管理团队及时掌握需求的状态和发展，提高需求管理的效率和准确性。
3. 需求评审在需求确认阶段，组织需求评审会议，邀请项目相关方参预需求的评审和讨论。
需求管理规范
需求管理规范1. 引言需求管理是项目管理中至关重要的一环。
良好的需求管理可以确保项目团队和利益相关者在整个项目生命周期中达成共识，并最大限度地满足项目目标和用户需求。
本文档旨在制定需求管理的规范，以提高项目的成功率和交付质量。
2. 需求管理的目标需求管理的主要目标包括但不限于以下几个方面：- 确定和理解项目利益相关者的需求和期望。
- 明确项目目标和范围，以便明确项目的可交付成果。
- 收集、分析和确认需求，确保其准确性、一致性和完整性。
- 跟踪和控制需求的变更，以确保变更的合理性和影响的可控性。
- 与利益相关者保持沟通和协商，以确保需求的共识和满足。
3. 需求管理的过程需求管理包括以下基本过程：3.1 需求识别和定义在该阶段，项目团队与利益相关者合作，识别和定义项目的需求。
此过程涉及以下活动：- 收集利益相关者的需求和期望。
- 确认项目的目标和范围。
- 识别并记录需求并将其细化为具体的需求。
3.2 需求分析和确认在该阶段，项目团队对已识别的需求进行分析和确认，以确保需求的准确性和一致性。
此过程包括以下活动：- 分解和澄清需求，将其划分为可执行的任务。
- 确定需求之间的相互关系和依赖。
- 与利益相关者沟通和协商，以确认需求。
3.3 需求变更管理需求变更是项目过程中常见的情况，因此需要制定有效的变更管理策略。
此过程包括以下活动：- 评估变更对项目目标、范围和进度的影响。
- 根据变更的重要性和优先级进行批准或拒绝。
- 更新需求文档和相关项目文档。
3.4 需求跟踪和控制需求跟踪和控制是保证需求满足的关键，以确保项目成功交付。
此过程包括以下活动：- 跟踪需求实施的进展情况。
- 检查需求的实施质量和结果。
- 控制变更并确保变更的合理性和影响的可控性。
3.5 需求验证和确认交付在项目完成阶段，项目团队应验证和确认实施的需求，并与利益相关者进行最终的需求确认。
此过程包括以下活动：- 验证需求是否满足项目目标和利益相关者的期望。
需求管理规范
需求管理规范引言概述：需求管理是软件开发过程中至关重要的一环，它涉及到需求的收集、分析、确认、变更控制和跟踪等多个方面。
合理的需求管理规范能够确保项目的顺利进行，减少沟通误差和项目变更带来的风险。
本文将从需求收集、需求分析、需求确认、需求变更控制和需求跟踪五个大点进行详细阐述。
正文内容：1. 需求收集1.1 确定需求收集的来源：需求可以来自多个渠道，如客户、用户、市场调研等。
在需求收集过程中，需要明确需求的来源，以便后续的分析和确认工作。
1.2 使用合适的需求收集技术：需求收集技术有很多种，如面谈、问卷调查、用户故事等。
在选择需求收集技术时，需要考虑到项目的特点和需求的复杂程度，选择合适的技术进行需求收集。
2. 需求分析2.1 确定需求的优先级：在需求分析过程中，需要对需求进行优先级排序，以便后续的开发和测试工作。
优先级的确定可以根据需求的重要性、紧急程度和可实现性等因素进行评估。
2.2 分解需求为更小的可执行任务：将大的需求分解为更小的可执行任务，有助于团队更好地理解和实现需求。
分解需求可以采用工作分解结构（WBS）等技术。
2.3 确定需求的可测量性：需求分析过程中，需要确保需求是可测量的，即能够通过测试来验证需求的实现情况。
可测量性的确定可以通过需求的明确性、可验证性和可追踪性等指标来评估。
3. 需求确认3.1 确保需求的准确性和完整性：需求确认是验证需求的准确性和完整性的过程。
在需求确认过程中，需要与客户和用户进行充分的沟通和确认，确保需求的理解一致。
3.2 确定需求的可行性：需求确认过程中，需要评估需求的可行性，包括技术可行性、资源可行性和经济可行性等方面。
只有在需求可行的前提下，才能进行后续的开发和实施工作。
3.3 编写需求确认文档：需求确认过程中，需要编写需求确认文档，明确需求的内容、目标和约束等信息。
需求确认文档是需求管理的重要依据，也是后续变更控制和跟踪的基础。
4. 需求变更控制4.1 确定需求变更的流程和责任人：需求变更是不可避免的，但需要有一个明确的变更控制流程来管理需求的变更。
需求管理规范
需求管理规范需求管理是软件开发过程中的一个重要环节，它涉及到对用户需求进行收集、分析、描述、确认、优化、变更控制等一系列工作。
规范的需求管理可以确保开发团队理解用户需求，并能够将其有效地转化为可执行的软件开发任务，从而提高开发效率、降低开发成本、提升软件质量。
以下是一份关于需求管理的规范，希望能够对软件开发团队进行指导和规范。
1. 需求收集阶段需求收集是需求管理的第一步，团队应该与用户进行充分的沟通，了解用户的需求以及期望。
在需求收集过程中，应当明确需求的背景、目标、范围、非功能性需求等内容，并将其记录下来。
团队应当选择适当的需求收集技术，比如面谈、问卷调查、访谈等，以获取更全面、准确的需求信息。
2. 需求分析阶段需求分析是将收集到的需求进行整理、梳理和分析的过程。
在需求分析过程中，团队应当对需求进行逐一评估，判断其可行性和优先级，并将其转化为具体的开发任务。
此外，团队还应当对需求进行深入剖析，确保需求的可行性、一致性、完整性和明确性。
需求分析的结果应当以文档的形式呈现，方便后续的需求确认和开发实施。
3. 需求描述阶段需求描述是将分析结果转化为易于理解和执行的需求文档的过程。
需求文档应当包括对功能需求的描述、非功能性需求的描述、界面设计的描述等内容，同时还应当明确需求的优先级和其他相关属性。
需求文档应当使用简明扼要的语言，避免使用模棱两可的词语，以确保需求的明确性和一致性。
4. 需求确认阶段需求确认是确保开发团队和用户对需求的一致性和准确性的过程。
团队应当与用户进行再次沟通，让用户对需求文档进行审核和确认。
对于用户提出的修改意见和补充需求，团队应当及时进行整理和分析，并与用户协商达成一致。
在需求确认过程中，团队应当保持沟通畅通，确保需求的准确实施。
5. 需求优化阶段需求优化是对已经确认的需求进行进一步的梳理和完善的过程。
团队应当在需求优化阶段对已确认的需求进行评审，发现其中的不合理和冗余之处，并与用户进行再次确认和协商。
业务需求管理规范v1.0(201209)
公司业务需求管理规范v1版本说明：v1.01.总则1.1.概述为了加强公司业务需求全流程管理，提升项目管理水平，规范业务新增、变更、下线流程，特修订本管理办法。
本办法由省公司市场经营部牵头负责管理，当流程发生重大变更时应根据需要及时进行修订并通知相关人员。
本管理办法规定的公司业务需求管理规范，从2012年09月1日起试行。
本管理办法中所定义的单位或部门说明如下：1、技术部门：业务支撑系统部、网管中心。
2、业务部门：市场经营部、数据部、中心、集团客户部、省级集团客户服务中心、客户服务部、省客户服务中心、终端运营中心。
3、地市公司为公司九地市分公司。
1.2.适用范围本管理办法适用于公司业务支撑系统（包括BOSS系统、经分系统、客服系统、网上营业厅系统等电子渠道支撑系统、业务支撑系统部维护开发管理的增值系统），以及部分涉及业务功能承载的网管系统。
1.3.主要内容本办法主要包括需求规范、开发规范、测试/上线规范、推广应用规范四个部分，各部分内容如下：1.需求规范。
主要对需求定义、需求部门、需求角色、需求分类、需求管控原则、需求模板等内容进行规范。
2.开发规范。
主要对接口管理机制、支撑响应机制、过程沟通机制、RDMP 管理机制四个方面进行规范。
3.测试/上线规范。
主要对测试管理、上线管理和信息采编进行规范。
4.推广应用规范。
主要对应用评估分析、问题反馈机制进行规范。
2.需求规范2.1.需求定义需求主要是指省公司业务部门、业务支撑系统部内部以及地市公司所提出的涉及业务新增、变更和优化（系统BUG）的开发需求，业务部门提交的所有需求须严格按照所制定的业务需求模板提交。
2.2.需求特征定义将需求特征可以细分为三个类型：新增、变更/优化、系统BUG。
1、新增：新开发业务或功能，如省内携号业务的开发。
2、变更/优化：对原有业务规定、系统功能等进行调整、优化等；3、系统BUG：开发遗漏或错误导致的业务功能优化需求。
2.3.需求等级定义按照需求的重要程度分为重要和普通。
需求管理规范
需求管理规范引言概述：需求管理是软件开发过程中至关重要的一环，它涉及到需求的收集、分析、确认、变更与跟踪等多个方面。
一个良好的需求管理规范可以确保项目的顺利进行，减少开发过程中的风险和错误。
本文将从需求管理规范的五个大点进行阐述，包括需求收集、需求分析、需求确认、需求变更和需求跟踪。
正文内容：1. 需求收集：1.1 确定需求收集的渠道和方式：可以通过与客户的沟通、用户调研、市场分析等方式进行需求收集。
1.2 制定需求收集的计划和时间表：确定需求收集的时间节点和计划，确保需求的全面性和准确性。
1.3 进行需求的分类和整理：将收集到的需求进行分类和整理，方便后续的需求分析和确认工作。
2. 需求分析：2.1 确定需求的优先级和重要性：根据项目的目标和约束条件，确定需求的优先级和重要性，以便在开发过程中进行合理的资源分配。
2.2 进行需求的详细分解：将需求进行细化，明确每个需求的具体内容和功能，以便开发团队能够清晰地理解和实现。
2.3 进行需求的可行性评估：评估需求的可行性，包括技术可行性、资源可行性和经济可行性等，以便确定能否在项目中实现。
3. 需求确认：3.1 与客户进行需求的确认：与客户进行沟通和讨论，确保对需求的理解一致，并获得客户的确认和认可。
3.2 编写需求确认文档：将确认的需求编写成文档，包括需求的描述、功能点和约束条件等，以便开发团队参考和实施。
3.3 进行需求的验收测试：对已确认的需求进行验收测试，确保需求的实现符合客户的期望和要求。
4. 需求变更：4.1 建立需求变更的流程和机制：建立明确的需求变更流程和机制，包括需求变更的提出、评估、审批和实施等环节。
4.2 进行需求变更的影响分析：对提出的需求变更进行影响分析，包括对项目进度、成本和质量等方面的评估，以便做出合理的决策。
4.3 进行需求变更的控制和跟踪：对已经变更的需求进行控制和跟踪，确保变更的实施符合规范，并及时进行相应的调整和反馈。
需求管理规范
需求管理规范引言概述：需求管理是软件开发过程中至关重要的一环，它涉及到对需求的收集、分析、确认和变更控制等多个方面。
一个良好的需求管理规范可以确保项目的顺利进行，减少开发过程中的风险和错误。
本文将详细介绍需求管理规范的五个部分。
一、需求收集1.1 确定需求收集的渠道：明确需求收集的渠道，可以通过面对面的访谈、问卷调查、用户反馈等方式获取需求信息。
1.2 设计需求收集模板：建立统一的需求收集模板，包括需求描述、优先级、验收标准等内容，以便更好地记录和分析需求。
1.3 建立需求库：将收集到的需求进行分类、整理和存储，建立需求库，方便后续的需求分析和确认。
二、需求分析2.1 确定需求的可行性：对收集到的需求进行评估，包括技术可行性、资源可行性和商业可行性等方面，确保需求能够在项目中实现。
2.2 拆解需求：将大需求拆分成小需求，明确每个小需求的功能和目标，以便更好地进行后续的开发和测试工作。
2.3 确定需求的优先级：根据项目的紧急程度和价值，确定需求的优先级，以便在开发过程中合理安排资源和时间。
三、需求确认3.1 与用户进行确认：将分析后的需求与用户进行确认，确保需求的准确性和完整性，避免后期出现需求变更和冲突。
3.2 编写需求规格说明书：将确认后的需求编写成规格说明书，包括需求描述、功能点、验收标准等内容，以便开发人员参考和理解。
3.3 进行需求评审：组织开发团队和相关利益相关者进行需求评审，确保需求的一致性和可行性，避免后期出现开发偏差和错误。
四、需求变更控制4.1 建立变更控制流程：制定明确的需求变更控制流程，包括需求变更的提出、评估、批准和实施等环节，以便及时响应和处理需求变更。
4.2 评估需求变更的影响：对提出的需求变更进行评估，包括对项目进度、成本和质量等方面的影响，以便决策是否批准变更。
4.3 控制需求变更的范围：在变更控制流程中明确需求变更的范围，避免变更过多导致项目无法控制和实施。
五、需求跟踪和管理5.1 建立需求跟踪矩阵：建立需求跟踪矩阵，将需求与设计、开发、测试等阶段进行关联，以便跟踪需求的实现和进展情况。
需求管理规范
需求管理规范引言：需求管理是软件开发过程中非常重要的一环，它涉及到对用户需求的收集、分析、确认和变更控制等方面。
一个良好的需求管理规范能够确保项目的顺利进行，减少需求变更和项目失败的风险。
本文将详细介绍需求管理规范的五个方面。
一、需求收集1.1 用户需求收集：通过与客户的沟通和交流，了解客户的业务需求和期望，包括功能需求、非功能需求和约束条件等。
1.2 利益相关者需求收集：与项目的利益相关者进行沟通，了解他们对项目的期望和需求，包括项目经理、开发人员、测试人员等。
1.3 需求文档收集：收集和整理已有的需求文档，包括用户手册、业务流程图、需求规格说明书等。
二、需求分析2.1 功能分析：对收集到的需求进行细化和分解，将大的需求拆解成小的功能点，明确每个功能点的输入、输出和处理逻辑。
2.2 非功能分析：对非功能需求进行分析，包括性能要求、安全要求、可靠性要求等，明确每个非功能需求的具体指标和测试方法。
2.3 需求优先级分析：根据项目的目标和约束条件，确定每个需求的优先级，以便在开发过程中进行合理的资源分配和时间安排。
三、需求确认3.1 需求验证：与客户和利益相关者进行需求确认，确保需求的准确性和完整性，避免后期的需求变更和项目风险。
3.2 需求追踪：建立需求追踪矩阵，跟踪每个需求的状态和变更情况，确保需求的跟踪和控制。
3.3 需求文档编写：将确认的需求编写成需求规格说明书，包括需求的详细描述、输入输出和验收标准等，作为后续开发和测试的依据。
四、需求变更控制4.1 变更申请：对需求变更进行管理，客户或利益相关者提出变更申请，包括新增需求、修改需求和删除需求等。
4.2 变更评估：评估变更对项目进度、成本和质量的影响，确定是否接受变更，并进行相应的调整和协商。
4.3 变更控制：建立变更控制流程，对变更进行跟踪和控制，确保变更的合理性和可行性，避免对项目造成不必要的风险和影响。
五、需求交付和验收5.1 需求交付：将需求规格说明书交付给开发团队，确保开发人员理解和遵循需求，按时按量完成开发工作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
密级：内部公开
文档编号：SL_RD_XQGLGF
需求管理规范
------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的
为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前
期获得有效的输入，特制订本规范。
2．范围
本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。
3．术语
4.部门/角色与职责
5.内容
5.1流程图
图1需求开发与管理过程活动示意图
5.2主要活动
需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。
（需求的收集和整理）
产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。
（这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。
用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。
比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。
）
产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。
除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。
其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。
根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。
完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。
产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。
（需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。
）
需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。
UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。
在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。
需求确认包含两个重要工作：“需求评审”和“需求承诺”。
需求的评审
应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。
需求评审
的方式分为“技术评审会议”与“组内评审”两种。
产品经理根据需求分析的进展情况，采用“组内评审”的方式分阶段对需求分析的阶段成果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
当需要召开技术评审会议时，由产品经理向相关部门提出需求技术评审申请，由相关部门组织按“技术评审会议”的方式实施需求评审。
（评审过程本身也是一个知识传递过程，评审人员与产品经理一起讨
论用户需求，这有助于评审人员获得用户需求的前期认识。
1.评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理
进行二次需求分析和定义。
2.评审过程中可能发现某些特殊需求，这时产品经理和评审人员可
以群策群力共同思考解决问题的方式。
3.当局者迷、旁观者清。
再有经验的产品经理也可能犯错，评审人
员可以提出更合理或者更有建设性的想法供产品经理参考。
）需求承诺
产品经理将评审通过的《产品需求说明书》或《原型》提交给客户（或客户代表）进行确认，确认的方式可以是以下方式之一：
直接签字：由承诺方在《产品需求确认书》或《原型》上直接签字或盖
章确认。
邮件方式：由项目经理将《产品需求确认书》或《原型》与《评审报告》通过邮件发送给接收方，并明确确认通过的准则（如：如果在一周内未
予以回复则默认为确认通过）；
发送会议纪要函：如果承诺方参加了评审会议并在会上达成了共识，则
可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等，并通
过纪要函的方式发送给承诺方。
5.2.5需求的实现
根据需求的评审结果，项目经理输出需求实现的计划表，明确各阶段的时间节点和人员安排。
在开发设计阶段，需输出设计文档，并评审；测试部门应按时间节点输出测试用例，并评审。
开发工程师完成编码、单元测试、联调测试，在自测完成的情况下向测试部门输出安装包、releasenotes和测试说明文档申请集成测试。
5.2.6需求的测试
测试部门按照测试流程，进行需求的测试和验证。
同时根据《缺陷处理规程》来处理测试过程是发现的bug，直至灰度测试完成。
5.2.7需求跟踪
跟进需求的设计实现过程，保证需求的实现不打折扣，并随时关注需求的变化。
通过比较需求定义与后续工作成果之间的对应关系，建立与维护需求跟踪列表，确保产品依据需求的定义进行开发。
产品经理每天都需要跟进当前迭代中需求的实现进度，确保需求执行的过程没有出差错，一般而言，需求的跟踪分为两种：
正向跟踪：检查已安排的每个需求是否都能在后续的实现过程中有相对应的部分，确保没有漏做的需求，并保证需求的实现程度和需求定义要求的一样。
这就需要每天都与后续的各个负责实现的人员进行确认。
逆向跟踪：根据已有的原型、UI、系统设计文档、测试用例文档等成果文档，反向检查是否包含了所有已安排的需求。
5.2.8需求变更
对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免的。
这主要有以下几种原因：
1.软件所应用的外部环境发生变化；
2.随着用户对软件的熟悉和应用，又提出新的需求；
3.项目组进行需求分析时未能彻底分析用户的需求，或分析错误；
4.用户在开始时不能很全面的知道所需软件的功能。
需求变更评审及实施
1.对于小修小改的需求，产品经理着急相关人员座位过审，
相关人员知悉并同意后，更新Tapd上产品需求更改日志，并在需求详细阐述中，红色标示出修改点，以便下流部门
知悉
2.对于大改的需求，召集评审会，待下流部门过审后，项目
重新排期，再进入开发阶段，一样需要同步更新需求文档
和TAPD上需求日志
6.相关附件、表单。