Book5-确定项目的前景和范围

1. 引入

1.1. 社区团购激战正酣

团长：小区门口的便利店、彩票店、餐饮店主，佣金10%，提成收入200-350/天
社区团购：最后一个没有被完全电商化的市场，规模可达万亿。
品控、缺货、退货问题较为明显。

2. 确定项目前景和范围的活动

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

在看待现实世界时：世界是复杂的，从不同的角度观察(目的与条件)，会看到不同的内容(抽象与映射)
因此有2个问题：
1. 如何保证项目涉众以符合项目需要的角度描述现实世界？
2. 描述哪些事物和事件才会尽可能的符合项目的需要？
第一个问题：项目的目标就是系统的业务需求，为业务需求，在简单情况下可以进行问题分析，复杂情况下考虑进行目标分析，必要时辅以业务过程分析。
项目前景与范围文档：业务需求、高层解决方案以及系统特性，还有部分涉众分析的结果——涉众特征分析。
1. 前景描述产品用来干什么，将所有的涉众都统一到一个方向，所有的涉众都从共同认同的项目前景出发，理解和描述问题域及需求
2. 范围指出了当前项目是要解决的产品长远规划中的哪一部分，限定了需求的界限，范围内的事物和事件是描述的目标

2.2. 确定项目前景和范围的位置和作用

2.3. 确定项目前景和范围的关键

定义业务需求和能够满足需求的高层解决方案，包括:
1. 业务目标、目的
2. 高层业务功能
3. 每个高层业务功能所关联的高层数据
4. 每个功能相关的项目涉众
5. …
如果存在不同业务需求之间的冲突，那么在确定项目前景和范围阶段必须予以解决：不然会导致软件很难甚至无法继续推进。

2.4. 业务需求冲突示例

对一个配有嵌入式软件的售货机而言：
1. 销售机开发者的业务目标：
  1. 向零售商出售或出租售货机，并由此获利。
  2. 通过售货机向顾客销售消费品。
  3. 吸引客户对商品的兴趣。
  4. 生产出多种类型的售货机。
2. 零售商的业务目标：
  1. 将单位营业面积的收益最大化。
  2. 吸引更多的顾客来商店购买。
  3. 用售货机替代人工，带来销量和利润的增长。
3. 可能产生的矛盾：开发者重技术、零售商要求简单可直接投入使用、顾客希望方便和功能性
泡泡玛特即将上市

3. 确定项目前景与范围的过程

4. 本章总论

确定项目的前景与范围，就是确定项目的问题、目标、特性
1. (业务需求)问题：组织的战略目标、利益分配、政策规划、业务流程等高层问题
2. 目标：问题的反面，用户的期望
3. 特性：选定的、针对目标的解决方案所需要具备的功能特征，通常内聚于一个目标与任务，反映系统与外界一次有价值的完整互动过程(用户)
针对项目的复杂程度，可以采用的分析手段由浅到深依次为问题分析、目标分析、业务过程分析
1. 问题与目标明确 $\Rightarrow$ 问题分析 $\Rightarrow$ 用例图/上下文图
2. 目标之间存在较为复杂的关系 $\Rightarrow$ 目标分析 $\Rightarrow$ 目标模型与目标实现
3. 目标、特性之间存在紧密的联系 $\Rightarrow$ 业务过程分析 $\Rightarrow$ UML活动图
4. 分析过程越复杂，分析结果的形式化程度越高，变更的成本也越大
此外，还需要分析非功能需求，定义系统边界，生成前景与范围文档

5. 问题分析

为发现业务需求而需要讨论的问题是指一些高层次的问题，是和组织的战略目标、利益分配、政策规划、业务流程等内容相关的问题。

5.1. 获取问题

问题分析的前提是获取问题，通过收集背景资料或者与涉众沟通来实现
收集背景资料时要收集业务描述及其统计数据关注业务困难与问题。
与涉众的沟通主要通过面谈完成。
示例：×××连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门面店。原商店只有销售的收银部分使用软件处理，其他业务都是手工作业，这已经不能适应它的业务发展要求。首先是随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。其次是商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废的现象上升明显。再次是商店面临的竞争比以前更大，希望在降低成本，吸引顾客，增强竞争力的同时，保持盈利水平。
1. P1：手工作业销售迟缓，效率不高。
2. P2：商店的商品品种太多，无法准确掌握库存。
3. P3：成本不够低，导致竞争力不强，盈利水平不够。
4. P4：顾客不够多，销售额不高，盈利水平不够。
对每个问题：发现问题 $\rightarrow$ 明确问题 $\rightarrow$ 发现业务需求 $\rightarrow$ 定义问题解决方案及系统特性，得到每一个问题的业务需求和解决方案(特性、边界及约束)

5.2. 明确问题

5.2.1. 对问题达成共识

描述问题：在涉众之间取得认同

5.2.2. 收集背景资料，判断问题的明确性

问题的明确性要求它们具备一下两点：(不符合则是不明确的需求)

易于理解：P1是不明确的，P2是明确的。
1. P1：图书管理员：图书总是无法上架。
2. P2：图书管理员：
  1. 图书的内容分类不合适，无法分类上架
  2. 图书上架的工作太繁杂，导致来不及上架。
  3. 图书的借阅不遵守章程，不能保证上架。
能指明解决的方向
1. P3：决策者：生产的废品过多(系统无法提供帮助，不明确的)
不要为了发现问题而发现问题。

5.2.3. 分析不明确问题，发现问题背后的问题

对于不明确的问题，可以尝试发现涉众提出不明确问题的原因，理解其背后深藏的问题。

第一选择：直接咨询涉众：结合鱼骨图
第二选择：利用收集的资料和业务数据
必要时需要使用一些简单的问题分析技巧
发现深层问题的示例
1. 当前问题：产生了太多的废品
2. 进一步问题：产生太多废品的原因？
  1. 用鱼骨图列出所有的可能原因
  2. 请用户确认(通常可以解决问题)
  3. 如果用户无法确认，则搜集数据进行分析
  4. 重新定义新的问题(不准确的销售订单)

5.3. 发现业务需求

每一个明确、一致的问题都意味着涉众存在一些相应的期望目标，即业务需求。
一般情况下，业务需求就是问题的反面
1. P：决策者：生产的废品过多
2. BR：提供销售订单的准确性，在系统使用后3个月内，减少50%因此而产生的废品。
注意：业务目标要具有第二章所述的各种优秀特性，尤其是要有可验证性，可验证的数值指标是通过研究问题域的背景资料得出的。

5.4. 定义解决方案及系统特性

5.4.1. 建立问题解决方案

发现各种可行的高层次解决方案，分析不同方案的业务优势和代价，然后通过和涉众的协商，选定其中一个
1. 分析涉及的人员与任务，综合考虑，给出解决方案
2. 创造性过程：依赖于个人的技术水平、经验和综合素质
最终的解决方案需要由涉众自己决定。

例子

1. 背景：对一个设备制造商的IS系统升级
2. 问题：改进同经销商之间的通信
3. 涉众：制造商、经销商
4. 开发人员提出的解决方案：
   1. 提供更好的财务报告、更好的发票和陈述的格式、在线的零件订购以及电子邮件
   2. 最终希望能实现公司和经销商间的电子资金转账
5. 客户讨论修正后的方案：
   1. 首要任务是提供电子资金转账
   2. 最好能有电子邮件及其它的通信特性

5.4.2. 定义系统特性

明确该解决方案需要具备的功能特征，即系统特性
特性是对一系列内聚的相互联系的需求(要求)、领域特征和规格的总称[Classen2008]。通常，一个特性内聚于一个目标与任务，反映了系统与外界一次有价值的完整互动过程(一组任务的要求)。

P2的解决方案中的系统特性
   SF1：处理批量商品出/入库,掌握库存减少/增加。
   SF2：记录销售所影响的商品出库，掌握库存减少。
   SF3：记录退货所影响的商品入库,掌握库存增加。
   SF4：分析店铺商品库存,发现可能的商品积压、缺货和报废现象。
   SF5：根据积压、缺货和报废现象调整销售的商品目录。
   SF6：制定促销手段，处理积压商品。
   SF7：将报废商品自动出库。

5.4.3. 解决方案的边界

分析解决方案需要和周围环境形成的交互作用，定义解决方案的边界
面向对象方法：用例图
1. 涉及哪些用户？
2. 用户的目标有哪些？需要执行的任务有哪些？
3. 建立用例图(角色：用户；用例：目标-任务)
结构化方法：上下文图(DFD)
1. 它需要的信息由谁提供？
2. 它产生的信息由谁使用？
3. 谁控制它的执行？
4. 谁会影响它的执行？

5.4.3.1. 面向对象边界描述：用例图

用例图：外部角色在与解决方案的交互中完成的任务与目标

SF1:业务经理，商品人库、商品出库。
SF2:收银员，销售处理。
SF3:收银员,退货处理。
SF4:业务经理，库存分析;总经理,库存分析。
SF5:总经理，商品目录调整。
SF6:总经理,制定促销策略。
SF7:业务经理，商品报废。

5.4.3.2. 结构化边界描述：上下文图

上下文图：关注解决方案与环境之间的信息流输入/输出，以此界定解决方案的边界
抽取来源：
1. 需要的信息谁提供？
2. 产生的信息谁使用？
3. 谁控制它执行？
4. 谁影响它执行？

SF1:商品入库数量,业务经理(源头),系统内部使用;商品出库数量,业务经理(源头),系统
内部使用。
SF2:销售商品数量,收银员(源头),系统内部使用。
SF3:退货商品数量,收银员(源头),系统内部使用。
SF4:商品状态报告，系统内部数据源,业务经理与总经理(使用者)。
SF5:商品目录变更信息，总经理(源头),系统内部使用。
SF6:促销策略,总经理(源头),系统内部使用。
SF7:报废商品及其数量,系统内部数据源,业务经理(使用者)。

5.4.4. 确定解决方案的约束

对"新的销售订单系统"的约束

5.5. 案例分析

5.5.1. 业务需求

BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%
BR2：在系统使用3个月后，销售人员工作效率提高50%
BR3：在系统使用6个月后，店铺运营成本要降低15%
1. 范围：人力成本和库存成本
2. 度量：检查平均每个店铺的员工数量和平均每10,000元销售额的库存成本
BR4：在系统使用6个月后，销售额度要提高20%
1. 最好情况：40%
2. 最可能情况：20%
3. 最坏情况：10%

5.5.2. 涉及的用户及其任务

BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%
1. 客户经理：库存入库、出库、分析
2. 总经理：库存分析、促销、产品调整
BR2：在系统使用3个月后，销售人员工作效率提高50%
1. 销售人员：销售、退货
BR3：在系统使用6个月后，店铺运营成本要降低15%
1. 范围：人力成本和库存成本
2. 依赖于上两个目标的解决方案
BR4：在系统使用6个月后，销售额度要提高20%
1. 扩大销售：总经理：促销
2. 吸引回头客：客户经理：顾客管理(发展会员、礼品赠送)

5.5.3. 系统特性

SF1：分析店铺商品库存，发现可能的商品积压、缺货和报废现象：BR1，BR3
SF2：根据市场变化调整销售的商品：BR1，BR3，BR4
SF3：制定促销手段，处理积压商品：BR1，BR3，BR4
SF4：与生产厂家联合进行商品促销：BR1，BR3，BR4，CH
SF5：制定促销手段进行销售竞争：BR1，BR4，CH
SF6：掌握员工变动和授权情况：BR2
SF7：处理商品入库与出库：BR1
SF8：发展会员，提高顾客回头率：BR4，CR
SF9：允许积分兑换商品和赠送吸引会员的礼品，提高会员满意度：BR3，BR4，CR
SF10：帮助收银员处理销售与退货任务：BR2

5.5.4. 问题的用例图

5.5.5. 系统边界

由多个问题合并而来

5.6. 商业模式画布与问题分析

利用商业模式画布的九模块与模块之间的联系中抽取问题(问题分类)
利用商业模式的内、外评估与蓝海战略确定业务需求、生成系统特性、确定系统边界与开发约束(用于评估与量化的检查列表)
将生成的业务需求、系统特性、系统边界、开发约束与商业模式画布建立起联系，从而显式地维护各个元素之间的关联关系(可追踪)

网易严选的调整：复用渠道，强化产品，弱化自有电商。

6. 目标分析

面向目标的需求工程方法(Goal-Oriented Requirements Engineering)
为什么需要目标？
1. 面向目标的方法
  1. 将"目标"严格定义:单位、组织方式->目标模型
  2. 建立方法学支持:模型的建立与应用

6.1. 面向目标的方法

从早期就指导RE活动
1. 有利于需求的获取
2. 指导后期活动
为什么需要面向目标的方法
1. 业务需求不够严谨，在建模过程中无法形成方法学支持
2. 深层次分析组织及其涉众的目标、候选方案和隐式因素：深入理解涉众关注的领域。
得到业内的重视
1. 很多现存的方法学也开始整合对目标的分析与处理技术。目标概念在需求工程方法中的广泛被接受现象说明：目标已经成为了需求工程常用的核心概念"[Kavakli2002]。
2. 目标将会补充传统方法中的实体(Entities)概念和行为(Activities)概念，一起成为需求工程建模与分析的基本对象类别[Yu1998]。
3. KAOS[Dardenne93, van Lamsweerde1995]、NFR[Mylopoulos1992, Chung2000]、I*[Yu1997]、GBRAM[Anton1996, Anton1997]

6.2. 目标

目标就是系统被开发的目的。
目标模型的描述是需要精准描述和定义的。
面向目标的方法还给出了半形式化和形式化的描述(不必掌握)
1. 使用图形符号和文本符号的描述方式，具备一定的语义和语法规则。
2. 具有一定的特征属性，常见的有名称、类型、关注、定义(正式与非正式))、优先级、主体、拥有者、可行性、效用等

左图中O和W表示的是时序逻辑
P W Q 表示P必须一直为真直到未来某一点Q为真

目标描述
1. 类型
2. 属性
3. 链接

6.2.1. 目标可以有不同的抽象层次

高层次目标(G1)
1. 战略性的,全局的, 业务相关的
2. 增加50%的传输能力
低层次目标(G2)
1. 技术性的，局部的，产品设计相关的
2. 加速器每3秒发出一次命令

6.2.2. 目标的主体

目标需要有主体的参与和履职，主体是系统环境中的主动部分。
1. 主体可以是人、硬件和软件。
2. 主体具有主动性，他们可能需要约束自己的主动性来保证自己的主动性行为以确保目标的实现，比如发现商品积压则进行促销。
3. 越是抽象、粗粒度、范围广的目标，参与的主体越多，
4. 如果目标的主体只有软件，那么该目标等同于需求
5. 如果目标的主题只剩下系统环境中的一个对象，那么该目标等同于假设和依赖
区分主体和拥有者，拥有者通常是涉众，拥有者不一定参与目标达成过程。
G1的可能主体有库存管理员、信用卡刷卡器、税务系统接口。

6.2.3. 目标的分类

功能目标(Functional Goal)
1. 期望系统提供的服务。
2. 满足型目标(Satisfaction Goal)和信息型目标(Information Goal)
  1. 满足性目标：对行为者请求的满足。
  2. 信息型目标：保持对行为者的信息告知。
非功能目标(Non-functional Goal)
1. 期望系统满足的质量。
2. 常见的是质量目标(Quality goals)和约束目标(Constraint goals)、安全目标(Safety Goal)、性能目标(Performance Goal)、可用性目标(Usability Goal)等等
软目标(Soft Goal)和硬目标(Hard Goal)
1. 软目标：无法清晰判断是否能满足的目标，如关于可维护性的目标。
2. 硬目标：通过技术确认是否满足的目标，如关于性能指标的目标。

6.2.4. 目标的规格的基本模式

模式	符号描述	含义
实现(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)	-	最大化Maximize(目标功能) 或最小化Minimize (目标功能)

6.3. 目标模型的关系

目标模型的另一个核心要素是元素之间的关系，又称为链接
精化(Refinement)关系
阻碍(Obstruction)关系
支持与冲突(Support/Conflict)关系

6.3.1. 目标精化

一个高层次目标 $G$ $G$ 可以精化为低层次目标 $\{G_1,G_2,...,G_n\}$ ${G_{1}, G_{2}, . . ., G_{n}}$ ：
1. 如果一系列子目标 $\{G_1,G_2,...,G_n\}$ 的完成有助于目标G的完成，那么 $G$ 与 $\{G_1,G_2,...,G_n\}$ 之间就是AND精化关系。此时任意两子目标 $G_i$ 与 $G_j$ 之间是互补的。
2. 如果更进一步，子目标 $\{G_1,G_2,...,G_n\}$ 的完成能够直接保证G的完成 $\{G_1,G_2,...,G_n\}|=G$ ，那么 $G$ 与 $\{G_1,G_2,...,G_n\}$ 之间就是完备(Complete)AND精化关系。
如果任一子目标 $G_i$ 都是 $G$ 的替代方案，那么 $G$ 与 $\{G_1,G_2,...,G_n\}$ 之间就是OR精化关系。此时，任意两子目标 $G_i$ 与 $G_j$ 之间是互相替代的。
目标精化是目标模型的重要任务之一(Goal-oriented -> agent-oriented)
目标精化例子：描述火车管理系统的目标模型片段，3个高层的软目标：服务更多的旅客(ServeMorePassagers)、尽可能降低成本(Cost，类型Min)、安排运输(SafeTransport)

云朵就是软目标，最好写实现xxx
对ServeMorePassengers的工作可以同时(AND精化)从增加新班次( NewTracksAdded)和缩短班次间隔(TrainsMoreCloselySpaced)两个方面来实现。缩短班次间隔则可以通过(OR精化)减少站点间运行时间(TimeBetweenStations,类型Min)来实现。
降低成本的实现可以考虑降低新投资(DvlptCosts,类型Min)或者(OR精化)降低运营成本(OperationCosts,类型Min)。在实现安全运输的措施当中,有3个是必须同时(AND精化)达到的:一是要保持安全的车距(WCS - DistBetweenTrains,类型Maintain);二是列车的速度要保持在轨道能够承受的范围内(TrackSegmentSpeedLimit,类型Maintain);三是列车不要进人已经关闭的站台( TrainEntering-ClosedGate,类型Avoid)。

6.3.2. 目标阻碍

如果子目标 $O$ 的达成会使得高层目标 $G$ 失败 $O|=\neg G$ ，那么 $O$ 与 $G$ 的关系就是阻碍关系
阻碍目标也可以继续AND精化、OR精化
阻碍关系本身是一种特殊的精化:反向精化
阻碍关系如图5-9所示，其中的AccelerationSentInTimeToTrain目标与AccelerationCommand-NotSentInTimeToTrain目标之间就是阻碍关系。另外3个子目标NotSent、SendLate、SentToWrongTrain则是AccelerationCommandNotSentInTimeToTrain的OR精化。

6.3.3. 目标支持与冲突

多个目标之间关系
1. Support链接表示一个目标对其他目标的支持促进作用，支持关系可以被处理为OR精化关系
2. Conflict链接表示一个目标的实现对其他目标的实现有阻碍作用

符号	解释	描述
++	Make	一个目标的成功可以直接保证另一个目标的成功
+	Help	一个目标的成功可以让另一个目标更容易成功
-	Hurt	一个目标的成功会使得另一个目标的成功更加困难
–	Break	一个目标的成功会直接导致另一个目标的失败

NewTracksAdded和DvlptCosts是二元的冲突关系。

6.4. 目标与其他元素的关系

主体(Agent)
场景(Scenario)
操作(Operation)
任务(Task)
资源(Resource)
UML元素

6.4.1. 目标与主体关系

Assignment链接表示为实现目标而需要主体参与。
1. OR Assignment：多个主体中的一个来完成。
2. AND Assignment：多个主体一起共同完成

6.4.2. 目标与操作关系

AND Operationalization链接和OR Operationalization链接
目标实现过程中需要执行的操作， $G|= \{Spec(Op_1), ..., Spec(Op_n)\}$

6.4.3. 目标与场景关系

Cover链接表示场景涉及所有行为都是目标所包含的操作的子集
1. 帮助需求获取行为(针对分解后的子目标进行需求获取)
2. 帮助组织获取需求(将需求内容组织为场景，再将不通过场景归类汇总到目标)

6.4.4. 目标与数据模型

Concerns链接用来描述目标与应用领域对象(数据资源)之间的关系
所有被目标定义为Concerns属性的应用领域对象都应该与目标存在Concern链接关系。

6.5. 目标分析过程

目标分析是在需求工程前期阶段发生的，在非技术层次(目标的主体通常是涉众，尤其不能只有一个待开发系统)上建立目标模型，定义项目前景与范围的活动。

6.5.1. 面向目标的处理过程

高层目标的获取：现状和背景的分析：问题与缺陷
低层目标的获取：需求获取与目标分析
1. 已有目标的验证和细化(基于目标分析)
2. 基于场景的方法等等(基于目标实现)
目标分析：精化与分解，建立系统的目标模型
目标实现：收集与目标相关的需求信息，讨论可能的候选解决方案，确定最终的系统详细需求和解决方案

6.5.2. 分析示例的描述

×××连锁商店是一家刚刚发展起来的小型连锁商店，其前身是一家独立的小百货门面店。原商店只有销售的收银部分使用软件处理，其他业务都是手工作业，这已经不能适应它的业务发展要求。首先是随着商店规模的扩大，顾客量大幅增长，手工作业销售迟缓，顾客购物排队现象严重，导致流失客源。其次是商店的商品品种增多，无法准确掌握库存，商品积压、缺货和报废的现象上升明显。再次是商店面临的竞争比以前更大，希望在降低成本，吸引顾客，增强竞争力的同时，保持盈利水平。
BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%
BR2：在系统使用3个月后，销售人员工作效率提高50%
BR3：在系统使用6个月后，店铺运营成本要降低15%
1. 范围：人力成本和库存成本
2. 度量：检查平均每个店铺的员工数量和平均每10,000元销售额的库存成本
BR4：在系统使用6个月后，销售额度要提高20%
1. 最好情况：40%
2. 最可能情况：20%
3. 最坏情况：10%

6.5.3. 高层目标的获取

可以归因于企业的最高目标是生存的愿望
现状和背景的分析：问题与缺陷，需要实现的目标和保持的目标
实现保持目标
1. 通过规范与环境中其他企业的关系来维护企业规范。
2. 与客户，供应商，员工，投资者等保持关系。
我们结合模型将目标组织成目标模型

6.5.4. 目标精化

得到高层目标模型后，我们需要对高层目标模型进行精化，并且根据精化结果完善目标模型。
目标模型精化需要获取高层目标的相关信息并进行分析，发现其子目标，总结不同方法的目标精化过程。

6.5.4.1. 获取对高层目标的描述

通过收集背景资料，运用面谈、原型等需求获取方法，可以收集到对高层目标的描述信息。
常规描述信息包括企业规章、政策、任务描述、业务描述(比如工作流程)和场景描述。

从面谈报告中发现目标	从场景描述中发现目标

建议尤其要注重对信息持有情况的获取,如存储、加工和输出数据信息,因为这很常见，意味着相应Maintain目标的存在。例如,在收集图5-15所示高层目标"减少缺货、积压与报废"的描述信息时,可以发现需要持有库存数据,包括销售数据、退货数据、批量人库数据和批量出库数据,那么就可以建立1个目标(库存数据)和4个AND精化子目标(销售数据、退货数据、批量入库数据和批量出库数据),如下图所示。

6.5.4.2. 从高层目标描述中发现AND精化关系

发现AND精化关系：
1. 同一个目标有不同场景：每个 $G_i$ 代表一个典型场景，任意 $G_i$ 与 $G_j$ 代表不同的场景；
2. 完成目标有连续过程：每个 $G_i$ 代表 $G$ 完成过程中的一个状态， $G_{i}、G_{i+1}$ 代表两个连续的状态；
3. 完成目标需要有多个方面紧密配合： $G_i$ 与 $G_j$ 紧密联系或互相支持；
4. 目标有不同质量环境及表现：每个 $G_i$ 代表不同质量要求下的G的完成。
收银员有两个场景：AND精化

"减少积压缺货、积压与报废"有多个步骤 $\Rightarrow$ AND精化：持有库存数据 $\Rightarrow$ 分析数据尽早发现可能的缺货、积压与报废 $\Rightarrow$ 预先处置可能的缺货、积压与报废

"减少人力成本"的实现需要减少人员与提高人员工作效率两个方面的紧密结合 $\Rightarrow$ AND精化

6.5.4.3. 从高层目标描述中发现OR精化关系：多种可以相互替代的"候选办法"

目标"提高销售额"可以让更多的人来买和(单人)卖的更多两个方面分别找替代方法 $\Rightarrow$ OR精化

6.5.4.4. 目标精化汇总(不包含阻碍、冲突等关系)

6.5.5. 考虑阻碍目标实现的情况(avoid目标)

考虑使得子目标失败的阻碍，添加针对子目标的阻碍目标。
考虑主体行为导致目标失败的阻碍，添加针对高层目标的阻碍目标。
考虑预防失败的情况，即为高层目标添加阻碍目标，避免阻碍的出现。
发现太理想化的目标时，重新处理目标，缩小目标范围或为太理想化的目标添加约束。
发现因为应用领域不一致导致的目标阻碍时，将应用领域转为一致,消除阻碍现象。
比如"利润下降"和"销售更多商品"两个目标就是不同视点之间的冲突。

6.5.6. 考虑已有目标之间的支持与冲突关系

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

6.5.7. 对高层目标问"how"，对低层目标问"Why"，建立层次结构

对于各个建立目标模型的事项中，都要坚持对高层目标问"怎么实现(How)"，对低层目标问"为什么需要(why)"，来实现层次结构。
关注其主体：涉众，了解他们的观点和贡献往往能够帮助发现描述信息不足的目标的精化线索。

在考虑"怎么实现"时，还要注意区分"目标"与"任务"的不同:
1. 目标是一个**条件(硬件目标)或条件倾向(软件目标)，**一个目标的完成有很多种方式，可以用不同的任务来实现。
2. 任务是一个活动，是实际情况的反映，不是条件倾向，任务完成是指活动结束而不是某个条件得到满足。
3. 任务的执行有成功的、好的，也有不成功的、坏的,只有成功的、好的任务执行才能促使目标的满足。
需要专门强调的是,目标精化并不是一个自上至下分解的过程,而是一个不断获取、发现和分析的过程。

6.5.8. 目标精化的结束条件

子目标展开到单一事务时终止
1. Agents与System的一次协作活动
2. 连续活动，要求全部成功(要么全部失败)
3. 确认这些单一事务能够增加业务价值
单一事务可以被进一步展开为场景(任务的要求=>单个任务的描述)

6.5.9. 目标精化的约束

注意识别目标隐含的：

假设与依赖，例如：
1. 商业规则，特定场景限定
2. 市场与环境假设，业务过程假设…
质量属性
约束：资源依赖

6.6. 目标实现

任务是手机与目标相关的需求信息，讨论可能的候选解决方案，确定最终的解决方案。
主要工作
1. 将底层目标分配给主体
2. 由实现设计最底层目标的任务。
注意某些不在软件系统考虑范畴内的不必细化：也就是如果一个目标的责任被分配给了涉众，待开发的软件系统没有介入，说明这个目标没有纳入项目范围，但是必须记为项目假设和依赖，比如总经理的提前初值缺货商品。

7. 为隆中对构建目标模型与分析

8. 基于目标模型获取非功能需求——NFR(Non-Functional Requirements)

8.1. 为什么需要非功能需求分析

非功能需求已经超过功能需求成为决定项目成败的关键因素。
技术处理
1. 面向产品：保证产品能够满足非功能需求。
2. 面向过程：在整个软件开发过程中始终关注非功能需求。

8.2. 非功能需求分析的困难

没有提供足够的方法：一旦考虑到非功能性问题，就会限制功能分析或面向对象的分析
NFR很难表达。原因：
1. 非功能需求不集中，在系统中散布：难以界定它们的边界，也就难以描述和处理
2. 非功能需求不独立，依赖于功能需求：处理非功能需求时很难脱离功能需求进行独立考虑
3. 作为非功能需求主体的质量需求比较复杂：需要被分解为特征-子特征的层次结构
4. 非功能需求不独立，相互冲突、依赖：需要建立不同非功能需求之间的关系描述，比如性能与安全反相关。
根本困难是不独立性。

8.3. 使用面向目标的方法分析非功能需求

将非功能需求建模为目标
1. 在早期信息较为抽象和不充分时建模为软目标，后期添加目标满足标准修正为硬目标，这样符合需求开发的基本过程。
2. 让非功能目标支持、阻碍或精化功能目标，描述非功能需求对功能需求的依赖关系。
3. 让单个非功能目标依赖多个不同的功能目标，描述非功能需求的散布特性。
4. 使用支持、阻碍(冲突)精化描述不同非功能目标之间的折中与冲突关系。
5. 依赖质量模型，高层非功能目标精化为子非功能目标，描述非功能需求的层次结构关系
NFR方法是一个以目标模型为基础，同时包含获取、与其他需求模型的整合以及分析、规格化、验证等其他是需求开发活动框架。

8.4. 获取非功能需求及建立目标模型的简单过程

第一步：依赖功能需求识别、获取非功能需求目标
1. 涉众是没有意识到非功能需求，而不是没有
2. 注意涉众对功能描述
  1. 好用：易用性目标
  2. 小心谨慎：可靠性目标
  3. 数据比较多、计算复杂：性能目标
  4. 调整、修改、增加：可维护目标
  5. 数据敏感性：安全目标
  6. 关联技术环境：可移植性
3. 如图5-20所示,功能目标"将控制交通情况可视化"中的文字"可视化"可能意味着人机交互界面有质量要求，仔细描述后可以发现，可视化意味两件事情:将众多复杂数据清晰地显示在一个屏幕.上;实时刷新动态数据。于是就可以发现相应的非功能需求目标，分析后可以建立如图5-20所示的目标模型。

第二步：根据非功能需求层次结构、精化非功能需求目标
1. 有时获取到的非功能需求目标是比较简单的，例如图5-20所示的"实时显示雷达数据"。
2. 但更多的时候获取到的非功能需求是比较复杂、抽象的，典型情况是只获取到了质量模型的特征级质量需求。这时可以依据质量模型或其他非功能需求层次结构描述，将特征级的质量需求目标精化为子特征级的质量需求子目标。例如图5-19中,将安全目标"数据安全"精化为"防范恶意攻击""阻止合法误访问"两个更准确的子目标。

第三步：量化底层非功能需求目标的验收标准：
1. 在高层NFR目标模型中,因为复杂、抽象等原因，主要使用软目标描述非功能需求目标。但最终的规格化及验证需要可以验收的非功能需求目标。
2. 所以到了NFR分析后期，要为NFR目标模型中的底层非功能需求目标确定量化验收标准，如图5-20所示。

9. 业务过程分析

课本P121-134

9.1. 活动图(不考)

基于数据流图 $\Rightarrow$ 业务过程模型(Business Process Model) $\Rightarrow$ UML 活动图
反映复杂的工作流
核心思想是令牌平衡 Token balance!

9.1.1. 活动图节点

动作(Action)节点：数据处理，任务
控制(Control)节点：协同流转
1. 初始(Initial)
2. 结束(Final)
3. 决策(Decision)
4. 合并(Merge)
5. 分叉(Fork)
6. 汇合(Join)
对象(Object)节点：是指一个特定对象的实例

9.1.2. 活动图示例

9.1.3. 令牌平衡

一个控制流传递一个令牌。
一个对象流传递一个令牌。
决策节点从流入流接收到一个令牌后传递给多个流出流中的一个。
合并节点从多个流入流中只要接收到一个令牌就传递给流出流。
分叉节点从流入流接收一个令牌后，复制出多份令牌，给每个流出流都传递一个令牌
汇合节点从每个流入流都接收一个令牌，或者流入流的令牌接收情况符合汇合规格，就向流出流传递一个令牌。

9.1.4. 令牌不平衡

令牌不平衡意味着业务工作缺陷：丢失—有工作被忽视；缺少—有并发活动开始没有被认识到；多余—有并发活动结束没有被认识到

解决令牌不平衡问题

9.1.5. 复杂的令牌机制

9.1.6. 信号与事件机制

9.1.7. 异常与中断机制

9.1.8. 分区

9.1.9. 层次结构

将单个复杂业务过程分解为多个更简洁的活动图

9.2. 建立活动图

确定活动图的上下文环境：界定业务流程的处理界限
分析业务流程中的主要处理步骤
分析业务流程中的主要数据流
识别参与者，进行职责分配，将业务流程的处理步骤划分到不同的泳道，并将处理步骤和数据流的传递组织起来，建立活动图
添加活动图的详细信息，完善活动图描述，
尤其要注意下列工作：
1. 分析不同动作之间的协同是同步还是异步，同步使用控制流和数据流，异步使用信号与事件。
2. 分析是否存在业务过程失败场景，添加流终结节点。
3. 分析是否存在较为复杂的行为，为其建立活动。
4. 分析业务过程中是否有异常，补充异常处理。
5. 始终要检查令牌平衡，修正不平衡的节点。

9.3. 活动图和目标

活动是行为，因此应将其描述为目标
行动的参与者(分区)是目标的代理人

10. 定义系统边界

系统边界是系统与环境互动的界限，定义系统边界可以明确系统需要满足的与外界的交互行为，从而从宏观上界定了系统的功能概要。
系统边界是需求工程后期阶段需求分析活动的起始模型，后期的需求分析可以看成是逐一细化系统边界中的对外交互行为的活动。
1. 结构化方法用上下文图，关注系统与环境的输入输出数据流交互
2. 面向对象方法用系统用例图，关注系统与环境的功能性(目的性、任务性)交互

10.1. 问题分析与系统边界定义

每个问题的解决方案边界的合并(叠加、汇总、补充)

10.2. 目标分析与系统边界定义

边界目标：分配主体包括"将要构建的系统"和系统环境(涉众、硬件、其他系统等)的底层目标,这往往意味着存在系统与环境的互动,它们就是系统边界定义要考虑的目标
分析边界目标所覆盖的场景和操纵的操作(任务),可以得到系统用例，并据此建立面向对象的系统边界定义——系统用例图。
分析边界目标所关注的数据对象，可以得到系统与环境的输入/输出流,并据此建立结构化的系统边界定义——上下文图。

10.3. 业务过程分析与系统边界定义

活动图的每一个动作都可能(未必一定)是一个用例,可以据此完善面向对象方法的系统用例图。
活动图的每一个对象流都可能(未必一定)是一个系统与环境的输人/输出数据流，可以据此完善结构化方法的上下文图。

10.4. 系统用例图示例

10.5. 上下文图示例

11. 前景和范围文档

业务需求、高层次解决方案和系统特性都应该被定义到项目前景与范围文档之中
前景与范围文档主要由需求工程师来完成，但文档的负责人一般是项目的投资负责人、执行主管或其他类似角色
文档中记录的应该是清晰、明确的业务需求、高层次解决方案和系统特性
项目合约或抽象的业务用例文档也可以实现类似目的

11.1. 文档结构(建议看课本)

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

完整例子见课本P135-141

11.2. 示例

A vision and scope document
RUP V&S Document Template
And an example

11.3. 实践中确定项目的前景与范围

在公司内部，为确定项目的前景和范围，一般通过用户开会，进行摸底。由于公司的用户一般都是非计算机专业出生，一般对于项目的前景和范围，主要从实际工作出发，提出构想和思路，但是有个明显的问题是，有些构想太过理想化，有些思路又太过细节。
面临最大的挑战就是：由于公司业务的快速变更和快速拓展，公司内部员工提出的需求，比较难落到实处，太虚的目标都比较大，细节的需求又太细。
所以，我们的项目需求收集人员，不仅要能熟悉业务，而且要懂得归纳，懂得演绎，确实存在不少困难。

12. 本章小结

确定项目的前景和范围是需求工程以及整个项目的重要工作，它决定着整个项目后继工作的方向
确定项目的前景和范围
1. 简单情况下可以使用问题分析方法
2. 复杂情况下需要基于目标模型进行
3. 如果涉及复杂工作流程，就需要进行业务过程分析
4. 如果涉及复杂非功能需求，可以借助目标模型来进行
项目的前景和范围需要以文档的方式明确的固定下来

13. 思考：为新的直接销售和财务处理系统制定解决方案

Especially for You Jewelers是大学城的一个小珠宝零售商。在过去的两年里，Especially for You在它的商业方面经历了极大的发展，可是，它的财务业绩却与它的发展不同步。现在的事务处理系统部分手动、部分自动，不能有效的追踪客户账单和收据，Especially for You难以确定为什么它的成本这么高。此外，Especially for You频繁地实行特价以吸引顾客。它不知道这些特价是否有利可图，是否带来其他的销售。Especially for You也想增加回头客，所以它需要一个客户数据库。Especially for You想按照一个新的直接销售和财务处理系统以帮助解决这些问题。

13.1. 描述业务需求，描述解决方案

IT部门经理在部门会议上说道：“我有一些好消息，也有一些坏消息。好消息是公司高层今天早晨已经批准了‘工资管理系统项目’。新系统要减少文书工作的时间和错误，提升工资管理部门的士气，避免可能的违约漏洞与损失。坏消息是为满足新的国家法律报表要求系统必须在12月底前完成，成本要控制在预算之内，新系统要能够与已有系统交互，并且财务经理坚持要审查最终的设计方案。”

13.2. 思考

为什么要界定系统边界？系统与环境互动的界限，明确系统需要满足的与外界的交互行为，从而从宏观上界定了系统的功能概要。需求分析逐一细化系统边界中的对外交互行为的活动
为什么结构化分析与面向对象都要从系统边界开始？
你被任命为替换学生财务资助项目的项目经理。你想开发一个工作陈述来定义范围并降低范围蔓延的风险。
财务资助部门的主管坚持要你15个月、600 000美元的预算内替换他现有的系统就可以了。他说这就是你需要知道的全部，不需要浪费时间开发一个工作陈述了。
省略工作陈述的风险是什么？你将如何说服主管？
一个需求工程师正在为一个信息系统考虑三个可选的解决方案，所有三个方案都满足了用户的业务需求。
1. 第一个方案被认为与开发人员的技术知识最一致，
2. 第二个方案被认为是最快的实现方案，
3. 第三个方案是最划算的方案。
这三个方案中是否有一个可行方案？如果是这样，你认为需求工程师应该如果做出最后决定？
某大银行的一位银行卡办公室的收账经理Liz遇到了一个问题。她每周都收到一份过期未付款的账户名单。
这份报告已经从两年前的250个账户增加到现在的1250个账户。为了确定那些严重拖欠债务的账户，Liz需要通读这份报告。严重拖欠债务的账户由几个不同的规则确定，每个规则都要求Liz检查客户的一项或几项数据。过去半天的工作量现在增加到了每周三天。即使在确定了严重拖欠债务的账户后，如果没有查阅该账户三年内的历史资料，Liz也不能做出最后的信用决定(例如严厉的催款电话、断绝信用或将这个账户转给一个收账代理)。另外，Liz需要报告所有账户中过期未付款的、拖欠债务的、严重拖欠债务的和呆死账的比例。目前的报告中并没有给她提供这个信息。
假设现在需要你来开发一个软件，解决Liz面对的难题。那么你认为Liz现在遇到的问题有哪些？你希望新的软件应该达成哪些业务目标？你怎样设计软件的高层解决方案和系统特性？

2020-需求与商业模式创新

#课程笔记 #需求 #目标

2020-需求与商业模式分析-Book5-确定项目的前景和范围

https://spricoder.github.io/2021/01/17/2020-Demand-and-business-model-innovation/%E9%9C%80%E6%B1%82/2020-Demand-and-business-model-innovation-Book5-%E7%A1%AE%E5%AE%9A%E9%A1%B9%E7%9B%AE%E7%9A%84%E5%89%8D%E6%99%AF%E5%92%8C%E8%8C%83%E5%9B%B4/

作者

SpriCoder

发布于

2021年1月17日

许可协议

2020-需求与商业模式分析-Book6-涉众分析与硬采样上一篇

2020-需求与商业模式分析-Book4-需求获取概述下一篇