涉众分析

ADM

主体依赖模型ADM（Actor Dependency Model）

目标依赖（goal dependency）：依赖者希望被依赖者满足一个条件，但不会规定怎样满足该条件。

软目标依赖（soft goal dependency）：一种特殊类型的目标依赖，其条件是无法量化描述的。

任务依赖（task dependency）：依赖者希望被依赖者执行特定任务。任务依赖比目标依赖更加具体，因为满足目标可以执行很多任务，被依赖者有自己的选择权。而任务依赖直接为被依赖者规定了任务。

资源依赖（resource dependency）：依赖者希望被依赖者提供资源实体（抽象信息或者实物材料）为自己所用，但不关注提供资源需要被依赖者执行的行为和解决的问题。

img

涉众评估

  • 基于涉众特征与态度化解涉众风险策略

    • 基于特征化解举例：亲子兴趣班

      • 大人与小朋友一起参与：环境设定者（客户）-> 参与者（用户）

      • 良好的产品体验打造亲子品牌：被影响者（潜在用户/客户） -> 参与者

    • 基于态度化解举例：电子竞技产业

      • 与地方政府文化产业发展相结合：强反对者 -> 强支持者

      • 成功的赛事运营与未成年人游戏时长限制：弱反对者 -> 弱支持者

image-20230217142953979

涉众共赢

img

阅文的免费模式能否与订阅模式共赢？

  • Issue：免费带来的更多流量与写手身份转换

  • Stakeholder对上述Issue的意见：

    • 头部与底部写手、普通读者：可以接受
    • 腰部写手：影响收入，进一步弱化保障
    • 核心读者：担忧文章质量下降

  • 如何共赢：免费与订阅在多大程度上共存

    • 免费创作与订阅写作区分开，但共存

    • 允许作者同时成为免费与订阅（特定连载小说）写手，或新手作者需先从免费写手做起

    • 其它可能达成共赢的Issue：利用免费阅读模式为平台引流（并分享给腰部及以下写手）

    • 其它较难达成共赢的Issue：平台对IP的强力掌控与作者本身的著作权主张

目标模型

img

需求获取

面谈

用户 / 客户对于自己想做什么是清晰的，需要尽力的从他那里抽取出完整的想法

问题类型

  • 开放式问题

    • 被会见者对答复的选择可以是开放和不受限制的，他们可能答复两个词，也可能答复两段话。
    • 在希望得到丰富（具有一定深度和广度）信息时，开放式问题比较合适

  • 封闭式问题

    • 答案有基本的形式，被会见者的回答是受到限制的

  • 程序性提示

  • 探究式问题

  • 诱导式问题

  • 元问题

  • ……

前期

  • 开放式问题为主

  • 决策层与专家为主

  • 遵循 问题à目标à解决方案路线

    • 问题、目标

    • 目标、任务（流程à任务）

  • 分析基本的涉众特点

    • 角色、任务、个人目标、频率、优先级

后期

  • 封闭式问题为主

  • 抓住主题与线索

    • 例如，任务分解、流程图、界面示意…

  • 问题针对性

    • 任务分解关系

    • 流程正确性、异常

    • 界面中的行为、数据项

    • …

  • 事先准备面谈记录材料

原型

为什么要使用原型

  • 软件工程中存在着大量的不确定性，原型、迭代和（方法）验证是人们解决不确定性的主要手段
  • 帮助需求工程师及早解决需求的不确定性

image-20230217152403433

过程

通过原型获取需求的过程通常包括以下几个步骤：

  1. 确定原型目的和范围

​ 在开始制作原型之前，需要明确原型的目的和范围，例如确定要实现的功能、界面设计、交互流程等等。

  1. 制作原型

​ 基于需求文档或用户故事，设计师可以利用原型工具制作可交互的原型。原型可以包括静态原型（即静态图像）和动态原型（即包含交互和动画效果的原型）。

  1. 与用户和利益相关者讨论原型

​ 将原型与客户和利益相关者共享，以获得反馈和澄清需求。原型可以在用户体验测试和质量保证过程中使用。

  1. 根据反馈修改原型

​ 在收集了足够的反馈和意见后，利用反馈来修改原型，以更好地表达和验证需求。

通过原型获取需求可以更好地了解用户需求，并帮助客户和利益相关者更直观地了解系统功能和交互。同时，原型还可以作为需求文档的一种补充，通过可视化的方式展示需求，使需求更加明确和具体。

风险

  • 原型开发工作投入太多的工作，使得开发团队消耗了过多的时间和过大的成本

  • 涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求

    • 不要将原型的功能开发的太好，以免用户提出“交付”的要求

  • 用户可能会被原型所表现出来的非功能特性遮蔽了眼睛，从而忽略了他们更应该重视的功能特性

观察

  • 应用于用户无法完成主动的信息告知的情况下

    • 采样观察（Sampling Observation）

    • 民族志（Ethnography）

    • 话语分析（Discourse Analysis）

    • 协议分析（Protocol Analysis）

    • 任务分析（Task Analysis）

需求分析

  • 需求细化

  • 确定需求优先级

    image-20230217155545464

面向对象建模

image-20230217161005147

概念类图

image-20230217161129004

image-20230217161354024

顺序图

image-20230217161515136

系统顺序图

image-20230217161627985

image-20230217162208969

image-20230217162219858

状态图

  1. 确定上下文环境

    • 搞清楚状态的主体常见的状态主体有：类、用例、多个用例和整个系统

  2. 识别状态，标记初始状态和结束状态

    • 可能会不存在确定的初始状态和结束状态

  3. 建立状态转换

    • 补充详细信息，完善状态图

需求验证与需求管理

需求验证基本活动

需求验证流程

image-20230217163539692

需求验证方法

  1. 评审
  2. 原型与模拟
  3. 开发测试用例
  4. 用户手册编制
  5. 利用跟踪关系
  6. 自动化分析

需求管理任务与活动

背景

需求的影响力贯穿整个后续的产品生命周期

任务

保证后续的系统开发活动依照需求的基线展开，从而保障系统的质量（质量就是对需求的依从性）。

活动

image-20230217163549917

需求变更控制过程、组织与注意事项

需求追踪矩阵

用户需求 功能性需求 设计组件 实现组件 测试用例
UC-28 Catalog.query.sort Class catalog Catalog.sort() Search.7 Search.8
UC-29 Catalog.query.import Class catalog Catalog.import() Catalog.validate() Search.12 Search.13 Search.14

控制过程

image-20230217163557096

组织

变更控制委员会（CCB），评价需求的变更，做出批准或者拒绝变化的决定，并确保已批准变化的实现。

注意事项

  1. 认识到变更的必要性，并为之制定计划
    1. 定义明确的变更控制过程，建立变更控制的有效渠道
    2. 所有提交的需求变更请求都要进行仔细的评估
    3. 是否进行变更的决定应该由变更控制委员会统一做出
    4. 必须对变更的实现结果进行验证
    5. 需求的变化情况要及时的通知到所有会受到影响的项目涉众
  2. 维护需求基线，审计变更记录
  3. 管理范围蔓延：根据业务目标、产品前景和项目范围，评估每一项提议的新增需求和特性
  4. 灵活应对变更请求：
    1. 推迟产品的交付时间
    2. 要求增派人手：在有限的情况下有效
    3. 要求员工加班工作：只能适度的使用
    4. 推迟或者去除尚未实现的优先级较低的需求
    5. 容许产品质量的降低：尽量不使用