4.2 相关方需要与需求定义过程
4.2.1 目的
如ISO/IEC/IEEE 15288所述：
相关方需要和需求定义过程的目的是针对一个将在确定环境中提供服务的待开发系统，从用户或其他相关方视角定义需求。
4.2.2 概述
如图4-5所示，相关方需要和需求定义过程是在问题域，从业务运行的角度考虑不同相关方的需要与需求。在整个生存周期过程的不同阶段，都是围绕如何满足相关方的需要和需求来开展的，准确地定义问题是项目成功的关键。《连线》(Wired)杂志创始主编凯文·凯利在谈及“未来发展的12个趋势”时说：“答案是免费的，有价值的是问题。”从这句话可以看出，准确地定义问题对于解决问题来说是多么重要。
图4-5 相关方需要和需求定义问题（图片来源：IBM最佳实践）
相关方是对系统拥有合法权益的任何实体、个人或组织。在确定相关方的过程中：
1）在业务或使命定义过程中，从业务管理的角度确定主要的相关方。
2）在相关方需要与需求定义过程中，进一步考虑业务的整个生存周期不同阶段的相关方。
这包括可能受系统影响或能够影响系统的所有人员——用户、运行者、组织决策者、协议方、法规机构、开发团队、支持维护团队以及广泛的社会(在业务及提出的解决方案的背景环境内)。
在识别相关方后，需要采用不同的方法获取不同相关方的需要，然后对这些需要进行分析并转换成相关方需求集合。从需要到需求的过程，是一个典型的需求分析过程，需要从完整性、正式表达与达成一致三方面进行考虑。表4-2列举了需要和需求的典型区别。
表4-2 需要和需求的典型区别
（续）
相关方的需求驱动着系统的开发，并且是进一步定义或明确开发项目范围的一个根本的要素。
相关方的需要与需求定义过程与工程实践中的用户需求获取与分析过程比较接近。但是，通常的工程实践活动对这个问题进行了大范围的简化，最典型的一种情况就是在对相关方识别的过程中，忽略了很多的相关方，有些型号甚至只考虑用户（军方）的需要。这种简化导致了从一开始就漏掉了很多关键要素。
可以说，工程实践中经常在产品研制后期发现很多问题，很多问题的根源就是在相关方需要与需求定义过程开始时埋下的。
4.2.3 活动描述
图4-6所示为根据《INCOSE系统工程手册（第4版）》相关方需要与需求定义过程IPO图改编的相关方需要与需求定义过程。
图4-6 相关方需要与需求定义过程
根据ISO/IEC/IEEE 15288：2015,相关方需要与需求定义过程包括以下活动：
1.准备相关方需要与需求定义
本活动包含以下任务：
1）识别贯穿系统生存周期对系统感兴趣的相关方。
2）定义相关方需要和需求定义策略。
3）识别并计划必要的使能系统或需要的服务以支持相关方需要与需求定义。
4）获得或购买使能系统或服务的使用权。
2.定义相关方需要
本活动包含以下任务：
1）定义运行构想中的使用环境以及初步生存周期概念。
2）识别相关方需要。
3）确定需要的优先级并排序。
4）定义相关方需要与理由。
3.开发概念
本活动包含以下任务：
1）定义一组典型的场景，以识别与预期的运行和其他生存周期概念相对应的所有需要的功能。
2）识别使用者与系统之间的交互。
4.将需要转换成需求
本活动包含以下任务：
1）识别系统解决方案约束。
2）识别相关方需求以及与关键质量特性相关的功能，如质量保证、安全、保密、环境、健康等。
3）定义相关方需求，与生存周期概念、场景、交互、约束以及关键质量特性一致。
5.分析相关方需求
本活动包含以下任务：
1）分析相关方需求的完整性。
2）定义关键性能度量。
3）反馈需求分析结果给相应的相关方以确认它们的需要与预期已经充分地被捕获并表达。
4）解决相关方需求问题。
6.管理需求
本活动包括以下任务：
1）就相关方需求达成明确一致意见。
2）维护相关方需要与需求的可追溯性。
3）为选定的基线提供关键信息项。
4.2.4 关键要素解析
1.如何确定相关方
系统开发最大的挑战之一就是确定相关方以及获取它们的需要。在大多数情况下，系统开发过程中都重点关注客户与使用者这两类相关方的各种需要。从武器装备开发来讲，多数研究院所都重点关注军方的各种诉求。对相关方的遗漏，造成了系统开发在一开始就对需求考虑不完整。如何完整地确定目标系统的所有相关方，是系统开发在一开始就必须确定的。
正如ISO/IEC/IEEE 15288所叙述的，需求是系统生存周期的主要驱动因素。根据系统开发模型，相关方需要的获取应该在开发周期一开始就开展，并且需要持续开展，相关方的需要与需求在开发周期中可能随着时间的推移和外部环境的变化而发生变化。
确定相关方或相关方类别在业务或使命分析过程和相关方需要与需求定义过程两个过程中来完成。
在业务或使命分析过程中，从组织业务管理层面确认主要的相关方。在相关方需要与需求定义过程中，主要从业务运行层面来确定目标系统在整个生存周期中的相关方。二者所关注的层面不一样。
在目标系统的所有相关方中，大致可以分为三大类相关方：
1）直接相关方。这类相关方会直接从目标系统受益。这类相关方比较容易识别，主要包括客户、最终用户。
2）有数据/信息/能量（包括力）/物质/操作五类交互的相关方。《INCOSE系统工程手册》中所描述的系统都是开放的系统，每一个系统都会运行在一个特定的运行环境中。因此，凡是与目标系统有上述五类要素交互的其他系统的所有者，都是目标系统的相关方。这类相关方（图4-7）主要包括交互系统（的所有者）和使能系统（的所有者）。
图4-7 使能系统与交互系统
3）施加影响/被影响的其他相关方，主要包括：
①管理者（规划顾问组）。
②使用人员。
③工程负责人。
④运营人员。
⑤维护人员。
⑥定义使命任务的合作方（如第三方咨询机构）。
⑦承包商。
⑧法律、法规/标准。
⑨相关管理当局。
⑩外部环境约束与威胁/技术约束/竞争能力。
通常，法律法规以及标准不仅仅包括了国家标准、行业标准，也包括了目标系统所在企业的企业标准以及各种程序文件等。
2.相关方分析
确定完相关方后，接下来需要对相关方进行分析。对相关方的分析主要完成以下四方面的内容：
1）权利-利益分析。
2）权利-动态性分析。
3）影响力-重要性分析。
4）将上述分析结果通过相关方分析表示矩阵（表4-3）进行表示。
表4-3 相关方分析表示矩阵
通过上述分析，可以确定不同相关方的优先级。随后在确定不同相关方需要的优先级时，应根据相关方的优先级来分析确定。
3.获取相关方需要指南
（1）相关方需要获取过程 相关方需要获取六个活动：背景知识、收集需要、分类、冲突处理、优先级划分、需求检查。
获取相关方需要的过程如图4-8所示。
图4-8 获取相关方需要过程
（2）相关方需要获取方法 相关方的需要有多种来源：
1）对相关方的采访。
2）场景探索（通常通过相关方访谈)。
3）描述文档（可能来自于文档研究或市场研究)。
4）现有系统升级。
5）现有系统问题和修改建议。
6）模拟系统。
7）原型，部分系统，甚至简单的草图、产品模型。
8）新技术的机会。
9）研究。
10）调查问卷。
11）拟人化研究或分析的视频。
在不同的系统工程或需求工程书籍中，列举了很多的相关方需要获取的方法，这些方法适用于不同情况下的需要获取。
表4-4列举了17种需要获取方法，并对不同方法的优缺点进行了简单描述。这些方法在实践中可结合各自的优点进行组合应用。
表4-4 需要获取方法
（续）
《INCOSE系统工程手册》推荐的需要获取方法如图4-9所示。
图4-9 《INCOSE系统工程手册》推荐的需要获取方法
ISO/IEC/IEEE 29148：2011中推荐的需要获取方法如下：
1）结合头脑风暴的结构化研讨会。
2）访谈、问卷调查。
3）环境或工作模式观察（如实践和运动研究）。
4）组织分析技术（如SWOT分析、产品组合）。
5）确定过程和系统基准。
6）技术文件审查。
7）市场分析或竞争系统评估。
8）模拟、原型设计、建模。
（3）相关方需要获取技术选择 在实际工作中，并没有所谓的“正确答案”告诉人们应该选用什么方法来获取相关方的需要，通常会应用到几乎所有的获取技术，或者几种获取技术的组合。在这种情况下，选用什么样的获取技术，主要取决于相关方与需求开发团队之间的领域知识和开发经验。
图4-10来源于IBM的系统工程最佳实践。该图提供了一个框架，用于确定适当的相关方需要获取技术。它在客户/用户体验和开发团队经验方面定义了四个主要类别：模糊问题型、销售/教学型、追赶型和成熟型。
图4-10 相关方需要获取技术的选择
上述指南可以帮助我们选择哪一种方法：
1）追赶型：访谈、在目标环境中工作。
2）模糊问题型：头脑风暴、研讨会。
3）成熟型：问卷调查、研讨会、原型。
4）销售/教学型：原型。
4.开发运行概念文档（OCD）
在开发生存周期概念过程中，“场景”一词经常被用来描述一个单线程的行为；在其他情况下也用来描述许多单线程并发运行的一个超集。场景和“What-if”思维是规划者应对未来运行情况必不可少的工具。
场景技术作为一种战略规划工具，在历史上一直被军事战略家所采用。构建场景作为一种方法，在复杂和不确定的环境中规划和决策。这一活动可以让人们以一种创造性的方式思考、观察各种涌现的情况以减少对重要因素的忽视，构建场景的行为可以促进内部以及组织之间的交流。场景构建本质上是一种人为活动，可能涉及与现有系统/类似系统运营商、潜在终端用户的访谈、一个接口工作组会议（IFWG）。这项活动的结果可以在许多使用建模工具和模拟的图形形式中捕获。
系统的创建或升级，对系统的未来使用和突发性同样具有不确定性。相关方需要和需求定义过程会捕获一系列生存周期概念文件中对相关方需要的理解，每个概念集中在一个特定的生存周期阶段，包括采办概念、部署概念、运行概念（OpsCon）、支持概念、退役概念。
概念文件的主要目标是在系统生存周期的早期捕获需求。通过自由地想象和描述某些过程来理解相关方的需要，但不考虑如何满足需要。它捕获系统在背景环境中与其他系统交互所必需的行为特征，并捕获人与系统交互（系统所必须提供的功能）的方式。了解这些运行过程通常产生：
1）满足客户/用户的需要和目标的特定来源以及派生需求。
2）为系统工程师和设计师定义设计、开发、验证与确认系统提供宝贵的洞察力。
3）减少在移交运营系统中潜在的系统缺陷风险。
概念开发主要的目标是与系统最终用户在早期阶段交流以确保对相关方的需要（特别是运行需要）有清晰的认识，性能需求的理由纳入决策机制，用于后续系统需求以及更低层级规格。现有/相似系统的操作者/潜在用户访谈、交流会、IPO图、功能流框图（FFBD）、时间线图表、N2图提供有价值的相关方输入，建立一个符合相关方需要的概念。
其他目标还包括：
1）提供运行需要和捕获源需求之间的可追溯性。
2）建立需求基础以支持系统整个生存周期，如人员需求、支持需求等。
3）建立验证计划基础、系统级验证需求，以及环境模拟需求。
4）生成业务分析模型，测试系统与其环境之间的外部接口的有效性，包括外部系统的相互作用。
5）提供系统能力计算，为超限的行为以及任务效能计算提供依据。
6）在每一个层级确认需求，从其他来源发掘隐含的被忽视的需求。
（1）运行概念文档（OCD）开发指南
1)建立OCD开发团队。
2）确定参与者——跨学科的团队：
①领导者：由高级系统/需求工程师领导。
②专业领域参与者：
· 运营领域专业人员；
· 所有学科专业人员；
· 系统环境相关领域专业人员。
③不同环节参与者：
· 系统工程师、架构师、系统实现者、测试人员；
· 客户/买家、客户和承包商经理。
④还包括以下参与者：
· 熟悉影响系统的开发和部署监管环境的参与者。
· 具有自然和人工操作环境方面渊博知识的参与者。
3)编写OCD内容。
（2）运行概念文档（OCD）模板
见附录D.2。
5.相关方需求规格说明书（StRS）
相关方需求规格说明（Stakeholder Requirements Specification，StRS）描述组织为什么开发或改变系统的动机，定义在使用系统情况下的流程、策略与规则，从用户的视角描述高层需求，从特定使用环境中派生出使用者、操作者、维护者等相关方准确清晰的需要。业务需求规格说明（BRS）描述业务环境，StRS描述组织如何使用系统为业务带来价值。
StRS的内容由相关方确认，相关方对StRS的内容负责。不存在对所有项目都适用的相关方需求规格说明书，ISO/IEC/IEEE 29148：2018需求工程过程标准提供了相关方需求规格说明书的范例轮廓，见表4-5。
表4-5 ISO/IEC/IEEE 29148：2018标准中的StRS范例轮廓
关于相关方需求规格说明（StRS）各信息项的具体内容，请参考附录D.3。
6.需求评审
（1）需求评审流程
需求评审包含图4-11所示的六个步骤。
图4-11 需求评审过程
1）制定并发布评审计划。首先，需要确定评审人员。评审人员应包括客户、业务需求拥有者、系统工程师与业务分析师、供应商以及解决方案团队，如图4-12所示。确保已经代表了所有相关方类型，即便他们不能参加评审会议，他们所有的观点都必须处理。
图4-12 需求评审团队组成
其次，完成需求评审相关准备工作，包括与需求评审员一起就需求审查日期达成一致、需求评审基线文档准备、需求评审会议准备等工作。
2）出具相关文档。在评审会议前至少两周给相关方需求规格打基线并提供一份需求规格的复印件给评审员。评审员指南有助于审查团队关注关键领域。考虑与这个任务相关的检查清单提供给审稿人。
3）接收并分析变更请求。实际的审查会议的目的是做决策，不审查文档。
鼓励相关方在审查之前提交变更请求(也称为审查项差异或RIDs)，这样他们就可以进行分析，确保理解请求的意图，对相关请求进行分组，并评估变更的影响。
4）执行评审。召开评审会议。简要地概述主要风险和决策依据，目的是做出接受或拒绝评审前提交的每一个变更请求。变更请求也可能会进一步延迟而影响评估或探索性的工作的完成。
一旦决定了对于每个变更请求的结果，评审会议就结束。但是，审查过程将一直持续到所有被接受的变更请求的实现为止。
在评审中，所有关于行动确定、决策和问题识别等都必须有备忘录。
5）实现批准的变更。评审会议后更新相关方需求规范和其他相关文档，将批准的变更合并到其中。
6）结束评审。所有的接受变更请求合并到更新需求规格基线。
问题更新备忘录显示每个变更请求的状态/来自评审的行动项和审查委员会的建议。
相关方需求将会持续改变，然而随着进一步开发工作完成和变更影响范围的增加，需求变更的代价将会更加昂贵。因此需要有一个正式的变更控制过程来管理进一步的更改。
（2）需求评判准则
需求评审准则主要四个方面考虑：评审文档完整性、对需要或需求的满足情况、需求条目与需求集的质量、需要或需求满足的质量。
1）评审文档完整性。评审文档完整性，即发布给评审专家的待评审文档是否完整。完整性主要体现为基线工作文档的完整性，基线工作文档必须包括：
①相关方需求规格说明书。
②生存周期概念文档。
③需求验证与追踪矩阵（RVTM）。
④验证准则，包括MOEs与MOSs。
⑤被识别出的系统功能清单。
⑥相关方需要（备查）。
⑦相关方需要与需求定义过程记录（备查）。
其中，相关方需求规格说明书、生存周期概念文档、需求验证与追踪矩阵（RVTM）、验证准则（包括MOEs与MOSs）是相关方需求评审所需要的最重要的几份文档。
达标准则如下：
①上述移交物完整。
②与相关方需求规格说明书中对应的所有相关方的需要都齐备并且已经经过确认。
③具有正向与逆向的需求验证与追踪矩阵。
2）对需要或需求的满足情况。根据RVTM进行需要或需求满足程度分析。达标准则如下：
①所有的相关方需要都有对应的相关方需求相对应。
②对于不现实或不可行需要的协商过程有记录。
③上一级需求（业务需求）在本层级都有对应相关方需求条目去满足。
3）需求条目与需求集的质量。对于需求条目与需求集的质量的评审，主要通过两个检查单来执行，其一是需求规格说明书检查单，其二是相关方需求规格说明书检查单。
需求规格说明书检查单针对所有的需求规格说明书有效，见表4-6。
表4-6 需求规格说明书检查单
（续）
来源：IBM最佳实践。
对于相关方需求规格说明书的评审，还需要按照表4-7相关方需求规格说明书检查单进行检查。
表4-7 相关方需求规格说明书检查单
（续）
来源：IBM最佳实践。
达标准则如下：
①相关方需求规格说明书按照上述检查表审查后没有不符合项；
②不符合项已经得到纠正。
4）需要或需求满足的质量。需要或需求满足的质量是对需求规格说明书所描述的需求条目对满足需要或者上一级需求的科学性的评价。这需要评审专家团队的专业领域知识来支撑。主要从以下几方面来评价：
①是否集成考虑了法规、环境、交互系统、使能系统、参与者以及威胁因素。
②满足需要或需求的需求条目是否包含了全部可能的情况。
③是否考虑了故障或出错情况下的应对。
④用来满足需要或需求的需求条目是否准确地表达了需要或需求。
⑤用来满足需要或需求的需求条目是否是现有约束条件下最好的表达。
达标准则如下：
上述各方面要素都得到了肯定答案，或者得到了合理的解释。
4.2.5 案例——飞机起落架概念文档
参考《概念文档开发指南》组建概念文档编写团队，使用概念文档模板编写起落架概念文档。在运行概念文档中，核心的内容是要描述清楚系统的运行过程，因此，本章节案例主要以飞机起落架为对象，重点描述起落架的运行过程，其他内容读者可以参考《运行概念文档模板》。
起落架作为飞机在地面停放、滑行、起降滑跑时用于支持飞机重量、方向控制与吸收冲击能量的飞机部件，其主要功用是承受飞机在地面停放、滑行、起飞着陆滑跑时的重力，滑跑与滑行时操纵飞机，滑跑与滑行时的制动，承受、消耗和吸收飞机在着陆与地面接触时的冲击和颠簸能量并吸收飞机运动时产生的冲击载荷。同时因为现代飞机飞行速度很快，起落架可能影响整个飞机的气动外形，所以又提出了可收放需求——当飞机在空中飞行时就将起落架收到机翼或机身之内，以获得良好的气动性能，飞机着陆时再将起落架放下。
（1）确定飞机起落架的使命任务（从飞机分配来的要求）
1）承受飞机在地面停放、滑行、起飞着陆滑跑时的重力。
2）承受、消耗和吸收飞机在着陆与地面接触时的撞击和颠簸能量。
3）滑跑与滑行时的制动。
4）滑跑与滑行时操纵飞机转向。
（2）确定起落架完成上述使命任务的运行阶段 飞机起落架要完成由飞机分配来的使命任务，需要有以下几个运行阶段：
1）飞机停放。
2）起飞滑行。
3）收起落架。
4）放起落架。
5）飞机着陆起落架承载。
6）降落滑行。
7）停放飞机。
（3）确定每一个运行阶段可能的情况 在定义每一个阶段要素的过程中，需要分析起落架在不同阶段的正常运行情况，同时还要结合飞机起落架有史以来在不同阶段可能出现的各种不正常的情况，这需要长期的积累。图4-13所示为飞机起落架各个阶段情况描述。图中的风险与威胁列举了部分可能存在的风险与异常情况，风险与威胁并不一定是系统失效导致的，环境威胁也有可能导致失效。
注意，在这个时候的异常情况描述，只需要描述可能出现的异常现象即可，无须考虑零部件的失效问题。
图4-13 飞机起落架各个阶段情况描述
（4）定义每个阶段每一种情况下的活动 当确定了每个阶段可能存在的不同情况后，接下来需要对每一种可能情况的相应活动进行定义。
活动的定义需要从参与者、输入/输出、运行政策约束、物理环境、互操作系统和社会因素六方面考虑。
注意，每种情况的活动分解只向下分解一层即可，如起落架放下阶段的活动分解如下：
1）起落架可自动放下（正常情况）：
①打开舱门。
②上位开锁。
③放下起落架。
④下位锁定。
⑤反馈状态确认。
然后对上述活动按照参与者、输入/输出、运行政策约束、物理环境、互操作系统和社会因素六方面要素完成定义。
2）起落架不能自动放下（非正常情况1）。当起落架不能自动放下的情况出现时，我们需要考虑进行手动操作，手动操作起落架放下动作的活动如下：
①手动打开舱门。
②手动上位解锁。
③起落架依靠自重落下。
④手动下位锁定。
然后对上述活动按照参与者、输入/输出、运行政策约束、物理环境、互操作系统和社会因素六方面要素完成定义。在定义手动操作的过程中，因为运行环境是高空、高风速，主要的参与者与交互是人，所以在定义相关活动时需要考虑人在这种高空、高风速环境下完成操作的各种需要与条件。
3）起落架不能锁定（非正常情况2）。由于可能存在的非正常情况比较多，本书不再一一列举，有兴趣的读者可以尝试完成其他各种非正常情况的定义。
需要注意：凡是在运行过程中出现过的异常情况，在新系统的概念文档中都必须要有分析与应对，根据其发生的概率制定不同的解决方案，然后对解决方案进行活动分解与定义。
（5）按照运行概念文档模板完成起落架运行概念文档（略）
相关方需要与需求定义过程是一个非常关键的过程，识别完整的相关方与开发运行概念文档是重中之重。
在工程实践中，识别相关方的过程中最容易出现的问题是缺乏对相关方的抽象分类。很多人在实践中发现相关方好像无穷无尽，例如：一条生产线上的所有操作人员其实都是相关方，难道要把这些都列在清单中吗？显然这是不可能的。这个时候需要将其抽象为一类相关方，也就是操作人员，其所有的诉求综合后作为操作人员的需要。类似的还有企业的财务、质量人员等，这些在实际工程中都需要分析与抽象。但是前面所列举的三大类相关方一定要充分考虑。
从目前国内产品型号的工程实践情况来看，对于运行概念文档描述工作的开展非常有限，有些单位做过类似的事情，但都存在不规范的情况，并没有将概念文档开发过程做完。而运行概念文档是用来与用户确认需求最好的手段，同时也是后面从问题与向方案域转换的关键文档。
按照系统工程手册的描述，相关方需要与需求定义过程成功的标准包括以下几方面：
1）新系统的采办已经获得用户组织授权。
2）项目开发组织已经准备好SoW、StRS并获得新系统采办批准。
3）潜在承包商已经响应了采办需要，并提交提案。
4）市场驱动情况下，已经理解消费者想要买什么。
5）在市场与技术驱动情况下，开发团队已经获准开发新系统。
《INCOSE系统工程手册》中的相关方需要与需求定义了过程对应型号研制生存周期中的概念阶段。过程的输入包括立项论证报告，阶段性的输出结果，与项目任务书对应。
在这个过程中，主要完成以下六个方面的工作：
1）确定有哪些相关方。
2）从不同的相关方获取各自的需要，需要考虑采用哪些合适的方法来获取需要。
3）描述系统概念文档，尤其是运行概念文档，充分描述系统完成使命任务时应该怎么做。
4）分析相关方的需要，从相关方的问题描述中获取准确的需求。
5）确定验证准则与MOE。
6）建立需求关联。
相关方需要与需求定义过程非常关键。笔者在与不同科研院所交流的过程中都听到了类似这样的问题——为什么总是问题考虑不全面，需要到后期阶段不断地迭代与返工？这种情况非常普遍，究其根本原因，其实就是在相关方需要与需求定义过程中（即在型号研制的概念阶段）没有完整地定义问题。在这一过程中主要存在几个方面的问题：
1）相关方没有找全，这就是考虑问题不全面的隐患。很多时候只考虑了主要的相关方（比如型号研制项目中的军方）的各种需要与需求。
2）没有完整的概念文档，甚至缺乏概念文档。在笔者接触到的多个科研院所中，绝大多数院所没有完整规范化地描述过概念文档。概念文档中所需要的不同内容，在不同的型号项目中可能都描述过，但是从来没有在一个项目中将这些内容完整地描述过。没有描述的内容，可能就是考虑不全面的地方，后期阶段就可能带来额外的迭代或者返工。