项目需求跟踪矩阵表
简练网软考知识点整理-项目需求跟踪及需求跟踪矩阵
简练⽹软考知识点整理-项⽬需求跟踪及需求跟踪矩阵1.需求跟踪需求跟踪包括编制每个需求同系统元素之间的联系⽂档。
这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助⽂件、⽂档等。
跟踪能⼒信息使变更影响分析⼗分便利，有利于确认和评估实现某个建议的需求变更所必须的⼯作。
2.需求跟踪⽬的需求跟踪提供了⼀个表明与合同或说明⼀致的⽅法，需求跟踪可以改善产品质量，降低维护成本，⽽且很容易实现重⽤。
需求跟踪是个要求⼿⼯操作且劳动强度很⼤的任务，要求组织提供⽀持。
随着系统开发的进⾏和维护的执⾏，要保持关联链信息与实际⼀致。
跟踪能⼒信息⼀旦过时，可能再也不会重建它了。
由于这些原因，应该正确使⽤需求跟踪能⼒。
下⾯是在项⽬中使⽤需求跟踪能⼒的⼀些好处：（1）审核跟踪能⼒信息可以帮助审核确保所有需求被应⽤。
（2）变更影响分析跟踪能⼒信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
（3）维护可靠的跟踪能⼒信息使得维护时能正确、完整地实施变更，从⽽提⾼⽣产率。
要是⼀下⼦不能为整个系统建⽴跟踪能⼒信息，⼀次可以只建⽴⼀部分，再逐渐增加。
从系统的⼀部分着⼿建⽴，先列表需求，然后记录跟踪能⼒链，再逐渐拓展。
（4）项⽬跟踪在开发中，认真记录跟踪能⼒数据，就可以获得计划功能当前实现状态的记录。
还未出现的联系链意味着没有相应的产品部件。
（5）再设计（重新建造）你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
通过定义跟踪能⼒信息链提供⼀种⽅法收集从⼀个现成系统的反向⼯程中所学到的⽅法。
（6）重复利⽤跟踪信息可以帮助你在新系统中对相同的功能利⽤旧系统相关资源。
例如：功能设计、相关需求、代码、测试等。
（7）减⼩风险使部件互连关系⽂档化可减少由于⼀名关键成员离开项⽬带来的风险。
（8）测试测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。
以上所述许多是长期利益，减少了整个产品⽣存期费⽤，但同时要注意到由于积累和管理跟踪能⼒信息增加了开发成本。
需求跟踪矩阵模板
软件需求 概要设计 系统/FAT测试用例
详细设计 编码文件 集成/SIT测试用例
XX项目需求跟踪矩阵
子系统 系统管理
需求 权限管理
业务需求 需求名称
用户添加
状态
类别
优先 级
执行 状态
功能子集(FS)
软件需求 执行单元名称(EU)
做
必须 高
权限管理
用户添加
关键 程度
模块
权限管理 高
概要设计
跟踪矩阵
概要设计 组件
用户添加 用户维护 角色添加 角色维护 测试 角色权限对照
机器参数添加
详细设计 开发单元
编码文件 代码文件
SRS_XTGL_YHGL_用户添加001 SRS_XTGL_YHGL_用户添加002 SRS_XTGL_YHGL_用户添加003 SRS_XTGL_YHGL_用户添加004
完
完
完
用户维护
做
必须 高
用户维护
高
角色添加 角色维护
做
必须 高
新增 必须 高
角色添加
中
角色维护
中
权限报表
待定 必须 中
权限报表
低
角色权限对照
删除 必须 中
角色权限对照
低
参数管理
机器参数添加
必须 高
参数管理
机器参数添加
参数管理 高
电话银行
机器参数维护
必须 高
完
完
完
完完完完 完ຫໍສະໝຸດ 完请在这行之前插入行。
完完
请在这行之前插入行。
j1.java j2.jsp F_AddEmployee.sql FormConfig.xml
SugarCRM项目ST需求跟踪矩阵表
关联商业活动 创建新文件
SRS-Documents-FUNC-Manege SRS-My Portal -FUNC-New SRS-My Portal -FUNC-Delete SRS-My Portal -Mass Update
SRS-Campaigns-FUNC-Create
文件管理 添加我的门户网站 删除我的门户网站 批量更新
SRS-SugarCRM-FUNC-001
SRS-SugarCRM-FUNC-002
删除当前机会 批量删除机会
查找重复记录 查看更改日志
合并重复 导出 导入商业机会 批量更新 基本查找 删除当前新闻 批量删除新闻 导出
新增活动
查找活动
SRS-SugarCRM-FUNC-003
SRS-SugarCRM-FUNC-004 SRS-SugarCRM-FUNC-001
快速创建文件
SugarCRM-ST-Documents-New-002
完整创建文件
SugarCRM-ST-Documents-Basic Find
基本查找
SugarCRM-ST-Documents-Advanced Find
高级查找
SugarCRM-ST-Documents-Mass Update
批量更新
新增营销活动
SRS-Campaigns-FUNC-Manage
营销活动管理
SRS-Campaigns-FUNC-Manage
SRS-Campaigns-FUNC-TargetLst-Create SRS-Campaigns-FUNC-Associate-TargetLst SRS-Campaigns-FUNC-AssoTarget-001 SRS-Campaigns-FUNC-AssoTarget-002 SRS-Campaigns-FUNC-AssoTarget-003
需求跟踪矩阵的内容
需求跟踪矩阵的内容1. 介绍需求跟踪矩阵需求跟踪矩阵是一个用于追踪软件项目需求的工具。
它能够帮助团队有效地管理和掌控需求变更，确保项目在开发过程中的各个阶段能够满足用户的需求。
该矩阵记录了项目的需求以及与之相关的信息，如需求的来源、状态、优先级等，从而为开发团队提供了一个清晰的需求全貌。
2. 需求跟踪矩阵的结构需求跟踪矩阵通常由表格组成，其中包含了多个字段用于描述需求的各个方面。
常见的字段包括需求编号、需求描述、需求来源、需求状态、所属模块、开发优先级、验收标准等。
这些字段能够帮助团队跟踪和管理需求的生命周期，并确保参与项目的各方都对需求有一个共同的理解。
2.1 需求编号需求编号是每个需求的唯一标识符，用于在矩阵中区分不同的需求。
编号可以采用自定义的规则，比如简单的序号、项目缩写+序号等。
2.2 需求描述需求描述是对需求的详细说明，包括需求的背景、目标、功能要求等信息。
一个清晰、准确的需求描述能够帮助开发团队准确理解用户的期望。
2.3 需求来源需求来源是指提出该需求的人或团队。
需求可以来自于不同的渠道，比如用户反馈、市场调研、相关部门等。
记录需求来源能够帮助团队了解需求的背景和动机。
2.4 需求状态需求状态标识了需求所处的状态，比如已提出、待评审、开发中、已完成等。
需求状态的变更能够帮助团队了解需求的进展情况，并及时处理需求相关的事务。
2.5 所属模块所属模块指明了需求所属的功能模块或系统模块。
将需求按模块分类能够帮助团队更好地组织和安排开发工作，并便于后续的维护和升级。
2.6 开发优先级开发优先级用于确定需求的重要性和紧急程度。
通过给需求设置优先级，团队可以合理安排开发资源，确保高优先级需求得到及时处理。
2.7 验收标准验收标准是对需求实现的一组判断规则。
它描述了需求完成后应满足的条件和表现，便于项目验收和用户验收的进行。
3. 如何使用需求跟踪矩阵需求跟踪矩阵在项目的不同阶段都扮演着重要的角色。
需求跟踪矩阵模板
地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
名称搜素。 地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
名称搜素。 地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
件测试/验收交付
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
对应概要设 详细设计状 对应详细设
计章节
态
计章节
单元测试 集成测试用 系统测试
用例
例
用例
对应代码
示例：6.1.1 示例：修订 示例：6.1.1 示例：E1 示例：E5 示例：T3.1 示例：
一、项目信息（主要指项目基本信息）
项目名称 项目编号 客户名称 项目经理 项目发起人 编制人
日期
二、需求跟踪矩阵（把产品需求连接到可交付成果，把每个需求与业务目标或项目目标联系起来，有助于确保每
需求跟踪表模板
需求跟踪表
项目名称：
说明：
1、此表以需求编号作为唯一，可维护一对多关系。
2、原编号填入该需求在《用户需求说明书》中的编号
2、需求编号方法：日期_4位流水号（yyyymmdd_0001）,例如20000517_0001;
3、需求类别：A、功能性需求B、非功能性需求；
4、优先等级：A、B、C、D、E五个等级；
5、需求状态：A、已提出；B、已批准；C、已拒绝；D、已变更；E、已删除；F、已关闭；
6、进度：Y表示已完成，P表示正在进行，---表示不需进入该步骤进行处理；
7、设计、编码、测试用例填写：编号+（命名），具体的编码方法是：design/code/test+4位流水号，例如，design0001
（class）；另外，设计、编码、测试用例需遵循一致的命名约定，如设计模型中名为 class 的类由实施模型中的 class 类来实现。
8、设计可以包括：模型中的对象、关系数据库中的模型、表单，或对象类；代码可以是：类中的方法、源代码的文件名、过程或
函数；测试用例是改需求所对应的测试用例；发布产品版本是该需求所对应的产品版本；
9、本表A,B,C,D,E,F,H,I,J,K栏由需求管理员进行维护；L栏由设计人员进行维护，需求管理员进行检查和跟踪；M栏由开发人员进行维护，需求管理员进行检查和跟踪；G栏由测试经理进行维护，需求管理员进行检查和跟踪。
N栏由项目经理进行维护。
10、需求基线编号填入本次需求基线的编号，对于每一次需求基线的变更都需要建立新的《需求跟踪矩阵》
11、“蓝色字”标注的内容需要及时填写，“黑体字”标注的内容可以延迟到项目验收后填写。
软件开发项目需求跟踪矩阵
一级菜单
模块名称
1 界面需求
全局
全局
2 功能需求 3 功能需求 4 功能需求 5 功能需求 6 功能需求 7 功能需求 8 功能需求 9 功能需求 10 功能需求 11 功能需求 12 功能需求 13 功能需求 14 功能需求
全局 用户管理 用户管理 用户功能 用户功能 用户功能 用户功能 用户功能 用自定义。
单位设置 账户权限过滤 账户登录 对用户进行分组管理 按管理层级查询（及操作）用户权限台帐明细 修改用户组信息 删除用户组 添加新用户 不同角色查看不同的页面 按部门管理不同的用户 访问时间、ip范围等 不同角色配置不同的节点查看操作权限 不同角色配置不同的数据查看操作权限
全局 全局/用户管理 用户权限管理 用户权限台帐 用户权限台帐 用户权限台帐 用户权限台帐 用户权限台帐 用户权限管理 用户组管理 访问配置 用户权限管理 用户权限管理
需求编号
IR001
BR001 BR002 BR003 BR004 BR005 BR006 BR007 BR008 BR009 BR010 BR011 BR012 BR013
优先 所属阶段 级 低 第2阶段
中 第2阶段 中 第2阶段 中 第1阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第3阶段 高 第2阶段 高 第2阶段
对应功能
上传Logo图片和输入 项目名称 修改各参数的单位标 签 权限过滤 登录 新建用户组 用户（组）节点树 编辑用户组 删除用户组 添加新用户 权限过滤
数据表
接口
../auth/v1/login
自测用例
系统测试用例 完成情况
R
R R R R S S S S S S S S S
项目管理：怎样做需求分析
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。
建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。
下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求这是该阶段的一个最重要的任务.以下为获取用户需求需要执行的活动（如图1所示）。
● 了解客户方的所有用户类型以及潜在的类型。
然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
● 对用户进行访谈和调研。
交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。
需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。
例如，可以将需求细分为功能需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
● 需求分析人员对收集到的用户需求做进一步的分析和整理。
下面是几条常见的准则：⑴对于用户提出的每个需求都要知道“为什么"，并判断用户提出的需求是否有充足的理由;图1 获取用户需求的活动⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员.大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。
需求分析人员在这个任务中需要执行下述活动：⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；⑵使需求符合系统的整体目标；⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
分析用户需求在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
(项目简称)-RDM-需求跟踪矩阵
软件需求功能标题
软件需求变更标识
需求等所有需求项； 明书》通过评审和确认后开始跟踪； 格说明书》通过评审后开始跟踪；
阶段《需求跟踪矩阵》的填写和维护； 和计算百分比； 中的需求情况的度量数据收集到《数据度量及分析表》的“项目需求管理”页中。
用户需求标题
用户需求变更标识
填பைடு நூலகம்说明：
1、需求跟踪的内容包含功能需求和非功能需求等所有需求项； 2、定制类项目跟踪的源头从《业务需求说明书》通过评审和确认后开始跟踪； 3、研发类项目跟踪的源头从《软件需求规格说明书》通过评审后开始跟踪；
4、第一张表格由项目组成员负责各自开发阶段《需求跟踪矩阵》的填写和维护； 5、第二张表格不需要填写，已经自动统计和计算百分比； 6、项目经理在各阶段里程碑点将第二张表中的需求情况的度量数据收集到《数据度量及分析表》的“项目需求管理”
需求跟踪矩阵
知识创造未来
需求跟踪矩阵
需求跟踪矩阵是一种项目管理中常用的工具，用于跟踪需求与项目的关联关系。
它有助于确保项目中的所有需求得到满足，并提供了一种追踪需求变更和确认的方法。
需求跟踪矩阵通常由一个二维表格组成，其中列代表项目中的需求，行代表项目中的各个阶段或工作包。
每个单元格中的标记表示该需求在对应阶段或工作包中的状态。
以下是一个示例需求跟踪矩阵：
阶段/工作包 | 需求1 | 需求2 | 需求3
项目规划| √ | |
需求分析| | √ | √
系统设计| √ | √ |
编码| | √ |
测试| √ | | √
验收| √ | √ |
在这个例子中，我们可以看到每个需求在项目的每个阶段或工作包中的状态。
例如，需求1在项目规划、系统设计、测试和验收阶段都得到了满足，而需求2只在需求分析、系统设计和编码阶段得到了满足。
需求跟踪矩阵可以帮助项目团队了解需求的状态，及时发现并解决与需求相关的问题，并确保项目按照预期进行。
1。
项目管理中需求跟踪矩阵的应用
项目管理中需求跟踪矩阵的应用朱延杰1陈 羽2曾 俊2（1.云南省电网有限责任公司信息中心，云南 昆明 650217；2.云南云电同方科技有限公司，云南 昆明 650217）在信息系统建设过程的整个生命周期中，需求管理一直贯穿着整个项目，随着项目的演化，需求也在不断变化，需求管理决定了一个项目的成功与否，在规划阶段，通过与客户沟通获取用户的需求，同时约定好需求的范围，在设计阶段，根据用户的需求，得到功能需求和非功能需求，根据需求进行信息系统的开发，在过程出反复的与用户沟通，会产生新的需求变更，如何合理的控制需求变更对于一个项目的质量好坏有着重要的影响，也决定了一个项目的进度快慢。
在这些阶段如何控制好需求的演变就显得尤为重要，对于大部分企业，目前对于需求的管理主要是通过与用户沟通后，形成文档的方式来管理需求，最终验证产品是否成功，也是通过用系统对照需求文档来判断是否一致。
在对文档的管理过程中，每一次的需求变更，都需要同步的更新文档，管理的复杂随着变更次数的增加也会越来越复杂，保证项目的一致性和完整性也就越来越困难。
为了解决需求管理过程的复杂性，同时保障建设过程中的一致性和完整性，需要引入需求跟踪接矩阵，需求跟踪矩阵是把需求在建设过程中不断变化到最后可交付成果的一种表格，本文在传统的需求的跟踪矩阵上结合信息化建设的全生命周期，对每一个环节的需求进行横向追踪和纵向追踪，对需求的演变过程，以及各个阶段间需求的关联关系都有清晰的展示。
1 信息化建设全生命周期中对需求的管理在信息化建设的整个周期中，需求管理涉及到的阶段包括有需求规划阶段、需求定义阶段、需求设计阶段、需求测试阶段，以及需求变更阶段。
在需求的演变过程中，每个阶段都会产生相关的需求文档。
1.1 需求的分类 在需求管理中，需求主要分为业务需求、用户需求、功能需求、非功能需求。
业务需求：业务需求一般来自用户对于当前业务上需要信息化的需求。
描述了用户为什么要开发这个系统，以及希望达到的目标。
需求跟踪矩阵 模板
表格编号：XY202-项目编号-两位顺序号
项目名称： 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
567源自8原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
3 0 0 0 3
需求跟踪矩阵
项目经理PM： 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA： 功能测试 测试单元 是否完成 责任人 备注
项目管理过程组与知识领域表格
启动
过程组
规划过程组
执行过程组
监控过程组
收尾
过程组
7、
P
本钱管理
7.1
规划
本钱
管理
输入
工程管理方案工程章程
事业环境因素组织过程资产
7.4
控
制
成
本
输入
工程管理方案
工程资金需求
工业绩效数据
组织过程资产
工具
专家判断分析技术会议
输出
本钱管理方案
7.2
估
算
成
本
输入
本钱管理方案人力资源管理方案
范围基准工程进度方案风险登记册
6.2
定义
活动
输入
进度管理方案范围基准事业环境因素组织过程资产
工具
分析滚动式规划专家判断
输出
活动清单活动属性里程碑清单
6.3
排列
活动
顺序
输入
进度管理方案活动清单活动属性里程碑清单
工程范围说明书事业环境因素组织过程资产
工具
绩效审查
工程管理软件
资源优化技术
建模技术
提前量与滞后量
进度压缩
进度方案编制工具
工具
输出
风险登记册
工具
风险再评估
风险审计
偏差与趋势分析
技术绩效测量
储藏分析
会议
11.3
实施
定性
风险
分析
输入
风险管理方案范围基准风险登记册事业环境因素组织过程资产
工具
风险概率和影响评估概率和影响矩阵风险数据质量评估风险分类
风险紧迫性评估专家判断
输出
工程文件更新
11.4
第三版信息系统项目管理师十大管理47个过程的输入输出和工具
亠、项目整体管理过程名输入工具和技术输出1、制定项目章程1、项目工作说明书2、商业论证3、协议（合冋，备忘录、意向及协议书）4、组织过程资产5、事业环境因素1、专家判断2、引导技术1、项目章程2、制定项目管理计划1、项目章程2、其他规划过程的输出3、组织过程资产4、事业环境因素1、专家判断2、引导技术1、项目管理计划3、指导与管理项目工作1、项目管理计划2、批准的变更请求3、组织过程资产4、事业环境因素1、专家判断2、项目管理信息系统（PMIS ）3、会议1、可交付成果2、工作绩效数据3、变更请求4、项目管理计划更新5、项目文件更新1、项目管理计划2、进度预测1、分析技术2、项目管理信息系统1、变更请求2、工作绩效报告4、监控项目工作3、成本预测4、确认的变更5、工作绩效信息6、组织过程资产7、事业环境因素3、会议4、专家判断3、项目管理计划更新4、项目文件更新5、实施整体变更控制1、项目管理计划2、工作绩效报告3、变更请求4、组织过程资产5、事业环境因素1、会议2、变更控制工具3、专家判断1、批准的变更请求2、变更日志3、项目管理计划更新4、项目文件更新结束项目或阶段1、项目管理计划2、验收的可交付成果3、组织过程资产1、分析技术2、会议3、专家判断1、最终产品、服务或成果2、组织过程资产更新1、项目范围管理输入工具和技术输出过程名1、编制范围管理计划（规划范围管理）1、2、3、4、项目管理计划项目章程组织过程资产事业环境因素1、2、会议专家判断1、范围管理计划2、需求管理计划2、收集需求1、范围管理计划1、访谈1、需求文件2、需求管理计划2、焦点小组2、需求跟踪矩阵3、干系人管理计划3、引导式研讨会4、项目章程4、群体创新技术5、干系人登记册5、群体决策技术6、冋卷调查7、观察8、原型法9、标杆对照10、系统交付图11、文件分析3、定义范围1、范围管理计划1、产品分析1、项目范围说明书2、项目章程3、需求文件4、组织过程资产2、专家判断3、备选方案生成4、引导式研讨会2、项目文件更新4、创建工作分解结构（WBS ）1、范围管理计划2、项目范围说明书3、需求文件4、事业环境因素5、组织过程资产1、分解2、专家判断1、范围基准2、项目文件更新5、确认范围1、项目管理计划2、需求文件3、需求跟踪矩阵4、核实的可交付成果5、工作绩效数据1、检查2、群体决策技术1、验收的可交付成果2、变更请求3、工作绩效信息4、项目文件更新6、范围控制1、项目管理计划2、需求文件3、需求跟踪矩阵4、工作绩效数据5、组织过程资产1、偏差分析1、工作绩效信息2、变更请求3、项目文件更新4、项目管理计划更新5、组织过程资产更新三、项目时间管理过程名输入工具和技术输出1、规划进度管理1、项目管理计划2、项目章程3、组织过程资产4、事业环境因素1、专家判断2、分析技术3、会议1、项目进度管理计划2、定义活动1、进度管理计划2、范围基准3、组织过程资产4、事业环境因素1、分解2、滚动式规划3、专家判断1、活动清单2、活动属性3、里程碑清单3、排列活动顺序1、进度管理计划2、活动清单3、活动属性4、里程碑清单5、事业环境因素6、组织过程资产7、项目范围说明书1、前导图法2、箭线图法3、确定信赖关系4、提前量与滞后量1、项目进度网络图2、项目文件更新4、估算活动资源1、进度管理计划2、活动清单1、专家判断2、备选方案分析1、活动资源需求2、资源分解结构3、活动属性4、资源日历5、风险登记册6、活动成本估算7、事业环境因素8、组织过程资产5、估算活动持续时间1、进度管理计划2、活动清单3、活动属性4、活动资源需求5、资源日历6、项目范围说明书7、风险登记册8、资源分解结构9、事业环境因素10、组织过程资产6、制定进度计划1、进度管理计划2、活动清单3、活动属性4、项目进度网络图5、活动资源需求6、资源日历3、发布的估算数据3、项目文件更新4、项目管理软件5、自下而上估算1、专家判断1、活动持续时间估算2、类比估算2、项目文件更新3、参数估算4、三点估算5、群体决策技术6、储备分析1、进度网络分析法1、进度基准2、关键路线法2、项目进度计划3、关键链法3、进度数据4、资源优化技术4、项目日历5、建模技术5、项目管理计划更新6、提前量和滞后量6、项目文件更新7、控制进度7、活动持续时间估算7、进度压缩8、项目范围说明书8、进度计划编制工具9、风险登记册10、项目人员分配11、资源分解结构12、事业环境因素13、组织过程资产1、项目管理计划1、绩效审查2、项目进度计划2、项目管理软件3、工作绩效数据3、资源优化技术4、项目日历4、建模技术5、进度数据5、提前量和滞后量6、组织过程资产6、进度压缩7、进度计划编制工具1、工作绩效信息2、进度预测3、变更请求4、项目管理计划更新5、项目文件更新6、组织过程资产更新四、项目成本管理过程名输入工具和技术1、制定成本管理计划（规划成本）1、项目管理计划1、专家判断2、项目章程2、分析技术3、事业环境因素3、会议4、组织过程资产2、成本估算1、成本管理计划1、专家判断2、人力资源管理计划2、类比估算3、范围基准3、参数估算4、项目进度计划4、自下而上估算5、风险登记册5、三点估算6、组织过程资产6、储备分析7、事业环境因素7、质量成本8、项目管理软件9、卖方投标分析10、群体决策技术3、成本预算（制定预算）1、成本管理计划1、成本汇总2、范围基准2、储备分析3、活动成本估算3、专家判断4、活动依据4、资金限制平衡输出1成本管理计划1成本基准2、项目资金需求3、项目文件更新1、活动成本估算2、估算依据3、项目文件更新4、成本控制5、项目进度计划6、资源日历7、风险登记册8、协议9、组织过程资产5、参数模型1、项目管理计划2、项目资金需求3、工作绩效数据4、组织过程资产1、挣值管理2、预测3、完工尚需绩效指数4、绩效审查5、项目管理软件（PM软件）6、储备分析1、工作绩效信息2、成本预测3、变更请求4、项目文件更新5、组织过程资产更新6、项目管理计划更新五、项目质量管理过程名输入工具和技术输出1、规划质量管理1、项目管理计划1、成本效益分析1、2、干系人登记册2、质量成本法2、3、风险登记册3、七种基本质量工具3、4、需求文件4、标杆对照4、5、事业环境因素5、实验设计5、6、组织过程资产6、统计抽样7、其他质量管理工具8、会议2、实施质量保证1、质量管理计划1、质量审计1、2、过程改进计划2、过程分析2、3、质量测量指标3、质量管理与控制工具3、4、质量控制测量结果4、5、项目文件3、质量控制（控制质量）1、项目管理计划1、七种基本质量工具1、2、质量测量指标2、统计抽样2、3、质量核对单3、检杳3、4、单工作绩效数据4、审查已批准的变更请求4、5、批准的变更请求5、质量管理计划过程改进计划质量测量指标质量核对单项目文件更新变更请求项目管理计划更新项目文件更新组织过程资产更新质量控制测量结果确认的变更核实的可交付成果工作绩效信息变更请求6、7、86、项目文件更新7、项目管理计划更新8、组织过程资产更新可交付成果项目文件组织过程资产六、项目人力资源管理过程名称输入工具和技术输出1、编写人力资源计划（规划人力资源管理）1、项目管理计划2、活动资源需求3、事业环境因素4、组织过程资产1、组织结构图和职位描述2、人际交住3、组织理论4、专家判断5、会议1、人力资源管理计划2、组建项目团队1、人力资源管理计划2、事业环境因素3、组织过程资产1、事先分派2、谈判3、招募4、虚拟团队5、多维决策分析1、项目人员分配表2、资源日历3、项目管理计划更新3、建设项目团队1、人力资源计划2、项目人员分配表3、资源日历1、人际关系技能2、培训3、团队建设活动4、基本规则5、集中办公6、认可与奖励7、人事测评工具1、团队绩效评估2、事业环境因素更新4、管理项目团队1、人力资源管理计划1、观察和交谈1、变更请求2、项目人员分配表2、项目绩效评估2、项目管理计划更新3、团队绩效评估3、冲突管理3、项目文件更新4、问题日志4、人际关系技能4、事业环境因素更新5、绩效报告5、组织过程资产更新6、组织过程资产七、项目沟通管理过程名称1、制订沟通管理计划（规划沟通管理）2、管理沟通3、控制沟通输入工具和技术输出1、项目管理计划1、分析沟通需求1、项目沟通管理计划2、干系人登记册2、信息传递方法的选择2、其他文档的更新3、事业环境因素4、组织过程资产1、项目沟通管理计划1、沟通渠道的选择1、项目沟通2、工作绩效报告2、信息传递方式的选择2、项目管理计划更新3、组织过程资产3、信息管理系统3、其他项目计划更新4、事业环境因素4、绩效报告4、组织过程资产更新1、项目管理计划1、信息管理系统1、工作绩效信息2、项目沟通2、专家判断2、变更请求3、问题日志3、会议3、项目管理计划更新4、工作绩效数据4、其他项目计划更新5、组织过程资产5、组织过程资产更新八、项目采购管理过程名称输入工具和技术输出1、编制采购计划（规划采购）1、项目管理计划1、自制外购分析1、采购管理计划2、需求文档2、专家判断2、采购工作说明书3、风险登记册3、市场调研3、采购文件4、活动资源要求4、会议4、供方选择标准5、项目进度5、自制外购决策6、活动成本估算6、变更申请7、干系人登记册7、项目文件更新8、事业环境因素9、组织过程资产2、实施采购1、采购管理计划1、投标人会议1、选择的卖方2、采购文件2、建议书评价技术2、合同3、供方选择标准3、独立估算3、资源日历4、卖方建议书4、专家判断4、变更请求5、项目文件5、刊登广告5、项目管理计划更新6、自制外购决策6、分析技术6、项目文件更新7、采购工作说明书7、采购谈判8、组织过程资产3、控制采购1、项目管理计划1、合同变更控制系统1、工作绩效信息2、采购文件2、检杳与审计2、变更请求3、合同3、采购绩效审查3、项目管理计划更新4、批准的变更请求4、报告绩效4、项目文件更新5、工作绩效报告5、支付系统5、组织过程资产更新6、工作绩效数据6、索赔管理7、记录管理系统4、结束采购1、合同1、采购审计1、合同收尾2、合同收尾程序2、采购谈判2、组织过程资产更新3、项目管理计划3、记录管理系统4、采购文件九、项目风险管理过程名称输入工具和技术输出1、规划风险管理1、项目管理计划1、分析技术1、风险管理计划2、项目章程2、专家判断3、干系人登记册3、会议4、事业环境因素5、组织过程资产2、识别风险1、风险管理计划1、文档审查1、风险登记册2、成本管理计划2、信息收集技术3、进度管理计划3、核对单分析4、质量管理计划4、假设分析5、人力资源管理计划5、图解分析6、范围基准6、SWOT分析7、活动成本估算7、专家判断8、活动持续时间估算9、干系人登记册10、项目文件11、采购文件12、事业环境因素13、组织过程资产3、实施定性风险分析1、风险管理计划2、范围基准3、风险登记册4、事业环境因素5、组织过程资产1、风险概率和影响评价2、概率和影响矩阵3、风险数据质量评估4、风险种类5、风险紧急度评估6、专家判断1、风险登记册更新2、假设条件日志更新4、实施定量风险分析1、风险管理计划2、成本管理计划3、进度管理计划4、风险登记册5、事业环境因素6、组织过程资产1、数据收集和表示技术2、定量分析和建模技术3、专家判断1、项目的概率分布2、实现成本和实现目标的概率3、量化风险优先级清单4、定量风险结果的趋势5、规划风险应对1、风险管理计划2、风险登记册1、消极风险或威胁的应对策略2、积极风险或机会的应对策略3、应急响应策略4、专家判断1、项目管理计划更新2、项目文件更新6、控制风险1、项目管理计划2、风险登记册3、工作绩效数据4、工作绩效报告1、风险再评估2、风险审计3、偏差和趋势分析4、技术绩效测量5、储备分析。
2023年下半年中级系统集成项目管理师《应用技术》(真题卷)第四批次
2023年下半年中级系统集成项目管理师《应用技术》（真题卷）第四批次[问答题]1.某智能医疗项目处于概念阶段，项目的发起人、战略分析经理和项目经理等人正在制定项目高层级目标，项目发起人期望将“人工智能（江南博哥）问诊自动生成”作为今年项目重点目标，战略分析经理基于商业洞察的结果，建议优先启动人工智能问诊。
人力资源主管提出目前公司不具备人员条件。
财务总监提出医疗专业的数据来源成本很高今年启动项目很难。
在之后的几次讨论中，管理各方意见不断变化，且难以达成共识。
项目进入计划阶段后项目经理组织团队制定选代计划，因为时间紧张，产品经理期望第一个选代完成需求池中40%的需求。
研发团队表示进入新的领域，时间紧张，技术挑战大，第一个送代只能完成需求池中20%的高优先级需求。
项目在执行的过程中，基于需求设计，架构设计师和算法工程师对模型算法的选择存在争议，并在会议室发生多次争吵，该技术难题导致推迟2周。
项目经理与研发资源主管和人力资源主管沟通，是否可以通过增加研发人员投入来保证研发任务完成，反复申请多次未得到解决，导致开发直接落后突破重重困难后，项目终于进入项目收尾阶段，因为项目任务难度大，前几个选代遗留很多严重的性能问题质量保证人员要求必须解决交付。
某研发人员认为此要求没有依据且未考虑研发的感受，表示个人强烈不满在项目例会上，研发负责人申请需要增加1周问题修复的时间以完成项目。
[问题1]分析案例，请列出项目各阶段遇到的冲突类型。
启动过程的冲突类型是()。
计划阶段的冲突类型是()。
执行阶段的冲突是()。
收尾阶段的冲突是()。
[问题2]分析案例，请列出案例中冲突产生的根源。
[问题3]请选择对应的冲突解决方法(1)()就是冲突各方一起积极地定义问题、收集问题的信息、制定解决方案，最后直到选择一个最合适的方案来解决冲突，此时为双赢或多赢。
但在这个过程中，需要公开地协商，这是冲突管理中最理想的一种方法(2)()就是以牺牲其他各方的观点为代价，采纳一方的观点。