需求与商业模式创新-需求2-需求基础

Book2-需求基础

1. 需求的定义(IEEE)

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

2. 满足需求就是解决问题

1. 需求开发的最原始出发点就是用户需求，或者需求的源头：问题。

2.1. 问题与需求

1. 问题的产生地：当现实的状况与人们期望的状况产生差距时，就产生了问题。
2. 解决问题的方法：就要改变这些事件、事物的状态，或者改变其状态变化的演化顺序，使其达到期望的状态和理想的演进顺序，使其达到期望的状态或演进顺序。
3. 开发软件系统的目的：希望用它作为解决方案来解决问题，使得现实改善到期望的状况。
4. 例子:企业当前利润率为2%，希望开发和应用一个软件系统能够利润率提高到5%。
   1. 问题：利润率低，低3个百分点
   2. 期望的状况：利润率为5%
   3. 需求：将利润率提高3个百分点或者将利润率提高至5%

2.2. 问题解决的两个方面：问题域与解系统

软件，一种信息制品，为何能解决问题域中的问题，为人服务？

2.2.1. 问题域

1. 问题域即解决问题所必须涉及的事件和事物(实体和状态)
2. 问题域是需求的背景
   1. 要理解需求"将利润率提高到5%"，就需要明确利润是哪些部分组成的，分别是什么样的。
   2. 要理解需求"用户可以查询商品详细信息"，就需要了解用户在哪些任务中需要查看哪些商品的详细信息。
3. 问题域的背景信息，又被称为问题域特性，问题域和需求的区别:
   1. 问题域是自治的，有自己的运行规律，这些规律不会因解系统的引入而发生改变
   2. 需求是一种对未来的期望，是可以打折、部分满足甚至不予满足的，比如将利润率提高到5%，我们可以部分满足，只提高到3%。
   3. 问题域特性是既定现实，可以改善但不能忽视，更不能违背的，比如问题域特性是用户的销售市场遍布全国，那么就不能只考虑一个地点的销售情况。
4. 在美股交易交易前十的股票中有三家是新能源汽车，则新能源汽车中软件系统的问题域有哪些？车联网、自动驾驶、5G的重要应用领域、续航能力：电量控制的问题解决，续航能够超过260公里，电池并没有本质变化，分析能力有效提高，实现电池之间的协同协作。

2.2.2. 问题域特性

1. 问题域的背景信息(问题域自治的规律性)，被称为问题域特性：利用商业模式画布进行更好的描述
2. 需额外关注的问题域特性
   1. 间接特性(semi-automatic)
   2. 约束和假设：社会性因素
3. 问题域特性的重要性
   1. 要想解决问题，它就需要了解问题域特性，将解决方案和问题域特性结合起来
   2. 要防止解系统的引入在问题域当中引发未预见的连锁反应(例：间接特性不直接与解系统交互而引发)

2.2.3. 解系统

1. 软件系统通过影响问题域帮助人们解决问题，称为解系统。
2. 解系统中软件起主要作用：不是唯一作用
3. 解系统是问题的解决手段，并不是问题的产生地，所以解系统并不是问题域的一部分。解系统和问题域之间有可以相互影响的接口，以实现交互活动。

2.2.4. 不同角色不同的关注点

1. 用户关注问题域，而不应该关注软件系统
2. 开发人员关注解系统，应该以问题域为中心思考
3. 需求工程师扮演桥梁作用：现实世界方面与技术方面的桥梁
   1. 用户不需要了解和关注解系统
   2. 软件开发者不需要关注问题域
   3. 需求工程师通常是技术人员，来自解系统领域，但是他们必须要懂得如何站在用户(涉众)的立场，与用户(涉众)进行基于问题域的交流。
   4. 好的需求工程师更应该扮演好涉众代理的角色，站在涉众的立场想问题，替涉众跟踪和监控软件开发过程，保护涉众的利益

2.2.5. 问题域、要求与需求

1. 需求是用户对问题域中的实体状态或事件的期望描述
2. 需求并不针对解系统，所以其描述应该尽可能使用问题域的语言，而不应该包含"数据仓库技术"等计算机词汇。
   1. 不恰当的需求:如果用户在销售列表信息界面中选中一个商品，点击查看按钮，系统将显示商品的详细信息界面。
   2. 修改后的恰当的需求:在用户请求查看具体商品时，系统应该显示该商品的详细信息，包括条码、名称、价格和厂家。

2.2.6. 解系统与需求规格说明

1. 解系统的核心是软件解决方案和解决方案在通过计算机上的实现
   1. 软件解决方案描述了软件系统与问题域交互的过程，侧重于软件系统中与外界交互的部分。
   2. 实现部分则主要关注软件内部的组成元素等软件系统的构造要素。
   3. 解决方案被称为软件系统的需求规格说明
2. 需求工作衔接中
   1. 需求是用户与需求工程师协作基础
   2. 解决方案是需求工程师与软件开发者的协作基础

5. 需求开发的最终目的就是提供一个高质量的需求规格说明。需求规格说明是解系统为满足用户需求而提供的解决方案，规定解系统的行为特征。
6. 需求规格说明的典型描述方式
   1. 系统能够…
   2. 如果用户提出…请求，那么系统应该…

2.3. 问题解决的基础:模拟与共享现象

1. 软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性
2. 问题域与解系统能够形成互动的基础是解系统部分模拟了问题域，这种模拟性叫做共享现象。
   1. 模拟是指其中一方仿制另一方的信息。
   2. 解系统对问题域的模拟比较复杂，二者之间的模拟性具有交互性:
      1. 解系统会在自身中保持一份与问题域现象一致的信息，并随着问题域现象的变化而变化
      2. 问题域会期待在解系统中看到一致的信息，并据此展开自己的行为。
   3. 软件系统当中含有问题域某些部分的模型(或模拟)，常见的模型包括数据模型、对象模型、处理模型等。
   4. 问题域中的某些信息能够和模型中的信息建立映射关系
3. 解系统与问题域模拟的交互性是由人在意识中强制建立的。如果用户并未将现实发生的情况实时地输入到软件系统中，或者用户在工作时完全忽视软件系统提供的输出，那么软件系统就会失去影响和改变现实的能力。
4. 问题域中有一些没有被解系统模拟，不可能也没必要在解系统中完全重现。
5. 解系统也会包括一些并非来自于现实模拟的特征，例如数据库管理系统的选择等，因为这些因素并不对应任何问题域知识，却是解系统必不可少的部分。
6. 共享现象就是解系统所模拟的问题域部分，该部分在两个系统中同时存在，是通过映射建立的共同知识
   1. 利用数据表模拟库存与金额、坐标模拟位置、账户登录模拟开锁或授权，像素模拟图形、流数据模拟音频视频、AI模型模拟智力
   2. 游戏中的PVE与PVP互动、支付软件中的转账与支付、各种匹配、调度与推荐算法(游戏对手、商品、打车、短视频、信息流、相亲)

2.4. 问题解决方法:直接与间接

1. 共享现象(模拟后的知识)是解系统的一部分，所以解系统可以对其施加操作，适当改变这些知识，进而知识改变通过交互性传递给问题域，问题域在会接受改变的基础上继续规律性的运作，使问题得以解决。
2. 比如张三在现实世界中存了1000元，则数据库记录中添加了1000元，这样其他银行职员看到这条数据库记录后则也就知道了张三存了1000元的现实。
3. 成本是非常重要的因素
   1. 成本可以接受:直接方式解决
   2. 成本不可以接受：间接方式折衷

2.4.1. 直接方法

1. 模拟并操纵共享现象是软件系统满足需求最直接的方法
2. 比如系统记录了人的联系方式，那么软件系统可以完成通知任务。

2.4.2. 间接现象

1. 软件系统操纵共享现象影响问题域的一部分，然后利用问题域内在的规律性自动影响另一部分是软件系统满足需求简介方法。
2. 比如软件系统知道是谁没有还书，但是没有联系方式，那么可以通过告知管理员由管理员去通知的方式来间接完成。
3. 提醒需求工程师考虑问题域内的特征性，避免设计解决方案引入导致引发预期之外的连锁反应。比如车辆调度系统中，在公交公司中，我们只需要调度每一辆车就可以间接影响到驾驶员。

2.5. 问题解决方案——需求规格说明

1. 解系统解决问题的方案是改变共享知识，影响问题域的运行，进而满足用户的需求。
2. 需求规格说明包含两部分:
   1. 数据：对共享现象(模型)的描述，是现实世界的模型。
   2. 功能：对系统对共享现象所施加的操作的描述(功能)，对模型的操作，将结果反馈会现实世界，(辅助)解决问题
      1. 过程式分析：以功能分解为核心
      2. 面向对象分析：以封装的数据与对数据的操作为核心

2.6. 需求开发的形式化定义，问题解决的困难性

1. 如果拥有描述明确的问题域特性$E$和定义良好的系统行为$S$，就可以很容易地发现将系统应用到问题域后会产生的效果。这种效果如果符合预期的需求$R$，那么系统就是满足人们需要的系统。记为$E,S|\to R$
2. 问题解决的困难：
   1. 不存在描述明确的问题域特性E
   2. 不存在确定的针对S的评估标准R
   3. 根据问题域特性和系统行为预测系统应用效果是简单的，但是根据问题域特性和期望的系统应用效果构建系统行为的过程是困难的，也就是$E,S\to R$是一个创造性过程。
3. 需求工程的主要工作：
   1. 进行需求开发，确定用户的期望效果R
   2. 研究问题背景，描述问题域特性E
   3. 构建解系统，描述解系统行为S，使得$E,S|\to R$

2.7. 需求工程的基本活动与实质

2.8. 商业模式部分与需求工程部分的异同

1. 商业模式部分连接需求工程部分的内容
   1. 整套商业模式画布充当需求工程中从问题域抽取问题的方法与工具
   2. 商业模式设计与评估可视作IT企业自驱动创新的产品构思(以"人"为主)
2. 需求工程部分独有的内容
   1. 问题 – 目标 – 任务 – 交互的(基于各种模型的)逐层转化
   2. 以目标客户的需要(以"业务"为主)为驱动的需求工程与分析

3. 需求和问题都有层次性

1. 需求是问题解决的期望。
2. 问题和期望粒度不同的现象被称为需求的不同抽象层次

3.1. 需求层次划分

1. 需求的层次性：
   1. 业务需求
   2. 用户需求
   3. 系统级需求
2. 软件解决方案：
   1. 问题->目标->用户需求->系统级需求
   2. 背景->系统特性->问题域知识->分析模型
3. 目标是商业目标
4. 任务是用户任务
5. 系统行为是用户与系统的交互

3.2. 业务需求(与战略问题)

1. 针对整个业务的需求，是抽象层次最高的需求(Objective)，是系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统。
   1. 需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性。
   2. 高层次解决方案及系统特性指出了系统建立的方向，参与各方必须就它们达成一致，以建立一个共同的前景(Version)，保证涉众朝着同一个方向努力。
   3. 系统特性说明了系统为用户提供的各项功能，限定了系统的范围(Scope)，定义良好的系统特性可以帮助用户和开发者确定系统的边界。
   4. BR向SF的转化过程可以利用商业模式画布。
2. 示例(R、BR为业务需求，SF为高层次解决方案)
   1. BR1(核心资源):在系统使用6个月后，商品积压、缺货和报废的现象减少50%。
   2. BR2(关键业务):在系统使用3个月后，销售人员工作效率提高50%。
   3. BR3(成本结构):在系统使用6个月后，店铺运营成本降低15%。
      1. 范围:人力成本和库存成本。
      2. 度量:检查平均每个店铺的员工数量和平均每10000元销售额的库存成本。
   4. BR4(收入来源):在系统使用6个月后,销售额度提高20%(最好情况:40%;最可能情况:20%;最坏情况:10%。)
   5. 每个业务需求目标/指针可由针对画布模型的评估而确定
3. 业务需求必须是可验证的，其验证指标是通过研究问题域的背景资料得出的，其验证标准可以是：
   1. 一个数值指标，如BR1-BR4;
   2. 一个直接的有无、是否等判定，例如，下述BR5、BR6验收时就是有与没有的判定。
      1. BR5:跟踪记录储户的存取款情况。
      2. BR6:跟踪记录VIP顾客信息。
4. 其中SF1、SF3、SF7针对BR1与BR3，SF2针对BR1和BR4，SF4、SF5、SF8、SF9针对BR4、SF10针对BR2和BR3.

BR1(核心资源):在系统使用6个月后，商品积压、缺货和报废的现象减少50%。
BR2(关键业务):在系统使用3个月后，销售人员工作效率提高50%。
BR3(成本结构):在系统使用6个月后，店铺运营成本降低15%。
   范围:人力成本和库存成本。
   度量:检查平均每个店铺的员工数量和平均每10000元销售额的库存成本。
BR4(收入来源):在系统使用6个月后，销售额度提高20%(最好情况:40%;最可能情况:20%;最坏情况:10%。)

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

5. 业务需求级别的抽象用例

用例x：商品管理
级别：概要(抽象)
目标：减少商品积压、缺货和报废的现象
场景
   1、分析店铺商品库存，发现可能的商品积压、缺货和报废现象
   2、制定促销手段，处理积压商品

3.3. 用户需求(与任务问题)

1. 针对具体任务的期望，即执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。
2. 用户需求来源渠道
   1. 直接渠道：用户。
   2. 间接渠道：销售人员和售后支持人员，比如通用软件系统等等

例如，在超市管理系统中，收银员用户的需求如UR1~UR5所示。
   UR1:收银员可以使用系统逐--记录销售的商品。
   UR2:收银员可以使用系统计算商品账单并处理付款情况,账单计算需要使用促销策略。
   UR3:收银员可以使用系统为顾客打印收据。
   UR4:收银员可以使用系统退回顾客已经购买的商品。

3. 用户需求是对任务的期望，基本表达方式"xx用户可以使用系统完成xx任务"
   1. 用户任务应该是有价值的活动(客户洞察)，并具有较强的目标性(细化的讲故事与场景)
      1. 比如向"ATM机中插卡"就不是用户需求，因为用户不会漫无目的的插卡。
      2. 在上例以及其他诸多情况下，区分开目的和手段。
   2. 对所有的用户需求，都应该有充分的问题域知识作为支持。
4. 用户的任务可以有不同粒度的抽象表述，大的任务可以包含(分解)小的任务，我们建议使用无法进行任务分解的粒度，同样我们可以使用嵌套层次结构。
   1. 粒度的选取我们可以根据软件系统的复杂程度，最好是给出无法进行任务分解的用户需求，但是在比较复杂的软件系统中，比较抽象的用户需求也是可以接受的。
   2. 比如UR1-UR3命名为UR5.1-UR5.3表明是对UR5细化。
5. 用户需求的特点
   1. 模糊、不清晰：允许适度使用形容词和副词
   2. 多特性混杂：将功能需求和非功能需求混杂在一起
   3. 多逻辑混杂：用户需求是对用户任务的描述，任务本身往往由前后相继的多个逻辑处理过程，即一次用户任务对应多次系统交互才能完成。
6. 用户需求往往需要补充完整的问题域知识，比如对于UR1需要补充问题域知识

Data:需要记录的商品信息,包括ID、名称、描述、价格、特价、数量和总价。
Format:ID为xxx格式的条码。
Rule:总价=特价x数量。

7. 需求开发阶段可视作从用户需要解决的问题到用户与系统的一系列交互的转化，此过程中用户的输入与获得的反馈不断精化，但系统本身仍被视作一个整体，留待后续设计阶段确定模块划分与结构
8. 用户需求示例:连锁商店销售系统

用例1.1：销售处理
级别：用户需求
目标：快速、正确地完成商品销售
场景
   收银员可以逐一输入销售商品，系统记录并显示商品列表(UR1)
   系统结合促销策略，计算商品账单，收银员处理付款情况(UR2)
   系统记录销售信息，收银员使用系统打印收据(UR3)
扩展场景
   系统记录会员用户积分，收银员使用积分抵扣货款

3.4. 系统级需求

1. 系统需求是用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求，适合软件开发者，是很精确的。
2. 系统需求可以直接映射为系统行为(对应需求规格说明)，定义了系统中需要实现的功能，描述了开发人员需要实现什么。
3. 一般典型表述形式为"系统可以xxx"或者"在xx用户提出xx请求时，系统应该xxx"。
4. 需求分析:系统级需求就只能通过技术加工获得。
   1. 源对象:用户需求以及相关的问题域知识
   2. 处理方式是利用分析方法、技术建立需求分析模型，并给予需求分析模型将用户需求及问题域知识转化为系统级需求。
5. 一个软件系统的系统级需求集合定义了相应的业务需求以及用户需求的解决方案，构成了需求规格说明的主体部分。
6. 将用户需求转化为系统需求的过程是一个复杂的过程
   1. 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
   2. 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
   3. 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。

SR1及其嵌套、SR2属于细节的功能需求，DR1和Rule3是对功能需求的补充需求，分别属于数据需求和规则约束需求。

3.5. UR与SR

1. 用户需求和系统级需求在实践中经常是混淆的
   1. 用户习惯于用户需求；
   2. 开发者需要系统级需求，但得到的往往是用户需求
      1. 未能得到足够信息以准确地完成设计与实现工作
      2. 需要开发者以各自方式进行假设…
2. 正确处理用户需求和系统级需求
   1. 明确其不同点
      1. 用户需求：任务
      2. 系统级需求：交互
   2. 明确建立和维护用户需求与系统级需求的关系
   3. 系统级需求的建立需要需求分析人员的创造性(建模)

3.6. 需求开发要遵从层次性

1. 根据业务需求，协调涉众的立场，限定问题的范围，指导用户需求的获取过程。
2. 获取用户需求，并通过分析活动将其转化为系统级需求。
3. 将系统级需求映射为系统行为。

4. 需求的分类与表述

4.1. 需求的分类

1. 需求分类是为了将需求划分为需要区别对待的不同类型

2. 项目需求：
   1. 项目的成本要控制在60万元人民币以下。
   2. 项目要在6个月内完成
3. 过程需求：
   1. 在开发中，开发者要提交软件需求规格说明文档、设计描述文档和测试报告。
   2. 项目要使用持续集成方法进行开发。
4. 系统级需求：
   1. 所有针对系统工程的需求
   2. 系统工程，包括软件工程、硬件工程和人力资源管理。
5. 硬件需求：
   1. 对硬件相关的需求
   2. 系统要购买专用服务器，其规格不低于….。
6. 其他需求：
   1. 与人力资源相关的需求以及软件、硬件、人力之间协同的需求。
   2. 人力需求：系统投入使用时，需要对用户进行1个星期的集中培训。
7. 不切实际的期望：在使用系统时，收银员必须要在2个小时内完成一个销售处理的所有操作。
   1. R16:系统要分析会员的购买记录,预测该会员将来一周和一个月内会购买的商品：有限的资源条件下不可行
   2. R17:系统要能够对每月的出入库以及销售行为进行标准的财务分析：超出软件所能影响的问题域范围
   3. R18:在使用系统时,收银员必须要在2个小时内完成一一个销售处理的所有操作：软件系统无法限制收银员的行为
   4. R19:如果一个销售处理任务在2个小时内没有完成，系统要撤销该任务的所有已执行操作：正确表述

4.2. 项目需求

1. 项目需求针对的对象是作为项目核心的计划，包括项目的成本、资源、时间和进度等。

R10:项目的成本要控制在60万元人民币以下。
R11:项目要在6个月内完成。

4.3. 过程需求

1. 过程需求针对对象是软件开发过程，包括开发人员、工具和方法等。

R12:在开发中,开发者要提交软件需求规格说明文档、设计描述文档和测试报告。
R13:项目要使用持续集成方法进行开发。

4.4. 系统级需求

4.4.1. 软件需求

1. 功能需求(Functional Requirement)：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
2. 性能需求(Performance Requirement)：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
3. 质量属性(Quality Attribute)：系统完成工作的质量，即系统需要在一个"好的程度"上实现功能需求，例如可靠性程度、可维护性程度等。
4. 对外接口(External Interface)：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
5. 约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
6. 其他：数据需求等

4.4.2. 硬件需求

1. 与硬件相关的需求
2. R14:系统要购买专用服务器,其规格不低于…

4.4.3. 其他需求

1. 与人力资源相关的需求以及软件、硬件、人力之间协同的需求被称为其他需求。
2. R15:系统投人使用时,需要对用户进行为期一周的集中培训。

4.5. 不同类型需求的作用

1. 功能需求：必备，价值的来源
2. 性能需求：动态性(系统实际运行状态)需要专门模拟
3. 质量属性：从设计(尤其是体系结构设计)的角度来讲
4. 对外接口：从封装和信息隐藏，以及多平台交互的角度来讲
5. 约束：容易忽略

4.5.1. 功能性需求

1. 功能性需求是一个软件产品得以存在的愿意，是软件系统能够解决用户问题和产生价值的基础，也是整个软件开发工作的基础。
2. 最为复杂，在所有需求中占比可达90%甚至更高。
3. 最需要按照BR(SF)、UR、SR三个层次进行展开，围绕"目标-任务-交互"来开展。
4. 一般可以用可视化、故事和场景进行描述

4.5.2. 性能需求(Performance Requirement, PR)

1. 性能的定义是:一个系统或其组成部分在限定的约束下,完成其指定功能的程度,如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的功能。
2. 常见的性能需求
   1. 速度(Speed)，系统的响应时间。PR1：所有的用户查询都必须在10秒内完成。
   2. 容量(Capacity)，系统所能存储的数据量。PR2：系统应该能够存储至少10万条销售记录。
   3. 吞吐量(Throughput)，系统在连续的时间内完成的事务数量，例如 PR3：解释器每分钟应该至少解析5000条没有错误的语句。
   4. 负载(Load)，系统可以承载的并发工作量。PR4：系统应该允许200个用户同时进行正常的工作。
   5. 实时性(Time-Critical)，严格的实时要求。PR5：监测到病人异常后，监控器必须在0.5秒内发出警报。
3. 在限定性能目标的同时给出一定的灵活性或者给出多个不同层次的目标要求
   1. PR6:98%的查询不能超过10s。
   2. PR7:
      1. (最低标准)在200个用户并发时，系统不能崩溃;
      2. (一般标准)在200个用户并发时,系统应该在80%的时间内能正常工作;
      3. (理想标准)在200个用户并发时,系统应该能保持正常的工作状态。

4.5.3. 质量属性(Quality Attribute，QR)

1. 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量(包含性能需求)，比如买鞋子的时是否会脱胶、鞋面坚韧度等特性。
2. 质量属性是为了度量质量要素而选用的特征
3. 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系
4. 质量属性的重要性
   1. 对设计与构造的影响很大
   2. 对越复杂的系统越为重要
   3. [Robert1990] ：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要。

4.5.3.1. 质量属性举例——ISO/IEC 9126

全部见课本P37-39页

4.5.3.2. 常见的质量属性示例

1. 可靠性(Reliability)：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力。
   1. Reliability6：在进行数据的下载和上传中，如果网络故障，系统不能出现故障。
      1. Reliability6.1：分店子系统应该检测到故障，并尝试重新连接网络3次，每次15秒；
         1. Reliability6.1.1：重新连接后，分店子系统应该继续之前的工作；
         2. Reliability6.1.2：如果重新连接不成功，分店子系统应该等待5分钟后再次尝试重新连接
            1. Reliability6.1.2.1：重新连接后，分店子系统应该继续之前的工作；
            2. Reliability6.1.2.2：如果重新连接仍然不成功，分店子系统将数据恢复到同步之前的状态；
      2. Reliability6.2：总店子系统应该检测到故障，并等待分店子系统的消息
         1. Reliability6.2.1：在等待10分钟仍然没有接到分店子系统的消息时，分店子系统将数据恢复到同步之前的状态
2. 可用性(Availability)：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率
   1. QA2：系统的可用性要达到98%。
3. 安全性(Security)：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的
   1. QA3：VIP顾客只能查看自己的个人信息和购买记录；收银员只能查看，不能修改、删除VIP顾客的信息。
4. 可维护性(Maintainability)：软件系统或部件能修改以排除故障、改进性能或其他属性或适应变更了的环境的容易程度，包括可修改性(Modifiability)和可扩展性(Extensibility)
   1. QA4：如果系统要增加新的特价类型，要能够在2个人月内完成。
5. 易用性(Usability)：与用户使用软件所花费的努力及其对使用的评价相关的特性。
   1. QA6：使用系统1个月的收银员进行销售处理的效率要达到10件商品/分钟

4.5.3.3. 质量属性——质量属性的开发

1. 用户并不能明确地提出他们对产品质量的期望，他们并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性
2. 需求工程师
   1. 质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性，形容词和副词通常意味着质量属性的存在
   2. 打造极致用户体验(产品优势)需重视相关的质量属性开发
      1. 对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在，并统一处理
      2. B站的效率，微信的简约，电商平台的导航与布局等：产品迭代-优雅地小步快跑

4.5.3.4. 质量属性——进展

1. 在大规模软件中，质量属性的获取与分析在更大的程度上影响上系统的成败，这也成为2000s之后最重要的研究方面之一

4.5.3.5. 示例：质量属性需求——需求规格片段

1. 性能需求
   1. Performance1：搜索主题、搜索求购信息、出售信息，应在2s内显示结果
   2. Performance2：站内信信发送后应该在1m内推送给目标用户
   3. Performance3：目标用户的请求答复发送后应该在1m内推送给请求用户
   4. Performance4：用户想要交易时输入的个人联系信息应该在1m内推送给发帖用户

4.5.4. 对外接口(External Interface，IR)

1. 解系统和其他系统之间的软硬件接口
   1. 接口的用途
   2. 接口的输入输出
   3. 数据格式
   4. 命令格式
   5. 异常处理要求

2. 用户界面
   1. 可以作为需求，写在SRS(Software Requirement Specification，需求规格说明)中，也可以利用专门的人机交互设计文档记录
   2. 简单需求：给出一个界面示意图
   3. 复杂需求：
      1. 一个界面示意图
      2. 在操作界面时的注意事项，例如按钮使用规则，数据填写规则，相应规则…
3. 通信接口：通信协议，寻址，数据及其格式
4. 往往会体现重要合作KP(支付、硬件、内网、小程序、封装的服务等)，支付方式是微信支付在前还是支付宝支付在前。

4.5.4.1. 示例：用户界面与功能需求——需求规格片段

4.5.4.2. 示例：对外接口——需求规格片段

1. IF1：与地图API的接口：定位用户与商户的位置
   1. 参数：手机GPS定位坐标；
   2. 返回值：在地图的定位，并基于此给出最近的商家。
2. IF2：支付宝接口：当订单生效应允许通过支付宝付款。
   1. 参数：商家支付宝账号，顾客支付宝账号，应付款额。
   2. 返回值：支付成功或支付失败状态。

4.5.5. 约束(Constraint，Rule)

1. 总体上限制了开发人员设计和构建系统时的选择范围
   1. 系统开发及运行的环境：包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。
   2. 问题域内的相关标准(商业模式评估)：包括法律法规、行业协定、企业规章等，比如系统的保密性要能满足xxx法律第xx条的规定。
   3. 商业规则(商业模式设计)：用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围
   4. 社会性因素：文化、信仰等社会性因素。
2. 随着2000s之后,基于web的产品发展,软件对周围环境的要求越来越突出,尤其是:
   1. 商业规则：目标、规则、中行原油宝
   2. 法规与行业规范：利用违规内容抹黑竞争对手
   3. 社会性因素：宗教信仰、价值取向、流行风潮等
3. 规则：条件性、相对独立于功能、散布、易修改

4.5.5.1. 示例：规则与功能需求——需求规格片段

4.5.6. 其他需求

1. 安装需求(例如OR1)、培训需求(OR2)、数据需求等
   1. OR1：在安装系统时，要初始化用户、商品库存等重要数据。
   2. OR2：系统投入使用时，需要对用户进行1个星期的集中培训。
2. 如果在功能需求中没有描述数据内容(例如SR3)，就需要补充描述数据信息(例如DR1~DR2)。
   1. SR3：在收银员输入商品标识时，系统显示商品信息，商品信息参见DR1、DR2；
   2. DR1：ID是规则为…的商品条形码；
   3. DR2：商品信息包括：ID、名称、描述、价格、特价、数量、总价

4.5.7. 特别提醒

1. 功能需求自身有自己的组织方式
2. 其他类型的需求，极少数独立，绝大多数围绕着功能需求进行组织，即需要在功能需求中引用其他类型的需求，类似SR ..*.*的格式

5. 优秀需求的特性

5.1. 完备性

1. 不需要做更多的扩展就可以充分的说明用户所需要的系统功能。
2. 判断标准：每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息
   1. R2.5-1：系统应该允许被扩展。
   2. (更好)R2.5-2：系统的调度算法应该允许被扩展。
3. 注意与用户端专家确认

5.1.1. 功能需求的完备性

对功能需求的描述，要确保下列方面都得到了描述：

1. 行为的触发者(Trigger)，包括：数据输入、接收的请求、要处理的异常等。
2. 行为的前置条件(Precondition)，包括：系统的模式或状态、其他外部系统的状态、任何系统数据的值等；
3. 行为(Action)，在前置条件下接受到触发者时，系统必须执行的行为；
4. 后置条件(Postcondition)，包括：系统的模式或状态、其他外部系统的状态、任何系统数据的值等；。
5. 不满足前置条件(Failed preconditions)的情况，以及相应情况下的结果(Resulting failure postconditions)
6. 功能需求完备性——需求规格说明片段

Order.Show 系统显示待选列表 
Order.Show.Select 系统标记选择项 
Order.Show.Select.Add 系统新增选项 
Order.Show.Select.Del 系统删除已选项 
Order.Show.Select.Upd 系统更改已选项 
Order.Valid.Log 系统记录本次操作

5.1.2. 数据需求的完备性

对数据需求(或者功能需求描述中的数据内容)要注意下列内容以保障完备性：

1. 类型
2. 语义(例如在数据字典或项目术语表中描述数据的含义)
3. 组成成分(例如属性，子部分等)
4. 初始值或缺省值
5. 可能的取值范围
6. 度量单位
7. 数据量
8. 更新频率
9. 可以对其施加的合理操作
10. 对外关系，例如关联、聚集、泛化等

5.1.3. 对外接口的描述的完备性

对外接口的描述要注意下列内容：

1. 接口的名字
2. 接口的定义，简短的描述
3. 接口的方向声明(In，Out，或者双向)
4. 服务请求，包括
   1. 语法，例如名称、参数、返回值
   2. 语义，含义，协议，例如前置条件、后置条件与不变量或者状态模型等
   3. 异常，语法与语义
   4. 接口定义的特殊数据类型
   5. 质量属性要求(例如性能、可靠性、安全性、保密性等)

5.1.4. 质量属性描述的完备性

对质量属性(含性能)的描述要注意下列内容以保障完备性：

1. 针对系统或其部件的质量标准
2. 明确了需要满足质量标准的情况与条件
3. 衡量质量标准所使用的单位
4. 质量度量的阈值
5. 示例：质量属性需求完备性——需求规格片段
   1. 可维护性
      1. Modifiability1：如果系统要增加一个功能模块，要能够在3人14天内完成
      2. Modifiability2：对系统数据库的优化维护工作可以在0.5个人日内完成
   2. Reliability6：系统必须易用，用户首次使用必须能在无帮助的情况下5分钟之内了解整个系统的概貌。

5.2. 正确性(真实性)

1. 真实的反映用户的意图
2. 需求在传递给开发人员前，必须请需求的提出者予以确认

5.2.1. 需求正确性难以达到的主要原因

1. 用户在表达自己的需要时，可能会在潜意识下进行一定的加工。常见的情况是:用户的问题是A，但用户认为如果提供了方法B，则问题A自然可以得到解决，为此用户向需求工程师反映的便是B，而不是真实的A。所以为了发现用户的真实需求，需求工程师一定要进行问题分析，尽力发现问题背后的问题。
2. 在人际交流中，信息会发生自然衰减，甚至扭曲，导致需求工程师理解的并非是用户所表达的。对此情况的解决方法是在需求传递给开发人员之前，请提出需求的用进行仔细检查和确认。

5.2.2. 需求的正确性[Gilb2005]

1. 多问用户"为什么"，将需求描述从具体情景、技术环境等约束中抽离出来。比如用户描述"需要将联系人信息放到Web站点上"，需求工程师得到的是"交流共享联系人信息"。
2. 从业务方面描述需求，而不是从技术方面描述需求：用涉众能听懂的话来描述。
3. 关注涉众的想法。包括关注涉众对需求的效益评价，关注涉众对需求的优先级划分，真正理解需求对于涉众的意义。
4. 在演化中理解需求。将最初始的需求展示给涉众，并利用涉众的反馈发现真正的需求。
5. 通过量化手段准确理解需求。对验证标准的反复推敲可以更准确地理解涉众的需求含义。
6. 示例：需求的正确性——需求案例
   1. 原有问题：使用搜索引擎找不到想要的东西
   2. 对应需求：期望使用搜索引擎找到需要的内容更好的搜索算法？
   3. 正确吗？
   4. 加工关键：因为噪音数据太多，导致寻找目标内容非常困难
   5. 正确需求：去除搜索引擎结果中的干扰数据

5.3. 可行性

1. 可行性由开发人员进行检查，需要进行一定的分析和研究，而不是单纯的凭借经验和直觉
2. 在系统和运行环境的已知条件和约束下实现需求(不切实际的期望，原型，用足够的可行性与成本信息帮助用户取舍)，必要的时候要通过开发原型来加以验证

5.4. 必要性

1. 满足用户的业务需求所必需的
2. 不必要的需求也是时间中常见的问题
   1. 用户将之作为和开发人员谈判的筹码，然后通过取舍来获取到自己想要的利益。
   2. 用户在交流中总是害怕信息有所遗漏，并因而产生不良后果。
   3. 需求开发人员画蛇添足，添加用户肯定会细化的功能
3. 奥卡姆剃刀原则

5.5. 无歧义

1. 每一项需求都应该有而且只能有一种解释
2. 定义一个可以共同理解的词汇表(Glossary)

3. 正确处理冲突的方式不是使用模糊化的处理方式，而是在项目前景的指导下，促进用户之间的协商解决。

5.6. 可验证

1. 通过分析、检查、模拟或者测试等方法能够判断需求是否被满足
2. 不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要
   1. 让需求具体化
   2. 小心形容词和副词的使用
   3. 避免程度词的使用

6. 例子 TODO

描述	分类
系统能够为用户提供库存分析报告、商品/利润报告和过期商品报告	SR
商品的标识由0～24位字母、数字混合组成的字符串	DR
电梯的默认停运楼层必须是最低楼层到最高楼层范围内的某个整数	constraint
系统开发成本不能超过60万人民币	constraint
在500个用户同时使用时，系统数据库和服务器都要能够正常工作	PR
系统必须能够与Oracle数据库交互	IF
如果系统要支持Android平台，需要在6人月内完成	QR-可维护性与可移植性
经过10天培训的收银员就能够熟练使用系统	BR
系统开发的成本不超过10万元RMB	Rule
使用银联专用刷卡设备，向银行传递的交易数据格式为	DR
当订单数量大于现有数量时，系统必须通知操作员	UR
产品在发布1年之后，必须在出版的A、B、C三个产品评论刊物中被评为最可靠的产品	不切实际的期望
系统每小时必须处理至少3000次呼叫	PR
软件管理工具必须帮助项目管理者进行开发管理工作，以通过CMMI-4的评估
该软件管理工具的开发过程自身必须符合CMMI-4标准
系统开发必须在6个月内完成
项目需要招聘并培训专职的系统管理员，以让其维护系统的运行与使用
系统必须能够与Oracle数据库交互
数据库与服务器之间的通信必须是加密的
在500个用户同时使用时，系统数据库和服务器都要能够正常工作
系统需要帮助项目管理者安排项目计划，具体包括
在项目管理者请求分配任务时，系统将选中的需求开发任务分配给选中的开发人员
需求开发任务的ID为：项目ID+需求ID+开发任务类型+序号

6.1. 分析问题、问题域、模拟知识、解决方案分别是什么？

1. 共享单车(ofo、mobike)

6.2. 实例分析(系统A-招标书)

说出如下需求的类型，是否存在问题

1. 实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化
2. 实现工作流程合理化、高效化，决策支持科学化、准确化；
3. 统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。
4. 先进性：软件系统采用三层B / S 系统结构，以"界面表示层－逻辑处理层－数据访问层"分层设计实现。采用国际上先进成熟的、厂商广泛支持的计算机技术、网络技术与软件技术对系统进行规划，保证系统整体架构在未来几年内都处于国际领先的地位。
5. 安全性：软件系统具有较高的安全要求，系统必须具备充分的安全措施，包括具备严格的权限控制机制和完备的日志记录，以确保信息安全。
6. 可靠性：保证系统核心功能可以7×24小时连续运行；
7. 规范性：系统必须遵循国家有关法律法规要求，符合国家有关标准要求以及关于信息系统建设的各项标准和规范。
8. 收文管理应包括:
   1. 来文登记、拟办、领导审批、办理、归档、查询统计等功能。附件支持WORD 、PDF 、EXCEL 、HTML 等文档类型格式；需提供方便、灵活、直观的文件批示处理；对收文的处理全过程进行自动化管理、跟踪和记录；在收文处理的过程中，支持电子印章、电子签名或手写批注等功能。
   2. 来文登记：完成来文登记功能。登记来文基本信息(来文编号、来文标题、主题词、来文单位、来文时间)，还要对原文进行扫描处理，引入到公文库中。并可完成收文办文单打印功能。完成后启动收文流转流程。
   3. 拟办：查看公文的基本信息，原文内容。签录拟办意见，发送给领导审批。
   4. 领导审批：查看公文的基本信息，原文内容。签录批示意见，确定主办部门、协办部门。
   5. 办理：办理人根据领导批示办理，记录办理情况。
   6. 归档：对办理完结的来文归档，将来文信息、拟办意见、领导批示、办理情况等信息及来文扫描件发送到档案管理系统，档案科确认接收的文件，才属于己归档文件。
   7. 查询统计：提供按来文编号、来文标题、主题词、来文单位、来文时间等查询统计功能，要求查询统计结果可以打印。
9. 验收投标方需提供以下文档：
   1. 软件需求分析报告
   2. 软件总体设计报告
   3. 软件操作手册
   4. 软件配置手册
   5. 软件试运行报告
   6. 应用软件介质
10. 培训要求
11. 投标人必须提供相应的应用软件技术和系统操作等方面的培训。投标人须在文件中提出全面、详细的培训课程以及时间表交给业主，并在合同签定后征得业主同意后实施。
12. 投标人应提供面向系统管理员的应用软件系统结构、日常维护等方面的培训。
13. 对于所有培训，投标人必须派出具有相应专业资格和实际工作经验的人员进行培训。
14. 投标人须提供详细的培训计划。
15. 以上培训内容的培训费用均包含在投标报价内，项目采购人不再另行支付

6.3. 示例分析B-需求规格说明问题

说出如下需求的类型，是否存在问题

1. 2.1. 开发意图
   1. 减少人力成本
   2. 提高办公效率
   3. 成本统计、查询
   4. 历史信息查询
   5. 支持WEB 操作
2. 2.3. 产品功能
   1. 2.3.1. 人员管理
      1. 对本公司的人力资源进行管理。
      2. 提供功能：新员工信息录入、信息修改(晋升、部门调动、休假、婚姻状况变更)、离职人员归档。
      3. 注)该操作需要具有人员管理权限的人才可以进行。
   2. 2.3.2. 业务管理
      1. 对本公司的业务进行管理。
      2. 提供功能：新业务录入、现有业务变更(计划提前或延后、合同金额或付款方式变更、业务内容变更)、已完成的业务归档。
      3. 注)该操作需要具有业务管理权限的人才可以进行。
   3. 2.4.1. 扩展性
      1. 要求结构设计良好，二次开发成本要求低于本次开发成本30%
      2. 能够简单的进行多语言版本改造。
   4. 2.4.2. 灵活性
      1. 支持主流浏览器：IE7,8, FireFox2.0, Google 浏览器。
   5. 2.4.3. 精度
      1. 金额相关：小数点后保留2 位有效数字；
      2. 时间相关：精确到秒；
      3. 传输过程中的精度：小数点后保留5 位有效数字。
   6. 2.4.4. 响应要求
      1. 用户登陆： <= 0.5 秒
      2. 页面跳转： <= 2 秒
   7. 2.4.5. 安全性
      1. 系统管理员(admin)负责系统维护；
      2. 根据公司体制指定各部门负责人，并赋予相应的操作权限；
      3. 所有信息保存在MySQL 数据库中；
      4. 用户密码采用密文形式保存

1. 3.3.2. 人员信息变更
   1. 目的：修改员工信息。
   2. 功能：提供员工信息修改界面，并将修改后的信息保存进MySQL 数据库。
   3. 步骤：
      1. 在界面上修改员工信息。
      2. 操作者权限检查。
      3. 操作成功，返回人员管理界面；
   4. 操作失败，提示错误信息。
   5. 流程图：

6.4. 实例分析(系统C)

1. 4.1 业务现状与分析
   1. 单一客户经理渠道从"绿色通道"变成制约集团发展的瓶颈
   2. 其他营销服务界面缺乏有效识别集团客户的工具
   3. 目前公司缺少一套贯穿全省各级公司和各部门的统一业务调度系统来协助跨部门工作
   4. 各节点缺乏受理标准时限规范，内部资源调度无法快速响应，
   5. 客户经理在面对客户时无法进行服务时限承诺，降低了集团业务的客户满意
   6. 业务支撑平台不断增多，且均需要分散维护，服务质量难以保障

7. Summary

1. 需求及其问题都具有层次性
   1. 业务需求(系统特性)、用户需求、系统级需求
   2. 目标、任务、系统交互
2. 具体的软件需求类别包括
   1. 功能需求、性能需求、质量属性、对外接口和约束等
   2. 价值基础、如何量化、体系结构设计的重要因素、隔离业务环境与人机交互、环境/标准法规/商业规则/社会
3. 优秀需求的特性
   1. 完备性：
      1. 功能属性：触发者、前置条件、行为、后置条件、前置条件不满足与相应处理
      2. 数据需求(功能需求的数据部分)：语义、成分、初始/默认值、取值范围、度量单位、数据量、更新频率、合法操作、与其它数据关系(关联、聚集、泛化)
      3. 接口：名称、定义、方向声明、服务请求
      4. 质量属性(含性能)：系统与部件的质量标准、满足质量标准的情况与条件、衡量质量标准所使用的单位、质量度量的阈值
      5. 与用户端专家确认
   2. 正确性：用户意见的真实反映(为什么、侧重业务、关注涉众、演化中理解、使用量化手段理解)
   3. 可行性：在系统和运行环境的已知条件和约束下实现需求(不切实际的期望，原型，用足够的可行性与成本信息帮助用户取舍)
   4. 必要性
      1. 奥卡姆剃刀
      2. 不必要需求的原因：用户谈判的筹码、害怕信息的遗漏、需求人员添加的"用户肯定喜欢"功能
   5. 无歧义：每种需求都只能有唯一的明确解释；最好定义一个通用的词汇表
   6. 可验证：
      1. 能够通过分析、检查、模拟或测试的需求(是否满足)
      2. 不可验证的需求往往是因为描述模糊或过于抽象