需求部分期末复习

参考自 zhy 的博客2020-需求与商业模式分析-Exam-需求 - SpriCoder的博客

1. 需求工程导论

1. 需求工程：

   1. 基本活动：
      1. 需求获取
      2. 需求分析：目标、功能和约束映射为软件行为，建立系统模型
      3. 需求规约：以文档的方式固化下来。
      4. 需求验证
         1. 保证需求及文档的正确性
         2. 通过检查和修正，保持文档的完整性和一致性
         3. 所有涉众一致同意
      5. 需求管理：管理建立的基线

⭐2. 需求类型

1. 需求的定义(IEEE)

   1. (用户的观点)用户为了解决问题或达到某些目标所需要的条件或能力。
   2. (开发者的观点)系统或系统部件为了满足合同、标准、规范或者其他正式文档所规定的要求而需要具备的条件或能力。
   3. 对1或2中的一个条件或一种能力的一种文档化表述。
   4. 注：需求是以用户为中心的，是与问题相联系的；需求要被清晰、明确地写在文档上。

2. 需求的层次性

   1. 业务需求：解决方案与系统特性
   2. 用户需求：问题域知识
      1. 用户需求是对任务的期望，基本表达方式"xx用户可以使用系统完成xx任务"
   3. 系统级需求：需求分析模型
      1. 一般典型表述形式为"系统可以xxx"或者"在xx用户提出xx请求时，系统应该xxx"。

3. 需求的分类

   1. 需求
      1. 项目需求：项目时间、项目成本
      2. 过程需求：过程方法、过程文件
      3. 系统级需求：系统工程的需求
         1. 软件需求
            1. 功能需求
            2. 性能需求：速度、 容量、吞吐量、负载、实时性等
            3. 质量需求：可靠性、可用性、安全性、可维护性、易用性
            4. 对外接口：硬件、软件、数据库接口、用户界面、通信接口
            5. 约束：限制开发人员设计和构建系统时的选择范围
               1. 系统开发及运行的环境
               2. 问题域标准：法律法规等
               3. 商业规则
               4. 社会性因素
            6. 其他需求：安装需求、培训需求、数据需求(功能需求没有描述的补充)
         2. 硬件需求：服务器规格
         3. 其他需求：人力资源(系统投入使用时，需要对用户进行1个星期的集中培训)、协同需求
   2. 不切实际的期望：不可行，做不到

3. 需求工程过程

1. 常见的文档

   1. 项目前景和范围文档
   2. 用户需求文档
   3. 需求规格说明文档
      1. 系统规格说明
      2. 软件规格说明

2. 过程活动

   1. 需求获取：从人、资料或者环境当中获取需求的过程
      1. 收集背景资料
      2. 获取问题与目标，定义项目前景和范围
      3. 识别涉众
         1. 涉众分析
      4. 选择获取方法、执行获取
         1. 面谈
         2. 观察
         3. 原型
      5. 记录获取结果
   2. 需求分析：主要工作：建模来整合各种知识，以帮助人们更好地理解问题：信息的细化、为创造性活动提供支撑，完成内容的转化。最后产生需求的基线集。指定系统开发需要完成的任务。
   3. 需求规格说明
   4. 需求验证，标准：需求正确，反应用户的意图、完整性和一致性、可读性和可修改性。
   5. 需求管理：保证需求作用在整个软件的产品生命周期中的持续、稳定和有效发挥
      1. 维护需求基线
      2. 实现需求跟踪：前向跟踪和后向跟踪
      3. 进行变更控制

4. 需求获取：

总结：

1. 需求获取前半段

   1. 确定项目的前景与范围：问题分析-目标分析-业务过程分析
   2. 涉众分析：涉众识别-涉众描述-涉众评估-涉众代表选择-参与策略

2. 需求获取后半段

   1. 基于用例/场景展开用户需求获取
   2. 用户需求获取手段
      1. 面谈
      2. 原型：抛弃式与演化式，控制成本，应对模糊与变更
      3. 观察：采样观察与民族志，应对复杂协同

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

1. 为什么要确定项目的前景和范围

   1. 保证项目涉众以符合项目需要的角度描述现实世界：项目的目标就是业务需求
   2. 前景描述产品用来干什么，将所有的涉众都统一到一个方向，所有的涉众都从共同认同的项目前景出发，理解和描述问题域及需求。
   3. 范围指出了当前项目是要解决的产品长远规划中的哪一部分，限定了需求的界限，范围内的事物和事件是描述的目标。

   

2. 不同的业务需求之间存在冲突，则在确定项目前景和范围阶段必须予以解决。对于零售机问题中的矛盾

   1. 开发者重视技术
   2. 零售商要求简单直接投入使用
   3. 用户希望便捷和功能性

3. 分析过程的深入：问题分析、目标分析、业务过程分析

4. 还需要分析非功能需求，定义系统边界，生成前景与范围文档

5.1. 问题分析

🌟 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. 目标的基本模式：实现、终止、保持、避免和优化

   模式	符号描述	含义
   实现(Achieve)	$P \Rightarrow \Diamond Q$	如果将来某一时刻Q为真(被满足)，则目标实现
   终止(Cease)	$P \Rightarrow \Diamond \neg Q$	如果将来某一时刻Q为假(被终止)，则目标实现
   保持(Maintain)	$P \Rightarrow \Box Q$	将来任一时刻Q都为真，则目标实现
   避免(Avoid)	$P \Rightarrow \Box \neg Q$	将来任一时刻Q都为假，则目标实现
   优化(Optimize)-min/max	-	最大化Max(目标功能) 或 最小化Min (目标功能)

6. 目标模型元素之间的关系的关系

   1. 精化

      1. AND精化：子目标完成保证父目标完成，合并画实心圆
      2. OR精化：子目标之间是可以相互替代的，分开画空心圆

      一个高层次目标G可以精化为低层次目标{G1,G2,…,Gn}：目标精化是目标模型的重要任务之一

      精化的结束条件：

      子目标展开到单一事务时终止

      • 事务指的是用户与系统的一次协作活动，要求全部成功或全部失败。确认这些单一事务能够增加业务价值

      

   2. 阻碍：子目标达成会导致父目标失败，允许继续被精化为低层次目标(AND/OR)

      

   3. 支持与冲突【非父子目标之间的关系】

      1. 支持：某一个目标达成会支持促进其他目标(可以被处理为OR关系)
      2. 冲突：某一个目标对于其他目标的实现有阻碍作用
      3. 通常会通过文字+符号表示
         1. ++ 保证
         2. + 更容易
         3. - 更困难
         4. -- 导致失败

7. 目标与主体：Assignment链接表示为实现目标而需要主体参与。六边形且没有箭头

   1. OR关系：多个主体中一个完成
   2. AND关系：多个关系中已通过完成

   

8. 目标与操作：操作也可以OR和AND精化，圆角矩形且没有箭头

   

9. 目标分析过程

   • 面向目标方法
     1. 高层目标的获取：现状和背景的分析：画布、评估
     2. 低层目标的获取
     3. 目标分析
        1. 精化与分解（建立目标模型）
     4. 目标实现

10. 例子

    对于各个建立目标模型的事项中，都要坚持对高层目标问"怎么实现(How)“，对低层目标问"为什么需要(why)”，来实现层次结构。

    1. 案例

       

    2. 获取高层目标

       

       

    3. 目标精化（AND 精化和 OR 精化）

       建议尤其要注重对信息持有情况的获取,如存储、加工和输出数据信息,因为这很常见，意味着相应Maintain目标的存在。看到高层目标"减少缺货、积压与报废"的描述信息时,可以发现需要持有库存数据

       

    4. 发现阻碍，支持和冲突

       要注意发现冲突关系。尤其要关注不同视点( view)之间的冲突以及正式定义之间相矛盾的冲突。例如"减少人员"与"销售更多商品"两个目标就是不同视点之间的冲突

       

11. 目标实现

    1. 将最底层目标分配给主体（人+系统）

       

    2. 设计实现最底层目标的操作

       

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

5.4. 活动图

5.5. 定义系统边界

5.6. 前景和范围文档

6. 涉众分析与硬采样

1. 涉众：所有能够影响软件系统的实现(系统决策者、开发者、利益所在者)或者会被实现后的软件系统所影响的(已有产品更新、全新产品开发)关键个人和团体(stakeholder)。

2. 涉众分析过程：

   1. 涉众识别:寻找软件系统的涉众类别。

   2. 涉众描述:

      1. 描述不同涉众类别的简单特征和复杂特征

   3. 涉众评估:

      1. 为涉众类别划分优先级。
      2. 评估不同涉众类别的风险，化解风险。
      3. 分析涉众冲突,实现共赢。

   4. 涉众代表选择:从每种涉众类别中选择代表。

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

   

6.1. 涉众识别

1. 基本原则

   • 涉众需要细分

     • 每一类涉众要稳定的从相同立场、视角来看待相同的系统

   • 发现关键涉众(影响关乎软件系统成败)

     • 需要分析他们各自的赢利条件，以在相互妥协中尽力实现一个共赢的结局，最简单的区分特征是任务。
     • 如果互动及其关注点属于项目的目标与范围，并且其影响关乎软件系统成败和实现，那么涉众就属于关键涉众

   • 涉众群体需要持续维护和关注

2. 识别方法

   1. 简单方法：先膨胀后收缩：根据收集到的背景资料尽可能多的列举，然后尽可能的合并涉众。

   2. 经验方法：检查列表

      1. 用户：关注软件功能
      2. 客户：成本、效益(用户替代源)
      3. 开发者：实现软件系统
      4. 管理者：关注系统开发进程
      5. 领域专家：关注软件中的知识
      6. 政府力量：法律法规、长远规划等；约束和指导
      7. 市场力量(用户替代源)
      8. 维护人员：关心系统的非功能性属性

      优点：容易操作；缺点：有的类别太粗如用户类别

   3. 经典方法：涉众网络

      1. 涉众：节点，互动：边
      2. 从容易发现的涉众出发(涉众基线，如客户等)
      3. 头脑风暴
      4. 对得到的涉众列表分析相关性，分析时要将其与软件系统联系起来，这个网络包含了涉众与软件系统之间的交互以及涉众之间的交互，确定各个涉众类别和软件系统的相关性、关键性，最后缩减成一个涉众列表。

🌟主体依赖模型ADM(Actor Dependency Model)——分析涉众互动，识别关键涉众类别

箭头由依赖者指向被依赖者

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

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

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

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

5. 完备描述涉众之间的互动，了解涉众的社会互动性。

例子：B站的涉众分析

1. 一般Up主与观众：目标是流畅、有趣的视频观看，任务是为平台带来流量和关注度，占用大量带宽和审核资源，被补贴

2. "二次元"核心Up主与观众：目标是垂直、核心的动漫内容消费，任务是为平台带来收益和核心社区，强力的粘性消费补贴平台其他用户

3. 前者追求流畅视频体验(软目标)、占带宽多(资源)，产品粘性与消费能力较弱(任务)；后者则相反(高粘性游戏运营，主要收入)

   1. 后者在事实上补贴前者
   2. B站策略 两大类涉众并存：大会员+社区+电商 VS 宅向内容与营销

6.2. 涉众描述

需要描述涉众对系统的影响，对项目的期望即目标，主要关注点，对项目的态度

🌟6.3. 涉众评估

1. 为涉众类别划分优先级：尤其是任务特征，使用功能越多、越频繁、越大规模的用户群体优先级越高。

2. 涉众优先级评估：🌟Power-interest图

   1. 参与者：系统的实际使用者，对系统也有较大影响力，优先级最高。
   2. 环境设定者：很少使用系统，但是由于政治、经济等因素对系统有比较大的影响，优先级次之，最常见的是政府和管理者。
   3. 被影响者：可能是系统直接使用者，也可能是因为系统出现被剥夺了部分利益的输家，受影响大，能影响的少，优先级一般低于环境设定者，但是特殊情况下也可能高于环境设定者。
   4. 观众：不受影响，也不影响，优先级最低，比如环境专家和市场力量。

2. 不同涉众类别的风险:Power/Attitude图

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

3. 化解涉众风险

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

4. 分析涉众冲突，🌟共赢分析

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

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

1. 完整采样

2. 态度积极

3. 数量适中(6-10)

4. 比例恰当

5. 如果找不到涉众类别代表，可以使用用户替代源：因为业务关系而和用户频繁接触的人 ，能够代替他们发表看法

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

1. 让代表们在合适的时间参与合适的工作

2. 使用敏捷方法，建立起和用户的直接联系，用户参与软件系统开发的全过程

   1. 为其设计
   2. 与其设计
   3. 由其设计

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

6.9. 硬采样

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

用户知道所有事情，用面谈；用户有不确定的需求，用原型；某些场景用户不知道或不能主动告知，用观察

场景与用例

• 场景：具有重点描述真实世界的特征，利用情景、行为者之间的交互、事件随时间的演化等方式来叙述性的描述系统的使用

• 用例：在系统（或者子系统或者类）和外部对象的交互当中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务

• 商业模式中的场景一般需要多个用例来支撑

• 将前景、范围以及涉众分析得到的结果不断的填入场景与用例之中

🌟8. 面谈

1. 准备面谈

   1. 准备工作
   2. 面谈准备的关键：问题类型
      1. 开放式问题
         1. 答复的选择可以是开放和不受限制的。
         2. 感到自在、丰富细节、让被会见者更感兴趣、启迪
         3. 失控、看上去没有准备、细节过多
      2. 封闭式问题
         1. 节省时间、切中要点、控制、确切
         2. 厌烦、细节时候、不能建立友好关系
      3. 探究式问题
      4. 诱导式问题
      5. 双筒问题
      6. 元问题：我的问题看起来相关吗等
   3. 问题准备
      1. 分析基本的涉众特点：角色、任务、个人目标、频率、优先级
      2. 前期开放性问题，后期封闭性问题

2. 主持面谈

3. 处理面谈结果

4. 面谈类型

   1. 结构化面谈：安全按照事先的问题和结构来控制面谈
   2. 半结构化面谈：事先需要根据面谈内容准备面谈的问题和面谈结构，问题在面谈过程中调整
   3. 非结构化面谈：没有事先预定的议程安排、问题

5. 面谈优点和缺点：

   1. 优点：

      1. 面谈的开展条件较为简单
      2. 能获得广泛内容
      3. 建立相互之间的友好关系
      4. 通过参与面谈，被会见者会产生一种主动为项目做出贡献的感觉，提高涉众的项目参与热情

   2. 缺点：

      1. 面谈比较耗时
      2. 在被会见者地理分散的情况下往往难以实现面谈
      3. 面谈参与者的记忆和交流能力对结果影响较大，尤其是面谈的成功较高的依赖于需求工程师的人际交流能力
      4. 在会见者不了解被会见者认知结构的情况下，面谈不可能取得令人满意的效果

6. 其他相关方法：

   1. 群体面谈
   2. 调查问卷：依然是一种面谈方法，面谈方法以口头语言为主要的交流媒介，而调查问卷以文档为主要的交流媒介
   3. 头脑风暴：目的不是发现需求，而是发明需求，或者说是发现潜在需求

9. 原型

1. 为什么要使用原型：解决不确定性

2. 定义：原型是一个系统，它内化了(capture)一个更迟系统(later system)的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。

   1. 如果在最终的物件(final artifact)产生之前，一个中间物件(mediate artifact)被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。

3. 软件工程中的原型：

   1. 演示原型：目的是让用户相信应用系统的开发是可行的
   2. 严格意义上的原型：主要被用在分析需求阶段，探索和解决需求的不确定性。
   3. 试验原型：主要被用在构建系统阶段，探索和解决解决方案的不确定性
   4. 引示系统原型：用作最终系统的构建核心

4. 原型方法过程

   1. 确定原型需求
   2. 原型开发：低成本、易修改
   3. 原型评估：无偏见环境、是否一致、评估者反应建议、创新思想
   4. 原型修正

5. 抛弃式原型：

   1. 探索式原型

      1. 演示原型
      2. 严格意义上的原型

   2. 实验式原型

      1. 试验原型

   演化式原型：

   1. 引示系统的原型

6. 使用要点

   1. 坚决抛弃抛弃式原型

   2. 控制原型成本：

      1. 水平和垂直两个方向：用尽可能低的成本开发水平原型
         1. 水平原型：它仅仅实现选定功能所有层次中的某些特定层次
         2. 垂直原型：它会触及到选定功能实现的所有层次
      2. 使用简单介质

   3. 善用故事板原型

      

      1. who what how

      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. 问题域信息 2. 用户界面特征 3. 业务需求、组织策略、政策法规
硬数据	文档分析	阅读、研究得到的硬数据，从中发现需求信息 1.问题域信息 2.工作流程 3.业务细节
客户的需求文档	需求剥离	抽取客户的需求文档中的需求描述 ，粗粒度需求

硬数据：

1. 定量硬数据：数据收集表格、统计报表

2. 定性硬数据：组织描述文档，业务指导文档如工作指南和规章手册

11. 需求分析概述

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

11.1. 根本任务

1. 建立分析模型，达成开发者和用户对需求信息的共同理解：确定本质特征，获取某个可以转换为知识的事物信息，即建模——建立需求分析模型。

2. 建立解决方案：依据共同理解，发挥创造性，创建软件系统解决方案

11.2. 建模

1. 抽象

2. 分解

3. 投影

11.3. 两个世界与三种模型

1. 计算世界与计算模型

   1. 使用软件的构成单位作为模型的组元
   2. 软件构建单位之间的关系作为模型组元之间的关系
   3. 计算模型：使用的组元和组元间关系都是软件的元素，是来自软件(计算世界)的模型。
   4. 计算世界基于计算科学建立的，具有形式化的特征，信息的描述具有明确化、准确化和确定化的特征
   5. 需求阶段不适合建立

2. 问题世界与业务模型

   1. 使用问题域中的重要概念作为模型的组元
   2. 使用概念之间的业务联系作为组元之间的关系
   3. 使用了业务描述的方式，具有非形式化特征

3. 软件分析模型(分析视图)

   1. 介于计算模型和业务模型二者之间的模型形式
   2. 分析模型使用了计算模型的组元形式，描述解决方案时具有比业务模型更加严谨和适用的描述方式。
   3. 分析模型在组元的表现上使用了业务模型的表现方式
   4. 分析模型是半形式化的

11.4. 需求建模

1. 需求分析的关键就是为真实世界的问题建模，即问题域模建模。

2. 通常的做法是：

   1. 先依据获取的问题域信息建立初步的模型。
   2. 然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。
   3. 最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。

11.5. 需求细化

11.6. 需求的记录

11.7. 需求协商

12. 过程建模

13. 数据建模

14. 面向对象建模

14.1. 类

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

1. 不包含行为的类图

2. 如果候选对象既维持一定的状态，又依据状态表现一定的行为，那么它就应该是一个独立存在的对象。从代码角度即有属性又有对应的方法

3. 过程

   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.6. 状态图

1. 确定上下文环境

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

3. 建立状态转换

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

14.7. OCL

14.8. CRC

15. 需求规格说明

16. 需求验证

1. 验证(validation)与确认(vertification)

   1. 需求验证
      1. 需求集是正确的、完备的和一致的
      2. 技术上是可解决的
      3. 它们在现实世界中的满足是可行的和可验证的
   2. 需求确认
      1. 每一条需求都是符合用户原意的

2. 需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动

3. 软件工程中的系统验证的主要手段

   1. 软件测试
   2. 静态分析

4. 需求验证方法

   1. 评审(同级评审)：由作者之外的其他人来检查产品问题的方法，是主要的静态分析手段
   2. 原型与模拟：复杂的动态行为
   3. 开发测试用例：如果不能配备测试用例则可能存在问题
   4. 用户手册编制：验证功能需求、项目范围、异常流程、环境与约束
   5. 利用跟踪关系：层次化的需求关系：上层需求是否得到下层的支持
   6. 自动化分析

5. 需求验证不仅要发现问题，而且要监督问题的解决

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. 交叉引用：文档之间

   3. 控制变更

      

      1. 变更控制注意事项

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