系统与软件工程 生存周期过程 需求工程 征求意见稿

1系统与软件工程生存周期过程需求工程——规定了在工程活动中实施的所需过程，从而在整个生存周期内产生对系统/软件产品（包括——提供了所需和相关信息项的格式指南。——在涉及人工系统、软件密集型系统、软件和硬件产品以及与这些系统和产品相关的服务的项——执行需求工程活动的人员，以确保其对需求工程过程的应用符合GB/T2203——在涉及人工系统、软件密集型系统、软件和硬件产品以及与这些系统和产品相关服务的项目——执行需求工程活动的人员，以确保其在需求工程应用过程中开发的信息下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修GB/T8566-2022系统与软件工程软件生存周期过程（ISO/IEC/IEGB/T22032-2021系统与软件工程系统生存周期过程（ISO/IEC/2注：GB/T19000区分了两种类型的属性：固有存在于某物中的永久性特征；以及产品、过程或系统的指定特征经正式核准的技术状态项的版本，与介质无关，是在技术状态项的生存周期中的特定时间节点确业务需求规格说明businessre业务或使命需求(3.1.19)（业务或使命问题或机会的定义、各种概念以及各种解决方案的要求条对于某一个组织的一项或一系列行动的设想或意图，注1：运营理念经常体现在长期战略计划和年度业务计划中。），3注2：一个派生需求通常是在利益相关方(3.1.28在系统/软件生存周期过程中，执行开发活动（包括需求分析、设计、测试直到验收）的个人或组），对于一个组织的，关于一个系统或一组相关系统的运行或一系列运行的，设想或意注：运行概念使用一个或多个特定系统或与一组相关的系统，从用户（3.1.35）和操作方（3.1.18）角度，给出对想象中的事件或活动序列的描述，包括产品或服务与其环境和用户（3.1.35）的交互，以及在4在需方（3.1.1）和供方（3.1.3在系统、产品或服务的整个生存周期中识别、记录、维护、沟通、追溯和跟踪需求（3.1.19）的需求可追溯性requirements需求跟踪矩阵requirementstracea）（5注：这意味着已对一个或一组需求进行了评审，以帮助确保实现良好需求的特征，并对需求集进行了良好的组织。软件需求规格说明softwarereq软件及其外部接口的基本需求（3.1.19）[功能、性能、设计约束（3.1.7）和属性（3.1.2）]的注：利益相关方包括但不限于最终用户（3.1.35）、最终用户组织、支持者、开发者（3.1.11）、生产者、培训师、维护者、处置者、需方（3.1.1）、客户（3.1.9）、操作方（3.1.18）、供应商组织、认证者和监管机利益相关方需求规格说明stakeholderrequirementsspeci利益相关方（3.1.28）和与外部环境关系的需求（3.1.19）[特征、背景、概念、约束（3.1.7）系统及其运行环境和外部接口的结构化需求（3.1.19）集合[功能、性能、设计约束（3.1.7）和6在系统使用期间与系统交互或从系统中获益的个人或团通过提供客观证据对特定的预期用途或应用要求（3.1.19）已得到注：系统生存周期周境中的确认是一组活动，确保并获得系统能够实现其预期用途、目标和目的的信心。建立了注：系统生存周期周境中的验证是一组活动，将系统生存周期中的产品与该产品所需的特性进行比较。这可能包BABOK：业务分析知识手册（BusinessAnalysisBookofKnowledge）BRS：业务需求规格说明（BusinessRequirementsSpecificatiConOps：运营理念（ConceptofOperaFSM：功能规模测量（FunctionalSizeMeasureHIS：人系统集成（HumanSystemsIntegratiMDD：模型驱动开发（ModelDrivenDevelopment）MOP：性能测度（MeasuresofPerformancOpsCon：运行概念（OperationalCoRTM：需求追踪矩阵（RequirementsTraceabilityMSRS：软件需求规格说明（SoftwareRequirementsSpecifStRS：利益相关方需求规格说明（StakeholderRequSyRS：系统需求规格说明（SystemRequirementsSpecificTBD：待确定（ToBeDetermiTBR：待规定（TobeTobeSpecTPM：技术性能测度（TechnicalPerformanceM4符合性74.1预期用途本文件为处理需求工程执行GB/T22032-2021和GB/T8566-2022的过程提供了指南。本文件还对实施这些过程产生的信息项或文件的内容和格式提出了规范性定义和建议。本文件的用户可以声称符合4.2完全符合4.3过程的符合性4.4信息项内容的符合性本文件提供了系统、产品或服务生存周期内产生的多个需求工程信息项的要求。符合本文件信息——生成本文件中规定的所需信息项；——证明需求工程活动期间产生的信息项符合本文件中定义的内容要求。本文件中信息项的要求包含在第7章中。本文件中信息项的内容要求见第9注1：如果本文件的用户声称完全符合ISO/IEC/IEEE1528注2：在本文件中，为了便于参考，每个信息项4.5符合性4.5.1过程本文件未对剪裁生存周期过程作出规定。GB/T22032-2021附录A提供了有关系统生存周期过程剪裁的规范性指导。GB/T8566-2022附录A提供了有关软件生存周期过程剪裁的规范4.5.2信息项择或修改本文件的条款。声明剪裁文本，并声明其剪裁合规性。定制符合性是通过使5概念8本章介绍的概念适用于需求描述本身以及对其文档化过程中产生的信息项。这些概念适用于相关5.2基本要求需求工程是一个具有跨领域功能的学科，在需方和供方或开发人员的领域之间进行协调，以建立和维护相关系统、软件或服务要满足的需求。需求工程涉及发现、获取、开发、分析a)参考已定义的系统、软件或服b)使利益相关方（如需方、用户、客户、操作方、供方）能够达成一致的理解；e)为验证设计和解决方案提供5.2.2利益相关方当在需求工程的周境中考虑时，项目中的利益相关方因项目而异。至少一组利益相关方包括用户或多个组织具有从该系统中受益的合法权益。其次，监管机构可能有法律、行业或其他5.2.3将需要转化为需求定义需求始于利益相关方需要（或目标、目的），这些需要经过细化和演变才能成为利益相关方的有效需求。初始的利益相关方关注点不作为利益相关方要求，因其通常缺乏定义、分析以及可能的一致性和可行性。需求工程使用运营理念来帮助理解利益相关方在组织层面的关注点，并从系统角度来看待系统运营理念，将利益相关方从最初的、往往是潜在的需要引导到一组客观充分、结构化和更当相关系统是整个系统结构中第二级或更低层级的系统元素时，还需要识别该层级利益相关方的需要和要求。这些需要不仅仅适用于系统结构中最顶层的系统。在做出更低级别的架构或设计决策之然后，利益相关方的系统需求被转换为相关系统的较低层级系统元素需求。如果技术或复杂性风转换可能会涉及到大量的迭代。同样的过程也递归地应用于较低物理层级的需设计和开发的系统元素，第6章详细说明了执行利益相关方和系统需求定义的过程。第7、8和9章包含与记录需求相关的信5.2.4需求构造9应制定结构良好的利益相关方需求、系统需求和系统元素需求。此举有助于与利益相关方进行需求确认，并有助于确保需求准确地描述利益相关a)系统应满足或拥有解决问题、实现目标或解决利益相关方问题的能该描述提供了区分需求和这些需求的属性（条件、假设和约需求是转换或表达需要及其相关约束和条件的文字陈述。需求可以用自然语言或其他形式的语言编写。如果以自然语言的形式表达，则文字陈述宜包括一个主语和一个动词，以及充分表达内容所需的其他元素。需求应说明需求的主题（例如，系统、软件等）、应做什么（例如，d)偏好或目标是期望的、非强制性的、非约束性的规定，使用“宜”。注2：敏捷中的需求可以使用替代方式，如用户故事，而不明确使用术语“应”。关于或或条件是为需求规定的可测量的定性或定量属性。条件进一步限定了所需的需求，并提供了允许以可确认和验证的方式制定和说明需求的属性。条件可能会限制设计师可以选择的选项。重要的是将利益相关方的需要转化为利益相关方的需求，约束限制了系统工程过程的设计解决方案或实现。约束可以适用于所有b)物理尺寸限制（例如，控制器应安装在机可对需求进行排序或加权，以表明优先级、时间或相5.2.5独立需求的特征a)必要的。需求定义了基本能力、特性、约束和/或质量因素。如果这些未包含在需求集中，则将存在能力或特性方面的缺陷，而这些缺陷无法通过实施其他需求来实现。该要求目前适用，并没有随着时间的推移而过时。明确确定了具有计划失效期日期或适用日期的需求。b)合适的。需求的具体意图和详细程度适合于其所指的实体层级（与实体层级相适应的抽象层注1：虽然额外的详细信息可能仍然很重要，但这些信息以其他形式记录和传达，如5.2.8中的需求属性（例如，基本原理），以帮助设计和实现。此外，在需求中包含设计解决方案会产生潜在设计解决方案可能被忽略或消除的风险。例如，说明表达准确的业务系统集或可购买而非制造的系统的需求，说明概念系统中项目的差d)完整的。需求充分描述了满足实体需求所需的必要能力、特征、约束或质量因素，而不需要其g)可验证的。需求的结构和措辞应确保其实现能够在需求存在的水平上得到证明（验证）并使客5.2.6一组需求的特征对于利益相关方、系统和系统元素需求的集合，要考虑一些特定的特征，而不是针对任何单独的需求。这些需求集提供了一个符合利益相关方意图和约束的一致解决方案。系统、软件或服务的每组素，而无需进一步的信息。此外，集合不包含任何“待决定（TBD）”、“待规定(TBS)”或“待解决(TBR)”子句。“TBx”词组的解决可能是迭代的，“TBx”项目有一个可接受的时间注2：在需求定义的演变过程中，通常需要包括TBx名称，因为过程由系统分析结果和权衡决定通知。然注3：经修改的开源软件通常具有所关注的系统中未使用的现有功能。对于集成系统、系统体系和包含COTS组b)始终如一。需求集包含唯一的单个需求，这些需求与集合中的其他需求不冲突或重叠，并且单位和测量系统是同质的。需求集合中使用的术语是一致的，即在整个需求集合中使用相同的术c)可行。整套需求可以在实体约束（例如成本、进度、f)能够被验证。满足需求集将导致在约束条件下（例如，成本、进度、技术、仔细检查这些特性的需求集对于避免生存周期内的需求变化和增长（“需求蠕变”）至关重要，需求应说明“需要什么”，而不是“如何”。需求宜说明所关注的系统需的设计决策。然而，随着需求在系统的各个层级上进行分配和分解，可以确认在更高层级上定义的设计决策/解决方案架构。这是需求、架构和设计过程的迭代和递归应用程序的一应避免使用含糊和笼统的术语，以防导致需求往往难以验证，甚至不可能验证，或者可能）；）；）；d)歧义术语，如副词和形容词（如“几乎总是”、“重要”、“最），）；）；）；i)不完整的参考文件（未指定参考文件的日期和版本号；未仅指定参考文件的适用部分以限制有关需求的所有假设均应在5.2.8中与需求相关的需求属性之一(例如，基本原理)或随附的文件中5.2.8需求属性为了支持需求分析，格式良好的需求宜包括定义的描述性属性，以帮助识别解和管理需求。属性信息宜与所选需求存储库中的需求相关需求属性示例a)标识。每个需求都应被唯一标识（即编号、名称标签、助记符）。联系和关系，也可以与标识分开。唯一标识符有助于需求追踪。一旦分配，标识是唯一的，b)版本号（以及需求版本的指示）。这是为了确保实现正确的需求版本，并c)所有者。维护需求的组织人员或元素，有权对该需求发表意见，批准需求变更，并报告需求d)利益相关方优先级。宜确定每个需求的优先级。这可以通过潜在利益相关方之间的协商一致过程来确定。在适当情况下，可使用1-5等量表或高、中、低等简单方案来优先级。优先级并不意味着某些要求是不必要的，但可能表明在需要就替代品作出决定时，哪些要求是权衡空间的候选要求。优先化需要考虑需要需求的利益相关方。这有助于权衡需e)风险。根据风险因素分配给每个需求的风险值。有风险的需求包括不具备格式良好的需求应），实体需要无法实现（系统验证失败）。风险还可以解决技术、进度、成本、政治等方面的可行性/可达性。如果满足需求所需的技术是新的，成熟度较低，则风险高于在其他类似项目f)原理。应掌握确定每个需求的基本原理。基本原理提供了需要该需求的理由（根原因），并指出了任何支持性分析、权衡研究、建模、模拟或其他实质性g)困难。宜指出每项需求的假定难度（例如，简单/标称/困难）。h)类型。需求在意图和所代表的属性种类上有所不同。类型属性的使用有助于识别相关需求，需求类型属性示例a)功能/性能。功能需求描述系统或系统元素功能或系统将执行的任务。性能是功能的一个属性。性能需求本身就是一个不完整的需求。性能通常是定b)接口。接口需求定义了系统如何与外部系统交互（外部接口），或系统内的系统元素（包括人的元素）如何相互交互（内部接口）。外部接口要求在系统、软件或服务与项目外部世界程要求包括：遵守国家法律和地方法规，包括环境法、行政要求、需方/供方关系要求和具体工作指令。过程需求也可能由公司方针或实践强加给项目。系统或系统元素实施过程需求，如指定特定设计方法，通常在项目协议文档（如合同、工作说明书和质量计划）中获得。性、可携带性、可重用性、可靠性、可维护性和安全性。在开始要求活动之前，应识别质量要求的种类（例如，“能力”）。这宜根据正在开发e)可用性/使用质量要求（针对用户性能和满意度）。为系统设计和评估提供依据，以满足用户需要。可用性/使用质量需求是与系统的总体需求规格说明一起开发的，并构成系统总体注2：GB/TSQuaRE标准，特别是GB/T25000.30f)人为因素要求。在安全性、性能、有效性、效率、可靠性、可维护性、健康、幸福感和满意度方面，说明与人类用户（以及受使用影响的其他利益相5.3实际考虑事项迭代和递归两种形式过程的应用，对于应用本文件中定义的过程是必不可少的和有用的。过程的迭代应用当在系统的同一层级上重复应用同一过程或过程集时，该应用称为迭代应用。迭代不仅是适当的，而且是预期的。通过应用一个或一组过程创建新信息。通常，这些信息的形式是关于需求、分析的风险或机遇的问题。此类问题应在完成一个或一组过程的活动之前解决。当重新应用活动或过程可以解决问题时，这样做很有用。在将下一个过程或一组活动应用于所关注的系统之前，可能需要迭代来确过程的递归应用当同一组过程或同一组过程活动应用于系统结构内连续层级的系统元素时，应用程序形式称为递归。一个应用程序的结果用作系统结构中下一个较低（或较高）系统的输入，以获得更详的结果集。这种方法为系统结构中的连续系统增加了价值。图2说明了从上到下将流程递归应用到系统的过程。利益相关方需求定义过程只能应用于所关注的系统层级。然而，需求、架构和设5.3.2需求工程中的迭代和递归的层级上定义和记录需求陈述，而不仅仅是整个所关注的系统。将系统需求分配或分发到系统元素可以实现这一点。将需求分配给系统元素的活动是架构定义过程的一部分，与系统架构的定义并行进行。在需求过程和生存周期中的其他过程（如架构、设计）之间可能存在多次迭代，以解决需求和架构之a)需求分析中、分析活动之间有目的的迭代；b)从下游活动到需求分析的计划迭代，因为预测的、显著的、需求的真实变化率反映了需要的c)从下游活动到需求的计划内或计划外迭代，因为可行性和平衡问题由技术或实施问题引起的d)由于其他解决方案问题，如非开发系统元素的变更或缺陷所关注的系统的设计创建了对系统元素的要求，而系统元素的设计创建了对较低物理系统元素的要求，依此类推。因此，本文件中所述的需求工程活动可以并且通常宜应用于逐步从属的解决方案元架构设计的主要目标之一是确定如何划分系统；也就是说，如何识别哪些需求宜分配给哪些系统元素。在定义系统元素时，宜创建额外的需求声明（称为派生需求），以定义系，从而在系统元素的较低抽象层级的上下文中提供必要的清晰性，或指定系统元素的设计约束或性此外，在架构或设计演变的某些部分发展之前，无法导出某些需求。一些要求取决于几个系统元素如何相互操作。例如，系统的信息吞吐量取决于系统硬件、软件、人员动作和环境的交互。需求、架构和设计过程的递归和迭代应用程序用于获得这经验丰富的工程师通常能够识别现有或现成的解决方案在哪里可以适应系统元素的实现。分配给这些注：6.3.3详细说明了定义需求的过程，包括如何应用迭代本条通过说明项目中的典型应用程序类型，描需求过程及其结果规格说明取决于定义需求的系统的范围。要开发或改变的系统或系统元素的需求受制于业务或组织运作的组织级需求。系统或系统元素的需求逐步分配到较低级别的系统。系统范注1：即使业务一词可用于公共部门等非营利组织，本文件的用户也可以根据用户环境将业务一词替换为组织或组业务需求规格说明（BRS）、利益相关方需求规格说明（StRS）、系统需求规格说明（SyRS）和软件需求规格说明（SRS）旨在表示不同的需求信息项集。规格说明对应于图3中的需求，如下所示：BRS–业务需求（业务管理层级StRS—利益相关方需求（业务运营层面SyRS—系统需求；SRS—软件需求。这些信息项可以迭代或递归地应用于多个规格说明（实例）。图4中说明了需求过程注2：在某些情况下，项目不是由业务需求驱动的，而是由任务需求驱动的。在这种情况下，可以考虑任务需求规运营理念（ConOps）和系统运行概念（OpsCon）有助于从组织中的各个利益相关方处获取需求，并作为沟通和分享组织意图的实用手段。在组织层面，ConOps解决了领导层预期的组织运作方式。ConOps可能将一个或多个系统的使用称为“黑箱”。OpsCon从用户的角度解决了特BRS、StRS、SyRS、SRS、ConOps和OpsCon中表示的信息项是相互依赖的。这些项目的开发需要互不同类型的系统可以为其包含的各种需求提供并行文档。但是，一般来说，需求文档将从BRS、StRS和SyRS开始，包括软件规格说明以及硬件和接口规格根据对GB/T22032-2021和GB/T8566-2022中一项或两项的遵守情况，项目应实施GB/T22032-2021和GB/T8566-2022中定义的以下c)系统需求定义过程（GB/T22032-2021中6.4.3）或系统/软件需求定义过程（GB/T8566-与本文件相关的原始GB/T22032-2021和GB/T8566-2022,为避免过度重复，GB/T8566-20222)利益相关方需要和需求定义过程；这三个过程产生了一组基线需求，这些需求将导入到架构和设计过程，配、分解并跟踪到系统元素。架构和设计过程还包括需求分配，以启动需求过程的递归和迭代的应用。这应用了ISO/IEC/IEEE24748-1中所述的项目系统生存周期模型定义。架构和设计过程包括需求的分组织战略通常包括组织的预期方向和业务或使命目标，包括应解决的任何问题或机遇。通过审查与组织业务或使命相关的问题和机遇，组织可以识别现有能力、系统、产品或服务中的缺陷或差距。该策略包括开展业务或使命分析所需的方法、里程碑、资源和具体考虑因或使命需要得到详细阐述并正式成为业务/使命需求。这还包括用于识别问题空间识别和计划为了支持业务或使命分析所需要的使能系使能系统或服务有助于系统的生存周期活动。就业务或使命分析而言，包括组织的业务系统和存储库、业务开发和市场分析资源，以及为问题空间和解决方案空间的评估和分析提供洞察力这可能包括对企业内部或外部的业务数据系统在相关权衡空间因素的周境中分析客户投诉、问题和机在为解决方案类别的识别和评估做准备时，这项任务与理解已识别的问题或机遇的驱动因素相关。重点是任务需求、业务机会、能力的变化方面，某些质量或性能方面的改进，或效率方面的一些提高。权衡空间因素是确定备选方案可行性的最关键标准。这些因素根据使命或业务机会的重要程度来定义问题。标准可以是技术参数，如有效性度量，也可以是业务参数，如市场份注：质量改进包括人身财产安全性、信息安全性、可访问性和可用性。性能改进包括可靠性、用户满意度和服务每项分析任务都宜从机会或问题的简明陈述开始。虽然业务或使命管理层可能会发现很难简明扼要地定义问题或机遇，但如果问题或机遇的所有者无法在一开始就简明扼要地表达出来，则后续分析很可能失败。在一些组织中，问题或机遇可以用一个简明的陈述来描述，有时称为使业务或使命管理准备一些初步的生存周期概念，这些概念由业务运营层的利益相关方在随后的利益相关方需要和需求定义过程中详细阐述和细化。典型的生存周期概a)OpsCon概述了在组织预期运营的背景下系统解决方案(新的或发展的)的运营方面的内容。b)获取概念描述系统解决方案的获取方式，包括利益相关方参与、解决方案来源、需求定义、d)支持概念描述部署系统解决方案后支持系统解决方案所需的支持基础设施和人力考虑。支持e)退役概念描述系统停止运行和退役的方式，包括处理过程中使用的或由此产生的所有有害物由于这些是生存周期概念的典型示例，也可以创建其他示例来处理生存周期的特定焦点。生存周注：最终的系统解决方案可以是新系统、现有系统或系统集的演变、对现有系统或系统集的操作变更，或这些的本活动确定并描述可解决问题或机遇的解决方案类别。在需求工程的早期阶段，业务或使命管理需要谨慎地用逻辑术语描述需要，也就是说，用问题域（业务任何问题域，通常在解决域中都有一系列潜在的解决方案类。每个备选解决方案类将代表一组解决方案，这些解决方案可能代表完全不同的设计类型，甚至是不同类型的项目。因此，可行性分析是缩小解决方案范围的关键步骤，以便能够有效地管理后续项根据可用资源（如资金、时间、人员和材料）考虑可行的备选方案。权衡空间因素在一套评估参数和决策标准中发挥着重要作用。权衡空间因素是确定替代解决方案类别可行性的最关键标准。这些因素根据任务或业务机会的重要程度来定义问题。标准可以是技术参数，如有效性度量务参数，如市场份额。关于备选方案权衡研究和评估的制定和实施，请参考GB/T22032-2021中6.3.4和6.4.6或GB/T8566-2022中6.3.4有关执行决策分析（权衡研究）和在备选方案中做出决策的信息，请参考GB/T22032-2021中宜建立和维护需求可追溯性，以记录业务需要和需求是如何满足业务问题和机遇的，以及是如何与首选替代解决方案类和利益相关方需要和需求相关的。需要在整个系统生存周期以及以后获取、在追踪和维护业务和使命需求。使用需求管理工具可以促进这一过程。关于可追溯性应用的更多讨论见关键信息项和工件将包括初步生存周期概念，包括：Op退役概念。此外，权衡研究报告和支持性分析也可能被视为关键信利益相关方需要和需求定义过程的目的，是定义利益相关方对系统的需求，此系统能够在定义该过程定义了在整个系统生存周期内涉及的利益相关方[或利益相关方类(集)]及其需要。对这些需要进行分析，并将其转换到一个共同的利益相关方需求集合。此集合表述系统与其运行环境之h)利益相关方需要和要求定义过程所需的所有使能系项目应根据与利益相关方需要和需求定义过程相关准备利益相关方需要和需最好识别系统生存周期的所有阶段，然后识别在整个系统生存周期中拥有关方或利益相关方类。从利益相关方那里获得的需求可能取决于利益相关方在组织中的角色、责任和地位。识别在所需产品或服务中扮演角色或感兴趣的所有利益相关方类。然后识别对目标、战略、运营和目标体系有重大影响的利益相关方。随着对所需产品或服务的了解越来越多，利益相关方类的列表通常会随着时间的推移而修改。应识别每个利益相关方类的代表，并包括多层级的观点。仅从一个利益相关方类或一个层级收集的信息角度单一可能存在偏见。有代表性的利益相关方是必要的，以提该策略包括诱导和获取利益相关方要求并将其转化为利益相关方需求所需的方法、里程碑、资源和具体考虑因素。这包括如何处理对立的利益。在处理对立的利益相关方要求时，首先寻找对需求子不同的或对立的利益相关方需要可能会引起解决方案可能需要适应需求的变体的实现，这些变体可能是解决方案的操作、逻辑或物理方面的变体。该策略解决了如何处理各种各样的、可能相互对立的需使能系统或服务有助于系统的生存周期活动。在利益相关方这还可以包括工具和存储库，这些工具和存储库维护有关系统的信息，这些系统在接口处提供输入或这可能包括对企业内部或外部的业务数据系统或其他资源的预定或指在运营理念和初步生存周期概念内定义使用的ConOps描述了一个组织对一项行动或一系列行动的假设或意图。ConOps通常包含在长期战略计划ConOps提供了界定操作空间、系统功能、接口和操作环境的基础。有时，使用周境描述获取使用周境（见ISO/IEC25063）。初步生利益相关方需要的识别包括直接从利益相关方那里提取需要，基于领域知识和的利益相关方需要，以及记录以往活动的差距。需要通常包括效能指标。功能分析通常用于辅助提取有助于诱导出和识别非功能性需求的质量需求，这些需求通常是隐含的利益相关方需使用决策管理过程（GB/T22032-2021，6.择。其他过程可用于提供评估和选择的洞察力，例如测量过程（GB/T22032-2021中的6.3.7或GB/T8566-2022中的6.3.7）以提供定量洞察力，系统分析过程（GB/T22032-2021，6.4.6或GB/T8566-2022中的6.4.6）提供特定参数或风险管理过程（GB/T22032-2021中的6.3.5或GB/T8566-2022中的6.3.5）的分析结果，以深入了解与需要相关的技术、成本、进度或其他风险在大多数系统中，可能有许多需要来源，最终也可能是需求来源，因此识别并评估对系统的影响是至关重要的。需要处理的一些共同来源和问题包a)目标。术语“目标”（有时称为“业务关注点”或“关键成功因素”）指的是系统层目标。目标为一个系统提供了动力，但往往是模糊不清的。评估目标的价值（相对于优先级）c)运行场景。是否有任何需要考虑的特殊场景？场景可用于定义运行概念，并限制系统产品、预期操作环境和接口系统、平台或产品的预期用途范围。场景有助于识别可能被忽略的需求。将场景分解为更小的部分有助于揭示可能导致识别需求的活动。“生命中的一天”分析允许分析员在典型的使用周期中浏览系统的使用情况。这种类型的分析可能从传统结构化系统思维以外d)运行环境和使用周境-需求源自系统/软件产品将在其中运行的环境。系统/软件会在高温或低环境的其他方面（威胁和互操作系统）也可能导致对系统的需求。这些会极大地影响系统的可g)有效性。系统在执行其任务时应具有多大的有效性/效率？有效性的适用措施是什么？系统是i)组织环境。需要许多系统来支持组织的注2：很少有系统不存在与使用、用户、操作员、维护人员或某些人为系统问题源相关的重大风险。有关使用系统可能导致的伤害类型的说明，参见ISO9241-220:2注3：有关可访问性的更多信息，参见ISO/IECTR2注4：有关用户需要的更多信息，参见ISO/IEC25064；有关识别用户和环境特性，参见ISO9241-11和ISO/IEC开发运行概念和其他生存周定义一组有代表性的场景，以识别与预期的运行和其他生存周期概念相符的场景可用于定义概念文档，并限定系统产品、预期运行环境和接口系统、平台或产范围。场景有助于识别可能被忽略的需求。场景可以帮助建立为对系统成功至关重要的、满足关键和期望的系统性能阈值和目标的系统性能指标。场景还可能确定那些需要的、但可能会做出妥协的、用以满足关键的参数。用例方法也可用于定义概念文档。根据这种方法，识别了一组参与者（与系统交在利益相关方需要和需求过程中，利益相关方对业务或使命分析过程中提出的一些初步生存周期概念进行了详细阐述和细化。这些包括OpsCon、获取概念、部署概念、支持概念、退役概念以及为解这些因素可能包括工作场所环境、正常或异常使用条件，以及用户的预期技能和知识。系统可用种全面的系统方法，以使包括人、技术（硬件和软件）、操作环境和系统元素之间的必要接口协调工场景和任务、用户群体和质量特性考虑的清晰理解。用户任务和性能、人力和培训方面的需求主要可以通过将系统的目标或使命分解到任务分析层级来定义，以定义用户界面的特征或前端分析来确定培将利益相关方需要转化为利益相关a)外部或组织利益相关方（例如，工程计划、技术性能度量、技术成熟度、法规、生存周期成d)反映总体需方/用户满意度的有效性和适用性措施（例如，性能、安全性、可靠性、可用性、a)最高管理层要求的预算限额是后续需求过程的约束；b)为系统制定的维护策略可能会对需求施加条件或约束（维修时间和/或备件水平可能会驱动识别与关键质量特性相关的利益相关方需求和功作为这项任务的一部分，识别和评估重用以前存在的需求的机会非常重要。这包括识别提供类似功能或能力的现有系统、适用于所关注的新系统的指定功能或能力，以及关于可重用程需求和需要获取是一项迭代活动。考虑几种不同的技术h)组织分析技术（如优势-劣势-机熟悉如何将他们的专业知识转化为格式良好的需求陈述。除了这些需求的人力资源外，重要的系统需领域的基本特征。也可能存在驱动系统要求的安全或其他对用户社区的描述（通常在组织运作概念中找到）可以提供对整个工作的共同理解，并确认场景的适当性。用户描述可能涵盖产品将要销售到的人口统计组，或指定使用该系统或从其运行中获益的在利益相关方需求和需要获取过程中，让利益相关方参与利益相关方需求（例如，格式良好的需宜针对5.2.5和5.2.6中定义的特如果来自现有或遗留系统的利益相关方需求已被识别为可重用的候选需求，则宜根据适用性、可行性、可用性、质量、成本效益、价值和货币等因素对其进行分析以供使用。在重用需求时，宜仔细检查重用需求与所关注的系统的特定需求的符合性，以确保符在需求工程过程中，通常会有一个或多个正式计划的点来确认需求。目标是在投入资源实施需求的系统解决方案之前识别所有问题。需求确认涉及检查需求集的过程，以帮助确保需求定义了正确的需求确认须经项目管理方和关键利益相关方批准。本活动用于确认需求正确反映了利益相关方的在需求的分析和分配过程中，持续进行需求协商非常重要，因为会发生冲突。可能需要在要求互出于合同原因，此类决策可追溯至利益相关方通常很重要。多种分析方法和冲突解决技一些组织认为需求协商是需求确认的一部分。只要冲突解决在需求分析任务中尽早发生，特定流管理利益相关方需要和要进行需求评审可能是验证和确认需求规格说明最常用的方法。成立一个查找错误、错误的假设、清晰度的缺失、可验证性问题以及与标准实践的偏差的评审小组，进行审查的小组的成员很重要（例评审可以在需求集合中的系统结构的任何层面进行。各种类型的评审可能适用于需求的整个开发和维护过程，包括技术评审、检查和走查。可以通过使用低保真原型来获得系统潜在用户的反馈，实利益相关方要求的协议可能仅限于单个利益相关方，仅同意利益相关方要求的关方需求之间可能存在冲突。完整记录利益相关方需要，即使这些需要之间存在冲突，这是利益相关宜建立和维护需求可追溯性，以记录正式需求如何满足利益相关方的目标并达成利益相关方的协定。利益相关方需求需要在整个系统生存周期和更长的时间内获取、跟踪和维护，并置于技术状态控制之下。使用需求管理工具可以促进这一过程。关于可追溯性应用的更多讨论见本文件的任注3：GB/T22032-2021、6.3.5和本文件宜考虑使用需求管理工具，尤其是对于更复杂的项目。该工具宜能够示关系。需求管理工具旨在促进和支持整个项目生存周期内需求的系统化管理。这包括但不限于需求注5：有关需求管理工具的其他信息和指南，参见ISO/IEC需求存储库宜首先保存利益相关方需要的源文档、项目约束（如来自业务策略/其设计的整个系统需求集提供基础的所有其他条件。可作为利益相关方需求定义过程一部分输出的信系统[系统/软件]需求定义过程的目的是，把期望的能力从面向利益相关方或用户的视图，转为了满足利益相关方的需求，本过程创建了一组特定的可测量的系统需求，从供应商的角度指定了系统应该具备哪些特性、属性以及功能和性能需求。只要条件允许，需求不应隐含任何特定实a)组织。利益相关方宜了解将使用目标系统/软件的组织以及该组织的真正使命b)环境。利益相关方宜了解所关注系统领域的成熟度、所关注系统与运行环境中其他系统之间c)约束。利益相关方宜考虑影响所关注的系统的生存周期的约束，如成本、进度、政治、环境该策略包括识别和定义系统/软件需求以及在整个生存周期中管理需求所需的方法、里程碑、资源识别和规划支持系统[/软件]需求定义所必要的使能使能系统或服务有助于系统的生存周期活动。在系统/软件需求定义的情况下，使能系统和服务包括工具和存储库。这些工具和存储库可用于从利益相关方获取系统需求，并获取、管理和当更好地理解了系统/软件的各种功能和元功能或能力的现有系统、适用于所关注的新系统的识别与风险、软件系统的关键性或者关键质量特性相技术措施用于深入了解系统或系统元素在达到要求中规定的技术参数方面的进展情况。这些措施包括性能测度（MOP）和技术性能测度（TPM）。MOP表征与系统操作相关的物理或功能属性的测度。MOP是在运行环境条件下测量的。TPM是用于评估设计进度、性能要求合规性和关键性能参数的技术风险的测度。有关这些方面的更多信息，参见ISO/IEC/IEEE24748-2。使用质量测度用于确定产品是否满足特定用户的需要，以在现实系统环境中的特定使用环境中实现有效性、生产率、安全性和满意度的特定目标。v)来自现有的自动和手动系统运行过程和数据的转换，迁vi)需求属性，如基本原理；优先级；软件系统元素括派生需求）如何满足利益相关方需求和目标，并达成利益相关方软件规格说明参数的选择取决于软件元素、架构和利益相规格说明是需求的集合，描述了产品、材料的基本技术要求以及确定是否满足这些要求的标准。作为系统/软件需求分析过程重要组成部分的需求规格说a)为需方或供方之间就产品的用途达成协议奠定了基础（在市场驱动的项目中，用户输入）；架构可用于帮助分析需求集，以帮助确保架构的所有特性和功能在需求中得到正确表可用性、质量、成本效益、价值和货币等因素对其进行分析以供使用。在重用需求时，宜仔细检查重注1：有关要求重用的附加指南，参见ISO/IE5.2.8中的分类有助于完成此任务。GB/T22032-2021中的a）或GB/T8566-2022中的a）中的“验证准备”活动宜用于需求验证的定义、识别评估每个系统需求实现情况所需的性能测度和技术性能测度。该架构可用于帮助定义关键性除了验证需求之外，下面的活动处理了需求（无论是单独的还是作为一个集合）的确认，以恰当将分析后的需求反馈给合适的利益相关方进行需求确认有助于确保利益相关方需求已正确转化为系统需求。可以使用各种技术，包括利益相关方评审、原型设计、建模和仿真、概念建模和正式建模。适当的技术可以根据利益相关方的特点而有所不同，因此可能需要采用多种技术，以便考虑所有利益相关方。本文件在任务1下讨论了评利益相关方评审是一种常见的技术，用于确认易于实现的需求。利益相关方评利益相关方的小组一起对需求进行分析，以确定系统需求是否完整、正确和一致，且反映利益原型通常用于获取需求、确认系统需求的解释、澄清或检查需求属性以及识别任何遗漏的需求。原型的优势在于，为利益相关方的评估和输入提供了更丰富的背景，可以更容易地解释假设，并且可以提供关于其错误原因的有用反馈。例如，通过动画或静态原型可以更好地理解用户界面的动态行为，而不是通过文本描述或图形模型。然而这也有一些缺点，包括开发原型的成本、潜在的错误假设和无根据的期望以及低保真度原型的质量问题。当原型的目的得到充分理解时，可以使用原型的适当保真度水平来实现有效的早期需求评审和验证。保真度水平和构建质量应以原型目的为基础。建模和仿真可用于协助利益相关方确认需求。建模和仿真的优势在于，当结果与利益相关方的预期不符时，可以演示交互作用并允许进行敏感性分析。架构定义过程中的模型和视图可用于帮助利益注2：有关建模在开发架构和帮助识别相关需求中的作用的更多信息，参见ISO/IEC/IE静态概念建模是另一种可以使用的技术。目的是帮助理解问题，而不是开始设计解决方案。因此，概念模型包括来自问题域的实体模型，这些实体被配置为反映其真实世界的关系和依赖关系。有几种a)问题的性质：某些类型的应用程序要求对某些方面进行特别严格的分析。例如，控制流持、作为过程要求或简单地“更好”的记法可能是适当的c)需方的过程要求：需方可能会采用特定的记法或方法，这可能与之前的使用基于离散数学的记法并可追溯到逻辑推理的形式化建模在一些专业领域产生了影响。正式建模可能由需方或标准实施，也可能为某些关键功能在系统需求的分析和分配过程中，持续进行需求协商非常重要，因为会发生冲突。当需求集完整、进行需求评审可能是验证和确认需求以及促进需求符合性的最常用方法。此外，利益相关方宜准备通过谈判达成并维持协定。通常，系统/软件需求的所有者负责主持协商。负责人宜具备必要的谈判需求追踪涉及到恢复需求的来源和预测需求变更的影响。可追溯性宜包括接口要求。追踪是执行以下分析的基础：覆盖率分析（以帮助确保在设计中满足所有利益相关方的需求，并确保每个低层级还宜向上追溯到激发每个需求的需求和利益相关方（例如，从软件需求返回到帮助满足的系统需求）。对于源自权衡或设计研究的需求，这些派生需求宜可追溯至其派生的研究，且该研究宜可追溯b)允许跟踪需求开发和分配，以及相关措施，如需求覆盖率、合规性和复杂性；每个需求应进行技术状态控制。与需求一起记录的辅助信息可以包括每个需求、决策、假设和变更历史的概要依据，以及5.2.8中描述的需求分类信息。再次指出，需求管理工具的使用促进了维护需求可追溯性和技术状态控制信息项的繁琐而复杂的项目，这些信息项可以作为系统需求定义过程的一架构定义过程的目的是生成系统架构备选方案，选择一个或多个备选方案，构建利益相关方关注接口需求（机械、电气、数据和包络）是需要全面记录的重要需求类型，可以包含在规格说明或接口控制文档中，并且需要可追溯到接口双方。接口需求被纳入架构定义中。接口文档由涉及系统间备选架构是根据配置系统的一组系统元素的需求来定义的。建立和维护需求和架构（包括系统元注1：GB/T22032-2021，第6.4.9节或GB针对每项验证活动选择适当的验证方法或技术和相关该活动通过在创建需求时最初关联验证方法来实现。宜记录验证方法。文档可能包括需求验证和可追溯性矩阵或验证计划中的验证声明。验证方法定义了如何（包括成功标准和结束方法）、何时何地证明每项要求的合规性以供需方接受。验证方法与每个需求相关联以定义活动，这些活动产生证明需求满足的客观信息。一个好的验证方法定义可b)谁。确定负责执行验证的组织或人员，如承包商、分包c)何时。在获取项目计划中指定进行验证的时间。这应该是一项基于事件的成就，有四种标准验证方法可用于获取满足要求的客观证据：检查、分析或模拟、演示和测检查——根据适用文档对项目进行检查，以确认符合要求。现实际条件下的测试或不符合成本效益的情况下使用。当此类方法确定拟定解决方案满足适当的需求、规格说明或派生需求时，可使用分析（包括模拟）。分析也可以基于“相似性”，通过审查类似项目的先前验证，并确认其验证状态可以合法地转移到当前系统元素。只有当项目在设计、制造和使用方面相似时，才能使用相似性；类似的系统元素采用了同等演示——功能性能的定性展示，通常在没有或很少使用仪器或测试设备的情况下完成。演示使用一组由供方选择的系统激励的测试活动，以表明系统或系统元素对激励的响应是合适的员在使用系统时可以执行其分配的功能。进行观察并与预定响应进行比较。当以统计术语给出要求或测试——在真实或模拟的受控条件下，对项目的可操作性、可保障性或性能进行定量验证的行动。环境条件、所需的资质和测试人员、要遵循的一般步骤、要收集的具体数据、收集数据的重复性标准这确保了系统或系统元素可以按照协定的标准执行其分配的功能。开发评审和系统验证和确认结果构成认证需求可追溯性经常被用作一个单一的责任点，用于将需中向前推进，以评估需求是否得到满足。在需求可追溯性中，验证方法和信息与需求相关联，以表明如何验证系统或系统元素表明其满足需求。随着系统生存周期阶段的推进，宜增加对工作产品需求的确认过程的目的是提供客观证据，证明系统在使用时能够满足其业务或使命目标，以及利益相关注1：GB/T22032-2021中的6.4.11或GB系统运行概念和包含系统的利益相关方需求基线，其中所关注的系统是需求管理包括那些记录和维护不断发展的需求以及来自需求工程活动的相关上下文和历史信息的任务。需求管理还建立了定义、控制和发布所关注的系统各级基线需求的程序。有效的需求管理发生在GB/T22032-2021和GB/T8566-需求很少是静态的。宜识别可能演变的需求，并将其传达给需方和技术团体。需求的核心子集可能会提前冻结。评估拟议新需求的影响，以帮助确保维持需求基线的初始意图，在大多数情况下，需求理解都会随着生存周期活动的进行而不断发展。这通常会导后期修改需求。或许理解需求工程最关键的一点是，需求的很大一部分将发生变化。无论如何，在生存周期中进行需求变更时应谨慎。尽管某些变更可能不可避变更可能导致“需求蠕变”，从而导致成本超支、进度延误、设计错误、买方不满甚至取消项目。无论需求变更的原因是什么，认识到变更的必然性是极为重要的，并采取措施减轻变更的影响是非常重要的。通过确保拟定的变更经过定义的影响评估、审查和批准流程，并通过应用详细的需求追技术状态管理的目的是在整个生存周期内管理和控制系统元素和技术状态。技术状态管理还管理系统运行概念和利益相关方、系统、软件和系统元素要求被确定为技术状态管理规划中技术状态常用的基线是功能基线、分配基线、开发基线和产品基线。给定项目使用的基线以及变更批准所a)功能基线（需求基线）建立了对系统预期功能的共同理解（即协定的系统需求规格说明和相关b)分配基线对应于所关注的系统下物理层级的已审核和版本化系统元素需求规格说明，包括接口c)开发基线表示生存周期中选定时间内不断演变的系统和系统元素技术状态。此基线的变更权限当对运行概念和利益相关方、系统、软件和系统元素需求进行变更时，需要正式捕获这些更改，并将其记录在需求的文档基线中，同时还需要确定具体更改和相关基本原理的技术状态信息。宜维护应根据项目和组织技术状态管理过程对需求进行技术状态注2：GB/T22032-2021，6.3.5和GB/T信息管理过程的目的是向指定的利益相关方生成、获取、确认、转换、保留、检索、传播和处置系统运行概念文档和利益相关方需求规格说明、系统需求规格说明、软件需求规格说明和其他系注2：GB/T22032-2021中6.3.6和GB/T测量过程的目的是收集、分析和报告客观数据和信息，以支持有效管理并证明产品、服务和过程需求工程作为一门学科，从过程和产品环境中的需求测量中获益。可能需要一个以上的指标来洞分析工作，可用于设置需求发布标准，可作为需求和详细设计评审的输入标准，并可用于承b)需求数量–需求数量可用于测量需求工程活动的进度，估计需求完c)需求波动性——在过程上下文中，需求波动性可以表示组织的需求工程过程不会将一组需求聚合到一个结构良好的集合中。在产品环境中，高波动性值可能表明利益相关方未能就系统c)追溯性指标（例如，无子女的父母百分比、每个父母的平均子女）；软件需求用于软件功能规模测量（FSM）方法中，以帮助管理软件项目的许多方面。FSM方法分为注3：GB/T22032-2021中的6.3.7和GB/T8566-2022中的6.3.7提供了有关测量过程的附加信息，ISO/IEC/IEEE选择在整个生存周期内可随时获得数据的度量是一种良好的实践。然后，可以将数据采集集成到与需求相关的过程中，以便在需求工程进行时定期获得数据和洞察力。总体审查b)利益相关方需求规格说明（StRSd)软件需求规格说明（SRS），如果遵守GB/T8566-2022。注2：如5.4所述，四种文档类型中的每一种都可以在项目中产生多个规格说明信息项。例如，可以为系统和系统注3：四种规格说明信息项BRS、StRS、SyRS和SRS可包含类似的信息项，这些信息项可视为同一产品的不同视图。注4：BRS和StRS在不同领域中可以有不同的标题，并且可以包含在其他信息项中，只要这些规格说明的功能可以信息项的管理应采用GB/T22032-2021和GB/T8566-2022的业务需求规格说明（BRS）描述了组织开发或更改系统的动机，定义使用系统所依据的流程和方针业务部门应指定BRS的信息元素。业务管理层应对本规格说明的内容负责。BRS是利益相关方积极注2：在许多行业中，BRS通常与利益相关方需求规格说明（StRS）相关。本文件的用户可以根据用户环境将StRS注3：业务分析知识手册（BABOK）将利益相关方需求和业务需求区分如下：业务需求是对企业目的、目标或需求的高级陈述，描述了项目使能的原因、项目将实现什么以及哪些指标可用于衡量项目的成功。利益相关方需求是对特定利益相关方或利益相关方类别需求的陈述，描述了给定利益相关方的需求以及利益相关方将如何没有一个最优的组织。图5显示了在组织/业务上下文中创建利益相关方需求规格说明（StRS）描述了组织开发或更改系统的动机，定义使用系统的过护人员从使用环境中派生的需求。在BRS中描述的上下文中，StRS描述了组织将如何利用该系统为业务StRs的信息元素应由利益相关方指定。利益相关方应对规格说明的内容负责。StRS是利益相关方积极参与需求过程的基础。StRS中包含的利益相关方需求的典型类型是组织需求、业务需求和用户需注1：ISO/IEC/IEEE15289提供了将用户（利益相关方）需求纳入系统需求规格说明的指南。由于这些内容是从利益相关方的角度指定的，本文件在StRS中包含了这些需求。用户需求可以在SyRS中通过解没有一个最优的编排。图6显示了在组织/业务上下文中创建的S系统需求规格说明（SyRS）识别了所选所关注的系统的假设和非功能性需求的说明。SyRS可能包括用于说明系统环境、使用场景、主要域实体、数据、信息SyRS的目的是根据系统与其外部环境的交互或接口，描述系统应该做什么。SyRS应完整描述所有输入、输出以及输入和输出之间所需的关系。传统上，SyRS被视为将需方的要求传达给将指定和构建系统的技术团体的文档。构成本规格说明及其表述的需求集合起到了两个群体之间的桥梁作用，需要被需方和技术团体理解。创建系统中最困难的任务之一是与两个组中的所有子组进行沟通，本文件提出了这种结构化信息收集与向不同受众呈现信息的方式之间的区别。SyRS的呈现形式应适合其预期用途。这可以是纸质文档、模型、原型、其他非纸质文档或他们的任何组合来表示。所有这些表述都可以从这个SyRS中派生出来，以满足特定受众的需求。但是，应注意确保每个演示文档都可追溯到系统需求信息的共同来源。受众应该意识到，这种结构化的信息收集仍然是解决所选特定演通常，过程需求（如何开发或构建系统）应包含在合同文档，如工作说明书中，SyRS提供了需求定义、系统运行概念、系统架构和系统需求分析任务的结果。因此，SyRS描述了系统的需方希望系统为他们做什么、系统的预期环境、系统的使用概况、性能参数、预期质量和有效应编排SyRS的特定需求部分，以便利益相关方一致同意编排方法有助于理解需求。对于所有项目，软件需求规格说明（SRS）是在特定环境中执行特定功能的特定软件产品、程序或并将外部性能和功能需求放在软件部分上。当然，SRS应同意并扩展这些系统需求。SRS表示需求的优先级和关键性。SRS定义了其适用的指定软件产品的所有所需功能，并记录了软件必须执行的条件和约SRS的具体要求条款的编排应确保系统利益相关方一致同意编排方法有助于理解要求。对于所有系a)系统模式——根据操作模式，某些系统的行为完全不同。例如，根据其模式，控制系统可能b)用户类——一些系统为不同的用户类提供不同的功能集。例如，电梯控制系统为乘客、维修c)对象——对象是在系统中具有对应对象的真实实体。例如，在患者监控系统中，对象包括患者、传感器、护士、房间、医生、药品等。与d)特征——特征是系统外部所需的服务，可能需要一系列输入来实现所需结果。例如，在电话系统中，功能包括本地呼叫、呼叫转移和会议呼叫。每个特征通常以一系列刺激-反e)激励——一些系统通过描述其在激励情况下的功能能够被最好地组织。例如，自动飞机着陆系统的功能可分为功率损失、风切变、横摇突变、垂直速f)响应——一些系统通过描述支持响应生成的所有功能能够最好地组织。例如，人事系统可以被编排为关联到生成工资支票的所有功能、关联到生成当前员工列表所有功能等相对应的条公共内部数据访问组织的功能层级结构。数据流图和数据字典可用于显示函数和注2：有许多记法、方法和自动支持工具可用于帮助记录SRS要求。在很大程度上，方法和工具的有用性是组织的以证明是有用的；当按特征组织时，激励-响应序列可以证明是有用的；当按功能层级结构进行组织时，数9信息项内容9.2.1标识标题和修订通知唯一标识文档。修订信息可能包括项目名称、文档版本号、发布日期、批准签字、文档当前版本中已更改的子条款列表以及文9.2.2前页9.2.3定义提供任何词或词组的定义，这些词或词组具有普通词典定义以外的特9.2.4参考资料b)按标题、报告编号（如适用）、日期和发布组织标识每份文该信息可参考附录或其他文档提供。参考资料信息宜细分为“遵守”部分（包含引用文档中包含9.2.5首字母缩略语和缩写词9.3业务需求规格说明（BRS）内容本条定义了业务需求规格说明（BRS）的规范性内容。项目根据与业务需求规格说明9.3.2业务目的在组织层面上描述组织寻求新业务或改变当前业务以适应新的管理环境的原因和背景。在这种情9.3.3业务范围b)定义相关业务领域中包含的业务活动范围。范围可以根据组织中与业务活动直接相关的部门c)描述正在开发或更改的系统的范围。描述包括系统描述相关业务领域的主要内部部门和外部实体，及9.3.5主要利益相关方列出主要利益相关方或利益相关方类别，并描述他们将如何影响组织和9.3.6业务环境定义在理解新的或现有的业务时宜考虑的外部和内部环境因素，并获取利益相关方对拟议开发或更改的系统的要求。环境因素宜包括市场趋势、法律法规、社会责任和技术基础等外部条件对业务以9.3.7使命、目的和目标9.3.8业务模式描述预期实现业务任务的方法。描述宜集中于系统支持的开发或更改方法，包括产品和服务、地9.3.9信息环境描述基于多个信息系统公共基础的组织级决策的总体策略，宜包括以a）项目组合——当多个系统项目正在运行或计划追求相同的业务目的时，优先级、相对定位和b）长期系统计划——对已经确定或计划了的公共系统基础设施或架构，宜将其描述为对可能的c）数据库技术状态——宜指定组织级数据库技术状态计划以及组织全局数据可用性和可访问性9.3.10业务过程提供业务活动程序的说明以及过程内可能的系统接口。此信息项的目的是表示系统如何以及在何种上下文中支持业务活动。通常，业务过程通过分解和分类形成有序结构。每个业务过程应有唯一的名称和编号。单个业务过程的描述宜表示为表示活动序列的9.3.11业务运行方针和规则描述用于执行业务过程的逻辑命题。这些命题可能是启动、分支和终止业务过程中的业务活动顺9.3.12业务运行约束描述在执行业务过程时要施加的条件。这些条件可能与性能约束有关（例如，9.3.13业务运行模式非常繁忙的状态。业务操作的不稳定状态包括由于意外情况（如事故或自然灾害）而导致拟议系统不9.3.14业务运行质量定义业务运营所需的质量层级。例如，业务过程可以以比业务过程可靠性更高的优先级处理所需注：这可能包括使用中的可用性和质量的高层级目标（有效性、效率、满意度和无使用风险，见ISO9241-9.3.15业务结构识别和描述与系统相关的业务结构，如组织结构（分工和部门）、角色和责资源共享结构。可能需要使系统功能与这些结构保持一致，并9.3.16高层级运行概念以高层级的方式描述拟议系统，指出在不指定设计细节的情况下提供的操作特性。宜包括以下信9.3.17高层级运行场景描述用户/操作员/维护人员在重要使用环境中如何与系统交互的示例。描述了系统支持的业务过程的一个活动或一系列活动的高级场景。场景应具有唯一的名称和编号，并应在9.3.9中的业务流程描9.3.18其他高层级生存周期概念9.3.19项目约束本条定义了利益相关方需求规格说明（StRS）的规范性内容。项目根据项目政策中与利益相关方需求规格说明相关的内容，生成以下信息项内容。可根据项目的信息管理方针选择内容9.4.2利益相关方目的在组织层面上描述组织寻求新业务或改变当前业务以适应新管理环境的原因和背景。在这种情况9.4.3利益相关方范围b)定义相关业务领域中包含的业务活动范围。范围可以根据组织中与业务活动直接相关的部门c)描述正在开发或更改的系统的范围。描述包括系统9.4.4概述描述相关业务领域的主要内部部门和外部实体，及9.4.5利益相关方9.4.6业务环境定义外部和内部环境因素，在理解新的或现有的业务和获取利益相关方对要开发9.4.7使命、目的和目标9.4.8业务模型描述预期实现业务目标的方法。描述宜集中于系统支持的开发或更改方法，包括产品和服务、地9.4.9信息环境a)项目组合——当多个系统项目正在运行或计划追求相同的业务目标时，优先级b)长期系统计划——对已经确定或计划了的公共系统基础设施或架构，宜将其描述为对可能的c)数据库技术状态——宜指定组织级数据库技术状态计划以及组织全局数据可用性和可访问性9.4.10系统过程提供系统支持业务活动的方式和周境描述。一般来说，系统过程是从具有分解和分类的业务过程的有序结构开始的。每个系统过程在结构中都应该有唯一的名称和编号。单个系统过程的描述宜表示9.4.11系统运行方针和规则描述业务运行方针和规则可能如何在SyRS和SRS的功能需求中得到解决。方针和规则应具有唯一的9.4.12运行约束描述在执行业务过程时对系统施加的系统条件和功能要求。这些条件可能导出SyRS中的性能要求。9.4.13系统运行模式和状态9.4.14系统运行质量定义系统运行所需的质量水平，如性能、兼容性、可靠性、安全性、可维护性和可移植性。例如，9.4.15用户需求用户需求是为满足已识别的用户需要而设计和评估系统提供基础的使用需求。用户需求可以包括指定预期结果和相关质量标准的使用的相关质量（包括可用性）需求，指定实现预期结果所需交互的用户系统交互需求，以及任何可能限制解决方案设计和实现自由以满足用户需求的约束。用户需求可为设计指定的使用环境（即系统使用的环境）宜作为用户需求规格说明的一部分进行规定，以明确识别需求适用的条件。系统的可用性要求和目标包括特定使用环境中可测量的有效性、效率和满意注1：有关使用环境的更多信息，参见ISO/IEC25030和ISO9241-11。有关日常产品使20282-1注2：ISO/IECTR25060、ISO/IEC25064、ISO9241-210和ISO9241-220中提9.4.16运行概念以高层级的方式描述拟议系统，指出在不指定设计细节的情况下提供的运行特性。宜包括以下信9.4.17运行场景描述用户/操作员/维护人员在重要使用环境中如何与系统交互的示例。描述了系统支持的业务过程的一个活动或一系列活动的场景。该场景应具有唯一的名称和编号，并应在9.3.10中的业务过程描9.4.18拟议系统的其他详细概念9.4.19项目约束本条定义了系统需求规格说明（SyRS）的规范性内容。项目根据项目有关系统需求规格说明的政策，生成以下信息项内容。可根据项目的信息管理方针选择内容的编排，如顺序和章条9.5.2系统用途9.5.3系统范围b)参考并说明早期最终需求分析的结果，以简短但清晰的方式表达用c)描述所指定系统的应用。作为范围的一部分，该描述应准确地描述所有相关的顶层利益、目9.5.4系统概述系统周境从总体上描述系统的主要元素，包括人的元素及其相互作用方式。系统概述包括适当的图表和叙系统功能用户特征识别系统的每种类型的用户/操作员/维护人员（按功能、位置、设备类型）、每组人数、他们使9.5.5功能要求9.5.6可用性要求定义系统的可用性和使用质量需求和目标，包括可测量的有效性、效9.5.7性能要求）；b)定量标准，包括在规定的环境和其他条件下满足用户需求所需的设备耐久能力，包括最低总9.5.8系统接口要求指定系统元素之间以及与外部实体的接口要求。系统元素之间的接口宜包括与人元素的接口。与定义与接口相关的任何相互依赖性或约束（例如，通信协议、特殊设备、标准、固定格式）。每9.5.9系统运营人-系统集成要求参考适用文档，并规定任何特殊或独特的要求，例如，对人员和通信以及人员/设备交互功能分配定义由于操作的敏感性或任务的关键性而需要集中人力工程注意的任何特定区域、站点或设备的可维护性要求a)时间（例如，平均和最大停机时间、反可靠性需求其他质量需求9.5.10系统模式和状态9.5.11物理特性物理需求包括对重量、体积和尺寸的约束。包括系统安装位置的结构特征、本规格说明涵盖的项目或服务适应性需求定义增长、扩展、能力和收缩的需求。例如，如果系统将需要未来的网络带宽，则宜为适用的硬9.5.12环境条件真菌、霉菌、沙子、盐雾、灰尘、辐射、化学物质、空气污染物和浸没感应环境（如运动、冲击、噪声、电磁、热电磁信号环境；自感环境（如运动、冲击、噪声、电磁、热威胁以及合作环9.5.13系统安全要求定义与容纳系统的设施和系统本身的操作安全要求相关的系统安全要求。安全要求的一个例子可法。这可能包括保护系统免受意外或恶意访问、使用、修改、破坏或披露的因素。特别是在安全关键型嵌入式系统中，这可能包括数据集的分布式日志或历史记录、将某些功能分配给不同的单个系统，9.5.14信息管理要求定义系统对其接收、生成或导出的信息的管理需求。示例包括系统需要接收和存储的信息的类型9.5.15政策和法规要求从将影响系统运行或性能的组织策略和业务实践中派生需求。从相关的外部法规中获取需求。需求的例子包括多语言支持、人力资源政策和保护人详细说明健康和安全标准的派生需求，包括与设备特性、操作方法和环境影响（如有毒系统和电9.5.16系统生存周期保障要求概述质量活动，如评审和测量收集和分析，以帮助实现质量体系。生存周期维持和基地级维修所需的设施、备件、寻源采购、供应、提供、技术文档和数据、支持人员培训、初期干9.5.17包装、搬运、装运和运输要求定义对系统施加的要求，以确保系统能够在其预期运行环境中进行包装、处理、装运、运输和存9.5.18验证提供计划用于鉴定系统或系统元素的验证途径和方法。建议以与9.5.5至9.5.17中信息元素平行的9.5.19假设和依赖性列出适用于系统需求的任何假设和依赖性，这些假设和依赖性宜在分9.6软件需求规格说明（SRS）内容9.6.3范围9.6.4产品视角如果产品是一个更大系统的一个元素，则将该较大系统的需求与SRS涵盖的产品功系统接口用户界面硬件接口指定软件产品和系统硬件元素之间每个接口的逻辑特征，这包括技术状态特征（端口数、指令集等还包含支持哪些设备、如何支持这些设备以及协软件接口指定其他所需软件产品（例如，数据管理系统、操作系统或数学软件包）的使用，以及与其他应注：指定所需的平台或操作系统是可以接受的，但要求特定版本几乎不可行。通常，可以为软件指定最新版本或b)根据消息内容和格式定义接口。无需详细说明任何记录良好的接口，但需要参考定义接口的通信接口操