内容发布更新时间 : 2024/5/20 17:32:46星期一 下面是文章的全部内容请认真阅读。
典型的工作产品
1. 衍生需求 2. 产品需求 3. 产品组件需求
子实践
1. 以专业术语开发产品与产品组件设计的需求。
针对产品架构设计所需的重要的产品质量和绩效，开发架构需求。 2. 由设计决策衍生需求。
有关开发解决方案以产生其他衍生需求，请参考技术解决方案过程域，以获得更多信息。.
技术的选用会引进其他的需求。例如：运用电子学将增加特定技术的需求，如电磁干扰的界限。
3. 建立并维护需求间的关连性，并考量在变更管理和需求配置时的影响。
有关维护需求追溯，请参考需求管理过程域，以获得更多信息。需求间的
关连有助于评估变更的影响。
SP 2.2
分配产品组件需求
为每个产品组件分配需求。 有关配置需求到产品和产品组件，请参考技术解决方案过程域，以获得更多信息。本执行方法提供信息以定义需求配置，但必须和技术解决方案过程域的执行方法互动，以建立配置需求的解决方案。
上述中所定义的解决方案，其产品组件的需求，包括所配置的产品绩效、设计限制，以及符合需求和有助于生产的合适、形式及功能。假使较高阶需求的指定绩效归属于两组或以上的产品组件时，该绩效必须进行切割，并单独配置到各个产品组件，就像是衍生需求一样。 .
典型的工作产品
1. 需求配置表 2. 暂时性的需求配置 3. 设计限制 4. 衍生需求
5. 衍生需求间的关系细部执行方法
子实践
1. 分配需求于功能。 2. 分配需求于产品组件。 3. 配置设计限制于产品组件。
4. 记录已配置需求间的关系。
关系包括依赖性，在这情境下，某需求的改变可能会影响其他的需求。
SP 2.3
识别接口需求
识别接口需求。 定义功能之间(或对象之间)的接口。功能接口可能衍生出替代方案的开发，替代方案在技术解决方案过程域中描述。
有关接口管理以及产品和产品组件的整合，请参考产品整合过程领域，以获得更多信息。
定义产品架构中所识别之产品与产品组件间的接口需求，并将它们当做产品与产品组件整合的一部分来管制，它们也是架构定义中不可缺少的部分。
典型的工作产品
1. 界面需求
子实践
1. 识别产品内部及外部的接口(例如：功能分割或对象之间的接口)。.
在设计工作进行的过程中，产品架构可能受技术解决方案过程的影响，而产生产品组件和项目外部组件间的新接口。 必须识别产品有关的生命周期过程的接口。
与测试设备、传输系统、支持系统及制造设施之间的接口，都属于这类接口。.
2. 开发已识别界面的需求。
有关在设计过程中，如何产生接口需求，请参考技术解决方案过程域，以获得更多信息。
例如以软件的来源、目的地、刺激及数据特征，和硬件的电子及机械的特征，来定义接口需求。
SG 3
分析并确认需求
对需求进行分析和确认，开发需求功能性的定义。 「分析并确认需求」特定目标的特定执行方法，支持「开发客户需求」和「开发产品需求」两个特定目标的需求开发过程。本特定目标的特定执行方法涵盖需求的分析，以及确认需求是否符合使用者预期。
执行分析，以决定为求满足关键人员的需要、期望、限制及接口，对原计划的操作环境会产生哪些影响。视产品的范围而定，可行性、任务需要、经费限制、市场潜力及采购策略等都必须纳入考量，并建立必要功能的定义。所有产品的特定使用形式均应考量，并产生对时间敏感的功能顺序的时间点分析。 分析的目的，在于决定可满足关键人员需要、期望及限制的产品概念的可能需求，再将这些概念转换为需求。与此活动同时进行的是，依据客户的输入和初步的产品概念，决定用以评估产品有效性的参数。
确认需求，以增加最终产品在使用环境中，可按照期望运作的可能性。
SP 3.1
建立操作概念和相关的场景
建立和维护操作概念和相关的场景。 场景一般而言是指使用产品时可能发生的事件顺序，以明确说明关键人员的某些需要。相对的，产品的操作概念通常是依据设计方案和场景而来。例如：卫星的通讯产品与地面的通讯产品，它们的操作概念是不同的。在研拟原始操作概念时，其替代方案通常尚未定义。所以，在需求分析时，开发概念性的解决方案。在进行解决方案的决策时，细化操作概念，进而开发出细部的需求。 正如某产品的设计决策可能变成产品组件需求，操作概念也可能变成产品组件的场景(需求)。开发操作概念及场景逐步开发，以利产品组件解决方法的选择，使得在实作后将满足产品的预期使用。不管哪一种工程，操作概念及场景描述了产品组件与环境、用户，及其他产品组件的互动关系。包括营运、产品推展、交付、支持（含维护及营运）、训练、处置，以及所有的模式和状态等相关的操作概念与场景，都应予以描述。
如果操作顺序用以表达客户需求而非操作概念，则场景可能包含了操作顺序。
典型的工作产品
1. 操作概念
2. 产品或产品组件安装、操作、维护及支持概念 3. 销毁概念 4. 使用案例 5. 依时间演化的场景 6. 新需求细部执行
子实践
1. 开发操作概念和场景，包括适当的功能、绩效、维护、支持及销毁。
识别并开发场景，此场景须与关键人员各细部层级的需要、预期及限制一
致。经此建议的产品或产品组件应可如预期运作。. 2. 定义产品或产品组件的操作环境，包括界限和限制。 3. 审查操作概念和场景，以细化需求并发现新需求。
操作概念和场景的开发是个反复的过程。应定期举行审查，以确保其结果与需求一致。审查可采用逐步审查的形式。
4. 产品与产品组件一经选定，就开发详细的操作概念，以定义产品、最终用
户及环境的互动，并满足操作、维护、支持及销毁的需要。
SP 3.2
建立必要的功能定义
建立和维护需求的功能性的定义。 功能的定义，也就是所谓的“功能分析”，描述哪些是产品预期该做的，包括，行动、顺序、输入、输出，或其他说明如何使用产品的信息。
功能分析与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。在面向对象的软件设计里，它相当于定义所谓的服务或方法。功能、功能的逻辑群组，以及它们和需求的关连的定义，就是所谓的「功能架构」。有关「功能架构」的定义，请参见词汇。
典型的工作产品
1. 功能架构 2. 活动图和使用案例
3. 面向对象分析和已识别的服务或方法细部执行方法
子实践
1. 分析和量化最终用户需要的功能.
2. 分析需求，以识别逻辑或功能分割(如子功能)。
3. 依已建立的准则(如类似的功能、绩效或耦合)，将需求分割成群组，以促
进和专注于需求分析。 4. 在产品开发的整个过程，考量具有时效性的功能的顺序。
5. 分配客户需求于功能分割、对象、人员或支持组件，以支持解决方案的综
合。 6. 分配功能及绩效需求于功能及子功能。
SP 3.3
分析需求
分析需求，以确保其必要性和充分性。
在操作概念和场景的说明下，分析在产品架构某一阶的需求，以决定其是否必要且可满足较高阶的目标。经过分析的需求就变成产品架构中较低阶需求的基础，而较低阶的需求通常是更详细且精准的。
定义需求时，必须能了解它与更高阶需求和已定义功能的关系。决定应识别哪些需求，以追踪技术的进展，也是重要的行动之一。例如：在整个开发过程，产品的重要性或软件产品的规模大小，可依其风险程度加以监控。
有关用于支持此分析的验证方法，请参考验证过程域，以获得更多信息。 典型的工作产品
1. 需求缺陷报告
2. 用来解决缺陷的需求变更建议 3. 关键需求
4. 技术绩效度量细部执行方法
子实践
1. 分析关键人员的需要、期望、限制及外部接口，以移除矛盾，并汇整成相
关主题。 2. 分析衍生需求，以决定是否满足更高阶需求的目标。
3. 分析需求，以确保是完整、可行、可实现及可验证的。
虽然设计决定某特殊解决方案的可行性，本细部执行方法可以了解哪些需求会影响可行性。.
4. 识别对成本、时程、功能、风险或绩效有重大影响的关键需求。 5. 识别技术绩效度量，以便于开发阶段时进行追踪。
有关度量的用途，请参考度量与分析过程域，以获得更多信息。
6. 分析操作观念及场景，以细化客户需要、限制及接口，并发现新需求。
此分析可能产生更详细的操作观念及场景，同时也衍生新需求。
SP 3.4
分析需求以取得平衡
分析需求以平衡相关干系人的需求和约束。 关键人员的需要和限制，可说明成本、时程、绩效、功能、再使用的组件、维护能力，或风险。
典型的工作产品
1. 需求相关风险的评估细部执
子实践
1. 使用经验证的模型、仿真及原型等，以分析关键人员的需要和限制间的平
衡。.
分析的结果，可用以降低产品的成本与开发产品时的风险。 2. 执行需求及功能架构的风险评估。
有关执行客户及产品需求和功能架构的风险评估，请参考风险管理过程域，以获得更多信息。.
3. 检查产品生命周期概念，以分析它对需求风险的影响或冲击。
SP 3.5
确认需求
确认需求，以确保将要产生的产品能在预期的用户环境中运行。 在开发工作的初期，与最终使用者执行需求确认，俾使需求能够引导开发工作，并导致成功的最终确认的信心。此活动应与风险管理活动整合。成熟的组织，通常会以更复杂的方式使用多种技术来执行需求确认，扩大确认的基础，以包括其他的关键人员需要和期望。这些组织通常会使用分析、模拟或原型等方法，以确保需求满足关键人员的需要和期望。