需求与商业模式创新-需求考试复习

Exam-需求

1. 需求工程导论

1. 软件的模拟特性源自知识载体的特性，不能没借书记录借了。
   1. 目的性：软件目标是直接或间接地满足用户的某些目的或者解决用户的某些问题
   2. 正确性：软件的功能能够保证目标的正确实现
   3. 现实可理解性：软件系统是在理解其现实环境的基础上，通过影响现实的某些环节，或者改变显示各部分的通信方式，最终达成某些目的或解决某些问题。
2. 不同类型软件的成功标准
   1. 面向专业用户的工具型软件:
      1. 首要成功标准：具有功能的复杂性和使用的高效性
      2. 目标：具有一定的创新优势而进行巧妙的功能安排
   2. 面向普通用户的工具型软件:
      1. 首要成功标准：功能的有用性
      2. 目标：进行方案权衡，寻找一套切实有效的功能配置
   3. 应用型软件:
      1. 基础是具有模拟性
      2. 目标：发现人们利用软件的原因(目的)，找出需要软件解决的问题。
3. 需求问题的具体原因
   1. 非技术型和社会性因素重视不足
      1. 需求处理的任务阶段：发现并解决问题
      2. 需求管理的手段角度：建模与分析技术
      3. 需求管理的过程阶段：矛盾冲突、涉众协商
   2. 传统需求分析方法的缺陷：核心是理解现实
   3. 软件规模的日益扩大：涉众增加、冲突激化
   4. 需求问题的高代价性
4. 需求工程：
   1. 需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效益。
   2. 任务：需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用的方式、方法所施加的限制和约束
   3. 活动
      1. 需求开发
         1. 需求获取
            1. 系统涉众
            2. 现有问题
            3. 系统目标
            4. 业务细节、用户需求
         2. 需求分析
            1. 目标、功能和约束映射为软件行为，建立系统模型
            2. 标识不一致缺陷，发现并弥补遗漏的需求
         3. 需求规格说明：完整、一致的需求与能够满足需求的软件行为以文档的方式固化下来。
         4. 需求验证
            1. 保证需求及文档的正确性
            2. 通过检查和修正，保持文档的完整性和一致性
            3. 所有涉众一致同意
      2. 需求管理：管理建立的基线
5. 系统工程与软件工程：系统需求开发阶段的需求被分配到软件工程、硬件工程和人力工程部分。
6. 需求工程的复杂性：问题域、目标、任务、交互的相互转化(广义的设计)是创造性的活动
   1. 处理范围广泛:需求工程连接现实世界和计算机世界。
      1. 理解现实世界
      2. 理解计算机世界
      3. 连接现实世界和计算机世界：产生互动效应
   2. 涉及诸多参与方
   3. 处理内容多样：各种类型的功能性和非功能性需求。
   4. 处理活动互相交织：四个需求开发活动相互交织
   5. 处理结果要求苛刻：包含错误、噪声、不切实际的需求都会导致灾难后果。
7. 需求工程师是涉众和开发者之间的桥梁
   1. 涉众代理
   2. 软技能

2. 需求基础

1. 需求的定义(IEEE)
   1. (用户的观点)用户为了解决问题或达到某些目标所需要的条件或能力。
   2. (开发者的观点)系统或系统部件为了满足合同、标准、规范或者其他正式文档所规定的要求而需要具备的条件或能力。
   3. 对1或2中的一个条件或一种能力的一种文档化表述。
   4. 注：需求是以用户为中心的，是与问题相联系的；需求要被清晰、明确地写在文档上。
2. 问题与需求
   1. 问题：现实的状况与人们期望的状况产生差距
   2. 解决问题的方法：就要改变这些事件、事物的状态，或者改变其状态变化的演化顺序，使其达到期望的状态和理想的演进顺序，使其达到期望的状态或演进顺序。
   3. 开发软件系统的目的：希望用它作为解决方案来解决问题，使得现实改善到期望的状况。
   4. 例子:企业当前利润率为2%，希望开发和应用一个软件系统能够利润率提高到5%。
      1. 问题：利润率低，低3个百分点
      2. 期望的状况：利润率为5%
      3. 需求：将利润率提高3个百分点或者将利润率提高至5%
   5. 问题域：解决问题所必须涉及的事件和事物(实体和状态)
   6. 问题域是需求的背景：要理解需求"将利润率提高到5%"，就需要明确利润是哪些部分组成的，分别是什么样的。
   7. 问题域的背景信息，又被称为问题域特性，关注间接特性、约束和假设，防止解系统引入导致的问题域中的未预见的连锁反应
   8. 问题域与需求
      1. 问题域是自治的，有自己的运行规律，这些规律不会因解系统的引入而发生改变
      2. 需求是一种对未来的期望，是可以打折、部分满足甚至不予满足的，比如将利润率提高到5%，我们可以部分满足，只提高到3%。
      3. 问题域特性是既定现实，可以改善但不能忽视，更不能违背的，比如问题域特性是用户的销售市场遍布全国，那么就不能只考虑一个地点的销售情况。
   9. 解系统：软件系统通过影响问题域帮助人们解决问题，软件起主要作用，核心是软件解决方案和解决方案在通过计算机上的实现
   10. 需求工程师"桥梁"：用户不关注软件系统，开发者关注解系统，以问题域为中心思考
   11. 需求：用户对问题域中的实体状态或事件的期望描述，尽可能使用问题域的语言
   12. 软件系统的需求规格说明：解决方案
3. 模拟与共享：
   1. 软件系统中的某些部分对问题域中的某些部分的具有模拟特性
      1. 解系统自身会保持一份与问题域现象一致的信息，并随问题域现象变化而变化
      2. 问题域期待在解系统中看到一致的信息，并由此展开自己的行为
   2. 共享现象：问题域与解系统能够形成互动的基础是解系统部分模拟了问题域的模拟性
4. 问题的解决方法
   1. 直接：模拟并操纵共享现象
   2. 间接：操作共享现象影响问题域的一部分，然后利用问题域内在规律性自动影响一部分。
5. 解系统解决问题的方案是改变共享知识，影响问题域的运行，进而满足用户的需求。
6. 问题解决方案——需求规格说明文档
7. 需求的层次性
   1. 业务需求：解决方案与系统特性
      1. 战略出发点
      2. 共同的前景
      3. 系统的范围
      4. 业务需求必须是可验证的
   2. 用户需求：问题域知识
      1. 描述了系统能够帮助用户做什么
      2. 用户需求是对任务的期望，基本表达方式"xx用户可以使用系统完成xx任务"
      3. 允许适度使用形容词
      4. 允许功能性和非功能性需求混杂。
   3. 系统级需求：需求分析模型
      1. 系统需求是用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求，适合软件开发者，是很精确的。
      2. 一般典型表述形式为"系统可以xxx"或者"在xx用户提出xx请求时，系统应该xxx"。
      3. 用户需求转换为系统级需求
         1. 分析问题域及其特性
         2. 将用户需求部署到系统模型中，定义系统的行为
8. 需求的分类
   1. 需求
      1. 项目需求：项目时间、项目成本
      2. 过程需求：过程方法、过程文件
      3. 系统级需求：系统工程的需求
         1. 软件需求
            1. 功能需求
            2. 性能需求：速度、 容量、吞吐量、负载、实时性等
            3. 质量需求：可靠性、可用性、安全性、可维护性、易用性
            4. 对外接口：硬件、软件、数据库接口、用户界面、通信接口
            5. 约束：限制开发人员设计和构建系统时的选择范围
               1. 系统开发及运行的环境
               2. 问题域标准：法律法规等
               3. 商业规则
               4. 社会性因素
            6. 其他需求：安装需求、培训需求、数据需求(功能需求没有描述的补充)
         2. 硬件需求：服务器规格
         3. 其他需求：人力资源(系统投入使用时，需要对用户进行1个星期的集中培训)、协同需求
   2. 不切实际的期望：不可行，做不到
9. 优秀需求的特性
   1. 完备性：各种相关属性是否齐全
   2. 正确性：真实反映用户的意图
   3. 可行性：可以实现
   4. 必要性：奥卡姆剃刀
   5. 无歧义
   6. 可验证

3. 需求工程过程

1. 常见的文档
   1. 项目前景和范围文档
   2. 用户需求文档
   3. 需求规格说明文档
      1. 系统规格说明
      2. 软件规格说明
2. 过程活动
   1. 需求获取：从人、资料或者环境当中获取需求的过程
      1. 收集背景资料
      2. 获取问题与目标，定义项目前景和范围
      3. 识别涉众，选择信息的来源
         1. 涉众分析
         2. 硬数据采样
         3. 相关的文档、专家
      4. 选择获取方法、执行获取
         1. 面谈
         2. 观察
         3. 原型
      5. 记录获取结果
   2. 需求分析：主要工作：建模来整合各种知识，以帮助人们更好地理解问题：信息的细化、为创造性活动提供支撑，完成内容的转化。最后产生需求的基线集。指定系统开发需要完成的任务。
      1. 背景分析
      2. 业务分析(问题分析、目标分析、涉众分析)，确定系统边界 (业务需求)
      3. 软件需求建模
      4. 细化需求
      5. 确定优先级
      6. 需求协商
   3. 需求规格说明：获取的需求需要被编写成文档，主要目的是为了在系统涉众之间交流需求信息，业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档(或者用例文档)，系统需求被写入需求规格说明
      1. 定制文档模板
      2. 编写文档
   4. 需求验证，标准：需求正确，反应用户的意图、完整性和一致性、可读性和可修改性。
      1. 执行验证：同级评审、原型、模拟
      2. 问题修正
   5. 需求管理：保证需求作用在整个软件的产品生命周期中的持续、稳定和有效发挥
      1. 建立和维护需求基线集：版本控制、标识、过程记录与传达
      2. 建立需求跟踪信息：前向跟踪和后向跟踪
      3. 进行变更控制
3. 需求工程过程示例
   1. 软件开发螺旋模型的需求开发过程
   2. 依赖于原型方法的需求开发过程
      1. 领域分析和原型开发属于需求获取活动。
      2. 基础及高阶模型开发属于需求分析活动。
      3. 同级评审、场景走查和涉众反馈属于需求验证活动。
   3. Practices-Based
   4. Agile RE
   5. RUP
4. 需求会极大程度上影响软件开发活动

4. 需求获取概述

1. 需求获取的常见困难：用户/客户与开发团队分离
   1. 用户和开发人员的背景不同，立场不同
      1. 知识理解的困难
      2. 默认(Tacit)知识现象
   2. 普通用户缺乏概括性、综合性的表述能力
   3. 用户存在认知困境：潜在知识，民族志、原型法
   4. 用户越俎代庖：用户提出的不是需求，而是解决方案
   5. 缺乏用户参与
2. 需求获取
   1. 研究应用背景，建立初始的知识框架
   2. 根据获取的需要，采用必要的获取方法和技巧
      1. 先行确定获取的内容和主题，设定场景
      2. 分析用户的高(深)层目标，理解用户的意图
   3. 进行涉众分析，针对涉众的特点开展工作
3. 需求获取的内容
   1. 需求
   2. 问题域特性
   3. 环境与约束
4. 需求获取的来源
   1. 涉众
   2. 硬数据
   3. 相关产品：原有系统、竞品、协作产品
   4. 重要文档
   5. 相关技术标准和法规
   6. 归纳获取源：人脑内知识、人脑外知识
5. 需求获取的方法
   1. 传统方法：问卷调查、面谈、硬数据分析、文档检查、需求剥离等
   2. 集体获取方法：头脑风暴(Brainstorming)、专题讨论会(Workshop)、JAD(Joint Application Development，联合需求开发)、JRP(Joint Requirements Planning，联合需求计划)等
   3. 基于上下文的方法：观察、民族志(Ethnography)和话语分析(Conversation Analysis) - 深入到用户之中，对其进行观察(第三者)
   4. 原型法
6. 防止需求遗漏：涉众意见、不要抽象和模糊、多种方式建模、边界检查
7. 结束判断条件：没有更多用例、导出用例、重复讨论、项目范围外、优先级低、不是本版本
8. 获取的结果
   1. 笔录：冗余、遗漏、自相矛盾、多种形式
   2. 正式文档
      1. 项目前景和范围文档
      2. 用例文档
9. 常见问题
   1. 边界错误或不明晰
   2. 边界控制失败
   3. 用户参与不足
      1. 认识不足
      2. 用户抵制
      3. 没有明确用户(替代源)
      4. 管理上的障碍
   4. 存在理解偏差：最好是面对面，非正式的电话交谈、正式的电话交谈(例如客户热线或者远程电话会议)、邮件、web反馈表、文档以及一些面对面的交流(例如JAD会议、原型等)
10. 选择需求获取方法的依据(表格)：方法有采样观察、非结构化面谈、结构化面谈、头脑风暴、原型、场景分析、民族志、群体面谈。
    1. 需求的目的
    2. 知识的类型：动态或静态，抽象或详细
    3. 知识内化的特性要求：新、潜在、场景、惯性和明显知识
    4. 可观察现象
    5. 约束

5. 确定项目的前景和范围

1. 为什么有确定项目的前景和范围
   1. 保证项目涉众以符合项目需要的角度描述现实世界：项目的目标就是业务需求
   2. 前景描述产品用来干什么，将所有的涉众都统一到一个方向，所有的涉众都从共同认同的项目前景出发，理解和描述问题域及需求。
   3. 范围指出了当前项目是要解决的产品长远规划中的哪一部分，限定了需求的界限，范围内的事物和事件是描述的目标。
2. 不同的业务需求之间存在冲突，则在确定项目前景和范围阶段必须予以解决。对于零售机问题
   1. 开发者重视技术
   2. 零售商要求简单直接投入使用
   3. 用户希望便捷和功能性
3. 确定项目的前景与范围就是确定项目的问题、目标、特性。
   1. 问题：业务需求
   2. 目标：问题的反面，用户的期望
   3. 特性：选定的、针对目标的解决方案所需要具备的功能特征，通常内聚于一个目标与任务，反映系统与外界一次有价值的完整互动过程(用户)
4. 分析过程的深入：问题分析、目标分析、业务过程分析
5. 还需要分析非功能需求，定义系统边界，生成前景与范围文档

5.1. 问题分析

1. 获取问题
   1. 收集背景资料或与涉众沟通：关注业务描述和统计数据。
   2. 与涉众沟通通过面谈实现。
   3. 对每个问题：发现问题 - 明确问题 - 发现业务需求 - 定义解决方案(功能&非功能)
2. 明确问题
   1. 包含元素：ID、提出者、关联者、问题描述、影响
   2. 调整为
      1. 易于理解：明确
      2. 能指明解决的方向
   3. 分析不明确的问题，发现问题背后的问题
      1. 直接咨询涉众
      2. 利用收集的资料和业务数据：使用鱼骨图列出所有的可能原因
3. 发现业务需求
   1. 明确一致的问题意味着业务需求，最重要的是可验证性。
   2. 在明确问题的元素基础上添加目标(问题解决的目标，即业务需求)
4. 定义解决方案及系统特性
   1. 建立问题解决方案，包含元素：方案描述、业务优势、代价(该解决方案带来的代价)。
   2. 定义系统特性：方案具备的功能特性(系统特性)、系统与外界一次有价值的完整交互过程，比如记录销售所影响的商品出库，掌握库存减少。
   3. 分析解决方案的边界：
      1. 面向对象：用例图，注意标识系统边界
      2. 面向结构：上下文图，关注解决方案与环境之间的信息流输入/输出
   4. 确定解决方案的约束：经济的、行政的、技术的、系统的、环境的、进度及资源的。
5. 商业模式与问题分析
   1. 画布的九模块与模块之间的联系抽取问题(问题分类)
   2. 商业模式内外评估与蓝海战略确定业务需求、系统特性、系统边界和约束(用于评估与量化的检查列表)
   3. 将生成的业务需求、系统特性、系统边界、开发啊约束与商业模式画布建立关系(可追踪性)

5.2. 目标分析

1. 目标：系统被开发的目的
2. 时序逻辑的常用操作符：下一个为真、未来有一个为真、未来均未真、为真直到另一个为假
3. 目标的描述包括
   1. 目标的分类
      1. 功能目标：期望系统提供的服务
         1. 满足型目标(Satisfaction Goal)：对行为者的满足
         2. 信息型目标(Information Goal)：对行为者的信息告知
      2. 非功能目标：期望系统满足的质量，常见的是质量目标(Quality goals)和约束目标(Constraint goals)、安全目标(Safety Goal)、性能目标(Performance Goal)、可用性目标(Usability Goal)等等
      3. 软目标：无法清晰判断是否可以满足的目标，可维护性，云朵表示
      4. 硬目标：通过借宿确认是否满足的目标，性能指标，矩形表示
   2. 非正式定义
   3. 关注
   4. 正式定义
4. 目标的主体：主题是环境中的主动部分。
   1. 如果主体只有软件，那么目标就是需求
   2. 如果主题只有系统环境的一个对象，那么目标就是假设与依赖
   3. 区分主体与拥有者：拥有者一般是涉众，拥有者不一定参与目标达成过程。
5. 目标规格的基本模式：实现、终止、保持、避免和优化
6. 目标模型的关系
   1. 精化
      1. AND精化：子目标完成保证父目标完成，合并画实心圆
      2. OR精化：子目标之间是可以相互替代的，分开画空心圆
   2. 阻碍：子目标达成会导致父目标失败，允许继续反向精化(AND/OR)
   3. 支持与冲突
      1. 支持：某一个目标达成会支持促进其他目标(可以被处理为OR关系)
      2. 冲突：某一个目标对于其他目标的实现有阻碍作用
      3. 通常会通过文字+符号表示
         1. ++ 保证
         2. + 更容易
         3. - 更困难
         4. -- 导致失败
7. 目标与主体：
   1. OR关系：多个主体中一个完成
   2. AND关系：多个关系中已通过完成
8. 目标与操作：操作也可以OR和AND精化
9. 目标与场景：Covers连接表示场景所涉及的所有行为都是目标包含的操作的子集
10. 目标与数据模型：Concerns表示目标与应用领域对象之间的关系
11. 目标分析过程(例子)
    1. 高层目标的获取：现状和背景的分析、问题与缺陷
       1. 背景资料
       2. 面谈(提问的为N层，那么回答为N+1层)、原型
       3. 硬数据类信息
    2. 低层目标的获取：需求获取与目标分析
       1. 已有目标的验证和细化(基于目标分析)
       2. 基于场景的方法等等(基于目标实现)
    3. 目标分析：精化与分解，建立系统的目标模型，使用Maintain、Achieve等
       1. 高层目标的AND精化
       2. 高层目标的OR精化
       3. 目标精化汇总
       4. 考虑阻碍目标实现的情况
       5. 考虑已有的目标之间的支持与冲突关系
       6. 对高层目标"How"、对底层目标"Why"
       7. 精化结束条件
          1. 子目标到单一事务
          2. 单一事务可以被进一步展开为场景
       8. 目标精化的约束
          1. 假设与依赖
          2. 质量属性
          3. 约束
    4. 目标实现：收集与目标相关的需求信息，讨论可能的候选解决方案，确定最终的系统详细需求和解决方案
       1. 将目标分配给主题
       2. 由实现设计最底层的任务
       3. 不在软件系统的不必细化

5.3. 基于目标模型获取非功能需求

1. 非功能需求获取困难
   1. 不集中、在系统中分散
   2. 不独立、依赖于功能需求
   3. 相互独立和依赖
2. 根本困难：不独立
3. 目标：非功能需求建模
   1. 早期为软目标，后期为修正为硬目标
   2. 通过支持、阻碍或精化功能目标，来体现依赖关系
   3. 单个非功能目标依赖多个功能目标，体现分散特性
   4. 通过支持、阻碍或精化非功能目标，描述不同非功能目标之间的折中关系
   5. 高层非功能目标精化为子非功能目标，描述非功能需求的层次结构关系
4. 建立步骤：标记为NFR
   1. 依赖功能需求识别、获取非功能需求目标
      1. 注意涉众对功能的描述：好用，易用性目标、小心谨慎，可靠性目标、数据比较多、计算复杂，性能目标、调整、修改、增加：可维护目标、数据敏感性：安全目标、关联技术环境：可移植性
   2. 根据非功能需求层次结构、精化非功能 需求目标
   3. 量化底层非功能需求目标的验收标准

5.4. 活动图

不考

5.5. 定义系统边界

1. 系统边界是系统与环境互动的界限，定义系统边界可以明确系统需要满足的与外界的交互行为，从而从宏观上界定了系统的功能概要。
2. 系统边界是需求工程后期阶段需求分析活动的起始模型，后期的需求分析可以看成是逐一细化系统边界中的对外交互行为的活动。
3. 边界目标：分配主体包含"将要构建的系统"和系统环境(涉众、硬件、其他系统等)的底层目标，这就意味着是系统边界定义要考虑的目标
4. 系统用例图中的系统边界用方框，里面写系统名称来完成界定。
5. 为什么要界定系统边界？系统与环境互动的界限，明确系统需要满足的与外界的交互行为，从而从宏观上界定了系统的功能概要。需求分析逐一细化系统边界中的对外交互行为的活动

5.6. 前景和范围文档

1. 业务需求：描述新系统可以为涉众带来的主要利益，说明了项目的最终目标
   1. 应用背景：描述原状、说明动机，必要时说明历史延续。
   2. 业务机遇：
      1. 如果是商业产品，则为市场机遇和要竞争的市场；如果是企业信息系统，则是业务问题和改进的业务流程，以及系统应用环境。
      2. 对已有产品和可能的接触方案进行评估，指出新产品优点(独特点)
      3. 说明产品是怎样符合市场潮流、技术发展。
      4. 说明还需要哪些技术、过程和资源。
   3. 业务目标：用可量化和可衡量的方式概述产品提供了哪些重要的业务利益。
   4. 成功标准：使用分级(理想、一般和最低)
   5. 业务风险：
      1. 与产品开发相关的主要风险，包括市场竞争、时间安排、用户认可、实现技术以及可能对业务造成的负面影响。
      2. 找到避免风险的必要措施。
      3. 包含可能性与影响。
2. 项目前景
   1. 前景概述
      1. 使用简洁的声明概括系统的长期目标和意图。声明反映能够满足不同涉众需求的平衡观点。
      2. 前景声明可以理想化，但应当以需求或市场现状、企业结构、团队战略和资源限制为依据。
   2. 主要特性：新产品的每一项主要特性或用户功能进行固定的、唯一的命名或编号，突出其超越原有产品或竞争产品的特性。
   3. 假设与依赖：
      1. 构思项目和编写文档过程中的涉众提出的每一项假设，保证各方达成一致。
      2. 记录项目对不再自身控制范围内的为外部因素的主要依赖关系，这类外部因素包含悬而未决的行业标准或政府法规、其他项目、第三方厂商以及开发伙伴等。
3. 项目范围
   1. 第一版范围：描述产品质量特性，产品依靠这些产品特性为不同类别的用户提供预期利益。如果开发能力有限，则将注意力集中在能够短时间内，以最适宜的成本，为大多数用户提供最大价值的特性。
   2. 后续版本范围：对于阶段性开发方式。
   3. 限制与排除：列出涉众可能希望得到，但是不在某个产品或特定计划中的功能和特性，比如xxx系统只能用于xxx
4. 项目环境
   1. 操作环境：描述在什么样的环境中，比如用户地理分布、访问时间、数据、响应事件、服务终端、安全性
   2. 涉众：不同类型的客户、目标市场和目标市场的用户类别
   3. 项目属性：涉众必须项目属性以及优先级达成一致，属性包括特性、质量、成本、进度和人员，上面的属性都有如下3个因素
      1. 驱动因素：重要的成功因素
      2. 约束因素：项目必须在一定限制下开展工作
      3. 可调整因素：可以根据其他方面平衡和调整的因素。
      4. 项目经理的目标：在约束施加的限制内合理安排可调整因素，获得最大的驱动因素。
      5. 任何情况下质量都不是应该被牺牲的项目属性，但是其他属性要根据具体需求安排优先级。
5. 词汇表
6. 参考资料
7. 附录

6. 涉众分析与硬采样

1. 涉众：所有能够影响软件系统的实现(系统决策者、开发者、利益所在者)或者会被实现后的软件系统所影响的(已有产品更新、全新产品开发)关键个人和团体(stakeholder)。
2. 业务驱动：围绕业务展开、和业务直接相关。
3. 涉众分析的差异性(视所开发系统的情况而定)
   1. 小型系统：
      1. 小型系统是指那些能够支持组织的部分工作，但又不会影响整个组织基础工作的信息系统，比如企业人事管理。
      2. 关注某个特定问题、功能固定、界限清晰
      3. 涉众有限且明显，默认涉众处于就绪态，不需要专门进行涉众分析。
   2. 组织级系统：
      1. 其功能能够影响整个组织基础工作的系统，它的功能在质量上和小型系统有着明显的差异。
      2. 影响用户群体之外的其他群体，甚至改变现存权利结构
      3. 发现直接和间接群体，防止抵制，尤其要发现那些不直接与系统互动，但会间接影响系统或被系统影响的群体。
   3. 战略信息系统：
      1. 作为组织战略决策而得以开发的系统
      2. 无法根据现有的业务和技术状况来确定系统将来的应用效果。系统的影响范围也难以确定，涉众数量更多而且更加难以确定，在业务环境内分析各种可能的机遇和风险，并据此发现可能的涉众，防止抵制
      3. 分析组织内各类人群的互动关系，各种风险/机遇对既有互动关系的影响
   4. 组织间系统(Inter-Organizational Systems)
      1. 通过系统自身的实施建立或增强组织之间的合作关系
      2. 系统的很多决定不是单个组织所能控制的
      3. 在主动参与和抵制系统的问题上有着更多的困难
      4. 涉众比组织内系统的涉众更加难以寻找和选择
      5. 考虑组织之间的合作关系和利益分配方案，在组织的大框架下进行涉众的寻找和选择
      6. 分析组织间的互动关系，分析关系到组织间互动的各类人群在组织内的互动关系
4. 互联网产品：人性驱动
   1. 如何补贴多个客户群体的收益流
   2. 冲击其他竞品

6.1. 涉众识别

1. 发现所有涉众类别：一致稳定、相同立场、相同视角看相同软件系统
2. 发现关键涉众(影响关乎软件系统成败)：各自赢输条件、共赢、根据任务区分，分析关键涉众的标准：一个涉众类别的任务或他们与外界的交互活动是否属于项目范围，服务于业务需求的满足。
3. 持续维护涉众群体
4. 识别方法
   1. 先膨胀后收缩：根据收集到的背景资料尽可能多的列举，然后尽可能的合并涉众。
   2. 检查列表
      1. 用户：关注软件功能
      2. 客户：成本、效益(用户替代源)
      3. 开发者：实现软件系统
      4. 管理者：关注系统开发进程
      5. 领域专家：关注软件中的知识
      6. 政府力量：法律法规、长远规划等；约束和指导
      7. 市场力量(用户替代源)
      8. 维护人员：关心系统的非功能性属性
   3. 涉众网络
      1. 涉众：节点，互动：边
      2. 从看容易发现的涉众出发(涉众基线，如客户等)
      3. 头脑风暴
      4. 对得到的涉众列表分析相关性，分析时要将其与软件系统联系起来，这个网络包含了涉众与软件系统之间的交互以及涉众之间的交互，确定各个涉众类别和软件系统的相关性、关键性，最后缩减成一个涉众列表。

6.2. 涉众描述

1. 简单特征：包括个人特征和工作特征
2. 复杂特征：包括关注点、兴趣去向、重要性、影响力、输赢条件和受影响程度。
   1. 对项目的关注点和兴趣所在，态度是反对还是赞同
   2. 对项目的期望，成为项目赢家的条件
   3. 可能受到的项目的影响，影响的具体内容及影响程度
   4. 可以对项目施加的影响，力量的施加点及其强度
   5. 关注：主要目标、态度、主要关注点和约束条件

6.3. 涉众评估

1. 涉众类别划分优先级：尤其是任务特征，使用功能越多、越频繁、越大规模的用户群体优先级越高。
2. 涉众优先级评估：Power-interest图
   1. 参与者：系统的实际使用者，对系统成功有较大影响力，对系统也有较大影响力，优先级最高。
   2. 环境设定者：很少使用系统，但是由于政治、经济等因素对系统有比较大的影响，优先级次之，最常见的是政府和管理者。
   3. 被影响者：可能是系统直接使用者，也可能是因为系统出现被剥夺了部分利益的输家，受影响大，能影响少，优先级一般低于环境设定者，但是特殊情况下也可能高于环境设定者。
   4. 观众：不受影响，也不影响，优先级最低，比如环境专家和市场力量。

2. 不同涉众类别的风险:Power/Attitude图
   1. 强反对者是需要重点分析的。
   2. 涉众的关注点和兴趣去向也是重要内容，一般环境设定者是项目高风险因素。
   3. 对于高风险的涉众类别，要尽可能澄清各个涉众类别的角色和职责，发现项目对他们的依赖和假设条件，分析实际情况与预期不一致时可能出现的风险，并提前化解。

3. 化解涉众风险
   1. 一方面提高环境设定者对系统的关注，转化为参与者
   2. 一方面消除强反对者的反对原因，变为强支持者
   3. 给予被影响者一些发表和实现自身意见的权利，环节忧虑。

4. 分析涉众冲突，实现共赢
   1. 发现冲突：Stackholder/Issue关系图
      1. 列出所有涉众类别：描述兴趣和对系统的期望
      2. 从兴趣和期望中发现背后的共同问题
      3. 建立涉众类别与问题的关联，如果某个涉众类别对Issue感兴趣，则这个涉众类别和Issue存在关联关系。
      4. 对每一个StackHolder-Issue关系，表明关系上被寄予的期望。
         1. 如果期望和业务需求冲突，则调整和折中，重新评估项目可行性
         2. 如果Issue关联的不同关系标识有互相冲突期望，则意味涉众在Issue上有需求冲突，分析同时成为项目赢家的条件，分析目标、约束等给冲突方进行权衡。
   2. 免费与订阅模式的共赢：分拆，免费引流、IP与著作权管控
5. 手机游戏的参与者、环境设定者、被影响者、观众？如何化解风险？
6. 手机游戏的强支持者、强反对者、弱支持者、弱反对者？如何化解风险？

6.4. 涉众代表选择：从每种涉众中该选择代表

1. 完整采样
2. 态度积极
3. 数量适中(6-10)
4. 比例恰当
5. 使用用户替代源
   1. 系统分析人员
   2. 技术支持人员
   3. 服务咨询人员
   4. 顾问
   5. 用户方管理者
   6. 市场人员等

6.5. 制定涉众代表参与需求开发乃至软件系统的参与策略

1. 让代表们在合适的时间参与合适的工作
2. 使用敏捷方法，建立起和用户的直接联系，用户参与软件系统开发的全过程
   1. 为其设计
   2. 与其设计
   3. 由其设计

6.6. 利用目标模型进行涉众分析

1. 目标模型框架I*
2. 将目标模型的Goal分配到Actor
   1. 根据Goal的优先级安排Actor的优先级
   2. 根据Goal的风险确定Actor的风险
3. 根据目标分析深入分析Actor间的互动
   1. 发现Actor之间的冲突
   2. 根据Goal的冲突情况协商解决Actor间冲突
4. 根据目标的优先级安排主体的优先级。
5. 根据目标的风险确定主体的风险。
6. 根据目标分析深人分析主体间的互动:
   1. 根据目标冲突可以发现深层次的主体冲突。
   2. 根据目标的冲突情况协商解决主体间的冲突。

6.7. ADM模型

1. 目标依赖(goal dependency)：依赖者希望被依赖者满足一个条件，但不会规定怎样满足该条件。
2. 软目标依赖(soft goal dependency)：一种特殊类型的目标依赖，其条件是无法量化描述的。
3. 任务依赖(task dependency)：依赖者希望被依赖者执行特定任务。任务依赖比目标依赖更加具体，因为满足条件可以执行很多任务，被依赖者有自己的选择权。而任务依赖直接为被依赖者规定了任务。
4. 资源依赖(resource dependency)：依赖者希望被依赖者提供资源实体(抽象信息或者实物材料)为自己所用，但不关注提供资源需要被依赖者执行的行为和解决的问题。
5. 每个主题的期望都需要由其他主题来满足，每个主题提供的资源、职责要由其他主题来消费，联合起来就可以充分、完备描述涉众之间的互动，了解涉众的社会互动性。

6.8. B站的涉众分析

1. 一般Up主与观众：目标是流畅、有趣的中视频观看，任务是为平台带来流量和关注度，占用大量带宽和审核资源，被补贴
2. "二次元"核心Up主与观众：目标是垂直、核心的动漫内容消费，任务是为平台带来收益和核心社区，强力的粘性消费补贴平台其他用户
3. 前者追求流畅视频体验(软目标)、占带宽多(资源)，产品粘性与消费能力较弱(任务)；后者则相反(高粘性游戏运营，主要收入)
   1. 后者在事实上补贴前者，需要注意(A站欢迎回家)
   2. B站策略：大会员+社区+电商 VS 宅向内容与营销

6.9. 硬采样

1. 硬数据类型
   1. 定量硬数据
      1. 数据收集表格
      2. 统计报表
   2. 定型硬数据：整个组织的描述文档，门户网站、组织结构图
2. 采样数量
   1. $样本大小=p\ast (1-p)\ast (\frac{确定性因子}{可接受的错误}{)}^2$
   2. P是差异样本比例，未知的情况下设为0.25

7. 基于用例/场景模型展开用户需求获取

1. 多轮获取要点
   1. 前景与范围阶段
      1. 准备：背景资料获取与分析
      2. 第一轮：问题分析(深入)
      3. 第二轮：高层解决方案制定(确认)
   2. 用户需求获取阶段
      1. 准备：明确主题与内容，准备材料
      2. 第一轮：明确任务与任务中主要问题(深入)
      3. 第二轮：明确任务细节，澄清困难内容(技巧、困难)
      4. 第三轮：明确解决方案(确认)
2. 获取方法
   1. 面谈：常规方法
      1. 集体面谈：快速方法
      2. 调查表：用户分散
      3. 头脑风暴："发明"需求
   2. 不确定性：原型
   3. 情景性：观察

7.1. 需求获取活动主线索——用例/场景模型

1. 目标模型用于组织系统的目标、特性、任务等与业务需求相关的内容,目标分析过程是建立目标模型并验证其正确性、完备性、一致性的过程。
2. 用例/场景分析无法完成对用户需求相关内容正确性、完备性、一致性的验证
3. 面向对象分析模型或结构化分析模型用于描述软件解决方案的细节知识，组织和指导系统级需求的建立。面向对象分析或结构化分析是建立面向对象分析模型或结构化分析模型的过程，同时还能够验证用户需求相关内容的正确性、完备性和一致性。

7.2. 用例/场景

1. 为什么使用场景/用例?
   1. 场景是更为基本的元素，用例是一种特殊场景，是需求工程师在组织需求是更喜欢使用的场景类型。
   2. 场景强调系统同外部环境互动以完成预期任务，具有重点描述真实世界(商业模式设计：讲故事->场景)的特征，它利用情景、行为者之间的交互、事件随时间的演化等方式来叙述性的描述系统的使用
   3. UML将用例定义为"在系统(或者子系统或者类)和外部对象的交互当中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务"。
   4. 每一个行为序列成为一个场景。一个用例是多个场景的集合，用例承载了目标相关的成功和失败的场景。
2. 用例驱动
   1. 用例/场景：更易于涉众接受
   2. 用户需求：更易于开发者接受
3. 用例包含：用例标识名称、用例属性、参与者、描述、触发条件、前置条件、后置条件、正常流程、分支流程、异常流程、相关用例、业务规则、特殊需求、假设、TBD
4. 场景/用例缺点
   1. 只考虑其他内容与功能需求之间的联系，却无法描述其他内容相互之间的联系，例如质量需求的相互依赖(目标模型)、界面需求的跳转(对外接口中的人机交互文档)、对外接口需求与质量需求的联系(IF作为主体承载目标实现)…
   2. 只考虑存在联系的事实，却无法分析联系的合理性，例如有无遗漏功能需求、数据需求及业务规则是否充分、质量需求是否可行(需求分析)
5. 用户/场景是有层次性的，可以描述业务需求、用户需求和系统级需求。

1. 内容
   1. 主要关注点：关于现在的，关于未来的，关于解决方案的
   2. 环境范围：
      1. 系统内部的行为细节
      2. 系统和应用环境交互
      3. 系统和外部环境交互
      4. 提倡把组织背景、文化背景和目标等环境上下文信息描述包括在场景的内容中国。
   3. 抽象层次
      1. 具体的(实例场景)：对个别行为者、事件、情节的细节描述，很少或完全没有抽象内容，张三去某个ATM取1000元钱
      2. 抽象的(类型场景)：以经验中的类别和抽象概念来描述事实，储户在ATM上取钱。
      3. 混合的：部分具体部分抽象，储户要从ATM中取1000元钱。
   4. 覆盖范围：功能需求，非功能需求
   5. 粒度
      1. 整个业务过程(前期)
      2. 某个任务的完成过程(中期)
      3. 某个交互行为的详细处理步骤(后期)
   6. 示例类型
      1. 正常流程
      2. 异常流程
2. 场景的目的
   1. 描述
   2. 探索
   3. 解释
3. 模糊、不正确、不完备等细节内容需要再获取

7.3. 用例图

1. 用例
2. 参与者
3. 关系
4. 用例扩展、包含、泛化
5. 参与者泛化
6. 系统边界
7. 用例逐步完善，直到可以绘制系统顺序图和概念类图

8. 面谈

1. 准备面谈
   1. 准备工作
      1. 背景资料(权威性、三家企业、互联网)
      2. 确定面谈主题和目标
      3. 选择被会见者
      4. 通知被会见者：正式途径
      5. 确定问题和类型
   2. 面谈准备的关键：问题类型
      1. 开发式问题
         1. 感到自在、丰富细节、让被会见者更感兴趣、启迪
         2. 失控、看上去没有准备、细节过多
      2. 封闭式问题
         1. 节省时间、切中要点、控制、确切
         2. 厌烦、细节时候、不能建立友好关系
      3. 探究式问题
      4. 诱导式问题
      5. 双筒问题
      6. 元问题：我的问题看起来相关吗等
      7. 程序性提示：
         1. 总结和反馈
         2. 重复和改述
         3. 建立场景和细节描述
         4. 抗辩
   3. 问题准备
      1. 分析基本的涉众特点：角色、任务、个人目标、频率、优先级
      2. 前期开放，后期封闭
   4. 背后要点：取得共情与目标的平衡
2. 主持面谈
   1. 开始：良好氛围
   2. 进行：信息交流、进程、调整、观察、保持主题
   3. 结束：感谢、回答、亲善和信任
   4. 记录面谈
      1. 内容：事实和问题、被会见者的观点(是否夸大)、感受(了解文化、提高自信)、组织和个人的目标(硬数据和目标)
      2. 笔录
      3. 录像和摄影
3. 处理面谈结果
   1. 复查面谈记录
   2. 总结面谈信息
   3. 评估面谈信息
   4. 完成面谈报告，包括主题、会见目标、谈话要点、被会见者的观点、下次会见目标
4. 面谈类型
5. 面谈优点和缺点
6. 群体面谈
   1. 涉众
   2. 主持人：控制者、需要经验、协调冲突解决
   3. 负责人：地位较高的管理者、涉及的不通过部门和用户
   4. 分析人员：倾听发现系统需求，暂时主导会谈
   5. 记录人员：记录会议上讨论的每件事情，需要能使用CASE工具，和分析人员可能重合。
   6. 观察员：倾听角色，除非被邀请主动发言、面谈后帮助记录人员整理会议记录。
   7. 时间：全天2-4天
7. 调查问卷：面谈方法以口头语言为主要的交流媒介，而调查问卷以文档为主要的交流媒介
8. 头脑风暴：目的不是发现需求，而是发明需求，或者说是发现潜在需求
   1. 发明并描述以前不存在的全新的业务功能：之前不存在该业务
   2. 明确模糊的业务：某项业务是比较模糊混乱的
   3. 在信息不充分的情况做出决策：对各种情况进行考虑和衡量
9. 确保共同理解

9. 原型

1. 解决不确定性：原型、迭代和验证
2. 原型是一个系统，它内化了(capture)一个更迟系统(later system)的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。
   1. 如果在最终的物件(final artifact)产生之前，一个中间物件(mediate artifact)被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。
   2. 包括书面描绘、场景叙述、情节串联图板、幻灯演示、动画模拟、屏幕快照和程序代码等在内的各种被用来探索和论证软件系统功能的物件都是软件的原型
3. 软件工程中的原型：
   1. 演示原型
   2. 严格意义上的原型
   3. 实验原型
   4. 引示系统原型
4. 方法过程
   1. 确定原型需求：
      1. 为什么、起点、结束标准？
      2. 界定不确定性
      3. 明确不确定的维度：外观(具体感觉体验)、角色(为什么有用)和实现
   2. 原型开发：低成本、易修改
   3. 原型评估：无偏见环境、是否一致、评估者反应建议、创新思想
   4. 原型修正
5. 使用要点
   1. 坚决抛弃抛弃式原型
      1. 抛弃式：探索式、实验式
      2. 演化式
   2. 控制原型成本：
      1. 水平和垂直两个方向
         1. 水平原型：它仅仅实现选定功能所有层次中的某些特定层次
         2. 垂直原型：它会触及到选定功能实现的所有层次
      2. 使用简单介质：低保真原型
         1. 纸面原型
         2. 幻灯动画介质
   3. 善用故事板原型
      1. 角色、内容、方法
      2. 被动、主动、交互
   4. 控制原型法风险
      1. 避免成本失控
      2. 避免给用户错误印象(已经完成)
      3. 注意非功能需求
      4. 注意用户假设

10. 观察和文档审查

10.1. 观察

1. 应用于用户无法完成主动的信息告知的情况下
   1. 采样观察(Sampling Observation)：传统且简单，对特定时间段或特定事件进行观察。
      1. 最简单
      2. 时间采样：不同时间间隔来观察用户
      3. 事件采样：不同事件维度来观察用户，获取默认知识
   2. 民族志(Ethnography)：长期且浸入式，观察者深入用户较长时间
      1. 民族志要求人类学家花费长期的时间在被研究的社会中生活并且仔细观察该社会中的实际活动，得到第一手的观察数据。
      2. 典型示例是复杂的协同问题，这些问题往往具有一定的社会性、突现的情景性。
      3. 优点：可以深度理解信息，可以让真实世界的社会性因素可见化、打破人们已有的错误假设和观念
      4. 缺点：耗时、数据量大难以传递到开发环境
      5. 针对复杂协同问题的民族志
         1. 工作的分布式协同：人们的工作协同、注意硬数据、观察如何协同、分工职责、对他人评价等等。
         2. 工作的计划和程序：细节步骤和过程，集成满足整个工作的要求，发现实际和文档化程序的偏离。核心是计划和程序
         3. 工作的意识：指活动的某种组织方式，活动对协同的其他人可见和可以被理解，比如个人空间布局、个人对他人的监控、如何保证自己工作可见。
      6. 规则：
         1. 定期记录发现
         2. 尽快记录过程中面谈
         3. 定期的复查和更新自己想法
         4. 确定管理海量数据的策略
   3. 话语分析(Discourse Analysis)：对用户交谈行为观察，观察和分析交互方式或特定话语分析
   4. 协议分析(Protocol Analysis)：对用户任务的观察，一边观察对象一边执行任务
   5. 任务分析(Task Analysis)：对人机交互行为进行的观察，引入相关的模型方法来观察、记录和执行用户与软件系统的交互行为。
2. 情景性：
   1. 突现(Emergent)：事件由集体促成，在互动中突现，不要局限于个人视角
   2. 局部(Local)：特定的上下文环境，脱离上下文可能无法形成准确的理解
   3. 暂时(Contingent)：演进过程中的一刻，事件及其解释依赖于当前的情况
   4. 涉身(Embodied)：需要了解参与者的认知和能力是受限的
   5. 开放(Open)：业务不确定并开放，以后完善
   6. 模糊(Vague)：事件的解释不会特别详细，基于潜在知识，尚未明确表达，需求工程师难以理解。
3. 观察关注问题的上下文环境，也就是社会因素，包括组织的文化、组织的结构、用户的工作环境、用户的工作实践、法律与政策约束等。

10.2. 文档审查

1. 相关产品的需求规格说明文档：需求重用
   1. 问题域消息：不因系统引入而转移
   2. 用户界面特征：人机交互习惯
   3. 业务需求、组织策略和政策法规等
2. 硬数据：文档分析，进行定量分析，组织业务工作流程，注意文档不一定完全正确
3. 客户的需求文档：需求剥离，手工或剥离工具

11. 需求分析概述

包括面向过程建模、数据建模和面向对象建模

11.1. 根本任务

1. 建立分析模型，达成开发者和用户对需求信息的共同理解：确定本质特征，获取某个可以转换为知识的事物信息，即建模——建立需求分析模型。
2. 依据共同理解，发挥创造性，创建软件系统解决方案：将问题分解成独立、更简单和易于管理的子问题

11.2. 建模

1. 抽象
2. 分解
3. 投影
4. 模型是对复杂系统的简化和抽象，关注特定的组元和组元之间的关系，同时忽略与组元无关的次要信息。

11.3. 两个世界与三种模型

1. 计算世界与计算模型
   1. 使用软件的构成单位作为模型的组元
   2. 软件构建单位之间的关系作为模型组元之间的关系
   3. 计算模型：使用的组元和组元间关系都是软件的元素，是来自软件(计算世界)的模型。
   4. 计算世界基于计算科学建立的，具有形式化的特征，信息的描述具有明确化、准确化和确定化的特征
   5. 需求阶段不适合建立
2. 问题世界与业务模型
   1. 使用问题域中的重要概念作为模型的组元
   2. 使用概念之间的业务联系作为组元之间的关系
   3. 使用了业务描述的方式，具有非形式化特征
3. 软件分析模型(分析视图)
   1. 介于计算模型和业务模型二者之间的模型形式
   2. 分析模型使用了计算模型的组元形式，描述解决方案时具有比业务模型更加严谨和适用的描述方式。
   3. 分析模型在组元的表现上使用了业务模型的表现方式
   4. 分析模型是半形式化的

11.4. 需求建模

1. 需求分析的关键就是为真实世界的问题建模，即问题域模建模。
2. 常见影响因素
   1. 问题域模型：实时应用(流)/信息系统应用
   2. 需求分析人员的技能
   3. 客户的过程需求
   4. 方法和工具的可用性
3. 通常的做法是：
   1. 先依据获取的问题域信息建立初步的模型。
   2. 然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。
   3. 最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。
4. Wieringa框架
   1. 功能性-通信式-行为式描述
   2. 系统对外交互-系统内部交互
5. Zachman框架

11.5. 需求细化

1. 用户需求细化
2. 非功能需求细化

11.6. 需求的记录

1. 标识符(ID)，每一条需求都应该能够通过ID唯一的标识自己。
2. 源头(Source)，要能够回溯到需求的源头，例如特定的涉众。
3. 理由(Rational)，需求被提出的目的。
4. 优先级(Priority)
   1. 资源有限、分阶段开发
   2. 累计投票、区域划分(按特性)、Top-N、数据量化
5. 成本(Cost)，预估的实现成本。
6. 风险(Risk)，实现该需求的过程中可能带来的风险。
7. 可变性(Volatility)，将来发生变化的可能性。

11.7. 需求协商

1. 明确冲突的因素，避免情绪上的冲突
2. 明确冲突的解决空间
3. 确定最佳解决方案

12. 过程建模

1. 数据流图
   1. 外部实体、过程、数据流、数据存储
   2. 上下文图：
      1. 低于0层图一般不显示外部实体
      2. 分解过程中，输入输出要平衡
2. 微规格说明
   1. 结构化自然语言
   2. 行为图
   3. 决策表
   4. 决策树
3. 数据说明：数据字典，包括名称、别名、使用的地点与方法、描述和格式
4. 模块结构图
   1. 功能分解图：自上而下分解
   2. 过程依赖图：数据、资源、约束依赖

13. 数据建模

1. 实体关系图
   1. 识别并筛选实体
   2. 确定标识符
   3. 发现行为
   4. 发现弱实体和关联实体
2. 结合硬数据表单生成实体关系图
3. 实体关系图与过程模型的关系：功能/实体矩阵

14. 面向对象建模

1. 对象：对象是指在一个应用当中具有明确角色的独立可确认的实体
   1. 包含标识、状态和行为
   2. 成为对象的条件：独立可确认、明确的角色和职责
   3. 链接：对象之间的物理或业务联系
   4. 可见性

14.1. 类

1. 类是共享相同属性和行为的对象的集合，它为属于该类的所有对象提供统一的抽象描述和生成模板
   1. 抽象描述称为接口(Interface)，定义了类所含对象对外的(其他类和对象)的统一协议
   2. 生成模板称为实现(Implementation)，说明了类所含对象的生成机制和行为模式
   3. 分类：数据驱动与职责驱动(选用)
2. 类之间的关系：
   1. 关联：连线
   2. 聚合与组合：聚合(Line & Point)是空心菱形，组合(Hand & Finger)是实心菱形
   3. 继承：空心三角

14.2. 领域模型(概念类图)

1. 不包含行为的类图
2. 过程
   1. 识别候选对象与类
      1. 概念类分类列表
      2. 名词分析
      3. 行为分析
   2. 确定概念类：状态与行为
      1. 属性的复杂度问题：二维限制不应该出现在面向对象建模中，比如图书中的作者是一个复杂属性，我们也不应该将其抽象为一个对象，因为他没有自己的行为。
      2. 人们易于武断的将单值状态类抽象为其他类的属性：比如价格之于商品，价格本身可能会有一定的行为。
   3. 建立类之间的关联
   4. 添加类的重要属性

14.3. 顺序图

1. 组合片段
   1. opt:可选
   2. alt:多选一
   3. loop：循环
   4. break：满足条件执行其中语句后退出顺序图
   5. par:交织并行
   6. critical:关键原子操作，不可以被破坏
   7. strict:必须顺序执行
   8. seq:不同时间线上可以按照任意序

14.4. 通信图

14.5. 系统顺序图

14.6. 状态图

1. 确定上下文环境
2. 识别状态，标记初始状态和结束状态
3. 建立状态转换
4. 补充详细信息，完善状态图

14.7. OCL

1. 类型：多种数据类型
2. 表达式
3. 保留关键字
4. 辅助状态图
5. 建立契约说明，说明行为
   1. 操作
   2. 引用
   3. 前置条件
   4. 后置条件

14.8. CRC

1. CRC是Candidates、 Responsibilities和 Collaborators三者的缩写
2. 基于CRC可以建立一种索引卡片，被称为CRC卡，每个卡片代表了一个被发现的候选对象
3. CRC卡简洁方便，可以随时被移动、修改或者丢弃，所以它特别适合于在复杂的系统当中进行对象的发现和设计思想的挖掘，即进行复杂情况下的面向对象分析与设计

4. 步骤
   1. 确定主题
   2. 识别候选对象
   3. 描述对象特性
   4. 发现系统职责
   5. 分配系统职责
   6. 建立对象间协作

15. 需求规格说明

1. 需求获取：目标是得到用户需求——收集需求信息
2. 需求分析：目标是更深刻的理解用户需求——界定能够让用户满意的解决方案准则
3. 需求规格说明：目标是定义用户需求——准确描述需求及其解决方案
4. 需求规格说明文档的作用
   1. 更好的传递软件系统的需求信息和解决方案给所有的开发者
   2. 拓展人们的知识记忆能力
   3. 作为合同协议的重要部分
   4. 作为项目开发活动的一个重要依据
   5. 发现和减少可能的需求错误，减少项目的返工，降低项目的工作量
   6. 作为有效的智力资产：新人培训、客服、类似或增强项目
5. 忽视的原因
   1. 交流途径
   2. 时间压力
   3. 迭代式开发
   4. 敏捷
6. 内容
   1. 前景和范围内
      1. 问题域信息
      2. 解决方案：系统特性
      3. 需求：从用户需求细化得到
   2. 系统需求规格说明文档一般被认为是软件、硬件、接口需求规格说明文档和人机交互文档的更高层文档。
7. 原则：
   1. 目标是交流
   2. 结果组织：位置得当、引用或强化，但不重复
   3. 表达方式：形式依赖于内容，使用系统的表达方式
   4. 细节描述：定义术语表、避免干扰文本、避免歧义词汇
8. 优秀需求规格说明文档特性
   1. 完备性
   2. 一致性
   3. 根据重要性和稳定性定级
   4. 可修改
   5. 可跟踪

16. 需求验证

1. 验证(validation)与确认(vertification)
   1. 需求验证：以正确的方式建立需求
      1. 需求集是正确的、完备的和一致的
      2. 技术上是可解决的
      3. 它们在现实世界中的满足是可行的和可验证的
   2. 需求确认：建立的需求是正确的
      1. 每一条需求都是符合用户原意的
2. 需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动
3. 软件工程中的系统验证的主要手段
   1. 软件测试
   2. 静态分析
4. 需求验证方法
   1. 评审(同级评审)：由作者之外的其他人来检查产品问题的方法，是主要的静态分析手段
      1. 自由方法和检查清单方法是使用最为广泛的两种方法。
      2. 基于场景方法也是常用的一种方法。
      3. 类型
         1. 审查
         2. 小组评审
         3. 走查
         4. 轮查、同级
   2. 原型与模拟：复杂的动态行为
   3. 开发测试用例：如果不能配备测试用例则可能存在问题
      1. 开发系统测试用例
      2. 测试用例套件
      3. 建立测试用例
   4. 用户手册编制：验证功能需求、项目范围、异常流程、环境与约束
   5. 利用跟踪关系：层次化的需求关系
   6. 自动化分析
5. 问题修正：
   1. 需求澄清(Requirements Clarification)
      1. 理解偏差：重新进行分析工作
      2. 分析遗漏：重新分析和文档化这部分信息
      3. 表达不当：重新以合适的方式表达
   2. 缺失需求：重新执行需求获取等一系列工作
   3. 需求冲突：协商解决
   4. 不切实际的期望：项目调整与需求协商
6. 需求验证不仅要发现问题，而且要监督问题的解决

17. 需求管理

1. 需求基线应该成为后续软件系统开发的工作基础和粘合剂
2. 需求管理作用
   1. 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解：增强了项目涉众对需求(尤其是复杂需求)的掌握。
   2. 增进了项目涉众之间的交流：减少了可能的误解和交流偏差。
   3. 减少了工作量的浪费，提高了生产力：需求管理能够更加有效的处理需求的变更
   4. 准确反映项目的状态，帮助进行更好的项目决策：需求跟踪信息能够更加准确的反映项目的进展情况
   5. 改变项目文化，使得需求的作用得到重视和有效发挥：使得项目涉众认识到需求在项目工作中的重要性
3. 简述需求管理的三种方法和流程
   1. 维护需求基线
      1. 基线：已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能修改它
      2. 配置管理
         1. 标识配置项
         2. 版本控制
         3. 变更控制
         4. 访问审计
         5. 状态报告
      3. 状态维护
   2. 需求跟踪
      1. 避免在开发过程或者演化过程中与需求基线不一致或者偏离的风险
      2. 需求跟踪是以软件需求规格说明文档作为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。
      3. 前向跟踪：前向跟踪是指被定义到软件需求规格说明文档之前的需求演化过程
         1. 向前跟踪到需求：说明涉众的需要和目标产生了哪些软件需求
         2. 从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标
      4. 后向跟踪：后向跟踪是指被定义到软件需求规格说明文档之后的需求演化过程
         1. 从需求向前跟踪：说明软件需求是如何被后续的开发物件支持和实现的
         2. 回溯到需求的跟踪：说明各种系统开发的物件是因为什么原因(软件需求)而被开发出来的
      5. 实现方式
         1. 需求跟踪矩阵
         2. 实体关系模型
         3. 交叉引用：文档之间
      6. 建立流程
         1. 认识到需求跟踪的重要性，明确需求跟踪需要解决的问题
         2. 说明需求跟踪过程的目标
         3. 明确需要捕获的跟踪联系
         4. 组织提供资源支持和技术支持
         5. 制定有效的过程策略：需求跟踪过程与实际的项目开发工作融合，作为项目开发工作的一部分。
         6. 便利需求跟踪信息的使用：为客户、项目管理者以及开发者等项目涉众提供便利的使用途径。
   3. 需求变更控制
      1. 变更控制过程
         1. 提交需求变化
         2. 评估需求变化可能带来的影响
            1. 利用需求跟踪信息确定变更的影响范围，包括需要修改的系统组件、文档、模型等。
            2. 依据需求依赖信息确定变更将会带来的冲突和连锁反应，确定解决的方法。
            3. 评估变更请求的优先级和潜在风险。
            4. 明确执行变更需要执行的任务，估算变更所需要的工作量和资源。
            5. 评价变更可能给项目计划带来的影响。
         3. 变更评估结果使用正式文档的方式固定，提交给变更控制委员会。
      2. 配置管理部门
4. 避免范围蔓延
5. 灵活应对变更请求
6. 使用辅助工具