系统需求是系统级别 的所有需求, 描述了系统作为一个整体应满足利益相关者需求的功能,并以文本陈述、视图和非功能性需求的适当组合来表达; 后者表示必要的安全、安保、可靠性等水平。
系统需求在系统工程中扮演着重要角色,因为它们:
- 形成系统架构和设计活动的基础。
- 形成系统 集成 和 验证 活动的基础。
- 作为 验证和利益相关者接受的参考。
- 在整个项目中进行交互的各种技术人员之间提供一种沟通方式。
利益相关者需求的引出从 概念定义开始,最初将通过访谈和任务分析进行开发。在系统定义 期间会详细考虑系统需求 。 在实现两者之间的一致性之前,两者都不能被认为是完整的,正如可追溯性所证明的那样,可能需要多次迭代。
需求的定义和目的
需求是识别产品或过程操作、功能或设计特征或约束的声明,它是明确的、可测试的或可测量的,并且对于产品或过程的可接受性是必要的(ISO 2007)。
为避免与需求有关的众多术语混淆,请考虑以下分类:
- 过程角色或状态 :需求在定义过程中扮演的角色; 例如,它在系统块中的位置(例如,已翻译、派生、满意)或其协议状态(例如,建议、批准、取消)。
- 抽象级别 :需求所代表的定义过程中的级别; 例如,利益相关者需求、系统需求、系统元素需求。
- 需求类型 :需求本身的性质; 例如,功能、性能、约束等。
任何单个需求可能同时处于特定状态、特定抽象级别和特定类型。 有关需求类型之间差异的更多说明,请参阅(Martin 1997,第 2 章)。
管理系统需求的原则
与利益相关者需求和逻辑架构的关系
一组 利益相关者的需求 被澄清,并从需求陈述翻译成面向工程的 语言,以实现适当的架构定义、设计和验证活动,这些活动是系统需求分析的基础。
系统需求基于对与性能和其他质量测量相关的任何解决方案系统所需功能的识别和综合,并为评估候选解决方案和验证完整系统提供基础。 系统需求以对架构和设计有用的 技术语言表达:明确、一致、连贯、详尽和可验证。 当然,与利益相关者密切协调是必要的,以确保翻译准确并保持可追溯性。 这导致了一组系统功能和需求,这些功能和需求指定了可测量的特性,这些特性可以形成系统实现的基础。
逻辑架构 定义了 系统边界和功能,从中可以得出更详细的系统需求。 这个过程的起点可能是从利益相关者需求中识别功能需求,并以此开始架构定义,或者从高级功能架构视图开始,并将其用作构建系统需求的基础。 所采用的确切方法通常取决于系统是已经了解的产品或服务的演变,还是新的和前所未有的解决方案(请参阅 综合可能的解决方案)。 然而,当流程启动时,重要的是利益相关者需求、系统需求和逻辑架构都是完整的、相互一致的,并且在系统生命周期模型中的适当点上一起评估。
架构和设计期间的可追溯性和系统需求分配
需求可追溯性提供了跟踪信息的能力,从利益相关者需求的来源,到顶层需求和系统层次结构中所有级别的其他系统定义元素(请参阅 应用生命周期过程)。 在提出工程改进或变更请求的情况下执行影响分析时,可追溯性还用于提供对变更程度的理解作为输入。
在体系结构定义和设计期间,可以使用多种方法在系统层次结构中将需求从一个级别分配到较低级别,视情况而定 - 参见表 1。
表 1. 系统需求的评估类型。 (SEBoK 原创)
系统需求的分配类型 | 描述 |
直接分配 |
来自较高级别的系统需求直接分配给较低级别的系统或系统元素(例如,用于绘制产品可见部分的颜色)。 |
间接赋值(简单分解) |
系统需求分布在多个系统或系统元素上,更复杂的分配计算之和等于具有足够余量或容差的更高级别的需求(例如,质量需求、功率分配、可靠性分配等)。 必须维护每个任务的记录和配置管理的“任务预算”。 |
间接赋值(建模和分解) |
使用分析或数学建模技术将系统需求分布到多个系统或系统元素。 将得到的设计参数分配给适当的系统或系统元素(具有适当的余量)。 例如,在分析雷达检测需求的情况下,输出功率、波束大小、频率等这些较低级别的参数将分配给适当的硬件和软件元素。 同样,必须记录分析(或模型)并进行配置管理。 |
派生需求(来自设计) |
此类系统需求是在设计活动期间根据设计团队而非利益相关者社区的决定而制定的。 这些需求可能包括使用商业现货 (COTS) 项目、库存中的现有系统或系统元素、通用组件和类似的设计决策,以便为客户提供“最佳价值”解决方案。 因此,这些派生的需求可能不会直接追溯到利益相关者需求,但它们不会与利益相关者需求或约束相冲突。 |
系统需求分类
根据需求定义方法和/或所应用的体系结构和设计方法,系统需求的几种分类是可能的。 (ISO 2011) 提供了表 2 中总结的分类(有关其他分类,请参见参考资料)。
表 2. 系统需求分类示例。 (SEBoK 原创)
系统需求类型 | 描述 |
功能需求 |
定性地描述运行中要执行的系统功能或任务。 |
性能需求 |
定量地定义功能或任务的执行范围,或多好以及在什么条件下执行(例如速率、速度)。 这些是系统性能的定量需求,可以单独验证。 请注意,可能有多个性能需求与单个功能、功能需求或任务相关联。 |
可用性需求 |
定义系统使用的质量(例如可衡量的有效性、效率和满意度标准)。 |
接口需求 |
定义系统需要如何与外部系统交互或交换材料、能量或信息(外部接口),或系统内的系统元素(包括人为元素)如何相互交互(内部接口)。 接口需求包括与支持交互或交换的外部系统或内部系统元素的物理连接(物理接口)。 |
操作需求 |
定义系统运行或存在所需的运行条件或属性。 这种类型的需求包括:人为因素、人机工程学、可用性、可维护性、可靠性和安全性。 |
模式和/或状态需求 |
定义正在使用的系统的各种操作模式和进行模式转换的事件。 |
适应性需求 |
定义系统生命周期内的潜在扩展、增长或可扩展性。 |
物理约束 |
定义适用于构成系统的系统元素的重量、体积和尺寸约束。 |
设计约束 |
通过施加不可移动的边界和限制来定义解决方案设计者可用选项的限制(例如,系统应包含遗留或提供的系统元素,或某些数据应保存在在线存储库中)。 |
环境条件 |
定义系统在其不同操作模式下遇到的环境条件。 这应解决自然环境(例如风、雨、温度、动物群、盐分、灰尘、辐射等)、诱发和/或自诱发环境影响(例如运动、冲击、噪声、电磁、热等) ,以及对社会环境的威胁(例如法律、政治、经济、社会、商业等)。 |
后勤需求 |
定义系统持续使用所需的后勤条件。 这些需求包括保障(提供设施、水平支持、支持人员、备件、培训、技术文件等)、包装、装卸、运输、运输。 |
政策法规 |
定义可能影响系统运行或性能的相关和适用的组织政策或监管需求(例如劳工政策、向监管机构的报告、健康或安全标准等)。 |
成本和进度限制 |
例如,定义系统单个样本的成本、第一个样本的预期交付日期等。 |
需求管理
执行需求管理以确保系统和系统元素需求与系统的其他表示、分析和工件保持一致。 它包括提供对需求的理解、获得承诺、管理变更、维护需求之间以及与系统定义的其余部分的双向可追溯性,以及与项目资源和进度保持一致。
有许多工具可用于为需求管理提供支持基础设施; 最好的选择是与项目或企业的流程相匹配的。 需求管理还与基线管理和控制的配置管理密切相关。 当需求被定义、记录和批准后,需要将它们置于基线管理和控制之下。 基线允许项目分析和了解正在进行的提议变更的影响(技术、成本和进度)。
过程方法
方法的目的和原则
系统需求分析过程的目的是将所需服务和属性的利益相关者、面向用户的视图转换为满足用户操作需求的产品技术视图。 这个过程构建了一个系统的表示,它将满足利益相关者的需求,并且在限制允许的情况下,并不意味着任何特定的实施。 它产生了可测量的系统需求,从供应商的角度指定了它必须具备哪些性能和非性能特征才能满足利益相关者的需求(ISO 2015)。
进程的活动
在此过程中的主要活动和任务包括:
- 分析利益相关者的需求,以检查预期服务和操作场景、条件、操作模式和约束的完整性。
- 定义系统需求及其基本原理。
- 使用建议的分类对系统需求进行分类(参见上面的示例)。
- 将派生的需求(来自架构和设计)合并到系统需求基线中。
- 建立与利益相关者需求和需求的向上可追溯性。
- 在系统层次结构的相邻级别的需求之间建立双向可追溯性。
- 验证每个系统需求的质量和完整性以及系统需求集的一致性。
- 根据一组利益相关者需求验证每个系统需求的内容和相关性。
- 识别 系统需求可能产生的潜在风险(或威胁和危害)。
- 综合、记录和管理系统需求和潜在的相关风险。
- 在批准需求后,建立控制基线以及其他系统定义元素以及已建立的配置管理实践。
检查系统需求的正确性
应检查系统需求以衡量它们是否表达得很好和适当。 有许多特征可用于检查系统需求,例如标准的同行评审技术以及将每个需求与一组需求特征进行比较,这些在“需求的呈现和质量”的表 2 和表 3 中列出" 部分(下)。 可以使用“方法和建模技术”(下文)部分中描述的需求获取和基本原理捕获来进一步验证需求。
方法和建模技术
需求获取和原型设计
需求启发需要用户参与,并且可以有效地获得利益相关者的参与和支持。 质量功能部署 (QFD) 和原型设计是可以应用并在本节中定义的两种常见技术。 此外,访谈、焦点小组和 Delphi 技术经常被用于引出需求。
QFD 是一种强大的技术,可以引出需求并将设计特征与用户需求进行比较(Hauser 和 Clausing 1988)。 QFD 应用程序的输入是用户需求和操作概念,因此用户参与至关重要。 应包括整个生命周期的用户,以确保用户需求的所有方面都得到考虑和优先考虑。
早期原型设计可以帮助用户和开发人员以交互方式识别功能和操作需求以及用户界面约束。 这可以实现真实的用户交互、发现和反馈,以及一些敏感性分析。 这提高了用户对需求的理解,增加了满足他们实际需求的可能性。
捕获需求原理
将利益相关者需求转化为系统需求的一种强大且具有成本效益的技术是捕获每个需求的基本原理。 需求基本原理只是关于需求存在的原因、所做的任何假设、相关设计研究的结果或任何其他相关支持信息的陈述。 这支持进一步的需求分析和分解。 基本原理可以直接在需求数据库中获取(Hull、Jackson 和 Dick 2010)。
这种方法的一些好处包括:
- 减少需求总数 - 该过程有助于识别重复项。 减少需求数量将降低项目成本和风险。
- 早期暴露不良假设
- 删除设计实现 ——许多写得不好的利益相关者需求是变相的设计需求,因为客户有意或无意地指定了一个候选实现。
- 改善与利益相关者社区的沟通 ——通过捕获所有利益相关者需求的基本原理,用户和设计人员之间的沟通渠道得到了极大的改善。 (改编自 (Hooks and Farry 2000) 的第 8 章)。
建模技术
当需求必须详细或细化时,或者在涉及利益相关者需求定义和任务分析期间未考虑的主题时,可以使用的建模技术包括:
- 状态图模型(ISO 2011,第 8.4 节)
- 场景建模(ISO 2011,第 6.2.3.1 节)
- 仿真、原型制作(ISO 2011,第 6.3.3.2 节)
- 质量功能部署(INCOSE 2011,第 83 页)
- 系统建模语言 (SysML) 序列图、活动图、用例、状态机图、需求图 (OMG 2010)
- 操作场景的功能流程图(Oliver、Kelliher 和 Keegan 1997)
需求的呈现和质量
通常,需求以文本形式提供。 存在编写良好需求的指南; 它们包括关于需求陈述的语法、措辞(排除、概念的表示等)和特性(具体、可测量、可实现、可行、可测试等)的建议。 请参阅(INCOSE 2011,第 4.2.2.2 节)和(ISO 2011)。
需求和需求集都有几个特征,用于帮助开发和验证需求在解决方案中的实现。 表 3 提供了单个需求的特性列表和描述,表 4 提供了一组需求的特性列表和描述,改编自(ISO 2011,第 5.2.5 和 5.2.6 节)。
表 3. 个别需求的特征。 (SEBoK 原创)
特征 | 描述 |
必要的 |
需求定义了基本能力、特性、约束和/或质量因素。 如果不包含在需求集中,则将存在能力或特性的缺陷,无法通过实施其他需求来满足 |
合适的 |
需求的具体意图和详细程度与其所指的实体的级别(抽象级别)相适应。 这包括避免对架构或设计进行不必要的限制,以帮助确保实现的独立性尽可能 |
明确的 |
需求以这样的方式陈述,以便只能以一种方式解释 |
完全的 |
需求充分描述了满足实体需求所需的能力、特征、约束或质量因素,而不需要其他信息来理解需求 |
单数 |
需求应说明单一的能力、特性、约束或质量因素 |
可行的 |
该需求可以在具有可接受风险的实体约束(例如,成本、进度、技术、法律、监管)内实现 |
可验证 |
需求的结构和措辞使得它的实现可以在需求存在的水平上得到客户满意的证明(验证) |
正确的 |
需求必须是对其转化的实体需求的准确表示 |
符合 |
个别需求应符合批准的标准模板和写作需求的风格(如适用) |
注意:一些来源认为可追溯性是一种特性(ISO 2011)。 然而,最近的观点是,可追溯性实际上是需求的一个属性。 也就是说,附加到需求的东西,而不是需求的内在特征(INCOSE 2011)。 可追溯性特征或属性被定义为: 需求可向上追溯至特定的书面利益相关者需求声明、更高层次的需求或其他来源(例如,贸易或设计研究)。 该需求还可以向下追溯到较低层需求规范或其他系统定义工件中的特定需求。 也就是说,需求的所有父子关系在跟踪中被识别,以便需求跟踪到它的源和实现。
表 4. 一组需求的特征。 (SEBoK 原创)
特征 | 描述 |
完全的 |
需求集是独立的,因此它充分描述了满足实体需求所需的能力、特征、约束和/或质量因素,而无需其他信息。 此外,该集合不包含任何待定义(TBD)、待指定(TBS)或待解决(TBR)子句。 |
持续的 |
需求集包含独特的、不与集合中的其他需求冲突或重叠的单个需求,并且它们使用的单位和度量系统是同质的。 需求集中使用的语言是一致的,即在整个需求集中使用相同的词来表示相同的事物。 |
可行的 |
需求集可以在具有可接受风险的实体约束(例如,成本、进度、技术、法律、监管)内实现。 (注:可行包括“负担得起”的概念。) |
可理解的 |
这套需求的编写必须清楚地说明实体的期望及其与其所属的系统的关系。 |
可以通过验证 |
必须能够证明需求集将导致在约束(例如成本、进度、技术、法律和法规遵从性)内实现实体需求。 |
表格中的需求
可以在表格中提供需求,特别是在为系统或系统元素指定一组参数时。 提供标准表格模板是一种很好的做法。 对于表,以下约定适用:
- 调用需求集中明确指向该表的每个需求表。
- 用唯一的标题和表号标识每个表。
- 在表格标题中包含“需求”一词。
- 在紧接其前的文本中确定表格的用途,并解释如何阅读和使用表格,包括上下文和单位。
- 对于独立因变量情况,以最适合信息使用的方式组织表格。
- 每个单元格最多应包含一个需求。
流程图中的需求
流程图通常包含图形形式的需求。 这些需求可能包括必须纳入系统的逻辑、操作需求、过程或程序需求,或由一系列相互关联的步骤以图形方式最佳定义的其他情况。 对于流程图,以下约定适用:
- 在明确指向流程图的需求集中调用流程图。
- 用唯一的标题和图号标识每个流程图。
- 在流程图的标题中包含“需求”一词。
- 在流程图中清楚地指出和解释代表需求的独特符号。
图纸需求
图纸还提供了定义需求的图形方式。 图纸中定义的需求类型取决于图纸的类型。 以下约定适用:
- 当图纸可以帮助描述以下内容时,请使用图纸:
- 在明确指向图纸的需求集中调用图纸。
工件
此过程可能会创建多个工件,例如:
- 系统需求文件
- 系统需求证明文件(用于可追溯性目的)
- 系统需求数据库,包括可追溯性、分析、基本原理、决策和属性(如适用)。
- 系统外部接口需求文档(该文档描述了系统的接口与其使用环境的外部元素;接口需求可以集成或不集成到系统需求文档中。
这些工件的内容、格式、布局和所有权将根据创建它们的人以及它们将在哪个域中使用而有所不同。 在它们和过程的输出之间,活动应该涵盖本文第一部分中确定的信息。
关于系统需求的实际考虑
如表 5 中所讨论的,有几个 缺陷 会抑制一组最佳系统需求的生成和管理。
表 5. 系统需求定义的主要缺陷。 (SEBoK 原创)
缺陷 | 描述 |
对利益相关者需求的分析不充分 |
如果利益相关者需求的接收者没有对它们进行足够的批判性分析,那么后果可能是难以将它们转化为系统需求以及返回给利益相关者的义务,从而浪费时间。 |
运营模式和场景分析不充分 |
编写系统需求的负责人没有对运行模式和运行场景进行充分分析或定义。 这些元素允许在工程过程的早期构建系统及其使用,并帮助设计人员记住功能和接口。 |
系统需求不完整 |
如果系统需求不够精确和完整,则设计可能无法达到预期的质量水平,并且系统的验证和确认将被延迟。 |
缺乏验证方法 |
延迟捕获每个系统需求的验证方法和事件; 对每个需求的验证方法的识别通常会为需求本身的正确性和必要性提供额外的洞察力。 |
缺少可追溯性 |
每个需求的可追溯性不正确或缺失,无论是对上层“父”需求还是对不适当系统或系统元素的分配。 |
表6 中 经过验证的实践 已被反复证明可以降低项目风险和成本,提高客户满意度,并产生成功的系统开发。
表 6. 经验证的系统需求实践。 (SEBoK 原创)
实践 | 描述 |
让利益相关者参与 |
尽早让利益相关者参与系统需求开发过程。 |
基本原理的存在 |
捕获每个系统需求的基本原理。 |
始终在开始前完成 |
在开始定义系统需求之前,尽可能检查利益相关者需求是否完整。 |
同行评审 |
与适用的主题专家一起组织对系统需求的同行评审。 |
建模技术 |
使用上述部分中所述的建模技术。 |
需求管理工具 |
考虑使用需求管理工具,尤其是对于更复杂的项目。 该工具应该能够跟踪系统需求之间的联系以显示关系。 需求管理工具旨在促进和支持整个项目生命周期中系统需求的系统管理。 |
需求工程办法 |
使用典型的需求工程度量; 如需更多信息,请参阅系统工程领先指标指南 (Roedler 等人,2010 年)。 过程和产品测量都应该用于需求工程。 为了获得所需的洞察力以促进风险管理的需求工程,可能需要根据需求的信息需求(风险、目标、问题)使用一种以上的度量。 有用的措施包括:
- 需求波动
- 需求趋势
- 需求验证进度(计划与实际)
- 需求验证进度(计划与实际)
- 每个计划的 TBD 和 TBR 关闭
- 同行评审缺陷
|
|