论文部分内容阅读
利益攸关者需求定义流程的目的是在特定的环境下，定义能够向用户和其他利益攸关者提供所需服务的系统的需求。
这一流程识别贯穿于系统生命周期所涉及的系统利益攸关者或利益攸关者的级别及其需要、期望和愿望。该流程对上述内容进行分析并将其转换成利益攸关者的一系列公共需求，这一系列公共需求表达系统将要与其运行环境的预期互动，并作为确认每个产生出来的运行服务所依据的参照。几乎完全达成共识的是成功的项目取决于满足利益攸关者/客户的需要和需求。
成功的项目取决于满足利益攸关者/客户的需要和需求，关于这一点已几乎完全达成共识。利益攸关者是对系统拥有合法利益的任何实体（个人或组织）。典型的利益攸关者包括用户、运行者、组织决策者、协议方、法规机构、开发代理、保障组织以及大到社会。当不可能直接接触时，系统工程师找到如市场营销或非政府组织等代理，以表达对某一利益攸关者阶层（如消费者或未来新生代）的关心。利益攸关者的需求支配着系统的开发，并且是进一步定义或明确开发项目范围的一个基本的因素。如果一个组织正在采办这一系统，该流程在协议中为可交付物的技术描述提供基准——以系统级规范和系统边界定义的接口为典型的形式。图1 是该流程的背景环境图。
利益攸关者需求定义流程包含以下活动：
" 引出利益攸关者需求
–识别贯穿于系统全生命周期内对其感兴趣的利益攸关者。
–引出需求——系统必须实现的内容及达到的程度。
" 定义利益攸关者需求
– 定义由协议或与遗留使能系统的接口所强加的约束。
– 构建场景以定义方案文件;预见的系统产品使用范围;预期的运行环境;以及接口系统、平台或产品。场景有助于识别有可能被忽略的需求。社会和组织的影响亦从使用这些场景中显露出来。
– 建立关键的和期望的系统性能——对系统成功至关重要的以及系统所期望的但为满足关键参数可能被折中的系统性能参数的阈值和目标值。
– 建立MOE和适用性——反映客户/用户的总体满意度（如性能、安全性、可靠性、可用性、可维护性和工作负载需求）的指标。
" 分析和维护利益攸关者需求
– 分析需求的清晰性、完整性和一致性。
– 协商修改以解决无法实现的或不切实际的需求。
– 为历史或归档目的，确认、记录和维护贯穿于系统生命周期之内以及超越系统生命周期之外的利益攸关者需求。
– 建立和维护可追溯性矩阵以文件化正式需求是如何用于满足利益攸关者的目标并获得利益攸关者的同意的。
常用方法和技巧：
" 开发用户群体的描述以提供工作期间的共同理解并确认场景的合适性。用户描述可覆盖产品将要销售给的人群，或被指派部署系统或从系统运行中受益的特定人员的类别。
" 一旦建立利益攸关者的需求，就将这些需求正式地置于构型控制之下。
" 在系统工程师与利益攸关者之间建立良好的关系和开放的交流，这在开始细化和明确一系列需求的协商时是有帮助的。
" 识别所有利益攸关者。至关重要的是在该流程中识别和包含关键的系统利益攸关者，包括开发/设计团队。
" 避免设计一个最终的解决方案或避免建立对该解决方案的不具正当理由的约束。
在ISO/IEC 15288：2008背景环境中，需求在其中的两个技术流程（即利益攸关者需求定义和需求分析）中被特别提到，并且是许多系统生命周期流程的驱动因素。依托系统开发模型，利益攸关者需求的捕获应按照常理在开发周期将要开始的时候进行一次或作为一个持续的活动来开展。无论如何，引出和分析需求的原因是相同的——理解利益攸关者的需要以足够好地支持架构设计流程。
该活动中的最大挑战之一是识别引出该需求的一系列利益攸关者。客户和最终用户相对容易识别，但亦应看到或听到在所感兴趣之系统的结果中获利的管理机构及其他感兴趣的各方。利益攸关者可包括互操作系统和使能系统本身，因为这些系统通常会强加需要被识别和考虑的约束。在可持续的开发中，这包括寻找新生代的代表。图2阐明了潜在利益攸关者的范围。
这一流程识别贯穿于系统生命周期所涉及的系统利益攸关者或利益攸关者的级别及其需要、期望和愿望。该流程对上述内容进行分析并将其转换成利益攸关者的一系列公共需求，这一系列公共需求表达系统将要与其运行环境的预期互动，并作为确认每个产生出来的运行服务所依据的参照。几乎完全达成共识的是成功的项目取决于满足利益攸关者/客户的需要和需求。
成功的项目取决于满足利益攸关者/客户的需要和需求，关于这一点已几乎完全达成共识。利益攸关者是对系统拥有合法利益的任何实体（个人或组织）。典型的利益攸关者包括用户、运行者、组织决策者、协议方、法规机构、开发代理、保障组织以及大到社会。当不可能直接接触时，系统工程师找到如市场营销或非政府组织等代理，以表达对某一利益攸关者阶层（如消费者或未来新生代）的关心。利益攸关者的需求支配着系统的开发，并且是进一步定义或明确开发项目范围的一个基本的因素。如果一个组织正在采办这一系统，该流程在协议中为可交付物的技术描述提供基准——以系统级规范和系统边界定义的接口为典型的形式。图1 是该流程的背景环境图。
利益攸关者需求定义流程包含以下活动：
" 引出利益攸关者需求
–识别贯穿于系统全生命周期内对其感兴趣的利益攸关者。
–引出需求——系统必须实现的内容及达到的程度。
" 定义利益攸关者需求
– 定义由协议或与遗留使能系统的接口所强加的约束。
– 构建场景以定义方案文件;预见的系统产品使用范围;预期的运行环境;以及接口系统、平台或产品。场景有助于识别有可能被忽略的需求。社会和组织的影响亦从使用这些场景中显露出来。
– 建立关键的和期望的系统性能——对系统成功至关重要的以及系统所期望的但为满足关键参数可能被折中的系统性能参数的阈值和目标值。
– 建立MOE和适用性——反映客户/用户的总体满意度（如性能、安全性、可靠性、可用性、可维护性和工作负载需求）的指标。
" 分析和维护利益攸关者需求
– 分析需求的清晰性、完整性和一致性。
– 协商修改以解决无法实现的或不切实际的需求。
– 为历史或归档目的，确认、记录和维护贯穿于系统生命周期之内以及超越系统生命周期之外的利益攸关者需求。
– 建立和维护可追溯性矩阵以文件化正式需求是如何用于满足利益攸关者的目标并获得利益攸关者的同意的。
常用方法和技巧：
" 开发用户群体的描述以提供工作期间的共同理解并确认场景的合适性。用户描述可覆盖产品将要销售给的人群，或被指派部署系统或从系统运行中受益的特定人员的类别。
" 一旦建立利益攸关者的需求，就将这些需求正式地置于构型控制之下。
" 在系统工程师与利益攸关者之间建立良好的关系和开放的交流，这在开始细化和明确一系列需求的协商时是有帮助的。
" 识别所有利益攸关者。至关重要的是在该流程中识别和包含关键的系统利益攸关者，包括开发/设计团队。
" 避免设计一个最终的解决方案或避免建立对该解决方案的不具正当理由的约束。
在ISO/IEC 15288：2008背景环境中，需求在其中的两个技术流程（即利益攸关者需求定义和需求分析）中被特别提到，并且是许多系统生命周期流程的驱动因素。依托系统开发模型，利益攸关者需求的捕获应按照常理在开发周期将要开始的时候进行一次或作为一个持续的活动来开展。无论如何，引出和分析需求的原因是相同的——理解利益攸关者的需要以足够好地支持架构设计流程。
该活动中的最大挑战之一是识别引出该需求的一系列利益攸关者。客户和最终用户相对容易识别，但亦应看到或听到在所感兴趣之系统的结果中获利的管理机构及其他感兴趣的各方。利益攸关者可包括互操作系统和使能系统本身，因为这些系统通常会强加需要被识别和考虑的约束。在可持续的开发中，这包括寻找新生代的代表。图2阐明了潜在利益攸关者的范围。