求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
目录
第一部分:SEBoK介绍
SEBoK 简介
系统工程导论
SEBoK 用户和用途
第二部分:系统工程基础
系统基础
系统方法在工程系统中的应用
系统科学
系统思维
用模型表示系统
第三部分:系统工程与管理
系统工程 STEM 概述
基于模型的系统工程 (MBSE)
生命周期过程简介
生命周期模型
概念定义
系统定义
系统实现
系统实施
系统集成
系统验证-1
系统验证-2
系统部署和使用
系统部署
系统操作
系统维护
Logistics
系统工程管理
技术规划
评估和控制
决策管理
风险管理
配置管理
信息管理
质量管理
度量管理
业务和任务分析
业务和任务分析
系统工程标准
相关标准
系统工程标准的应用
系统工程标准的校准与比较
服务的生命周期管理
第四部分:系统工程的应用
产品系统工程
服务系统工程
企业系统工程
Systems_of_Systems(SOS)
医疗系统工程
第五部分:启用系统工程
支持业务和企业执行系统工程
支持团队执行系统工程
支持个人执行系统工程
第六部分:系统工程相关领域
系统工程和环境工程
系统工程和工业工程
系统工程与地理空间/大地测量工程
系统工程和项目管理
系统工程和软件工程
系统工程与质量属性
第七部分:系统工程实施实例
系统工程实施示例:信息系统
系统工程实施示例:防御系统
系统工程实施示例:交通系统
系统工程实施示例:医疗系统
系统工程实施示例:空间系统
系统工程实施示例:管理系统
系统工程实施 : 矩阵示例
 
 
目录
生命周期过程和企业需求
译者:火龙果Alice
88 次浏览
 
 捐助

通用生命周期模型描述了从实现结果的需求到实现新的或修改的工程系统的建议的简单转换。这就形成了在该利益体系(SoI)的生命周期中投入时间、金钱和其他资源的决策基础。这一转变中涉及的SE活动有很大一部分涉及不同级别和类型的需求。

需求和生命周期

在生命周期的概念定义阶段,当企业确定需要的新功能时,业务或任务分析开发反映问题空间观点的高级策略和需求集(可以表示为任务或业务需求)。随着解决方案空间的探索和解决方案类的特征化,开发涉众需求并将其转换为涉众需求(从用户的角度)。在确定了解决方案类并寻求了特定的解决方案之后,在生命周期的系统定义阶段,涉众需求被转换为系统需求(从解决方案的角度)。由于系统定义递归地定义了解决方案的较低级别的细节,需求是用较低的抽象级别定义的。在最高级别上,理想的需求是与实现无关的,因此不是特定于一个解决方案,允许一系列可能的解决方案。在最低的层次上,需求陈述可能变得更加特定于所选的解决方案。

概念定义进一步描述了业务或企业以及涉众的需求和要求。它讨论了如何将业务或企业的新功能定义为理解问题空间的一部分。它还讨论了涉众需求的开发,以及从用户的角度将其转换为需求。

系统定义有对需求及其类型的进一步描述(例如,系统需求、涉众需求、派生需求)。它讨论了不同的过程角色/状态、层次和需求的性质如何应用于对需求的理解。

将企业需求转变为需求

需要和需求可以存在于多个层次上,用于描述这些层次的术语将因应用程序域和服务于它们的企业而不同。这使得将一般的SE生命周期流程与它们关联起来变得困难。Ryan(2013)提出了一个通用模型(见图1),在该模型中,某种类型的企业形成了将战略意图转化为系统定义的焦点。在企业观中,企业领导制定企业战略、概念和计划;一种业务管理视图,在这种视图中,业务管理派生业务需求和约束,并形式化它们的需求;业务操作视图,涉众在其中定义他们的需求和需求。在系统视图中,定义了一个工程系统,如果需要,扩展到系统元素的较低级别的视图。注意,一个工程系统可能包含许多元素,包括产品、人员和过程。可以创建系统体系结构,以定义这些元素如何一起为组织启用所需功能的逻辑和物理视图。

图 1. 将需求转化为需求 (Ryan, 2013) 由 M. Ryan 授予许可。 所有其他权利均由版权所有者保留。

在下面的讨论中,Ryan 进一步定义了一组通用术语来定义需要和要求的级别,并将它们与通用组织角色相关联。 有关此一般描述如何映射到不同应用程序上下文或组织结构的讨论,请分别参见 第 4 部分和 第 5 部分

图 1 中的各种视图称为层。 在最高层,企业有许多指导其未来的战略。 例如,在上面的插图中,系统起源于运营概念(ConOps) 或战略业务计划 (SBP),它传达了领导层关于现有系统和待定系统的组织运营的意图。发达。 在这一层,ConOps 或 SBP 用“品牌”来定义企业,并建立使命宣言和相应的目标和目标,清楚地说明企业前进的原因和战略。

业务或任务分析流程以组织的任务或愿景声明、由 ConOps 或 SBP 传达的目标和目的开始。 业务管理使用此指南来定义业务需求,主要以生命周期概念的形式,捕获业务管理的采购、开发、营销、运营、部署、支持和退役的概念。 然后使用这些概念来定义该层的特定需求。

生命周期概念中包含的业务需求被详细阐述并形式化为业务需求,这些需求记录在业务需求规范 (BRS) 或业务需求文档 (BRD) 中。 将业务需求转化为业务需求的过程称为任务分析或业务分析。

一旦业务管理层满足了他们的需求和要求,他们就会将它们传递给业务运营层。 在这里,利益相关者需求和要求 (SNR) 定义流程使用 ConOps 或 SBP 以及生命周期概念中包含的概念作为指导。 需求工程师 (RE) 或业务分析师 (BA) 通过结构化流程从业务运营层引导利益相关者,以获取利益相关者的需求——以精炼的 OpsCon 或类似文档和其他生命周期概念的形式(参见图 1)。 RE 或 BA 使用结构化流程来引出特定需求,如用户故事、用例、场景、系统概念或操作概念中记录的那样。 如需进一步讨论作战概念和作战概念文件及其相互作用,

然后将利益相关者的需求转化为一组正式的利益相关者要求,这些要求记录在利益相关者要求规范 (StRS) 或利益相关者要求文档 (StRD) 中。 这种转变是由一个定义明确、可重复、严格且记录在案的需求分析过程指导的。 这种需求分析可能涉及使用功能流程图、时间线分析、N2 图、设计参考任务、建模和模拟、电影、图片、状态和模式分析、故障树分析、故障模式和影响分析以及贸易研究。 在某些情况下,这些需求分析方法可以使用作为高级逻辑架构的一部分创建的视图。

在系统层,在系统需求定义过程中,StRS 中的需求然后由 RE 或 BA 转换为 系统需求,并记录在系统需求规范 (SyRS) 或系统需求文档 (SyRD) 中。 与前面的过程一样,RE 或 BA 使用与上述相同的需求分析方法来定义需求,完成需求到需求的转换。 在每一层,产生的需求都将被记录、同意、基线化,并置于配置管理之下。 如上所述,系统需求分析也可以链接到适当的逻辑和物理架构,非正式地或在共享配置控制下。 请注意,一些组织可能会为为满足业务需求而开发的多个系统中的每一个系统准备单独的生命周期概念。

一旦一组需求在一个层被记录、同意和基线化,它们将向下传递到下一层,如图 1 所示。在下一层,需求是需求转换过程的结果在该层以及从前一层的需求分解或派生的结果。 因此,许多 SyRS 或 SyRD 要求可以从 StRS 或 StRD 分解(即,由其要求明确)或衍生(即,由其要求隐含)。 在子系统或系统元素层也是如此,其中许多子系统或系统元素需求可以分解或从 SyRS 或 SyRD 派生。 在所有情况下,对于图 1 所示的每一层, 这组需求可以追溯到分解或派生它们的前一层的需求。 这个过程继续到下一层系统元素。

需求的表达方式因这些层而异,因此表达它们的规则也不同。 随着需求的开发——以及解决方案的设计——通过抽象层,我们期望需求陈述变得越来越具体。 在最高级别上,理想的要求并不特定于特定的解决方案,而是允许一系列可能的解决方案。 在最低级别,需求陈述将完全针对所选解决方案。 需要注意的是,某一层的需求形式可能不适用于另一层。 例如,在业务管理层,可能要求所有产品都是“安全的”。 虽然这是一个糟糕的系统要求,但它适用于业务管理层。 在下一层,业务运营, 定义“安全”的要求会更少,更详细。 这些要求适用于所有产品线。 在系统层,将为该特定系统制定更具体的安全要求。 然后,这些要求将分配给下一个较低层的系统元素。


您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



88 次浏览
 捐助
欢迎参加课程:
MBSE(基于模型的系统工程)
系统思维与系统工程
系统工程方法与实践