系分-案例分析-需求工程
- 需求获取方法
- 案例 - 需求获取方法
- 需求分析（FAST分析）
- 范围定义
- 问题分析
- 鱼骨图
- 问题、机遇、目标和约束矩阵
- 帕累托图
- 制定系统改进目标
- 需求分析
- 定义需求
- PIECES方法
- P - 性能（Performance）
- I - 信息（Information）
- E - 经济 （Economics）
- C - 控制 （Control）
- E - 效益 （Efficiency）
- S - 服务 （Service）
- 逻辑设计
- 策略分析
- 物理设计和集成/构造和测试/安装和发布
- 系分 - 案例 - 需求分析（FAST分析）
- 结构化分析SA
- 数据流图（DFD）
- 系分 - 案例 - 需求分析(结构化分析SA)
- 面向对象的分析（OOA）
- UML(统一建模语言)
- UML 2.0 包括 14 种图
- 用例图中的用例关系【包含、扩展、泛化】==注：包含和扩展都属于依赖关系==
- 类图与对象图
- UML-4+1视图
- 系分 - 案例 - 需求分析(面向对象的分析OOA)
需求获取方法
方法 | 特点 |
收集资料 | 把与系统有关的、对系统开发有益的信息收集起来。 |
阅读历史文档 | 对收集数据性的信息较为有用。 |
用户访谈 | 1对1-3，有代表性的用户。比较耗时，一般选择有代表性的用户，开放式（问答式，比较发散）与封闭式（选择题）问题相结合。成本高，要有领域知识支撑。 |
问卷调查 | 用户多，无法一一访谈，成本低。 |
抽样调查 | 基于数理统计，降低成本，快速获取。样本大小=a*(可信度系数/可接受的错误)2 注：a一般取0.25。 |
现场观摩 | 针对较为复杂的流程和操作过程。 |
参加业务实践 | 有效的发现问题的本质和寻找解决问题的办法。 |
联合需求计划（JRP） | 高度组织的群体会议，各方参与，成本高。以会议的形式获取需求。 |
情节串联版【原型前身】 | 一系列图片，通过这些图片来讲故事。 |
案例 - 需求获取方法
联合需求计划（JRP）是一种流行的需求获取方法。请说明什么是JRP，JRP 与其它需求获取方法相比有什么优势？
联合需求计划是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发的一部分。JRP 是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。JRP 将会起到群策群力的效果，对于一些问题最有岐义的时候、对需求最不清晰的领域都是十分有用的一种方法。
优势：
- 发挥用户和管理人员参与系统开发过程的积极性，提高系统开发效率。
- 降低系统需求获取的时间成本，加速系统开发周期。
- 采用原型确认系统需求并获取设计审批，具有原型化开发方法的优点。
需求分析（FAST分析）
FAST（Framework for the Application of Systems Thinking），叫 FAST 框架运行，FAST 分析也行，或者是 FAST 方法学也是可以的。FAST 不是一套实际的商业方法，我们可以把它当成遇到的最佳方法实践的组合。同许多商业方法不一样，它不是一种规范。也就是说，FAST 是一个灵活的框架，可以用于不同型的项目和策略。
FAST方法的阶段：
- 范围定义
- 问题分析
- 需求分析
- 逻辑设计
- 决策分析
- 物理设计和集成
- 构造和测试
- 安装和发布
范围定义
又叫初始化研究阶段或计划阶段等。
- 列出问题和机会
- 协商项目的初步范围
- 评价项目价值
- 计划项目进度表和预算
- 汇报项目计划
问题分析
又叫研究阶段或可行性分析阶段等。
- 研究问题领域
- 分析问题和机会
- 分析业务过程
- 制定系统改进目标
- 修改项目计划
- 汇报调查结果和建议
问题分析的目标就是在开发之前对要解决的问题有一个更透彻的理解。
为了达到这一目标，通常需要经过在问题定义上达成共识，理解问题的本质。
问题分析阶段的四项主要任务包括:
- 研究问题领域，深入学习当前系统。
- 分析问题和机会，问题阻碍企业经营目标，机会可以提高管理水平。
- 制定系统改进目标，内部外部的新要求。
- 修改项目计划，根据结果修改计划。
鱼骨图
因果鱼骨图通过直观的图形找出问题或现象的所有潜在原因，从而追踪出问题的根源。
问题、机遇、目标和约束矩阵
鱼骨图，输出结果以文档样式显示，如下：
针对 【现有系统】 | 针对 【待开发的新系统】 |
问题或机会【表象】 | 系统目标 【改进的要求】 |
原因和结果 【背后的原因】 | 系统约束条件 【资源的限制】 |
帕累托图
帕累托图是采用直方图的形式，用于识别造成大多数问题的少数重要原因。根据问题的相对频率或大小从高往低降序排列，帮助设计师将精力集中在重要的问题上。它为 80%的问题找到关键的 20%的原因，它可以一目了然地显示出各个问题的相对重要程度，有助于预防在解决了一些问题后，却使另外一些问题变得更糟的现象发。
在使用时，通常按照以下步骤进行：
- 明确问题，达成共识的问题定义。
- 找出问题的各种可能原因，通常可以利用头脑风暴来收集意见，并通过参考以往积累的资料和运营的数据来综合分析。
- 选择评价标准和考察期限，最常用的评价标准包括频率（占总原因的百分比）和费用（产生的影响），而考察的期限则应具有相应问题的代表性，并不是越长越好。
- 收集各种原因发生的频率及费用数据。
- 将原因按照发生的频率或费用从大到小排列起来。
- 将原因排在横轴上，频率或费用排列在纵轴上。
制定系统改进目标
系统的改进目标可能受到约束条件的调节。约束条件可以分为：
- 进度。例如，新系统必须在12月31日前运行
- 成本。例如，新系统成本不能超过50万。
- 技术。例如，新系统必须能够实现在线实时处理。
- 政策。丽日，新系统必须满足相关技术规范。
需求分析
有些方法学将问题分析和需求分析合并成一个阶段。
- 定义需求
- 排序需求的优先次序
- 修改项目计划
- 交流需求陈述
定义需求
功能需求，满足系统目标所需的输入、输出、过程和存储的数据的形式定义。
非功能需求，性能、易学性、易用性、预算、开支和开支节省、时间表和最终期限、文档和培训需求、质量管理、安全和内部审核控制等。
PIECES方法
P - 性能（Performance）
性能用于描述企业当前的运行效率，可以分析当前业务的处理速度。
- 可接受的吞吐率是多少
- 可接受的响应时间是多少
I - 信息（Information）
信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种问题。
- 需要的输入和输出是什么？它们必须在什么时候发生
- 需要的数据要被存储在哪里
- 信息必须有多及时
- 对外部系统的接口是什么
E - 经济 （Economics）
经济指标主要是从成本和收益的角度分析企业当前存在的问题。
- 必须减少开支的系统领域是什么
- 应该减少多少开支或者增加多少收益预算限度是多少
- 开发的时间表示什么
C - 控制 （Control）
提高信息的安全和控制水平。
- 对系统或信息的访问必须被控制吗
- 对隐私有什么要求
- 数据的重要成都要求对数据进行特殊处理（例如：备份、脱机存储等）吗
E - 效益 （Efficiency）
提高企业的人、财、物等的使用效率。
- 在过程中有必须被消除的重复步骤吗
- 在系统使用其资源的方式中存在降低成本的方法吗
S - 服务 （Service）
提高企业对客户、供应商、合作伙伴、顾客等的服务质量。
- 谁将使用系统？他们都在哪里
- 有不同类型的用户吗
- 相应的人员因素是什么
- 在系统中需要包括什么培训设备和培训材料
- 有哪些培训设备和培训材料需要独立于系统进行开发和维护？
- 对可靠性/可用性有什么要求
- 应该如何包装和分发系统
- 需要哪些文档
逻辑设计
- 结构化功能需求
- 建立功能需求的原型（可选）
- 验证功能需求
- 定义验收测试用例
策略分析
- 确定候选方案
- 分析候选方案
- 比较候选方案
- 修改项目计划
- 推荐一种系统方案
物理设计和集成/构造和测试/安装和发布
系分 - 案例 - 需求分析（FAST分析）
问题分析阶段主要完成对项目开发的问题、机会和/或指示的更全面的理解。请说明系统分析师在问题分析阶段通常需要完成哪四项主要任务。
问题分析的目标就是在开发之前对要解决的问题有一个更透彻的理解。为了达到这一目标，通常需要经过在问题定义上达成共识，理解问题的本质。
问题分析阶段的四项主要任务包括：
（1）研究问题领域
（2）分析问题和机会
（3）制定系统改进目标
（4）修改项目计
一份需求定义文档应该包括哪些内容？对于与系统开发相关的人员：系统所有者、用户、系统分析人员、设计人员和构造人员、 项目经理，需求定义文档各有什么作用？
一份需求定义文档可能是项目文档中被阅读和引用得最多的文档。应该包含以下内容：
- 系统应该提供的功能和服务。
- 非功能需求，包括系统的特征、特点和属性;限制系统开发或者系统运行必须遵守的约束条件。
- 系统必须连接的其他系统的信息。
系统所有者和用户使用需求定义文档来确认需求以及任何可能产生的变化，并作为验收的依据。
系统分析人员、设计人员和构造人员使用它来理解需要什么以及处理需求变更，开发用于验证系统的测试用例。
项目经理使用它作为制定项目计划、处理变更及验收的依据。
FAST 开发方法在系统分析中包括了初始研究、问题分析、需求分析和决策分析等四个阶段，请简要说明每个阶段的主要任务。
范围定义（初始研究阶段）：
- 列出问题、机会和指示
- 协商项目的初步范围
- 评估项目价值
- 计划项目进度表和预算
- 汇报项目计划
问题分析阶段：
- 研究问题领域
- 分析问题和机会
- 分析业务过程
- 制定系统改进目标
- 修改项目计划
- 汇报调查结果和建议
需求分析阶段：
- 定义需求
- 排列需求优先序
- 修改项目的计划
- 交流需求陈述
- 持续不断的需求管理
决策分析阶段：
- 确定候选方案
- 分析候选方案
- 比较候选方案
- 修改项目计划
- 推荐一个系统方案
结构化分析SA
数据流图（DFD）
数据平衡原则
- 顶层图与 0 层图对比，是否顶层图有，但 0 层图无的数据流，或反之。
- 检查图中每个加工，是否存在只有入没有出，或只有出没有入，或根据输入的
数据无法产生对应的输出的情况。
异常现象：
- 黑洞：一个加工只有输入数据流而无输出数据流
- 奇迹：一个加工只有输出数据流而无输入数据流
- 灰洞：若一个加工的输入数据流无法通过加工产生输出流
系分 - 案例 - 需求分析(结构化分析SA)
流程图和数据流图是软件系统分析设计中常用的两种手段，请用 300 字以内文字简要说明流程图与数据流图的含义及其区别，并说明项目组为何确定采用数据流图作为建模手段。
数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。两者的区别如下：
- 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
- 数据流图展现系统的数据流；流程图展现系统的控制流。
- 数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。
- 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。
高质量的数据流图是可读的、内部一致的并能够准确表示系统需求。请用 300 字以内文字说明在设计高质量的数据流图时应考虑的三个原则。
高质量数据流图设计时应考虑的三个原则如下：
- 复杂性最小化原则。数据流图分层结构就是把信息划分为小的且相对独立的一大批子集例子，这样就可以单独考察每一个数据流图。如果要了解某个过程更加详细的信息，可以跳转到该过程的下一层;如果要知道一个数据流图如何与其他数据流图相关联，可以跳转到上一层的数据流图进行考察。
- 接口最小化原则。接口最小化是复杂性最小化的一种具体规则。在设计模式时，应使得模型中各个元素之间的接口数或连接数最小化。
- 数据流一致性原则。一个过程和它的过程分解在数据流内容中是否有差别?是否存在有数据流出但没有相应的数据流入的加工，是否存在有数据流入但没有相应的数据流出的加工。
（1）信息工程方法中的’实体（entity） ”与面向对象方法中的“类（class） ”之间有哪些不同之处?
（2）在面向对象方法中通常采用用例（Use Case）来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的 Essential Use Cases 和Real Use Cases 有哪些区别？
（1）实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
（2）Essential Use Cases 可翻译为抽象用例，Real Use Cases 可翻译为基础用例。他们是区别在于：基础用例是实实在在与用户需求有对应关系的用例，是从用户需求获取的渠道得到的，而抽象用例是从基础用例中抽取的用例的公共部分，是为了避免重复工作，优化结构而提出的用例。
面向对象的分析（OOA）
UML(统一建模语言)
- UML 由构造块、规则、公共机制组成。
- 对象三要素：属性、方法、对象ID（标识）
- 接口 指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
- 构件是物理上或可替换的系统部分，它实现了一个接口集合。
UML 2.0 包括 14 种图
速记：
- 类图构件搞对象、组合生下部署图、还送一个小包图
- 用例状态在活动、定时顺序来通信、二者交互制成品
静态图
类型 | 定义 | |
类图 | 描述一组类、接口、协作和它们之间的关系。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。 |
|
构件图（也称组件图） | 描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。 |
|
对象图 | 描述一组对象及它们之间的关系。 |
|
组合结构图 | 描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。 |
|
部署图 | 描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。 |
|
包图 | 描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。 |
|
制品图 | 描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。 |
|
动态图
类型 | 定义 | |
用例图 | 描述一组用例、参与者及它们之间的关系。 |
|
状态图（也称组件图） | 描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。 |
|
活动图 | 将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它强调对象间的控制流程。 |
|
定时图（也称计时图） | 也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。 |
|
顺序图(也称序列图） | 是一种交互图，交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。 |
|
通信图(也称协作图） | 也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。 |
|
交互概览图 | 是活动图和顺序图的混合物。 |
|
用例图中的用例关系【包含、扩展、泛化】注：包含和扩展都属于依赖关系
包含关系【使用关系】：从多个用例中提取公共行为，提取出来的公共用例称为抽象用例，而把原始用例称为基本用例。如下：
扩展关系：一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例。如下：
泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。如下：
用例建模的流程：
- 识别参与者（必须）
- 合并需求获得用例（必须）
- 细化用例描述（必须）
- 调整用例模型（可选）
类图与对象图
依赖关系 一个事物发生变化影响另一个事物。
泛化关系 特殊/一般关系
关联关系 描述了一组链，链是对象之间的连接
- 聚合关系 整体与部分生命周期不同汽车和轮子
- 组合关系 整体与部分生命周期相同公司和部门
实现关系 接口与类之间的关系
UML-4+1视图
用例视图 | (user-case view)最终用户，需求分析模型。 |
逻辑视图 | (logical view)展现系统功能。系统分析、设计人员。类与对象 |
实现视图 | (implementation view)源代码结构。程序员。物理代码文件和组件 |
进程视图 | (process view)并发与同步结构。系统集成人员。线程、进程、并发 |
部署视图 | (deployment view)软件构件到物理结点映射。系统和网络工程师 |
系分 - 案例 - 需求分析(面向对象的分析OOA)
用例建模的主要工作是书写用例规约。用例规约通常包括哪几部分内容？
用例规约：用例名称、简要说明、事件流、非功能需求、前置条件、后置条件、扩展点、优先级。
识别设计类是面向对象设计过程中的重要工作，设计类表达了类的职责，即该类所担任的任务。请用 300 字以内的文字说明设计类通常分为哪三种类型、每种类型的主要职责，并针对题干描述案例涉及的具体类为每种类型的设计类举出 2 个实例。
- 实体类。实体类映射需求中的每个实体，保存需要存储在永久存储体中的信息，例如，用户、商品等。
- 控制类。控制类是用于控制用例工作的类，用于对一个或几个用例所特有的控制行为进行建模。例如，结算、备货等。
- 边界类。边界类用于封装在用例内、外流动的信息或数据流。例如，浏览器、购物车等。
在面向对象的设计过程中，活动图（activity diagram）阐明了业务用例实现的工作流程。请用 300 字以内的文字给出活动图与流程图（flow chart）的三个主要区别。
- 活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现系统的行为，而非处理过程；而流程图着重描述处理过程。
- 流程图一般都限于顺序进程，而活动图则可以支持并发进程。
- 活动图是面向对象的，而流程图是面向过程的。
随着共享单车投放量以及用户量的增加会存在系统性能或容量下降问题，请用 200 字以内的文字说明，在系统设计之初，如何考虑此类问题？
- 采用集群技术进行服务器的水平扩展。
- 采用负载均衡技术，提升并发处理能力。
- 采用分布式存储方式，将各地区数据分散存储，减少压力
在结构化和面向对象的软件分析过程中，通常会使用到数据流图、活动图和流程图,请分别描述这三种模型的特点和适用场景。
- 数据流图：
通过系统内数据的流动来描述系统功能的一种方法，强调系统中的数据流动。其基本元素包括：数据流，外部实体，加工，数据存储。主要用于结构化需求分析，为系统做功能建模。 - 活动图：
与流程图类似，但可以表现并行执行。用于面向对象分析与设计建模。 - 流程图：
能清晰展现业务执行的流程顺序，强调控制流。用于结构化需求分析与结构化设计，为系统梳理业务流程。
需求评审是通过将需求规格说明书递交给相关人员检查，以发现其中存在缺陷的过程。在需求工程中，需求评审是一个非常重要的过程。结合题干案例，请用 300 字以内的文字简要说明需求评审的内容及作用。
需求评审内容：
- SRS 正确地描述了预期的、满足项目干系人需求的系统行为和特征。
- SRS 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
- 需求是完整的和高质量的。
- 需求的表示在所有地方都是一致的。
- 需求为继续进行系统设计、实现和测试提供了足够的基础。
- 用例优先级合理度评估。
本例中存在需求描述不完整的情况，如：谁向系统请求？输入个人详细信息要输入哪些？选择账户类型，有哪些账户类型供选择？都未明确描述
采用面向对象方法进行软件系统分析与设计时，一项重要的工作是进行类的分析与设计。请用 200 字以内的文字说明分析类图与设计类图的差异。
- 分析类图：在需求分析阶段，类图是研究领域中的概念；分析类图主要用于描述应用领域中的概念，类图中的类从领域中得出，从需求中获取。
- 设计类图：在设计阶段，类图重点描述类与类之间的接口；设计类图用于描述软件的接口部分，而不是软件的实现部分，设计类图更易于开发者之间的相互理解和交流；
设计类图通常是在分析类图的基础上进行细化和改进的。
