需求工程教学资料：Chap06 涉众分析与硬数据采样.pptVIP

3.4 涉众评估 优先级评估 基于涉众扩展特征进行涉众优先级的评估 3.4 涉众评估 风险评估 分析态度 3.4 涉众评估 风险评估 化解涉众风险策略 3.4 涉众评估 共赢分析 Stakeholder/Issue关系图 列出系统的所有涉众类别，明确描述他们的兴趣和对系统的期望； 从涉众们的兴趣和期望中发现背后涉及的共同问题（Issue）； 建立涉众类别和问题的关联，如果某个涉众类别对一个Issue存在兴趣，那么该涉众类别和这个Issue就存在关联关系； 对每一个Stakeholder-Issue关系，标明该关系上面所被寄予的期望； 3.4 涉众评估 共赢分析 Stakeholder/Issue关系图 共赢分析 Stakeholder/Issue关系图 如果某个Stakeholder-Issue关系上所寄予的期望与项目的业务需求无法保持一致，那么它关联的涉众就在该Issue的问题上和项目整体目标存在冲突 涉众和项目负责人互相调整、折中 重新评估项目的可行性 3.4 涉众评估 3.4 涉众评估 共赢分析 Stakeholder/Issue关系图 如果Stakeholder/Issue关系图中某个Issue所关联的不同关系标识有互相冲突的期望，那么就意味着它所关联的涉众在该Issue上存在需求冲突 分析各冲突方成为项目赢家的条件 适当的调整, 化解冲突 分析项目在该Issue上的目标、约束和可选方案，并提供给冲突方进行权衡，促进他们之间协商解决 利用目标模型深入涉众分析 将目标模型的Goal分配到Actor 根据Goal的优先级安排Actor的优先级 根据Goal的风险确定Actor的风险 根据目标分析深入分析Actor间的互动 发现Actor之间的冲突 根据Goal的冲突情况协商解决Actor间冲突 涉众的目标模型 基于目标模型的涉众互动分析 3.5 涉众选择 代表采样 完整采样: 每种涉众类别都有自己的代表 态度积极: 愿意提供帮助 数量适中 太少 : 个人看法倾轧群体共同看法 太多: 达成一致困难 代表数量的准确数字要视项目的上下文环境来确定, 一般6-10 比例恰当 计算机技能 业务技能 3.5 涉众选择 参与策略 让代表们在合适的时间参与合适的工作 3.5 涉众选择 用户替代源 因为业务关系而和用户频繁接触的人 ，能够代替他们发表看法 市场人员 服务咨询人员 技术支持人员 领域专家 3.5 涉众选择——用户参与 建立和用户的直接联系 用户参与软件系统开发的整个过程 反馈设计：最终的软件系统是和用户的活动行为密切相关的 优点 会有更精确的用户需求，进而提高了系统的质量 可以避免发生代价昂贵的系统故障 能提高用户对系统的接受度 用户能够更有效的理解和使用系统 可以提高组织内决策制定过程的参与度 缺点 采集和管理巨量原始数据会花费很多时间 需要解决直接接触用户和对设计施加影响的困难 用户通常不愿意在别人的观察下工作，而且研究发现用户在被观察时并不是真的在工作 难以安排对用户工作过程的观察 思考题 Phil Ittup是系统分析员团队中的一员，他受委任去与组织成员面谈，为系统研究收集材料。企业称为Fall Back工业，它有5个管理层。此外，生产、会计、营销、系统、物流和高层管理是将受到所建议的系统影响的职能区域。每个阶层大约有40人。生产层共有80人，会计层有35人，营销层有42人，系统层有10人，物流层有28人。高层管理有5人。Phil应该怎样选择面谈对象？为什么？ 思考题 案例1 案例2 实例 在开发过程中，因都是平时工作中接触的业务范围，因此开发时以为满足了功能需要，实现了软件预定的管理和统计功能，那么开发就是成功的 其结果是，在软件测试阶段，各等级的用户都反映出相对一致的意见。其中，反映最多的就是系统维护和操作太复杂，甚至经常报告说服务器和软件不稳定，不匹配。经认真调研，发现问题虽然有一点，但绝非基层报告的那么严重，软件应该是可以满足日常工作的。 结果：2003年，我处信息化还没有普及，尤其是基层领导，个别甚至是电脑盲。而我们的软件，为提高使用效率，设置了大量的快捷键操作方式，这让个别领导感觉难以接受。后来，我们对软件的操作界面和菜单进行了优化和简化，而用单选框选择代替了审批。通过一系列的修改和完善，反对该软件的人渐渐少了。 实例分析 在系统上线后，首先表达不满的是申请接水及变更业务的用户。我们发现，由于柜面人员需要向系统中录入申请信息并且扫描、上传部分重要文件，这延长了柜面办理业务的时间，造成用户业务申请的等待时间增长。 我们在涉众识别的时候，遗漏那些不使用系统（非参与者）但是被影响的人，——在本项目中就是直接到柜面申请接水及变更业务的人。然而接水及变更业务的