目标模型

确定项目前景和范围

保证项目涉众以符合项目需要的角度描述现实世界，并以尽可能符合项目需要的方式描述事物和世界，方法是：

• 定义项目前景：所有的涉众都从共同认同的项目前景出发，理解和描述问题域及需求。
• 定义项目范围：范围内的事物和事件是描述的目标。

确定项目前景和范围的关键是定义业务需求和能够满足需求的高层解决方案，包括：

• 业务目标、目的
• 高层业务功能
• 每个高层业务功能所关联的高层数据
• 每个功能相关的项目设置
• 等等。。。

如果存在不同业务需求之间的冲突，那么在该阶段必须予以解决。

目标分析

面向目标的方法关注Why，深层次分析组织及其涉众的目标、候选方案和隐式因素。

目标是系统被开发的目的，它有着明确的定义方式，包括名称、类型、关注、定义、优先级、主体、拥有者等。

目标的类型

• 功能目标：描述系统的预期行为，包括满足型目标和信息型目标。
• 非功能目标：常见的有质量目标和约束目标。

软目标和硬目标：能否利用技术手段确认是否满足

实现目标（对应终止目标）、维护目标（对应避免目标）和优化目标。

目标格式

• 实现：若将来某一时刻Q为真（被满足），则目标实现
• 终止：若将来某一时刻Q为假（被终止），则目标实现
• 保持：将来任意时刻Q为真，则目标实现
• 避免：将来任意时刻Q为假，则目标实现
• 优化：最大化或最小化（目标功能）

目标关系

精化关系：一个高层次目标G可以精化为多个低层次目标Gi。

• 如果这些子目标的完成有助于目标G的完成，那么G与Gi间就是AND精化关系，此时任意两个子目标Gi和Gj是互补的。
• 如果子目标的完成能够直接保证G的完成，那么就是完备AND精化关系。
• 如果任意子目标都是G的替代方案，那么G与{Gi}之间就是OR精化关系。此时任意两个子目标Gi和Gj是互相替代的。

阻碍关系：如果子目标O的达成会导致高层目标G失败，那么O和G就是阻碍关系。

• 阻碍目标也可以AND精化和OR精化。
• 阻碍关系本身是特殊的精化——反向精化

目标之间的链接：

• Support链接表示支持作用（OR精化关系）
• Conflict链接表示阻碍作用
• ++：一个目标的成功可以直接保证另一个目标的成功
• +：一个目标的成功可以让另一个目标更容易成功
• -：一个目标的成功会使得另一个目标的成功更加困难
• –：一个目标的成功会直接导致另一个目标的失败

目标与主体的关系：

• OR Assignment：多个主体中的一个来完成
• AND Assignment：多个主体共同完成
• （AND/OR）Operationalization：目标实现过程中需要执行的操作

面向目标的方法

面向目标方法的处理过程：

• 高层目标的获取：现状和背景的分析（画布、评估）
• 低层目标的获取：需求获取和目标分析
  • 已有目标的验证和细化（基于目标分析）
  • 基于场景的方法等（基于目标实现）
• 目标分析：精化与分解
  • 建立系统的目标模型
• 目标实现

目标精化

1. 发现AND和OR精化关系
   • 同一个目标有不同场景（AND）
   • 完成目标有连续过程（AND）
   • 完成目标需要多方面配合（AND）
   • 目标有不同质量环境及表现（AND）
   • 多种可以相互替代的候选方法（OR）
2. 考虑阻碍实现的情况（Avoid目标）
3. 考虑已有目标之间的支持与冲突关系
4. 对高层目标问how，对低层目标问why，建立层次结构
5. 子目标开展到单一事务时终止——主体与系统的一次原子性协作
6. 识别目标隐含内容
   • 假设与依赖
   • 质量属性
   • 约束

目标实现

1. 将最底层目标分配给主体（人或系统）
2. 设计实现最底层目标的操作（任务：细粒度用例/场景）

涉众分析

涉众是所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的关键个人或团体。

涉众分析围绕一个组织的各个部门内的员工所负责的业务展开，所有的描述和胜败条件都和业务直接相关。

互联网产品的涉众：人性驱动，但也有围绕业务的利益冲突。互联网产品也需要展开基于业务的涉众分析：

• 某产品设计的新功能是否冲击其他功能或本公司其他产品
• 定期评估商业模式时，是否需要放弃某些客户细分
• 平台商业模式中如何补贴多个客户群体的收益刘
• 被产品影响的各监管力量和社会环境的态度

涉众识别

涉众类别需要细分，发现所有类别。每一类涉众的所有成员都能够一致、稳定的从相同立场、相同视角来看待相同的软件相同。

发现比较关键的涉众，需要分析他们各自的赢利条件。

涉众群体需要持续维护。

关键涉众类别判定：涉众互动。如果互动及其关注点属于项目的目标和范围，那么涉众就是关键涉众。

先膨胀后收缩

尽可能列出涉众后合并，简单但可能有遗漏

涉众网络

从容易发现的涉众出发，与初始涉众一起膨胀——收缩，集体确定关键涉众列表，再请列表的新代表加入讨论，直到列表稳定

检查列表

用户、客户、开发者、管理者、领域专家、政府力量、市场力量、维护人员。

容易操作但粒度太粗

主体依赖模型ADM

利用ADM分析涉众互动，识别关键涉众

• 目标依赖：依赖者希望被依赖者满足条件，但不会规定如何满足
• 软目标依赖：一种特殊的目标依赖，条件无法量化描述
• 任务依赖：依赖者希望被依赖者执行特定任务，比目标依赖更加具体
• 资源依赖：依赖者希望被依赖者提供资源实体，但不关注提供资源的实现方式和解决问题

涉众评估

优先考虑涉众的基本特征，尤其是任务特征。

基于涉众特征和态度化解涉众风险

Power—Interest模型

共赢分析

Stakeholder-Issue模型

1. 列出系统的所有涉众类别，明确描述他们的兴趣和对系统的期望
2. 从涉众们的兴趣和期望中发现共同问题（Issue）
3. 建立涉众类别和问题的关联。如果某个涉众类别对一个Issue存在兴趣，那么就存在关联关系
4. 对每一个Stakeholder-Issue关系，标明关系中寄予的期望

如果某个关系上的期望与项目的业务需求无法保持一致，那么关联的涉众就在该Issue上和项目整体目标存在冲突

• 涉众和项目负责人互相调整、折中
• 重新评估项目的可行性

如果某个Issue所关联的不同关系存在相互冲突的期望，那么就意味着它关联的涉众在该Issue上存在需求冲突

• 分析各冲突方成为项目赢家的条件
• 适当调整，化解冲突
• 分析项目在该Issue的目标、约束和可选方案，并提供给冲突方进行权衡，促进他们之间协商解决。

需求获取

面谈

问题类型

开发式问题

回答是开放和不受限制的。在希望得到丰富（具有一定深度和广度）信息时适合开放式问题。

优点：

• 让被会见者感到自在、更感兴趣
• 可以反应被会见者的思想情况
• 提供丰富细节
• 启迪进一步提问
• 允许会见者没有太多准备

缺点：

• 产生太多不相关细节
• 面谈可能失控
• 。。。

封闭式问题

答案有形式和限制。

优点：

• 节省时间、切中要点
• 保持控制
• 快速探讨大范围问题
• 得到确切数据

缺点：

• 使被会见者厌烦
• 得不到丰富细节
• 失去主要思想

其他问题

探究式问题、诱导性问题、双筒问题、元问题

问题准备

前期：

• 开放式问题为主
• 决策层和专家为主
• 遵循问题——目标——解决方案路线
  • 问题、目标
  • 目标、任务
• 分析基本的涉众特点
  • 角色、任务、个人目标、频率、优先级

后期：

• 封闭式问题为主
• 抓住主题和线索
  • 任务分解、流程图、界面示意
• 问题针对性
  • 任务分解关系
  • 流程正确性、异常
  • 界面中的行为、数据项
  • 。。。

需求分析

基本任务

建立分析模型

建立解决方案

需求细化

概念类图、顺序图、状态图

需求验证

评审

是主要的需求验证方法

原型与模拟

涉及到复杂的动态行为时使用，成本较高

开发测试用例

如果无法为某个需求定义完备的测试用例，那么它可能就存在着模糊、信息缺漏、不正确等缺陷

排斥性需求和全局性非功能性需求除外

用户手册编制

验证功能需求：对软件功能和实现的描述

验证项目范围：对系统没有实现的功能的描述

验证异常流程需求：问题和故障的解决

验证环境和约束需求：系统的安装和启动

跟踪关系

业务需求——用户需求——系统需求：如果前项需求没有后项需求的支持，那么PRD就有不完备的缺陷

系统需求——用户需求——业务需求：如果前项需求没有对应的后项需求，那么该需求就是非必要的

自动化分析

需求管理

需求跟踪

避免开发过程或演化过程中与需求基线不一致或者偏离的风险

需求跟踪矩阵

需求依赖

建立依赖矩阵来发现、管理和部署需求之间的关联关系

需求变更

过程

• 提请者提请需求变更
• 接收者接受变更请求
• 评估者进行变更评估
• 变更控制委员会进行变更决策
• 决定变更后，修改者执行变更
• 验证者验证变更

注意事项

• 认识到变更的必要性，并为此制定计划
• 维护需求基线，审计变更记录
• 管理范围蔓延
• 灵活应对变更请求
• 使用辅助工具