启发
术语“收集”或“汇总”意味着相关方已经有了被收集或汇总的产品信息,所以启发不仅仅代表收集或汇总产品信息。相关方通常有想要的东西、想要和创意,但是他们难以清晰的表达。
启发是从相关方和其他来源抽取需要、需求或其他信息的活动。依靠知识和经验来识别合适的方法,以便从多个来源抽取信息。商业分析师和相关方通过反复交互以获得对产品信息的共同理解,所以用“启发”是更准确的描述。
当实施启发以理解单一概念时(如现有过程的当前状态),也会多次迭代这些过程,甚至从不同来源获取观点或填补信息中的空白。特别是当结果模糊不清和开发的事,就需要询问额外的问题和实施更多的启发活动。
启发的方法包括:
需要什么样的信息?
在哪里可以找到这些信息?
如何获得这些信息?
何时进行启发活动?【最难确定】
确定启发方法
全面考虑如何实施启发活动、涉及哪些相关方、使用哪些启发技术,及启发活动的顺序。要充分考虑对相关方时间的有效利用、高效的相关方协作,以及有组织的启发方法。
可从项目组合、项目集或项目经理,以及职能经理处获得早期的支持和认同,考虑适当的启发活动的数量,来支持规划、设定期望值和降低风险。在决定商业分析活动的顺序时,这些角色可以一起工作,以确定资源可用性将如何影响排序决策。
创建启发方法所需要的工作涉及思考如何最好的协调和实施启发,包括:
要启发什么信息:需要什么问题来定义问题、解决问题或回答问题?
在哪里找到这些信息:文件、头脑?
如何获取信息:用什么方法从来源处获取?
何时实施启发活动:按照什么顺序实施,以及应何时安排?
全面的启发方法的效益
定义问题、改进效果或产生解决方案所需信息的清晰想法。
尽量减少不必要的启发活动。
来自每个启发活动的有价值的效果。
有效的可预测的利用想法的时间来启发信息。
更好的全面关注整个启发过程。
启发准备
启发准备是组织协调和调度准备并未单个启发活动准备必要的材料。可提前让参与者预先了解他们为什么要参与互动和他们需要什么。并且准备材料有利于引导者有效的实施启发,以确保与相关方花费的时间是有效的并提供最大价值。
在实际操作中可事先咨询相关方,以便知道他们的期望。如果有需要他们提前完成的启发准备活动,则基于其提醒。预先进行足够的沟通,以确保相关方能够预留时间。
实施这些活动为启发活动做准备:
确定目标:为每个启发活动设定目标,以确保每项活动都能有效的实施。目标是启发互动正在进行的原因。
确定参与者:相关方。
识别资源:某些启发活动需要支持材料,包括目标、日程表、背景、讨论问题、基本规则、演示材料或产品信息。
识别启发活动的问题:在实施启发活动之前准备好问题,以确保启发活动的目标得以实现。
设置议程:事先将要被讨论或研究的主题和通常的时限提供给参与者,让其知道对他们的期望。如果需要参与者进行事前准备工作,建议事先与他们进行沟通,以确保他们做好了准备。可以创建分析模型并且将其作为启发活动准备的一部分以便在启发过程中应用模型来识别需要回答的问题或需要审查的主题。
安排启发活动:安排适当的时间,确保为启发活动准备的所有支持材料。如会议室、投影仪等。
实施启发
实施启发是应用各种方法或技术从相关方和其他来源抽取信息的过程,以充分定义和明细需求及其他产品信息。
实施启发活动的阶段
开场:设定了启发活动的阶段、节奏和总体目的。
主体:提出问题并给出或揭示答案的所在。
收尾:为具体活动提供了完美的结束。
确认启发结果
确认启发结果是对启发结果执行跟进活动、确定使用了适当的正式程序、与相关方一起评审准确性和完整性,以及与历史信息进行比较以,理解想法和启发结果。
启发结果可以用不同方式来确认,可以分发给最初提供这些信息的参与者,以确认其准确性,或要求参与者在启发过程中澄清和纠正信息,并且团队应该讨论并就如何审查和确认启发结果达成一致。
启发结果修正
细化和/或被更正,以及被消除多余信息。
组织、分类和整合。
在未来的启发中被跟踪差异。
需要转化为适当的正式程序。
被打包以便用于分发。
分析
分析是对信息进行检查、分解、合成和澄清以进一步理解、完善和改进信息,包括对产品信息进行足够详细的检查和记录的过程,以确保能反映相关方的需要,与相关方的目的和商业目标保持一致,并且能够识别可行的解决方案设计。
商业分析师就是做战略解码和战略执行,从了解领导意图,传递给执行人员去执行,通常需要承担大量的工作,除分析、建模和记录产品信息之外,分析还通过确保信息正确、符合标准、可跟踪到目的、识别内在风险及可转化为产品设计等来完善一系列产品信息。
确定分析方法
需求架构明确了需求、模型和其他产品信息之间的相互关系。分析方法还识别哪些分析模型是最合适的,以及它们是如何彼此关联的。此外,分析方法还定义了哪些分析活动是相互关联的、在开始记录需求时使用哪些模板、使用哪些工具,以及如何修订这些活动。还明确了是否需要保留在分析会议中产生的草稿或非正式笔记,以及何时需要适用更正式的文件。
分析方法确定了在商业分析过程中要考虑的相关产品信息类型,包括有利于生产的模型选择思路、需要收集的需求特性,以及对如何核实、确认和排序产品信息的解释,作用就是为执行开发解决方案达成共识。
提前考虑如何实施分析的过程,包括要分析什么、哪些模型最有利于生产,以及需求和其他产品信息将如何被合适、确认和排序,为执行开发解决方案的商业分析工作提供了共识。
确认分析方法包括:
核实和如何创建与分析模型,哪些模型最适合,哪些相关方将使用和评审模型,使用何种建模语言,以及模型细化到什么程度。
何时对需求进行定义和明细,以及适用于需求的适当深度级别。
定义验收标准的方法,以描述获取验收标准的时间和级别。
合适的方法,谁参与合适需求、时间、频率,以及如何最好的确保需求得到良好的记录、理解,并且符合相关标准。
如何确认需求,以了解用来确认需求的信息,以及谁应参与并确保需求是满足商业目的和目标的。
项目组合、项目集或项目的早期排序方法,以确保相关方对如何确定优先级及谁有权决定优先级有正确的期望。
识别和管理风险的方法,以确保在分析活动中不会漏掉重要风险。
在早期评估产品设计的方法,以便就设计工作的级别和时间达成一致。
创建和分析模型
模型提供了一种简洁的格式有效的排列和传递大量信息,通常比文字描述更能清晰的传递信息。创建模型是创建任何产品信息的结构化标识的过程,以便于识别和发现无关的信息来促进深入的分析。其作用有助于已有序的方式传输,实现数据的清晰度、正确性和完整性。可以更好的理解、传递,让各方达成共识,所以就要模型化。
创建和分析模型包括开发采用分析方法确定的分析模型,以及使用已开发的模型来改进整体产品信息。通过从多个角度探索解决方案,分析模型有助于发现信息中的差距和识别无关信息。模型为讨论和分析提供了背景信息,有助于更好的理解复杂关系和概念。
模型的作用
定义和明细需求
建立信息共识
绘制项目组合、项目集或项目内部和之间的关系和依赖性地图
寻找需要额外启发的信息差距
识别一起为涵盖的相关方
在启发或评审过程中促进相关方对信息的理解
评估产品的当前状态和将来状态之间的能力差距
分析变更以识别产品受影响的领域。
理解什么对用户是有价值的。
在项目组合中排序产品信息或项目。
估算商业分析工作
为架构设计提供商业前景。
模型分类
类别 | 类别描述 | 模型 | 模型描述 |
范围模型(WHY) | 界定解决方案范围 | 系统交互图 | 显示直接系统和人机界面的交互 |
生态系统图 | 系统接口高层级的表现(不包括对接口的要求),用来定义流程数据对象的数据需求 | ||
事件清单 | 描述系统对任何事件触发器的响应,有助于识别用例、用户故事或系统流 | ||
特性模型 | 树状或层级结构排列,易于在单个页面中显示不同层级的许多特性,有助于说明特性时如何组合在一起的 | ||
目的模型和商业目标模型 | 组织并反映目的、商业问题、商业目标、成功衡量标准和高层级功能的图表。 | ||
组织结构图 | 展示组织内部或部分组织内部报告结构的,有助于识别相关方。 | ||
用例图 | 概括功能的范围及功能与参与者的关系 | ||
过程模型(How) | 如何使用解决方案 | 过程流 | 识别目前与新的解决方案的变化与差距,促进与业务干系人的会话 |
用例 | 描述一组场景,场景是通过系统实现主要参与者目的的单个通道 | ||
用户故事 | 是需求的功能的组合,格式:谁,需要,为了 | ||
规则模型 | 解决方案需要遵守的规则 | 商业规则目录 | 开展某个业务的限制,包含所有商业规则的知识库 |
决策表 | 描述一系列决策和这些决策所导致的成果,考虑所有可能的决策场景及相应成果的组合,避免有漏。 | ||
决策树 | 描述一系列决策和这些决策所导致的成果,可以显示有序排列的决策。 | ||
数据模型 | 在过程或系统中使用的数据及数据的生命周期 | 数据字典 | 数据执行的商业规则,通常与定义需求和验收标准一起创建。 |
数据流向图 | 说明了系统、参与者和数据之间的关系,通过数据追溯,确定具体数据需求 | ||
实体关系图 | 定义商业数据对象及其相互关系,有助于识别那些被创建、被使用或从系统输出的数据 | ||
状态图 | 模型对象的有效状态和任何在这些状态之间允许的转换,用来快速可视化对象的生命周期 | ||
状态表 | 模型对象的有效状态和任何在这些状态之间允许的转换,用来考虑每个可能的转换,确保状态转换不丢失 | ||
接口模型 | 解决方案如何与其他系统和用户交互 | 显示-操作-响应模型 | 链接用户界面元素需求和可视化的呈现方式 |
原型图 | 构建预期解决方案之前的表示法,低保真就是草图,高保真是带交互 | ||
线框图 | 是原型的一种,专用于模拟用户界面设计,也用于呈现最终用户界面外观样式 | ||
报告表 | 单个报告的详细需求,包括报告的整体信息,也包括域级别的信息 | ||
系统接口表 | 为单一系统接口获取所有详细层级需求,使每个系统与解决方案系统建立连接 | ||
用户界面流 | 显示用户与系统的交互场景 |
有些分析模型还是需要适用文本来详细阐述其可视化的内容,以协助相关方理解如何阅读和解释模型。没有一个单独的模型能把项目组合、项目集或项目中全部有用的内容标识清楚。同样,不存在需要创建所有模型的情形。
商业分析需要根据已知的场景选择最有用的模型,并且确定与谁一起合作能最佳的创建和评审这些模型。
定义验收标准
验收标准是在解决方案被接受之前需要满足的条件,是用于衡量客户是否满足所构建的方案。确定验收标准涉及与商业相关方一起评审需求和分析模型,以确定商业相关方将如何批准已完成的工作。
验收标准构成验收测试的基础,在产品评审阶段,由产品所有者或商业相关方来决定是否接受和发布已开发的解决方案,此时,验收标准在评估解决方案中尤其重要。
验收标准的设定或编写可以在整体解决方案级别或商业目标级别上进行。也可根据目的、目标、关键绩效指标、项目指标、客户指标、销售和市场指标或运营指标等设定或编写验收标准。
备注:谁有权利提出这样的需求,就有责任提出验收标准。确定了要什么才能确定验收标准。
验收过程
完成需求设计评审;
通过代码评审;
完成单元测试;
完成集成测试;
通过功能测试;
通过自动化回归测试;
通过产品负责人验收;
更新用户帮助手册;
核实需求
核实需求增加了以符合组织所定义的标准的方式来陈述和/或理解需求的可能性。从而使需求能够传达给所有感兴趣的想法,并且有益于最终产品的质量。
核实是评审需求和其他产品信息的错误、冲突,以及是否遵循质量标准或行业标准,是否符合法规、规范或强制条件,更多偏向于内部的检查过程,以确保需求和其他产品信息都被正确构建,并且模型足够清晰以有效使用。而确认需求是确保产品能够满足客户和其他已识别相关方的需要。
核实需求的质量度量方法
3C原则:
正确性(Correct);
完成性(Complete);
一致性(Cosistnt);
评审:
同行桌面检查:查看材料。
走查:口头反馈。
检查:严格评审形式。
INVEST:
独立的(Independent);
可协商(Negotiable);
有价值的(Values);
可估算的(Estimable);
短小的(Small);
可测试的(Testable);
确认需求
确认是检查需求是否满足商业目的和目标,确保正在构建的是正确的解决方案,所有需求和其他产品信息能准确反映相关方的意图,以及每项需求匹配一项或多项商业需求的过程。
确认需求是要与相关方(偏向外部)达成共识,避免因误解商业或客户想要而导致解决方案不符合商业目的和目标的情况发生,进而最小化缺失相关方期望或交付错误解决方案的风险。
将需求和其他产品信息映射到商业目标的方式来执行,可识别差距、不一致性或重复。
排序需求和其他产品信息
理解产品信息的单个部分如何实现相关方目标的过程,并且使用该信息及其他已商定的优先级因素来促进对工作的排序,确保所有相关方对需求如何实现目的和目标的方式达成一致,并且确定了如何相应的将需求分配到迭代或发布中,以便按照最符合组织需要的顺序实现商业目标。
排序的优先级重点关注可增大最大价值的需求项,考虑因素包括价值、成本、难度、法规和风险等。
识别和分析产品风险
产品风险是不确定因素,可能影响产品或解决方案在定义、开发和预期结果方面的成果。如果具有负面影响的产品风险没有得到处理,可能导致产品故障。而识别和分析产品风险正是揭示和检验假设和不确定性的过程。
商业分析师要主动管理商业分析活动中的不确定性,并且揭示和主动找到产品中潜在的优势和劣势领域。
识别和分析产品风险的活动
识别产品风险
执行定性风险分析
执行定量风险分析
规划风险应对:
消极:规避(100%)、转移、减轻(几率)、接受
积极:开拓(100%)、提高、分享、接受
实施风险应对
监督风险
假设
约束条件
依赖性
问题
产品风险分析结果
易识别的产品风险
潜在的应对措施清单
风险优先级列表
预警信号
近期需要应对的风险
额外分析和应对的风险
定性分析结果的趋势
总风险敞口
低优先级风险观察清单
评估产品设计选项
评估产品设计关注产品应如何构建和产品应有怎样的外观,理解可用的设计选项,并且分析如何将这些设计演变为解决方案的细节。基于商业目的和目标、期望的实际成本、可行性和关联的风险来识别、分析和比较接近方案设计选项。
每个选项的分析结果都提供了可阐明改选项利弊、风险和成本等相关信息。将每个选项与其他选项进行比较,以确定哪个选项能最好的实现整体产品目的和目标,并且遵守约束、预算和/或时间限制,不可向的设计不考虑在内。
当需求的增量已为设计准备就绪时,设计评估就可以完成,这些需求都需要进行排序,以便设计能实现最重要的需求。可以进行足够详细的设计分析,以确保解决方案的多个发布或组件之间的一致性。
分析小结
主要任务:
应用过程:
1、确认采用集体还是独立的需求启发技术
2、在具备详细支持资料(如起因和原理)的情况下发现和捕获需求
3、逐步阐述和分解需求
4、使用决策和评价技巧来评估产品方案与能力
5、确定哪些需求可以接受、推迟或拒绝
6、在各个阶段或发布中分配需求
7、在需求基准上获得批准或签字
8、建模和优化需求(使用范围模型、过程模型、数据模型或规则模型)
9、使用流程(如用例、用户故事)、数据和界面详情来编写需求规格
10、使用文件审查、原型法、演示等工具和技巧及其他验证方法来验证需求
11、使用衡量工具与技巧来详细说明和明确具体的指标与验收标准
12、评价解决方案是否满足需求
跟踪与监督
跟踪与监督包括用于在需求和其他产品信息之间确立关系和依赖性的关系,这有助于确保需求得到批准和管理,并且寻求变更的影响也得到评估。
跟踪是通过在对象之间建立连接来在整个含片生命周期中跟踪信息的能力,这些链接也称为依赖。
监督确保了产品信息从批准到实施都是准确的,包括了产品信息的变更和确定保持产品质量的推荐操作。
跟踪的原则是,让变更影响分析的进行成为可能,这也是确认目标达成和确保测试范围的基础,还有助于发现缺失的需求和无关的需求。
跟踪有双向、向前、向后的,因为对需求跟踪是多个方向进行的。
向后:从需求跟踪到触发范围特性、商业目的和目标。
向前:从设计需求到测试组件和最终产品。
单向:从文本的产品信息跟踪到模型。
确定跟踪与监督方法
跟踪方法定义了用于指定需求、模型和其他产品信息之间如何相互关联,包括哪些产品信息部件最适合跟踪如何在它们之间跟踪需求的架构。
有利于:
缺失需求的可能性降到最低。
确保了变更符合商业目标和/或项目目标。
使实施必要的变更变得简单。
符合组织标准,满足法规要求,同时还能应对未来的需要,包括提供有关超出当前项目的长期且有价值的产品信息。
跟踪组件包括:
对象类型;
所需的细节水平;
需要建立和维护的关系;
如何跟踪关系,如使用需求特性、跟踪矩阵或需求管理工具等;
推动需求生命周期的需求状态,如批准、顺延或拒绝;
变更管理组件包括:
如何提出需求变更;
如何评审变更;
如何记录变更管理的决策;
如何沟通需求变更;
批准变更后,如何完成和获得对需求、模型、跟踪和其他产品信息的变更;
需求变更过程中的角色和责任;
确立关系和依赖性
确立关系和依赖是跟踪或设定需求和其他产品信息之间的联系,有助于确认每个需求都能提升商业价值且符合客户的期望,也能支持对产品范围的监督和控制。
可以在商业分析可交付成果,以及其他项目团队成员产生的可交付成果之间执行跟踪,例如项目需求和设计、开发和测试组件。
作用:
确保产品信息能提升商业价值且符合客户的期望;
管理范围;
最小化缺失需求的可能;
进行影响分析;
做出发布决策;
选择和批准需求
选择和批准需求是促进与相关方进行讨论的过程,以协商和确认哪些需求应纳入迭代、发布或项目中,并提供了授权以考虑如何及何时构建完整或部分的解决方案来开发或修改产品。
批准需求的执行能够蝴蝶共识,以确定需求准确描述了产品团队被要求构建的产品。经批准的需求确立了需求基准。需求基准是包含所有对解决防范、项目、项目阶段、迭代、增量、发布,以及项目或解决方案的任何其他部分的批准的需求范围。
批准的需求的特征:
经过核实:需求质量足够高。
经过确认:需求满足商业需要。
管理需求和其他产品信息变更
管理需求和其他产品信息变更提供了一个过程以管理对批准的需求的变更,并且把不受控或未批准的与需求相关的产品和项目风险降到最低。在进行变更时,若不考虑依赖性,以及变更对整个产品和项目(包括预期的商业价值)的影响,往往会造成对产品和项目的负面影响。
通过理解变更的价值和影响来检查项目中出现的变更和缺陷,并随着变更的达成,这些变更信息将被反映到任何必要的地方以支持排序和最终产品开发。
商业分析师需要引导项目中重要的解决方案变更的合并,限制不必要的变更和提供对变更对最终产品影响的理解,包括维护需求、相关方的可交付成果和工作成果的完整性,并且确保每个新需求都符合商业需要和商业目标。
变更状态:
变更批准:对计划和进行中的商业分析活动进行调整。
变更延期:确保在提出的日期处理变更。把提出的变更分配到产品未完项中靠后的位置。
拒绝变更:将拒绝变更提议的决策和其依据记录到文件中。
需要更多信息:确保影响分析被完全构建。
跟踪和监控小结
主要任务:跟踪和监控需求、设定需求基准、评估需求变更。
应用步骤:
1、使用跟踪工具和技术跟踪需求
2、创建并维护需求跟踪矩阵
3、维护或协助维护产品未完项
4、用沟通方法,向项目经理和其他相关方传达需求状态,以便让他们了解需求问题、冲突、变更、风险及整体状态。
5、创建需求基准
6、对需求变更进行影响分析(包括依赖关系和风险)
7、使用变更管理流程管理变更
8、比需求基准,以此来管理需求变更,进而维持需求及相关构建的完整性
备注:PM关心项目需求影响,BA关心产品需求影响。
解决方案评价
确定即将实施或已经实施的完整或部分解决方案,并确定解决方案会在多大程度上满足相关方的商业需要,包括交付给客户的价值。
准备工作包括定义和确认预期商业价值,识别和确认用于评估是否实现商业价值的性能数据类型,确认性能数据的实际可用性,以及在必要时候获取基准或控制数据。
评价解决方案的困难之处:
解决方案的部分效益和价值是无形的,无法进行直接测量,需要间接进行。
解决方案本身可能并不需要某些用于评级解决方案的信息。
在解决方案发布之前,可能无法测量。产品或企业运营团队就要负责确定和测量领先指标。
评价时机:
需要做解决方案作出通过/不通过或发布决策的任意时刻。
解决方案投入运营后的短时间内,如刚过保修期时。
解决方案投入运营后,需要获得解决方案是否满足商业目的和目标,以及期望价值是否能持续交付的远期愿景时。
评估解决方案绩效
分析活动提供了有形的数据,以确定商业投资的解决方案是否达到了预期的商业成果,
包括确认已投入运营的解决方案是否交付了期望的商业价值。
对解决方案的绩效评价通常在解决方案发布后进行。所以,测量工作常常是需要持续一定时间以获取其趋势。因此,组织需要对测量工作的投入做出承诺,并且在不具备商业价值测量能力时,对这些能力进行组件或购买。如果资源提供有困难,组织就要考虑采用成本更低的次优方法进行测量,此时可能选择代理或外包的方式。
评价验收标准和解决缺陷:测试时;
评价解决方案的长期绩效:上线后;
确定解决方案评价方法
确定要评价组织和/或解决方案的哪些方面、收集频率、如何测量绩效,何时及由谁来测量,需要选择或定义绩效指标和测量指标,以便后续可以收集、报告和评价,以支持组织和/或产品的持续改进,并且为决定哪些类型的指标能够帮助组织评估产品性能提供了依据。
如果不尽早定义,获得所需的细节的成本可能会变得很高,并且当备选指标的收集成本过高或过于耗时而无法证明其使用的合理性时,可以考虑使用成本更低的、次优的替代方案。
指标是用于评价解决方案或商业的一系列可量化的测量,两种常见的指标类型:验收标准;交付指标(确定商业价值是否交付)。
评价验收结果并解决缺陷
将验收测试的结果与验收标准进行比较,并且为如何解决不满足验收标准的场景提供解决方案,以及决定是否发布整个解决方案或部分解决方案,是否执行变更,或者对产品进行补救或增强。
聚焦验收测试与验收标准之间的比较,而不是测试结果本身,考虑修复和处理缺陷所产生的商业影响和成本,以及如果选择不解决这些缺陷,将对商业带来的影响和产生的成本。
测试结果可来自:探索性测试、用户验收测试、生活时光测试、试生产或模拟生产测试、功能测试和非功能测试。
测试结果分析包括:
成本分析、可能对商业造成的影响进行分析;
提出解决缺陷的解决方案;
潜在的权变措施,但不影响产品和其他功能或导致产品异常工作;
通过变更请求实施产品改进;
对产品的策略方法和测量内容进行调整;
识别是否需要对缺陷的技术原因进行调整;
通过沟通就如何使用产品向客户或用户进行澄清;
获得解决方案发布的验证
在构建的解决方案与发布的解决方案间为相关方验收创建一个商定的中断,为是否将部分或完整的解决方案发布到生产中并最终交接给运营团队做出决策,以及转移关于产品、风险、已知问题和这些问题可能出现的权变措施的知识和现有信息的过程。
发布决策通常基于以下条件:
由评价验收结果来证明解决方案的可接受性;
确认该组织已经做好发布准备;
确认为准备发布而进行的过渡活动已完成到必要的程度(不影响用户),包括协调并发的多个解决方案;
对其他剩余的产品风险和权变措施的验证;
解决方案评价小结
主要任务:确认解决方案(测试)、识别和解决问题、获得解决方案批准、评估部署的解决方案。
应用步骤:
1、规划解决方案评估或测试
2、验证解决方案组件,以确定解决方案是否带来商业价值
3、促进或参与解决方案的测试
4、使用质量保证工具和方法来分析和沟通解决方案中已鉴别的差距与偏差
5、让相关方能够处理好解决方案范围、需求和已制定之解决方案的偏差
6、使用决策技巧来获取相关方对已制定之解决方案的签署同意,以便继续推进部署
7、使用验证技巧来评估已制定的解决方案,以便解决方案在满足商业论证和价值主张方面的良好程度。
解决方案评价计划包括:
1、监督、跟踪或确认项目或组织的哪些目的、目标或风险。
2、谁会承担进行评价所需花费的时间和工作量成本。
3、解决方案或其基础架构是否具有对评价标准的内置测量能力
4、是否存在已有手段来抽取测量数据用于评价
5、选择的评价方法是否有效且相对经济
6、现有方式是否已经可以用来汇报和公布评价结果